Teams new to Amazon Bedrock often expect a lengthy approval workflow before they can call Claude. The current reality is simpler, and occasionally surprising in the other direction: access to Bedrock foundation models is enabled by default, provided the calling identity has the correct AWS Marketplace permissions. The first time your account invokes a third-party model such as Claude, Bedrock automatically initiates the Marketplace subscription behind the scenes. That setup can take up to 15 minutes, and if a prerequisite is missing you'll see an AccessDeniedException rather than a helpful wizard.
What the first invocation actually needs
Three AWS Marketplace IAM actions must be available to whoever enables a model for the first time in an account: aws-marketplace:Subscribe, aws-marketplace:Unsubscribe, and aws-marketplace:ViewSubscriptions. These are only needed once per model per account — after the subscription exists, ordinary users invoking Claude don't need Marketplace permissions at all. If your organization wants to control which models can be enabled, aws-marketplace:Subscribe can be restricted to specific models using the aws-marketplace:ProductId condition key.
Note also that first use of a model implies agreement to the applicable third-party end-user license agreement, so procurement and legal teams may want to review terms before a developer's first call quietly creates the subscription.
The one-time use-case form for Anthropic models
Anthropic models carry one extra step on the classic Bedrock surface: a one-time First Time Use (FTU) use-case form. You submit it once per AWS account — or once per AWS Organization, since a submission from the management account is inherited by member accounts. You can complete it in the Bedrock console's model access pages, or programmatically via the PutUseCaseForModelAccess API. Importantly, this requirement does not apply to Anthropic models accessed through the newer bedrock-mantle endpoint (the "Claude in Amazon Bedrock" Messages API surface).
ListFoundationModelAgreementOffers, CreateFoundationModelAgreement, GetFoundationModelAvailability, and DeleteFoundationModelAgreement.Blocking access is a different lever than granting it
Because Bedrock auto-initiates subscriptions, two intuitive "off switches" don't work the way administrators expect:
| What you might try | What actually happens |
|---|---|
Deny aws-marketplace:Subscribe | Does not block the first invocation by itself — Bedrock's auto-subscription flow can still proceed |
| Delete the model agreement | Not sufficient — invoking the model again simply re-creates the agreement |
Deny bedrock:InvokeModel in IAM or an SCP | This is the documented, reliable way to block model access |
If governance is the goal, write explicit deny policies on the invocation actions rather than trying to starve the subscription machinery. Our article on Service Control Policies for Bedrock covers the organization-wide version of this.
Verifying access before you write code
Once access is in place, the fastest sanity check is a call from the console playground or a minimal script. On the current "Claude in Amazon Bedrock" surface, that looks like:
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
msg = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=256,
messages=[{"role": "user", "content": "Say hello."}],
)
print(msg.content[0].text)
If this returns an AccessDeniedException, work backwards: check the Marketplace permissions, wait out the up-to-15-minute subscription setup, confirm the FTU form (for the legacy surface), and confirm the caller's IAM policy allows invocation of the model you named. Remember that Bedrock model IDs carry an anthropic. prefix — anthropic.claude-sonnet-5, not claude-sonnet-5.
Where to go next
With access enabled, try the Bedrock console playground for prompt prototyping, or jump to your first API call on Bedrock. The quickstart has the cross-platform view.