Day 5 - Week 1 종합: 시나리오로 단단해지는 기초와 IAM

한 주 동안 글로벌 인프라부터 멀티 계정 거버넌스까지 훑었다. 머리로는 다 안다고 느껴도, SAA-C03 시험은 항상 한 줄짜리 시나리오로 변형해서 묻는다. "본사 밖으로 데이터가 못 나간다"라는 한 문장에서 Outposts가 떠올라야 하고, "TCP 게임 서버 글로벌 지연 최소화"에서 Global Accelerator가 즉시 튀어나와야 한다. 시험은 키워드를 외운 사람을 거르는 게 아니라 "이 시나리오의 본질이 무엇이냐"를 빠르게 판단할 수 있는 사람을 뽑으려 한다.

이 글은 Week 1을 다시 정리하면서 시나리오 키워드 → 솔루션 매핑을 머리에 새기는 시간이다. 단순 암기가 아니라 "왜 그 답인지"를 한 번 더 짚는다. 시나리오 매핑은 시험 전날 다시 한 번 통독하면 합격선이 확실히 올라가는 영역이기도 하다. 그리고 실무에서는 이 매핑이 곧 "사고가 나기 전에 다른 사람이 짠 설계를 검토하는 능력"이 된다 — 1주차에서 본 모든 사건(Capital One, us-east-1, 도쿄 AZ, SolarWinds, Travis CI)이 결국 누군가가 같은 매핑을 헷갈렸을 때 일어났다.

Week 1 그림 다시 그리기

[ AWS Global Infrastructure ]
       │
       ├── Region (34) ──┬── AZ (3+) ──┬── DC
       │                 │             └── DC
       │                 └── AZ ── DC
       ├── Edge Location (600+) ── CloudFront / R53 / GA / WAF
       ├── Local Zone (30+) ── 미니 리전
       ├── Wavelength ── 5G 엣지
       └── Outposts ── 고객 DC

[ Identity ]
   User / Group / Role / Policy
       │
   AssumeRole (STS) → 임시 자격 증명
       │
   ┌─── External ID (Confused Deputy 방어)
   ├─── Permissions Boundary (권한 상한)
   ├─── ABAC (태그 기반)
   └─── OIDC/SAML (페더레이션)

[ Multi-Account ]
   Organizations → OU 트리
       │
   ┌─── SCP (계정 권한 상한)
   ├─── Control Tower (자동 Landing Zone)
   ├─── RAM (리소스 공유)
   └─── StackSets (일괄 배포)

이 세 영역이 Week 1의 결론이고, Week 2 ~ Week 12의 모든 서비스가 이 세 평면 위에 얹어진다고 보면 정확하다. 네트워킹은 AZ 위, 보안은 IAM 위, 다계정 패턴은 Organizations 위에서 동작한다. 그리고 이 세 평면의 교집합 — "어느 계정의 어느 리전 어느 AZ에 있는 리소스에 누가 무엇을 할 수 있는가" — 가 결국 모든 SAA 시나리오의 좌표계가 된다.

이 3층 모델은 사실 분산 시스템 보안의 고전적인 3축 — Where(위치), Who(신원), What(자원) — 을 클라우드 운영에 매핑한 것이다. 1985년 NIST가 정의한 보안 3요소(Confidentiality / Integrity / Availability)에 더해, 2003년 NIST SP 800-53이 명문화한 Access Control(AC), Audit & Accountability(AU), System and Communications Protection(SC) 세 영역이 거의 일대일로 매칭된다. AC는 IAM, AU는 CloudTrail/Config, SC는 VPC/네트워크 컨트롤로 구현된다.

이 3층은 실제 AWS의 권한 평가 엔진에서도 그대로 반영된다. AWS Zelkova(IAM 정형 검증)와 Tiros(네트워크 정형 검증)는 각각 IAM/SCP 정책과 VPC 라우팅을 SMT 제약으로 변환해서 "이 요청이 도달 가능한가"를 푼다. 2018년 USENIX Security 논문 "Semantic-based Automated Reasoning for AWS Access Policies"가 Zelkova의 기반이고, 같은 해 발표된 "Reachability Analysis for AWS-based Networks"가 Tiros의 기반이다. Access Analyzer, Reachability Analyzer, IAM Access Advisor가 모두 이 위에서 돌아간다.

시나리오 키워드 매핑

이 표는 시험 전날 30분이면 통독되고, 같은 매핑을 5번 이상 반복해서 보면 시험장에서 시나리오 첫 줄만 보고 후보 답이 떠오른다. 키워드 → 솔루션 매핑은 SAA의 "패턴 인식 시험"적 성격을 가장 잘 보여준다.

⚠️ 함정: 같은 키워드가 다른 답으로 가는 경우도 많다. "암호화"는 KMS인가 CloudHSM인가? 단일 회사 사용이면 KMS, FIPS 140-2 Level 3 규제(FedRAMP High, 일부 금융)면 CloudHSM. "DR"은 Multi-AZ인가 Cross-Region인가? AZ 단위 격리는 Multi-AZ, 리전 단위 격리는 Cross-Region. 키워드만 보지 말고 "이 시나리오의 위협 모델이 무엇이냐"를 함께 봐야 한다.

CAP/PACELC와 AWS 서비스 매핑

SAA에서 직접 묻지는 않지만, 시나리오 해석에 결정적이다. 분산 시스템의 trade-off를 모르면 "왜 이 옵션이 강한 일관성을 못 주는가" 같은 질문에 답을 못 한다. 그리고 이 매핑은 실무에서도 "왜 우리 서비스의 글로벌 일관성이 깨졌는가"를 디버깅할 때 직접 쓰인다.

DynamoDB의 strong consistency는 단일 리전 안에서만 옵션으로 제공되고(ConsistentRead=true), Global Table은 항상 eventual이다. Global Table의 충돌 해결은 Last-Writer-Wins(LWW) 기반이라 동시 쓰기 시 데이터 손실 가능성이 있다. 그래서 멀티 마스터 글로벌 쓰기가 필요하면 DynamoDB Global Table을 쓰되 "타임스탬프 충돌이 비즈니스적으로 허용 가능한가"를 먼저 따져야 한다. 더 엄격한 일관성이 필요하면 CRDT(Conflict-free Replicated Data Type)나 Paxos/Raft 기반 합의 알고리즘이 필요한데, AWS는 이를 Aurora의 quorum-based replication(6-way write across 3 AZ, 4/6 read, 3/6 write 쿼럼)으로 일부 제공한다. Aurora 논문 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases(SIGMOD 2017)가 이 아키텍처의 정수다.

사례: 2015년 GitHub은 자체 MySQL 클러스터 분할 사고로 24시간 동안 데이터 일관성이 깨졌다. 두 데이터센터 간 네트워크 분할이 발생했고, 양쪽 모두 자신이 primary라고 판단해 쓰기를 받아버린 split-brain 사건이다. 사후 분석 보고서에서 GitHub은 "분할 시 우리는 CP를 선택하고 가용성을 포기한다"고 명시했다. 이런 사례는 CAP의 trade-off가 추상적 이론이 아니라 매일 운영자가 마주하는 결정임을 보여준다. AWS는 RDS Multi-AZ에서 같은 결정을 내렸고, 그래서 페일오버 동안 60초 정도 가용성이 끊긴다.

⚠️ 함정: "Aurora는 strong consistent이므로 글로벌 DB도 같다"고 가정하면 틀린다. Aurora Global Database는 storage-level async replication(보통 1초 RPO)이고 secondary 리전은 read-only다. 글로벌 쓰기를 원하면 DynamoDB Global Table을 써야 하지만 그건 LWW의 충돌 위험을 받아들여야 한다. 또 "ElastiCache Redis Cluster Mode는 ASync replication이지만 multi-AZ 페일오버로 가용성 보장"이라고 보는 것도 부분적으로 틀리다 — 페일오버 시 ack되지 않은 쓰기는 손실될 수 있다.

공동 책임 모델 재정리

서비스 추상화가 올라갈수록 책임 경계선이 위로. 그래도 데이터 분류·IAM·암호화 키 관리는 항상 고객이라는 점이 핵심. 이 원칙은 Capital One 사고가 가장 명확하게 보여준다 — AWS는 자기 인프라 책임을 다했고, 사고는 고객 영역의 WAF 오설정(SSRF)·IMDSv1·과한 IAM 권한에서 났다.

사례: 2022년 6월 Toyota 자회사가 GitHub 공개 저장소에 5년간 액세스 키가 노출된 사고가 있었다. 약 30만 명 고객 데이터가 위험에 노출됐고, 원인은 개발자가 코드와 함께 자격 증명을 푸시한 것이었다. AWS 책임은 0% — 모든 게 고객 책임 영역에서 일어났다. 사후 표준 권고는 ① IAM User 대신 IAM Role + IRSA/Instance Profile, ② Access Key를 발급해야 한다면 IAM Identity Center의 임시 자격 증명, ③ Git pre-commit hook(git-secrets, truffleHog)으로 커밋 차단. 같은 패턴의 사고가 Uber(2016), Imperva(2019), Codecov(2021)에서도 반복됐다.

공동 책임 모델은 서비스마다 미묘하게 다르다. RDS는 DB 엔진 패치(minor version)는 AWS, major version 업그레이드는 고객 선택. Lambda는 런타임 패치는 AWS, 런타임 EOL 후 마이그레이션은 고객(Node 14 → 18 등). ECS Fargate는 컨테이너 OS·런타임은 AWS, 이미지 안의 OS 패키지 패치는 고객. 이 미묘한 차이가 시험 함정으로 쓰인다. AWS Trusted Advisor와 AWS Security Hub의 Foundational Security Best Practices(FSBP)가 이런 책임 경계를 자동 점검해준다.

정책 평가 결정 트리

요청 → SCP(Org) → Resource Policy → Identity Policy → Permissions Boundary → Session Policy
   각 단계에서 명시 Deny → 즉시 DENY
   모든 단계 통과 → ALLOW
   어느 곳도 Allow 없음 → DENY (default)

같은 계정 = 합집합, 교차 계정 = 교집합, KMS = Key Policy 명시 위임 필수. 이 세 줄이 IAM 평가 로직의 전부다. 면접에서 "AWS IAM 평가 로직을 1분 안에 설명해보라"는 질문을 받았다면 이 세 줄이 답이다.

함정: "Resource Policy만 Allow하면 Cross-Account가 된다"는 보기는 오답이다. 같은 계정이면 그게 맞지만, 교차 계정에서는 호출자 계정의 Identity Policy에서도 Allow가 있어야 한다. 또 KMS는 별격이다 — Key Policy에서 명시적으로 IAM에게 위임("Enable IAM User Permissions" statement)하지 않으면 IAM 정책에서 Allow를 줘도 KMS 키를 못 쓴다. 이는 KMS가 "키 소유자가 최종 권한자"라는 모델이기 때문이다.

정책 평가는 사실 6개 정책 타입의 교차로 결정된다 — SCP, Resource Policy, Identity Policy, Permissions Boundary, Session Policy, VPC Endpoint Policy. AWS 공식 문서의 "Policy Evaluation Logic" 흐름도가 가장 정확한 레퍼런스다. 각 정책 타입의 "Allow 필요 vs 선택"이 시나리오마다 다르다. 한 마디 요약: 명시 Deny는 항상 최종, Allow는 모든 경계를 통과해야.

이 모델은 보안 이론의 Mandatory Access Control(MAC)과 Discretionary Access Control(DAC)의 혼합이다. SCP와 Permissions Boundary는 MAC(상위 권한자가 강제하는 한도), Identity/Resource Policy는 DAC(소유자가 자유롭게 설정). 미국 군사 보안 표준 Bell-LaPadula Model(1973)의 multilevel security 개념과 유사하다. AWS가 정책 평가를 SMT solver로 푸는 것도 이 모델이 형식 검증 가능한 구조를 갖기 때문.

다계정 표준 토폴로지

이 토폴로지는 AWS Security Reference Architecture(SRA) 문서에 권장 형태로 명시되어 있다. 모든 대기업 고객이 이 변형을 쓴다고 보면 정확하다. Netflix, Capital One, Airbnb, Slack 등의 공개 발표 자료를 보면 거의 같은 패턴이 반복된다.

사례: 2019년 Netflix Tech Blog는 자사 다계정 전략을 공개했는데, 1,000개 이상의 AWS 계정을 운영하면서 워크로드별·팀별·환경별로 계정을 잘게 쪼개는 "Account per Workload" 패턴을 표준화했다고 밝혔다. 이유는 ① 블래스트 반경 제한, ② 비용·태그 자동화, ③ IAM 권한 단순화. 같은 패턴을 Spotify, Lyft, Stripe도 채택했고, 이게 SRA가 권장하는 토폴로지의 실제 모델이다. 2023년 기준 큰 회사는 보통 100~5,000 계정을 운영하고, AWS Organizations의 한도(10,000 계정/Org)가 사실상 상한이다.

다계정 운영의 실무 핵심은 두 가지 자동화다. ① 계정 발급 자동화 — Control Tower의 Account Factory 또는 Account Factory for Terraform(AFT)으로 새 계정 생성 → 베이스라인 적용 → 권한 부여 → 알림이 GitOps 흐름으로 묶인다. ② 베이스라인 자동 배포 — CloudFormation StackSets의 SERVICE_MANAGED + auto-deployment=Enabled 옵션으로 새 계정에 자동으로 보안 베이스라인(GuardDuty, Config Rules, IAM Password Policy, S3 BPA 등)이 들어간다. 이 두 자동화가 없으면 100계정 운영은 사람으로 불가능하다.

자주 헷갈리는 핵심 비교

함정: ZoneName vs ZoneId는 시험에 자주 안 나오지만, 실무에서는 "다른 계정과 같은 AZ 쓰기"를 묻는 보안·비용 시나리오에서 결정적이다. CloudFront vs Global Accelerator는 시험에서 자주 비교되는 짝이고, 키워드 "TCP/UDP", "게임", "VoIP", "MQTT", "WebRTC 시그널링"이 보이면 무조건 GA. CloudFront Functions vs Lambda@Edge도 같은 비교 축인데, "수 ms 미만 응답"이면 Functions, "Node.js/Python 런타임 풀 사용"이면 Lambda@Edge.

AWS는 같은 기능을 여러 서비스로 제공할 때 항상 trade-off 축이 다르다. KMS vs CloudHSM은 추상화 vs 격리도, ALB vs NLB는 L7 기능 vs L4 throughput, SQS vs SNS vs EventBridge는 point-to-point vs fanout vs schema-routing. SAA 시험은 항상 "어느 축에서 trade-off를 묻고 있느냐"를 식별해야 한다. 이 사고법을 익히면 모르는 새 서비스도 동일한 축 위에 매핑해서 후보 답을 좁힐 수 있다.

정리

Week 1은 "AWS라는 우주의 좌표계"를 머리에 박는 시간이었다. Region/AZ/Edge의 격리 모델, IAM의 정책 평가, 다계정의 거버넌스. 이 셋이 나머지 11주 모든 주제의 배경이 된다. 다음 주는 그 위에 네트워킹(VPC, 서브넷, 라우팅)을 얹는다. 한 번에 다 이해하려 하지 말고, 시나리오 문제 풀 때마다 이 표를 다시 펴서 매핑하는 습관을 들이면 시험 직전엔 키워드 → 솔루션 매핑이 자동 반사로 박힌다. 그리고 그 자동 반사가 SAA 합격뿐 아니라 실무 설계에서도 "30분 미팅 안에 솔루션 후보 3개를 그릴 수 있는" 시니어 엔지니어의 핵심 역량이다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 글로벌 게임 회사가 전 세계 사용자에게 일관된 TCP 기반 게임 서버 응답 시간을 제공하려 한다. 가장 적합한 솔루션은?

• ACloudFront + Lambda@Edge — 엣지 PoP 600여 곳에 HTTP 콘텐츠를 캐시하고 Node.js 로직까지 실행하지만, L7 HTTP/HTTPS 전용이라 게임의 raw TCP 세션은 가속하지 못함
• BGlobal Accelerator
• CRoute 53 Latency Routing — 클라이언트를 지연 최소 리전 엔드포인트로 DNS 응답하지만, TTL 캐싱에 묶이고 실제 패킷은 공용 인터넷을 그대로 타 백본 가속이 없음
• DElastiCache Global Datastore — 리전 간 1초 미만으로 Redis 데이터를 복제하는 캐시 계층일 뿐, 게임 서버 TCP 트래픽 라우팅과는 무관함

문제 2

한 금융 회사가 한국 금융감독원 규정으로 일부 데이터를 본사 내부에 보관하면서도 AWS API로 운영해야 한다. 가장 적합한 솔루션은?

• ADirect Connect만 사용 — 본사와 AWS 리전을 전용 회선으로 저지연 연결하지만, 데이터 자체는 결국 AWS 리전에 저장되므로 "본사 내부 보관" 규제 요건을 충족하지 못함
• BLocal Zones — 주요 도시에 배치된 AWS 운영 미니 시설로 저지연을 주지만, 고객 건물이 아닌 AWS 데이터센터라 데이터 주권 요건에 부적합
• COutposts
• DSnowball Edge — 페타바이트급 데이터를 오프라인으로 옮기거나 단기 엣지 컴퓨팅에 쓰는 일회성 장비라, 상시 AWS API 운영 플랫폼으로는 부적합

문제 3

한 회사가 50개 AWS 계정에서 us-east-1 외 모든 리전 사용을 차단하려 한다. 가장 효율적인 방법은?

• A각 계정마다 IAM 정책 추가 — 50개 계정의 모든 사용자·역할에 동일 정책을 일일이 붙여야 해 관리가 폭증하고, 새 신원이 생길 때마다 누락 위험이 커 거버넌스로 부적합
• BOrganizations SCP로 aws:RequestedRegion 조건 Deny
• CCloudTrail 알림 — 리전 사용을 사후에 로그로 탐지·알림할 뿐, API 호출 자체를 막지 못해 예방적 차단이 되지 못함
• DVPC를 us-east-1에만 생성 — VPC가 없어도 리전 단위 글로벌 서비스나 S3·DynamoDB 같은 서비스는 다른 리전에서 그대로 호출되므로 차단이 불완전함

문제 4

EC2가 S3에 접근하는 가장 안전한 방식은?

• AAccess Key를 ~/.aws/credentials에 저장 — 장기 자격 증명이 디스크에 평문으로 남아 인스턴스 침해 시 그대로 탈취되고, 수동 키 회전 부담까지 더해져 위험함
• BIAM Role을 Instance Profile로 attach + IMDSv2
• Croot Access Key 사용 — 계정 전체 무제한 권한을 가진 최상위 자격 증명이라 노출 시 피해가 계정 전역으로 번지며 AWS도 절대 사용 금지로 권고함
• DS3 Public Read 허용 — 인증 없이 누구나 객체를 읽게 만들어 데이터 유출로 직결되고, EC2 접근 제어와는 정반대 방향의 설정임

문제 5

GitHub Actions가 AWS에 배포할 때 키 회전 부담을 없애려면?

• AIAM User Access Key를 Secret으로 저장 — GitHub Secrets에 장기 키를 보관해 동작은 하지만, 정기 수동 회전 부담이 남고 로그 노출 시 그대로 탈취되는 Travis CI 침해와 동일한 위험을 안음
• BOIDC 페더레이션으로 Role 단명 자격 증명
• CEC2를 띄워 SSH 키 — 배포마다 별도 EC2와 SSH 키를 관리해야 해 운영이 복잡해지고, 키 자체가 또 다른 장기 시크릿이 되어 회전 부담을 없애지 못함
• Droot 자격 증명 — 계정 전역 무제한 권한을 CI에 노출하는 것으로, 최소 권한 원칙을 정면으로 위반하는 최악의 선택임

문제 6

한 SaaS가 우리 AWS의 CloudWatch 로그를 수집한다. Confused Deputy 방어를 위해 필요한 것은?

• ACross-Account Role + External ID 조건
• BIAM User에 Access Key 부여 — SaaS에 장기 Access Key를 넘기는 방식으로 키 유출·회전 부담이 크고, Confused Deputy(혼동된 대리인) 문제 자체를 전혀 해결하지 못함
• CS3 Public Read — 로그 버킷을 공개로 열어 누구나 읽게 만드는 데이터 유출 설정으로, 안전한 위임 수집과는 정반대임
• DVPN 연결 — 네트워크 계층 터널만 제공할 뿐, SaaS가 우리 계정 역할을 빌릴 때의 신원 위임·권한 경계 문제와는 무관함

문제 7

한 회사가 새 AWS 계정을 매주 10개씩 발급하면서 동일한 보안 베이스라인을 적용하려 한다. 가장 적합한 방법은?

• A운영자가 매번 수동 설정 — 매주 10개 계정마다 사람이 베이스라인을 손으로 적용해야 해 누락·드리프트가 불가피하고, 규모가 커질수록 운영이 무너짐
• BControl Tower Account Factory + StackSets auto-deployment
• CCloudFormation을 각 계정에서 수동 실행 — 템플릿은 일관되지만 새 계정마다 사람이 직접 스택을 실행·교차 계정 역할을 설정해야 해 자동 전파가 빠짐
• DTerraform Apply를 매번 실행 — IaC로 표준화는 되지만 새 계정 생성·등록을 별도 파이프라인으로 묶지 않으면 매번 수동 트리거가 필요해 완전 자동화에 미치지 못함

문제 8

한 회사가 신입 개발자에게 IAM Role을 자유롭게 만들 권한을 주되, AdministratorAccess급 Role 생성은 막고 싶다. 가장 적절한 방법은?

• ACloudTrail로 사후 감지 — Role 생성을 로그로 남겨 사후 추적은 가능하지만, 과한 권한 Role이 만들어지는 것 자체를 사전에 막지 못해 예방적 통제가 아님
• BPermissions Boundary를 강제 첨부 조건으로 정책에 명시
• C신입 권한을 모두 회수 — Role 생성 권한 자체를 빼앗는 것이라 "자유롭게 만들되 상한만 둔다"는 요구를 정면으로 위반함
• DOrganizations SCP만 사용 — 계정·OU 단위 상한이라 같은 계정 안에서 개별 Role마다 다른 한도를 강제하기엔 입자도가 너무 거칠어 부적합

문제 9

한 AZ에서 냉방 장애로 EC2가 다운된다. 이미 ASG가 multi-AZ로 구성되어 있다면?

• A모든 서비스 다운 — multi-AZ ASG가 살아있는 AZ에 인스턴스를 보충하므로, 한 AZ 장애로 전체가 내려간다는 전제 자체가 HA 설계와 모순됨
• BASG가 다른 AZ에 자동으로 인스턴스 보충, 서비스 유지
• CRDS Multi-AZ도 같이 다운 — RDS Multi-AZ는 standby가 다른 AZ에 있어 30~60초 내 자동 페일오버하므로, 함께 영구 다운된다는 설명은 틀림
• D수동 페일오버 필요 — ASG health check와 ELB가 자동으로 비정상 인스턴스를 교체·재분산하므로, 운영자의 수동 개입이 필요하지 않음

문제 10

다음 중 AWS 책임이 아닌 것은?

• A하이퍼바이저 보안 — Nitro 등 가상화 계층은 AWS가 설계·패치·격리하는 "클라우드의 보안" 영역이라 전적으로 AWS 책임임
• B게스트 OS 패치 (EC2)
• C물리 시설 보안 — 데이터센터 출입 통제·전원·냉방 같은 물리 인프라는 AWS가 전담하는 대표적 AWS 책임 영역임
• DAZ 간 네트워크 암호화 — 리전 내 AZ를 잇는 백본 트래픽은 2018년 이후 Nitro 인스턴스 간 자동 암호화되어 AWS가 책임지며 고객 작업이 불필요함

문제 11

한 시스템이 트랜잭션당 1ms 미만 RPO를 요구하고 한 리전 안에서만 운영된다. RDS는?

• ASingle-AZ Standard — 단일 AZ에 인스턴스 하나뿐이라 복제 자체가 없어, AZ 장애 시 백업 복원 전까지 데이터 손실이 발생해 1ms RPO를 보장하지 못함
• BMulti-AZ Synchronous Replication
• CCross-Region Read Replica — 리전 간 비동기 복제라 복제 지연이 초 단위로 벌어져 RPO가 1ms를 한참 초과하고, 동일 리전 운영이라는 조건에도 과한 구성임
• DAurora Global Database — 리전 간 storage-level 비동기 복제(약 1초 RPO)라 보조 리전 손실 위험이 있고, 단일 리전만 요구하는 시나리오에는 과잉임

문제 12

한 회사가 Organizations 안에서 중앙 Networking 계정의 VPC 서브넷을 다른 30개 워크로드 계정에 공유하려 한다. 가장 적합한 솔루션은?

• AVPC Peering을 30번 — 중앙 VPC와 30개 계정을 각각 점대점으로 잇는 방식으로, 서브넷을 공유하는 게 아니라 별도 CIDR VPC를 연결하는 것이라 요구사항과 다르고 non-transitive 제약도 따름
• BAWS RAM으로 서브넷 공유
• CTransit Gateway만 사용 — VPC 간 라우팅 허브일 뿐 각 계정이 독립 VPC를 그대로 운영해야 해, "중앙 VPC의 서브넷을 직접 공유"하는 요구는 충족하지 못함
• DDirect Connect — 온프레미스와 AWS를 잇는 전용 회선 서비스라, 계정 간 VPC 서브넷 공유 시나리오와는 전혀 무관함