Research-backed calculator guide

Amazon Bedrock Cross-Region Inference Cost: Global vs Geographic Routing

Learn how Amazon Bedrock cross-region inference cost is calculated, why source Region matters, and when global's roughly 10% token savings should give way to geographic routing.

What “source Region” means for Bedrock billing

The source Region is the Region addressed by the Bedrock runtime call. An inference profile then determines the set of Regions to which Bedrock may route the model request. A geographic profile is bounded by a named geography, while a global profile extends beyond those boundaries to supported commercial Regions. The destination is therefore a routing outcome, not the billing-rate selector in your spreadsheet. ^[1]

This distinction matters when teams compare an application in us-east-1 with a request that happens to execute in us-west-2. You should record the source Region and profile ID on each cost event. Do not replace the source Region with the observed processing Region when estimating token spend. AWS says CloudTrail records cross-region requests in the source Region and exposes additionalEventData.inferenceRegion so that operations teams can see where processing occurred. ^[1]

There is also no separate Bedrock cross-region routing line item described in the AWS documentation. The service’s cross-region feature is not the same as building your own multi-Region proxy, replicating an application, or moving data through a separately metered network path. Keep those architecture costs outside the token calculation, and verify them separately if your design adds other AWS services.

Global versus geographic cross-region pricing

Use the following decision matrix before applying a discount to a budget. It deliberately treats cost as one input rather than the only decision rule.

AWS describes geographic profiles as staying within the selected geography, but that does not mean “single source Region only.” A prompt and result can move outside the source Region while remaining inside the geography. AWS also notes that data used for abuse detection may be stored in a destination Region for models where that applies. If your requirement is that inference never leaves one specific Region, use direct in-Region invocation instead of assuming a geographic profile provides single-Region processing. ^[3]

Global profiles make a different trade. The extra routing scope can improve access to capacity and is associated with approximately 10% savings on input and output token pricing versus geographic cross-region inference. AWS’s global documentation still says the price is calculated from the source Region. The savings statement should therefore be applied to the comparable geographic/global rates shown for the specific model, rather than to an unrelated Region’s public rate card. ^[2]

Worked cost example

Assume a production assistant sends 8,000,000 input tokens and receives 1,200,000 output tokens in one month. The application invokes an inference profile from us-east-1. To make the arithmetic inspectable, assume the comparable geographic token rates are $3.00 per 1 million input tokens and $15.00 per 1 million output tokens. These are illustrative planning assumptions, not a current AWS quote for a named model.

The global column applies AWS’s documented approximately 10% comparison as a planning proxy. The exact amount can differ if the selected model has a different profile, rate table, tier, or availability rule. If your actual input rate is r_i and output rate is r_o, replace the assumptions with:

geographic = (8.0 × r_i) + (1.2 × r_o)

global estimate = (8.0 × r_i × 0.90) + (1.2 × r_o × 0.90)

This example excludes taxes, currency conversion, retries, failed requests, prompt-cache meters, batch or priority/flex tier changes, guardrails, Knowledge Bases, logging destinations, CloudWatch ingestion, application compute, and any other services. It also assumes all 8.0M input and 1.2M output tokens use the same model and source Region. If traffic is split across source Regions, calculate each source-Region bucket separately rather than averaging rates first.

The table is useful for a budget review because it makes the decision reversible. Start with actual token counts and AWS’s current model table. Run the geographic and global scenarios. Then add the non-token costs that your architecture actually enables. Finally, compare the savings with the cost of a compliance exception, additional review, or a required single-Region design. A 10% token difference is not permission to violate a residency control.

A reliable estimation workflow

First, identify the exact model ID and inference profile ID. “Bedrock” is not one price. AWS states that pricing depends on modality, provider, and model, and its pricing page presents multiple service tiers. ^[4] Note whether the request is text, multimodal, embedding, image, or another meter before copying a rate.

Second, identify the source Region in the SDK or API client configuration. Put that Region in the cost ledger beside the model and profile. The destination Region observed in CloudTrail is useful for capacity and governance analysis, but it should not silently replace the source Region in the billing estimate.

Third, select the routing boundary. For geographic inference, list the actual geography and destination Regions in the profile. For global inference, confirm that your security and data-governance policies permit processing in supported commercial Regions worldwide. AWS’s security guidance says geographic profiles require permissions for the source model and all destination models. Global profiles use a different permission pattern, including the unspecified requested-Region condition for global destination model access. ^[5]

Fourth, multiply actual input and output tokens separately. Do not use “total tokens” with one blended rate when input and output prices differ. For agent workloads, include tool-loop turns and retries. For RAG, count retrieved context sent back to the model as input. The existing RAG, embedding and vector database cost calculator can help separate retrieval and embedding assumptions from generation tokens.

Fifth, validate the estimate against logs and the invoice. CloudTrail and model invocation logging can reveal the inferenceRegion, while usage exports and the AWS bill provide the financial record. A source-region estimate should explain the token charge; it should not be treated as proof that no other enabled service generated a charge.

For a broader provider comparison, use the Model pricing comparison route to normalize input/output units and assumptions. If the alternative is hosting a model yourself, compare the fully loaded baseline with the Self-hosted GPU inference cost calculator, including utilization and idle capacity rather than comparing Bedrock tokens with raw GPU rental alone.

Data residency, IAM, and cost limitations

Geographic cross-region inference is a routing boundary, not an attestation that every byte stays in the source Region. AWS says prompts and outputs might move outside the source Region during cross-region inference, while remaining within the selected geography, and it documents encrypted transmission over the AWS network. Review the model-specific abuse-detection behavior and your own retention policy. ^[3]

Global inference should be rejected when your policy requires a bounded geography unless your compliance owner explicitly approves the worldwide processing scope. The global discount is a vendor-documented pricing comparison, not a compliance waiver. Conversely, geographic inference is not necessarily more expensive after total cost: it may prevent an exception process, keep data in an approved boundary, or reduce the engineering needed for an external routing layer.

Access policy is part of the implementation cost. A geographic profile can fail if an organization’s service-control policy allows only the source Region and blocks a destination Region that the profile needs. Global profiles have their own IAM and SCP requirements, including handling of aws:RequestedRegion: unspecified. Test policy behavior in a non-production account before using a profile in a production budget. ^[5]

The estimate also has a time boundary. This article records the pricing and product behavior checked on November 2, 2026. AWS can add models, change profile coverage, revise prices, or change supported destinations. Refresh the model’s AWS pricing section and supported-profile documentation before approving a forecast, especially for a long-lived contract or regulated workload.

FAQ

Does Bedrock charge the destination Region for cross-region inference?

The documented Bedrock pricing basis is the source Region from which you call the inference profile, and AWS says there is no additional routing cost for cross-region inference. The destination Region is still important for routing, IAM, quotas, logging analysis, and residency review. Do not interpret “no extra routing charge” as “no other AWS service in the surrounding architecture can charge.” ^[1]

Is global cross-region inference always 10% cheaper?

AWS documents approximately 10% savings on both input and output token pricing compared with geographic cross-region inference for global profiles. Treat that as a documented comparison for supported models and profiles, not as a guarantee for every Bedrock model, modality, tier, or future price table. Use the exact model’s pricing table and label your spreadsheet result an estimate until reconciled to usage. ^{[2] [4]}

Which is better for data residency: global or geographic routing?

Geographic routing is the relevant option when processing must remain inside a defined geography. Global routing can process in supported commercial AWS Regions worldwide, so it is appropriate only when your governance rules permit that scope. Neither option should be treated as a single-Region guarantee; use direct in-Region invocation when the request cannot leave one Region. ^{[1] [3]}

Does cross-region inference use Provisioned Throughput?

The general Bedrock cross-region inference documentation states that inference profiles currently do not support Provisioned Throughput. The worked example in this guide is therefore an on-demand token estimate. Confirm the current feature support for your model and profile before modeling a capacity commitment. ^[1]

How can I tell where a request was processed?

Inspect CloudTrail’s additionalEventData.inferenceRegion field, and use model invocation logging when enabled. AWS says logs remain associated with the source Region while the field identifies the processing Region. Use that evidence to investigate routing and policy behavior, but continue using the source Region as the token-billing basis in your estimate. ^[1]