Amazon SAP-C02: 조직 복잡성 및 다중 계정 전략 — 학습 가이드
다음의 일부입니다: AWS Solutions Architect Professional SAP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
다중 계정 전략 및 계정 벤딩
다중 계정 전략은 책임의 명확한 분리에서 시작됩니다. 즉, 보안 및 감사, 공유 네트워킹, 프로덕션 워크로드, 샌드박스 또는 개발자 계정을 분리하는 것입니다. AWS Organizations를 AWS Control Tower 또는 사용자 지정 랜딩 존과 함께 사용하면 처음부터 이러한 분리를 강제할 수 있습니다. Control Tower의 Account Factory는 계정 생성, 기준 IAM 역할, VPC 템플릿, 가드레일을 자동화하는 계정 벤딩 패턴을 제공합니다. 반면, CloudFormation/CDK와 Service Catalog로 구축된 사용자 지정 랜딩 존은 맞춤형 네트워크 및 거버넌스를 위한 더 많은 유연성을 제공합니다. 주요 트레이드오프는 운영 오버헤드와 영향 반경(blast-radius) 축소 간의 균형입니다. 계정이 많아지면 관리 영역(자동화, 교차 계정 역할, 결제 가시성)이 넓어지지만, 도메인 침해 노출을 제한하고 계정별 규정 준수를 단순화합니다. 네트워킹 선택(AWS Resource Access Manager를 사용한 VPC 공유, Transit Gateway 허브 앤 스포크, VPC 피어링을 사용한 격리된 VPC)은 비용 및 지연 시간 트레이드오프를 결정합니다. 공유 서비스(DNS, NAT, Active Directory)는 종종 네트워킹 또는 공유 서비스 계정에 위치하며, 계정 벤딩은 새 계정을 이러한 공유 리소스에 자동으로 연결하거나 위임된 VPC를 프로비저닝해야 합니다. 할당량과 자동화를 계획해야 합니다. 계정 규모가 커져도 수작업이 늘어나지 않도록 기준 아티팩트를 위한 파이프라인을 중앙 집중화해야 합니다.
거버넌스: SCP, Control Tower 가드레일, 조직 정책
다중 계정 AWS 환경의 거버넌스는 조직 수준의 정책 시행과 위임된 런타임 제어에 의존합니다. 서비스 제어 정책(SCP)은 계정 전반에 걸쳐 허용되는 작업의 상한선을 설정합니다. SCP는 강력하지만 매우 엄격해서, 루트 OU의 deny 규칙은 명시적으로 허용되지 않는 한 관리자조차 서비스 연결 역할(service-linked role)을 생성하거나 서비스를 사용하는 것을 방지합니다. Control Tower는 일반적인 SCP 및 Config 규칙을 구현하는 사전 구축된 가드레일(필수, 강력 권장, 선택)을 제공하지만, 고급 서비스 패턴에는 제한적일 수 있습니다. 설계 결정은 중앙 집중식 거버넌스와 위임된 거버넌스 중 무엇을 선택할지에 중점을 둡니다. 엄격한 루트 수준의 거부 목록은 규정 준수를 극대화하지만 제품 팀과 자동화에 마찰을 증가시키는 반면, 권한 경계(permission boundary) 및 IAM 역할 제어를 사용하는 허용적인 기준선은 개발자 속도를 높일 수 있습니다. 로깅 및 감사 정책(조직 CloudTrail, AWS Config 애그리게이터, Security Hub 및 GuardDuty 위임 관리자)은 불변의 감사 추적을 보장하기 위해 관리 계정에서 시행되어야 합니다. 실용적인 접근 방식은 계층화된 거버넌스입니다. 즉, 영향이 큰 제한을 위한 조직 SCP, 개발자 범위를 위한 권한 경계, 수동 게이팅 없이 일관성을 유지하기 위해 랜딩 존 CI/CD로 적용되는 자동화된 가드레일을 사용하는 것입니다.
보안 경계: 교차 계정 역할, KMS, 리소스 정책
교차 계정 액세스는 핵심 패턴이며 최소 권한 원칙과 강력한 신뢰 제어로 구현되어야 합니다. 일반적인 패턴은 신뢰하는 보안 주체(principal)가 STS를 통해 수임하는 각 계정의 IAM 역할을 통해 액세스를 위임하는 것입니다. CICD 배포, 모니터링(CloudWatch/SSM), 서드파티 통합을 위한 역할은 적절한 경우 MFA를 요구하고 파트너 액세스를 위해 외부 ID(external ID)를 사용해야 합니다. S3, SQS, KMS 키의 리소스 기반 정책은 직접적인 교차 계정 액세스를 가능하게 하지만, KMS는 복잡성을 더합니다. KMS 키 정책은 신뢰하는 계정의 보안 주체와 서비스를 명시적으로 허용해야 하며, 임시 액세스를 위해 권한 부여(grant) 또는 제약 조건이 있는 권한 부여(grant-with-constraints)가 필요할 수 있습니다. 로깅 또는 보안 계정에서 중앙 집중식 KMS 키를 사용하면 중앙 집중식 암호화는 단순화되지만 운영상의 결합이 발생하고 잠재적인 가용성 문제가 생길 수 있습니다. 반면, 계정별 키는 영향 반경을 줄이지만 키 교체 및 권한 부여 관리를 복잡하게 만듭니다. 일반적인 함정으로는 SCP가 의도치 않게 KMS 또는 서비스 연결 역할 생성을 거부하는 경우, SCP와 충돌하는 버킷 정책, 수집기 계정의 Config/CloudTrail에 위임 역할을 추가하는 것을 잊는 경우 등이 있습니다. 설계 결정 시에는 관리 단순성, 최소 권한 원칙, 교차 계정 지연 시간을 고려해야 합니다.
중앙 집중식 로깅, 결제 및 자동화 패턴
중앙 집중식 로깅과 결제는 엔터프라이즈 가시성의 핵심입니다. 중앙 보안 또는 감사 계정의 S3 버킷으로 전송되는 조직 CloudTrail은 변경 불가능한 이벤트 캡처를 보장합니다. 분석을 위해 Kinesis Data Firehose로 보내는 CloudWatch Logs 구독 필터로 보완하고, Config 데이터를 집계기를 사용하여 동일한 계정으로 집계합니다. 비용 가시성을 확보하려면 Organizations의 통합 결제, Cost Explorer, Budgets 및 중앙으로 전송되는 비용 및 사용 보고서가 필요합니다. Config 규칙을 통한 태그 거버넌스 및 자동화된 태그 적용은 차지백(chargeback) 정확도를 향상시킵니다. 여러 계정에 걸쳐 확장되는 자동화 패턴은 일반적으로 교차 계정 배포 역할을 수임하는 공유 CI/CD 파이프라인 또는 배포 계정을 사용하거나, 대량 프로비저닝을 위해 위임된 관리자가 있는 CloudFormation StackSets를 사용합니다. 교차 계정 패치 및 구성을 위해 Systems Manager Automation 및 State Manager를 사용하되, 각 계정에서 필요한 역할과 SSM 권한을 부여해야 한다는 점을 기억하십시오. 장단점은 중앙 집중화와 지연 시간 사이의 균형을 맞추는 것입니다. 중앙 집계는 중복 스토리지를 줄이고 분석을 단순화하지만 네트워크 및 가용성 종속성을 생성합니다. 분산 로깅은 데이터를 복제하지만 장애를 격리합니다. 보존, 수명 주기 규칙, DR을 위한 교차 리전 복제, 규정 준수 요구 사항에 부합하는 암호화 키 관리를 계획하십시오.
실제 문제: 사용 사례 시나리오
시나리오: Contoso Media는 Organizations와 Control Tower가 구축된 엔터프라이즈 AWS 환경을 운영하고 있습니다. 이 회사는 관리 계정, 공유 서비스 네트워킹 계정, 그리고 2개의 리전에서 프로덕션, 스테이징, 개발자 워크로드를 실행하는 20개의 멤버 계정을 보유하고 있습니다.
과제: Contoso는 중앙 집중식 로깅, 적절한 SCP 가드레일, Transit Gateway를 통한 공유 서비스 계정으로의 자동화된 네트워크 연결, 계정별 수동 IAM 설정이 필요 없는 배포 파이프라인을 보장하면서 15개의 새로운 프로젝트 계정을 신속하게 온보딩해야 합니다.
권장 접근 방식:
- Control Tower Account Factory 또는 자동화된 AWS Organizations API 워크플로를 사용하여 계정을 AWS Config에 등록하고, 감사 계정 S3 버킷을 가리키는 조직 CloudTrail을 활성화하며, 필수 태그를 적용하는 기준 CloudFormation/CDK 템플릿으로 계정을 생성합니다.
- OU 수준에서 영향력이 큰 거부(예: 교차 리전 키 삭제 및 허용되지 않는 리전 거부)를 강제하는 SCP를 연결하고, 개발 권한 OU는 덜 제한적으로 유지합니다. 광범위하게 적용하기 전에 샌드박스에서 SCP를 검증합니다.
- 공유 서비스 네트워킹 계정에서 Transit Gateway를 구성하고, 계정 생성 프로세스가 수임하는 위임된 관리자 또는 교차 계정 역할을 사용하여 Infrastructure-as-Code로 각 신규 계정의 Transit Gateway VPC 연결을 위한 연결(attachment)을 생성하여 연결 생성 및 라우팅 전파를 자동화합니다.
- 계정 생성 프로세스에 의해 생성된 교차 계정 IAM 역할(assume-role)을 사용하는 툴링 계정에 중앙 집중식 CI/CD 배포 파이프라인을 프로비저닝합니다. 초기 기준 프로비저닝 및 지속적인 업데이트를 위해 CloudFormation StackSets(위임된 관리자) 또는 교차 계정 CodePipeline 작업을 사용합니다.
근거: 기준 아티팩트를 사용하여 계정 생성을 자동화하면 수동 단계를 최소화하면서 거버넌스를 강화할 수 있습니다. 교차 계정 역할과 Transit Gateway를 통해 네트워크 및 배포 작업을 위임하면 공유 서비스를 중앙 집중화하고, 장애 영향 반경(blast radius)을 줄이며, 보안이나 감사 가능성을 희생하지 않고 온보딩을 확장할 수 있습니다.
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →