Grok 4.6 on Bedrock makes geography part of the model call

Amazon Bedrock now offers SpaceXAI Grok 4.6 through two cross-Region inference profiles. The US profile can process requests across supported Regions within the United States. The Global profile can route them across supported commercial AWS Regions worldwide.

That makes the first production decision larger than “Should we test Grok 4.6?” A team also has to choose where requests may be processed, which endpoint the application will call, and what evidence it needs to retain. This article explains those dependencies and gives a synthetic canary for verifying the chosen route before real business data enters it.

What did AWS release?

AWS announced Bedrock support for Grok 4.6 on August 19, one day after the model's launch date in the Bedrock model card. AWS describes it as a model for coding, agentic tasks, and knowledge work. The model card documents a 500,000-token context window, text and image input, text output, and four reasoning-effort settings.

Those are provider-published capabilities, not proof that the model fits a particular workload. Quality still needs evaluation against the team's own inputs, acceptance criteria, latency limits, and review burden.

The operational change is more concrete. AWS exposes two system-defined profile IDs:

• us.xai.grok-4.6 routes within the US geography.
• global.xai.grok-4.6 may route to any supported commercial AWS Region worldwide.

Both profiles expand the capacity available to a request without requiring the application to select a destination Region itself. They do not create the same processing boundary.

How do US and Global profiles change the decision?

AWS's cross-Region inference documentation distinguishes geographic profiles from global profiles. A geographic profile keeps processing inside its named geography. A global profile allows worldwide routing across supported commercial Regions.

AWS positions the Global option for the broadest capacity and lower token pricing. Its comparison table says Global pricing is approximately 10% lower than geographic cross-Region pricing. Treat that as a provider-published price comparison, not a forecast of total workload savings. Retries, output length, reasoning effort, logging, surrounding infrastructure, and human review can matter more than the token-rate difference.

The US profile is the relevant candidate when policy or contract terms require processing to stay in the United States. “US” still means more than one Region may process a request. The application chooses the profile's geographic boundary; Bedrock chooses an available processing Region inside it.

Global should be an explicit approval, not an accidental default chosen for a cheaper rate. It can be appropriate when worldwide processing is allowed and the broader capacity pool is valuable. It is inappropriate when the team cannot document that worldwide processing is permitted for the data class in the workload.

Processing location and log location are different facts

Cross-Region inference centralizes some evidence in the source Region. AWS says CloudTrail records the request there, even when another Region processes it. The event's additionalEventData.inferenceRegion field identifies the processing Region.

That distinction matters during review. A CloudTrail event stored in us-east-1 does not mean us-east-1 processed the prompt. The inference profile defines the allowed pool, while inferenceRegion records where Bedrock says that invocation was processed.

AWS also says cross-Region traffic remains on the AWS network and is encrypted in transit. Those infrastructure facts do not decide whether the business may process a particular customer record, source file, or internal document in every Region allowed by the profile. Data classification and contractual approval still sit above the route.

Endpoint choice determines whether invocation logging can see the call

The launch notice highlights the bedrock-runtime endpoint with Responses, Chat Completions, and Converse support. The current model card also lists bedrock-mantle as a supported endpoint for some APIs.

AWS's model invocation logging documentation draws an important boundary between them. Invocation logging currently supports calls through bedrock-runtime, including compatible Responses and Chat Completions calls on that endpoint. AWS says calls through other endpoints, including bedrock-mantle, are not currently captured by model invocation logging.

An application can therefore call the same named model while taking a different evidence path. If the pilot requires invocation records, do not approve only “Grok 4.6 on Bedrock.” Record the endpoint and API operation too, then prove that the expected event reaches the configured destination.

Invocation logging is also disabled by default. When enabled, it can collect request data, response data, and metadata in same-account, same-Region CloudWatch Logs or Amazon S3 destinations. That can help with debugging and usage review, but it can also create a retained copy of sensitive prompt and output content. Enable only the fields and destinations the team is prepared to protect, retain, review, and delete.

CloudTrail and invocation logging answer different questions. CloudTrail can establish who called the service, when, from which source Region, and which processing Region AWS recorded. Invocation logging can preserve model input and output content for supported runtime calls when configured. Neither proves that an output was correct or that a business action based on it was approved.

What should a pilot record before its first real request?

Write one route definition for the workload, rather than relying on a general Bedrock approval:

Scroll sideways to see all 2 columns.

Route fact	Pilot decision
Workload and data class	Name the exact job and the least-sensitive representative data it needs.
Inference profile	Record us.xai.grok-4.6 or global.xai.grok-4.6, not only the model name.
Allowed processing boundary	State US-only or worldwide and link the policy or contract owner who approved it.
Source Region	Record where the application calls Bedrock and where source-side evidence should appear.
Endpoint and API	Record bedrock-runtime or bedrock-mantle plus Responses, Chat Completions, or Converse.
Evidence	Decide whether CloudTrail is sufficient or invocation content logging is required.
Content retention	Define which prompt and output fields may be logged, destination access, retention, and deletion.
Fallback	Name a separately approved profile and endpoint, or stop when the primary route is unavailable.

This is narrower than a full model evaluation. It establishes where the test may run and whether operators can explain the route afterward. The Bedrock model facts register can hold the wider quality, quota, lifecycle, and fallback facts after this route is proven.

How can a synthetic canary verify the route?

Use a prompt containing a unique synthetic marker and no customer, employee, source-code, credential, or production data. Invoke the exact profile, endpoint, API, source Region, IAM role, and client configuration intended for the pilot.

Then check four outcomes:

1. Confirm the application record contains the selected profile ID, source Region, endpoint, API operation, request ID, and synthetic marker.
2. Find the matching CloudTrail event in the source Region and preserve its additionalEventData.inferenceRegion value. Confirm that the Region falls inside the approved profile boundary.
3. If invocation logging is required, verify that the matching runtime call reaches the configured same-Region destination with the expected metadata. Do not use a successful runtime log to infer coverage for bedrock-mantle.
4. Remove the synthetic record under the planned deletion procedure, then test the fallback or stop rule without silently switching to a profile with a broader geography.

Repeat the canary after changing the profile, endpoint, API, source Region, IAM path, logging configuration, or client library. A pass belongs to that exact route, not to the model name in general.

Grok 4.6's arrival on Bedrock is useful because it makes two infrastructure choices visible at the start. The profile decides the allowed processing pool. The endpoint helps determine whether model invocation logging can observe the call. Choose both before evaluating real work, and preserve enough source-Region evidence to show that production followed the route the business approved.

Sources

• AWS What's New: Amazon Bedrock now supports SpaceXAI Grok 4.6 with Cross Region Inferencing, August 19, 2026
• Amazon Bedrock model card: Grok 4.6
• Amazon Bedrock: Cross-Region inference
• Amazon Bedrock: Model invocation logging