Claude Opus 5 returns “not available for this account” despite AVAILABLE agreement, entitlement, authorization and region

We are trying to use Claude Opus 5 on Amazon Bedrock from Asia Pacific (Sydney), ap-southeast-2.

The Australian inference profile is visible and active:

au.anthropic.claude-opus-5

We also tested:

global.anthropic.claude-opus-5

Both runtime invocations fail with:

AccessDeniedException: anthropic.claude-opus-5 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales.

However, the Bedrock control-plane access checks now show that all required availability conditions are satisfied.

Running:

aws bedrock get-foundation-model-availability
--region ap-southeast-2
--model-id anthropic.claude-opus-5

returns:

{ "modelId": "anthropic.claude-opus-5", "agreementAvailability": { "status": "AVAILABLE" }, "authorizationStatus": "AUTHORIZED", "entitlementAvailability": "AVAILABLE", "regionAvailability": "AVAILABLE" }

We also successfully created the foundation-model agreement using:

aws bedrock create-foundation-model-agreement
--region ap-southeast-2
--model-id anthropic.claude-opus-5
--offer-token "<offer-token>"

The command completed successfully and returned:

{ "modelId": "anthropic.claude-opus-5" }

The agreement initially showed PENDING and later changed to AVAILABLE.

We then tested actual invocation through Bedrock Runtime using the Converse API.

Example:

import boto3

client = boto3.client( "bedrock-runtime", region_name="ap-southeast-2" )

response = client.converse( modelId="au.anthropic.claude-opus-5", messages=[ { "role": "user", "content": [ {"text": "Reply exactly OK"} ] } ], inferenceConfig={ "maxTokens": 8, "temperature": 0 } )

This still returns:

AccessDeniedException: anthropic.claude-opus-5 is not available for this account.

We also tested the global profile:

global.anthropic.claude-opus-5

and received the same account-level error.

For comparison, the same AWS account, environment and Bedrock Runtime setup successfully invokes:

au.anthropic.claude-opus-4-6-v1

with a normal successful response.

We also tested newer Claude models and observed the following:

Model Agreement Authorization Region Runtime invoke Claude Opus 4.6 AVAILABLE AUTHORIZED AVAILABLE PASS Claude Opus 4.7 NOT_AVAILABLE AUTHORIZED AVAILABLE FAIL Claude Opus 4.8 NOT_AVAILABLE AUTHORIZED AVAILABLE FAIL Claude Sonnet 5 AVAILABLE AUTHORIZED AVAILABLE FAIL Claude Opus 5 AVAILABLE AUTHORIZED AVAILABLE FAIL

For Sonnet 5, all relevant control-plane fields also showed available/authorized, but runtime invocation still returned:

anthropic.claude-sonnet-5 is not available for this account

This suggests there may be an account-level runtime access restriction that is not represented by get-foundation-model-availability.

Questions Is Claude Opus 5 currently subject to a staged rollout, usage-history requirement, runtime allowlist, capacity gate, or other account-level eligibility restriction on Amazon Bedrock? Can get-foundation-model-availability return: agreement = AVAILABLE authorization = AUTHORIZED entitlement = AVAILABLE region = AVAILABLE

while the account is still excluded from runtime model access?

If so, how can a customer on AWS Basic Support request enablement for: au.anthropic.claude-opus-5 Is there any additional Marketplace, Anthropic, Bedrock, billing or account prerequisite that is not exposed through get-foundation-model-availability? Is there a recommended escalation path for Basic Support customers when AWS Sales cannot investigate account-level Bedrock model access?

We are specifically interested in Australian processing through the AU geographic inference profile, but the same failure also occurs with the Global Opus 5 profile.

Any clarification from AWS or other customers who have encountered the same situation would be appreciated.