Bedrock "Error 002: Access to Bedrock models is not allowed for this account" on four Organization member accounts vended the same day; accounts vended one day earlier and three months later work

All Bedrock invocations fail on four member accounts of my AWS Organization with:

ValidationException: Error 002: Access to Bedrock models is not allowed for this account

The distribution of failures looks like a provisioning defect rather than configuration.

The pattern tracks account creation date exactly

Identical test in every case: same region, same model ID, same request body, same Converse call.

Account   Joined Org     Bedrock
-------   ------------   -----------
A         2026-04-11     works
B         2026-04-28     works
C         2026-04-29     Error 002
D         2026-04-29     Error 002
E         2026-04-29     Error 002
F         2026-04-29     Error 002
G         2026-07-20     works

Every account created on 2026-04-29 fails. No account created on any other date fails. The four failing accounts were vended together in a single automated batch.

Not provider-specific

On a failing account, every model family returns Error 002 — including providers with no use-case form or model-access gate:

amazon.nova-lite-v1:0     Error 002
amazon.nova-micro-v1:0    Error 002
(OpenAI model)            Error 002
(xAI model)               Error 002
cohere.embed-v4:0         Error 002   (embeddings, separate code path)
(Anthropic model)         Error 002

Reproduced with both InvokeModel and Converse, with two different IAM Identity Center permission sets (one administrator-level, one power-user-level), and with a role assumed from the management account. Bare and cross-region-inference-profile model IDs behave identically.

Ruled out

• IAM: simulate-principal-policy returns "allowed" for bedrock:InvokeModel, bedrock:Converse and bedrock:ListFoundationModels with the tested region supplied as aws:RequestedRegion.

• SCP: my Org applies an SCP that restricts regions, but it explicitly exempts Bedrock invocation actions, and simulation confirms those actions evaluate as allowed in the tested region. That SCP is demonstrably functioning for other services — a non-exempted service in a non-permitted region returns a normal AccessDeniedException that names the offending policy. Error 002 is a ValidationException and names nothing.

• Anthropic use-case form: present on the affected accounts (get-use-case-for-model-access returns populated formData), and irrelevant regardless, since providers that require no such form fail identically.

• Region: the working accounts succeed in the same region with the same model IDs.

• Model IDs: invalid IDs produce a clearly different error ("The provided model identifier is invalid"). On working accounts, unsupported models produce informative errors ("on-demand throughput isn't supported, use an inference profile"; "marked by provider as Legacy"). Failing accounts never reach that stage.

Every status API reports blocked accounts as healthy

This is what made diagnosis difficult. On an account that cannot invoke anything:

get-foundation-model-availability:
    agreementAvailability.status : NOT_AVAILABLE
    authorizationStatus          : AUTHORIZED
    entitlementAvailability      : AVAILABLE
    regionAvailability           : AVAILABLE

list-foundation-models    : returns 12+ models normally
list-inference-profiles   : all profiles ACTIVE

Three of four availability fields claim the model is usable. agreementAvailability reads NOT_AVAILABLE on my WORKING accounts too, so it does not discriminate either.

Reproduction

cat > body.json <<'EOF'
{"messages":[{"role":"user","content":[{"text":"Reply with exactly: OK"}]}],
 "inferenceConfig":{"maxTokens":32}}
EOF

aws bedrock-runtime converse \
  --region <region> \
  --model-id amazon.nova-lite-v1:0 \
  --cli-input-json file://body.json

ValidationException: Error 002: Access to Bedrock models is not allowed for this account

The identical command against a sibling account in the same Organization returns 200.

Questions

1. What does Error 002 mean at the service level? The evidence points to an account-wide Bedrock entitlement flag set at provisioning time, independent of model access, use-case forms, IAM and SCPs.

2. Is this a known defect for accounts vended in a particular window? Four-for-four on a single date with zero failures on any other date seems like a strong signal.

3. Why ValidationException rather than AccessDeniedException? It carries no remediation path and is easily mistaken for a model-access problem.

4. Is there any API that reports whether Bedrock is enabled for an account at all? Every read path returns healthy on a fully blocked account.

5. Can this be self-resolved, or does it require Support to enable Bedrock per account?

I can provide account IDs and the exact region privately to AWS staff or via a Support case.