Pro 시험에서 단일 서비스만 묻는 문제는 사실상 없다. 어떤 시나리오를 펼치든 IAM(누가 접근하는가), VPC(어디서 흐르는가), EC2/EBS/ELB(무엇이 그 트래픽을 처리하는가)가 동시에 등장한다. 그래서 한 주 동안 분리해서 본 세 영역을 오늘은 하나의 시나리오에서 만나는 방식 으로 다시 본다. 이게 시험장 현장에서 작동하는 진짜 사고법이다.
오늘 글의 구조는 셋이다.
1주차 한 줄 요약 40개 : 시험장에서 0.5초 안에 떠올라야 할 사실들.
3-layer 사고법 : IAM ⇒ VPC ⇒ Compute로 시나리오를 분해하는 손기술.
시나리오 12문항 : Pro 난이도, 풀이 시간 30분.
이 세 가지를 한 묶음으로 연습하면 시험장에서 시나리오를 만났을 때 손이 먼저 움직인다. Day 1에서 본 "5단계 분해"가 머릿속에서 5초 안에 작동하고, 그 5단계가 다시 IAM-VPC-Compute의 3-layer로 흐른다.
SAP-C02 = 75문항 / 180분 / 750점 합격, ESL +30분 신청 가능 (총 210분).
시나리오 5단계 분해: WHO · WHAT · WHY · CONSTRAINTS · KEYWORD. 마지막 문장의 형용사가 정답을 결정.
보기 4개 소거 4패턴: 과잉설계 / 과소설계 / 자체구현 / 잘못된 조합.
3-2-2 규칙: 한 문제 3분 이내, 답 변경 2번 이내, 2분 내 안 풀리면 flag.
first-instinct fallacy — 통계적으로 바꾼 답이 더 자주 틀린다. 확실한 근거 없으면 첫 직관 유지.
권한 평가 6층 : SCP → Permission Boundary → Identity Policy → Resource Policy → Session Policy → VPC Endpoint Policy. 6층 중 하나라도 Deny면 차단, 모두 Allow여야 통과.
Explicit deny가 모든 allow를 이긴다 — 단 하나의 명시적 Deny가 끝.
Cross-account 접근은 양쪽 모두 Allow 필요 (Trust Policy + Resource Policy 또는 Identity Policy).
SCP·Permission Boundary는 deny-only 의미 — 권한 부여 안 함, 천장(ceiling)만 정함.
STS 5종: AssumeRole / AssumeRoleWithSAML / AssumeRoleWithWebIdentity / GetFederationToken / GetSessionToken.
ExternalId 는 confused deputy 공격 방지 — SaaS 3rd party 접근 시 필수, Trust Policy에 명시.
GitHub Actions → AWS는 OIDC + AssumeRoleWithWebIdentity (long-lived key 불필요), Trust Policy의 sub claim으로 repo·branch 제한.
Multi-account SSO는 IAM Identity Center + Permission Set, SCIM(RFC 7644)으로 자동 동기화.
ABAC는 태그 기반 — aws:PrincipalTag/Project ↔ aws:ResourceTag/Project 매칭으로 정책 폭증 방지.
IAM Access Analyzer 는 Microsoft Research의 Zelkova(SMT 기반 형식 검증)로 외부 접근 자동 탐지.
RFC 1918 사설 IP: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. /16~/28 범위, IPAM으로 전사 IP 충돌 방지.
서브넷당 5개 IP 예약: .0(network) / .1(라우터) / .2(DNS) / .3(예약) / .255(브로드캐스트).
NAT Gateway는 AZ-local → 가용성 위해 AZ별 1개. 단일 NAT는 그 AZ 죽으면 outbound 전체 차단.
SG는 stateful (return 자동 허용), NACL은 stateless (양방향 명시).
NACL ephemeral port: Linux 32768-60999, Windows 49152-65535, 안전한 범위는 1024-65535.
S3·DynamoDB는 Gateway Endpoint (무료, Route Table에 prefix list), 나머지는 Interface Endpoint (시간당 $0.01 + 데이터).
PrivateLink : SaaS가 자기 NLB 뒤 서비스를 Endpoint Service로 노출, 양방향 라우팅 없음.
SG ID 참조는 같은 VPC·Peered VPC에서만 작동, Transit Gateway는 IP CIDR 참조만.
VPC Flow Logs는 ENI 5-tuple + 결과 기록, payload 없음. Traffic Mirroring은 payload 캡처.
Transit Gateway는 BGP 기반 hub-and-spoke, 5000 VPC까지, route table별 segmentation.
Direct Connect는 dedicated(전용 회선) vs hosted(파트너 공유), VIF 3종(Private/Public/Transit).
Nitro System : ASIC 기반 카드 가상화, 1% 미만 오버헤드. Network·EBS·Security·Hypervisor가 별도 카드.
Graviton (g suffix) ARM Neoverse 기반, x86 동급 대비 20-40% 가격 성능 우위. Multi-arch 컨테이너 필수.
Inferentia/Trainium ASIC은 LLM 추론·트레이닝에서 GPU 대비 60-70% 비용 절감.
gp3는 IOPS와 크기를 독립 프로비저닝 (gp2 대비 20% 저렴), 단 burst 없음.
io2 Block Express 는 NVMe-oF 기반 sub-ms latency, 256K IOPS, r5b/x2idn 전용.
EBS는 AZ-local + 3 replica 동기, 다른 AZ는 스냅샷 경유.
EBS Multi-Attach: io1/io2 + clustered filesystem(GFS2/OCFS2/OracleRAC) + 16 instance.
NLB만 정적 IP + 클라이언트 IP 보존 + 초당 수백만 패킷 (Flow hash 기반 ECMP).
ALB는 Cognito 직접 통합 (X-Amzn-Oidc-Data 헤더), gRPC 1급 지원.
Warm Pool 은 stopped 인스턴스 미리 부팅, 콜드 스타트 5분→30초.
Mixed Instances Policy + price-capacity-optimized가 Spot의 표준.
Spot은 평균 70% 할인, 2분 경고 후 회수, 다양한 패밀리로 분산.
Placement Group: Cluster(저지연 HPC) / Spread(격리 7/AZ) / Partition(HDFS·Cassandra rack-aware).
Lifecycle Hook의 default heartbeat 1시간, max 48시간, complete-lifecycle-action 호출 필수.
Pro 시나리오를 풀 때 3개 레이어 순서대로 점검하면 빠진 요소가 보인다.
┌──────────────────────────────────────────────────┐
│ Layer 1: IAM "누가 접근하나?" │
│ - SCP / Permission Boundary / IAM / Resource │
│ - Federation (SAML/OIDC), STS, ABAC │
│ - Cross-Account Role + ExternalId │
├──────────────────────────────────────────────────┤
│ Layer 2: VPC "어디로 흐르나?" │
│ - VPC CIDR, Subnet, Route Table │
│ - SG (stateful) + NACL (stateless) │
│ - VPC Endpoint (Gateway/Interface), PrivateLink│
│ - Transit Gateway, Direct Connect, VPN │
├──────────────────────────────────────────────────┤
│ Layer 3: Compute "무엇이 처리하나?" │
│ - EC2 family / pricing / Nitro / Graviton │
│ - EBS type (gp3/io2BE/st1), Snapshot, FSR │
│ - ELB 4종 (ALB/NLB/GLB/CLB) │
│ - ASG (Target/Step/Predictive/Warm Pool) │
└──────────────────────────────────────────────────┘
💡 관련 이론 : 이 3-layer는 Saltzer-Schroeder의 보안 원칙 8개 (1975) 중 "Complete Mediation"과 "Defense in Depth"를 그대로 구현한 형태다. 모든 요청은 (1) IAM에서 권한 검사, (2) VPC에서 네트워크 격리, (3) Compute에서 워크로드 실행이라는 세 게이트를 거친다. 한 게이트가 뚫려도 다른 게이트가 막아준다. Capital One 사고는 SSRF로 IAM 게이트를 뚫었지만, 만약 VPC Endpoint Policy까지 적용했다면 S3 접근이 차단됐을 것이다.
🔍 더 깊이 : 세 레이어 사이에는 **경계 변환(boundary translation)**이 있다. IAM의 Principal ARN이 VPC의 Source IP로 바뀌고(NAT 경유 시 외부에 같은 IP로 보임), Compute에서는 인스턴스 메타데이터의 IAM Role로 다시 변환된다. 이 변환 과정에서 정보가 흐려지므로, 멀티 계정 환경에서 CloudTrail로 추적할 때 user-agent + source IP + role session name을 모두 봐야 한다. 단일 변수로는 누가 한 짓인지 모를 수 있다.
시나리오 : "한 글로벌 제약사가 AWS Organizations에 80개 계정을 운영한다. 연구 부서가 임상시험 데이터를 다루기 위해 EC2 + RDS PostgreSQL을 사용한다. FDA 21 CFR Part 11 규제에 따라 모든 데이터 액세스가 감사 추적되어야 하고, 데이터는 ap-northeast-2에만 머물러야 한다. 또한 외부 SaaS(Veeva, Medidata)가 일부 데이터를 읽어야 하며, 액세스 키 사용을 금지한다. 가장 적절한 아키텍처는?"
5단계 분해 + 3-layer 매핑:
WHO : 글로벌 제약사, 80개 계정, 연구 부서 + 외부 SaaS(Veeva/Medidata).
WHAT : EC2 + RDS PostgreSQL, 임상시험 데이터.
WHY : FDA 21 CFR Part 11, 데이터 주권(ap-northeast-2).
CONSTRAINTS : 모든 액세스 감사, 액세스 키 사용 금지.
KEYWORD : 규제 + 멀티 계정 + SaaS 접근 + 키 회피.
→ 3-layer 답안:
IAM 레이어 : SCP로 ap-northeast-2 외 리전 deny. 외부 SaaS는 Cross-Account Role + ExternalId (액세스 키 회피). Org Trail로 80계정 CloudTrail 일원화. KMS custom CMK + Key Policy로 데이터 암호화.
VPC 레이어 : VPC Endpoint(S3·RDS·KMS) + Endpoint Policy로 외부 흐름 차단. 외부 SaaS는 PrivateLink로 NLB 뒤 노출. NACL/SG로 outbound 인터넷 차단(인터넷 미경유).
Compute 레이어 : EC2는 IMDSv2 강제, EBS는 KMS encrypted, RDS는 Multi-AZ + 자동 백업 + 35일 보존. RDS audit log를 CloudWatch Logs로 export.
이 한 시나리오에 1주차 학습 내용이 거의 다 들어있다. 시험장에서 손이 자동으로 3-layer를 그리고, 각 레이어에 키워드를 채워넣는 흐름이 표준 풀이법.
📝 연습 문제 선택지를 클릭하면 정답·해설이 펼쳐집니다.
한 회사가 100개 계정을 운영 중이다. 보안팀이 "production OU에서는 root user의 로그인 자체를 차단하고, MFA 없이 IAM 호출도 차단"하려 한다. 가장 적합한 방법은?
A 각 계정에서 root user 비밀번호를 삭제하고 액세스 키를 비활성화 B Organizations SCP로 production OU에 deny 정책 적용 (Condition: `aws:PrincipalType=Root`, `aws:MultiFactorAuthPresent=false`) C Lambda로 root 로그인 이벤트를 모니터링 후 SNS 알람 발송 D IAM Identity Center로 모든 사용자를 통합하고 root 사용을 정책으로 금지 한 글로벌 SaaS가 us-east-1에서 운영되며, eu-west-1로 확장한다. EU 사용자 데이터는 GDPR에 따라 EU에 머물러야 한다. 단일 코드베이스를 유지하면서 데이터 격리를 보장하려면?
A DynamoDB Global Table (양 리전 active-active 자동 복제) B RDS Cross-Region Replica (us-east-1 마스터에서 eu-west-1로 복제) C 리전별 독립 DB + Route 53 Geolocation + 인증 시점 리전 결정 D Aurora Global Database (primary us-east-1, secondary eu-west-1) 한 핀테크가 PCI-DSS 인증을 위해 모든 EC2가 us-east-1 외 리전을 사용하지 못하도록 강제하려 한다. 운영 부담을 최소화하려면?
A AWS Config Custom Rule을 모든 계정에 배포해 비인가 리전 리소스를 탐지 B Organizations SCP에 `aws:RequestedRegion ≠ us-east-1`이면 모든 액션 deny + 글로벌 서비스(IAM, Org, Route53) NotAction 예외 C Lambda를 EventBridge로 트리거해 비인가 리전 리소스를 자동 삭제 D 각 계정 IAM 정책에 리전 조건을 일일이 추가하고 신규 계정에도 수동 반영 한 회사가 EC2에서 S3에 접근한다. 트래픽이 NAT Gateway를 거쳐 월 $30,000 비용. PCI-DSS 감사에서도 "S3 트래픽이 인터넷을 거친다"고 지적. 어떻게 해결하는가?
A S3용 Interface Endpoint(PrivateLink)를 AZ마다 추가 B Gateway Endpoint 추가 + Route Table prefix list 자동 등록 C VPC Peering으로 S3를 사설 경로로 연결 D Direct Connect Public VIF로 S3에 전용 회선 연결 한 미디어 회사가 글로벌 게임 매치메이킹(WebSocket)을 운영한다. 정적 IP를 외부에 노출, 리전 장애 시 수 초 내 페일오버, 초당 100만 패킷 처리. 적합한 조합은?
A ALB + Route 53 Failover 라우팅 (Health Check 기반 DNS 페일오버) B NLB + Route 53 Health Check (latency 라우팅으로 최근접 리전 선택) C Global Accelerator + NLB (Multi-Region) D CloudFront + Lambda@Edge (엣지에서 WebSocket 종단 처리) 한 회사가 GitHub Actions에서 AWS Lambda에 배포한다. 보안팀이 "long-lived AWS Access Key를 GitHub Secrets에 저장 금지"라고 요구한다. 어떻게 해결하는가?
A 전용 IAM User를 만들고 90일 키 회전을 Lambda로 자동화 B AWS OIDC Provider 등록 + GitHub Actions에서 AssumeRoleWithWebIdentity, Trust Policy의 sub claim으로 repo·branch 제한 C GitHub Actions가 S3에 ZIP 업로드 후 S3 이벤트로 Lambda 배포 트리거 D CodePipeline + CodeBuild로 GitHub 소스를 받아 Lambda에 배포 한 회사가 야간 ETL 배치(stateless, 재시작 가능)에 EC2 100대를 4시간 운영한다. 비용 최소화 + SLA(다음날 09시 완료) 만족.
A 100대 On-Demand로 SLA 보장 우선 B 100대 3-year Standard RI로 시간당 단가 최소화 C Spot Fleet with diverse instance families (capacity-optimized) + price-capacity-optimized D 50대 3-year RI baseline + 50대 단일 패밀리 Spot 혼합 한 회사가 ALB 뒤에 인증을 적용한다. 백엔드(Node.js)는 인증 코드를 거의 안 쓰고 사용자 정보만 받고 싶다. 가장 적합한 방법은?
A 백엔드에 Passport.js + JWT 검증 구현 B ALB의 Cognito 통합 활성화 + X-Amzn-Oidc-Data 헤더 수신 C API Gateway + Lambda Authorizer로 토큰 검증 후 백엔드 전달 D CloudFront + Lambda@Edge에서 JWT 검증 후 오리진 포워딩 한 회사가 RDS MySQL을 us-east-1에서 운영하며, ap-northeast-2에 DR을 구축하려 한다. RPO 1분 이내, RTO 5분 이내. 가장 적합한 솔루션은?
A RDS Multi-AZ (동기 standby로 단일 리전 내 페일오버) B RDS Cross-Region Read Replica + 수동 promote C Aurora Global Database (RPO < 1초, RTO ~1분) D DMS continuous replication으로 타 리전 인스턴스에 지속 복제 한 SaaS가 자기 서비스를 고객 VPC 안에서 사설 IP로 사용 가능하게 하려고 한다. 표준 패턴은?
A 고객 VPC와 SaaS VPC 간 Cross-Region VPC Peering B Transit Gateway를 RAM으로 고객과 공유해 라우팅 연결 C PrivateLink + NLB + VPC Endpoint Service D Direct Connect Public VIF로 SaaS 엔드포인트 노출 한 회사가 200명 직원의 AD를 가지고 있다. AWS Organizations 80개 계정에 SSO로 접근. 직원 퇴사 시 자동으로 모든 계정에서 권한 회수. 가장 적합한 솔루션은?
A 각 계정에 IAM User를 만들고 퇴사 시 수동으로 일괄 비활성화 B IAM Identity Center + AD Connector + SCIM 자동 동기화 C 각 계정에 SAML IdP를 등록하고 AD federation으로 연결 D Cognito User Pool에 직원을 통합하고 그룹으로 계정 권한 매핑 Multi-AZ에 Private Subnet 3개를 두고 외부 API를 호출한다. 가용성을 확보하면서 비용을 최소화하려면 NAT Gateway를 어떻게 배치하는가?
A 단일 NAT Gateway를 한 AZ에 두고 3개 서브넷이 공유 (가장 저렴) B 각 AZ에 NAT Gateway 1개씩 (총 3개), 각 Private Subnet은 자기 AZ NAT 사용 C AZ마다 NAT Instance를 EC2로 직접 운영하며 ASG로 자가 복구 D Private Subnet을 IGW에 직접 라우팅해 outbound 처리
1주차는 시험의 문법과 SAA의 핵심 4개 영역(IAM·VPC·EC2·ELB)을 Pro 깊이로 복습했다. 한 줄 요약 40개와 3-layer 사고법이 시험장에서 작동하면, 처음 보는 시나리오라도 손이 자동으로 분해를 시작한다.
2주차부터는 SAP에서만 본격적으로 다뤄지는 멀티 계정 아키텍처 (Organizations·SCP·Control Tower·Identity Center)로 들어간다. 도메인 1의 26% 비중을 차지하는 영역이므로 가장 큰 ROI다. 오늘 본 시나리오 12문항을 다시 한 번 풀고, 틀린 문제는 분해법을 적용해 어디서 틀렸는지 확인하자. 시험장에서 손이 먼저 5칸을 그리는 순간이 곧 합격의 신호다.