Running Claude Code on Amazon Bedrock

Key Takeaways

Developers everywhere are talking about how AI coding tools like Claude Code by Anthropic have changed their day-to-day and they're shipping more than ever. But some devs can't use these tools due to data residency, billing, or compliance issues. Well, now you can run Claude Code and have it use models hosted entirely within AWS through Amazon Bedrock. That means you can use Claude Code and still meet your security, compliance, and cost governance requirements. One of the main benefits is that you get the full Claude Code experience and your data never leaves AWS infrastructure. In this video, I'm going to give you a complete walk-through of running Claude Code on Amazon Bedrock. I'll cover what Claude Code is, why you'd want to run it on Bedrock, environment setup, cross-region inference, and prompt caching. Then we'll cover some helpful things for teams running Claude Code on Bedrock, including granular cost tracking, Amazon Bedrock Guardrails for content filtering, and the new Amazon Bedrock Mantle endpoint. Let's get into it. If you haven't used Claude Code yet, it's an agentic coding tool that reads your code base, creates and edits files, runs commands, and integrates with your external tools through MCP and the command line. There are basic use cases like creating new features for your app or fixing bugs, but it goes way beyond that. You can create custom skills to define repeatable workflows specific to your team, like how you build applications, write tests, or handle migrations. You can also spin up sub-agents and teams of agents that work on different parts of a problem in parallel. It's common to even use multiple Claude Code instances to coordinate across different parts of your project. So, why should you run it on Amazon Bedrock? There are a few compelling reasons. First, and this is the big one for enterprise teams, is that your data never leaves AWS. AWS doesn't train models on your data, your code, or your prompts, and it also doesn't share that information with the model providers. When you run through Bedrock, any telemetry data that would usually be sent to Anthropic is turned off by default, including feedback data. This is exactly what you need if you have strict data residency requirements. Second, you get familiar infrastructure and the security and compliance tooling that comes with Bedrock. You can use IAM credentials, Amazon CloudWatch, AWS CloudTrail for logging, and Bedrock Guardrails for content filtering or PII redaction. If your organization already runs on AWS, this fits right into the systems you're used to. Third, usage gets charged to your existing AWS billing. You don't need a separate vendor contract to use it. Later in this video, we'll cover how to access per team or per user cost breakdowns, and how to use cost allocation tags so you can get granular insights into spending. All right, let me show you how this actually works. To get Claude Code talking to Bedrock, you first need a few things. Claude Code and the AWS command line interface installed, an AWS account, and IAM permissions to invoke Bedrock models. Before starting up Claude Code, you need to configure the settings that tell Claude Code to route through Bedrock instead of Anthropic's API. You can do this by running Claude and then typing /config to open the settings file, or you can edit the settings file directly at .claude/settings.json. We'll be editing this file directly. Add these values to your settings. The first variable, Claude code use bedrock equals one, is the switch that tells Claude code to point to bedrock. And AWS region tells it which region to send requests to. These are the two bare minimum settings you need to run on bedrock. Then I also have a few model variables set up, which allow you to pin specific versions, so you can control exactly what models you're using. If you're wondering how to find valid model IDs for bedrock, you can run the command AWS bedrock list foundation models by provider Anthropic. This returns a list of foundation models you could reference in your settings. Now, because this information lives in your settings.json file, the configurations you choose will persist across terminal sessions automatically. Every time you open a terminal and type Claude, it connects to bedrock, and it will use whatever local AWS credentials you already have configured to make the secure connection to bedrock. It follows the standard AWS SDK credential chain. If you've already got credentials working for the AWS command line, Claude code will just pick them up. If you're using IAM Identity Center, then you just log in with your profile first. Using single sign-on with IAM Identity Center is a very common way to authenticate with AWS these days, and it uses temporary credentials. This means that the creds do expire at some point, usually after an hour or so. But if you're in the middle of a coding session and your token expires, it doesn't mean you just get kicked out. Claude code can handle getting new credentials automatically. To set this up, you need to add this JSON snippet to your settings. It defines the AWS auth refresh settings so that Claude code can get new credentials when they go stale. It refreshes in the background and keeps everything going. The settings you define can apply to different scopes depending on where the configuration lives. There are three that matter for most developers. The user scope is your personal settings file in your home directory under .cloud/settings.json. Whatever you put here applies to you across all projects on your machine. This is where your bedrock environment variables and model preferences go by default. The project scope lives in your repository at that same location. This gets committed to get, so anything you put here applies to all collaborators on the project. And local scope is at .cloud/settings.local.json in the same repo, but it's automatically get ignored. So, it only applies to you in that specific project. You would use that for personal overrides. When the same settings exist in multiple scopes, the higher scopes win. So, if your entire team is working with Cloud Code, you use project scope to standardize model versions and regions across collaborators, and you commit that file to get, so your team shares the same settings. Then for developers who want different configurations, they use local scope. Now, let's launch Cloud Code by running the command cloud. You should see the welcome screen showing up that shows Amazon Bedrock as the provider. Now, before we build anything, let's add the Agent Toolkit for AWS plugin. This gives Cloud Code access to tools and best practices, so it can build applications on AWS more effectively. To install it, we can run /plugin marketplace add AWS Agent Toolkit and hit enter. And then we want to run /reload plugins and hit enter, and now our plugins are ready to use. And now we can ask Cloud to do something for us, like create a serverless URL shortener and deploy it to AWS using the CDK and Python. Then we can hit enter and off it goes. It will run the agent loop, building this, asking for permissions as it needs them, and all of the inference will run against Bedrock in the background. Now, one of the common issues for heavy cloud code users is throttling, which is when you get errors due to capacity limitations or hitting rate limits on the API. Cross-region inference provided by Bedrock can help mitigate this. When using cross-region inference, Bedrock automatically routes your requests to regions that have available capacity. You don't need to build any client-side of load balancing to make it happen, and the pricing stays the same. You just get more throughput. It's set up through the model ID you supply in your settings file. You supply an ID for a cross-region inference profile, and Bedrock handles the rest. If you supply a model ID that points to a single region like this, with no prefix for cross-region inference, you're locked into one region, and that means you're capped at that region's throughput. In-region model IDs are best used for when you need to route to the closest region for latency-sensitive workloads or when you need deterministic routing. To use cross-region inference profiles, you instead want to provide a model ID for geo-cross-region routing. Geo-cross-region inference profiles have a prefix like US, EU, or APAC. Your requests can route anywhere within that geography. So, with the US prefix, your traffic stays within US regions, but can move between them when one gets busy. For most teams, this is the default that I would recommend. Then there's global cross-region inference profiles, which use the global prefix. With this, your requests can route to any supported region worldwide for that model, which will give you the maximum available throughput. If you followed the setup I just showed you, then you're already using geo-cross-region inference, as the model ID starts with a US prefix. Everything I've shown you so far uses the standard Bedrock runtime endpoint. That works, but there's a newer endpoint called Amazon Bedrock mantle that AWS recommends going forward, and there are a few reasons why. Mantle serves models through their native API shapes like the Anthropic messages API with better throughput handling, separate input and output token quotas, and performance tiers. All backed by the same Bedrock infrastructure and enterprise controls. So, you still get all of the benefits and features that we just covered. Mantle is also designed with something called zero operator access. And what that means is that even AWS as the operator running Bedrock can't access your inference data. The system is architected so that there is no backdoor, admin override, or support engineer who can pull up your prompts. The technical path simply just doesn't exist. So, when you're sending code through Claude to Bedrock, that conversation lives entirely in your AWS account. Mantle also uses an advanced scheduling and work queuing architecture instead of hard per account throttling. That way, when capacity is tight, your requests get briefly queued instead of rejected. For heavy Claude code users, that means fewer errors. Then for quotas, standard Bedrock gives you a combined pool of tokens where output tokens burn down at a higher ratio. Mantle separates it into different pools for input and output tokens. For agentic workloads where you're feeding in large code bases and generating a lot of code back, that separation works in your favor because generating a ton of code doesn't eat in your quota for sending context, and sending a large code base doesn't eat in your quota for generating code. To switch Claude code to the mantle endpoint, it's just in your settings file. For the environment variable, you would use Claude Code Use Mantle and set the value to one. And then Claude Code routes through the Mantle endpoint. Now, you should also know that model IDs on Mantle look different. They're prefixed with Anthropic. There is no region prefix. Once you launch Claude Code with these settings, you can run status and the provider line shows Amazon Bedrock Mantle. So, you know you're connected to the right endpoint. Now, time for my favorite feature, prompt caching, which is on by default. You don't configure anything for it. As you go back and forth with Claude Code, the shared context between your messages gets cached, so it doesn't have to be reprocessed on every turn. That means up to 90% lower cost and up to 85% lower latency as your session goes on. But, you should know that the default cache window is 5 minutes. So, if you're firing off prompts back-to-back, you're getting the full benefit. But, if you step away, check Slack, review PR, grab a coffee, 5 minutes can go by pretty fast, and then your cache expires. There's a setting you can add to extend that to 1 hour. In your settings file, add this snippet to the environment block. And with that in place, it extends your cache to a full hour. The trade-off is slightly higher write cost per cache token, but if you're actively working and context switching through a session, it pays for itself because you're not recaching the same information every time you come back to your session. This 1-hour extension does require the Mantle endpoint at the time of filling, but these things do move fast. So, some of what's missing today may not be missing by the time that you watch this. So, just check on the docs to see where things are at. Now that you know the basics for getting Claude Code running on Bedrock, let's talk about running this for entire engineering teams. If you're part of a dev team using Claude code on Bedrock, it won't be long before you get this question. How much are we spending and who's spending it? Without granular attribution, you get one bill with one total number. You can't tell if a spike in usage was one developer experimenting with Opus or the whole team running Sonic with an upcoming deadline. And if you've got a data science team and a platform team both hitting Bedrock in the same AWS account, their spend is just mixed together. Granular cost attribution solves this. Bedrock automatically records which IAM principle, like which user or role, made every inference call. When you're analyzing spend, you can filter per project, developer, or per model. This sort of IAM principle-based cost allocation can also be connected to team structure by tagging your IAM roles with metadata like team name and cost center. Once the tags are in place and activated for cost allocation tracking, they show up as filterable columns in your billing data through Cost Explorer. You can also access the most granular data through cost and usage reports, which give you line item detail for every Bedrock inference request. Each API call generates separate line items for input tokens, output tokens, cache read tokens, and cache write tokens. For even more control, you can create application inference profiles. Instead of everyone on your team calling the same model ID directly, you create a named profile that points to that model, and you attach cost allocation tags to it. Then each team uses their specific profile ARN as their model ID. When they use Claude code, every token consumed through that profile automatically gets attributed to whatever tags you set on it. Here's what creating one looks like in Python. We can give this a run and it outputs the ARN for the app inference profile. You then take that ARN and drop it into the team's settings file as their model. This way the tracking is structural instead of behavioral. Another common need for teams using Cloud Code is guardrails around what goes into the model and what comes out of the model. For example, maybe you want to make sure personally identifiable information doesn't leak into generated code or prevent inappropriate content from surfacing in exchanges or code suggestions. Amazon Bedrock Guardrails gives every developer on a team a consistent and safe experience regardless of what project each person is working on. With Amazon Bedrock Guardrails, you define content filtering policies for things like blocking restricted categories, redacting sensitive data, or enforcing topic boundaries. The setup is three steps. First, create a guardrail in Amazon Bedrock. Second, publish a version of the guardrail. And third, add the guardrail headers to your settings file. There are two headers in one environment variable. One header for the identifier and the other for the version of the guardrail. One thing to watch for, if you're using cross-region inference profiles, then you need to enable cross-region inference for your guardrail, too. Otherwise, it won't apply those requests that get routed to other regions. This is something that's easy to miss and you'll wonder why your policies aren't firing. You can include this in a shared settings file and then every developer gets the same content governance automatically. You should be aware though that guardrails do have their own pricing model. I'll put a link in the description so you can learn more about that. That said, you can start simple. You probably only need PII redaction and maybe some denied topics. You can always tighten and tune policies later. That's Cloud Code on Amazon Bedrock. Your data stays in your AWS account. You get cross-region inference for throughput, prompt caching for cost and speed, cost attribution for visibility, guardrails for content governance, and mantle when you need native API compatibility. And it all runs through the AWS credentials you already have. Something to note though is that with any enterprise deployment path, there are tradeoffs. You gain compliance, IAM, and billing controls, and you trade a handful of advanced features that are still actively making their way to Bedrock. Switching to the mantle endpoint closes some of those gaps, but not all of them at the time of filming. If you want to get started right now, all you need to do is add those first two environment variables that I showed you. Links to everything you need are in the description, including a lightweight repo where you can find the commands and code I ran today, hands-on workshops, and Claude on AWS resources. Thanks for watching, and if you have any questions, drop [music] them in the comments below, and I'll see you in the next one.