AWS Bedrock Says You Have Access to Claude Sonnet 5 and Opus 5. The Quota Says Zero.

TL;DR: If a newer Anthropic model on Bedrock returns AccessDeniedException while every access-related API says you’re fine, look at the Service Quotas, not at IAM. The account carries a per-model tokens-per-minute quota set to zero, and a zero quota surfaces as an access error. You can’t fix it yourself. An AWS account manager escalated our case and got it “approved”, and the models still return AccessDeniedException. A brand-new AWS account starts at zero too.

The AWS forums are full of this one, and the usual answers (check IAM, request model access, try another region) are all wrong.

Background

This is a customer’s AI document-processing pipeline that I developed. It runs on the customer’s AWS account, six months old, mostly in EU regions. Billing has been low throughout development, around $100 a month for four months. Both facts come back later.

The contradiction

The control plane, for Sonnet 5:

authorizationStatus:      AUTHORIZED
entitlementAvailability:  AVAILABLE
regionAvailability:       AVAILABLE
agreementAvailability:    AVAILABLE
ListInferenceProfiles:    ACTIVE

The data plane, same account, same minute:

aws bedrock-runtime converse --region eu-central-2 \
  --model-id eu.anthropic.claude-sonnet-5 \
  --messages '[{"role":"user","content":[{"text":"Reply Y"}]}]' \
  --inference-config '{"maxTokens":1}'

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

Everything green. Nothing works.

The cause: a zero quota

The answer isn’t in the Bedrock APIs. It’s in Service Quotas:

# What your account is actually allowed
aws service-quotas get-service-quota --region eu-central-2 \
  --service-code bedrock --quota-code L-D4FBCF4E --query "Quota.Value"
# -> 0.0

# What AWS publishes as the default for everyone
aws service-quotas get-aws-default-service-quota --region eu-central-2 \
  --service-code bedrock --quota-code L-D4FBCF4E --query "Quota.Value"
# -> 6000000.0

The account carries an explicit override to zero tokens per minute against a published default of six million. A zero quota produces an AccessDeniedException at invoke time. Not a throttling error, not a quota error, an access error. That mismatch is why this is so hard to diagnose.

The get-foundation-model-availability family answers a different question: are you commercially cleared to use the model? Agreement signed, region supported, use-case form on file. It says nothing about whether you’re allowed any throughput. Two independent gates, and the API you’d naturally reach for only shows one.

Quota codes are per model. The ones I checked on the six-month-old account:

Each model also has a separate global cross-region quota, zeroed the same way. Find yours with aws service-quotas list-service-quotas --service-code bedrock and grep for the model name.

It’s a rollout gate, not your setup

Before blaming your configuration, check whether the failure follows a release line. Mine did, cleanly:

An account-specific entitlement problem doesn’t fall along a release line like that. A staged rollout does, and a zero quota is plausibly how AWS implements it. I tested the usual suspects anyway, and none was the cause:

• IAM. iam simulate-principal-policy returns allowed for bedrock:InvokeModel. An IAM denial also reads differently: User ... is not authorized to perform ....
• Region or inference profile. Same denial across five EU regions, from us-east-1 via the us. profile, via the global. profile, and with the bare model ID.
• The model access page. As far as I can tell it’s retired for Anthropic models. Access is granted on first request now.
• The use-case form. On file. put-use-case-for-model-access returns success and persists nothing on an account that already has one. It appears to be write-once. Don’t burn an afternoon on it like I did.
• Flakiness. Deterministic, 6 of 6.
• The marketplace agreement. Check agreementAvailability.status anyway. Each new model ships with its own offer, and it shows NOT_AVAILABLE until you accept it with list-foundation-model-agreement-offers and create-foundation-model-agreement. That gap is real and yours to close. But it’s necessary, not sufficient: on a second account, I accepted the Sonnet 5 offer, the agreement went AVAILABLE within a minute, and the next Converse call was denied as before with the quota still at 0.0.

Three different AccessDeniedExceptions

“Access denied” on Bedrock means at least three unrelated things under the same exception name. Read the message, not the type:

• Your account is currently being verified. Verification normally takes less than 2 hours. New-account verification. Wait. It flickers per model while it propagates.
• Model use case details have not been submitted for this account. The one-time Anthropic use-case form. “Once per account” has a catch: opt-in regions keep their own copy. I submitted it from Zurich (eu-central-2) and calls there worked within a minute, while the console in a standard region still asked for it. Submit it in us-east-1 and in every opt-in region you run in. If you picked Zurich, Milan or Spain for data residency, that’s you.
• anthropic.claude-… is not available for this account. The zero quota. The one this note is about, and the only one you can’t fix yourself.

What you can do

File a service quota increase. It’s free, needs no support plan, and goes to the service team rather than to sales:

aws service-quotas request-service-quota-increase --region eu-central-2 \
  --service-code bedrock --quota-code L-D4FBCF4E --desired-value 6000000

In September this call rejected any value at or below the published default (You must provide a quota value greater than the default quota value of 6000000.0), so asking to be restored to normal wasn’t even expressible. By October it accepted the default. If you get the error, ask for the smallest round number above it. Quotas aren’t billed, only tokens are.

Don’t reach for aws support create-case. On Basic support it fails with SubscriptionRequiredException. That’s also why these cases get closed with “contact Sales”: Basic can’t open a technical case, so it never reaches anyone who can look at a quota.

Don’t trust the request status. A request can close, or even be reported approved, while invocation still fails. CASE_CLOSED in list-requested-service-quota-change-history isn’t “it works”. Trust the applied value, then a real Converse call. Mine closed within minutes to hours, which says the evaluation is automated. The reply is a template:

Thank you for your interest in this model. To maintain service quality and
ensure a reliable experience for all customers, model access for a given
account may depend on factors such as regional availability, account history,
and usage patterns. We are unable to approve your request at this time.
Accessibility is subject to change automatically as time passes.

Meanwhile, pin the newest model you can actually reach and get on with it. A model one generation back that responds beats a model you’re entitled to on paper.

The support case and AWS Sales

We also opened a support case through the console. A human asked for the use case again, I submitted it again, and the answer was the same template. I rated the response accordingly. I can only speculate that the low rating is what prompted an AWS account manager to offer a meeting.

He was punctual, helpful, and confirmed most of what I’d worked out:

• AWS has seen AI-related abuse and is building a system to keep fraud off the platform. It’s still being tuned.
• Abuse often comes from new accounts, days to months old from what I gather. Not our account’s age.
• Billing history is a credibility factor, and $100 a month is low. His advice: use the quota you have from the start, stay consistent, and only then apply for increases.
• High-risk cases cluster around certain kinds of video generation, and higher-tier models are more likely to be abused.
• Processing business documents, including ones containing PII, is not a concern.
• He can vouch for us internally given a closed case ID, a more detailed use case, and company formation documents.
• Final authority lies with the fraud-detection team. If you’re flagged, nothing helps until your trust score reaches the automated threshold.

Separately, Anthropic’s usage policy requires human oversight for consequential decisions, so a system that auto-rejects job applications wouldn’t qualify on that side either. Whether AWS’s gate checks for that, I can’t tell.

Approved. Still denied.

Three days after the meeting I sent everything he asked for: account ID, region, the closed case IDs, a longer use-case description (back-office document processing, a human makes every final decision, no data used for training), and the company’s commercial-register extract. He filed the escalation that afternoon.

On September 24 he wrote back:

Amazing news. I got word today that our request was approved. Could you please check and confirm you have access?

I checked. AccessDeniedException on Sonnet 5, on Opus 5, and on Opus 5.5, released that same day. The applied quota still read 0.0.

That’s weird. But yes, let’s give it some time.

The next day I filed one more quota increase for Sonnet 5. The template came back within hours. Whatever “approved” meant on the account-management side, it never reached the gate that answers your Converse call.

A fresh account is no different

To rule out anything specific to this account, I opened a brand-new AWS account under a different company on October 8. Two days later, with no usage, no history and no requests filed, its quotas looked like this:

The same line, in the same place. A two-day-old account can’t have earned a bad reputation, so the zero isn’t a verdict on anything it did: new accounts start that way, which fits what the account manager described. It also closes the obvious workaround of opening a fresh account. And it isn’t only the expensive models. Haiku 5.5, the cheapest of the newer generation, is zeroed too.

Meanwhile, the model you can reach is being retired

On October 11 the fresh account received an AWS Health notice: Sonnet 4.5 entered the Legacy state on October 8, gets no further quota increases, and goes end-of-life on April 8, 2027. It recommends migrating to the latest Anthropic model and requesting quota for it through Service Quotas.

So the account is told to move off the model it can use and onto the models it’s denied. The deprecation clock and the trust-score clock run on different systems, and nobody checks that the second unlocks before the first runs out. Sonnet 4.6 and Opus 4.6 are still at the default, so there’s somewhere to go for now. If you’re on a gated account, budget for the gap.

One more round

On October 13, with every self-service step done on both accounts (use case on file, Sonnet 5 agreement accepted), I filed the Sonnet 5 increase once more, cross-region and global, at the published default: on the old account in Zurich, and on the fresh account in us-east-1 and Zurich. Six requests. Each closed sixteen minutes after filing, denied with the same template, quotas still at 0.0. The fresh account’s Sonnet 5.5 request the day before had gone the same way.

Lessons learned

• For small companies: don’t build a system that has to reach production soon on a new AWS account. If you can, start on a consultant’s account until your own is unlocked. A freshly opened account won’t help; it starts at zero too.
• Treat an “approved” from account management as a hint, not a result. The only proof is the applied quota value and a real Converse call.
• Escalate early and be persistent. Reaching a human helps your case. Just don’t expect the human to be able to flip the switch.

Case still pending as of October 13, nearly three weeks after “approved”, with no further word from account management since September 24. To be continued.