API Keys for AWS Services - Which Calls Accept a Bearer Token, the IAM User Behind Each Key, and Where to Stop It

First Published: 2026-11-10
Last Updated: 2026-11-10

Several AWS services accept requests using a bearer token in the Authorization header, rather than using SigV4 signatures. AWS documentation refers to these as API keys. Each long-term API key is associated with an IAM user. Both the permissions of that IAM user and the service-specific scope of the bearer token determine what can be accessed with a key.

This article lists five services that, as of November 10, 2026, accept API keys: Amazon Bedrock, Claude Platform on AWS, Amazon CloudWatch metrics, Amazon CloudWatch Logs, and AWS X-Ray traces. The article will outline the scope of the bearer token, the IAM user and managed policies behind each key, where the key can be stopped, and what CloudTrail records. The places to stop a key are divided into three stages: creation, use, and revocation.

This article distinguishes between information provided in AWS documentation, information that is not found in the documentation, and inconsistencies between different documentation sources. This article did not test anything in an actual environment. The process of creating keys is left to the documentation for each individual service.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What an API Key Is on AWS
4. Which Calls Accept a Bearer Token
5. The IAM User Behind the Key
6. Three Places to Stop a Key
7. What CloudTrail Records
8. Where the Sources Disagree and What They Do Not Say
9. Failure Modes
10. Frequently Asked Questions About API Keys for AWS Services
11. Summary
12. References

1. Scope and Assumptions

This chapter first defines the intended audience, the scope of this article, the consulted resources, and the terminology used. The following ten points represent the key conclusions.

AWS API keys come in two types. Long-term keys are service-specific credentials associated with an IAM user. Short-term keys are pre-signed URLs that use SigV4 (see Chapter 3).
The IAM User Guide's table of API keys lists four services as of November 10, 2026. While the X-Ray Developer Guide refers to X-Ray API keys as IAM service-specific credentials, there is no corresponding entry in the IAM table (see Chapter 4).
What a bearer token can call varies by service. CloudWatch metrics and X-Ray are limited to the ingestion endpoint only. CloudWatch Logs keys are used with the HTTP ingestion endpoints and require bearer token authentication on the receiving log group. Bedrock and Claude Platform on AWS are not limited to ingestion only (see Chapter 4).
The permissions of the associated IAM user determine what a long-term key can access. Service-specific managed policies range from allowing only the two actions required for trace ingestion to including creation and deletion actions (see Chapter 5).
There are three places to stop a key. iam:CreateServiceSpecificCredential controls creation, each service's CallWithBearerToken controls use, and revocation is done by changing the key's status or deleting the key (see Chapter 6).
To stop the use of Bedrock API keys, you must deny both bedrock:CallWithBearerToken and bedrock-mantle:CallWithBearerToken. Denying only one will not prevent usage (see Section 6.2).
Short-term Bedrock keys do not have a creation stage. The AWS Security Blog states that short-term keys are created on the client-side, and that this creation is not recorded in CloudTrail (see Section 6.1).
How these keys appear in CloudTrail varies by service. Some services have a field that indicates a bearer request, while others differentiate based on the IAM user's name (see Chapter 7).
To perform an inventory of long-term keys, use list-service-specific-credentials with the --all-users flag. Service-specific credentials are not included in the IAM credential report (see Section 7.4).
There are at least six discrepancies between the consulted resources. This article does not state that any of these resources is incorrect (see Section 8.1).

1.1 Intended Audience

This article is intended for the following audience:

Security and governance professionals responsible for deciding whether and to what extent to allow AWS API keys within their organizations.
Operations personnel who need to send metrics, logs, and traces from external tools (that do not support SigV4) to AWS.
Individuals who want to decide in advance where to stop a key if an API key leaks.
Investigators responsible for searching CloudTrail for instances of bearer token requests.

This article assumes that readers are considering the following points, and each point will be verified in the article's content:

Denying the bedrock:CallWithBearerToken action is enough to stop Bedrock API keys.
The services listed in the table in the IAM User Guide represent all services that can accept API keys.
An API key can call any API of the service it was created for.
Permissions for an API key are determined on a per-key basis.
Usage of an API key is logged in CloudTrail in the same form in every service.
API keys can be inventoried using the IAM credential report.

1.2 What This Article Covers and What It Does Not

This article covers the mechanisms of long-term and short-term keys, a cross-service table of five services, the IAM user and managed policies behind each key, the three places to stop a key, CloudTrail records, inventory, and discrepancies between sources.

This article does not cover:

The details of the two Bedrock endpoints and the IAM action that each call checks. This is covered on this site at Amazon Bedrock Inference Endpoints and API Keys.
The conditions for the receiver and the two methods for sending traces from the Claude Console to CloudWatch. This is covered on this site at Receiving Claude API OpenTelemetry Traces on AWS.
Service-specific credentials for Amazon Keyspaces and what their revocation reaches. This is covered on this site at IAM Authentication to DynamoDB, Keyspaces, and OpenSearch Service.
General principles of service control policies. This is covered on this site at AWS Organization Guardrails.
Temporary credentials issued by AWS STS and the paths used to sign with SigV4. The order in which SDKs search for credentials is covered on this site at The AWS Credential Provider Chain Across SDKs and the CLI What an Amazon Cognito identity pool hands out as temporary credentials is covered on this site at What a Cognito Identity Pool Hands Out.
Procedures for creating keys, pricing, and a list of supported regions.

This article limits its discussion of stopping keys to descriptions of controls and monitoring. It does not cover methods for extracting key values or circumventing controls.

1.3 Date of Review and Materials Reviewed

This article reviewed the following materials on November 10, 2026 (Japan Standard Time). Throughout the text, the English name at the start of each line is used.

IAM API keys page: The API keys for AWS services page in the IAM User Guide.
service-specific credentials page: The Service-specific credentials for IAM users page in the IAM User Guide.
credential report page: The credential report page in the IAM User Guide.
IAM API Reference: The CreateServiceSpecificCredential page and the ServiceSpecificCredential data type page in the IAM API Reference.
Service Authorization Reference: Seven pages in the Service Authorization Reference: IAM, Amazon Bedrock, Amazon Bedrock Powered by AWS Mantle, Claude Platform on AWS, Amazon CloudWatch, Amazon CloudWatch Logs, and AWS X-Ray.
Bedrock API keys pages: Six API key pages in the Amazon Bedrock User Guide.
Bedrock Mantle CloudTrail page: The Monitor bedrock-mantle API calls using CloudTrail page in the Amazon Bedrock User Guide.
Claude Platform pages: Four pages in the Claude Platform on AWS User Guide: Authentication, IAM policies, IAM actions, and Monitoring and logging.
CloudWatch metrics bearer page: The Setting up bearer token authentication for Metrics page in the CloudWatch User Guide.
CloudWatch Logs bearer page: The Setting up bearer token authentication page in the CloudWatch Logs User Guide.
OTLP endpoints page: The OTLP Endpoints page in the CloudWatch User Guide.
X-Ray bearer page: The Setting up bearer token authentication for traces page in the AWS X-Ray Developer Guide.
Claude traces page: The Send Claude Platform traces to Amazon CloudWatch page in the CloudWatch User Guide.
managed policy pages: The pages of the AWS Managed Policy reference.
Security Blog post: The "Securing Amazon Bedrock API keys" article on the AWS Security Blog. Published on October 17, 2025, with additions regarding Mantle on July 1, 2026.
What's New posts: Five announcements, to be listed in the table in Section 3.6.
CodeCommit history page: The document history page of the AWS CodeCommit User Guide.

Every document was read using the original text obtained with curl. The Claude Platform on AWS rows were also checked against the Claude Platform on AWS topic of Anthropic's claude-api skill.

1.4 Terms, and Different Things with the Same Spelling

This article uses the following terms consistently:

API Key: A bearer token received by AWS services instead of SigV4. In this article, this term refers only to what AWS documentation calls an "API key."
Long-Term Key: An API key created as a service-specific credential for an IAM user.
Short-Term Key: An API key in the form of a pre-signed URL that uses SigV4.
The IAM User Behind the Key: The IAM user associated with a long-term key.
Service-Specific Credential: A credential associated with an IAM user and usable only with a single service. In addition to long-term keys, this includes CodeCommit Git credentials and Amazon Keyspaces credentials.
Temporary Credentials: Credentials issued by AWS STS and used for SigV4 signing. This article distinguishes between short-term keys and temporary credentials.
The Place to Stop a Key: Refers to the three stages of creation, use, and revocation.

There are other terms that share the same spelling as "API key." API keys for Anthropic's Claude API, keys for Anthropic's Admin API, and tokens for package registries are not considered "API keys" in the context of this article. API keys for Claude Platform on AWS, which are covered in AWS documentation, are distinct from the keys created in Anthropic's Claude Console (see Section 4.3).

Similarly, "bearer token" also has other meanings. While OpenID Connect ID tokens and JWTs received by API gateways are also sent as bearer tokens, this article does not address those.

2. How to Read the Tables

This chapter defines the terminology used in the tables in this article, specifically the terms for the state of the sources, and how this article writes verification dates and dates.

2.1 Terms for the State of the Sources

This article uses six terms to describe the state of the documentation. These terms, including their English spellings, will also be used in the tables.

Stated: The documentation contains a statement regarding the matter.
Stated as not supported: The documentation explicitly states that the matter is not supported or cannot be used.
Documentation does not list: While a list or table exists, the specific item is not included. This does not necessarily indicate that the matter is unsupported or unavailable.
No statement found: Despite searching using different search terms and examining different categories of documentation (as described in Section 1.3), no relevant statement could be found. This does not necessarily indicate that the matter is absent or does not occur.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This includes cases where the statements directly contradict each other, as well as cases where the scope, strength, or subject matter differs, and the text alone does not settle which one applies. This article presents both statements and their sources without designating either as incorrect.
Inference: This represents an inference made by this article, and is not a statement found in any of the documentation. This article says in the same sentence that it is an inference.

This article distinguishes between "Stated as not supported" and "No statement found." The former refers to a statement in the documentation, while the latter indicates that this article was unable to find a relevant statement.

2.2 How This Article Writes Verification Dates and Dates

The "Verification Date" column in the table in this article refers to the date on which the values in that row were verified against the relevant documentation. Dates are recorded in Japan Standard Time. The values in the table may change after the verification date. In particular, the rows of the table on the IAM API keys page, the contents of the managed policies, and the scope that a bearer token can call change. The X-Ray API keys were recently announced on November 3, 2026.

The dates listed in the "What's New" posts refer to the publication dates specified on each announcement page. The dates and times for creating and editing managed policies are listed on the managed policy pages and are recorded in UTC.

3. What an API Key Is on AWS

This chapter explains how two types of API keys work, details the APIs that manage these keys, and outlines the order that AWS recommends, as described in the documentation.

3.1 Long-Term Keys Are Service-Specific Credentials of an IAM User

The IAM API keys page describes long-term keys as follows:

Long-term API keys are associated with an IAM user and generated using IAM service-specific credentials. These credentials are designed for use with only a single AWS service, enhancing security by limiting credential scope.

A long-term key is associated with a single IAM user and a single service. When creating a key, you must specify the name of the service, and that key can only be used with that service. The IAM API Reference, specifically the CreateServiceSpecificCredential page, describes the ServiceName field as the only service that can be accessed with the key.

The value of a long-term key is only displayed when it is created. The IAM API keys page states that if the value is lost, a new key should be created, and the old key should be deactivated.

3.2 Short-Term Keys Are Pre-Signed URLs That Use SigV4

The IAM API keys page describes short-term keys as follows:

A short-term API key is a pre-signed URL that uses AWS Signature Version 4. Short-term API keys share the same permissions and expiration as the credentials of the identity that generates the API key and are valid for up to 12 hours or the remaining time of your console session, whichever is shorter.

Short-term keys do not create IAM users. Instead, they inherit permissions and expiration from the credentials of the identity that generated them. The IAM API keys page notes that short-term keys can be generated for Amazon Bedrock and Claude Platform on AWS, and refers users to the respective user guides for instructions on how to create them. The Bedrock API keys pages specify that Bedrock short-term keys are only valid in the region where they were created.

3.3 The APIs That Manage Keys, and Limits

The IAM API keys page lists five IAM APIs for managing long-term keys: CreateServiceSpecificCredential, ListServiceSpecificCredentials, UpdateServiceSpecificCredential, DeleteServiceSpecificCredential, and ResetServiceSpecificCredential.

The limits and validity periods are as follows:

A single IAM user can have up to two sets of service-specific credentials for each service. The service-specific credentials page notes that this limit lets you keep one set in use while rotating to a new set.
The validity period is specified in days using the CredentialAgeDays parameter in the CreateServiceSpecificCredential API. The valid range for this value is 1 to 36600.
If CredentialAgeDays is not specified, the key will not expire. The IAM API Reference states that CredentialAgeDays is only valid for services that support long-term API keys.
The IAM console provides seven validity period options: 1 day, 5 days, 30 days, 90 days, 365 days, a custom date, and no expiration. The console includes a recommendation against using the "no expiration" option.
A key's status can be one of three values: Active, Inactive, or Expired. The ServiceSpecificCredential data type in the IAM API Reference lists these three values.

3.4 The Order AWS Recommends

The IAM API keys page states the following regarding long-term keys:

Long-term API keys have a higher security risk compared to short-term API keys. We recommend using short-term API keys or temporary security credentials when possible.

This is an order of recommendation, not a deprecation of long-term keys. Similar guidance is provided in the documentation for various services.

The Bedrock API keys pages recommend using long-term keys solely for exploration purposes, and short-term keys for production environments.
The CloudWatch metrics bearer page and the CloudWatch Logs bearer page recommend using SigV4 with short-term credentials wherever possible, and limiting the use of API keys to situations where short-term credentials are not feasible.
The X-Ray bearer page also recommends using SigV4 with short-term credentials where possible, and limiting the use of API keys to situations where short-term credentials are not practical.
The service-specific credentials page recommends using AWS temporary credentials wherever possible when starting from scratch.

3.5 Users of the Same Mechanism from Before API Keys

Service-specific credentials were used in two services before API keys. The IAM API Reference page for CreateServiceSpecificCredential lists CodeCommit and Amazon Keyspaces separately from services that receive long-term API keys.

CodeCommit's Git-based credentials. CodeCommit stopped accepting new customers on July 25, 2024, and has since resumed accepting new customers as of November 25, 2025. The CodeCommit history page documents these two dates.
Amazon Keyspaces' credentials. This is covered on this site's IAM Authentication to DynamoDB, Keyspaces, and OpenSearch Service page.

These two services do not use API keys sent as bearer tokens. Nevertheless, the IAM action to stop their creation is the same. This point is relevant to the conditions for service names outlined in Section 6.1.

3.6 Announcement Dates

Below is a table listing the dates for the "What's New" posts related to API keys:

Announcement	Date
Amazon Bedrock API keys	July 8, 2025
Three condition keys to control Bedrock API keys	September 4, 2025
HTTP ingestion and bearer token for CloudWatch Logs	March 16, 2026
General availability of Claude Platform on AWS	May 11, 2026
API keys for OpenTelemetry traces in CloudWatch	November 3, 2026

No announcement regarding API keys for CloudWatch metrics was found in the "What's New" posts. While there is a separate announcement regarding OpenTelemetry metrics for CloudWatch, it does not appear to correspond to the release of API keys.

4. Which Calls Accept a Bearer Token

This chapter lists, for each of five services, the calls that accept a bearer token and those that do not.

4.1 The Five-Service Table

The table on the IAM API keys page has four rows as of November 10, 2026: Amazon Bedrock, Claude Platform on AWS, Amazon CloudWatch, and Amazon CloudWatch Logs. There is no row for X-Ray. This article will add an X-Ray entry and arrange the resulting list into a table of five rows.

Service	Service Name (when creating)	IAM API Keys Page	Long-Term Key	Short-Term Key	Scope for Bearer Token	What the Sources Say a Bearer Token Cannot Call	Verification Date
Amazon Bedrock	`bedrock.amazonaws.com`	Stated	Stated	Stated	Operations for Bedrock and Bedrock Runtime	`InvokeModelWithBidirectionalStream`, Agent operations, Data Automation operations	2026-11-10
Claude Platform on AWS	`aws-external-anthropic.amazonaws.com`	Stated	Stated	Stated	Routes permitted by IAM. Same base URL and request format as SigV4.	Bedrock API keys are not supported.	2026-11-10
CloudWatch metrics	`cloudwatch.amazonaws.com`	Stated	Stated	`N/A`	Only the endpoint for ingesting OTLP metrics.	Query APIs, the PromQL endpoint, OTLP endpoints for traces and logs.	2026-11-10
CloudWatch Logs	`logs.amazonaws.com`	Stated	Stated	`N/A`	Endpoint for ingesting data via HTTP. Destination: Log groups with bearer token enabled.	No statement found.	2026-11-10
X-Ray traces	`xray.amazonaws.com`	Documentation does not list	Stated	No statement found	Only the endpoint for ingesting OTLP traces.	X-Ray APIs requiring SigV4.	2026-11-10

The table is read as follows.

The "Service Name" column lists the values that are passed to the --service-name parameter of create-service-specific-credential. The value for "Claude Platform on AWS" is taken from the CLI example on the IAM API keys page (see Section 8.1).
The N/A values in the "Short-Term Key" column are the values in the table on the IAM API keys page. X-Ray does not have a corresponding row in the table, and short-term keys are not mentioned on the X-Ray bearer page.
According to the table on the IAM API keys page, only Bedrock and Claude Platform on AWS utilize short-term keys. The OTLP endpoints page describes the bearer method for metrics and traces as passing a long-lived API key in the Authorization header.
The column of what a bearer token cannot call lists examples provided in the documentation. You cannot read something as callable simply because it is not listed in this column.

4.2 Amazon Bedrock

The Bedrock API keys pages specify the scope of operations accessible using a bearer token as follows:

Amazon Bedrock API keys are limited to Amazon Bedrock and Amazon Bedrock Runtime actions.

These pages also list the following operations that are not permitted: InvokeModelWithBidirectionalStream, Agents for Amazon Bedrock, Agents for Amazon Bedrock Runtime, and operations related to Data Automation. The key can be passed either through the environment variable AWS_BEARER_TOKEN_BEDROCK or in the Authorization header.

Bedrock API keys are accepted by both the Amazon Bedrock endpoint and the Mantle endpoint. The two endpoints have different namespaces for the actions that stop use (see Section 6.2). Details specific to each endpoint are covered on this site's Amazon Bedrock Inference Endpoints and API Keys.

4.3 Claude Platform on AWS

The Authentication page of the Claude Platform pages describes two authentication methods: SigV4 and API keys, with SigV4 designated as the primary method. Both methods utilize the same base URL and request format. API keys are provided either through the environment variable ANTHROPIC_AWS_API_KEY or as an argument to the SDK, and the SDK transmits them as a bearer token. IAM authorizes these requests using the aws-external-anthropic:CallWithBearerToken action.

The same page also limits the keys that can be used:

Only API keys created in the AWS Console under Claude Platform on AWS work with this service. Keys created in the standard Claude Console for first-party API access do not work against the Claude Platform on AWS endpoint. Amazon Bedrock API keys do not work either — Bedrock uses a separate endpoint, authentication flow, and IAM namespace.

Short-term keys are generated using a token generator library published by Anthropic, and created from IAM credentials. The same page further states that short-term keys have a default validity period of 12 hours and can be scoped to a workspace and to the aws-external-anthropic:CallWithBearerToken action.

The IAM actions page of the Claude Platform pages describes CallWithBearerToken as an authentication-layer permission that does not map to a route. The scope of requests that can be made using a bearer token is the route-mapped actions allowed together with CallWithBearerToken (see Section 6.2).

4.4 Amazon CloudWatch metrics

The CloudWatch metrics bearer page limits the scope of the metrics API key as follows:

They cannot be used to call any other CloudWatch API or endpoint, including query APIs (GetMetricData, ListMetrics, DescribeAlarms), the PromQL query endpoint, the OTLP traces endpoint, or the OTLP logs endpoint.

The metrics API key can only be used to access the OTLP metrics ingestion endpoint. This endpoint requires HTTPS and will reject requests sent using unencrypted HTTP.

When creating an API key in the CloudWatch console under Settings > Global, the console creates an IAM user and attaches the CloudWatchAPIKeyAccess managed policy, and creates a service-specific credential. The console also provides the option to store the key in AWS Secrets Manager.

4.5 Amazon CloudWatch Logs

A CloudWatch Logs API key is used to send logs in four formats to the HTTP ingestion endpoints. According to an announcement on March 16, 2026, in the "What's New" posts, these formats are HTTP Log Collector, ND-JSON, Structured JSON, and OpenTelemetry.

CloudWatch Logs has specific requirements not found in other services. To receive logs, you must enable bearer token authentication on the receiving log group. The same announcement states:

Customers must enable bearer token authentication on each log group before it can accept logs, which protects from unintended ingestion.

To enable this, use the CLI command aws logs put-bearer-token-authentication. The Service Authorization Reference describes this action as logs:PutBearerTokenAuthentication, outlining the permissions required to enable or disable bearer token authentication for a specified log group. The OTLP endpoints page also states that when sending logs to the endpoint using a bearer token, you must enable bearer token authentication on the destination log group.

This article could not find a list of APIs that cannot be called using bearer token authentication on the CloudWatch Logs bearer page (No statement found).

4.6 AWS X-Ray traces

The X-Ray bearer page describes the X-Ray API key as follows:

An X-Ray API key is an IAM service-specific credential for xray.amazonaws.com, owned by an IAM user. A request with an API key has exactly the permissions of that IAM user.

Although the X-Ray API key does not appear in the table on the IAM API keys page, the X-Ray bearer page describes the X-Ray API key as an IAM service-specific credential, and states that you can create an X-Ray key in the "API keys for AWS services" section of the IAM console. The absence of the X-Ray API key in the table on the IAM API keys page does not mean that the X-Ray API key is not an IAM API key.

The X-Ray bearer page limits the scope of what can be accessed using the bearer token as follows:

API keys work only for sending spans to the OTLP traces endpoint, which is authorized as xray:PutTraceSegments. You can't use them to call the X-Ray APIs that require SigV4, including the PutTraceSegments API and the APIs that read trace data.

The same page also states that the endpoint for OTLP traces requires Transaction Search and that requests must be made over HTTPS. The key can be used with the standard endpoint, the FIPS endpoint, and the X-Ray interface VPC endpoint. A single IAM user can have up to two X-Ray API keys.

Regarding the two methods for sending traces from the Claude Console to CloudWatch, see this site's Receiving Claude API OpenTelemetry Traces on AWS.

4.7 A Single Key Can Only Be Used with One Service

Both the CloudWatch metrics bearer page and the CloudWatch Logs bearer page state that a separate API key is required for each service. The Claude traces page indicates that a dedicated API key is needed for traces, and that keys created for CloudWatch metrics or CloudWatch Logs cannot be used.

This is consistent with the characteristics of the long-term keys described in Section 3.1. If you are sending metrics, traces, and logs from the same external tool, you will need three keys. Whether to assign these three keys to a single IAM user or to create separate IAM users for each service is not specified in the documentation. The X-Ray bearer page recommends using one IAM user per application or integration.

5. The IAM User Behind the Key

This chapter describes where long-term key permissions are determined and details the managed policies that are automatically applied.

5.1 Key Permissions Are the Permissions of the IAM User

The IAM API Reference documentation for CreateServiceSpecificCredential describes the UserName field as follows:

The new service-specific credentials have the same permissions as the associated user except that they can be used only to access the specified service.

Similarly, the X-Ray bearer page, as described in Section 4.6, states that API key requests inherit the permissions of the associated IAM user. Long-term keys themselves do not have a dedicated permissions field. To modify what a key can access, you must change the IAM user's policy. The Bedrock API keys pages also state that to change the permissions of a long-term key, you must modify the policy associated with that user.

Based on this behavior, the following two points follow:

Two keys associated with the same IAM user will have the same permissions. It is not possible to assign different permissions to individual keys.
The IAM user's policy, not the key itself, determines the extent of what an attacker can access when a key is compromised.

5.2 Managed Policies Attached Automatically

The IAM API keys page describes the application of managed policies as follows:

When you generate a long-term API key for a service, the corresponding AWS managed policy is automatically attached to the IAM user, granting access to core operations for that service.

The following table lists five services, their associated managed policies, and a selection of the actions included within each policy. It also lists the documentation used to verify the policy content.

Service	Managed Policy	Included Actions (Selection)	Documentation Verifying Content	Verification Date
Amazon Bedrock	`AmazonBedrockLimitedAccess`	`bedrock:CallWithBearerToken`, `bedrock-mantle:CallWithBearerToken`, `bedrock:InvokeModel`, `bedrock:Get`, `bedrock:List`, creation and deletion of guardrails and custom models	managed policy pages	2026-11-10
Claude Platform on AWS	`AnthropicInferenceAccess`	Actions for `AnthropicReadOnlyAccess` and inference actions	IAM policies page of the Claude Platform pages	2026-11-10
CloudWatch metrics	`CloudWatchAPIKeyAccess`	`cloudwatch:CallWithBearerToken`, `cloudwatch:PutMetricData`, `cloudwatch:PutProfileRecords`, conditional `kms:Decrypt`	managed policy pages	2026-11-10
CloudWatch Logs	`CloudWatchLogsAPIKeyAccess`	`logs:CallWithBearerToken`, `logs:PutLogEvents`, conditional KMS actions	managed policy pages	2026-11-10
X-Ray traces	`AWSXRayAPIKeyAccess`	`xray:CallWithBearerToken`, `xray:PutTraceSegments`	managed policy pages	2026-11-10

The following explains how to interpret the table.

The X-Ray row is not found in the table on the IAM API keys page. While the X-Ray bearer page recommends attaching AWSXRayAPIKeyAccess, it does not state that it is attached automatically.
As of November 10, 2026, a dedicated page for AnthropicInferenceAccess could not be found in the managed policy pages. The URL redirects to an overview page for the managed policy reference. The content was verified with the description on the IAM policies page of the Claude Platform pages. This does not indicate that the policy does not exist.
AnthropicReadOnlyAccess permits Get*, List*, and CallWithBearerToken. AnthropicInferenceAccess includes those permissions, plus CreateInference, CreateBatchInference, CancelBatchInference, DeleteBatchInference, and CountTokens.

5.3 Which Path Automatically Applies Policies?

The IAM API keys page states, as described in Section 5.2, that when creating a long-term key, a managed policy is automatically applied. However, the same page's CLI instructions detail creating an IAM user with create-user, then attaching a managed policy with attach-user-policy, before creating a key with create-service-specific-credential. Similarly, the CLI instructions on the Bedrock API keys pages also specify explicitly attaching a managed policy in the same order.

The following service documentation describes the process of automatically applying policies through the console.

The CloudWatch metrics bearer page and the CloudWatch Logs bearer page state that when creating an API key through the console, the console creates an IAM user, attaches a managed policy, and then creates the key.
The Bedrock API keys pages state that when creating a long-term key, an IAM user is created, the selected policy is applied, and the key is associated with that user.

This article interprets the "automatically applied" behavior described on the IAM API keys page as the behavior of the console path (Inference). When using the CLI or API, it is necessary to attach a policy to the IAM user before creating the key.

5.4 The Scope of Managed Policies Varies by Service

The managed policies listed in the table in Section 5.2 have significantly different scopes.

AWSXRayAPIKeyAccess only allows two actions: those required for ingesting traces.
CloudWatchAPIKeyAccess and CloudWatchLogsAPIKeyAccess allow actions for ingesting data and KMS actions for writing to encrypted destinations. These KMS actions are subject to conditions that apply only when using CloudWatch or CloudWatch Logs.
AmazonBedrockLimitedAccess allows not only inference, but also guardrails, custom models, provisioned throughput, and the creation and deletion of inference profiles. Additionally, it allows actions related to AWS Marketplace subscriptions, subject to the aws:CalledViaLast condition.
Regarding AnthropicInferenceAccess, the IAM policies page of the Claude Platform pages states:

Through the Get* and List* wildcards it grants read access to every API resource in the namespace, including file content download through GetFile and memory contents through GetMemoryStore.

As described in Section 5.1, the IAM user's permissions determine what a key can invoke. Therefore, this article infers that long-term keys for Bedrock and Claude Platform on AWS, if left with their managed policies, can invoke more than just inference (Inference). The CloudWatch metrics bearer page and the CloudWatch Logs bearer page recommend using the managed policies as a starting point and then refining them as needed. The Security Blog post provides an example of replacing AmazonBedrockLimitedAccess with a custom policy that limits permissions.

AWS may update the contents of managed policies. The overview page of the managed policy reference states that when AWS updates the permissions in a managed policy, the update affects all principals that the policy is attached to. The CloudWatchAPIKeyAccess page indicates the last modification was November 3, 2026, at 13:57 UTC.

5.5 No IAM User Stands Behind a Short-Term Key

Short-term keys do not create IAM users (see Section 3.2). The permissions associated with a short-term key are those of the principal who created it. The Bedrock API keys pages state that short-term keys inherit the permissions of that principal. The Authentication page of the Claude Platform pages indicates that the principal using a short-term key also requires the aws-external-anthropic:CallWithBearerToken permission.

To modify the permissions of a short-term key, you must change the policy of the principal who created it.

6. Three Places to Stop a Key

This chapter outlines the places where keys can be stopped, in three stages: creation, use, and revocation.

6.1 Stopping Creation

The IAM action iam:CreateServiceSpecificCredential governs the creation of long-term keys. The resource for this action is an IAM user, allowing you to restrict which users can create keys. The Service Authorization Reference lists two condition keys for this action:

iam:ServiceSpecificCredentialServiceName: Filters by the name of the service.
iam:ServiceSpecificCredentialAgeDays: Filters by the number of days the key is valid.

The following policy, an example from the CloudWatch Logs bearer page, allows the creation of only CloudWatch Logs keys that expire within 90 days, specifically for a designated IAM user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:CreateServiceSpecificCredential",
      "Resource": "arn:aws:iam::123456789012:user/username",
      "Condition": {
        "StringEquals": {
          "iam:ServiceSpecificCredentialServiceName": "logs.amazonaws.com"
        },
        "NumericLessThanEquals": {
          "iam:ServiceSpecificCredentialAgeDays": "90"
        }
      }
    }
  ]
}

When denying creation, it is important to pay close attention to the service name condition. The Security Blog post states:

If you do not use the condition iam:ServiceSpecificCredentialServiceName in an IAM policy, iam:CreateServiceSpecificCredential will then also deny the creation of API keys for other services, such as AWS CodeCommit and Amazon Keyspaces (for Apache Cassandra).

Both the CloudWatch metrics bearer page and the CloudWatch Logs bearer page include similar warnings in their examples, which demonstrate how to deny both creation and use. If you deny the iam:CreateServiceSpecificCredential action without specifying a service name condition, you will also prevent the creation of the CodeCommit and Amazon Keyspaces credentials described in Section 3.5.

Short-term keys do not have this creation stage. The Security Blog post describes short-term keys for Bedrock as follows:

Short-term API keys are generated locally on the client side, therefore their creation of these short-term keys won't be recorded in CloudTrail

The same article states that short-term key creation cannot be blocked, and advises stopping their use instead. A statement regarding whether the creation of short-term keys for Claude Platform on AWS is logged in CloudTrail could not be found in the materials reviewed (No statement found).

6.2 Stopping Use

Each service's CallWithBearerToken action controls the use of a key. The actions for the five services are listed in the table below:

Service	Action to Stop Use	Key-Type Condition Key in the Service Authorization Reference	Verification Date
Amazon Bedrock endpoint	`bedrock:CallWithBearerToken`	`bedrock:BearerTokenType`	2026-11-10
Amazon Bedrock Mantle endpoint	`bedrock-mantle:CallWithBearerToken`	`bedrock-mantle:BearerTokenType`	2026-11-10
Claude Platform on AWS	`aws-external-anthropic:CallWithBearerToken`	`aws-external-anthropic:BearerTokenType`	2026-11-10
CloudWatch metrics	`cloudwatch:CallWithBearerToken`	Documentation does not list	2026-11-10
CloudWatch Logs	`logs:CallWithBearerToken`	Documentation does not list	2026-11-10
X-Ray traces	`xray:CallWithBearerToken`	Documentation does not list	2026-11-10

The key-type condition keys filter by whether the key is short-term or long-term. The Service Authorization Reference describes each of the three condition keys as filtering by short-term or long-term bearer tokens. The CallWithBearerToken rows for CloudWatch, CloudWatch Logs, and X-Ray do not list a condition key. This is not a statement that filtering by type is impossible for these three services.

Bedrock has two namespaces. The Bedrock API keys pages state the following:

Denying only bedrock:CallWithBearerToken does not prevent API key usage through the Mantle endpoint. You must also deny bedrock-mantle:CallWithBearerToken to completely block API key usage.

CallWithBearerToken is an authentication-layer permission. A bearer token request requires both CallWithBearerToken and the action of the operation.

The X-Ray bearer page states that xray:CallWithBearerToken allows authentication using an API key, and xray:PutTraceSegments authorizes the sending of spans.

The IAM policies page of the Claude Platform pages indicates that without CallWithBearerToken, requests using an API key will be rejected before they reach the authorization check for inference. The same page notes that this action is not required for SigV4 calls.

Therefore, for Claude Platform on AWS, even if CallWithBearerToken is denied, SigV4 calls will continue to function. Only requests using a bearer token will be blocked. That the same holds for the other services is this article's reading, based on the Service Authorization Reference describing each service's CallWithBearerToken as permission for authentication using a bearer token (Inference).

The following policy collectively denies the use of bearer tokens for five different services. It combines the Action of the deny examples in the Bedrock, CloudWatch metrics, CloudWatch Logs, and X-Ray documentation, adds aws-external-anthropic:CallWithBearerToken, and consolidates them into a single statement. No deny example for this action was found in the Claude Platform pages (No statement found).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "bedrock:CallWithBearerToken",
        "bedrock-mantle:CallWithBearerToken",
        "aws-external-anthropic:CallWithBearerToken",
        "cloudwatch:CallWithBearerToken",
        "logs:CallWithBearerToken",
        "xray:CallWithBearerToken"
      ],
      "Resource": "*"
    }
  ]
}

There are two service-specific considerations:

CloudWatch Logs determines whether to accept bearer tokens based on the configuration of the receiving log group. Log groups that do not have bearer authentication enabled will not accept bearer logs (Section 4.5). The permission required to modify this setting is logs:PutBearerTokenAuthentication.
The X-Ray bearer page states that xray:CallWithBearerToken is evaluated solely based on identity-based policies. The same page indicates that to prevent usage, you must either deny the principal's xray:CallWithBearerToken permission or deny it through an organization's service control policy. To restrict usage to specific networks, you should add an aws:SourceIp condition to the statements that allow xray:CallWithBearerToken and xray:PutTraceSegments.

6.3 Revoking

There are three methods for revoking a long-term key:

Set the status to Inactive: This can be done using UpdateServiceSpecificCredential. The key remains, and can be reactivated to Active.
Regenerate the value: This can be done using ResetServiceSpecificCredential. The key's ID remains, but it will have a new value. The CloudWatch metrics bearer page and the CloudWatch Logs bearer page state that an expired key cannot be reset.
Delete the key: This can be done using DeleteServiceSpecificCredential.

Keys created with CredentialAgeDays become Expired when the period ends.

The CloudWatch metrics bearer page and the CloudWatch Logs bearer page recommend first setting suspected compromised keys to Inactive. The X-Ray bearer page recommends either immediately setting keys to Inactive or deleting them. To stop all bearer requests by an IAM user while investigating, attach a policy that denies CallWithBearerToken to that user. These pages also state that you must use AWS credentials, not an API key, to manage keys.

Only the X-Ray bearer page mentions the time it takes for changes to take effect.

Changes to a key's status or the user's permissions take effect within about five minutes.

Regarding the other four services, no statement was found regarding the time it takes for changes to take effect (No statement found).

Short-term keys do not have options to set them to Inactive or delete them.

The Bedrock API keys pages state that if a short-term key is compromised, you should either invalidate the session in which the key was created or apply a policy that denies the CallWithBearerToken permission.
The Authentication page of the Claude Platform pages states that short-term keys expire automatically and do not require explicit rotation or revocation. No information was found regarding methods to stop them before their expiration date (No statement found). Based on the information in Section 5.5, this article infers that because short-term key permissions are derived from the permissions of the principal that created them, denying that principal's aws-external-anthropic:CallWithBearerToken permission will prevent the bearer token from being used (Inference).

6.4 Stages Where Service Control Policies Can Stop a Key

A service control policy can stop keys at two stages: creation and use.

Creation: Deny the iam:CreateServiceSpecificCredential action. Whether to apply conditions based on the service name should follow the guidance in Section 6.1. A "What's New" post from March 16, 2026, states that service control policies can block the creation of service-specific credentials.
Use: Deny each service's CallWithBearerToken action. The X-Ray bearer page explicitly mentions denying it in a service control policy. The Security Blog post provides an example of a service control policy that denies both the creation of Bedrock service-specific credentials and the use of API keys in Bedrock.

Revocation changes the state of a key, so it is not done with a policy. General principles regarding service control policies are covered on this site at AWS Organization Guardrails.

7. What CloudTrail Records

This chapter details how the creation and use of keys are recorded in CloudTrail, on a service-by-service basis.

7.1 Creation and Management of Long-Term Keys

The creation of long-term keys is recorded in CloudTrail as a call to IAM's CreateServiceSpecificCredential. The Security Blog post provides an example, showing events with eventSource set to iam.amazonaws.com. Status changes, resets, and deletions are also IAM API calls.

As described in Section 6.1, the creation of short-term keys is not recorded in CloudTrail for Bedrock.

7.2 Records of Use

The format of usage logs varies depending on the service.

Service	Logging Method	How to Identify Bearer Token Requests	Verification Date
Amazon Bedrock endpoint	The Security Blog post describes inference calls such as Converse as management events.	Check `additionalEventData` for `callWithBearerToken` set to `true`.	2026-11-10
Amazon Bedrock Mantle endpoint	Inference calls are logged as data events. Management events are also recorded.	Check `requestParameters` for `callWithBearerToken` and, if applicable, `bearerTokenType`.	2026-11-10
Claude Platform on AWS	Inference calls and similar activities are logged as data events. The resource type is `AWS::AWSExternalAnthropic::Workspace`.	No statement found.	2026-11-10
CloudWatch metrics	Logged as data events. The resource type is `AWS::CloudWatch::Dataset`.	Filter by the name of the API key's IAM user.	2026-11-10
CloudWatch Logs	Data events for calls with `CallWithBearerToken`. The resource type is `AWS::Logs::LogGroupAuthorization`.	The resource type itself indicates a bearer call.	2026-11-10
X-Ray traces	Data events for `PutTraceSegments`. The resource type is `AWS::XRay::Trace`.	Check `additionalEventData` for `callWithBearerToken` set to `true`.	2026-11-10

The table is to be read as follows.

The Bedrock Mantle CloudTrail page states that the service adds callWithBearerToken to the requestParameters of every Mantle management event. It also states that the bearerTokenType is included when applicable.

The CloudWatch metrics bearer page indicates that for OTLP ingestion events, the AdditionalEventData.protocol field will be OTLP. This field differentiates between OTLP ingestion and the traditional SDK PutMetricData, but does not differentiate between bearer and SigV4. The documentation specifies that bearer requests should be filtered by the IAM user name associated with the API key.

The X-Ray bearer page states that for API key request events, the userIdentity field will indicate the IAM user holding the key. SigV4 requests do not have a callWithBearerToken field.

The Monitoring and logging page of the Claude Platform pages describes workspace and vault operations as management events, while operations such as inference, batch processing, and file handling are categorized as data events. There is no mention of whether CallWithBearerToken itself is logged, or whether a field indicating a bearer request is present (No statement found).

An example on the X-Ray bearer page illustrates a bearer request event as follows:

{
  "eventSource": "xray.amazonaws.com",
  "eventName": "PutTraceSegments",
  "eventCategory": "Data",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::111122223333:user/xray-traces-api-key-user",
    "accountId": "111122223333",
    "userName": "xray-traces-api-key-user"
  },
  "additionalEventData": {
    "callWithBearerToken": true,
    "protocol": "OTLP"
  },
  "resources": [
    {
      "type": "AWS::XRay::Trace"
    }
  ]
}

7.3 Data Events Are Not Recorded by Default

The data events listed in the table in Section 7.2 are not recorded by default. The X-Ray bearer page states:

CloudTrail doesn't log data events by default.

The CloudWatch metrics bearer page, the CloudWatch Logs bearer page, and the Bedrock Mantle CloudTrail page also indicate that advanced event selectors must be configured to record data events. The Monitoring and logging page of the Claude Platform pages states that explicit configuration is required to record data events. The concept of data events is discussed on this site at What Counts as a Data Plane Action on AWS.

The actual key values are not recorded. The Bedrock API keys pages state:

All API calls are logged in AWS CloudTrail. API keys are passed as authorization headers and are not logged.

7.4 Inventory

To list long-term keys, use list-service-specific-credentials with the --all-users flag. The IAM API keys page describes this method as a way to retrieve metadata for all long-term keys within an account. The same page provides an example of specifying a service using the --service-name flag. The CloudWatch metrics bearer page notes that the list response includes creation time and status.

The IAM credential report does not include service-specific credentials. The credential report page states:

The report does not include service-specific credentials (such as CodeCommit passwords, Amazon Bedrock long-term API keys, or Amazon CloudWatch Logs long-term API keys) or any other user access keys beyond the first two.

The items within parentheses are examples and do not represent a complete list. The same page explains that to view all credentials, you should use the ListServiceSpecificCredentials and ListAccessKeys APIs. Regarding the credential report, this site also addresses Where the Logs Come From on AWS.

Short-term keys are not included in the list. The Security Blog post explains that short-term keys for Bedrock are created on the client-side and cannot be listed through AWS APIs. The same article provides an example of how to periodically check IAM users with active, service-specific credentials using AWS Config rules.

8. Where the Sources Disagree and What They Do Not Say

This chapter collects the inconsistencies and missing information found in the documents reviewed for this article.

8.1 Where the Sources Disagree

This article identifies six points where the data sources disagree. It does not conclude that any single source is incorrect.

How to create API keys for Claude Platform on AWS. The CLI instructions on the IAM API keys page create a long-term key as a service-specific credential by passing aws-external-anthropic.amazonaws.com to the --service-name parameter. The Authentication page of the Claude Platform pages states that only keys created in the Claude Platform on AWS console are valid (Section 4.3). The Claude Platform pages do not mention IAM users or service-specific credentials. Whether the keys created through the two paths are the same cannot be determined from the documentation.

Naming conventions for returned values when creating keys. Both the IAM API keys page and the Bedrock API keys pages refer to the key value as ServiceApiKeyValue. The CloudWatch metrics bearer page, the CloudWatch Logs bearer page, and the X-Ray bearer page use the term ServiceCredentialSecret. The ServiceSpecificCredential data type in the IAM API Reference describes ServiceCredentialSecret as the secret portion of Bedrock API keys and CloudWatch Logs API keys, and has no ServiceApiKeyValue field. The same data type states that ExpirationDate is returned only for Bedrock API keys and CloudWatch Logs API keys.

Spelling of the key-type condition keys. The Service Authorization Reference uses the terms bedrock:BearerTokenType and bedrock-mantle:BearerTokenType. The Bedrock API keys pages use bedrock:bearerTokenType and bedrock-mantle:bearerTokenType. This article will use the spelling from the Service Authorization Reference.

Actions authorizing the ingestion of X-Ray traces. The X-Ray bearer page states that the endpoint for OTLP traces is authorized as xray:PutTraceSegments. The Service Authorization Reference describes xray:PutSpans as the permission to send OpenTelemetry spans to X-Ray. The two statements do not settle which one applies to which path.

Describing the validity period for short-term keys. The IAM API keys page states that the maximum validity period is 12 hours, or the remaining duration of the console session, whichever is shorter. The Bedrock API keys pages state that the validity period is 12 hours, or the duration of the session of the principal that generated the key, whichever is shorter. The Authentication page of the Claude Platform pages states that the default validity period is 12 hours. The maximum and default periods are not the same.

The CallWithBearerToken resource for Claude Platform on AWS. The IAM policies page of the Claude Platform pages states that principals that authenticate with an API key need CallWithBearerToken on the target workspace. The explanation of an example on the same page describes CallWithBearerToken as an action without a route that does not bind to a workspace ARN, and sets the Resource to *.

8.2 What the Documentation Does Not List

For the following three items, a table or list exists, but the item is not in it (Documentation does not list):

The X-Ray row in the table on the IAM API keys page. The X-Ray bearer page describes X-Ray API keys as IAM service-specific credentials (see Section 4.6).
The rows for CloudWatch, CloudWatch Logs, and X-Ray's CallWithBearerToken in the Service Authorization Reference, specifically the condition keys (see Section 6.2).
The AnthropicInferenceAccess page in the managed policy pages (see Section 5.2).

8.3 Items with No Statement Found

No statement was found for the following items in the materials reviewed for this article (No statement found). None of these indicates that the item does not exist.

The "What's New" announcement of API keys for CloudWatch metrics.
A field that indicates a bearer request in CloudTrail events for Claude Platform on AWS.
Whether the creation of short-term keys for Claude Platform on AWS is recorded in CloudTrail.
The time it takes for changes to key status and permissions to take effect in the four services other than X-Ray.
A list of APIs that cannot be accessed with CloudWatch Logs API keys.
Short-term keys for X-Ray.

8.4 Important Notes When Reading

The table on the IAM API keys page is dynamic. The X-Ray API key was announced on November 3, 2026, and as of November 10, 2026, the table has no row for it. Do not interpret the number of rows in the table as representing the number of services that receive the API key.
The managed policies are subject to change by AWS. The table in Section 5.2 reflects the information as of the date of verification.
The consolidated deny policy in Section 6.2 of this article combines examples from the documentation of several services; it is not an example from a single source.

9. Failure Modes

This chapter gathers common failures identified from the materials presented in Chapters 3 through 8.

Denying only bedrock:CallWithBearerToken to stop Bedrock API keys: Usage through the Mantle endpoint continues. You should also deny bedrock-mantle:CallWithBearerToken (Section 6.2).
Reading the rows of the table on the IAM API keys page as all services that can receive API keys: X-Ray API keys do not have a corresponding row, but they are IAM service-specific credentials (Section 4.6).
Assuming that an API key can call any API of the service it was created for: CloudWatch metrics and X-Ray keys are only usable with their respective ingestion endpoints (Sections 4.4 and 4.6).
Assuming that a single key can be reused for metrics, traces, and logs: The key is only valid for the service it was created for (Section 4.7).
Assuming that you can assign permissions on a per-key basis: For long-term keys, the permissions are those of the IAM user behind the key (Section 5.1).
Treating long-term keys for Bedrock and Claude Platform on AWS with their managed policies as keys solely for inference: AmazonBedrockLimitedAccess includes create and delete actions, while AnthropicInferenceAccess allows read access to all resources in the namespace (Section 5.4).
Assuming that managed policies are automatically attached when creating keys using the CLI: The CLI instructions on the IAM API keys page attach managed policies explicitly (Section 5.3).
Denying iam:CreateServiceSpecificCredential without a service name condition: This also prevents the creation of credentials for CodeCommit and Amazon Keyspaces (Section 6.1).
Assuming that preventing creation also stops short-term keys: Bedrock short-term keys do not have a creation stage; stop their use instead (Section 6.1).
Assuming that, in CloudWatch Logs, creating a key is enough to receive bearer logs: You must enable bearer token authentication on the receiving log group (Section 4.5).
Assuming that denying CallWithBearerToken also blocks SigV4 calls: The Claude Platform pages state that SigV4 calls do not need this action. That only bearer requests are affected for the other services as well is this article's reading (Inference, Section 6.2).
Assuming that the CloudTrail events of all services include a callWithBearerToken field: CloudWatch metrics events are filtered by IAM user name, while CloudWatch Logs events are distinguished by resource type (Section 7.2).
Searching for bearer request records without configuring data events: Data events are not recorded by default (Section 7.3).
Taking an inventory of API keys with credential reports: Service-specific credentials are not included in the credential reports (Section 7.4).
Copying field names and condition key spellings from different documents as if they were one: The documents spell them differently (Section 8.1).

10. Frequently Asked Questions About API Keys for AWS Services

This chapter answers the reader assumptions outlined in Section 1.1, using statements from Chapters 3 through 8.

Q1. To stop a Bedrock API key, is it sufficient to simply deny the `bedrock:CallWithBearerToken` permission?

No, it is not. The Bedrock API keys pages state that denying only bedrock:CallWithBearerToken will not prevent the API key from being used with the Mantle endpoint. You must also deny the bedrock-mantle:CallWithBearerToken permission (see Section 6.2).

Q2. Does the list of services displayed in the table on the IAM API keys page represent all services that can receive API keys?

No, it does not. As of November 10, 2026, the table consists of four rows and does not include an entry for X-Ray. The X-Ray bearer page describes X-Ray API keys as IAM service-specific credentials (Sections 4.1 and 4.6).

Q3. Can an API key call any API of the service it was created for?

There are cases where this is not possible. The key for CloudWatch metrics only works with the endpoint for ingesting OTLP metrics and cannot be used with the query APIs. Similarly, the key for X-Ray only works with the endpoint for ingesting OTLP traces and cannot be used with X-Ray APIs that require SigV4. The key for Bedrock is limited to operations involving Bedrock and Bedrock Runtime, and certain operations are excluded (see Chapter 4).

Q4. Can permissions be separated for each API key?

Permissions cannot be separated for long-term keys. The IAM API Reference states that service-specific credentials have the same permissions as the associated IAM user, but are only usable with the specified service. To separate permissions, you must separate IAM users (see Section 5.1).

Q5. Where should you restrict access to prevent all API keys from being used in the organization?

To completely prohibit the use of API keys within an organization, you need to deny access in two stages: creation and use. The iam:CreateServiceSpecificCredential permission controls creation, and you need to determine whether to apply a condition based on the service name. If you do not, this will also prevent the creation of CodeCommit and Amazon Keyspaces credentials. Use is restricted by denying access to six CallWithBearerToken actions across five services. Bedrock has two namespaces (see Sections 6.1, 6.2, and 6.4).

Q6. How can you distinguish bearer token requests in CloudTrail?

It varies depending on the service. With X-Ray and the Amazon Bedrock endpoint, you can identify them through additionalEventData and its callWithBearerToken field. For the Mantle endpoint, you can identify them through requestParameters and its callWithBearerToken field. CloudWatch Logs identifies them through data events with the resource type AWS::Logs::LogGroupAuthorization. CloudWatch metrics can be filtered by the IAM user name associated with the API key. The method for distinguishing requests in Claude Platform on AWS could not be found in the materials consulted for this article (Section 7.2).

Q7. Can API keys be inventoried in the IAM credential report?

No. The credential report page states that the credential report does not include service-specific credentials. Long-term keys can be listed using the list-service-specific-credentials command with the --all-users flag. Short-term keys are not included in the list (see Section 7.4).

Q8. If a long-term key may have leaked, what should be stopped first?

The CloudWatch metrics bearer page and the CloudWatch Logs bearer page first instruct you to set the key status to Inactive. To stop all bearer requests by that IAM user, attach a policy that denies CallWithBearerToken to the user. Subsequently, investigate in CloudTrail how the key was used, create a new key, and then delete the old key. The X-Ray bearer page states that changes take effect within about five minutes (Section 6.3).

11. Summary

Before allowing or stopping AWS service API keys, ensure the following:

Review the IAM API keys page and the documentation for the services you intend to use. Verify that, since the verification date of this article (November 10, 2026), the rows in the table, the scope of what can be accessed with a bearer token, and the managed policies have not changed.
For the services you are using, confirm the scope of what can and cannot be accessed using a bearer token, based on the service's documentation.
Determine whether to keep the managed policy as the policy of the IAM user behind each long-term key, or to restrict it.
When creating keys, restrict creation using the iam:CreateServiceSpecificCredential permission and two condition keys, and set a maximum validity period.
Decide whether to apply a condition based on the service name when denying creation, considering the impact on CodeCommit and Amazon Keyspaces credentials.
When stopping use, deny the CallWithBearerToken permission on a service-by-service basis, including the two Bedrock namespaces.
In CloudWatch Logs, enable bearer token authentication only for log groups that accept bearer tokens.
As part of your incident response procedures, define the steps to take if a key leaks: set the key to Inactive, deny CallWithBearerToken, check CloudTrail, create a replacement, and delete the old key.
Configure CloudTrail to record data events for the services you are using and define how to identify bearer token requests.
Perform inventory of long-term keys using the list-service-specific-credentials command, rather than using credential reports.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi