Amazon Bedrock supports in-country inference in India for Kimi K3 alongside global and US-based inference. According to AWS, organizations can select an inference profile that determines which destination Regions are eligible to process a request. For workloads that need processing to remain in India, the designated profile is in.moonshotai.kimi-k3. It restricts inference processing to the AWS Mumbai and Hyderabad Regions.

The invoked profile defines the processing boundary

Kimi K3 is offered through cross-Region inference profiles in Amazon Bedrock. The profile used for a request determines the set of eligible destination Regions. This makes profile selection a central deployment choice: the India profile establishes a boundary covering two Indian Regions, while the global and US-based options address different processing-location requirements.

For cross-Region inference, data is encrypted while moving between Regions and remains on the AWS network. Users do not have to establish their own multi-Region VPC infrastructure. The service therefore handles the regional connection involved in inference, while the selected profile governs where processing may occur.

Runtime APIs and document inputs

Applications can invoke Kimi K3 through the Bedrock Runtime endpoint with multiple APIs. AWS identifies the Chat Completions and Responses APIs, with support for streaming, tool calling, and structured outputs. These options let an application progressively present a response, connect the model to defined tools, or request output in a predictable machine-readable form.

Kimi K3 accepts images, PDFs, and other file types, and input files can be included directly with base64 encoding. It can read and reason about images containing multilingual text. In the document-processing flow described by AWS, this capability removes the need for a separate OCR or translation service. The original document can be interpreted in its own script while the application requests a differently structured or differently worded result.

Structured results and the sample pipeline

Structured output is available through function calling or a JSON Schema output format. This matters when a response is intended to feed another application step rather than only be displayed as prose. A schema can define the expected fields, while function calling can connect the result with an available tool or action.

The supplied sample pipeline performs OCR in the original script, extracts configurable JSON fields, produces an English summary, and answers multi-turn questions in Hinglish. The example combines multilingual document reading, machine-processable extraction, summarization, and conversational follow-up in one flow. This is a description of the provided pipeline and not an independent assessment of its accuracy.

Choosing cost and queue behavior per request

Amazon Bedrock service tiers provide per-request price-performance selection. The flex tier offers a 50 percent discount from default standard pricing for requests that are less sensitive to latency. The priority tier provides higher queue priority at a higher price. An application can therefore align the selected tier with the urgency of an individual request instead of applying one service level to every task.

Kimi K3 also supports discounted pricing for prompt-cache hits on Amazon Bedrock. Both implicit and explicit prompt-caching modes are available. This gives integrations a choice in how they handle reusable prompt context and makes caching directly relevant to repeated interactions.

Logs, metrics, and the destination Region

Logs and metrics are stored in the source Region where the request was submitted, regardless of which destination Region processed it. Optional CloudTrail data-event logging can record the destination Region in additionalEventData.inferenceRegion. Operational teams should therefore distinguish between the source location of observability data and the destination location of inference processing.

The service separates several decisions that can otherwise be conflated. The inference profile defines eligible processing locations; the runtime API and output mechanism define how the application interacts with the model; and service tiers plus prompt caching shape the price-performance choice. With the India profile, the eligible processing boundary is Mumbai and Hyderabad, while logs and metrics remain in the Region from which the request originated.