Friday, March 27, 2026

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


Kia ora!

Prospects in New Zealand have been asking for entry to basis fashions (FMs) on Amazon Bedrock from their native AWS Area.

In the present day, we’re excited to announce that Amazon Bedrock is now accessible within the Asia Pacific (New Zealand) Area (ap-southeast-6). Prospects in New Zealand can now entry Anthropic Claude fashions (Claude Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6, and Haiku 4.5) and Amazon (Nova 2 Lite) fashions immediately within the Auckland Area with cross area inference.

On this submit, we discover how cross-Area inference works from the New Zealand Area, the fashions accessible via geographic and international routing, and get began along with your first API name. We cowl three key areas:

  • How Amazon Bedrock in ap-southeast-6 makes use of cross-Area inference to provide you entry to FMs, with the ANZ geographic routing configuration throughout Auckland, Sydney, and Melbourne
  • Supported fashions, IAM permissions, and making your first inference name from the Auckland Area
  • Quota administration, safety concerns, and selecting between geographic and international cross-Area inference in your workloads

Understanding cross-Area inference

Cross-Area inference is an Amazon Bedrock functionality that distributes inference processing throughout a number of AWS Areas that will help you obtain increased throughput at scale.

Once you invoke a cross-Area inference profile, Amazon Bedrock routes your request from the supply Area (the place you provoke the API name) to a vacation spot Area (the place inference processing happens). All information transmitted throughout cross-Area operations stays on the AWS community and doesn’t traverse the general public web, and information is encrypted in transit between AWS Areas. All cross-Area inference requests are logged in AWS CloudTrail in your supply Area. If you happen to configure mannequin invocation logging, logs are printed to Amazon CloudWatch Logs or Amazon Easy Storage Service (Amazon S3) in the identical Area.

Amazon Bedrock supplies two varieties of cross-Area inference profiles:

  • Geographic cross-Area inference – Routes requests inside a particular geographic boundary. For instance, with AU profile, and Auckland as your supply Area, requests path to Auckland, Sydney, and Melbourne. Designed for organizations with information residency necessities that want inference processing to remain inside Australia and New Zealand.
  • World cross-Area inference – Routes requests to supported industrial AWS Areas worldwide, offering the best accessible throughput. Designed for organizations with out strict information residency necessities.

What’s new: New Zealand as a supply Area for cross-Area inference

With this launch, Auckland (ap-southeast-6) turns into a brand new supply Area for each AU geographic and international cross-Area inference on Amazon Bedrock. This implies which you can now make Amazon Bedrock API calls from the New Zealand Area, and cross-Area inference routes your requests to vacation spot Areas the place the FMs course of inference.

AU geographic cross-Area inference configuration

The AU cross-Area profile now spans three Areas throughout Australia and New Zealand. The next desk particulars the supply and vacation spot Area routing.

Supply Area Vacation spot Areas Description
Auckland (ap-southeast-6) ap-southeast-6, ap-southeast-2, ap-southeast-4 New – Requests from Auckland will be routed to Sydney, Melbourne, or Auckland
Sydney (ap-southeast-2) ap-southeast-2, ap-southeast-4 Requests from Sydney will be routed to Sydney or Melbourne
Melbourne (ap-southeast-4) ap-southeast-2, ap-southeast-4 Requests from Melbourne will be routed to Sydney or Melbourne

There are two necessary particulars to notice:

  • The AU cross-Area inference profiles for Sydney and Melbourne proceed to route between Sydney and Melbourne solely. The addition of Auckland doesn’t change the vacation spot Areas for current Australian supply Area configurations.
  • Requests originating from Auckland will be served regionally or routed to both Australian Area, offering three vacation spot Areas for capability distribution.

World cross-Area inference from New Zealand

For organizations with out strict information residency necessities, international cross-Area inference from the Auckland Area supplies entry to inference capability throughout all supported AWS industrial Areas worldwide. World cross-Area inference delivers two key benefits:

  • Larger throughput — Clever routing distributes visitors dynamically throughout all supported industrial Areas, lowering the chance of throttling throughout visitors spikes
  • Constructed-in resilience — Requests are mechanically routed to Areas with accessible capability, serving to your purposes keep operational continuity as demand patterns shift

Getting began

Supported fashions and inference profile IDs

Cross-Area inference from the New Zealand Area helps basis fashions from a number of suppliers throughout each AU geographic and international cross-Area inference profiles. The next desk exhibits examples of the newest fashions accessible at launch.

Cross-Area inference kind Instance fashions
AU geographic cross-Area inference Anthropic Claude Opus 4.6, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Haiku 4.5
World cross-Area 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-Area inference presently helps Anthropic Claude fashions, conserving inference processing throughout the ANZ geography. World cross-Area inference supplies entry to a broader set of basis fashions from a number of suppliers. To make use of a cross-Area inference profile, substitute the foundational mannequin ID with the geographic (au.) or international (international.) prefix — for instance, anthropic.claude-sonnet-4-6 turns into au.anthropic.claude-sonnet-4-6 or international.anthropic.claude-sonnet-4-6.

For the whole and up-to-date record of supported fashions and inference profile IDs, seek advice from Supported Areas and fashions for inference profiles.

Cross-Area inference profiles work with the InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream APIs. The Converse API supplies a constant request and response format throughout completely different basis fashions, making it easy to change between fashions with out rewriting integration code.

Configure IAM permissions

To invoke basis fashions via AU geographic cross-Area inference from the Auckland Area, your AWS Id and Entry Administration (IAM) coverage wants two statements:

  • Granting entry to the inference profile within the supply Area
  • Granting entry to the muse mannequin in all vacation spot Areas listed within the AU cross-Area inference profile.

The next IAM coverage instance grants entry to invoke Anthropic Claude Sonnet 4.6 via AU geographic cross-Area inference from Auckland. Change along with your AWS account ID.

{ 
     "Model": "2012-10-17", 
     "Assertion": [ 
         { 
             "Sid": "AllowAuCrisInferenceProfile", 
             "Effect": "Allow", 
             "Action": [ 
                 "bedrock:InvokeModel", 
                 "bedrock:InvokeModelWithResponseStream" 
             ], 
             "Useful resource": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6" 
         }, 
         { 
             "Sid": "AllowFoundationModelViaAuCris", 
             "Impact": "Permit", 
             "Motion": [ 
                 "bedrock:InvokeModel", 
                 "bedrock:InvokeModelWithResponseStream" 
             ], 
             "Useful 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" 
             ], 
             "Situation": { 
                 "StringLike": { 
                     "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6" 
                 } 
             } 
         } 
     ] 
} 

The primary assertion permits invoking the AU inference profile from the Auckland supply Area. The second assertion permits the FM to be invoked within the three vacation spot Areas, however solely when the request is routed via the AU inference profile. This follows the precept of least privilege by stopping direct mannequin invocation in these Areas.

The identical two-statement sample applies to any mannequin within the AU cross-Area inference profile—substitute the mannequin ID within the useful resource ARNs. For international cross-Area inference IAM insurance policies, service management insurance policies (SCP) configurations, and superior safety patterns, seek advice from Securing Amazon Bedrock cross-Area inference: Geographic and international.

Safety and compliance concerns

Cross-Area inference is designed with safety at its core. All requests journey solely over the AWS World Community with end-to-end encryption, and your information at relaxation stays within the supply Area.

For organizations utilizing SCPs to limit entry to particular AWS Areas, word the next when calling from the Auckland supply Area (ap-southeast-6):

  • AU geographic cross-Area inference requires permitting ap-southeast-2, ap-southeast-4, and ap-southeast-6 for Amazon Bedrock actions in your SCPs, as a result of Auckland’s AU profile routes to all three ANZ Areas.
  • World cross-Area inference moreover requires permitting unspecified as a Area worth for Amazon Bedrock actions, as a result of vacation spot Areas are decided dynamically.

The next instance SCP restricts companies to the Auckland Area, with exceptions for Amazon Bedrock and international companies like IAM. It limits Amazon Bedrock to the three ANZ Areas, and requires that Amazon Bedrock entry in Sydney and Melbourne undergo cross-Area inference profiles quite than direct mannequin invocation:

{ 
     "Model": "2012-10-17", 
     "Assertion": [ 
         { 
             "Sid": "DenyNonBedrockServicesOutsideAuckland", 
             "Effect": "Deny", 
             "NotAction": [ 
                 "bedrock:*", 
                 "iam:*", 
                 "organizations:*", 
                 "support:*" 
             ], 
             "Useful resource": "*", 
             "Situation": { 
                 "StringNotEquals": { 
                     "aws:RequestedRegion": ["ap-southeast-6"] 
                 } 
             } 
         }, 
         { 
             "Sid": "DenyBedrockOutsideANZRegions", 
             "Impact": "Deny", 
             "Motion": "bedrock:*", 
             "Useful resource": "*", 
             "Situation": { 
                 "StringNotEquals": { 
                     "aws:RequestedRegion": [ 
                         "ap-southeast-2", 
                         "ap-southeast-4", 
                         "ap-southeast-6" 
                     ] 
                 } 
             } 
         }, 
         { 
             "Sid": "DenyDirectBedrockInDestinationRegions", 
             "Impact": "Deny", 
             "Motion": "bedrock:*", 
             "Useful resource": "*", 
             "Situation": { 
                 "StringEquals": { 
                     "aws:RequestedRegion": [ 
                         "ap-southeast-2", 
                         "ap-southeast-4" 
                     ] 
                 }, 
                 "Null": { 
                     "bedrock:InferenceProfileArn": "true" 
                 } 
             } 
         } 
     ] 
} 

Within the earlier coverage:

  • The primary assertion restricts all companies to the Auckland Area, aside from Amazon Bedrock and international companies corresponding to IAM, AWS Organizations, and AWS Assist that function independently of Area restrictions.
  • The second assertion restricts Amazon Bedrock to the three ANZ Areas, which is important for AU cross-Area inference to route requests from Auckland to Sydney and Melbourne.
  • The third assertion makes use of the Null situation on bedrock:InferenceProfileArn to disclaim any Amazon Bedrock request in Sydney or Melbourne that’s not routed via a cross-Area inference profile. This prevents direct mannequin invocation in vacation spot Areas whereas permitting cross-Area inference to operate usually.

For detailed SCP configuration examples, international cross-Area inference IAM insurance policies, disabling particular cross-Area inference sorts, and AWS Management Tower integration steering, seek advice from Securing Amazon Bedrock cross-Area inference: Geographic and international.

Auditing and monitoring

AWS CloudTrail logs all cross-Area inference calls within the supply Area. The additionalEventData.inferenceRegion discipline information the place every request was processed, so you possibly can audit precisely the place 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 supplies metrics for cross-Area inference requests in your supply Area. Key metrics embody:

  • InvocationCount — Complete variety of inference requests
  • InvocationLatency — Finish-to-end response time together with cross-Area routing
  • InvocationClientErrors — Failed requests, together with throttling (spikes point out that you simply’re approaching quota limits)
  • InputTokenCount and OutputTokenCount — Token consumption for quota monitoring

Quota administration

Amazon Bedrock service quotas are managed on the supply Area stage. Quota will increase requested from the Auckland Area (ap-southeast-6) apply solely to requests originating from Auckland.

Quotas are measured in two dimensions:

  • Tokens per minute (TPM) — The utmost variety of tokens (enter + output) processed per minute
  • Requests per minute (RPM) — The utmost variety of inference requests per minute

When calculating your required quota, account for the token burndown charge. For Anthropic Claude Opus 4.6, Sonnet 4.6, and Sonnet 4.5, output tokens eat 5 instances extra quota than enter tokens (5:1 burndown charge). For Claude Haiku 4.5 and Amazon Nova fashions, the burndown charge is 1:1.

Quota consumption system:

Quota consumption = Enter tokens + Cache write tokens + (Output tokens x Burndown charge)

To request quota will increase, navigate to the AWS Service Quotas console in your supply Area, choose Amazon Bedrock, and seek for the related cross-Area inference quota in your mannequin.

Conclusion

On this submit, we launched cross-Area inference help from the New Zealand Area on Amazon Bedrock. Prospects in New Zealand can now make API calls from Auckland and entry basis fashions via geographic and international cross-Area inference profiles.Key takeaways:

  • Auckland is now a supply Area for cross-Area inference — New Zealand prospects could make Amazon Bedrock API calls from their native Area, with logs and configurations staying in Auckland.
  • AU geographic cross-Area inference retains information inside ANZ — Inference requests from Auckland route to a few locations (Auckland, Sydney, and Melbourne), offering Anthropic Claude fashions throughout the ANZ geographic boundary.
  • World cross-Area inference expands mannequin entry — offering the best accessible throughput by routing requests to supported industrial AWS Areas worldwide.
  • Present Australian routing is unchanged — Sydney and Melbourne supply Areas proceed to route between one another solely.

You will get began with cross-Area inference from the New Zealand Area with the next steps:

  • Register to the Amazon Bedrock console within the Auckland Area (ap-southeast-6).
  • Configure IAM and SCP permissions utilizing the coverage instance on this submit.
  • Make your first API name utilizing the au. inference profile ID.
  • Request quota will increase via the Service Quotas console primarily based in your anticipated workload.

For extra data, seek advice from:


In regards to the authors

Zohreh Norouzi

Zohreh Norouzi is a Safety Options Architect at Amazon Net Companies. She helps prospects make good safety decisions and speed up their journey to the AWS Cloud. She has been actively concerned in generative AI safety initiatives throughout APJ, utilizing her experience to assist prospects construct safe generative AI options at scale.

Melanie Li

Melanie Li, PhD, is a Senior Generative AI Specialist Options Architect at AWS primarily based in Sydney, Australia, the place her focus is on working with prospects to construct options utilizing state-of-the-art AI/ML instruments. She has been actively concerned in a number of generative AI initiatives throughout APJ, harnessing the ability of LLMs. Previous to becoming a member of AWS, Dr. Li held information science roles within the monetary and retail industries.

Saurabh Trikande

Saurabh Trikande is a Senior Product Supervisor for Amazon Bedrock and Amazon SageMaker Inference. He’s enthusiastic about working with prospects and companions, motivated by the aim of democratizing AI. He focuses on core challenges associated to deploying complicated AI purposes, inference with multi-tenant fashions, value optimizations, and making the deployment of generative AI fashions extra accessible. In his spare time, Saurabh enjoys mountaineering, studying about revolutionary applied sciences, following TechCrunch, and spending time together with his household.

James Zheng

James Zheng is a Software program Growth Supervisor at Amazon Net Companies.

William Yap

William Yap is Principal Product Supervisor for Amazon Bedrock.

Julia Bodia

Julia Bodia is Principal Product Supervisor for Amazon Bedrock.

Related Articles

Latest Articles