This page walks through one way to run Claude apps gateway on AWS. The configuration is a working example for customer-managed infrastructure rather than a supported production deployment; use it to see how the pieces fit together before adapting it to your own environment. For the platform-agnostic requirements, see the deployment guide.
Bedrock isn’t the only Claude upstream on AWS. The gateway also supports Claude Platform on AWS, the Anthropic-operated Claude API with AWS authentication and AWS Marketplace billing, in place of Bedrock or alongside it. Its upstream entry, credentials, and IAM permissions differ from this page’s Bedrock-scoped ones; the Claude Platform on AWS upstream reference covers what changes, and the rest of this page applies unchanged.
Architecture
The example architecture, with Amazon Bedrock as the model upstream. A Claude Platform on AWS upstream occupies the same position.
- Amazon ECS on AWS Fargate service or Amazon EKS Deployment running the gateway container
- Amazon ECR repository for the gateway image
- Amazon RDS for PostgreSQL instance in private subnets, not publicly accessible, for the gateway’s store
- AWS Secrets Manager secrets for the JWT signing key, the OIDC client secret, and the Postgres URL
- IAM role with
bedrock:InvokeModelandbedrock:InvokeModelWithResponseStream, attached as the ECS task role or bound via IAM Roles for Service Accounts (IRSA) on EKS - Internal Application Load Balancer for HTTPS
Prerequisites
The walkthrough creates the gateway’s own resources, but it builds on network and identity infrastructure you already have. Before you start, you need:- An AWS account with permission to create the resources above
- The AWS CLI v2 installed and authenticated, and Docker installed locally
- A VPC with at least two private subnets in different Availability Zones, with outbound internet access through a NAT gateway; the internal load balancer needs subnets in two AZs, and the gateway needs egress to Bedrock and your IdP
- An Okta OIDC web application with redirect URI
https://<gateway-host>/oauth/callback; see Identity provider setup - A TLS hostname for the gateway, typically an internal DNS name in a Route 53 private hosted zone pointing at the load balancer, with an ACM certificate for that name, imported or issued by AWS Private CA
Set your environment variables
Every command on this page reads four values from your shell:AWS_REGION, ACCOUNT_ID, VPC_ID, and PRIVATE_SUBNETS.
Pick a US region where Bedrock serves the Claude models you need. The walkthrough relies on the gateway’s built-in model catalog, which resolves to us.anthropic.* inference profiles, and the IAM policy grants those ARNs. In a non-US region, add a models: block with that geo’s inference-profile IDs and change the IAM policy’s ARN prefix to match.
If you don’t have the VPC ID at hand, list your VPCs with aws ec2 describe-vpcs, then list that VPC’s subnets to find two private ones in different Availability Zones:
Deploy the gateway
The steps below provision the full deployment withaws commands.
1
Create the security groups
Three security groups chain the traffic path: your corporate network reaches the load balancer on 443, the load balancer reaches the gateway on 8080, and the gateway reaches Postgres on 5432. Nothing else is reachable. How you attach them depends on the compute track:
- On ECS Fargate, the deploy step attaches
$ALB_SGto the load balancer and$GW_SGto the service. - On EKS, the AWS Load Balancer Controller creates its own frontend security group for the ALB, so
$ALB_SGand$GW_SGgo unused: the deploy step’sinbound-cidrsannotation restricts the listener to your corporate network, and the database security group admits the cluster’s security group instead.
2
Create the IAM roles and submit the use case form
The gateway runs with a dedicated task role whose only permission is invoking Claude models on Bedrock. Per the Bedrock upstream reference, the policy must cover both the cross-region inference-profile ARNs and the underlying foundation-model ARNs: