AWS Adds Local Claude Inference in India, Seoul and Singapore

AWS opened three new Claude processing routes in Asia

AWS announced on September 29, 2026 that Amazon Bedrock now supports Claude Opus 5 and Claude Sonnet 5 with in-region inference in Seoul (ap-northeast-2), and Claude Sonnet 5 with in-region inference in Singapore (ap-southeast-1). A separate same-day announcement added Claude Opus 5, Claude Sonnet 5 and Claude Haiku 4.5 through geographic inference inside India.

These are availability and routing updates, not new Anthropic model launches. Their practical value is narrower and important: teams that could not accept global cross-Region routing now have Claude processing routes constrained to one AWS Region in South Korea or Singapore, or to two AWS Regions inside India.

Seoul and Singapore keep each request in one Region

AWS says the Seoul (ap-northeast-2) and Singapore (ap-southeast-1) routes use the bedrock-runtime endpoint without a cross-Region routing layer. Input prompts and outputs remain in the Region called for the full request lifecycle. Claude Opus 5 and Sonnet 5 are available this way in Seoul; the announcement names Sonnet 5, but not Opus 5, for Singapore.

The trade-off is capacity concentration. Requests are bounded by the selected Region’s capacity and quotas. Billing, quota consumption, CloudWatch metrics and CloudTrail records are scoped to that Region. AWS recommends the bedrock-runtime endpoint for new applications and documents InvokeModel, Converse and Anthropic Messages API access.

India keeps inference in-country, not in one Region

India uses a geographic cross-Region inference profile. A request originates in Mumbai (ap-south-1) or Hyderabad (ap-south-2) and may be served by either Region. AWS says prompts and outputs can move between those two Regions but do not route outside India. The broader capacity pool is the reason to choose this path; it is not equivalent to pinning processing to Mumbai or Hyderabad alone.

AWS says customer data is not stored in a destination Region during cross-Region inference and describes Bedrock as zero data retention by default. The launch post also qualifies that statement: certain models can require AWS human review when automated safety classifiers flag content. Buyers should map that exception, log destinations and contractual language to their own data classes rather than turning “in-country” into an unqualified compliance claim.

Direct IDs and India profile IDs are not interchangeable

For Seoul and Singapore, AWS examples invoke direct IDs: anthropic.claude-opus-5 and anthropic.claude-sonnet-5. The examples target bedrock-runtime in ap-northeast-2 or ap-southeast-1. For India, the examples use the geographic profile IDs in.anthropic.claude-opus-5 and in.anthropic.claude-sonnet-5 from ap-south-1; AWS also names Claude Haiku 4.5 as available through the India profile.

That prefix encodes a routing decision. Migration tests should verify the exact ID, source Region, IAM permission for inference profiles, SDK path, streaming behavior, quotas and failure handling. A configuration copied from Global CRIS or a direct endpoint should not be assumed to preserve the intended boundary.

Pricing is regional but the launch posts do not quote rates

The Seoul-and-Singapore post says billing follows standard on-demand pricing for the Region called. The India post says billing and quota consumption are tracked against the source Region even when the other Indian Region handles inference. Neither announcement publishes a numeric input-token, output-token or cache rate.

AWS’s live Bedrock pricing page is model- and Region-dependent, so this briefing does not manufacture a single price. Before launch, capture the displayed rate for the exact model, account, source Region and route; include cache, guardrail, provisioned-capacity and surrounding service costs where applicable. Recheck the quote at approval time because public pricing and availability can change.

What builders and buyers should do next

Use Seoul or Singapore when the requirement is a named single-Region processing boundary and the required model is listed there. Use the India profile when in-country processing plus capacity across Mumbai and Hyderabad is acceptable. Keep Global CRIS only when wider routing is allowed and its capacity benefits justify the broader boundary.

Pilot with non-sensitive traffic first. Record the resolved model ID, source Region, permitted destination set, account-visible price, quota, retention terms, human-review exception, logs and fallback behavior. Wait if the workload requires Opus 5 in Singapore, one-Region processing in India, an undisclosed numeric rate, or contractual evidence stronger than a public launch post. Reject any design that silently falls back to a broader profile when the approved residency route is unavailable.

Disclosures

AccessAllGPT did not receive AWS or Anthropic credentials, credits, early access, a briefing, pricing, data, review or compensation for this article. Amazon Web Services and Anthropic did not sponsor, review or endorse it. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with AWS, Anthropic or organizations cited. Publication-wide relationships are listed on the disclosures page.