AWS Bedrock Model Not Available in Region — ValidationException Fix (2026) | AI Error Hub
AWS Bedrock Routing · Region Severity: Medium HTTP 400

AWS Bedrock Model Not Available in Region

The Bedrock SDK returns ValidationException or ResourceNotFoundException because the foundation model you asked for hasn't launched in the region your client is targeting. Anthropic Claude Opus 4.7, Nova Reel, and Meta Llama 4 all have selective regional rollouts — us-east-1 first, us-west-2 within weeks, other regions months later.

Provider: AWS Bedrock Category: Routing · Region First seen: 2023-09 (Bedrock GA) Last verified: Jul 22, 2026

Quick Fix (TL;DR)

TL;DR

Call list_foundation_models() in the target region to confirm what's actually available, then either switch to a cross-region inference profile (prefix us., eu., apac.) that routes your call to a region where the model exists, or fall back to a similar model that's already GA in your region. ~65% of these errors are new-model launches not yet reaching the target region; 25% are typos where the region ID is subtly wrong; 10% are legacy models that were withdrawn from that region.

The Full Error Message

Validation error — model requires inference profile
botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the Converse operation: Invocation of model ID anthropic.claude-opus-4-7-20260315-v1:0 with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.
Resource not found — model does not exist in this region
botocore.exceptions.ClientError: An error occurred (ResourceNotFoundException) when calling the InvokeModel operation: Could not resolve the foundation model from the provided model identifier.
Legacy model withdrawn
botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the Converse operation: The model anthropic.claude-instant-v1 is no longer available for on-demand invocation. Migrate to anthropic.claude-haiku-4-5-20251001-v1:0 or a similar model.

Foundation Model Regional Availability (Nov 2026 Snapshot)

A partial snapshot — check the console or list_foundation_models for the current authoritative list. AWS updates availability weekly.

Modelus-east-1us-west-2eu-west-1ap-northeast-1On-demand?
anthropic.claude-sonnet-4-6YesYesYesYesYes
anthropic.claude-opus-4-7YesYesNoNoProfile only
anthropic.claude-haiku-4-5YesYesYesYesYes
amazon.nova-pro-v1:0YesYesYesYesYes
amazon.nova-reel-v1:0YesNoNoNoYes
meta.llama4-70b-instructYesYesNoNoYes
mistral.large-2-latestYesYesYesNoYes
cohere.command-r-plus-v1:0YesYesYesNoYes

Cross-Region Inference Profile Prefixes

When a model requires an inference profile, prefix the model ID with a geography code and the SDK routes across all member regions.

PrefixGeographyTypical Member Regions
us.United Statesus-east-1, us-west-2, us-east-2
eu.Europeeu-west-1, eu-west-2, eu-central-1
apac.Asia Pacificap-northeast-1, ap-southeast-1, ap-southeast-2

Root Causes (Ranked by Frequency)

40%
Model launched in fewer regions than your target. New models roll out us-east-1 first, then us-west-2, then EU. If you're in eu-west-2 and the model launched last week, it may not be there yet.
25%
Model requires an inference profile, not direct invocation. Newer premium models (Claude Opus 4.7, some Nova tiers) are gated to cross-region inference profiles only — the error is ValidationException, not ResourceNotFoundException.
12%
Region ID typo. us-east-1a (that's an AZ, not a region) or us-east-la (letter L instead of 1) slip past linters.
8%
Legacy model withdrawn from that region. anthropic.claude-instant-v1 was pulled from all regions in 2025; older code targeting it fails.
7%
Client region pinned in code, environment says otherwise. Code explicitly sets region_name="us-east-1", but the deployment expected the container's AWS_REGION env var to win.
5%
Model ID version suffix stale. Using anthropic.claude-sonnet-4-6-20250929-v1:0 after AWS bumped the version to ...v2:0.
3%
Marketplace model unsubscribed. Some third-party models require a Marketplace subscription in the target region separately from the model access grant.

Fix #1 — Confirm What's Actually Available in the Target Region

FIX 1One API call answers "does this model exist here?" definitively.

The list_foundation_models API is authoritative — it reflects the exact set of models the caller can invoke in the specified region. Run it once per environment as part of your startup health check, cache the result for 24 hours, and fail fast if a required model is missing.

audit_regional_availability.py
import boto3
from botocore.exceptions import ClientError

REGIONS_TO_CHECK = ["us-east-1", "us-west-2", "eu-west-1", "eu-west-2", "ap-northeast-1"]

REQUIRED_MODELS = [
    "anthropic.claude-sonnet-4-6-20250929-v1:0",
    "anthropic.claude-haiku-4-5-20251001-v1:0",
    "amazon.nova-pro-v1:0",
]

def audit():
    print(f"{'Region':<18}{'Model':<50}Status")
    print("-" * 88)
    for region in REGIONS_TO_CHECK:
        bedrock = boto3.client("bedrock", region_name=region)
        try:
            available = {
                m["modelId"] for m in bedrock.list_foundation_models()["modelSummaries"]
            }
        except ClientError as e:
            print(f"{region:<18}<Bedrock control plane unreachable> {e.response['Error']['Code']}")
            continue

        for model in REQUIRED_MODELS:
            status = "OK" if model in available else "MISSING"
            print(f"{region:<18}{model:<50}{status}")

if __name__ == "__main__":
    audit()

Sample output line to look for: us-east-1 anthropic.claude-opus-4-7-20260315-v1:0 MISSING. If the model shows up in list_foundation_models but invocation still fails with "isn't supported", the model is available but requires an inference profile — see Fix #2.

Fix #2 — Switch to a Cross-Region Inference Profile

FIX 2Route through the geography that has the model without pinning a specific region.

For models like Claude Opus 4.7 that are only available via inference profiles, prefixing the model ID with us., eu., or apac. tells Bedrock to route the call to whichever member region has capacity. The client region still matters for latency and data residency, but the model access must be granted in every member region of the profile.

use_inference_profile.py
import boto3
from botocore.exceptions import ClientError

REGION = "us-east-1"

# Direct model ID — fails with ValidationException for Opus 4.7:
BAD_MODEL_ID = "anthropic.claude-opus-4-7-20260315-v1:0"

# Cross-region inference profile — routes across us-east-1, us-west-2, us-east-2:
GOOD_PROFILE_ID = "us.anthropic.claude-opus-4-7-20260315-v1:0"

runtime = boto3.client("bedrock-runtime", region_name=REGION)

def try_direct():
    try:
        runtime.converse(
            modelId=BAD_MODEL_ID,
            messages=[{"role": "user", "content": [{"text": "hi"}]}],
            inferenceConfig={"maxTokens": 1},
        )
    except ClientError as e:
        code = e.response["Error"]["Code"]
        msg = e.response["Error"]["Message"]
        print(f"Direct invoke   : {code} - {msg[:80]}")

def try_profile():
    try:
        resp = runtime.converse(
            modelId=GOOD_PROFILE_ID,
            messages=[{"role": "user", "content": [{"text": "hi"}]}],
            inferenceConfig={"maxTokens": 5},
        )
        used = resp["usage"]
        print(f"Profile invoke  : OK  in={used['inputTokens']} out={used['outputTokens']}")
    except ClientError as e:
        print(f"Profile invoke  : {e.response['Error']['Code']}")
        print("--> Grant access to Anthropic in EVERY member region of the profile")
        print("    (us-east-1, us-west-2, us-east-2).")

if __name__ == "__main__":
    try_direct()
    try_profile()

Model access requirement for profiles: the caller must have model access granted in every member region of the profile, not just the region the SDK connects to. If us.anthropic.claude-opus-4-7 can route to us-east-1, us-west-2, and us-east-2, request Anthropic access in all three regions or you'll see intermittent AccessDeniedException depending on where the traffic lands.

Fix #3 — Graceful Fallback When the Preferred Model Is Missing

FIX 3A resolver that picks the best available model per region.

For applications deployed to multiple regions, the "best" model isn't always available everywhere. This resolver takes a preference list, checks availability per region, and returns the highest-preference model that's actually usable. Wire it into your app's startup and re-check on cache TTL.

model_resolver.py
import boto3
import time
from functools import lru_cache

# Preference order — most capable to least capable.
PREFERENCES = [
    "anthropic.claude-opus-4-7-20260315-v1:0",
    "anthropic.claude-sonnet-4-6-20250929-v1:0",
    "anthropic.claude-haiku-4-5-20251001-v1:0",
    "amazon.nova-pro-v1:0",
]

# Which of these are ONLY available via inference profile?
PROFILE_ONLY = {
    "anthropic.claude-opus-4-7-20260315-v1:0": "us.anthropic.claude-opus-4-7-20260315-v1:0",
}

# 24-hour cache — availability changes infrequently.
_CACHE_TTL = 24 * 3600
_cache = {}

def resolve(region: str) -> str:
    """Return the highest-preference model ID actually invokable in this region."""
    now = time.time()
    if region in _cache and now - _cache[region][1] < _CACHE_TTL:
        return _cache[region][0]

    bedrock = boto3.client("bedrock", region_name=region)
    available = {
        m["modelId"] for m in bedrock.list_foundation_models()["modelSummaries"]
    }

    for model in PREFERENCES:
        if model in available:
            # If profile-only, return the profile ID.
            chosen = PROFILE_ONLY.get(model, model)
            _cache[region] = (chosen, now)
            return chosen

    raise RuntimeError(f"No preferred model available in {region}")

if __name__ == "__main__":
    for region in ["us-east-1", "eu-west-1", "ap-northeast-1"]:
        chosen = resolve(region)
        print(f"{region:<20}--> {chosen}")

Observability: emit a CloudWatch custom metric each time resolve() returns a non-primary model — a spike means your preferred model was withdrawn or removed from a region, worth investigating.

Prevention Checklist

  • Bake a list_foundation_models check into your service startup — fail the pod/container if a required model is missing rather than failing at first request.
  • Maintain a per-region availability matrix in your infra repo — update weekly from the AWS blog's Bedrock announcements.
  • Prefer cross-region inference profiles (us., eu., apac.) over pinned model IDs — better resilience to regional launches and outages.
  • Include the full model version suffix (v1:0, v2:0) in all model ID strings — never trust that a bare model name will resolve.
  • Set CloudWatch alarms on ValidationException from Bedrock — a sudden onset usually indicates a model version bump or regional withdrawal.
  • Deploy multi-region services with a resolver pattern (Fix #3) — no hard-coded model IDs per deployment.
  • Subscribe to the AWS Bedrock announcements RSS feed — regional availability changes are announced there before they appear in docs.

Tested by

Frequently Asked Questions

The error text is the tell: 'Invocation of model ID X with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model' means the direct model ID is not accepted.

Prefix the model ID with the appropriate geography code — us., eu., or apac. — to convert it to a profile ID. The Bedrock console also shows an "Inference profile required" badge on the model page.

Two causes:

  1. The caller doesn't have bedrock:ListFoundationModels permission on all model families — the API respects IAM but the console runs under your admin identity.
  2. The model is available but requires an inference profile, in which case list_inference_profiles is where it appears, not list_foundation_models.

Always call both APIs when auditing.

No. Per-token pricing is identical whether you invoke via direct model ID or via a cross-region inference profile. AWS routes the call to the region with capacity but bills at the model's on-demand rate.

The only cost difference comes from data-transfer if the routed region is far from your client, which is rare because profiles route within a geography.

AWS provides at least 60 days notice via email to the account root, an AWS Health Dashboard event, and a blog post. During that window, calls still succeed but a deprecation warning appears in CloudTrail.

After the deprecation date, calls fail with ValidationException including a suggested replacement model ID. Monitor AWS Health events for keyword BEDROCK_MODEL_DEPRECATION and update your resolver's PREFERENCES list ahead of the cutoff.

You can — by creating a boto3 client for the destination region and calling it directly — but you take on the region's IAM, latency, and data-residency implications.

Inference profiles are the AWS-supported abstraction: they handle authentication propagation, region routing, and quota aggregation. Manual cross-region invocation is only worth it when you need to pin a specific region for compliance and want to skip the abstraction.

Related Errors

Never get blindsided by an AI provider error again.

Every Tuesday, get the week's newest AWS Bedrock, Anthropic, OpenAI, and Gemini errors — with tested fixes — delivered to your inbox. Free, no spam, unsubscribe with one click.

Last verified Jul 22, 2026 · AWS Bedrock is a trademark of Amazon Web Services · AI Error Hub is not affiliated with AWS.

This is a title