I haven't run Bedrock in production. It's in this catalog because four other entries send you here, and because it's my answer to a question Australian clients ask more and more: can we use Claude without our data leaving the country?
Through Anthropic's own API, no: it processes requests in the US or globally. Through Bedrock, yes. Its Australian inference profile keeps each request in Sydney or Melbourne from the moment it arrives to the moment the answer leaves, and Melbourne can also serve a single Region. For a client already on AWS, it fits everything they have: IAM signs the calls, CloudTrail records them, the bill arrives on the AWS invoice, and there's no new vendor for procurement to approve. Australian routing costs 10% more than global.
How the options compare for keeping AI data in Australia, in October 2026:
| Option | Data stays in Australia? | Fits when |
|---|---|---|
| Amazon Bedrock, AU profile | Yes, Sydney and Melbourne, for the Claude models with an Australian route | The client is on AWS. My pick |
| Anthropic API | No: US or global only | Residency doesn't matter |
| OpenRouter | No: global routing (in-region only for the EU and the US) | Residency doesn't matter |
| Google Vertex AI (Gemini) | Processed in the Region you call, Sydney included; check the model | The client is on Google Cloud |
| Azure OpenAI, Australia East | Processed in Sydney under a regional deployment | The client is all-in on Microsoft (my verdict on Azure is Never) |
| OpenAI API data residency | Stored in Australia; in-country processing unconfirmed | Ask OpenAI before promising it |
| Open models on your own GPUs in Sydney | Yes, entirely in the client's account | Strict isolation, at a far higher running cost |
Two things to know before you promise residency. Bedrock doesn't offer everything Anthropic's API does: no batches, no Files API, no server-side web search or code execution, no Managed Agents, so a feature built on those needs rework. And residency is per model: today, Fable 5.1's regional endpoint exists only in the US, so it can't be kept in Australia at all. Check the model, pin it, and verify the routing yourself.
When a client project puts Bedrock into production, this entry gets a real verdict.
Use it when
- Claude, and the data must stay in Australia: the AU inference profile processes every request in Sydney or Melbourne, for its whole life.
- The client is on AWS: calls signed with IAM roles, logged in CloudTrail and CloudWatch, billed on the AWS invoice, no new vendor to approve.
- Code that must not leave AWS or Australia: Claude Code runs against Bedrock with AWS credentials.
Don't use it when
- You need Anthropic's server-side features: no Batch API, Files API, web search, code execution, MCP connector, Agent Skills or Managed Agents on Bedrock.
- Residency doesn't matter and you want to switch models freely: OpenRouter, one key for every vendor.
- The model you need can't stay in Australia. Fable 5.1's regional endpoint is US-only today.
Pricing
Claude at Anthropic's list prices on the global endpoint. Regional endpoints and the AU inference profile, which keep requests in Australia, cost 10% more. Other models at their own Bedrock prices.
Gotchas, with fixes
Gotcha: The default and the global endpoint route anywhere in the world. Australian residency only happens if you ask for it.
Fix: Call from ap-southeast-2 or ap-southeast-4 with the au. inference profile (or Melbourne's in-region endpoint), and block the other Regions with a service control policy.
Gotcha: AWS warns that a profile's geographic prefix alone doesn't prove where requests go, and destinations can differ by source Region.
Fix: Run get-inference-profile from every source Region you use, and keep the list of destination Regions as evidence for the client's compliance file.
Gotcha: Not every Claude model has an Australian route, and new models often reach the US first.
Fix: Check the model's Regional availability before you promise residency, and pin the model ID: don't let "latest" move you to a model that routes overseas.
Gotcha: Prompts and outputs can be stored in opt-in Regions for abuse detection when a profile routes there.
Fix: Use the AU profile, whose destinations are only Sydney and Melbourne, and check Bedrock's data-protection terms against the client's obligations.
Provisioning
Official Pulumi package · Official Terraform provider
@pulumi/aws and the AWS Terraform provider cover IAM, guardrails, application inference profiles (for cost tags per client or feature) and Knowledge Bases. Model access is enabled per account in the console.
Instead, consider
- Anthropic API (for client systems) Residency doesn't matter and you need the server-side features. Anthropic's own API offers only US or global processing.
- OpenRouter Any model from any vendor on one key, when the data may leave Australia.
- Claude Code Developers on a client codebase that must stay in AWS: point Claude Code at Bedrock.
Worked examples
Where it fits
- An AI chat or LLM feature: Pick 05.
Instead of OpenRouter when the data must stay in Australia. Claude through the AU inference profile.
Sources
- Anthropic: Claude in Amazon Bedrock (models, Regions, feature gaps)
- AWS: supported Regions and models for inference profiles
- AWS: cross-Region inference for Claude in Japan and Australia
- Google Cloud: Vertex AI data residency
- OpenAI: data residency
Last reviewed by Nicolas Dao