AWS Bedrock AccessDeniedException on Claude: Every Fix

AccessDeniedException when invoking Claude models on AWS Bedrock almost always traces back to one of three separate gates that all have to open at the same time: the IAM invocation permission, the AWS Marketplace subscription that gets created on your first call, and the Anthropic First-Time-Use form. But here is the part almost nobody tells you: the most common cause is not IAM at all — it is the automatic Marketplace subscription failing silently because your IAM role lacks two specific aws-marketplace: permissions that have nothing to do with Bedrock. Your policy can be perfect for bedrock:InvokeModel and the call still fails, because Bedrock tried to subscribe you to Claude as a third-party Marketplace product and your role was not allowed to subscribe.

That three-gate architecture — IAM permission, Marketplace subscription, Anthropic FTU form — is what makes this error so maddening. Each gate produces the same error message, each gate has a different fix, and the error text does not tell you which gate is closed. A developer can fix one, hit the same error from the next gate, conclude the first fix did not work, and start undoing correct changes. This guide walks every gate in the order you are statistically most likely to hit them, with the exact CLI command or console step that opens each one.

The second thing worth internalizing: Claude on AWS Bedrock is a third-party model offered and billed through AWS Marketplace. Charges appear on your AWS bill under the model provider (Anthropic), not under Amazon Bedrock. This is not a technical footnote — it is the reason the Marketplace subscription gate exists at all, and it is why the invocation path for Claude has permissions requirements that Amazon's own Nova and Titan models do not.

What the Error Actually Says (and What Each Variant Points To)

Before debugging, read the full error message — the variants point at different causes:

• "AccessDeniedException: Model access is denied due to IAM user or service role is not authorized to perform the required AWS Marketplace actions (aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe) to enable access to this model." — The automatic Marketplace subscription is failing. This is Cause 1, and the error names the exact permissions you need.
• "AccessDeniedException: Model access is denied due to [IAM-ARN] is not authorized to perform: aws-marketplace:Subscribe on resource: * because no identity-based policy allows the action." — Same cause, more specific: your IAM entity specifically lacks the Subscribe action.
• "AccessDeniedException ... You don't have access to the model with the specified model ID." — The model is not activated for your account, or you are using the wrong model ID, or the model is not available in your region.
• "Access denied when calling Bedrock. Check your request permissions and retry the request." — Generic form; walk the full diagnostic.
• "AccessDeniedException ... contact AWS Sales" — Account-level entitlement restriction. IAM cannot fix this; AWS Support has to.
• "Too many tokens per day / Too many requests" — Not an AccessDeniedException, but often confused with one. This is quota throttling (Cause 6).

One more thing the error never tells you: whether it is the first invocation or a subsequent one. The first invocation triggers the Marketplace subscription; subsequent invocations do not. This is why an admin invoking the model once fixes it for everyone — the subscription is account-level, not role-level.

The 60-Second Diagnostic (Three Commands, Settled)

Three commands, sixty seconds, and the gate question is largely settled:

1. Confirm who is calling and from where.

   aws sts get-caller-identity

   Prints the ARN, account, and role making the request. Wrong account, wrong profile, wrong role — ruled in or out instantly.

2. Confirm the model exists in your region.

   aws bedrock list-foundation-models \
     --region us-east-1 \
     --query "modelSummaries[?modelId.contains(@, 'claude')].modelId"

   If Claude model IDs do not appear in your region's list, the model is not available there, or your account cannot see it — Cause 4 territory.

3. Attempt the invocation with full debug output.

   aws bedrock invoke-model \
     --model-id anthropic.claude-sonnet-4-20250514-v1:0 \
     --region us-east-1 \
     --content-type application/json \
     --accept application/json \
     --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":10,"messages":[{"role":"user","content":"hi"}]}' \
     /dev/null

   The error message from this call — the full text, not just the code — tells you which gate is closed. Read it against the variants above.

With those three results, walk the ordered causes below.

Cause 1: The Marketplace Subscription — The Silent First-Invocation Gate

This is the cause behind the majority of Claude-on-Bedrock AccessDeniedException reports, and it is the one that confuses people the most because it has nothing to do with Bedrock permissions.

Here is the mechanism. Claude models on Bedrock are third-party models offered through AWS Marketplace. When you invoke a Claude model for the first time in your account, Bedrock automatically initiates a Marketplace subscription — a $0 subscription, but a subscription nonetheless, with all the Marketplace machinery behind it. If the IAM role making that first request does not have the required Marketplace permissions, the automatic subscription fails. Subsequent invocations return AccessDeniedException because the model is not subscribed for your account.

The two permissions the subscription requires:

• aws-marketplace:Subscribe
• aws-marketplace:ViewSubscriptions

Neither of these appears in any Bedrock-focused IAM policy, because neither of them is a Bedrock action. They are Marketplace actions that Bedrock triggers on your behalf.

The fix

Attach the Marketplace permissions to the IAM entity that invokes the model:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:Subscribe",
        "aws-marketplace:ViewSubscriptions"
      ],
      "Resource": "*"
    }
  ]
}

Then retry the invocation. After you grant the permissions, it can take up to 2 minutes for the subscription to complete — during which you may continue to see the error before it clears.

The admin shortcut

If you cannot or do not want to grant Marketplace permissions to every user and role in your account, there is a documented alternative: have an administrator with the Marketplace permissions invoke the model once. After the first successful invocation creates the account-level subscription, all IAM roles in the account can invoke the model without the Marketplace permissions. The gate opens once, for everyone.

Why Amazon's own models do not hit this

Amazon's first-party models (Nova, Titan) do not require Marketplace permissions because they are not offered through AWS Marketplace. The Marketplace gate applies to third-party models — Anthropic, AI21 Labs, and similar — which are billed through the Marketplace infrastructure even though the per-token charges appear on your regular AWS bill.

Cause 2: The Anthropic First-Time-Use Form

Anthropic requires a one-time use-case submission — the First-Time-Use (FTU) form — before any Anthropic model can be invoked on your account. This is separate from the Marketplace subscription and separate from IAM, and it only applies to Anthropic models: Amazon, Meta, Mistral, and other providers do not have this requirement.

In the console, the form appears when you first attempt to use an Anthropic model — it asks for your use case details and, for some regions outside the US, requires a valid payment instrument on the account even though the subscription itself is free. This has produced a wave of AccessDeniedException reports from users in regions where the payment-instrument check fails on new or free-tier accounts.

The programmatic path

For CI/CD or automated setups, the FTU form can be submitted via the CLI:

aws bedrock put-use-case-for-model-access \
  --model-id anthropic.claude-sonnet-4-20250514-v1:0 \
  --use-case "Transactional customer support automation for our e-commerce platform"

For organizations, the FTU form is submitted once per account or once per AWS Organization — member accounts inherit the parent's submission.

Cause 3: Missing IAM Invocation Permissions

The boring cause that every guide covers — but with details most get wrong. The invocation permission is not just bedrock:InvokeModel:

• If your code uses streaming (and most modern integrations do), you need bedrock:InvokeModelWithResponseStream — a separate action. A policy that only grants InvokeModel works for non-streaming calls and fails the moment the SDK switches to streaming.
• If your code uses the Converse API (the newer, cleaner API), you need bedrock:Converse and bedrock:ConverseStream.
• If your code uses cross-region inference profiles, you also need bedrock:GetInferenceProfile and bedrock:ListInferenceProfiles — permissions that are easy to miss because they are not invocation actions.

The complete documented permission set for model inference:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ModelInvocationPermissions",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:Converse",
        "bedrock:ConverseStream",
        "bedrock:GetInferenceProfile",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetFoundationModel",
        "bedrock:ListFoundationModels"
      ],
      "Resource": "*"
    }
  ]
}

For tighter scoping, replace "Resource": "*" with the specific foundation-model ARNs you want to allow — but note that cross-region inference profiles use a different ARN pattern (inference-profile/ rather than foundation-model/), so a policy scoped only to foundation-model ARNs will deny inference-profile invocations.

Cause 4: Wrong Model ID or Wrong Region

Claude model IDs on Bedrock follow a specific pattern, and getting any part of it wrong produces the "You don't have access to the model with the specified model ID" variant of the error:

Three failure modes with model IDs:

• Using the Anthropic API model name (claude-sonnet-4-20250514) instead of the Bedrock model ID (anthropic.claude-sonnet-4-20250514-v1:0) — the formats differ, and Bedrock does not auto-correct.
• Using a model ID from a different region's availability list — not every Claude model is available in every region, and invoking a model ID that does not resolve in your region produces the access-denied variant.
• Version drift — Claude model versions are retired and replaced; an old tutorial's model ID may no longer resolve.

The 10-second test

aws bedrock list-foundation-models --region us-east-1 \
  --query "modelSummaries[?modelId.contains(@, 'claude')].{ID:modelId,Lifecycle:modelLifecycle.status}"

This lists every Claude model ID available in your region, with its lifecycle status. Copy the exact ID from this output — not from a tutorial, not from memory — and retry.

Cause 5: Cross-Region Inference Profiles Blocked by SCPs

If your code uses a cross-region inference profile (the us.anthropic.* model IDs), you hit a distinct failure mode that does not exist for in-region calls:

If any destination Region in a cross-Region inference profile is blocked in your SCPs, the request fails even if other Regions remain allowed.

A US cross-region inference profile for Claude routes requests across multiple US regions — us-east-1, us-east-2, us-west-2, and others. Your organization's SCPs may restrict which regions your account can operate in (a common Control Tower or Landing Zone configuration), and if any of the profile's destination regions is on the deny list, the entire invocation fails with AccessDeniedException — even if your source region and your preferred destination are both allowed.

This is the cause that most often fools experienced AWS engineers: everything about the account looks correct, the model is subscribed, the IAM policy is perfect, and the call still fails. The SCP region restriction is invisible from the IAM console and from the Bedrock console — it lives in the Organizations layer.

The fix

Update your SCP to either allow all Bedrock actions regardless of region, or to exempt Bedrock from the region restriction. The documented pattern for exempting Bedrock from a region-restriction SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2"
          ]
        }
      }
    }
  ]
}

The "NotAction": "bedrock:*" exempts all Bedrock actions from the region restriction, while other services remain restricted. A tighter variant scopes the exemption to only the inference-profile invocation path.

For accounts under Control Tower, the specific challenge: inference profiles require permissions in regions your Control Tower configuration may block by default, and the exemption has to be added to the SCP guarding the account, not to the IAM role.

Cause 6: Zero Quota on New Accounts

A provisioning issue that has hit a wave of new AWS accounts: Bedrock service quotas set to zero across all models and regions, despite the documentation describing default quotas in the thousands of tokens per minute. The account is provisioned at 0, every request is rejected instantly, and the error can masquerade as an access denial.

The signature: the error says "Too many tokens per day" or "Too many requests" rather than a clean AccessDeniedException, but the underlying cause is the zero quota — and no amount of IAM editing or Marketplace subscribing fixes a quota of zero.

The check

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --region us-east-1 \
  --query "Quotas[?contains(QuotaName, 'tokens')].{Name:QuotaName,Value:Value}"

If the tokens-per-minute quotas all show 0, your account hit the provisioning issue.

The fix

This requires AWS Support to manually provision the quotas at the account level — it is not something you can fix from the console or the CLI. Open a support case with the specific message: "All Bedrock applied quotas show 0 across all regions and models. Please provision the default quotas for this account." Reference the known issue if the first-line responder is unfamiliar with it.

Cause 7: Account-Level Entitlement Restrictions ("Contact AWS Sales")

If the error message includes the phrase "contact AWS Sales", the model has an account-level entitlement restriction. This is the rarest cause and the only one that is entirely outside your control:

• It cannot be resolved with IAM permissions
• It cannot be resolved with an SCP update
• It cannot be resolved by changing model access on the Bedrock console
• It does not appear in the Service Quotas console

The documented path: confirm you have the IAM permissions, the Marketplace permissions, a valid payment method, and the Anthropic FTU form completed. If all prerequisites are met and you still get "contact AWS Sales," the restriction is on AWS's side, and the fix is a support case.

Cause 8: Invalid Payment Instrument

A specific variant reported on new and free-tier accounts: the Marketplace subscription (even at $0) performs a validation check on the account's payment method, and if the payment instrument is invalid, missing, or fails the check, the subscription cannot complete. This surfaces as an AccessDeniedException or as an INVALID_PAYMENT_INSTRUMENT error, depending on where in the flow it fails.

The fix: ensure the AWS account has a valid, chargeable payment method — even though the Claude subscription itself costs nothing to create. Free-tier accounts without a payment method on file hit this wall; adding a card resolves it.

Cause 9: VPC Endpoint Policy Filtering

If your Bedrock invocations originate from inside a VPC with an interface endpoint for Bedrock (AWS PrivateLink), the endpoint's policy can restrict which Bedrock actions and resources are allowed — and a filtering of the bedrock-runtime endpoint can deny InvokeModel calls independently of IAM.

The signature: invocations work from outside the VPC but fail from inside it. Same role, same model, same everything — only the network path differs.

The check: aws ec2 describe-vpc-endpoints for the Bedrock endpoint, then read the endpoint policy for Deny statements or Resource restrictions that exclude your model ARNs.

Every Cause at a Glance, in Order

Programmatic Model Activation: The CI/CD Path

For teams provisioning accounts through pipeline automation — Landing Zone, Control Tower, Terraform — the model activation step can be done programmatically instead of through the console:

1. Submit the FTU form for Anthropic models (required before any Claude activation):

   aws bedrock put-use-case-for-model-access \
     --model-id anthropic.claude-sonnet-4-20250514-v1:0 \
     --use-case "Automated customer support responses"

2. Get the offer token:

   aws bedrock list-foundation-model-agreement-offers \
     --model-id anthropic.claude-sonnet-4-20250514-v1:0

   Note the offer token from the output.

3. Create the agreement (activates the model):

   aws bedrock create-foundation-model-agreement \
     --model-id anthropic.claude-sonnet-4-20250514-v1:0 \
     --offer-token example-offer-token

This is the path for organizations that need to activate the same models across many accounts without a human clicking through each console. The IAM entity running these commands needs the Marketplace permissions covered in Cause 1, plus the bedrock:PutUseCaseForModelAccess, bedrock:ListFoundationModelAgreementOffers, and bedrock:CreateFoundationModelAgreement actions.

Setting Up Claude Code with AWS Bedrock (And Why It Hits This Error Too)

Claude Code — Anthropic's CLI coding agent — can be configured to use AWS Bedrock as its backend instead of Anthropic's direct API. The setup is environment-variable based:

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export ANTHROPIC_MODEL="anthropic.claude-sonnet-4-20250514-v1:0"

When Claude Code invokes Bedrock, it goes through the same bedrock-runtime endpoint, uses the same model IDs, and hits the same three gates — Marketplace subscription, FTU form, IAM permissions — as any other Bedrock integration. The error message surfaces in Claude Code's output as an AccessDeniedException, and the diagnostic is identical to the one above.

Two Claude Code-specific gotchas worth knowing:

• The credential chain matters. Claude Code uses the standard AWS credential chain — environment variables, config file, instance profile — and if the credentials it finds differ from the ones you tested with, the failure is a credential-context problem, not a Bedrock problem.
• Claude Code uses streaming by default. If your IAM policy only grants bedrock:InvokeModel (not InvokeModelWithResponseStream), Claude Code will fail with AccessDeniedException even though a non-streaming test call succeeds.

For readers new to Bedrock entirely, our guide on what Amazon Bedrock is in plain English covers the service from zero — what it does, what it costs, and how it fits alongside the other AI services in AWS.

Admins: Preventing AccessDeniedException Across a Fleet

For platform teams provisioning accounts and managing Bedrock access at scale:

1. Bake the Marketplace permissions into your account bootstrap. Every account that will touch Bedrock should have the aws-marketplace:Subscribe and aws-marketplace:ViewSubscriptions permissions in its baseline IAM policy — not added reactively after the first failure. This is the single highest-ROI prevention.
2. Run the programmatic activation in your account pipeline. The put-use-case-for-model-access → list-foundation-model-agreement-offers → create-foundation-model-agreement sequence can be a Lambda step in your Landing Zone account provisioning, eliminating the human-gate entirely.
3. Grant all four invocation actions by default. InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream — plus the inference-profile read actions. Tightening to specific models can come later, after things work.
4. If you use SCPs for region control, exempt Bedrock explicitly. The cross-region inference profile failure mode (Cause 5) is invisible until production traffic hits it, and the fix is an SCP change that requires Organizations-level access the application team may not have.
5. For Anthropic, submit the FTU form at the organization level. One submission per org covers all member accounts, eliminating the per-account form problem entirely.

For teams watching costs while they scale, our guide on Bedrock pricing and token cost reduction covers the pricing model and where the savings actually are.

When Nothing Works: The Honest End of the Road

If all nine causes are ruled out — Marketplace subscribed, FTU submitted, IAM correct, model ID valid, region available, SCP clear, quota nonzero, payment valid, no VPC endpoint blocking — then the remaining possibilities are the platform-side ones: an entitlement restriction (Cause 7, requiring support), a regional service incident, or a provisioning bug on the account that only AWS can see.

The escalation path: open an AWS Support case with the exact error text, the request ID from the response headers (visible with --debug on the CLI or in SDK error objects), the model ID, the region, and the caller ARN from aws sts get-caller-identity. With the request ID, support can trace exactly where in the evaluation the request failed — something no amount of client-side debugging can reach.

Frequently Asked Questions

How do I fix AccessDeniedException when invoking Claude on AWS Bedrock?

Start with the two most common causes: attach aws-marketplace:Subscribe and aws-marketplace:ViewSubscriptions permissions to your IAM role (the automatic Marketplace subscription needs them), and submit the Anthropic First-Time-Use form. Then verify bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream are in your policy. Wait up to 2 minutes after fixing permissions for the subscription to complete.

Why does my IAM policy work for Bedrock but still get AccessDeniedException for Claude?

Because Claude is a third-party model offered through AWS Marketplace, and the first invocation triggers an automatic Marketplace subscription that requires aws-marketplace:Subscribe — a permission no standard Bedrock policy includes. Fix: add the Marketplace permissions, or have an admin invoke the model once to create the account-level subscription.

What IAM permissions do I need for AWS Bedrock?

For model invocation: bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:Converse, bedrock:ConverseStream, plus bedrock:GetInferenceProfile and bedrock:ListInferenceProfiles for cross-region inference. For Claude specifically, also add aws-marketplace:Subscribe and aws-marketplace:ViewSubscriptions for the first invocation.

Do I need to enable Claude models in the Bedrock console?

Access to all Bedrock foundation models is enabled by default with the correct AWS Marketplace permissions — the old manual enablement page is no longer the primary gate. However, Anthropic models require the one-time First-Time-Use form before invocation, and the first invocation creates the Marketplace subscription automatically.

What is the Anthropic FTU form on Bedrock?

The First-Time-Use form — a one-time per-account use-case submission Anthropic requires before any Claude model can be invoked on Bedrock. Submit it through the console when prompted, or programmatically via the put-use-case-for-model-access CLI command. For Organizations, one submission covers all member accounts.

Why does Claude work in us-east-1 but fail in us-west-2?

Model access on Bedrock is per-region: a Marketplace subscription created in us-east-1 does not automatically exist in us-west-2. Invoke the model once in each region you use (with the correct permissions), or use the programmatic activation commands. Also check that the specific Claude model is available in that region at all.

How do I activate Claude models on Bedrock programmatically?

Three steps: submit the FTU form (aws bedrock put-use-case-for-model-access), get the offer token (aws bedrock list-foundation-model-agreement-offers), and create the agreement (aws bedrock create-foundation-model-agreement). The IAM entity running these needs the Marketplace permissions plus the agreement API actions.

Why does Bedrock say I don't have access to a model when get-foundation-model-availability says AUTHORIZED?

The entitlement API reports availability, not activation. A model can be listed as available for your account while the Marketplace subscription or the FTU form has not been completed — the invocation still fails. Walk the full diagnostic: Marketplace permissions, FTU form, IAM invocation permissions, in that order.

What is the difference between bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream?

InvokeModel covers non-streaming request-response calls. InvokeModelWithResponseStream covers streaming responses (where tokens arrive progressively). Many SDKs and tools — including Claude Code — default to streaming, so a policy granting only InvokeModel will fail for streaming calls with AccessDeniedException. Grant both.

Why does cross-region inference fail when in-region works?

Cross-region inference profiles route requests across multiple regions, and if any destination region is blocked by your Organizations SCP, the entire request fails — even if your source region is allowed. Fix: exempt bedrock:* from the region-restriction SCP, or use in-region model IDs instead of cross-region inference IDs.

Can I use Claude Code with AWS Bedrock?

Yes. Set CLAUDE_CODE_USE_BEDROCK=1, configure your AWS credentials and region, and set ANTHROPIC_MODEL to the Bedrock model ID (like anthropic.claude-sonnet-4-20250514-v1:0). Claude Code then invokes Bedrock through the standard runtime endpoint and is subject to the same permissions, subscriptions, and FTU requirements as any other integration.

Why is my new AWS account getting AccessDeniedException for every Bedrock model?

Two known issues hit new accounts: the zero-quota provisioning bug (all Bedrock service quotas set to 0, requiring an AWS Support case to fix), and the payment-instrument validation failing on free-tier accounts without a chargeable card. Also confirm the FTU form and Marketplace subscription are complete — new accounts hit all three gates at once.

What does "contact AWS Sales" mean in a Bedrock error?

The model has an account-level entitlement restriction. This cannot be fixed with IAM, SCPs, or console settings — it is a restriction AWS placed on the account. Confirm all other prerequisites are met, then contact AWS Support to have the entitlement reviewed.

Is Claude on Bedrock billed through AWS Marketplace?

Yes — Claude is a third-party model offered and billed through AWS Marketplace. Charges appear on your AWS bill and in Cost Explorer under Anthropic (the model provider), not under Amazon Bedrock. This is why the Marketplace subscription gate exists.

Is AWS Bedrock down? How do I check?

Check the AWS Health Dashboard for Bedrock service events in your region before assuming your configuration broke. Regional Bedrock incidents — elevated error rates, delayed processing — do happen, and during those windows your perfectly configured invocations fail the same way permission errors do. If the dashboard is clear, the problem is on your side; if it shows an event, retries and patience are the fix.

How do I check my Bedrock quota?

Run aws service-quotas list-service-quotas --service-code bedrock --region your-region to see all quotas including tokens-per-minute. If quotas show 0 on a new account, it is a provisioning bug that requires an AWS Support case to fix.

Wrapping Up: The Three Gates, in Order, Every Time

The next time AccessDeniedException stares back from a Claude invocation, resist the urge to open the IAM console first. The three gates, in the order you should walk them:

1. Marketplace subscription — does your role have aws-marketplace:Subscribe? If not, that is the fix, and it takes two minutes.
2. Anthropic FTU form — has the account ever submitted the use case for Anthropic models? If not, submit it.
3. IAM invocation permissions — all four actions (InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream), plus the inference-profile reads.

Those three open the door for the majority of failures. The model-ID and region checks, the SCP exemption for cross-region profiles, the zero-quota provisioning bug, and the entitlement restrictions fill in the long tail — but they are rare compared to the gates.

Jake hit this on the shop's AI invoice-reading prototype: perfect IAM policy, model ID copied from the docs, invocation failed with a Marketplace error he had never seen before. Ethan's verdict: "The error told you exactly which permissions were missing — you just stopped reading at 'AccessDenied' and assumed it was the Bedrock policy you already checked. The full message names aws-marketplace:Subscribe. That is the fix. Paste it, wait two minutes, and your invoice reader works."

If this is your first step into AWS services and the ecosystem feels vast, it is — and that is exactly why the free plain-English AWS series on this site exists: every core service explained in the order that makes sense, with prices included, so you build vocabulary before you build architecture..feel free to check it out.

Revision note. Written September 2026. All this might change as Anthropic releases new versions and AWS iterates on the model access UX. If you spent an afternoon with a perfect IAM policy and a still-blocked Claude invocation, you have met the three-gate architecture the hard way — and knowing to check the Marketplace permissions first puts you ahead of everyone still editing bedrock:InvokeModel for the fifth time..Happy learning! See you on next post!