Amazon Bedrock adds India-only inference for Kimi K3

Amazon Web Services (AWS) said on 3 November 2026 that Amazon Bedrock now supports in-country inference in India for Kimi K3, an open-weight multimodal model from Moonshot AI. The post, by AWS staff, says this is aimed at workloads with strict data-residency requirements. It is a vendor-published announcement with one customer quote and a sample project.

How the routing works

According to AWS, Kimi K3 on Bedrock is served through cross-Region inference profiles. You call the model from a source Region, and Bedrock processes the request in one of several destination Regions. The profile ID you call decides which destinations are allowed.

• Global profile, global.moonshotai.kimi-k3: AWS recommends it for most use cases as the lowest-cost and most broadly available option.
• India profile, in.moonshotai.kimi-k3: inference stays within the Mumbai and Hyderabad Regions.
• AWS says traffic between Regions is encrypted in transit and stays on the AWS network.

The post's example calls the India profile from the Mumbai (ap-south-1) source Region through Bedrock's OpenAI-compatible Chat Completions API. AWS lists three other ways in: the Responses API, Converse and InvokeModel. It says streaming, tool calling and structured outputs work through the OpenAI-compatible APIs, and that JSON Schema output is supported for firm output constraints.

What a residency review should check

AWS says Bedrock's metrics and invocation logs are stored in the source Region where you submitted the request, whatever destination Region processed it. If a team calls from outside India, those records would sit outside India even though inference ran inside. AWS also advises organisations that restrict Regions to allow the source Region and both Indian destinations in their IAM and service control policies, and points to its geographic cross-Region inference guidance.

Optional CloudTrail data-event logging records the destination Region for each call in an inferenceRegion field, which is the way to evidence where requests were processed. Invocation logging is opt-in and can contain prompts and outputs, so AWS says to review access, retention and storage settings before turning it on.

The cost and customer claims

The post gives no per-token price. It says a flex service tier is 50 percent cheaper than standard pricing for latency-tolerant work, that a priority tier costs more, and that prompt caching discounts repeated prompt prefixes. Caching can be implicit or explicit; explicit mode lets you mark breakpoints in the input to raise the hit rate.

Ultrahuman, which makes the Jade health assistant in its app, is quoted by AWS as handling more than 14,000 conversations a day. Its VP Engineering says, in the post, that health data stays inside AWS, Mumbai is a fallback Region, and prompt caching cut LLM costs by 80 percent and made multi-turn chats 85 percent faster. The post does not say what those figures are measured against, over what period, or whether the saving comes from caching alone.

What the post leaves out

There is no latency or accuracy comparison between the India and global profiles, no quota or throughput figure for the India profile, and no price. The worked example reads a synthetic Hindi electricity bill and answers follow-ups in Hinglish; AWS says all sample documents are fictional and advises post-validation or human review for important decisions. AWS describes Kimi K3 as having reached frontier-level coding and general agentic performance at release; that is Moonshot's claim as relayed by AWS, not an independent result.

For a team with an Indian residency requirement, the next step is a small test on the India profile: confirm the quota you get, measure latency and extraction accuracy against the global profile on your own documents, and check where your logs land.