Claude Platform on AWS Access Unifies Three Environments, but IAM Precision Decides the Security Outcome

AWS has documented three Claude Platform on AWS access paths under one subscription, despite their sharply different credential and security requirements.

Published October 1, the implementation connects AWS workloads, developer laptops, and external services to workspaces held in a dedicated AI Services account. Production applications use cross-account Signature Version 4, developers receive scoped API keys, and external workloads authenticate through OpenID Connect federation.

The architecture promises centralized billing and administration without forcing every environment through one credential model. Its tension is equally clear. Centralization simplifies ownership, but a broad IAM policy or mishandled developer key can weaken the workspace boundaries that make the design useful.

This is not simply another Claude integration guide. The AWS implementation turns authentication into an environment-specific control plane. It also exposes the operational work hidden behind the phrase “single subscription.”

Amazon Bedrock remains an important reference point. It provides Claude models through an AWS-managed foundation model service. Claude Platform on AWS instead offers Anthropic’s native platform experience through an AWS account, including its APIs, console, and platform features.

The new access pattern does not erase that distinction. It shows how enterprises can extend Anthropic’s native platform across an AWS organization while retaining IAM-based control over production traffic.

One Subscription Now Serves Three Trust Boundaries

The important change is not broader connectivity alone. AWS has mapped three environments to three distinct authentication methods while keeping workspace ownership centralized.

The proposed topology begins with three account roles. A management account handles organization-level billing and governance. A dedicated AI Services account owns the Claude Platform subscription, workspaces, API keys, and access roles.

One or more workload accounts then consume Claude inference without owning the subscription. Their applications assume roles in the AI Services account and call workspace resources authorized by those roles.

That separation gives the AI Services account a specific purpose. It becomes the administrative boundary around Claude access, rather than another general application account filled with unrelated resources.

AWS recommends creating separate production and development workspaces inside that account. A workspace is the resource boundary used to separate teams, projects, or environments while retaining centralized administration.

Each workspace has an Amazon Resource Name, or ARN, that IAM policies can reference. Permissions can therefore authorize inference against one workspace without automatically authorizing another.

The first access path covers applications already running inside AWS. AWS uses an Amazon EKS pod as its example, although the pattern can apply to other AWS workloads.

That pod first assumes a cross-account role in the AI Services account. The temporary credentials then sign Claude requests with AWS Signature Version 4, commonly called SigV4.

SigV4 cryptographically signs AWS API requests using AWS credentials. It lets the receiving service verify the caller, request integrity, and authorization context without a separate static API secret.

The cross-account role grants selected aws-external-anthropic actions against the production workspace ARN. The example includes inference, token counting, model retrieval, and model listing.

The role does not need permission to access the development workspace. This creates a direct relationship between the workload identity, its allowed API actions, and its permitted Claude workspace.

The second path covers developer laptops. Developers often need a lower-friction way to test prompts, SDK behavior, and application logic outside a deployed workload.

AWS assigns these users a long-lived API key associated with the development workspace. The standard Anthropic SDK can use that key against the regional Claude Platform on AWS endpoint.

This route preserves a familiar developer experience, but it creates a persistent bearer credential. Anyone holding the key can use its permissions until it expires or an administrator revokes it.

The third path targets external services. Examples include workloads running on Google Cloud, non-AWS Kubernetes clusters, and CI/CD systems such as GitHub Actions or GitLab CI.

Those services use OIDC federation, which exchanges an identity provider’s signed token for temporary AWS credentials. The temporary credentials generate a short-lived Claude bearer token.

AWS’s example creates a token lasting one hour. The implementation permits configurable lifetimes up to 12 hours, after which the external service must obtain another token.

Together, these three paths form the core of Claude multi-environment access. The subscription stays in one account, while authentication changes according to where the caller runs.

That is the architectural advance. It recognizes that an EKS pod, a developer laptop, and an external pipeline should not share one universal credential pattern.

Claude Platform on AWS Access Moves Control Into IAM

Claude Platform on AWS access now depends less on where code runs and more on whether IAM accurately describes its intended identity and workspace.

AWS introduced the service as a way to use Anthropic’s native platform through an existing AWS account. The company said AWS was the first cloud provider offering that native experience through its own account structure.

The original launch connected authentication, billing, and audit functions to AWS. Customers could use Anthropic’s APIs and tools without establishing a separate commercial relationship.

The multi-environment design extends that proposition beyond a basic API connection. It makes the AWS organization, rather than an individual application, the organizing layer for Claude access.

That matters because enterprise AI usage rarely stays inside one environment. A team might test an application locally, deploy it to EKS, and run evaluations from another cloud.

A shared static key can connect all three locations, but it also collapses their identities. Logs show the key, not necessarily the workload, account, or pipeline that used it.

Cross-account roles retain more context. The workload assumes a named role, receives temporary credentials, and makes signed requests that AWS can attribute to a principal.

The role also creates two authorization checkpoints. The workload account must permit its local identity to assume the target role. The AI Services account must trust that identity and organization.

AWS’s example adds an aws:PrincipalOrgID condition to the trust policy. That condition restricts role assumption to principals associated with the specified AWS organization.

The permission policy then limits inference to the production workspace ARN. Trust answers who can enter the role, while permissions define what that role can do afterward.

This separation places pressure on teams that previously treated model access as secret distribution. They now need to manage Claude AWS authentication as an identity architecture.

Security, platform, and application teams must agree on account ownership. They also need naming standards for roles, workspaces, policies, and environment mappings.

A dedicated account can make those responsibilities visible. However, it does not automatically make them correct.

The architecture also affects incident response. A production role can be disabled without immediately removing developer access. A compromised development key can be revoked without changing an EKS workload role.

Workspace separation can support cost attribution as well. AWS says organizations can tag workspaces and activate those tags for cost allocation.

After activation, which AWS says can take 24 to 48 hours, teams can filter AWS Cost Explorer data by workspace. That creates a path from technical isolation to project-level spending analysis.

Auditability requires another explicit choice. Workspace administration appears in CloudTrail management events by default, but inference belongs to the data-event category.

The monitoring documentation says teams must enable data-event logging to capture inference and other workspace operations. Those events can also create additional CloudTrail charges.

This distinction is easy to miss. Centralizing the subscription improves the potential audit trail, but it does not guarantee that inference activity is being recorded.

The design therefore pressures platform owners to treat observability as part of access control. A policy can limit an action, while logging provides evidence about which principal actually performed it.

The Three Authentication Paths Solve Different Problems

The architecture works because it avoids forcing convenience, workload identity, and external federation into the same credential lifecycle.

For AWS workloads, cross-account SigV4 offers the cleanest alignment with existing cloud identity. The application receives temporary AWS credentials by assuming a role.

It then signs each request to the Claude endpoint. There is no separate Claude API key stored in the workload account, container image, or deployment configuration.

This approach follows established AWS guidance. The company’s IAM best practices recommend temporary role credentials for workloads instead of long-lived access keys.

The production role can include only the actions the application needs. A basic synchronous application might need inference and token-counting permissions but not file, batch, or administrative actions.

Claude Platform on AWS uses the aws-external-anthropic IAM namespace. Its permission model maps API routes to specific actions, such as CreateInference for message requests.

That action can reference one workspace ARN. The application gains access to the production workspace without inheriting account-wide Claude privileges.

This is the strongest of the three paths for continuous AWS workloads. The application does not carry a durable Claude secret, and AWS can attribute requests to an assumed identity.

Developer laptops create a different constraint. Requiring every local experiment to traverse a cross-account role chain can raise setup costs and slow iteration.

AWS therefore uses a workspace-scoped API key for development. The key works with the standard Anthropic client and points to the Claude Platform on AWS regional endpoint.

The important qualification is that a newly generated key is not automatically narrow enough for this pattern. AWS says its backing IAM user initially receives the AnthropicLimitedAccess managed policy.

According to the implementation guide, that managed policy grants access across workspaces. An administrator must detach it and replace it with an inline policy limited to development.

That step is the most consequential manual control in the developer path. Generating the key is easy, while enforcing the intended workspace boundary requires a separate IAM change.

AWS recommends testing the boundary afterward. The developer should call the development workspace successfully, then attempt a production request and confirm that IAM denies it.

This negative test matters more than the successful request. A development response proves connectivity, but only a rejected production call verifies the isolation claim.

The API key remains self-authenticating. It works from AWS, another cloud, or a laptop because possession of the key supplies the credential.

Teams should therefore store it in an approved secret manager and set an expiration. They also need revocation procedures for lost devices, role changes, and accidental repository exposure.

The external workload path removes that persistent secret. OIDC allows a compatible identity provider to issue a JSON Web Token that identifies the workload.

AWS Security Token Service validates the token and checks the role’s trust conditions. It then returns temporary AWS credentials through AssumeRoleWithWebIdentity.

The OIDC guidance recommends this pattern for applications outside AWS because it avoids embedded long-term credentials.

The external workload uses its temporary AWS credentials to request a short-lived Claude bearer token. Once generated, that bearer token can call Claude without retaining the AWS credentials.

This is useful for external containers and CI/CD jobs, but token renewal becomes part of the application. A continuously running service must refresh the token before expiration.

The OIDC trust policy also deserves close attention. AWS’s example checks the token audience and subject claims against expected values.

The audience identifies the intended recipient of the token. The subject distinguishes the permitted workload, service account, repository, or pipeline identity.

Loose claim filters can admit more external identities than intended. A correct federation mechanism with an imprecise trust condition still produces excessive access.

These routes are therefore complementary, not interchangeable.

• Cross-account SigV4 fits production workloads already governed through AWS identities.

• Workspace-scoped API keys reduce friction for local development.

• OIDC federation fits external automation that can present a verifiable workload identity.

The shared element is the workspace. Each credential path should ultimately resolve to permissions for the workspace appropriate to that environment.

Centralization Does Not Remove Credential Risk

The design improves isolation only when every role, key, trust condition, endpoint, and logging setting matches the intended workspace.

The clearest risk sits in the developer path. AWS’s own instructions say a generated API key initially carries a managed policy with access to every workspace.

An administrator must identify the newly created backing IAM user, remove that policy, and attach a narrower inline policy.

That workflow is vulnerable to human error. An administrator might scope the wrong user, retain the managed policy, or reference an incorrect workspace ARN.

The resulting key would still function. Its successful development request would not reveal that it also retained production access.

A mandatory denial test can catch that mistake. Organizations should make the production-access test part of key issuance, not an optional validation performed later.

Long-lived keys also create weaker attribution than role-based access. Several developers sharing one key can appear as the same principal in audit records.

Individual keys improve attribution but expand the number of credentials requiring secure storage, expiration, revocation, and ownership tracking.

The cross-account path has different failure modes. A trust policy can be too broad, or the workload-side assumption permission can reach the wrong target role.

The aws:PrincipalOrgID condition helps restrict organizational scope. However, it does not replace an exact principal ARN or careful role naming.

Permissions also deserve action-level review. Granting wildcard access across the aws-external-anthropic namespace would undercut the guide’s least-privilege structure.

AWS publishes detailed IAM policy examples for single-workspace inference and other controls. Teams should validate their deployed policies against the API features they actually use.

The OIDC route shifts security toward external identity claims. Its safety depends on the issuer, audience, subject filter, role policy, and token-renewal logic working together.

A subject pattern that covers an entire repository group might authorize unrelated pipelines. A broad service-account pattern can admit workloads outside the intended namespace.

Temporary credentials limit exposure duration, but they do not correct excessive permissions during that duration. Short-lived access is safer than permanent access, not automatically least-privileged access.

The generated Claude token also becomes a standalone bearer credential. Until expiration, possession is enough to use it within the inherited authorization boundary.

Applications should avoid printing it to logs, build output, exception traces, or monitoring metadata. Token lifetime should match the job duration where practical.

Regional behavior adds another operational constraint. Workspaces are created in an AWS Region, and API requests must target the corresponding regional endpoint.

AWS distinguishes that endpoint binding from inference geography. The workspace’s security settings independently determine whether inference uses US or global routing.

Short-term keys work only with the same regional endpoint where they were generated. Long-lived API keys are not region-locked, according to AWS’s guide.

This difference can produce confusing failures during deployment. A token renewal process might succeed in one Region while an application points at another endpoint.

The architecture also has a broader boundary that buyers must understand. AWS says Claude Platform on AWS is operated by Anthropic, with requests and data processed outside the AWS security boundary.

That makes the service distinct from an assumption that all processing remains inside an AWS-controlled service perimeter. Organizations with strict residency requirements need a separate review.

AWS positions Claude Platform on AWS as complementary to Claude models available through Amazon Bedrock. The choice is therefore not merely one authentication method against another.

It includes platform features, operational ownership, processing boundaries, and regional requirements. Multi-environment access does not settle those questions for every workload.

Centralization can also increase the blast radius of administrative mistakes. The AI Services account holds the subscription, workspaces, API keys, and access roles.

A change in that account can affect several application accounts at once. The design should therefore apply stronger change controls to this account than to a casual development environment.

Teams should separate policy authoring from approval where possible. Infrastructure as code can also reduce inconsistent role definitions across additional teams and workspaces.

AWS says organizations with more environments can create a workspace for each team or workload and repeat the cross-account role pattern.

That approach scales the isolation model, but it also multiplies policies, role relationships, logs, tags, and endpoint configurations. Operational discipline becomes the limiting factor.

The central promise should therefore be stated carefully. The pattern provides the components for workspace isolation, but deployed policies and credential handling determine whether that isolation holds.

What Enterprises Should Validate Next

The next test is whether organizations can operate this access model consistently, not whether the three authentication flows work in a demonstration.

The first signal is automated policy validation. Teams should confirm that every production role targets one expected workspace ARN and only the required API actions.

Developer key issuance should include policy replacement, expiration, secret storage, and a forced production-denial test. A process that depends on memory will eventually drift.

If organizations automate these checks through deployment pipelines, AWS’s centralized model becomes more credible at scale. Repeated manual exceptions would weaken that conclusion.

The second signal is audit coverage. CloudTrail management events alone do not provide per-call inference visibility.

Organizations should enable data events for the relevant Claude workspace resource type, then verify that records contain useful principal attribution.

They should also test whether incident responders can connect a request to an EKS role, developer key, or external OIDC identity.

If the audit path preserves those distinctions, the three-route architecture supports accountable access. If logs flatten callers into shared identities, centralization offers less investigative value.

The third signal is adoption beyond AWS-native applications. The OIDC path is designed for external clouds, Kubernetes deployments, and CI/CD systems.

Its real test will be reliable token rotation during long-running jobs. Teams must also maintain narrow subject and audience claims as repositories and service accounts change.

Frequent authentication failures would encourage developers to fall back to long-lived secrets. Stable renewal with precise trust conditions would strengthen the federated approach.

Enterprises should also monitor workspace proliferation. Creating one workspace per team or workload can improve isolation, ownership, and cost allocation.

Too many workspaces without consistent labels and lifecycle rules can create another form of sprawl. Old keys, abandoned roles, and unused workspaces need a retirement process.

The dedicated AI Services account should become a governed service boundary. Its administrators need ownership records for every workspace, role, and credential.

Platform teams can record access decisions alongside application architecture and incident procedures. A searchable engineering knowledge base can help preserve those mappings as teams change.

The most useful evaluation starts with one complete application path. Connect a production workload through SigV4, a development client through a restricted key, and a pipeline through OIDC.

Then verify denied cross-workspace requests, token renewal, CloudTrail data events, and emergency revocation. Do those controls still hold after routine policy changes?

That answer matters more than the successful first request. Claude Platform on AWS access now supports three environments under one subscription, but its security value depends on repeatable proof of isolation.