Keep Claude Code and/or Codex in your workflow WITH Amazon Bedrock
Already building on AWS? See how Amazon Bedrock lets you run Claude Code, OpenAI Codex, and model-backed applications through the same identity, logging, and governance controls you operate today. Grounded in published customer examples, it covers the supported integration paths, what to verify before you commit, a scoped cost illustration, and a pilot framework for proving fit before you scale.
A team can be enthusiastic about an AI coding tool and still have unanswered questions about how to operate it across the business. Who can access which models? Where does inference run? How is usage attributed? Which records are available when something goes wrong?
For teams already building on AWS, Amazon Bedrock deserves a closer look because it offers a way to connect familiar tools to AWS authentication and model access. Claude Code supports Bedrock, and AWS announced general availability of OpenAI models and Codex on Bedrock on June 1, 2026. These are supported integration paths, rather than a requirement to build a new coding assistant. [1][2]
The case for choosing this path should rest on your operating requirements and measured results. A familiar billing account alone does not prove lower cost, and access to a model does not mean every tool feature or Bedrock service is available with it.
Start with the reasons customers give
Published customer stories make this argument more concrete.
LEGIC describes introducing Claude Code through Bedrock for approximately 50 developers, building on its existing AWS identity and governance environment. Its subsequent company-wide AI platform used Bedrock as well. The useful lesson is that an established AWS operating model can provide a starting point for wider adoption. [3]
AWS’s GoDaddy story describes an internal platform, GoCode, that gives 2,000 developers access to Claude Code through a controlled API proxy and Bedrock. GoDaddy reports that some projects previously taking a two-week sprint were completed in under a week. That is a reported outcome of GoDaddy’s deployment, not evidence that changing the inference provider alone halves delivery time. [4]
Thomson Reuters offers a production application example. Its published story describes choosing Claude through Bedrock partly because that approach fitted existing AWS operational practices and governance. The story also describes expert and automated evaluation. It supports the operating-model argument, rather than a claim about Claude Code adoption. [5]
These examples give builders a practical question to investigate: can the tools people already value work within the controls the organisation already operates?
Claude Code through Bedrock
Anthropic documents a Bedrock integration for Claude Code, including AWS authentication and model configuration. Teams can use that supported path while retaining Claude Code as their coding interface. [1]
The setup still needs deliberate choices. Confirm the model and Region, check permissions, and pin the model where repeatability matters. Feature parity also needs checking: Anthropic’s documentation currently lists the Claude Code web search tool as unavailable through Bedrock. That limitation applies to this integration; it is not a statement about every model or search capability on Bedrock. [1]
A useful pilot therefore tests the actual developer workflow: repository access, tool calls, edits, tests, authentication renewal and failure recovery. Being able to send a prompt is only the first check.
Codex and OpenAI SDK integrations
Codex is also part of this discussion. OpenAI documents Bedrock support for local Codex clients, including the CLI and IDE integration. Its guidance distinguishes the Bedrock Runtime provider from the Mantle provider, and requires the model identifier and provider configuration to match. Hosted Codex Cloud is outside the support described in that guidance. [6]
For application builders, OpenAI also documents Bedrock integrations in its SDKs. Authentication options and dependencies vary by SDK, so use the instructions for the language and version you actually deploy. An application migration should check API behaviour, tool calling, response handling and errors, as well as credentials. [7]
This creates two useful entry points: a supported coding client for developers and a documented SDK path for applications. Neither removes the need to verify the exact model, endpoint and features your workload requires.
What Bedrock can bring to the operating model
AWS identity is one reason to consider Bedrock. Its IAM documentation describes permissions for accessing the service and its resources. For a team already administering AWS access, the opportunity is to incorporate model access into that existing process. Whether this reduces administrative work is something to measure in the pilot. [8]
Visibility requires configuration, too. Bedrock model invocation logging is disabled by default. The documented logging facility supports the Runtime endpoint and can send invocation information to CloudWatch Logs or Amazon S3; it does not capture Mantle invocations. API audit records and full model input/output records should therefore be treated as distinct requirements. [9][10]
Data handling also needs precise language. AWS documents retention modes and model-specific requirements. Do not turn an older customer story’s description into a universal promise of zero retention. Check the current rules for the chosen model and API, including any response-storage behaviour. [11]
Bedrock Guardrails can add configured checks to supported requests, but support depends on the integration. For example, the GPT-6.1-Sol model card lists Guardrails support for several Runtime APIs, while excluding Responses and Mantle. A control mentioned on a service page is not necessarily available on every route to a model. [12][13]
Before selecting a path, capture the decisions explicitly:
| Requirement | Decision to verify |
|---|---|
| Access | Which AWS identities can invoke the selected model? |
| Geography | Which Region or inference profile satisfies the workload’s location requirements? |
| Records | Which endpoint supports the required audit and invocation records? |
| Data handling | What retention and response-storage rules apply? |
| Controls | Does the exact model and API support the required Guardrails integration? |
| Workflow | Does the coding client or SDK support the features the team needs? |
Geographic and global cross-Region inference have different routing boundaries. Treat that choice as an architectural requirement before comparing prices. [14]
Compare costs using an actual workload
Bedrock should not be presented as automatically cheaper. A useful comparison measures the cost of accepted work: a reviewed code change, a resolved support request or a successful application transaction. Token prices provide one input to that calculation.
For an illustration, the GPT-6.1-Sol model card lists the following standard commercial prices for short-context requests. Assume a workload totals 10 million uncached input tokens and 2 million output tokens, with each request within the card’s 272,000-input-token threshold. [13]
| Inference option | Input per million tokens | Output per million tokens | Illustrative inference cost |
|---|---|---|---|
| Global cross-Region inference | $2.00 | $10.00 | $40.00 |
| US geographic cross-Region inference | $2.20 | $11.00 | $44.00 |
The arithmetic is simply input volume multiplied by input price, plus output volume multiplied by output price. This is a pricing illustration, not an observed customer result or a monthly Codex budget. It excludes other infrastructure and operational costs. The lower-priced route is useful only if its routing boundary satisfies the workload’s requirements.
For a real pilot, record retries, unsuccessful attempts, review time and supporting infrastructure costs. Compare the same tasks and model configuration where possible. If you change both the model and the inference route, you cannot confidently attribute the resulting difference to Bedrock alone.
Prove the fit before expanding
Start with a representative repository or application and a small set of tasks that have clear acceptance criteria. For coding work, those criteria might include passing tests, a successful build and reviewer acceptance. These are proposed pilot criteria, not a claim that a model’s output is reliable merely because it runs through Bedrock.
Then answer four questions:
- Does the workflow work? Verify authentication, model selection, tool use and recovery from expected errors.
- Do the required controls work? Check permissions, geography, records, retention settings and supported Guardrails behaviour on the actual endpoint.
- What does accepted work cost? Include unsuccessful attempts and review effort alongside inference charges.
- Can the team operate it? Assign owners for access, budgets, configuration changes and incident handling, and keep a way to revert the pilot configuration.
Expand when the evidence supports expansion. Keep the criteria and measurements so a later model or configuration change can be assessed against the same workload.
For an organisation already invested in AWS, Bedrock can be a practical way to operate Claude Code, Codex and model-backed applications within its existing environment. The strongest reason to choose it is a demonstrated fit between the workflow people need, the controls the organisation requires and the economics of the work being delivered.
Sources
- Anthropic: Claude Code on Amazon Bedrock
- AWS: OpenAI models and Codex on Amazon Bedrock are now generally available
- AWS: From Claude Code to company-wide AI, how LEGIC built on Amazon Bedrock
- AWS: GoDaddy customer story
- Anthropic: Thomson Reuters customer story
- OpenAI: Amazon Bedrock setup
- OpenAI: Amazon Bedrock SDK guide
- AWS: Identity and access management for Amazon Bedrock
- AWS: Model invocation logging
- AWS: Logging Amazon Bedrock API calls using CloudTrail
- AWS: Data retention
- AWS: Amazon Bedrock Guardrails
- AWS: GPT-6.1-Sol model card
- AWS: Cross-Region inference
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article