创建安全组

三个安全组链接流量路径：您的企业网络在 443 上到达负载均衡器，负载均衡器在 8080 上到达 gateway，gateway 在 5432 上到达 Postgres。其他任何东西都无法到达。如何附加它们取决于计算轨道：

• 在 ECS Fargate 上，部署步骤将 $ALB_SG 附加到负载均衡器，将 $GW_SG 附加到服务。
• 在 EKS 上，AWS Load Balancer Controller 为 ALB 创建自己的前端安全组，因此 $ALB_SG 和 $GW_SG 未使用：部署步骤的 inbound-cidrs 注解将侦听器限制为您的企业网络，数据库安全组允许集群的安全组而不是 $GW_SG。

ALB_SG="$(aws ec2 create-security-group --group-name claude-gateway-alb \
--description "Claude gateway ALB" --vpc-id "$VPC_ID" \
--query GroupId --output text)"
GW_SG="$(aws ec2 create-security-group --group-name claude-gateway-svc \
--description "Claude gateway service" --vpc-id "$VPC_ID" \
--query GroupId --output text)"
DB_SG="$(aws ec2 create-security-group --group-name claude-gateway-db \
--description "Claude gateway Postgres" --vpc-id "$VPC_ID" \
--query GroupId --output text)"

aws ec2 authorize-security-group-ingress --group-id "$ALB_SG" \
--protocol tcp --port 443 --cidr <your-corporate-cidr>
aws ec2 authorize-security-group-ingress --group-id "$GW_SG" \
--protocol tcp --port 8080 --source-group "$ALB_SG"
aws ec2 authorize-security-group-ingress --group-id "$DB_SG" \
--protocol tcp --port 5432 --source-group "$GW_SG"

创建 IAM 角色并提交用例表单

gateway 使用专用任务角色运行，其唯一权限是在 Bedrock 上调用 Claude 模型。根据 Bedrock 上游参考，该策略必须涵盖跨区域推理配置文件 ARN 和底层基础模型 ARN：

cat > bedrock-invoke.json <<EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:CountTokens"],
"Resource": [
"arn:aws:bedrock:${AWS_REGION}:${ACCOUNT_ID}:inference-profile/us.anthropic.*",
"arn:aws:bedrock:*::foundation-model/anthropic.*"
]
}]
}
EOF
cat > ecs-trust.json <<'EOF'
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "ecs-tasks.amazonaws.com" },
"Action": "sts:AssumeRole"
}]
}
EOF

aws iam create-role --role-name claude-gateway-task \
--assume-role-policy-document file://ecs-trust.json
aws iam put-role-policy --role-name claude-gateway-task \
--policy-name bedrock-invoke --policy-document file://bedrock-invoke.json

ECS 还需要一个执行角色，ECS 代理本身使用它从 ECR 拉取镜像并注入稍后创建的 Secrets Manager 值。它与 gateway 的 AWS SDK 在运行时使用的任务角色分开：

aws iam create-role --role-name claude-gateway-execution \
--assume-role-policy-document file://ecs-trust.json
aws iam attach-role-policy --role-name claude-gateway-execution \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
cat > secrets-read.json <<EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
"Resource": [
"arn:aws:secretsmanager:${AWS_REGION}:${ACCOUNT_ID}:secret:gateway-jwt-secret-??????",
"arn:aws:secretsmanager:${AWS_REGION}:${ACCOUNT_ID}:secret:gateway-oidc-client-secret-??????",
"arn:aws:secretsmanager:${AWS_REGION}:${ACCOUNT_ID}:secret:gateway-postgres-url-??????"
]
}]
}
EOF
aws iam put-role-policy --role-name claude-gateway-execution \
--policy-name read-gateway-secrets --policy-document file://secrets-read.json

该策略为每个机密命名一个 ARN，而不是裸 gateway-* 通配符，在共享账户中，这也会匹配不相关的机密；尾部的 -?????? 完全匹配 Secrets Manager 附加到每个机密 ARN 的随机六字符后缀。尾部的 -* 将是一个普通前缀 glob，也会匹配更长的名称，例如 gateway-postgres-url-prod。

IAM 策略授予 gateway 调用 Bedrock 的权限，Bedrock 在商业区域中默认启用模型访问。剩余的账户级门槛是 Anthropic 的一次性用例表单：如果您账户中没有人提交过，请打开 Amazon Bedrock 控制台，从模型目录中选择一个 Anthropic 模型，并完成表单。提交后立即授予访问权限；有关 AWS Organizations 表单和提交者需要的 IAM 权限，请参阅 Claude Code on Amazon Bedrock。

EKS 轨道改为在 IRSA 角色上重用两个策略文档，而不是两个 ECS 角色；请参阅部署步骤。

配置 Amazon RDS for PostgreSQL

该实例在私有子网中运行，没有公共地址，存储加密打开。引擎版本固定为 Postgres 16，满足 gateway 支持的 PostgreSQL 14 下限，并保证下面的参数组系列与实例匹配。

首先，创建将数据库放在私有子网中的子网组，以及具有 rds.force_ssl=1 的参数组，以便服务器拒绝明文连接。引擎版本固定一次，因为参数组的系列必须与实例运行的引擎主版本匹配：

aws rds create-db-subnet-group --db-subnet-group-name claude-gateway-db \
--db-subnet-group-description "Claude gateway" --subnet-ids $PRIVATE_SUBNETS

PG_VERSION=16
PG_FAMILY="postgres${PG_VERSION}"
aws rds create-db-parameter-group --db-parameter-group-name claude-gateway-db \
--db-parameter-group-family "$PG_FAMILY" \
--description "Claude gateway - require TLS on every connection"
aws rds modify-db-parameter-group --db-parameter-group-name claude-gateway-db \
--parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"

然后使用生成的主密码创建实例：

PGPASS="$(openssl rand -hex 24)"
aws rds create-db-instance --db-instance-identifier claude-gateway-db \
--engine postgres --engine-version "$PG_VERSION" \
--db-instance-class db.t4g.micro \
--allocated-storage 20 --db-name claude_gateway \
--master-username gateway --master-user-password "$PGPASS" \
--db-subnet-group-name claude-gateway-db \
--db-parameter-group-name claude-gateway-db \
--vpc-security-group-ids "$DB_SG" \
--no-publicly-accessible --storage-encrypted

字面 --master-user-password 参数在命令运行时在进程表和审计/EDR 日志中可见，与机密步骤的注释涵盖的相同暴露。在共享或受监控的主机上，改为从 0600 文件通过 --cli-input-json 传递密码，就像 bundle 的 setup.sh 所做的那样。

等待实例启动，这可能需要几分钟，然后读取其私有端点并组装 gateway 将使用的连接字符串：

aws rds wait db-instance-available --db-instance-identifier claude-gateway-db
DB_HOST="$(aws rds describe-db-instances --db-instance-identifier claude-gateway-db \
--query 'DBInstances[0].Endpoint.Address' --output text)"
GATEWAY_POSTGRES_URL="postgres://gateway:${PGPASS}@${DB_HOST}:5432/claude_gateway?sslmode=verify-full"

sslmode=verify-full 使 gateway 验证 RDS 服务器证书的链和主机名，不仅仅是加密。信任锚是 AWS RDS 证书包，镜像构建步骤下面将其复制到 /etc/claude/rds-global-bundle.pem 并通过 NODE_EXTRA_CA_CERTS 信任。不要将 libpq 风格的 sslrootcert= 参数附加到 URL：gateway 的驱动程序仅从查询字符串读取 sslmode，并会将 sslrootcert 转发给 Postgres 作为启动参数，服务器会拒绝。

ECS 服务或 EKS pod 必须在此 VPC 中运行，以便它们可以到达实例的私有端点，claude-gateway-db 安全组仅允许 gateway 的安全组。

编写 gateway.yaml

upstreams 块使用 auth: {} 指向 Bedrock，因此 gateway 通过 ECS 上的任务角色或 EKS 上的 IRSA 角色从 AWS 默认凭证链进行身份验证。有关每个字段，请参阅配置参考。

两个 listen 字段描述什么位于 gateway 前面：

• public_url：外部 https:// 源，对于任何非环回绑定都是必需的；请参阅 listen 参考。gateway 仅从此值构建 IdP redirect_uri 和其发现文档，从不从 X-Forwarded-* 标头构建。
• trusted_proxies：前端的源范围。gateway 仅当 TCP 对等体在此列表中时才遵守 X-Forwarded-For，然后遍历链越过受信任的跳跃，因此每 IP 登录速率限制和审计事件记录开发人员 IP 而不是负载均衡器的。

在两个轨道上，前端是内部 ALB，无论是直接创建还是由 AWS Load Balancer Controller 创建，ALB 的节点从它附加到的子网中获取地址，因此将 trusted_proxies 设置为这些子网的 CIDR。这将这些子网中的每个主机信任为代理。保持 ALB 的入站源（您的企业 CIDR）不与它们重叠，并且不要与可能通过 X-Forwarded-For 欺骗客户端 IP 的不受信任的工作负载共享子网。

ALB 的客户端端口保留属性 routing.http.xff_client_port.enabled 可以保持任一设置：启用时，ALB 将客户端写为 203.0.113.7:54321 或 [2001:db8::1]:54321，gateway 读取两者并删除端口。

listen:
host: 0.0.0.0
port: 8080
public_url: https://claude-gateway.internal.example.com
trusted_proxies: [<your-alb-subnet-cidrs>]

oidc:
issuer: https://example.okta.com
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}           # EKS: ${file:/secrets/oidc-client-secret}
allowed_email_domains: [example.com]
# Okta org 授权服务器返回一个省略了
# 电子邮件和组的瘦 id_token；gateway 从 /userinfo 填充它们。
userinfo_fallback: true
# Okta 仅在请求 `groups` 范围且
# 应用的组声明过滤器允许它们时才发出组。
scopes: [openid, profile, email, offline_access, groups]

session:
jwt_secret: ${GATEWAY_JWT_SECRET}              # EKS: ${file:/secrets/jwt-secret}
ttl_hours: 8 # 限制取消配置延迟；降低
# 朝向 1 以获得更紧密的撤销

store:
postgres_url: ${GATEWAY_POSTGRES_URL}          # EKS: ${file:/secrets/postgres-url}

upstreams:
- provider: bedrock
region: <your-region>                        # 匹配 $AWS_REGION 以便 IAM
# 策略的 ARN 涵盖它
auth: {} # AWS 默认凭证链：
# ECS 任务角色，或 EKS 上的 IRSA

在 AWS Secrets Manager 中存储机密

创建三个机密；IAM 步骤中的执行角色已经可以读取它们：

aws secretsmanager create-secret --name gateway-jwt-secret \
--secret-string "$(openssl rand -base64 32)"
aws secretsmanager create-secret --name gateway-oidc-client-secret \
--secret-string '<your-okta-client-secret>'
aws secretsmanager create-secret --name gateway-postgres-url \
--secret-string "$GATEWAY_POSTGRES_URL"

注意每个调用打印的 ARN；ECS 任务定义通过 ARN 引用机密。

与机密不同，gateway.yaml 本身不包含机密值，因为每个凭证在启动时通过 ${VAR} 或 ${file:...} 扩展解析。一切如何到达容器因轨道而异：

• 在 ECS 上，下一步的构建将 gateway.yaml 复制到镜像中的 /etc/claude/gateway.yaml，任务定义通过其 secrets 字段将三个机密作为环境变量注入，因此 YAML 引用 ${GATEWAY_JWT_SECRET}、${OIDC_CLIENT_SECRET} 和 ${GATEWAY_POSTGRES_URL}。
• 在 EKS 上，从 ConfigMap 挂载 gateway.yaml 并将机密作为文件挂载在 /secrets，引用为 ${file:/secrets/...}。使用 External Secrets Operator 或 Secrets Store CSI 驱动程序的 AWS 提供程序从 Secrets Manager 获取 Kubernetes Secrets，或使用 kubectl 直接创建它们。

构建镜像并将其推送到 Amazon ECR

根据容器镜像要求构建镜像，将 linux-x64 glibc 二进制文件放在构建上下文中的 ./claude。根据这些要求编写您自己的 Dockerfile，或从 bundle 的 Dockerfile 开始，它将填充的 gateway.yaml 从前面的步骤复制到镜像中的 /etc/claude/gateway.yaml。在 ECS 上，该嵌入式副本是配置到达容器的方式，这就是为什么构建在文件被写入后进行。EKS 轨道改为在部署时从 ConfigMap 挂载 gateway.yaml，因此嵌入式副本在那里未使用。

镜像还携带 AWS RDS 证书包作为连接字符串的 sslmode=verify-full 的信任锚，因此首先将其下载到构建上下文中。AWS 轮换 bundle（新的区域 CA 被附加），因此每次构建时下载它，而不是固定校验和或提交它：

curl -fL --proto '=https' -o rds-global-bundle.pem \
https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

容器镜像要求不涵盖 bundle，因此如果您编写自己的 Dockerfile，添加复制和信任它的两行；bundle 的 Dockerfile 已经包含两者：

COPY rds-global-bundle.pem /etc/claude/rds-global-bundle.pem
ENV NODE_EXTRA_CA_CERTS=/etc/claude/rds-global-bundle.pem

创建 ECR 存储库并将 Docker 登录到它。不可变标签意味着部署步骤固定的 <version> 标签以后不能被无声地重新指向不同的镜像：

aws ecr create-repository --repository-name claude-gateway \
--image-tag-mutability IMMUTABLE \
--image-scanning-configuration scanOnPush=true
aws ecr get-login-password --region "$AWS_REGION" \
| docker login --username AWS --password-stdin \
"${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"

构建并推送镜像。下面的任务定义运行 linux/amd64，因此平台必须在这里匹配；对于 Fargate on ARM64 (Graviton)，使用 linux-arm64 二进制文件构建 linux/arm64 并改为将 cpuArchitecture 设置为 ARM64：

docker build --platform=linux/amd64 \
-t "${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/claude-gateway:<version>" .
docker push "${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/claude-gateway:<version>"

部署

aws ecs create-cluster --cluster-name claude-gateway
aws logs create-log-group --log-group-name /ecs/claude-gateway
aws logs put-retention-policy --log-group-name /ecs/claude-gateway \
--retention-in-days 90

{
"family": "claude-gateway",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "1024",
"memory": "2048",
"runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
"executionRoleArn": "arn:aws:iam::<account-id>:role/claude-gateway-execution",
"taskRoleArn": "arn:aws:iam::<account-id>:role/claude-gateway-task",
"containerDefinitions": [
{
"name": "gateway",
"image": "<account-id>.dkr.ecr.<region>.amazonaws.com/claude-gateway:<version>",
"portMappings": [{ "containerPort": 8080 }],
"secrets": [
{ "name": "GATEWAY_JWT_SECRET",   "valueFrom": "<gateway-jwt-secret ARN>" },
{ "name": "OIDC_CLIENT_SECRET",   "valueFrom": "<gateway-oidc-client-secret ARN>" },
{ "name": "GATEWAY_POSTGRES_URL", "valueFrom": "<gateway-postgres-url ARN>" }
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/claude-gateway",
"awslogs-region": "<region>",
"awslogs-stream-prefix": "gateway"
}
}
}
]
}

aws ecs register-task-definition --cli-input-json file://claude-gateway-task.json

ALB_ARN="$(aws elbv2 create-load-balancer --name claude-gateway \
--scheme internal --type application --ip-address-type ipv4 \
--subnets $PRIVATE_SUBNETS --security-groups "$ALB_SG" \
--query 'LoadBalancers[0].LoadBalancerArn' --output text)"

TG_ARN="$(aws elbv2 create-target-group --name claude-gateway \
--protocol HTTP --port 8080 --vpc-id "$VPC_ID" --target-type ip \
--health-check-path /readyz \
--query 'TargetGroups[0].TargetGroupArn' --output text)"

aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \
--protocol HTTPS --port 443 \
--ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
--certificates CertificateArn=<your-acm-certificate-arn> \
--default-actions Type=forward,TargetGroupArn="$TG_ARN"

aws elbv2 modify-load-balancer-attributes --load-balancer-arn "$ALB_ARN" \
--attributes Key=idle_timeout.timeout_seconds,Value=3600

aws ecs create-service --cluster claude-gateway --service-name claude-gateway \
--task-definition claude-gateway --desired-count 1 --launch-type FARGATE \
--deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
--health-check-grace-period-seconds 60 \
--network-configuration "awsvpcConfiguration={subnets=[$(echo $PRIVATE_SUBNETS | tr ' ' ',')],securityGroups=[$GW_SG],assignPublicIp=DISABLED}" \
--load-balancers "targetGroupArn=$TG_ARN,containerName=gateway,containerPort=8080"

BEDROCK_POLICY_ARN="$(aws iam create-policy --policy-name claude-gateway-bedrock-invoke \
--policy-document file://bedrock-invoke.json --query Policy.Arn --output text)"
SECRETS_POLICY_ARN="$(aws iam create-policy --policy-name claude-gateway-secrets-read \
--policy-document file://secrets-read.json --query Policy.Arn --output text)"

kubectl create namespace claude-gateway
eksctl create iamserviceaccount --cluster <your-cluster> --region "$AWS_REGION" \
--namespace claude-gateway --name gateway --role-name claude-gateway \
--attach-policy-arn "$BEDROCK_POLICY_ARN" \
--attach-policy-arn "$SECRETS_POLICY_ARN" \
--approve

将 gateway URL 推送到开发人员机器

gateway 现在正在运行，但开发人员在通过 MDM 部署的托管设置文件中设置 forceLoginMethod 和 forceLoginGatewayUrl 之前无法从 /login 到达它。开发人员无法手动在登录选择器中选择 gateway 选项。