Claude Platform on AWS 액세스, 세 환경을 통합하지만 IAM 정밀도가 보안 결과를 좌우한다
AWS는 자격 증명과 보안 요구 사항이 크게 다른 세 가지 Claude Platform on AWS 액세스 경로를 하나의 구독 아래에서 문서화했다.
10월 1일 공개된 이 구현 방식은 AWS 워크로드, 개발자 노트북, 외부 서비스를 전용 AI Services 계정에 보유한 워크스페이스에 연결한다. 프로덕션 애플리케이션은 계정 간 Signature Version 4를 사용하고, 개발자에게는 범위가 제한된 API 키가 제공되며, 외부 워크로드는 OpenID Connect 페더레이션을 통해 인증한다.
이 아키텍처는 모든 환경에 하나의 자격 증명 모델을 강제하지 않으면서 청구와 관리를 중앙화할 수 있다고 약속한다. 동시에 긴장 요소도 분명하다. 중앙화는 소유권 관리를 단순화하지만, 광범위한 IAM 정책이나 잘못 처리된 개발자 키는 이 설계의 가치를 뒷받침하는 워크스페이스 경계를 약화시킬 수 있다.
이는 단순한 또 하나의 Claude 통합 가이드가 아니다. AWS 구현은 인증을 환경별 제어 플레인으로 전환한다. 또한 “단일 구독”이라는 표현 뒤에 숨은 운영 작업도 드러낸다.
Amazon Bedrock은 여전히 중요한 기준점이다. 이 서비스는 AWS가 관리하는 파운데이션 모델 서비스를 통해 Claude 모델을 제공한다. 반면 Claude Platform on AWS는 API, 콘솔, 플랫폼 기능을 포함해 AWS 계정을 통한 Anthropic의 네이티브 플랫폼 경험을 제공한다.
새 액세스 패턴은 이 차이를 없애지 않는다. 대신 기업이 프로덕션 트래픽에 대한 IAM 기반 제어를 유지하면서 AWS 조직 전반으로 Anthropic의 네이티브 플랫폼을 확장할 수 있는 방식을 보여준다.
하나의 구독이 이제 세 가지 신뢰 경계를 지원한다
중요한 변화는 연결성 확대만이 아니다. AWS는 워크스페이스 소유권을 중앙화한 채 세 환경을 세 가지 별도 인증 방식에 매핑했다.
제안된 토폴로지는 세 가지 계정 역할에서 시작한다. 관리 계정은 조직 수준의 청구와 거버넌스를 처리한다. 전용 AI Services 계정은 Claude Platform 구독, 워크스페이스, API 키, 액세스 역할을 소유한다.
이후 하나 이상의 워크로드 계정이 구독을 소유하지 않고 Claude 추론을 사용한다. 이들 애플리케이션은 AI Services 계정에서 역할을 수임하고, 해당 역할이 승인한 워크스페이스 리소스를 호출한다.
이 분리는 AI Services 계정에 명확한 목적을 부여한다. 관련 없는 리소스로 채워진 일반 애플리케이션 계정이 아니라, Claude 액세스를 둘러싼 관리 경계가 되는 것이다.
AWS는 해당 계정 내에서 프로덕션과 개발 워크스페이스를 분리해 만들 것을 권장한다. 워크스페이스는 중앙 관리를 유지하면서 팀, 프로젝트, 환경을 분리하는 데 사용되는 리소스 경계다.
각 워크스페이스에는 IAM 정책에서 참조할 수 있는 Amazon Resource Name, 즉 ARN이 있다. 따라서 권한은 한 워크스페이스에 대한 추론을 승인하면서 다른 워크스페이스를 자동으로 승인하지 않도록 구성할 수 있다.
첫 번째 액세스 경로는 이미 AWS 내부에서 실행되는 애플리케이션을 다룬다. AWS는 Amazon EKS 파드를 예시로 들지만, 이 패턴은 다른 AWS 워크로드에도 적용할 수 있다.
해당 파드는 먼저 AI Services 계정에서 계정 간 역할을 수임한다. 그런 다음 임시 자격 증명이 흔히 SigV4라고 부르는 AWS Signature Version 4로 Claude 요청에 서명한다.
SigV4는 AWS 자격 증명을 사용해 AWS API 요청에 암호학적 서명을 적용한다. 별도의 정적 API 시크릿 없이도 수신 서비스가 호출자, 요청 무결성, 권한 부여 컨텍스트를 검증할 수 있게 한다.
계정 간 역할은 프로덕션 워크스페이스 ARN에 대해 선택된 aws-external-anthropic 작업을 부여한다. 예시에는 추론, 토큰 수 계산, 모델 조회, 모델 목록 조회가 포함된다.
이 역할에는 개발 워크스페이스에 액세스할 권한이 필요하지 않다. 이는 워크로드 ID, 허용된 API 작업, 허용된 Claude 워크스페이스 사이에 직접적인 관계를 만든다.
두 번째 경로는 개발자 노트북을 다룬다. 개발자는 배포된 워크로드 밖에서 프롬프트, SDK 동작, 애플리케이션 로직을 테스트할 때 마찰이 적은 방식을 필요로 하는 경우가 많다.
AWS는 이 사용자들에게 개발 워크스페이스와 연결된 장기 API 키를 할당한다. 표준 Anthropic SDK는 해당 키를 지역별 Claude Platform on AWS 엔드포인트에 사용할 수 있다.
이 경로는 익숙한 개발자 경험을 유지하지만, 지속적인 베어러 자격 증명을 만든다. 키를 가진 사람은 키가 만료되거나 관리자가 폐기할 때까지 해당 권한을 사용할 수 있다.
세 번째 경로는 외부 서비스를 겨냥한다. 예로는 Google Cloud에서 실행되는 워크로드, AWS 외부 Kubernetes 클러스터, GitHub Actions 또는 GitLab CI 같은 CI/CD 시스템이 있다.
이들 서비스는 ID 공급자가 서명한 토큰을 임시 AWS 자격 증명으로 교환하는 OIDC 페더레이션을 사용한다. 임시 자격 증명은 짧은 수명의 Claude 베어러 토큰을 생성한다.
AWS의 예시는 1시간 동안 유효한 토큰을 만든다. 구현 방식은 최대 12시간까지 구성 가능한 수명을 허용하며, 이후 외부 서비스는 새 토큰을 받아야 한다.
이 세 가지 경로는 함께 Claude 다중 환경 액세스의 핵심을 이룬다. 구독은 하나의 계정에 남아 있고, 인증은 호출자가 실행되는 위치에 따라 달라진다.
이것이 아키텍처상의 진전이다. EKS 파드, 개발자 노트북, 외부 파이프라인이 하나의 범용 자격 증명 패턴을 공유해서는 안 된다는 점을 인정한다.
Claude Platform on AWS 액세스가 제어를 IAM으로 이동시킨다
Claude Platform on AWS 액세스는 이제 코드가 실행되는 위치보다 IAM이 의도된 ID와 워크스페이스를 얼마나 정확하게 기술하는지에 더 크게 좌우된다.
AWS는 기존 AWS 계정을 통해 Anthropic의 네이티브 플랫폼을 사용할 수 있는 방식으로 이 서비스를 도입했다. AWS는 자체 계정 구조를 통해 해당 네이티브 경험을 제공하는 최초의 클라우드 제공업체라고 밝혔다.
최초 출시는 인증, 청구, 감사 기능을 AWS에 연결했다. 고객은 별도의 상업적 관계를 맺지 않고 Anthropic의 API와 도구를 사용할 수 있었다.
다중 환경 설계는 이 제안을 기본적인 API 연결 이상으로 확장한다. 개별 애플리케이션이 아니라 AWS 조직 자체를 Claude 액세스를 구성하는 계층으로 만든다.
이는 기업의 AI 사용이 한 환경 안에만 머무는 경우가 드물기 때문에 중요하다. 팀은 애플리케이션을 로컬에서 테스트하고 EKS에 배포하며, 다른 클라우드에서 평가를 실행할 수 있다.
공유 정적 키는 세 위치를 모두 연결할 수 있지만, 동시에 이들의 ID를 하나로 뭉갠다. 로그에는 키가 표시될 뿐, 이를 사용한 워크로드, 계정, 파이프라인이 반드시 드러나는 것은 아니다.
계정 간 역할은 더 많은 컨텍스트를 유지한다. 워크로드는 이름이 지정된 역할을 수임하고, 임시 자격 증명을 받으며, AWS가 보안 주체에 귀속할 수 있는 서명 요청을 수행한다.
이 역할은 두 개의 권한 부여 검사 지점도 만든다. 워크로드 계정은 로컬 ID가 대상 역할을 수임하도록 허용해야 한다. AI Services 계정은 해당 ID와 조직을 신뢰해야 한다.
AWS의 예시는 신뢰 정책에 aws:PrincipalOrgID 조건을 추가한다. 이 조건은 지정된 AWS 조직과 연결된 보안 주체로 역할 수임을 제한한다.
권한 정책은 이어서 프로덕션 워크스페이스 ARN으로 추론을 제한한다. 신뢰는 누가 역할에 진입할 수 있는지를 결정하고, 권한은 그 역할이 이후 무엇을 할 수 있는지를 정의한다.
이 분리는 이전에 모델 액세스를 시크릿 배포로 취급했던 팀에 부담을 준다. 이제 이들은 Claude AWS 인증을 ID 아키텍처로 관리해야 한다.
보안, 플랫폼, 애플리케이션 팀은 계정 소유권에 합의해야 한다. 역할, 워크스페이스, 정책, 환경 매핑에 대한 명명 표준도 필요하다.
전용 계정은 이러한 책임을 가시화할 수 있다. 그러나 그것이 자동으로 올바르게 구성됨을 의미하지는 않는다.
이 아키텍처는 사고 대응에도 영향을 준다. 프로덕션 역할은 개발자 액세스를 즉시 제거하지 않고도 비활성화할 수 있다. 손상된 개발 키는 EKS 워크로드 역할을 변경하지 않고도 폐기할 수 있다.
워크스페이스 분리는 비용 귀속도 지원할 수 있다. AWS는 조직이 워크스페이스에 태그를 지정하고, 비용 할당을 위해 해당 태그를 활성화할 수 있다고 설명한다.
AWS에 따르면 활성화에는 24~48시간이 걸릴 수 있으며, 이후 팀은 워크스페이스별로 AWS Cost Explorer 데이터를 필터링할 수 있다. 이는 기술적 격리에서 프로젝트 수준 지출 분석으로 이어지는 경로를 만든다.
감사 가능성에는 또 다른 명시적 선택이 필요하다. 워크스페이스 관리는 기본적으로 CloudTrail 관리 이벤트에 나타나지만, 추론은 데이터 이벤트 범주에 속한다.
모니터링 문서에 따르면 팀은 추론과 기타 워크스페이스 작업을 기록하려면 데이터 이벤트 로깅을 활성화해야 한다. 이 이벤트는 추가 CloudTrail 요금을 발생시킬 수도 있다.
이 구분은 놓치기 쉽다. 구독을 중앙화하면 감사 추적의 가능성은 높아지지만, 추론 활동이 실제로 기록된다는 보장은 없다.
따라서 이 설계는 플랫폼 소유자가 관측 가능성을 액세스 제어의 일부로 다루도록 요구한다. 정책은 작업을 제한할 수 있지만, 로깅은 실제로 어떤 보안 주체가 해당 작업을 수행했는지에 대한 증거를 제공한다.
세 가지 인증 경로는 서로 다른 문제를 해결한다
이 아키텍처가 작동하는 이유는 편의성, 워크로드 ID, 외부 페더레이션을 같은 자격 증명 수명 주기에 억지로 넣지 않기 때문이다.
AWS 워크로드의 경우 계정 간 SigV4는 기존 클라우드 ID와 가장 깔끔하게 정렬된다. 애플리케이션은 역할을 수임해 임시 AWS 자격 증명을 받는다.
그런 다음 Claude 엔드포인트에 대한 각 요청에 서명한다. 워크로드 계정, 컨테이너 이미지, 배포 구성에 별도의 Claude API 키를 저장할 필요가 없다.
이 접근 방식은 확립된 AWS 지침을 따른다. 회사의 IAM 모범 사례는 장기 액세스 키 대신 워크로드에 임시 역할 자격 증명을 권장한다.
프로덕션 역할에는 애플리케이션에 필요한 작업만 포함할 수 있다. 기본 동기식 애플리케이션에는 추론 및 토큰 수 계산 권한이 필요할 수 있지만, 파일, 배치 또는 관리 작업은 필요하지 않을 수 있다.
Claude Platform on AWS는 aws-external-anthropic IAM 네임스페이스를 사용한다. 이 권한 모델은 메시지 요청에 대한 CreateInference 같은 특정 작업에 API 경로를 매핑한다.
이 작업은 하나의 워크스페이스 ARN을 참조할 수 있다. 애플리케이션은 계정 전체의 Claude 권한을 상속하지 않고 프로덕션 워크스페이스에 액세스한다.
이는 지속적으로 실행되는 AWS 워크로드에 세 경로 중 가장 강력한 방식이다. 애플리케이션은 영구적인 Claude 시크릿을 보유하지 않으며, AWS는 요청을 수임된 ID에 귀속할 수 있다.
개발자 노트북에는 다른 제약이 있다. 모든 로컬 실험이 계정 간 역할 체인을 거치도록 요구하면 설정 비용이 늘고 반복 작업이 느려질 수 있다.
따라서 AWS는 개발용으로 워크스페이스 범위의 API 키를 사용한다. 이 키는 표준 Anthropic 클라이언트와 작동하며 Claude Platform on AWS 지역 엔드포인트를 가리킨다.
중요한 단서는 새로 생성된 키가 이 패턴에 맞게 자동으로 충분히 좁은 범위로 제한되지 않는다는 점이다. AWS에 따르면 이 키의 기반 IAM 사용자는 처음에 AnthropicLimitedAccess 관리형 정책을 받는다.
구현 가이드에 따르면 해당 관리형 정책은 워크스페이스 전반에 대한 액세스를 부여한다. 관리자는 이를 분리하고 개발 환경으로 제한된 인라인 정책으로 교체해야 한다.
그 단계는 개발자 경로에서 가장 중요한 수동 제어 지점입니다. 키 생성은 쉽지만, 의도한 워크스페이스 경계를 강제하려면 별도의 IAM 변경이 필요합니다.
AWS는 이후에 경계를 테스트할 것을 권장합니다. 개발자는 개발 워크스페이스 호출이 성공하는지 확인한 뒤, 프로덕션 요청을 시도해 IAM이 이를 거부하는지 확인해야 합니다.
이 부정 테스트는 성공한 요청보다 더 중요합니다. 개발 응답은 연결성을 입증하지만, 프로덕션 호출이 거부되어야만 격리 주장이 검증됩니다.
API 키는 계속해서 자체 인증 방식으로 작동합니다. 키를 소지하는 것 자체가 자격 증명을 제공하므로 AWS, 다른 클라우드 또는 노트북 어디에서든 사용할 수 있습니다.
따라서 팀은 승인된 시크릿 관리자에 키를 저장하고 만료를 설정해야 합니다. 분실된 기기, 역할 변경, 실수로 인한 리포지토리 노출에 대비한 폐기 절차도 필요합니다.
외부 워크로드 경로는 이러한 영구 시크릿을 제거합니다. OIDC를 사용하면 호환되는 ID 공급자가 워크로드를 식별하는 JSON Web Token을 발급할 수 있습니다.
AWS Security Token Service는 토큰을 검증하고 역할의 신뢰 조건을 확인합니다. 이후 AssumeRoleWithWebIdentity를 통해 임시 AWS 자격 증명을 반환합니다.
OIDC guidance는 AWS 외부 애플리케이션에 이 패턴을 권장합니다. 장기 자격 증명을 내장할 필요가 없기 때문입니다.
외부 워크로드는 임시 AWS 자격 증명을 사용해 단기 Claude bearer token을 요청합니다. 이 bearer token이 생성되면 AWS 자격 증명을 보관하지 않고도 Claude를 호출할 수 있습니다.
이는 외부 컨테이너와 CI/CD 작업에 유용하지만, 토큰 갱신은 애플리케이션의 일부가 됩니다. 지속적으로 실행되는 서비스는 만료 전에 토큰을 갱신해야 합니다.
OIDC 신뢰 정책도 면밀한 주의가 필요합니다. AWS의 예시는 토큰 audience 및 subject 클레임을 예상 값과 대조합니다.
audience는 토큰의 의도된 수신자를 식별합니다. subject는 허용된 워크로드, 서비스 계정, 리포지토리 또는 파이프라인 ID를 구분합니다.
느슨한 클레임 필터는 의도보다 많은 외부 ID를 허용할 수 있습니다. 신뢰 조건이 부정확하면 올바른 페더레이션 메커니즘도 과도한 접근 권한을 만들 수 있습니다.
따라서 이 경로들은 상호 보완적이며, 서로 대체 가능한 방식이 아닙니다.
Cross-account SigV4는 이미 AWS ID로 관리되는 프로덕션 워크로드에 적합합니다.
워크스페이스 범위 API 키는 로컬 개발의 마찰을 줄입니다.
OIDC federation은 검증 가능한 워크로드 ID를 제시할 수 있는 외부 자동화에 적합합니다.
공통 요소는 워크스페이스입니다. 각 자격 증명 경로는 궁극적으로 해당 환경에 적합한 워크스페이스 권한으로 연결되어야 합니다.
중앙화가 자격 증명 위험을 제거하지는 않는다
모든 역할, 키, 신뢰 조건, 엔드포인트 및 로깅 설정이 의도한 워크스페이스와 일치할 때에만 이 설계는 격리를 개선합니다.
가장 분명한 위험은 개발자 경로에 있습니다. AWS 자체 지침에 따르면 생성된 API 키에는 처음에 모든 워크스페이스에 접근할 수 있는 관리형 정책이 부여됩니다.
관리자는 새로 생성된 백엔드 IAM 사용자를 식별하고, 해당 정책을 제거한 뒤 더 제한적인 인라인 정책을 연결해야 합니다.
이 워크플로는 인적 오류에 취약합니다. 관리자가 잘못된 사용자의 범위를 지정하거나, 관리형 정책을 그대로 두거나, 잘못된 워크스페이스 ARN을 참조할 수 있습니다.
그 결과로 생성된 키는 여전히 작동합니다. 개발 요청의 성공만으로는 해당 키가 프로덕션 접근 권한도 유지하고 있다는 사실을 드러낼 수 없습니다.
의무적인 거부 테스트는 이 실수를 잡아낼 수 있습니다. 조직은 프로덕션 접근 테스트를 나중에 선택적으로 수행하는 검증이 아니라 키 발급 절차의 일부로 만들어야 합니다.
장기 키는 역할 기반 접근보다 추적성도 약합니다. 여러 개발자가 하나의 키를 공유하면 감사 기록에서 동일한 주체로 나타날 수 있습니다.
개별 키는 추적성을 개선하지만, 안전한 저장, 만료, 폐기 및 소유권 추적이 필요한 자격 증명의 수를 늘립니다.
Cross-account 경로에는 다른 실패 모드가 있습니다. 신뢰 정책이 지나치게 광범위할 수 있고, 워크로드 측의 역할 수임 권한이 잘못된 대상 역할에 도달할 수 있습니다.
aws:PrincipalOrgID 조건은 조직 범위를 제한하는 데 도움이 됩니다. 하지만 정확한 주체 ARN이나 신중한 역할 명명을 대체하지는 못합니다.
권한 역시 작업 수준에서 검토해야 합니다. aws-external-anthropic 네임스페이스 전반에 와일드카드 접근을 부여하면 가이드의 최소 권한 구조가 약화됩니다.
AWS는 단일 워크스페이스 추론 및 기타 제어를 위한 상세한 IAM policy examples를 제공합니다. 팀은 배포된 정책을 실제로 사용하는 API 기능에 맞춰 검증해야 합니다.
OIDC 경로는 보안을 외부 ID 클레임 쪽으로 옮깁니다. 이 경로의 안전성은 발급자, audience, subject 필터, 역할 정책 및 토큰 갱신 로직이 함께 올바르게 작동하는지에 달려 있습니다.
전체 리포지토리 그룹을 포괄하는 subject 패턴은 관련 없는 파이프라인까지 인증할 수 있습니다. 광범위한 서비스 계정 패턴은 의도한 네임스페이스 외부의 워크로드를 허용할 수 있습니다.
임시 자격 증명은 노출 기간을 제한하지만, 해당 기간 동안의 과도한 권한을 바로잡지는 못합니다. 단기 접근은 영구 접근보다 안전하지만, 자동으로 최소 권한 접근이 되는 것은 아닙니다.
생성된 Claude 토큰도 독립적인 bearer 자격 증명이 됩니다. 만료 전까지는 이를 소지하는 것만으로 상속된 권한 경계 안에서 사용할 수 있습니다.
애플리케이션은 이를 로그, 빌드 출력, 예외 추적 또는 모니터링 메타데이터에 출력하지 않아야 합니다. 가능하다면 토큰 수명은 작업 지속 시간에 맞춰야 합니다.
리전 동작은 또 다른 운영 제약을 더합니다. 워크스페이스는 AWS Region에 생성되며, API 요청은 해당 리전의 엔드포인트를 대상으로 해야 합니다.
AWS는 이 엔드포인트 바인딩을 추론 지역과 구분합니다. 워크스페이스의 보안 설정은 추론이 US 또는 글로벌 라우팅을 사용하는지 독립적으로 결정합니다.
단기 키는 생성된 동일한 리전 엔드포인트에서만 작동합니다. AWS 가이드에 따르면 장기 API 키는 리전에 고정되지 않습니다.
이 차이로 인해 배포 중 혼란스러운 실패가 발생할 수 있습니다. 토큰 갱신 프로세스는 한 리전에서 성공하지만 애플리케이션은 다른 엔드포인트를 가리킬 수 있습니다.
이 아키텍처에는 구매자가 이해해야 하는 더 넓은 경계도 있습니다. AWS는 Claude Platform on AWS가 Anthropic에 의해 운영되며, 요청과 데이터는 AWS 보안 경계 밖에서 처리된다고 설명합니다.
이는 모든 처리가 AWS가 제어하는 서비스 경계 내에 남는다는 가정과 이 서비스를 구별합니다. 엄격한 데이터 레지던시 요건이 있는 조직은 별도의 검토가 필요합니다.
AWS는 Claude Platform on AWS를 Amazon Bedrock을 통해 제공되는 Claude 모델과 상호 보완적인 서비스로 제시합니다. 따라서 선택지는 단순히 하나의 인증 방식과 다른 하나를 비교하는 문제가 아닙니다.
여기에는 플랫폼 기능, 운영 소유권, 처리 경계 및 리전 요건이 포함됩니다. 다중 환경 접근만으로는 모든 워크로드에서 이러한 질문이 해결되지 않습니다.
중앙화는 관리상 실수의 영향 범위도 넓힐 수 있습니다. AI Services 계정은 구독, 워크스페이스, API 키 및 접근 역할을 보유합니다.
이 계정의 변경 하나가 여러 애플리케이션 계정에 동시에 영향을 줄 수 있습니다. 따라서 이 설계에서는 일상적인 개발 환경보다 이 계정에 더 강력한 변경 통제를 적용해야 합니다.
팀은 가능하면 정책 작성과 승인을 분리해야 합니다. Infrastructure as code는 추가 팀과 워크스페이스 전반에서 일관성 없는 역할 정의를 줄이는 데도 도움이 됩니다.
AWS는 더 많은 환경을 가진 조직이 팀 또는 워크로드별로 워크스페이스를 만들고 Cross-account 역할 패턴을 반복할 수 있다고 설명합니다.
이 접근 방식은 격리 모델을 확장하지만, 정책, 역할 관계, 로그, 태그 및 엔드포인트 구성도 늘어납니다. 운영 규율이 제한 요인이 됩니다.
따라서 중앙화의 핵심 약속은 신중하게 표현해야 합니다. 이 패턴은 워크스페이스 격리를 위한 구성 요소를 제공하지만, 배포된 정책과 자격 증명 처리가 그 격리가 유지되는지를 결정합니다.
기업이 다음으로 검증해야 할 사항
다음 테스트는 세 가지 인증 흐름이 데모에서 작동하는지가 아니라, 조직이 이 접근 모델을 일관되게 운영할 수 있는지입니다.
첫 번째 신호는 자동화된 정책 검증입니다. 팀은 모든 프로덕션 역할이 하나의 예상 워크스페이스 ARN과 필요한 API 작업만을 대상으로 하는지 확인해야 합니다.
개발자 키 발급에는 정책 교체, 만료, 시크릿 저장 및 강제된 프로덕션 접근 거부 테스트가 포함되어야 합니다. 기억에 의존하는 절차는 결국 표준에서 벗어나게 됩니다.
조직이 배포 파이프라인을 통해 이러한 검사를 자동화한다면 AWS의 중앙화 모델은 대규모 환경에서 더 신뢰할 수 있게 됩니다. 반복적인 수동 예외는 그 결론을 약화시킬 것입니다.
두 번째 신호는 감사 범위입니다. CloudTrail 관리 이벤트만으로는 호출별 추론 가시성을 제공하지 않습니다.
조직은 관련 Claude 워크스페이스 리소스 유형에 대해 데이터 이벤트를 활성화하고, 기록에 유용한 주체 추적 정보가 포함되는지 검증해야 합니다.
또한 사고 대응자가 요청을 EKS 역할, 개발자 키 또는 외부 OIDC ID와 연결할 수 있는지 테스트해야 합니다.
감사 경로가 이러한 구분을 보존한다면 세 경로 아키텍처는 책임 있는 접근을 지원합니다. 로그가 호출자를 공유 ID로 평준화한다면 중앙화의 조사 가치는 낮아집니다.
세 번째 신호는 AWS 네이티브 애플리케이션을 넘어선 도입입니다. OIDC 경로는 외부 클라우드, Kubernetes 배포 및 CI/CD 시스템을 위해 설계되었습니다.
실질적인 시험대는 장기 실행 작업 중 안정적인 토큰 순환입니다. 팀은 리포지토리와 서비스 계정이 변경될 때도 좁은 subject 및 audience 클레임을 유지해야 합니다.
빈번한 인증 실패는 개발자가 장기 시크릿으로 되돌아가게 만들 수 있습니다. 정확한 신뢰 조건을 갖춘 안정적인 갱신은 페더레이션 접근 방식을 강화합니다.
기업은 워크스페이스 확산도 모니터링해야 합니다. 팀 또는 워크로드마다 하나의 워크스페이스를 생성하면 격리, 소유권 및 비용 배분을 개선할 수 있습니다.
일관된 레이블과 수명 주기 규칙 없이 워크스페이스가 너무 많아지면 또 다른 형태의 난립이 발생할 수 있습니다. 오래된 키, 방치된 역할 및 사용하지 않는 워크스페이스에는 폐기 절차가 필요합니다.
전용 AI Services 계정은 관리되는 서비스 경계가 되어야 합니다. 관리자는 모든 워크스페이스, 역할 및 자격 증명에 대한 소유권 기록을 보유해야 합니다.
플랫폼 팀은 애플리케이션 아키텍처 및 사고 절차와 함께 접근 결정 사항을 기록할 수 있습니다. 검색 가능한 engineering knowledge base는 팀이 바뀌어도 이러한 매핑을 보존하는 데 도움이 될 수 있습니다.
가장 유용한 평가는 하나의 완전한 애플리케이션 경로에서 시작합니다. 프로덕션 워크로드는 SigV4로, 개발 클라이언트는 제한된 키로, 파이프라인은 OIDC로 연결하십시오.
그런 다음 거부된 워크스페이스 간 요청, 토큰 갱신, CloudTrail 데이터 이벤트 및 긴급 폐기를 검증하십시오. 이러한 제어는 일상적인 정책 변경 이후에도 계속 유지됩니까?
그 답은 성공적인 첫 요청보다 더 중요합니다. Claude Platform on AWS 접근은 이제 하나의 구독 아래 세 환경을 지원하지만, 그 보안 가치는 반복 가능한 격리 증명에 달려 있습니다.
