Skip to content
Chimera readability score 0.6866 out of 100, reading level.

Artificial Intelligence
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.
| Source Region | Destination Regions | Description |
Auckland (ap-southeast-6 ) |
ap-southeast-6 , ap-southeast-2 , ap-southeast-4 |
New – Requests from Auckland can be routed to Sydney, Melbourne, or Auckland |
Sydney (ap-southeast-2 ) |
ap-southeast-2 , ap-southeast-4 |
Requests from Sydney can be routed to Sydney or Melbourne |
Melbourne (ap-southeast-4 ) |
ap-southeast-2 , ap-southeast-4 |
Requests from Melbourne can be routed to Sydney or Melbourne |
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.
| Cross-Region inference type | Example models |
| AU geographic cross-Region inference | Anthropic Claude Opus 4.6, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Haiku 4.5 |
| Global cross-Region inference | Anthropic Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5 |
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
with your AWS account ID.
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
, andap-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:
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:
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

Facts Only

Amazon Bedrock is now available in the Asia Pacific (New Zealand) Region (ap-southeast-6).
Customers in New Zealand can access Anthropic Claude models (Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6, Haiku 4.5) and Amazon Nova 2 Lite models.
Cross-Region inference routes requests from the source Region (Auckland) to destination Regions for processing.
Two cross-Region inference types exist: geographic (AU profile, limited to ANZ) and global (worldwide routing).
The AU geographic profile includes Auckland, Sydney (ap-southeast-2), and Melbourne (ap-southeast-4).
Global cross-Region inference provides higher throughput and resilience by routing to supported commercial AWS Regions.
IAM policies require permissions for both the source Region and destination Regions.
Data transmitted during cross-Region inference remains on the AWS network and is encrypted in transit.
AWS CloudTrail logs all cross-Region inference calls in the source Region.
Quotas are managed per source Region, measured in tokens per minute (TPM) and requests per minute (RPM).
Token consumption varies by model, with some models having a 5:1 burndown rate for output tokens.
The Converse API standardizes request/response formats across models.

Executive Summary

Amazon Bedrock is now available in the Asia Pacific (New Zealand) Region, allowing customers in New Zealand to access foundation models like Anthropic Claude and Amazon Nova directly from the Auckland Region. The service uses cross-Region inference, which distributes processing across multiple AWS Regions to improve throughput and resilience. Two types of cross-Region inference are supported: geographic, which keeps data within Australia and New Zealand (ANZ), and global, which routes requests worldwide for higher throughput. The AU geographic profile now includes Auckland, Sydney, and Melbourne, while global inference provides broader model access. Customers must configure IAM permissions and may need to adjust service control policies to comply with data residency requirements. Security measures include end-to-end encryption and logging via AWS CloudTrail. Quotas are managed at the source Region level, with consumption calculated based on token usage and model-specific burndown rates. This launch enables New Zealand-based organizations to leverage generative AI while maintaining local data governance.
The expansion reflects AWS's strategy to decentralize AI infrastructure, balancing performance with regulatory compliance. However, organizations must carefully manage permissions and quotas to avoid operational disruptions. The choice between geographic and global inference depends on data residency needs versus throughput priorities.

Full Take

This announcement marks a strategic expansion of AWS's generative AI infrastructure into New Zealand, addressing local demand while navigating data residency requirements. The strongest version of this narrative highlights AWS's commitment to decentralizing AI access, offering both geographic and global routing to balance compliance with performance. The technical implementation—cross-Region inference—is framed as a solution for throughput and resilience, with security measures like end-to-end encryption and CloudTrail logging reinforcing trust.
However, the pattern scan reveals subtle authority games: the emphasis on "intelligent routing" and "built-in resilience" leans on technical jargon to position AWS as the inevitable choice, while the complexity of IAM and SCP configurations could create dependency on AWS expertise. The framing of geographic vs. global inference as a binary choice (compliance vs. performance) risks oversimplifying organizational trade-offs, though the article does provide clear technical guidance.
Root cause: This reflects the broader cloud provider playbook of regional expansion to capture market share while addressing regulatory pressures. The unstated assumption is that centralized AI infrastructure (even with cross-Region routing) is the only viable path forward, sidelining alternatives like edge computing or hybrid models.
Implications: New Zealand organizations gain local access to cutting-edge AI but must navigate AWS's ecosystem lock-in. The cost-benefit analysis favors enterprises with existing AWS investments, potentially marginalizing smaller players. Second-order consequences include increased data sovereignty debates and pressure on local regulators to clarify cross-border data flow rules.
Bridge questions: How might this shift affect New Zealand's domestic AI innovation ecosystem? What are the long-term costs of relying on foreign cloud providers for critical infrastructure? Would a multi-cloud or hybrid approach better serve data sovereignty goals?
Counterstrike scan: A coordinated influence campaign would exaggerate the risks of not adopting AWS Bedrock (e.g., "falling behind in AI") while downplaying lock-in concerns. The actual content avoids such tactics, focusing on technical details and compliance. No structural alignment with manipulation patterns detected.
Patterns detected: none

Sentinel — Human

Confidence

Sentinel analysis incomplete — partial response from fallback model.

Signals Detected
severity: Sentence length and structure variations, as well as the use of contractions suggest human authorship.
severity: The technical nature of the content about AWS services suggests expertise or a professional writer, which is less common for synthetic data.