Run Generative AI inference with Amazon Bedrock in Asia Pacific (New Zealand)

Kia ora!

Customers in New Zealand have been asking for access to foundation models (FMs) on Amazon Bedrock from their local AWS Region.

Today, we’re excited to announce that Amazon Bedrock is now available in the Asia Pacific (New Zealand) Region (ap-southeast-6). Customers in New Zealand can now access Anthropic Claude models (Claude Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6, and Haiku 4.5) and Amazon (Nova 2 Lite) models directly in the Auckland Region with cross region inference.

In this post, we explore how cross-Region inference works from the New Zealand Region, the models available through geographic and global routing, and how to get started with your first API call. We cover three key areas:

• How Amazon Bedrock in ap-southeast-6 uses cross-Region inference to give you access to FMs, with the ANZ geographic routing configuration across Auckland, Sydney, and Melbourne
• Supported models, IAM permissions, and making your first inference call from the Auckland Region
• Quota management, security considerations, and choosing between geographic and global cross-Region inference for your workloads

Understanding cross-Region inference

Cross-Region inference is an Amazon Bedrock capability that distributes inference processing across multiple AWS Regions to help you achieve higher throughput at scale.

When you invoke a cross-Region inference profile, Amazon Bedrock routes your request from the source Region (where you initiate the API call) to a destination Region (where inference processing occurs). All data transmitted during cross-Region operations remains on the AWS network and doesn’t traverse the public internet, and data is encrypted in transit between AWS Regions. All cross-Region inference requests are logged in AWS CloudTrail in your source Region. If you configure model invocation logging, logs are published to Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3) in the same Region.

Amazon Bedrock provides two types of cross-Region inference profiles:

• Geographic cross-Region inference – Routes requests within a specific geographic boundary. For example, with AU profile, and Auckland as your source Region, requests route to Auckland, Sydney, and Melbourne. Designed for organizations with data residency requirements that need inference processing to stay within Australia and New Zealand.
• Global cross-Region inference – Routes requests to supported commercial AWS Regions worldwide, providing the highest available throughput. Designed for organizations without strict data residency requirements.

What’s new: New Zealand as a source Region for cross-Region inference

With this launch, Auckland (ap-southeast-6) becomes a new source Region for both AU geographic and global cross-Region inference on Amazon Bedrock. This means that you can now make Amazon Bedrock API calls from the New Zealand Region, and cross-Region inference routes your requests to destination Regions where the FMs process inference.

AU geographic cross-Region inference configuration

The AU cross-Region profile now spans three Regions across Australia and New Zealand. The following table details the source and destination Region routing.

There are two important details to note:

• The AU cross-Region inference profiles for Sydney and Melbourne continue to route between Sydney and Melbourne only. The addition of Auckland doesn’t change the destination Regions for existing Australian source Region configurations.
• Requests originating from Auckland can be served locally or routed to either Australian Region, providing three destination Regions for capacity distribution.

Global cross-Region inference from New Zealand

For organizations without strict data residency requirements, global cross-Region inference from the Auckland Region provides access to inference capacity across all supported AWS commercial Regions worldwide. Global cross-Region inference delivers two key advantages:

• Higher throughput — Intelligent routing distributes traffic dynamically across all supported commercial Regions, reducing the likelihood of throttling during traffic spikes
• Built-in resilience — Requests are automatically routed to Regions with available capacity, helping your applications maintain operational continuity as demand patterns shift

Getting started

Supported models and inference profile IDs

Cross-Region inference from the New Zealand Region supports foundation models from multiple providers across both AU geographic and global cross-Region inference profiles. The following table shows examples of the latest models available at launch.

AU geographic cross-Region inference currently supports Anthropic Claude models, keeping inference processing within the ANZ geography. Global cross-Region inference provides access to a broader set of foundation models from multiple providers. To use a cross-Region inference profile, replace the foundational model ID with the geographic (au.) or global (global.) prefix — for example, anthropic.claude-sonnet-4-6 becomes au.anthropic.claude-sonnet-4-6 or global.anthropic.claude-sonnet-4-6.

For the complete and up-to-date list of supported models and inference profile IDs, refer to Supported Regions and models for inference profiles.

Cross-Region inference profiles work with the InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream APIs. The Converse API provides a consistent request and response format across different foundation models, making it straightforward to switch between models without rewriting integration code.

Configure IAM permissions

To invoke foundation models through AU geographic cross-Region inference from the Auckland Region, your AWS Identity and Access Management (IAM) policy needs two statements:

• Granting access to the inference profile in the source Region
• Granting access to the foundation model in all destination Regions listed in the AU cross-Region inference profile.

The following IAM policy example grants access to invoke Anthropic Claude Sonnet 4.6 through AU geographic cross-Region inference from Auckland. Replace <ACCOUNT_ID> with your AWS account ID.

{ 
     "Version": "2012-10-17", 
     "Statement": [ 
         { 
             "Sid": "AllowAuCrisInferenceProfile", 
             "Effect": "Allow", 
             "Action": [ 
                 "bedrock:InvokeModel", 
                 "bedrock:InvokeModelWithResponseStream" 
             ], 
             "Resource": "arn:aws:bedrock:ap-southeast-6:<ACCOUNT_ID>:inference-profile/au.anthropic.claude-sonnet-4-6" 
         }, 
         { 
             "Sid": "AllowFoundationModelViaAuCris", 
             "Effect": "Allow", 
             "Action": [ 
                 "bedrock:InvokeModel", 
                 "bedrock:InvokeModelWithResponseStream" 
             ], 
             "Resource": [ 
                 "arn:aws:bedrock:ap-southeast-2::foundation-model/anthropic.claude-sonnet-4-6", 
                 "arn:aws:bedrock:ap-southeast-4::foundation-model/anthropic.claude-sonnet-4-6", 
                 "arn:aws:bedrock:ap-southeast-6::foundation-model/anthropic.claude-sonnet-4-6" 
             ], 
             "Condition": { 
                 "StringLike": { 
                     "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-southeast-6:<ACCOUNT_ID>:inference-profile/au.anthropic.claude-sonnet-4-6" 
                 } 
             } 
         } 
     ] 
} 

The first statement allows invoking the AU inference profile from the Auckland source Region. The second statement allows the FM to be invoked in the three destination Regions, but only when the request is routed through the AU inference profile. This follows the principle of least privilege by preventing direct model invocation in those Regions.

The same two-statement pattern applies to any model in the AU cross-Region inference profile—replace the model ID in the resource ARNs. For global cross-Region inference IAM policies, service control policies (SCP) configurations, and advanced security patterns, refer to Securing Amazon Bedrock cross-Region inference: Geographic and global.

Security and compliance considerations

Cross-Region inference is designed with security at its core. All requests travel exclusively over the AWS Global Network with end-to-end encryption, and your data at rest remains in the source Region.

For organizations using SCPs to restrict access to specific AWS Regions, note the following when calling from the Auckland source Region (ap-southeast-6):

• AU geographic cross-Region inference requires allowing ap-southeast-2, ap-southeast-4, and ap-southeast-6 for Amazon Bedrock actions in your SCPs, because Auckland’s AU profile routes to all three ANZ Regions.
• Global cross-Region inference additionally requires allowing unspecified as a Region value for Amazon Bedrock actions, because destination Regions are determined dynamically.

The following example SCP restricts services to the Auckland Region, with exceptions for Amazon Bedrock and global services like IAM. It limits Amazon Bedrock to the three ANZ Regions, and requires that Amazon Bedrock access in Sydney and Melbourne go through cross-Region inference profiles rather than direct model invocation:

{ 
     "Version": "2012-10-17", 
     "Statement": [ 
         { 
             "Sid": "DenyNonBedrockServicesOutsideAuckland", 
             "Effect": "Deny", 
             "NotAction": [ 
                 "bedrock:*", 
                 "iam:*", 
                 "organizations:*", 
                 "support:*" 
             ], 
             "Resource": "*", 
             "Condition": { 
                 "StringNotEquals": { 
                     "aws:RequestedRegion": ["ap-southeast-6"] 
                 } 
             } 
         }, 
         { 
             "Sid": "DenyBedrockOutsideANZRegions", 
             "Effect": "Deny", 
             "Action": "bedrock:*", 
             "Resource": "*", 
             "Condition": { 
                 "StringNotEquals": { 
                     "aws:RequestedRegion": [ 
                         "ap-southeast-2", 
                         "ap-southeast-4", 
                         "ap-southeast-6" 
                     ] 
                 } 
             } 
         }, 
         { 
             "Sid": "DenyDirectBedrockInDestinationRegions", 
             "Effect": "Deny", 
             "Action": "bedrock:*", 
             "Resource": "*", 
             "Condition": { 
                 "StringEquals": { 
                     "aws:RequestedRegion": [ 
                         "ap-southeast-2", 
                         "ap-southeast-4" 
                     ] 
                 }, 
                 "Null": { 
                     "bedrock:InferenceProfileArn": "true" 
                 } 
             } 
         } 
     ] 
} 

In the previous policy:

• The first statement restricts all services to the Auckland Region, except for Amazon Bedrock and global services such as IAM, AWS Organizations, and AWS Support that operate independently of Region restrictions.
• The second statement restricts Amazon Bedrock to the three ANZ Regions, which is necessary for AU cross-Region inference to route requests from Auckland to Sydney and Melbourne.
• The third statement uses the Null condition on bedrock:InferenceProfileArn to deny any Amazon Bedrock request in Sydney or Melbourne that’s not routed through a cross-Region inference profile. This prevents direct model invocation in destination Regions while allowing cross-Region inference to function normally.

For detailed SCP configuration examples, global cross-Region inference IAM policies, disabling specific cross-Region inference types, and AWS Control Tower integration guidance, refer to Securing Amazon Bedrock cross-Region inference: Geographic and global.

Auditing and monitoring

AWS CloudTrail logs all cross-Region inference calls in the source Region. The additionalEventData.inferenceRegion field records where each request was processed, so you can audit exactly where inference occurred:

{ 
     "eventSource": "bedrock.amazonaws.com", 
     "eventName": "InvokeModel", 
     "awsRegion": "ap-southeast-6", 
     "requestParameters": { 
         "modelId": "au.anthropic.claude-sonnet-4-6" 
     }, 
     "additionalEventData": { 
         "inferenceRegion": "ap-southeast-2" 
     } 
} 

For real-time operational monitoring, Amazon CloudWatch provides metrics for cross-Region inference requests in your source Region. Key metrics include:

• InvocationCount — Total number of inference requests
• InvocationLatency — End-to-end response time including cross-Region routing
• InvocationClientErrors — Failed requests, including throttling (spikes indicate that you’re approaching quota limits)
• InputTokenCount and OutputTokenCount — Token consumption for quota tracking

Quota management

Amazon Bedrock service quotas are managed at the source Region level. Quota increases requested from the Auckland Region (ap-southeast-6) apply only to requests originating from Auckland.

Quotas are measured in two dimensions:

• Tokens per minute (TPM) — The maximum number of tokens (input + output) processed per minute
• Requests per minute (RPM) — The maximum number of inference requests per minute

When calculating your required quota, account for the token burndown rate. For Anthropic Claude Opus 4.6, Sonnet 4.6, and Sonnet 4.5, output tokens consume five times more quota than input tokens (5:1 burndown rate). For Claude Haiku 4.5 and Amazon Nova models, the burndown rate is 1:1.

Quota consumption formula:

Quota consumption = Input tokens + Cache write tokens + (Output tokens x Burndown rate)

To request quota increases, navigate to the AWS Service Quotas console in your source Region, select Amazon Bedrock, and search for the relevant cross-Region inference quota for your model.

Conclusion

In this post, we introduced cross-Region inference support from the New Zealand Region on Amazon Bedrock. Customers in New Zealand can now make API calls from Auckland and access foundation models through geographic and global cross-Region inference profiles.Key takeaways:

• Auckland is now a source Region for cross-Region inference — New Zealand customers can make Amazon Bedrock API calls from their local Region, with logs and configurations staying in Auckland.
• AU geographic cross-Region inference keeps data within ANZ — Inference requests from Auckland route to three destinations (Auckland, Sydney, and Melbourne), providing Anthropic Claude models within the ANZ geographic boundary.
• Global cross-Region inference expands model access — providing the highest available throughput by routing requests to supported commercial AWS Regions worldwide.
• Existing Australian routing is unchanged — Sydney and Melbourne source Regions continue to route between each other only.

You can get started with cross-Region inference from the New Zealand Region with the following steps:

• Sign in to the Amazon Bedrock console in the Auckland Region (ap-southeast-6).
• Configure IAM and SCP permissions using the policy example in this post.
• Make your first API call using the au. inference profile ID.
• Request quota increases through the Service Quotas console based on your expected workload.

For more information, refer to:

• Amazon Bedrock documentation
• Cross-Region inference User Guide
• Supported Regions and models for inference profiles
• Securing Amazon Bedrock cross-Region inference: Geographic and global
• Amazon Bedrock pricing

About the authors