Build1 publisher2 min readPublished
Bedrock's India profile keeps Claude inference inside Mumbai and Hyderabad
Amazon Bedrock now runs Claude Opus 5, Sonnet 5 and Haiku 4.5 in India on a profile that routes requests only between Mumbai and Hyderabad. Teams whose data rules require processing inside India can use the three Claude models without the global cross-Region route.
The Engineer · Build desk
What happened
- A caller picks an inference profile in its source Region, and Bedrock routes each request to one of the destination Regions that profile lists, with no per-Region capacity to manage.
- Billing, quota, CloudWatch logs and CloudTrail entries are all recorded against the source Region, whichever Region actually ran the model.
- AWS says certain models require human review by AWS as a condition when automatic safety classifiers flag content.
- The India profile works on the bedrock-runtime endpoint with Anthropic's Messages API, InvokeModel, Converse, Guardrails and intelligent prompt routing.
- It is offered alongside the global cross-Region inference that customers in India could already use for these models.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A residency rule written for India as a whole fits this profile, but a rule that pins data to Mumbai alone does not fit, because a Mumbai call can be processed in Hyderabad.
- exposure A residency case built on zero data retention has to cover the human-review path, because flagged content from some models goes to AWS reviewers.
- capability A team calling from one source Region reads one CloudTrail and one bill for its India workload, even though two Regions serve it.
Bedrock picks the Region that runs the model. A request sent with the India profile ID can be served in either ap-south-1 or ap-south-2 [5], and prompts and outputs may move between the two while it is processed [6]. AWS says customer data is not stored in the destination Region, stays in the source Region, and travels over the AWS network encrypted in transit [8]. Bedrock also stores no model inputs or outputs by default [9].
AWS gives capacity as its reason for pooling two Regions. According to the post, requests draw on a broader pool of compute than one Region offers, and that keeps throughput steady during traffic peaks [7]. That claim holds for a given workload only if Mumbai and Hyderabad have spare capacity at the hour the workload peaks. A two-Region pool serving one country has less room to absorb a shared peak than a wider pool. I would load-test at the busiest hour before building capacity plans on it.
The post does not say which models carry the human-review condition or where that review is performed [10]. A data protection officer will want both answers from AWS in writing before approving the profile for regulated data.
Most of the adoption work is changing one identifier. In the console the choice is a profile labelled "IN Anthropic Claude Opus 5" [14]. In code it is the India profile ID passed to the same bedrock-runtime calls [13]. The Anthropic SDK path needs Python 3.8 or later, boto3, the anthropic package and aws_bedrock_token_generator for inference authentication [15]. With the global profile still on offer, residency ends up depending on which string a developer copies into a config file [3].
The post lists IAM permissions for geographic cross-Region inference among its prerequisites [16]. I would put the control there. Roles that touch regulated data would be granted the India profile and nothing else. A client configured for the global profile would then be refused at the permission check.
What to watch
- AWS naming which Bedrock models carry the human-review condition and where flagged content is reviewed.
- Any single-Region option for Claude Opus 5, Sonnet 5 or Haiku 4.5 in Mumbai or Hyderabad alone.
- Throughput reports from Indian teams at peak hours on the two-Region pool.