AWS posts Claude Code deployment playbook for GovCloud, from FedRAMP to token budgets

AWS on Monday published deployment guidance for running Anthropic's Claude Code on Amazon Bedrock inside the AWS GovCloud (US) Regions, the cloud most U.S. federal and defense-adjacent teams are cleared to touch. The guide, posted to the AWS Machine Learning Blog, walks through the compliance posture, the two endpoint flavors, and the cost controls teams will want before handing agents to hundreds of developers.

The compliance stack

The headline numbers: Claude Opus 5.5 and Claude Sonnet 5.5 hold FedRAMP Class D (formerly High) certification on Bedrock, according to AWS, while Claude Sonnet 5 holds FedRAMP Class D plus DoD Impact Level 4 and 5 authorization. Bedrock in GovCloud offers FedRAMP Class D and IL4/IL5 authorization pathways, and AWS's data protection rules mean customer content is not stored, logged, used to train AWS models, or shared with third parties.

Opus 5.5 arrived on GovCloud on September 22, with Sonnet 5.5 following on September 28, according to AWS's own timeline. Under ITAR and similar regimes, the question is never just "which model" but "where does inference happen and who can see it," and the guide answers both before anything else.

Two endpoints, three setup paths

GovCloud Bedrock exposes two surfaces, both running on the same Mantle inference engine with a Zero Operator Access architecture. The bedrock-runtime endpoint speaks the AWS SDK through InvokeModel and Converse, supports Bedrock Guardrails, Knowledge Bases, Agents, and invocation logging, and is the one AWS recommends when audit trails and content filtering matter. It is available in both GovCloud regions. The bedrock-mantle endpoint speaks the Anthropic Messages API natively and unlocks server-side tools, background inference, and Projects, but it is available only in US-West, and Guardrails plus invocation logging do not exist on it.

Setup comes in three flavors: an interactive login wizard (re-openable with /setup-bedrock), environment variables (CLAUDE_CODE_USE_BEDROCK=1, region set to us-gov-west-1, model pinned to a us-gov. prefixed ID like us-gov.anthropic.claude-sonnet-5-5), or Mantle routing with CLAUDE_CODE_USE_MANTLE=1, which can be combined with the Bedrock flags. Running /status verifies the setup; the provider line reads Amazon Bedrock or Amazon Bedrock (Mantle).

The money part: pin your models

The guide spends real estate on cost governance, which is where enterprise Claude Code rollouts usually get messy. AWS's advice is blunt: pin model versions, because unpinned sonnet and opus aliases resolve to Claude Code's built-in defaults, which can change between releases. The default primary model is Opus 5.5, and an unpinned deployment bills at the Opus per-token rate.

AWS suggests defaulting teams to Sonnet 5.5 and reserving Opus 5.5 for deeper reasoning or long autonomous runs, while workloads needing IL4/IL5 authorization should default to Sonnet 5, which the post describes as carrying the strongest compliance coverage. For spend control, the guide points to per-user token guardrails with alerts at 80% and 100% of daily limits, built from CloudWatch invocation logging, Lambda, and DynamoDB, plus prompt caching with five-minute and one-hour TTLs on supported models.

Agents on the agency desktop

One caveat runs through the whole document: Claude Code itself runs on the developer's machine even when inference is walled inside GovCloud, and AWS is explicit that a secure inference layer does not end the conversation. Teams should evaluate the agent software itself, apply managed permissions and invocation logging, and treat it like any other third-party tooling with shell access. The cloud can be compliant; the laptop still has to be managed.