AWS published an implementation guide for Kimi K3.1 Pro Highspeed on Amazon Bedrock on November 10, 2026, covering endpoint selection, authentication, model IDs, reasoning settings, prompt caching, and coding-assistant integration.
The guide follows AWS’s November 6 availability announcement. It’s deployment guidance for an already announced model, with a particularly straightforward starting point for existing Kimi K3 applications. AWS says the Highspeed variant uses the same endpoint, APIs, and features as Kimi K3 on Bedrock, so an initial migration can start with a model-ID change.
The consequential choices come immediately afterward. A regional endpoint address, an inference profile’s processing geography, and AWS’s data-handling boundary describe different things. Keeping those distinctions clear matters more than the size of the code change.
Switching an Existing Kimi Application
Kimi K3.1 Pro Highspeed supports four API families on the bedrock-runtime endpoint:
- OpenAI-compatible Chat Completions
- OpenAI-compatible Responses
- Amazon Bedrock Converse
- Amazon Bedrock Invoke
AWS recommends Chat Completions in its implementation guide. Bedrock’s API compatibility documentation also lists the model’s supported API families.
For an existing Kimi K3 application on Bedrock, the new global inference-profile ID is:
global.moonshotai.kimi-k3.1
Use that value in the OpenAI SDK’s model field or Bedrock Converse’s modelId field. An application currently calling Moonshot directly has an additional migration step: configure the Bedrock endpoint and AWS authentication.
An OpenAI SDK Request Against Bedrock
AWS’s example requires Python 3.11 or later and these packages:
pip install -U openai aws-bedrock-token-generator boto3
The installation command supplies the OpenAI client, AWS’s Bedrock token generator, and the AWS SDK for Python. It does not configure your AWS account or permissions.
The following request follows AWS’s documented client setup, with low reasoning selected for a simple explanation:
from openai import OpenAI
from aws_bedrock_token_generator import provide_token
REGION = "us-west-2"
MODEL_ID = "global.moonshotai.kimi-k3.1"
client = OpenAI(
base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
api_key=provide_token(region=REGION),
)
completion = client.chat.completions.create(
model=MODEL_ID,
messages=[
{"role": "system", "content": "You are a concise senior engineer."},
{"role": "user", "content": "When should I prefer a queue over a stream?"},
],
reasoning_effort="low",
)
print(completion.choices[0].message.content)
This code creates a short-term bearer token from AWS credentials, points the OpenAI client at Bedrock, and submits a Chat Completions request. It avoids placing a long-lived key directly in the example.
The IAM identity needs permission for bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the relevant inference profiles. AWS also specifies bedrock:CallWithBearerToken when using bearer-token authentication. Those permissions and valid AWS credentials are prerequisites for the example, according to the guide.
Existing Responses integrations use the same client, but reasoning is expressed as reasoning={"effort": "low"} instead of reasoning_effort="low".
Converse users should also check response parsing. AWS’s example notes that the model can return a reasoning block before its answer, then selects a content block containing text. Code that assumes the first content block is always the final answer deserves attention during migration.
Choose the Inference Profile Before the Endpoint Region
AWS documents three cross-Region inference profiles:
| Profile ID | Processing geography described by AWS | Practical use |
|---|---|---|
global.moonshotai.kimi-k3.1 | Any supported commercial AWS Region | AWS’s recommendation for most workloads; lower per-token cost than geographic profiles |
us.moonshotai.kimi-k3.1 | US Regions | Workloads requiring processing to remain within the US |
in.moonshotai.kimi-k3.1 | India Regions | Workloads requiring processing to remain within India |
These are routing profiles, not three names for an identical deployment. AWS’s guide explicitly connects the US and India profiles to data-residency requirements.
The Python example uses a us-west-2 endpoint with the global profile. That combination is important: the endpoint’s Region identifies where the client addresses the service, while the selected profile determines the documented cross-Region routing scope. A US endpoint combined with the global profile should not be read as a promise of US-only processing.
AWS’s availability announcement describes access across Bedrock Regions through cross-Region inference. That wording also should not be read as local inference capacity in every Region.
I’d make the profile an explicit deployment setting, alongside the endpoint Region. The reasoning is simple: changing the profile can change both processing geography and per-token cost. Leaving it buried in application code makes a consequential policy choice easy to overlook.
What AWS’s Data Boundary Covers
AWS says Kimi K3.1 Pro Highspeed inference is processed within its data boundary, is not shared with Moonshot AI, and is not used to train the model. The company also says zero data retention is always enabled for inference requests and that zero operator access prevents AWS operators from viewing prompts and completions during inference. These are AWS’s service assurances.
The useful distinction is between who handles the inference data and where processing occurs. Keeping data inside AWS’s boundary does not, by itself, mean it remains in a particular country. The inference profile supplies the separate geographic constraint described in the guide.
These assurances also concern Bedrock inference handling. Your application’s logging, stored conversation history, and copies of documents sent to a coding assistant still need their own controls.
For a migration review, I’d therefore separate two checks: confirm the selected profile satisfies the workload’s residency needs, then review what the application records around each request. AWS’s inference boundary is valuable, but it does not configure an application’s observability or storage policy.
Three Separate Controls for Cost and Latency
AWS’s guide provides three ways to tune a workload: reasoning effort, service tier, and explicit prompt caching. Each addresses a different source of cost or delay.
Set Reasoning Effort Deliberately
Kimi K3.1 Pro Highspeed always reasons before answering, according to AWS. Its supported effort settings are low, high, and max, with max as the default.
AWS describes selecting a lower effort as the most direct way to reduce latency and output tokens on simpler tasks. That makes an omitted setting consequential: a minimal model-ID migration can leave every request using maximum reasoning effort.
I’d start routine explanations and straightforward summarization with an explicit effort setting, then evaluate whether more reasoning improves the results enough to justify the additional work. The guide provides the control and expected direction of the tradeoff; it does not supply independent measurements for a particular application.
Use Flex for Work That Can Wait
AWS says the Flex tier costs half the Standard price, in exchange for potentially longer response times. It identifies model evaluations, content summarization, and background agent tasks as suitable examples.
Frequently Asked Questions
3 questions
1Can Existing Kimi K3 Users Change Only the Model ID?
AWS says Kimi K3.1 Pro Highspeed uses the same Bedrock endpoint, APIs, and features as Kimi K3. A model-ID change is the starting point, followed by checks on permissions, routing, and response parsing.
