RSS DEV 커뮤니티
팔로우
하나의 조직인가, 여러 조직인가? 아무도 쓰고 싶어 하지 않는 사후 분석
한 금융 기관은 비용 거버넌스를 위해 비즈니스 단위를 단일 AWS Organization으로 통합했지만, 루트 노드에 서비스 제어 정책(SCP)을 잘못 적용하여 47분간의 프로덕션 중단을 야기했습니다. 통합된 비용 가시성, 단일 정책 시행, 자동화 간소화에 대한 압박이 이러한 아키텍처 결정으로 이어졌습니다. 규정 준수를 위해 AWS 리전을 제한하려는 보안 팀의 시도가 루트에 SCP를 적용하면서 의도치 않게 결제 파이프라인에 대한 중요한 DynamoDB 호출을 차단했습니다. 이는 결제 계정이 차단된 리전의 DynamoDB Global Tables 엔드포인트를 사용했고, 초기 모니터링에서 오류가 감지되지 않았기 때문에 발생했습니다.
사고 타임라인은 SDK 오류부터 서킷 브레이커 작동, 그리고 처음에는 문제 해결 노력을 잘못 유도했던 알림까지 점진적인 실패를 보여줍니다. 근본 원인은 단일 조직 아키텍처에서 비롯된, 설계상 제한되지 않은 영향 범위였으며, 단순한 인적 오류가 아니었습니다. 이 설계는 결제와 같은 규제 워크로드와 운영 워크로드 간의 격리가 부족했습니다. 계층적 SCP를 가진 단일 조직은 루트 수준의 SCP가 네이티브 점진적 롤백 없이 모든 계정에 동시에 영향을 미친다는 것을 의미합니다.
이 텍스트는 더 강력한 격리 경계를 제공하는 수정된 멀티 조직 접근 방식과 이 문제적인 단일 조직 패턴을 대조합니다. 여러 조직은 독립적인 정책 수명 주기, 별도의 관리 계정 자격 증명, 그리고 감사자가 더 쉽게 수용하는 더 명확한 규제 격리를 제공합니다. 여러 조직은 운영 복잡성과 랜딩 존 자동화 중복을 증가시키지만, 이는 해결 가능한 문제입니다. 즉각적인 기술적 수정에는 루트 또는 중요한 OU에 정책을 연결하는 것을 방지하는 가드레일 SCP 구현이 포함되었습니다.
중기적으로는 PCI-DSS 워크로드를 위한 두 번째 AWS 조직이 생성되어 보안 및 정책 독립성을 강화했습니다. AWS Organizations 이벤트를 Slack 및 PagerDuty로 캡처하여 관찰 가능성이 향상되었고, 탐지 평균 시간(MTTD)이 크게 단축되었습니다. SCP의 핵심 문제는 일반적인 인프라 코드와 달리 즉각적인 전파와 스테이징 또는 자동 롤백의 부족입니다. 이를 해결하기 위해 SCP에 대한 불변 상태 레지스트리가 구현되어 몇 초 내에 자동 롤백이 가능해졌습니다.
