OpenAI GPT-5.6 reaches Australian Amazon Bedrock Regions through global inference

Australian teams can now call OpenAI’s GPT-5.6 Sol, Terra, and Luna models through Amazon Bedrock Runtime endpoints in the Asia Pacific (Sydney) and Asia Pacific (Melbourne) AWS Regions. The application sends its request to an Australian source Region, while Amazon Bedrock routes the request to a supported commercial AWS Region for processing through global cross-Region inference.

This arrangement gives applications access to a broader pool of capacity without requiring developers to implement destination-Region routing themselves. It does not mean that processing necessarily remains in the Australian source Region: the defining feature is that Bedrock handles routing from Sydney or Melbourne to a supported destination.

The three models target different workload profiles. AWS positions GPT-5.6 Sol for demanding reasoning, coding, and agentic tasks; Terra as a balance of performance and cost for routine production workloads; and Luna as the faster, more affordable option for high-volume or latency-sensitive applications. All three accept text and image inputs, produce text, and support context windows of up to 1 million tokens.

GPT-5.6 global inference profiles

Each model has a system-defined global inference profile:

• global.openai.gpt-5.6-sol
• global.openai.gpt-5.6-terra
• global.openai.gpt-5.6-luna

The Australian source Regions covered by AWS are Asia Pacific (Sydney), identified as ap-southeast-2, and Asia Pacific (Melbourne), identified as ap-southeast-4. Calls made through those profiles are routed to supported commercial AWS Regions.

That routing configuration should be treated as dynamic infrastructure rather than a permanent destination list. AWS says profile membership and model availability can change, so teams should check the current cross-Region inference support information before deployment. Organizations with geographic, governance, or processing-location requirements should account for this behavior during architecture and compliance reviews.

Getting started

Before invoking a model, a team needs an AWS account with either Sydney or Melbourne enabled as its source Region. The calling identity must be an AWS Identity and Access Management role or user permitted to invoke the GPT-5.6 inference profiles. If the organization applies a service control policy, that policy must also allow the relevant global profiles in the selected source Region.

The Python examples require Python 3.9 or later and the openai, boto3, and aws-bedrock-token-generator packages.

Verify profiles before building against them

The AWS CLI can list matching system-defined profiles and inspect an individual profile. For Sydney, AWS provides the following checks:

aws bedrock list-inference-profiles 
--region ap-southeast-2 
--type-equals SYSTEM_DEFINED 
--query "inferenceProfileSummaries[?contains(inferenceProfileId, 'openai.gpt-5.6')].[inferenceProfileId,status]" 
--output table

aws bedrock get-inference-profile 
--region ap-southeast-2 
--inference-profile-identifier global.openai.gpt-5.6-terra

The second command inspects Terra, but the profile identifier can be changed to Sol or Luna. To conduct the same checks from Melbourne, replace ap-southeast-2 with ap-southeast-4.

The same verification is available through the Amazon Bedrock console. After selecting Sydney or Melbourne, open Inference profiles under Infer and filter for the desired global OpenAI GPT-5.6 profile. AWS’s example shows the Terra profile active from Sydney.

Invoke GPT-5.6 through Amazon Bedrock Runtime

Bedrock exposes three invocation paths for these models: the OpenAI Responses API, the OpenAI Chat Completions API, and the Amazon Bedrock Converse API. The OpenAI-compatible interfaces use the /openai/v1 path on the regional Bedrock Runtime endpoint rather than an AWS SDK operation. They accept either AWS Signature Version 4 authentication or an Amazon Bedrock model inference API key.

For an application already built around the OpenAI SDK, the main adjustment is to direct the client to the regional Bedrock endpoint and select a global profile as the model. AWS’s Python approach uses the Bedrock Token Generator to derive a short-term model inference API key from the current AWS credentials, avoiding storage of a static key:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

region = "ap-southeast-2"
model_id = "global.openai.gpt-5.6-terra"

client = OpenAI(
    base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
    api_key=provide_token(region=region),
)

result = client.responses.create(
    model=model_id,
    input="Explain how Availability Zones support high availability.",
    max_output_tokens=300,
)
print(result.output_text)

Streaming through the Responses API is enabled with stream=True; the client can then consume response.output_text.delta events as text arrives. An application using Chat Completions can call client.chat.completions.create with the same endpoint and profile. AWS’s example sets max_completion_tokens to 300 and reasoning_effort to low.

Applications using an AWS SDK can instead choose the Bedrock Converse API. With Boto3, credentials are obtained through the standard AWS credential chain:

import boto3

region = "ap-southeast-2"
client = boto3.client("bedrock-runtime", region_name=region)
result = client.converse(
    modelId="global.openai.gpt-5.6-terra",
    messages=[{
        "role": "user",
        "content": [{"text": "Explain how Availability Zones support high availability."}],
    }],
    inferenceConfig={"maxTokens": 300},
)
print(result["output"]["message"]["content"][0]["text"])

Streaming is also available through converse_stream, with text delivered in contentBlockDelta events. All these examples use Sydney; changing the Region to ap-southeast-4 moves the source endpoint to Melbourne while retaining the global inference-profile model identifier.

Working with prompt caching

GPT-5.6 prompt caching works through the supported Bedrock APIs and has two modes. Implicit caching is enabled by default and needs no application changes. Explicit caching gives the application control over the reusable prompt prefix, the cache boundary, and the cache key. Teams evaluating caching as a cost optimization should test it with their actual prompt structure instead of assuming every request pattern will reuse the same material.

Setting up Codex with GPT-5.6 on Amazon Bedrock

Codex can access the same global profiles through its native Amazon Bedrock Runtime provider. AWS validated its configuration with codex-cli 0.149.1, GPT-5.6 Sol, and the Sydney Region. The source instructs users to install the latest alpha CLI with npm install -g @openai/codex@alpha and confirm the installed version with codex --version.

For federated access, AWS supplies a sample OIDC credential helper for identity providers including Okta, Auth0, Microsoft Entra ID, Amazon Cognito, and AWS IAM Identity Center. Administrators must first configure the identity provider, the corresponding AWS federation resource, and an IAM role with the necessary Bedrock permissions.

The helper should be placed behind a named AWS profile so it does not replace credentials resolved through the default profile:

[profile <AWS_OIDC_PROFILE>]
credential_process = <ABSOLUTE_PATH_TO_CREDENTIAL_PROCESS> --profile <OIDC_HELPER_PROFILE>
region = ap-southeast-2
output = json

The credential process exchanges an OIDC token for temporary AWS credentials. Codex then obtains those credentials through the normal AWS credential chain. A corresponding ~/.codex/config.toml configuration selects Sol, the Bedrock provider, the AWS profile, and the source Region:

model = "global.openai.gpt-5.6-sol"
model_provider = "amazon-bedrock-runtime"
model_reasoning_effort = "high"

[model_providers.amazon-bedrock-runtime.aws]
profile = "<AWS_OIDC_PROFILE>"
region = "ap-southeast-2"

If there is no valid cached session, the helper opens the configured browser sign-in page. After authentication, it returns temporary credentials through credential_process. In this path, inference requests are signed using SigV4 and do not use an API key. An AWS IAM Identity Center-backed profile already supplies short-term credentials that rotate with the single sign-on session. Melbourne users should set ap-southeast-4 in both the AWS profile and Codex configuration.

Quota management

On-demand GPT-5.6 capacity is governed by requests per minute (RPM) and tokens per minute (TPM). TPM consumption is not simply the visible output length: Bedrock applies a model-specific burndown calculation to input tokens, cache-write input tokens, and output tokens.

For GPT-5.6, input and cache-write input tokens count at a 1:1 rate, while every output token consumes 10 tokens of quota. This weighting makes output-length assumptions particularly important when estimating concurrency and peak throughput.

Quotas should be reviewed in the Service Quotas console for the source Region actually used by the application—Sydney at ap-southeast-2 or Melbourne at ap-southeast-4. AWS advises requesting increases early and testing representative prompts, response lengths, streaming, concurrency, and peak traffic before a production rollout. Current quota values and burndown rates should be checked directly because the source does not present fixed RPM or TPM limits.

Monitoring and logging

Calls through global inference profiles appear in Bedrock model invocation logging like other on-demand Bedrock Runtime requests. When that logging is enabled, its records include the model or inference-profile identifier and invocation metadata.

Codex emits OpenTelemetry metrics over OTLP/HTTP. CloudWatch Coding Agent Insights can turn that telemetry into views of token usage, API requests, active users, conversation activity, cache hit rate, and optional organizational dimensions. AWS describes two setup paths: Bearer-token authentication and an enterprise rollout.

Under the Bearer approach, a CloudWatch metrics API key is inserted into the Codex configuration alongside the regional metrics endpoint:

[otel]
environment = "production"

[otel.metrics_exporter]
otlp-http = { endpoint = "https://monitoring.ap-southeast-2.amazonaws.com/v1/metrics", protocol = "binary", headers = { "Authorization" = "Bearer YOUR_CLOUDWATCH_METRICS_API_KEY" } }

After replacing the placeholder and starting Codex, telemetry can be viewed in the Sydney CloudWatch console under GenAI Observability, Coding Agent Insights, and the Codex tab. The dashboard shown by AWS includes Codex token and request activity.

Organization, Environment, Department, Cost Center, Location, Team, and User filters can be populated through OTEL_RESOURCE_ATTRIBUTES. The Bearer option carries an important security caveat: AWS classifies the CloudWatch metrics API key as a long-term credential and recommends using it only when short-term AWS credentials are not feasible. The config.toml file must therefore be handled as a secret and given restricted file permissions.

For organizations using corporate single sign-on, AWS recommends the enterprise rollout. In that design, a local collector signs telemetry exports with SigV4 using the developer’s federated credentials, so no shared token has to be distributed.

Conclusion

The Australian Bedrock source endpoints give teams a managed route to three GPT-5.6 profiles without making applications choose their own processing destination. Developers can retain an OpenAI-compatible API integration, use Bedrock’s Converse API through an AWS SDK, or configure Codex to authenticate with temporary federated AWS credentials.

A production deployment still requires explicit preparation: confirm current profile membership, understand cross-Region processing, validate IAM and SCP permissions, evaluate caching with representative prompts, size quotas using the 10:1 output-token burndown, and choose an observability authentication method appropriate to the organization’s security model.

About the authors

The AWS source credits Frank Huang, a Senior AI/ML Specialist Solutions Architect based in Auckland; Sam Zhang, a Security Specialist Technical Account Manager based in Sydney; Melanie Li, a Senior Generative AI Specialist Solutions Architect based in Sydney; Zohreh Norouzi, a Senior Security Solutions Architect; and Saurabh Trikande, a Senior Product Manager for Amazon Bedrock and Amazon SageMaker Inference. Their stated areas of work span AI/ML delivery, infrastructure and generative-AI security, customer solution development, and inference product management.

Source: AWS Machine Learning Blog, Accessing OpenAI models on Amazon Bedrock from Australia with global cross-Region inference.

Definition. GPT-5.6 global cross-Region inference is an Amazon Bedrock arrangement that accepts requests from an Australian source Region and routes them to a supported commercial AWS Region for processing.