Why Enterprise Teams Choose AWS Bedrock for Claude
Claude is available on all three major cloud platforms — AWS Bedrock, Google Cloud Vertex AI, and Microsoft Azure — but AWS Bedrock has become the default choice for organisations already running significant workloads in AWS. The reason is operational simplicity: Bedrock integrates Claude directly into your existing AWS security posture, cost management structure, and monitoring toolchain. You don't need separate API key management, separate billing, or a new vendor relationship to get procurement to approve.
Bedrock also offers a specific security architecture that matters for regulated industries: when you invoke Claude through Bedrock, your data doesn't leave the AWS network boundary. It processes within AWS infrastructure, stays within your selected region, and can be locked down to a specific VPC. For financial services teams running in us-east-1 for regulatory reasons, or healthcare organisations with data residency requirements, this architecture is decisive.
This guide is specifically for the enterprise architecture of Claude on Bedrock — not a repeat of the basic setup walkthrough. If you're building production systems, you need to understand model access patterns, cross-region inference, provisioned throughput, guardrails, and cost governance. That's what we cover here. If you need help deploying this in your environment, our Claude API integration service handles Bedrock deployments across all major enterprise patterns.
Note on model availability: Claude models on Bedrock include Claude Opus 4.6, Sonnet 4.6, and Haiku 4.5. Model availability varies by AWS region — always verify availability in your target region in the Bedrock console before building architecture that depends on a specific model in a specific region.
Model Access and On-Demand vs Provisioned Throughput
Bedrock offers two ways to invoke Claude models: on-demand inference and provisioned throughput. The choice has significant cost and performance implications at enterprise scale.
On-Demand Inference
On-demand inference bills per token — input and output — with no upfront commitment. This is correct for variable workloads, development, and applications where request volume is unpredictable. The trade-off is that on-demand has throttling limits at the account and region level, which matter if your application sends high request volumes during peak hours.
Provisioned Throughput
Provisioned throughput reserves dedicated model capacity for a fixed term (1 month or 6 months), billed hourly regardless of usage. This is the correct choice when you have predictable, sustained request volume — a customer-facing application processing thousands of requests per hour, a daily batch pipeline, or a developer tooling integration used by a large engineering team. Provisioned throughput guarantees consistent latency and eliminates throttling risk at the cost of predictability in volume.
Most enterprise architectures use a hybrid: provisioned throughput for the baseline workload, with on-demand as overflow. This requires a routing layer that detects throttling responses and fails over to on-demand, but it's the most cost-efficient pattern at scale.
IAM Architecture for Enterprise Bedrock Deployments
Getting IAM right is the most important governance decision in your Bedrock architecture. The goal is principle of least privilege: every service, application, and user that invokes Claude through Bedrock should have exactly the permissions required — no more.
Core IAM Permissions
Applications invoking Claude through Bedrock need the following IAM permissions at minimum:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BedrockInvokeModel",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6-*",
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5-*"
]
}
]
}Scope the Resource to specific model ARNs, not *. This prevents an application with Bedrock access from invoking any model — including more expensive ones it shouldn't need. For applications that need Opus 4.6, add that ARN explicitly and document why that use case requires the most capable model.
Role-Based Access for Team Separation
Enterprise deployments typically need separate IAM roles for: production applications, development/test environments, batch jobs, and administrative access (model enablement, guardrail configuration). Maintain separate roles per workload type and attach them via IAM role assumption from the application's execution role (Lambda, ECS task role, EC2 instance profile).
Never use long-lived IAM access keys for Bedrock invocations in production. Use IAM roles with temporary credential vending via STS. If your application runs on ECS or Lambda, the execution role provides temporary credentials automatically.
VPC and PrivateLink Configuration
For regulated industries, production Claude on Bedrock should route through a VPC endpoint rather than the public internet. AWS provides PrivateLink endpoints for Bedrock that keep all traffic within the AWS network — traffic from your VPC to the Bedrock service never traverses a public IP or the internet.
Creating the VPC Endpoint
# Create Bedrock VPC endpoint
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0abc123def456789 \
--service-name com.amazonaws.us-east-1.bedrock-runtime \
--vpc-endpoint-type Interface \
--subnet-ids subnet-0abc123 subnet-0def456 \
--security-group-ids sg-0abc123 \
--private-dns-enabledWith --private-dns-enabled, existing application code that calls bedrock-runtime.us-east-1.amazonaws.com will automatically route through the VPC endpoint without code changes. The security group on the endpoint should allow inbound HTTPS (443) from your application's security group only.
Network ACL and Security Group Rules
Ensure your application subnets have outbound rules permitting HTTPS to the endpoint subnet. Lock down the VPC endpoint's security group to permit inbound traffic only from your application tier — deny all other sources. This prevents any other workload in the VPC from invoking Claude through your endpoint.
Bedrock Guardrails for Enterprise Content Control
AWS Bedrock Guardrails provides a managed layer for content filtering, topic blocking, PII detection, and grounding verification that sits between your application and Claude. For regulated industries or customer-facing applications, Guardrails is not optional — it's the mechanism that satisfies your AI governance requirements without custom prompt injection defence code.
Key Guardrail capabilities relevant to enterprise deployments include topic denial (block specific topics from being discussed — e.g., competitor comparisons in a customer-facing chatbot), sensitive information redaction (automatically detect and redact PII before it appears in outputs), and grounding checks (verify that responses are grounded in provided source documents rather than hallucinated).
Configure Guardrails at the organisational account level and reference them in all production Bedrock invocations. Associate a Guardrail ID and version with your application's inference calls — this ensures the content policy is versioned, auditable, and applied consistently regardless of which model version you're using.
CloudTrail Audit Logging and Cost Governance
Bedrock automatically integrates with AWS CloudTrail — every Bedrock API call is logged to your CloudTrail trail without additional configuration. This gives you an audit record of every Claude invocation: who called it, from which service, at what time, with which model, and the response metadata. For compliance programmes requiring AI audit trails, this is the key infrastructure that satisfies those requirements.
Cost Governance with AWS Cost Explorer
Tag your Bedrock workloads with cost allocation tags from day one. Apply tags that map to department, application, and environment — this allows you to break down Claude inference costs by team and use case in Cost Explorer. Without tags, you'll see a Bedrock line item in your bill with no visibility into what drove it.
Set AWS Budgets alerts for Bedrock spending per account or per tag group. For development environments, consider setting a hard limit that blocks invocations once a monthly budget is reached — this prevents runaway costs from misconfigured batch jobs or unbounded loops in development code.
If you need help designing a cost-governed, compliance-ready Bedrock architecture, our Claude API integration team builds this end-to-end for enterprise clients. We've deployed Bedrock architectures for financial services organisations where every Claude invocation feeds into audit systems and cost centres.
Enterprise Bedrock Architecture Review
Our Claude Certified Architects review your Bedrock architecture for security gaps, cost inefficiencies, and governance completeness. Most reviews surface 3–5 issues in IAM, monitoring, or cost allocation that teams didn't know existed.
Book an Architecture Review →Cross-Region Inference for Resilience and Capacity
Bedrock's cross-region inference feature allows you to configure a primary region and a list of fallback regions — if your primary region hits capacity limits or experiences a service disruption, Bedrock automatically routes requests to a configured backup region. For production applications that cannot tolerate downtime, cross-region inference is the correct architecture.
Configure cross-region inference through Inference Profiles in the Bedrock console. An Inference Profile defines the model, primary region, and ordered list of fallback regions. Reference the Inference Profile ARN in your application rather than hardcoding a model ARN — this gives you the cross-region routing behaviour transparently.
Note that cross-region data processing may have compliance implications for organisations with strict data residency requirements. Confirm with your legal and compliance teams before enabling cross-region inference for workloads processing regulated data.
Bedrock vs Direct Anthropic API: When to Use Each
AWS Bedrock is the right choice when your organisation is AWS-first — when you want unified billing, IAM, networking, and compliance tooling. It's also the correct choice for VPC-locked environments, for teams that need AWS Marketplace billing, and for organisations where enterprise procurement has already approved AWS but hasn't onboarded a direct Anthropic relationship.
The direct Anthropic API is correct when you need access to the latest model capabilities before they reach Bedrock (Bedrock lags Anthropic's direct API by weeks to months for new model releases), when you need Claude-specific features like extended thinking at their latest implementation, or when your architecture is multi-cloud and you want a single API across all environments.
For a comparison across deployment options, see our articles on Claude on Google Cloud Vertex AI and Claude on Microsoft Azure. For organisations deploying across all three clouds, our Claude API integration service designs architecture that abstracts the provider layer.