AWS Bedrock adds India-only inference profile for Moonshot's Kimi K3

India-only inference comes to Bedrock

AWS has added in-country inference for Kimi K3 on Amazon Bedrock, allowing requests to the model to be processed entirely within India, according to a post on dev.to. Kimi K3 is a multi-modal, open-weight model from Moonshot AI that was reported at release to perform at frontier level on coding and general agentic tasks.

Two profiles with different guarantees

Bedrock serves the model through cross-Region inference profiles: an application calls it from a source Region and Bedrock routes the request to a destination Region, with the profile ID in the call determining which destinations are eligible. There are two choices. The global profile, global.moonshotai.kimi-k3, is what AWS recommends for most workloads; it is the cheapest option and the most widely available. The India geographic profile, in.moonshotai.kimi-k3, keeps processing inside the Mumbai and Hyderabad Regions, which is the relevant feature for workloads bound by data-residency rules.

AWS states that traffic moving between Regions is encrypted and remains on its own network, so customers do not need multi-Region VPC infrastructure. The model card documents which source Regions can invoke each profile.

What changes for IAM and audits

The dev.to post works through the example of Mumbai as the source Region and shows an IAM policy that permits the model in both Indian Regions as well as the India inference profile. Organisations that restrict which AWS Regions may be used must keep the source Region allowed and permit routing to both Indian destinations; the post points to a profile-scoped exception for exactly this situation. On the API side, the model is reachable through OpenAI-compatible Chat Completions and Responses endpoints, and through Bedrock's Converse and InvokeModel operations.

One detail matters for compliance reviews: metrics and logs are stored in the source Region where the request was made, regardless of which destination processed it. CloudTrail data events can record the destination Region, which helps demonstrate that inference actually stayed in-country.

Document processing as the demonstration

To show the profile in action, AWS uses a scanned Hindi electricity bill. The model reads the image directly, extracts fields into JSON following a schema, produces an English summary and answers follow-up questions in Hinglish, without a dedicated OCR or translation step. AWS advises customers to test extraction quality against their own documents and to add validation or human review for critical workflows.

Pricing options

A flex service tier offers a 50 percent discount on standard pricing for latency-tolerant workloads, while a priority tier costs extra. Prompt caching, whether implicit or explicit, discounts repeated prompt prefixes. The dev.to post notes that AWS does not say whether the India profile is priced differently from the global one, so teams should check the pricing page before assuming parity.

AWS also quotes Ultrahuman, whose health assistant handles more than 14,000 conversations per day. The company reports an 80 percent reduction in LLM costs and 85 percent faster multi-turn conversations thanks to prompt caching, figures that are customer-reported rather than independently benchmarked.

Why it matters

Data-protection expectations in India increasingly require processing, not just storage, to happen in-country, and that has limited which models regulated organisations there can deploy. A geographic inference profile turns residency compliance into a routing configuration rather than a bespoke architecture project, and the logging behaviour gives auditors evidence of where inference ran. The choice of demo is also telling: a multimodal model that reads a Hindi document and converses in Hinglish targets real Indian enterprise workloads rather than translated Western use cases. The open question is cost, since if the India profile carries a premium, organisations will effectively be paying extra for compliance, and the pricing page is where that trade-off gets decided.