이 페이지는 AWS에서 Claude 앱 게이트웨이를 실행하는 한 가지 방법을 설명합니다. 이 구성은 지원되는 프로덕션 배포가 아닌 고객 관리 인프라의 작동 예제입니다. 이를 사용하여 각 부분이 어떻게 함께 작동하는지 확인한 후 자신의 환경에 맞게 조정하십시오. 플랫폼 독립적인 요구 사항은 배포 가이드를 참조하십시오.
Bedrock은 AWS의 유일한 Claude 업스트림이 아닙니다. 게이트웨이는 AWS 인증 및 AWS Marketplace 청구를 사용하는 Anthropic 운영 Claude API인 Claude Platform on AWS도 지원합니다. Bedrock 대신 또는 함께 사용할 수 있습니다. 업스트림 항목, 자격 증명 및 IAM 권한이 이 페이지의 Bedrock 범위 항목과 다릅니다. Claude Platform on AWS 업스트림 참조에서 변경 사항을 다룹니다. 이 페이지의 나머지 부분은 변경 없이 적용됩니다.
아키텍처
Amazon Bedrock을 모델 업스트림으로 하는 예제 아키텍처입니다. Claude Platform on AWS 업스트림이 동일한 위치를 차지합니다.
- AWS Fargate의 Amazon ECS 서비스 또는 게이트웨이 컨테이너를 실행하는 Amazon EKS Deployment
- 게이트웨이 이미지를 위한 Amazon ECR 리포지토리
- 게이트웨이의 저장소를 위해 프라이빗 서브넷에 있고 공개적으로 접근할 수 없는 Amazon RDS for PostgreSQL 인스턴스
- JWT 서명 키, OIDC 클라이언트 시크릿, Postgres URL을 위한 AWS Secrets Manager 시크릿
- ECS 작업 역할로 연결되거나 EKS의 IAM Roles for Service Accounts(IRSA)를 통해 바인딩된
bedrock:InvokeModel,bedrock:InvokeModelWithResponseStream,bedrock:CountTokens를 포함한 IAM 역할 - HTTPS를 위한 내부 Application Load Balancer
전제 조건
이 연습은 게이트웨이의 자체 리소스를 생성하지만 이미 있는 네트워크 및 ID 인프라를 기반으로 합니다. 시작하기 전에 다음이 필요합니다:- 위의 리소스를 생성할 권한이 있는 AWS 계정
- AWS CLI v2가 설치되고 인증되었으며, Docker가 로컬에 설치됨
- 서로 다른 가용 영역에 최소 2개의 프라이빗 서브넷이 있는 VPC. NAT 게이트웨이를 통한 아웃바운드 인터넷 액세스가 있어야 합니다. 내부 로드 밸런서는 2개의 AZ에 서브넷이 필요하고, 게이트웨이는 Bedrock 및 IdP로의 이그레스가 필요합니다.
- 리다이렉트 URI가
https://<gateway-host>/oauth/callback인 Okta OIDC 웹 애플리케이션. ID 공급자 설정을 참조하십시오. - 게이트웨이용 TLS 호스트명. 일반적으로 Route 53 프라이빗 호스팅 영역의 내부 DNS 이름으로 로드 밸런서를 가리키며, 해당 이름에 대한 ACM 인증서가 있어야 합니다. AWS Private CA에서 가져오거나 발급받아야 합니다.
환경 변수 설정
이 페이지의 모든 명령은 셸에서 4개의 값을 읽습니다:AWS_REGION, ACCOUNT_ID, VPC_ID, PRIVATE_SUBNETS.
필요한 Claude 모델을 제공하는 US 지역을 선택하십시오. 이 연습은 게이트웨이의 기본 제공 모델 카탈로그에 의존하며, 이는 us.anthropic.* 추론 프로필로 확인되고 IAM 정책이 해당 ARN을 부여합니다. US가 아닌 지역에서는 해당 지역의 추론 프로필 ID를 포함하는 models: 블록을 추가하고 IAM 정책의 ARN 접두사를 일치하도록 변경하십시오.
VPC ID가 없으면 aws ec2 describe-vpcs로 VPC를 나열한 다음 해당 VPC의 서브넷을 나열하여 서로 다른 가용 영역에 있는 2개의 프라이빗 서브넷을 찾으십시오:
게이트웨이 배포
아래 단계는aws 명령으로 전체 배포를 프로비저닝합니다.
1
보안 그룹 생성
3개의 보안 그룹이 트래픽 경로를 연결합니다: 회사 네트워크는 443에서 로드 밸런서에 도달하고, 로드 밸런서는 8080에서 게이트웨이에 도달하며, 게이트웨이는 5432에서 Postgres에 도달합니다. 다른 것은 도달할 수 없습니다. 이를 연결하는 방법은 컴퓨팅 트랙에 따라 다릅니다:
- ECS Fargate에서 배포 단계는
$ALB_SG를 로드 밸런서에 연결하고$GW_SG를 서비스에 연결합니다. - EKS에서 AWS Load Balancer Controller는 ALB용 자체 프론트엔드 보안 그룹을 생성하므로
$ALB_SG와$GW_SG는 사용되지 않습니다: 배포 단계의inbound-cidrs주석이 리스너를 회사 네트워크로 제한하고, 데이터베이스 보안 그룹은$GW_SG대신 클러스터의 보안 그룹을 허용합니다.
2
IAM 역할 생성 및 사용 사례 양식 제출
게이트웨이는 Bedrock에서 Claude 모델을 호출하는 유일한 권한을 가진 전용 작업 역할로 실행됩니다. Bedrock 업스트림 참조에 따르면 정책은 교차 지역 추론 프로필 ARN과 기본 기초 모델 ARN을 모두 포함해야 합니다:ECS는 또한 실행 역할이 필요합니다. ECS 에이전트 자체가 ECR에서 이미지를 가져오고 나중에 생성된 Secrets Manager 값을 주입하는 데 사용합니다. 이는 게이트웨이의 AWS SDK가 런타임에 사용하는 작업 역할과 별개입니다:정책은 각 비밀마다 하나의 ARN을 이름으로 지정하며, 공유 계정에서 관련 없는 비밀과도 일치하는 일반
gateway-* 와일드카드가 아닙니다. 뒤의 -??????는 Secrets Manager가 모든 비밀의 ARN에 추가하는 임의의 6자 접미사와 정확히 일치합니다. 뒤의 -*는 일반 접두사 glob이며 gateway-postgres-url-prod와 같은 더 긴 이름과도 일치합니다.IAM 정책은 게이트웨이에 Bedrock을 호출할 권한을 부여하고, Bedrock은 상용 지역에서 기본적으로 모델 액세스를 활성화합니다. 남은 계정 수준 게이트는 Anthropic의 일회성 사용 사례 양식입니다: 계정의 누구도 제출하지 않았다면 Amazon Bedrock 콘솔을 열고 모델 카탈로그에서 Anthropic 모델을 선택한 후 양식을 완료하십시오. 제출 직후 액세스가 부여됩니다. Amazon Bedrock의 Claude Code에서 AWS Organizations 양식 및 제출자가 필요한 IAM 권한을 참조하십시오.EKS 트랙은 2개의 ECS 역할 대신 IRSA 역할에서 두 정책 문서를 재사용합니다. 배포 단계를 참조하십시오.3
PostgreSQL용 Amazon RDS 프로비저닝
인스턴스는 공개 주소가 없는 프라이빗 서브넷에서 실행되며 스토리지 암호화가 켜져 있습니다. 엔진 버전은 Postgres 16으로 고정되어 있으며, 이는 게이트웨이의 지원되는 최소값인 PostgreSQL 14를 충족하고 아래 매개변수 그룹 패밀리가 인스턴스가 실행하는 엔진 주 버전과 일치함을 보장합니다.먼저 프라이빗 서브넷에 데이터베이스를 배치하는 서브넷 그룹과 그런 다음 생성된 마스터 암호로 인스턴스를 생성합니다:리터럴
rds.force_ssl=1을 사용하는 매개변수 그룹을 생성하여 서버가 일반 텍스트 연결을 거부하도록 합니다. 엔진 버전은 매개변수 그룹의 패밀리가 인스턴스가 실행하는 엔진 주 버전과 일치해야 하므로 한 번만 고정됩니다:--master-user-password 인수는 명령이 실행되는 동안 프로세스 테이블 및 감사/EDR 로그에 표시됩니다. 공유 또는 모니터링되는 호스트에서는 번들의 setup.sh가 하는 방식처럼 0600 파일에서 --cli-input-json을 통해 암호를 전달하십시오.인스턴스가 시작될 때까지 기다리십시오. 몇 분이 걸릴 수 있습니다. 그런 다음 프라이빗 엔드포인트를 읽고 게이트웨이가 사용할 연결 문자열을 조합하십시오:sslmode=verify-full은 게이트웨이가 RDS 서버 인증서의 체인과 호스트명을 확인하도록 하며, 암호화만 하지 않습니다. 신뢰 앵커는 AWS RDS 인증서 번들이며, 아래의 이미지 빌드 단계는 이를 /etc/claude/rds-global-bundle.pem에 복사하고 NODE_EXTRA_CA_CERTS를 통해 신뢰합니다. libpq 스타일 sslrootcert= 매개변수를 URL에 추가하지 마십시오: 게이트웨이의 드라이버는 쿼리 문자열에서 sslmode만 읽고 sslrootcert를 Postgres 시작 매개변수로 전달하며, 서버가 이를 거부합니다.ECS 서비스 또는 EKS 포드는 인스턴스의 프라이빗 엔드포인트에 도달할 수 있도록 이 VPC에서 실행되어야 하며, claude-gateway-db 보안 그룹은 게이트웨이의 보안 그룹만 허용합니다.4
gateway.yaml 작성
upstreams 블록은 auth: {}로 Bedrock을 가리키므로 게이트웨이는 ECS의 작업 역할 또는 EKS의 IRSA 역할에서 AWS 기본 자격 증명 체인을 통해 인증합니다. 모든 필드는 구성 참조를 참조하십시오.2개의 listen 필드는 게이트웨이 앞에 있는 것에 따라 다릅니다:public_url: 외부https://원점이며, 비루프백 바인드에 필수입니다. listen 참조를 참조하십시오. 게이트웨이는 IdPredirect_uri와 검색 문서를 이 값에서만 빌드하며,X-Forwarded-*헤더에서는 빌드하지 않습니다.trusted_proxies: 프론트 엔드의 소스 범위입니다. 게이트웨이는 TCP 피어가 이 목록에 있을 때만X-Forwarded-For를 준수하고, 신뢰할 수 있는 홉을 지나 체인을 걷습니다. 따라서 IP별 로그인 속도 제한 및 감사 이벤트는 로드 밸런서의 IP가 아닌 개발자 IP를 기록합니다.
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.yaml
oidc 블록만 Okta 특정입니다. Microsoft Entra ID를 대신 사용하려면 issuer를 https://login.microsoftonline.com/<tenant-id>/v2.0으로 설정하고, userinfo_fallback과 groups 범위를 제거하며, Entra가 그룹 이름이 아닌 그룹 Object ID를 내보낸다는 점에 유의하십시오. 따라서 managed.policies는 GUID에서 일치하거나 oidc.groups_claim: roles를 사용하는 App Roles에서 일치해야 합니다. ID 공급자 설정을 참조하십시오.5
AWS Secrets Manager에 비밀 저장
3개의 비밀을 생성합니다. IAM 단계의 실행 역할은 이미 이들을 읽을 수 있습니다:각 호출이 인쇄하는 ARN을 기록하십시오. ECS 작업 정의는 ARN으로 비밀을 참조합니다.비밀과 달리
리터럴
--secret-string 인수는 각 명령이 실행되는 동안 프로세스 테이블 및 감사/EDR 로그에 표시됩니다. 공유 또는 모니터링되는 호스트에서는 값을 0600 파일에 넣고 대신 --secret-string file://<path>를 전달하십시오. 번들의 setup.sh는 --cli-input-json에 0600 임시 파일을 전달하는 방식으로 비밀 값을 프로세스 argv에 노출하지 않습니다.gateway.yaml 자체는 모든 자격 증명이 ${VAR} 또는 ${file:...} 확장을 통해 부팅 시 확인되므로 비밀 값을 포함하지 않습니다. 모든 것이 컨테이너에 도달하는 방식은 트랙에 따라 다릅니다:- ECS에서 다음 단계의 빌드는
gateway.yaml을 이미지에/etc/claude/gateway.yaml로 복사하고, 작업 정의는 3개의 비밀을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로 직접 생성하십시오.
6
이미지를 Amazon ECR에 빌드 및 푸시
컨테이너 이미지 요구 사항에 따라 이미지를 빌드하고, 컨테이너 이미지 요구 사항은 번들을 다루지 않으므로 자신의 Dockerfile을 작성하면 번들을 복사하고 신뢰하는 2개의 줄을 추가하십시오. 번들의 ECR 리포지토리를 생성하고 Docker를 로그인하십시오. 불변 태그는 배포 단계가 고정하는 이미지를 빌드하고 푸시하십시오. 아래의 작업 정의는
linux-x64 glibc 바이너리를 빌드 컨텍스트의 ./claude에 배치하십시오. 해당 요구 사항에 따라 자신의 Dockerfile을 작성하거나 번들의 Dockerfile에서 시작하십시오. 이는 이전 단계의 채워진 gateway.yaml을 이미지의 /etc/claude/gateway.yaml에 복사합니다. ECS에서 이 임베드된 복사본은 구성이 컨테이너에 도달하는 방식이며, 이것이 빌드가 파일 작성 후에 오는 이유입니다. EKS 트랙은 대신 배포 시 ConfigMap에서 gateway.yaml을 마운트하므로 임베드된 복사본은 거기서 사용되지 않습니다.이미지는 또한 연결 문자열의 sslmode=verify-full에 대한 신뢰 앵커로 AWS RDS 인증서 번들을 전달합니다. 따라서 빌드 컨텍스트에 먼저 다운로드하십시오. AWS는 번들을 회전시킵니다(새 지역 CA가 추가됨). 따라서 체크섬을 고정하거나 커밋하기보다는 빌드당 다운로드하십시오:Dockerfile은 이미 둘 다 포함합니다:<version> 태그를 나중에 다른 이미지로 자동으로 다시 가리킬 수 없음을 의미합니다:linux/amd64를 실행하므로 플랫폼이 여기서 일치해야 합니다. Fargate on ARM64(Graviton)의 경우 linux-arm64 바이너리로 linux/arm64를 빌드하고 cpuArchitecture를 대신 ARM64로 설정하십시오:7
배포
- ECS Fargate
- EKS
클러스터와 게이트웨이의 stderr에 대한 로그 그룹을 생성합니다. 이는 감사 이벤트와 운영 로그를 모두 전달합니다. 보존은 별도의 호출이며, 보존이 없으면 CloudWatch는 로그를 영구적으로 유지합니다. 90일을 감사 보존 정책과 정렬하십시오:작업 정의를 작성하십시오. 작업 역할은 Bedrock 권한을 전달하고 실행 역할은 비밀을 주입합니다. Secrets Manager 단계의 비밀 ARN을 사용하십시오:등록하십시오:게이트웨이를 상태 확인하는 대상 그룹으로 내부 ALB를 앞단에 두십시오. HTTPS 리스너를 추가합니다. 서비스를 생성하십시오. 배포 회로 차단기는 나쁜 이미지 또는 부팅할 수 없는 구성으로 인해 작업이 계속 실패하는 배포를 마지막 안정 상태로 롤백합니다. 실패한 작업을 영구적으로 다시 시작하지 않습니다:60초 유예 기간은 콜드 작업이 이미지를 가져오고, 저장소에 연결하고, 첫 번째 상태 확인에 응답할 시간을 제공합니다. ECS가 배포에 대한 실패를 계산하기 시작하기 전입니다. 대상 그룹의
claude-gateway-task.json
--ip-address-type ipv4는 중요합니다: 내부 이중 스택 ALB는 공개 범위 AAAA 레코드를 게시하며, /login 프라이빗 네트워크 확인이 이를 거부합니다:--ssl-policy는 최신 TLS 하한을 고정합니다. 생략하면 여전히 TLS 1.0/1.1을 허용하는 레거시 ELBSecurityPolicy-2016-08 기본값으로 돌아갑니다.ALB는 기본적으로 60초 동안 데이터가 없는 연결을 닫습니다. 게이트웨이의 keepalive 핑은 스트림을 해당 기본값 내에 유지하므로 시간 초과를 높이면 핑 주기 위에 여유를 추가합니다. 문제 해결 행에서 끊어진 스트림을 다룹니다. 아래 명령은 리스너를 추가하고 시간 초과를 높입니다:GET /readyz에 대한 상태 확인은 저장소에 도달할 수 있는지 확인하므로 Postgres에 도달할 수 없는 작업은 회전에 들어가지 않습니다. 중단 동작에서 트레이드오프와 /healthz 대안을 참조하십시오.작업은 공개 IP가 없는 프라이빗 서브넷에서 실행되므로 모든 이그레스(Bedrock, IdP, Secrets Manager, ECR, CloudWatch Logs로)는 NAT 게이트웨이를 통해 이동합니다. Bedrock 트래픽을 공개 경로에서 벗어나게 하려면 bedrock-runtime 인터페이스 VPC 엔드포인트를 생성하고 업스트림의 base_url을 가리키십시오. Bedrock 업스트림 참조에 표시됩니다. IdP는 여전히 인터넷 이그레스가 필요합니다.개발자에게 프라이빗으로 확인할 수 있는 호스트명을 제공하여 마무리하십시오: Route 53 프라이빗 호스팅 영역에서 게이트웨이의 내부 DNS 이름을 ALB에 별칭으로 지정하고 listen.public_url을 해당 호스트명으로 설정하십시오. ALB의 자체 *.elb.amazonaws.com 이름은 내부 ALB에서 프라이빗 주소로 확인되지만 ACM 인증서를 전달할 수 없으므로 자신의 이름을 사용하십시오.첫 번째 로그인 전에 OAuth 클라이언트의 인증된 리다이렉트 URI를 <public_url>/oauth/callback으로 업데이트하십시오. public_url을 변경한 후 새 태그 아래에서 이미지를 다시 빌드하고 푸시하고, 새 작업 정의 개정을 등록하고, 다시 배포하십시오. ECS에서 설정은 이미지의 임베드된 gateway.yaml에 있으며, 게이트웨이는 해당 설정에서만 공개 원점을 빌드하고 X-Forwarded-Host 및 X-Forwarded-Proto를 무시합니다. X-Forwarded-For는 listen.trusted_proxies가 설정되었을 때만 클라이언트 IP에 대해 준수됩니다.8
게이트웨이 URL을 개발자 머신에 푸시
게이트웨이가 이제 실행 중이지만 개발자는 게이트웨이 URL이 머신에 있을 때까지
/login에서 도달할 수 없습니다. 관리형 설정 파일에서 forceLoginMethod 및 forceLoginGatewayUrl을 설정하고 MDM을 통해 각 디바이스에 배포하십시오. 개발자가 수동으로 선택할 수 있는 로그인 선택기의 게이트웨이 옵션이 없습니다.Terraform 참조
examples/gateway/aws의 동반 번들은 이 페이지를 코드로 패키징합니다:
setup.sh는 ECS Fargate 트랙에서 동일한aws명령으로 위의 프로비저닝 연습을 스크립트화합니다. 멱등성을 가집니다: 기존 리소스는 감지되고 건너뛰어지므로 다시 실행해도 안전하며, 모든 기본값은 환경 변수를 통해 재정의할 수 있습니다. Okta OIDC 클라이언트 시크릿과 ACM 인증서는 여전히 직접 생성합니다: 이들 없이 실행하면 ECS/ALB 배포를 건너뛰고, 누락된 입력을 이름 지으며,create-secret명령을 출력합니다. 둘 다 생성하고 다시 실행하세요. Bedrock 사용 사례 양식과 Route 53 별칭은 자동으로 실행되지 않고 다음 단계로 출력되며, 클라이언트 MDM 푸시는 이 페이지에서 수동 단계로 유지됩니다.gateway.yaml.example는 gateway.yaml 단계의 구성 템플릿이며, 선택적 키는 주석 처리되어 포함됩니다. 이를gateway.yaml로 복사하고 빌드하기 전에 모든REPLACE_ME를 바꾸세요.Dockerfile은 미리 빌드된linux-x64바이너리에서 런타임 이미지를 빌드하고 채워진gateway.yaml을/etc/claude/gateway.yaml에 복사하며, 저장소의sslmode=verify-full을 고정하는 AWS RDS 인증서 번들을 복사합니다.setup.sh는 번들이 빌드 컨텍스트에 아직 없을 때만 번들을 다운로드합니다. AWS CA 로테이션을 선택하려면 파일을 삭제하고 새 태그로 다시 빌드하세요. 구성 파일은 모든 자격 증명이 부팅 시${VAR}확장을 통해 해결되므로 시크릿 값을 보유하지 않습니다. 따라서 구성 편집은 새 태그로 다시 빌드하는 것을 의미합니다.setup.sh는 파일의 해시로 이미지에 태그를 지정하여 이를 자동화합니다.terraform/는 동일한 ECS Fargate 범위를 선언적으로 프로비저닝합니다: 보안 그룹, IAM 역할, ECR 리포지토리, RDS 인스턴스, Secrets Manager 시크릿, 및 내부 ALB 뒤의 ECS 서비스. VPC와 프라이빗 서브넷은 전제 조건으로 유지되며, 변수로 전달됩니다. Terraform은 ECR 리포지토리를 생성하지만 이미지를 빌드하지 않으며, 서비스 정의는 이미지를 참조하므로 적용은 두 번의 패스입니다: 리포지토리에 대한 대상 적용, 그 다음 빌드 및 푸시, 그 다음 전체 적용. 번들의terraform/README.md는 변수, 원격 상태, 및 정리를 다룹니다.
문제 해결
게이트웨이 부팅 및 로그인 오류는 플랫폼 독립적인 문제 해결 테이블을 참조하십시오. 아래 항목은 AWS에 특정합니다.원격 측정
게이트웨이는 머신별 OTEL 구성 없이 개발자별 사용 메트릭을 제공합니다. Claude Code는 OpenTelemetry(OTLP) 메트릭, 로그 및 옵트인 추적을 내보냅니다. 사용 모니터링은 CLI가 보고하는 모든 것을 다룹니다. 게이트웨이 세션에서 CLI는 각 내보내기에 인증된 IdP ID 속성user.id, user.email, user.groups를 스탬프하므로 사용이 OTEL_RESOURCE_ATTRIBUTES 배관 없이 개발자별로 롤업됩니다.
게이트웨이 자체는 인증된 OTLP 릴레이입니다. telemetry.forward_to를 listen.public_url과 함께 설정하면 모든 연결된 클라이언트에 OTEL 내보내기 설정을 푸시하고 OTLP 트래픽을 나열하는 각 대상으로 그대로 전달합니다. 각 대상은 메트릭, 로그, 추적을 독립적으로 옵트인하며, 기본값은 메트릭만입니다. 신호별 필드와 민감도 트레이드오프는 telemetry 참조를 참조하십시오. 게이트웨이는 원격 측정을 버퍼링, 집계 또는 저장하지 않으므로 데이터가 도달하는 위치는 전적으로 수집기의 내보내기 구성입니다.
클라이언트 원격 측정은 기본적으로 꺼져 있습니다. telemetry.forward_to를 구성하는 것이 연결된 개발자에 대해 이를 켜는 것이며, 각 대화형 클라이언트는 구성 참조에 설명된 대로 푸시된 설정에 대한 보안 승인 대화를 표시합니다. AWS에서 각 신호는 다음과 같이 대상으로 매핑됩니다.
클라이언트 메트릭, 로그 및 추적
telemetry.forward_to를 AWS Distro for OpenTelemetry(ADOT) 수집기와 같은 OpenTelemetry 수집기로 가리키고 거기서 Amazon CloudWatch, Amazon Managed Service for Prometheus 또는 모든 OTLP 백엔드로 내보내십시오.
수집기를 https://를 통해 도달할 수 있는 자체 내부 서비스로 실행하십시오. telemetry 참조는 루프백 예외 및 CLAUDE_GATEWAY_ALLOW_LOOPBACK을 다룹니다.
게이트웨이 로그
ECS Fargate에서 추가 설정이 없습니다:awslogs 드라이버는 게이트웨이의 stderr를 전달하며, 이는 감사 이벤트 및 운영 로그를 전달하고 위에서 생성된 /ecs/claude-gateway 로그 그룹으로 전달합니다. EKS에서 포드 로그는 기본적으로 CloudWatch에 도달하지 않으므로 감사 추적은 로그 수집을 설치할 때까지 손실됩니다: 컨테이너 로그 캡처가 활성화된 Amazon CloudWatch Observability 추가 기능 또는 Fluent Bit DaemonSet. 두 트랙 모두에서 CloudWatch Logs Insights로 로그를 쿼리하고 메트릭 필터에서 알람을 구동하십시오.
컨테이너 메트릭
클러스터에서 Container Insights를 활성화하십시오.aws ecs update-cluster-settings --cluster claude-gateway --settings name=containerInsights,value=enabled로 작업별 CPU, 메모리 및 네트워크를 활성화하십시오. EKS에서 Amazon CloudWatch Observability 추가 기능을 설치하십시오.
지출
원격 측정은 사용을 사후에 표시합니다. 지출 제한은 게이트웨이의 공유 업스트림 자격 증명 위의 라이브 개발자별 보기 및 적용입니다.다음 단계
- 구성 참조: 모든
gateway.yaml옵션,managed.policies및telemetry포함 - 배포 및 운영: IdP 설정, 상태 확인, JWT 비밀 회전, 업그레이드 및 보안 모델
- Claude 앱 게이트웨이 개요: 빠른 시작 및 개발자 연결
- Claude 앱 게이트웨이용 AWS 샘플: 다양한 고객 환경을 다루는 AWS 유지 배포 샘플