Deploying Anthropic Claude apps gateway for AWS for enterprise workloads

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Claude 앱 게이트웨이는 기업이 Claude Code와 Claude Desktop의 인증, 모델 접근, 사용량 귀속, 장애 조치, 지출 한도를 중앙에서 통제하도록 지원하는 자체 호스팅 거버넌스 계층이다.

📌 핵심 요약

• 참조 배포는 Claude CLI에 포함된 게이트웨이를 AWS Fargate의 무상태 컨테이너로 실행하고, 단기 인증 상태와 지출 카운터를 Amazon RDS for PostgreSQL에 저장한다.
• 내부 Application Load Balancer와 Route 53 프라이빗 호스팅 영역을 사용해 게이트웨이를 사설 네트워크로 제공하며, 업스트림 자격 증명은 IAM 역할과 AWS Secrets Manager에서 관리한다.
• 개발자는 OIDC 기반 브라우저 SSO로 로그인하고 기본 1시간의 단기 토큰을 발급받으며, 이후 요청마다 신원·그룹·정책·지출 한도가 검증된다.
• 그룹별 YAML 정책으로 허용 모델과 도구 권한을 서버 측에서 제한하고, 사용자별 사용량 메트릭은 OTLP 수집기로 전달해 비용과 활동을 귀속할 수 있다.
• 여러 업스트림을 선언 순서대로 구성해 장애·스로틀링·시간 초과 시 자동 전환할 수 있으며, 조직·그룹·사용자 수준의 개발자별 지출 상한을 추론 전에 집행할 수 있다.

🧩 주요 포인트

1. 인증 상태와 정책 집행을 중앙 게이트웨이에 모아 개발자 장비의 업스트림 자격 증명을 제거하고, 사용자 변경과 퇴사를 기존 ID 공급자에서 일관되게 반영한다.
2. 모델·도구 권한을 서버 측에서 강제하고 인증 신원에 사용량을 연결함으로써 수정된 클라이언트의 우회 가능성을 줄이고 팀별 거버넌스와 비용 추적을 가능하게 한다.
3. 다중 업스트림 장애 조치와 요청 전 지출 상한 검사를 결합해 가용성과 예산 통제를 보완하지만, 공급자 간 전환에서는 서비스 조건과 데이터 처리 지역의 변화를 검토해야 한다.

🧠 상세 정리

1. 기업 배포의 문제와 게이트웨이 역할

Claude Code와 Claude Desktop을 조직 전체에 배포하는 AI 관리자는 인증, 모델 접근, 비용 귀속, 지출 집행을 사용자별로 일관되게 관리해야 한다. 원문은 이러한 통제를 각 개발자 환경에 흩어 놓는 대신 중앙화하면 운영 부담을 줄이고 대규모 조직에 동일한 거버넌스를 적용할 수 있다고 설명한다. Claude 앱 게이트웨이는 두 애플리케이션과 Amazon Bedrock 또는 AWS상의 Claude Platform 사이에 배치되는 자체 호스팅 계층으로, 모든 추론 요청의 공통 통제 지점이 된다. 제시된 참조 배포는 단순한 기능 소개가 아니라 네트워크와 상태 저장 구조, 인증 및 요청 흐름, 정책, 관측성, 장애 조치, 지출 상한을 함께 다루는 운영 구성을 제안한다. 따라서 핵심 목적은 모델 호출 경로를 중앙화하고, 기존 기업 신원 체계와 인프라 안에서 접근 권한과 비용 책임을 동일한 사용자 신원에 연결하는 데 있다.

2. 참조 배포 토폴로지와 상태 관리

게이트웨이는 개발자가 사용하는 Claude Code CLI 바이너리에 포함되며, claude gateway --config gateway.yaml 명령으로 서버 모드를 시작해 기동 시 YAML 설정을 읽는다. 참조 구성에서는 각 AWS Fargate 태스크가 VPC 내부에서 하나의 무상태 게이트웨이 컨테이너를 실행하지만, 같은 이미지를 기존 환경에 맞춰 Amazon EKS나 Amazon EC2에서 실행할 수도 있다. 장치 코드와 세션 같은 단기 로그인 상태는 Amazon RDS for PostgreSQL에 저장되고, 지출 한도를 활성화하면 사용자별 지출 카운터와 감사 기록도 같은 데이터베이스에 보관된다. 인증 상태가 개별 태스크에 남지 않으므로 어느 태스크든 어떤 요청도 처리할 수 있고, 로드 밸런서에 고정 세션을 설정할 필요가 없다. 이 구조는 컨테이너 계층을 무상태로 유지하면서 로그인 연속성과 비용 집행에 필요한 상태만 공용 데이터 계층에 분리하는 방식이다.

3. 사설 진입점과 자격 증명 보호

외부 진입점은 내부 Application Load Balancer이며, AWS Certificate Manager 인증서를 사용해 TLS를 종료한다. Route 53 프라이빗 호스팅 영역은 게이트웨이 주소를 사설 IP로 해석하고, 사용자는 VPN이나 AWS Direct Connect 또는 이에 준하는 사설 연결을 통해 접근한다. 지원되는 AWS 서비스와의 통신은 VPC 엔드포인트로 사설 경로를 유지하며, 그 밖에 필요한 외부 통신은 NAT 게이트웨이를 사용한다. Amazon Bedrock 호출은 Fargate 태스크에 부여된 IAM 역할로 인증하고, Claude Platform on AWS의 API 키를 비롯한 정적 자격 증명은 AWS Secrets Manager에 보관하므로 개발자 장비에 업스트림 자격 증명을 배포하지 않는다. 운영 시에는 비스트리밍 응답 지연과 스트리밍 청크 사이의 정지 시간을 모두 고려해 로드 밸런서 유휴 제한 시간을 설정해야 하며, 기본값인 60초보다 긴 무데이터 구간이 예상되면 제한 시간을 늘려야 한다.

4. 로그인과 추론 요청의 처리 흐름

플랫폼 팀은 Claude Code와 Claude Desktop이 게이트웨이의 사설 URL을 사용하도록 관리형 설정을 배포한다. 개발자가 로그인 명령을 실행하면 클라이언트가 OAuth 2.0 장치 권한 부여 흐름을 시작하고, 브라우저는 OIDC 신원 공급자를 통해 사용자를 인증한다. 장치 확인 페이지를 게이트웨이가 직접 제공하므로 로그인에 사용하는 브라우저도 게이트웨이의 사설 엔드포인트에 접근할 수 있어야 한다. 인증 후 게이트웨이는 기본 1시간 동안 유효한 단기 베어러 토큰을 발급하며, 이후 세션 갱신은 백그라운드에서 자동으로 처리된다. 각 추론 요청에서는 토큰을 검증한 뒤 개발자의 신원과 그룹을 확인하고, 일치하는 정책과 지출 상한을 평가한 후 지정된 업스트림으로 요청을 전달하며 응답은 클라이언트로 스트리밍된다. 클라이언트가 생성한 사용량 메트릭은 정책 평가에 사용된 인증 신원에 귀속되고, 게이트웨이를 거쳐 설정된 OTLP 수집기로 전달된다.

5. OIDC 기반 SSO와 사용자 수명주기

게이트웨이는 인증을 기존 OIDC 신원 공급자에 위임하며, 원문은 Okta, Microsoft Entra ID, Auth0, Keycloak, Amazon Cognito 등을 지원 예시로 제시한다. 자체 사용자 디렉터리를 유지하지 않으므로 계정을 사전에 만들거나 SCIM 동기화를 별도로 구성할 필요가 없고, 신원 공급자가 부여한 그룹을 변환 계층 없이 정책 일치에 그대로 사용한다. 사용자와 그룹 변경은 다음 세션 갱신 때 반영되며, 퇴사자 차단도 신원 공급자에서 사용자를 제거하는 방식으로 처리된다. 제거된 사용자의 세션은 설정된 수명 이내에 만료되는데 기본값은 1시간이며, 이를 위해 업스트림 자격 증명을 회전할 필요는 없다. 다만 Microsoft Entra ID는 그룹 또는 역할 클레임을 기본으로 포함하지 않으므로 앱 역할로 그룹 정책을 적용하려면 OIDC 설정에 groups_claim: roles를 지정해야 한다. 이 항목이 없으면 게이트웨이가 그룹을 판별하지 못해 사용자가 그룹별 정책이 아니라 포괄 정책에만 일치하게 된다.

6. 그룹별 모델과 도구 권한 정책

모델 접근은 서버 측에서 강제되고, 도구 권한과 관리형 설정은 신원 공급자의 그룹을 기준으로 배포된다. 정책은 YAML에 선언된 순서대로 평가되어 처음 일치한 항목이 선택되고, match: {}로 정의된 포괄 기본 정책과 병합되므로 목록 마지막에 포괄 정책을 두어야 한다. 포괄 정책이 없으면 어떤 그룹별 항목에도 일치하지 않은 사용자가 전체 모델 카탈로그에 접근하게 된다고 원문은 경고한다. 예시에서는 계약자 그룹의 모델 목록을 제한하고 WebFetch와 WebSearch를 거부하며, 엔지니어 그룹에는 여러 모델과 Read, Grep, Bash, Edit 도구를 허용하되 .env와 secrets 경로 읽기를 차단한다. 제한은 수정된 클라이언트로도 우회할 수 없고 모델 선택기에는 허용된 모델만 표시되며, 변경된 정책은 개발자의 별도 조치 없이 연결된 클라이언트에 1시간 이내 전파된다. Claude Desktop을 허용하려면 모든 정책 항목에 desktop: {}를 포함해야 하며, 빠뜨리면 로그인에 성공하더라도 해당 정책 사용자의 Desktop 추론 요청은 거부된다.

7. 사용자별 텔레메트리와 다중 업스트림

클라이언트는 토큰 사용량, 비용 사용량, 총 활성 시간 메트릭을 생성하고 이를 사용자 ID, 이메일, 그룹 구성원 정보가 포함된 인증 신원에 귀속한다. 게이트웨이는 이 텔레메트리를 OTLP로 지정 수집기에 중계하며, Datadog, Splunk, Grafana와 ADOT 수집기를 통한 Amazon CloudWatch 같은 호환 백엔드를 사용할 수 있다. 로그와 추적에는 소스 코드나 프롬프트 내용이 포함될 수 있어 선택적으로만 활성화되며, 원문은 민감한 데이터를 노출하지 않고 사용자별 비용과 사용량을 파악하려는 배포에서 메트릭부터 사용하는 방식을 설명한다. 추론 업스트림은 선언된 순서대로 하나 이상 구성할 수 있고, 업스트림 장애, 스로틀링 또는 시간 초과가 발생하면 다음 대상으로 자동 전환된다. 예시는 서로 다른 리전의 Amazon Bedrock을 순차 배치하고 Claude Platform on AWS를 추가 대체 경로로 두지만, 공급자 간 장애 조치는 적용되는 서비스 조건과 데이터 처리 지역을 바꿀 수 있으므로 구성 시 그 차이를 함께 고려해야 한다.

8. 개발자별 지출 상한의 인라인 집행

AWS Budgets와 AWS Cost Explorer는 주기적으로 집계되는 계정 수준 비용 가시성을 제공해 조직 전체의 비용 거버넌스에 적합하지만, 게이트웨이는 각 추론이 실행되기 전에 개발자별 제한을 검사하는 방식으로 이를 보완한다. 지출 상한은 조직 전체 기본값, 그룹별 값, 사용자별 재정의의 세 수준에서 설정되며, 각 한도는 팀이 공유하는 예산 풀이 아니라 개발자마다 개별 적용된다. 유효 한도는 사용자별 재정의가 가장 우선하고, 그다음에는 사용자가 속한 그룹에 적용되는 값 중 가장 엄격한 상한이 선택되며, 마지막으로 조직 기본값이 사용된다. 어느 수준에도 상한이 없으면 지출은 무제한으로 처리되지만, 개발자가 계산된 한도에 도달하면 게이트웨이가 추론을 업스트림에 보내기 전에 즉시 HTTP 429 응답을 반환한다. 카운터는 일간, 주간 또는 월간으로 설정된 각 기간의 시작 시 자동 초기화되므로, 이 기능은 사후 비용 보고와 별개로 요청 시점의 사용자별 예산 집행을 수행한다.

🧾 핵심 주장 / 시사점

• 무상태 게이트웨이 태스크와 공용 PostgreSQL 상태 저장소를 분리한 구성은 고정 세션 없이 수평 확장할 수 있게 하면서도 인증과 지출 집행의 연속성을 유지한다.
• 정책 목록의 마지막 포괄 항목과 Claude Desktop 활성화 항목은 보안 및 기능 동작을 좌우하는 필수 설정이며, 누락 시 각각 예상보다 넓은 모델 접근이나 Desktop 추론 거부로 이어진다.
• 메트릭만 우선 전달하고 로그와 추적을 선택적으로 두는 구성은 사용자별 비용 귀속을 확보하면서 소스 코드와 프롬프트가 관측 시스템으로 노출될 가능성을 줄이는 운영 선택이다.

✅ 액션 아이템

• Claude 앱 게이트웨이를 참조 배포 방식으로 AWS Fargate 무상태 컨테이너에 올리고, 인증 상태·지출 카운터를 Amazon RDS for PostgreSQL에 집중 저장한다.
• 내부 Application Load Balancer와 Route 53 프라이빗 호스팅 영역에서 게이트웨이를 사설 네트워크로 노출하며 IAM 역할·AWS Secrets Manager로 업스트림 자격 증명을 관리한다.
• 요청 전 신원·그룹·정책·지출 한도 검증을 강제하고, 그룹별 YAML 정책으로 허용 모델·도구 권한을 서버 측에서 제한한다.

❓ 열린 질문

• OIDC 기반 브라우저 SSO에서 발급되는 기본 1시간 단기 토큰 갱신 시 조직·그룹·사용자 정책 동기화는 어떤 예외가 가장 먼저 드러날 것인가?
• AWS Secrets Manager 자격 증명과 다중 업스트림 장애·스로틀링·시간 초과 전환 순서를 결합할 때 가용성 우선순위는 어떤 규칙으로 정해야 하는가?
• 공급자 전환에서 서비스 조건·데이터 처리 지역이 바뀔 때 OTLP 비용/활동 메트릭으로 사용자별 사용량 귀속 신뢰성은 어떻게 보장할 것인가?