기준: SAP-C02 시험 가이드오류 제보
Week 3는 AWS 고급 네트워킹의 전 스펙트럼을 다뤘다. VPC 간 연결(Peering, TGW, Cloud WAN), 온프레미스 연결(Direct Connect, Site-to-Site VPN, Client VPN), 서비스 단위 사설 접근(PrivateLink, Gateway Endpoint)이라는 세 축이 어떻게 서로 보완하고 대체하는지 이해하는 것이 이번 주의 핵심이었다. 개별 서비스를 다시 암기하는 것이 아니라, "이 시나리오에서 왜 이 서비스가 정답이고 다른 것들은 왜 안 되는가"를 즉각적으로 판단하는 능력을 다지는 것이 오늘의 목표다.
SAP-C02 시험에서 네트워킹 도메인 문제는 키워드 하나가 정답을 통째로 바꾼다. "CIDR 겹침"이 나오면 Peering과 TGW는 즉시 탈락이다. "단방향 서비스 노출"이 나오면 PrivateLink가 강력한 후보가 된다. "1초 이내 페일오버"가 나오면 BFD(Bidirectional Forwarding Detection)를 떠올려야 한다. "회선 자체 암호화"가 나오면 MACsec이 답이다. 오늘은 이 키워드-정답 매핑을 씹어 삼키는 날이다.
다음 의사결정 트리를 손에 익혀두면 시험장에서 네트워킹 문제는 첫 15초에 방향이 잡힌다.
VPC 간 연결이 필요한가?
├── 2개 VPC, CIDR 겹침 없음, 단순 연결 → VPC Peering
├── 3개 이상 VPC, 허브-스포크, 온프레미스 연결 포함 → Transit Gateway
└── 글로벌 멀티 리전, 단일 정책 관리 → AWS Cloud WAN
온프레미스 연결이 필요한가?
├── 빠른 구축(수 분), 임시, 백업 → Site-to-Site VPN
│ └── 처리량 확장 필요 → TGW + ECMP (최대 50Gbps 이론상)
├── 대용량, 일관 지연, 규제, 장기 운영 → Direct Connect
│ ├── 단일 VPC → Private VIF + VGW
│ ├── 다중 VPC/리전 → Transit VIF + DX Gateway + TGW
│ ├── AWS 공개 서비스(S3 공인 IP) → Public VIF
│ ├── 99.99% SLA → Maximum Resiliency (2 Location × 2회선)
│ ├── L2 암호화 규제 → MACsec (10G/100G Dedicated)
│ └── 1초 이내 페일오버 → BFD 활성화
└── 개별 직원 단말 → Client VPN (OpenVPN, SAML/mTLS/AD 인증)
서드파티/내부 서비스를 사설로 접근?
├── CIDR 겹침 or 단방향 서비스 노출 → PrivateLink (Interface Endpoint)
├── S3, DynamoDB만 접근 (비용 최소) → Gateway Endpoint (무료)
└── 보안 어플라이언스 트래픽 체인 → Gateway Load Balancer Endpoint
네트워크 토폴로지 이론에서 이 서비스들은 각자 다른 추상화 레벨을 다룬다. VPC Peering과 TGW는 L3 네트워크 레벨 연결(IP 라우팅). PrivateLink는 서비스 레벨 연결(DNS + ENI, L4-L7). DX는 L1/L2 물리-데이터링크 레벨 위에 L3 BGP를 올린 구조. MACsec은 L2(이더넷 프레임) 암호화. 이 추상화 레벨의 차이가 각 서비스의 특성(CIDR 요구사항, 방향성, 확장성)을 결정한다. 예를 들어 PrivateLink가 CIDR 겹침을 허용하는 이유는 IP 라우팅이 아닌 서비스 단위(ENI)로 연결되기 때문이다. L3를 우회하는 L4 연결이므로 CIDR 충돌이 라우팅 문제를 일으키지 않는다.
| 서비스 | 방향 | CIDR 겹침 | 전이적 라우팅 | 멀티 리전 | 비용 특성 |
|---|---|---|---|---|---|
| VPC Peering | 양방향 | 불가 | 불가 | 가능(별도 Peering) | 무료(동일 AZ) / $0.01/GB(AZ 간) |
| TGW | 양방향 | 불가 | 가능(TGW 내) | TGW Inter-Region Peering | Attachment $0.05/hr + $0.02/GB |
| Cloud WAN | 양방향 | 불가 | 가능(정책) | 네이티브 글로벌 | Core Network Edge 시간당 |
| DX | 양방향 | 불가 | DXGW+TGW | DXGW 경유 | 포트+시간+GB |
| Site-to-Site VPN | 양방향 | 불가 | TGW 경유 가능 | 리전별 별도 | $0.05/hr + $0.09/GB |
| PrivateLink | 단방향 | 허용 | N/A | Cross-Region 지원(2024) | ENI $0.01/hr + $0.01/GB |
| Gateway Endpoint | 단방향(VPC→서비스) | N/A | 불가(VPC 내부만) | 불가 | 무료 |
VPC Peering이 "무료"라는 표현은 Peering 연결 자체에 요금이 없다는 의미다. 실제로는 AZ 간 데이터 전송 요금($0.01/GB)이 발생한다. 같은 AZ 내 Peering 통신은 무료지만 AZ를 넘으면 요금이 붙는다. TGW는 처리 비용($0.02/GB) 외에 Attachment 시간당 요금($0.05/시간)도 붙는다. 10개 VPC를 Full Mesh Peering으로 연결하면 45개 Peering이 필요하지만 연결 자체 비용은 없다. TGW로 전환하면 Attachment 10개($0.50/hr)와 처리량 요금이 추가된다. 대신 운영 부담이 45개→1개로 줄어든다. SAP-C02에서 "비용 최소화 + VPC 소수 + 단순 연결"이면 Peering, "운영 부담 최소 + VPC 다수"이면 TGW가 정답 방향이다.
| 이중화 모드 | 구성 | SLA | 사용 시나리오 |
|---|---|---|---|
| Maximum Resiliency | 2 Location × 2회선 = 4회선 | 99.99% | 미션 크리티컬, 금융, 공장 자동화 |
| High Resiliency | 2 Location × 1회선 = 2회선 | 99.9% | 일반 엔터프라이즈 |
| Development | 1 Location × 1회선 + VPN 백업 | 99% | 비프로덕션, POC |
AWS DX SLA에서 "99.99%"는 연간 약 52.6분의 다운타임을 허용한다. "99.9%"는 연간 8.76시간이다. "99%"는 연간 87.6시간이다. Maximum Resiliency에서 두 DX Location이 동시에 장애 날 확률은 각 Location의 장애 확률의 곱이다. 단일 Location SLA가 99.9%라면 장애 확률이 0.1% = 0.001이고, 두 Location이 동시에 장애일 확률은 0.001 × 0.001 = 0.000001 = 99.9999% 가용성이라는 계산이 성립한다. 이것이 AWS가 Maximum Resiliency를 "2 Location × 2 회선"으로 정의한 수학적 근거다. LAG(Link Aggregation Group)는 같은 Location 내 포트를 묶는 것이므로 Location 전체 장애에는 무력하다. 4회선이어도 같은 Location에 있으면 99.99% 달성 불가다.
| 시나리오 | 정답 VIF | 이유 |
|---|---|---|
| 단일 VPC, 작은 규모 | Private VIF + VGW | 단순하고 비용 낮음 |
| 멀티 VPC, 멀티 리전 | Transit VIF + DXGW + TGW | 확장성 |
| 온프레미스 간 DX 백본 연결 | SiteLink | AWS 리전 미통과 |
| 공개 AWS 서비스(S3 공인 IP) | Public VIF | 공인 IP 범위 BGP 광고 |
| L2 암호화 규제 | MACsec (10G/100G Dedicated) | 이더넷 프레임 암호화 |
| Hosted Connection | Private VIF 또는 Public VIF | Transit VIF 미지원 |
⚠️ Hosted Connection 함정: Hosted Connection(파트너 제공)은 Transit VIF를 지원하지 않는다. Dedicated Connection(AWS 직접 제공)만 Transit VIF 생성이 가능하다. 따라서 파트너 통해 DX를 연결하고 멀티 VPC에 접근해야 한다면 각 VPC마다 Private VIF를 만드는 방법(복잡) 또는 파트너에게 Dedicated Connection을 요청해야 한다. 시험에서 "파트너 DX + 다수 VPC"가 나오면 이 제약을 기억해야 한다. 또한 Hosted Connection의 대역폭은 50Mbps~10Gbps로 Dedicated Connection(1G/10G/100G)과 다른 선택지가 있다.
MACsec(IEEE 802.1AE)은 이더넷 프레임 단위로 암호화한다. DX는 L1 광섬유 위에 L2 이더넷을 올리는데 MACsec은 이 L2 프레임 전체를 AES-256으로 암호화한다. AWS에서 MACsec이 지원되는 것은 Dedicated Connection 10Gbps와 100Gbps뿐이다. 1Gbps Dedicated Connection과 모든 Hosted Connection은 MACsec 미지원이다. 규제 환경에서 "회선 자체 암호화"가 요구될 때 IPsec(L3)이나 TLS(L7)와 구분하는 것이 핵심이다. MACsec은 AWS와 DX Location 사이의 링크를 암호화하며 DX Location과 온프레미스 사이는 추가로 별도 MACsec 장비가 필요하다.
온프레미스 → AWS 방향 (아웃바운드 from 온프레미스):
온프레미스 BGP에서 DX neighbor에 Local Preference ↑ 설정
→ 온프레미스 BGP가 DX 경로를 선호해 DX로 나감
AWS → 온프레미스 방향 (인바운드 to 온프레미스):
온프레미스 BGP에서 VPN neighbor로 AS Path Prepending 적용
→ AWS BGP는 AS Path가 짧은 DX 경로를 선호
→ DX 다운 시 AWS는 유일한 VPN 경로 선택
BGP 속성의 전파 범위를 이해하면 혼동이 줄어든다. Local Preference는 iBGP(같은 AS 내부)에서만 교환되고 eBGP 피어에게는 전달되지 않는다. 따라서 온프레미스 라우터가 설정한 Local Preference는 AWS 측에 전달되지 않고 온프레미스 내부의 경로 선택에만 영향을 준다. 반면 AS Path와 MED(Multi-Exit Discriminator)는 eBGP를 통해 피어에게 전달되므로 AWS 라우터가 이 값을 받아 경로 선택에 활용한다. 이 전파 범위 차이가 방향별 BGP 조작 방법이 달라지는 이유다. RFC 4271(BGP-4)에서 Local Preference는 OPTIONAL NON-TRANSITIVE, AS Path는 WELL-KNOWN MANDATORY로 정의되어 있어 AS Path는 항상 eBGP 경계를 넘어 전파된다.
⚠️ 시험 함정: "AWS → 온프레미스 방향 우선순위 제어"가 나오면 반드시 AS Path Prepending을 떠올린다. "온프레미스 → AWS 방향 우선순위 제어"가 나오면 Local Preference를 떠올린다. 방향을 헷갈리면 반드시 틀린다. 또 하나의 함정: "BFD로 DX 페일오버를 빠르게"는 맞지만, BFD 자체가 경로 선택을 하는 것이 아니라 장애를 감지해 BGP에 통보하는 역할이다. BFD로 감지하고 BGP가 경로를 재계산하는 것이다.
DX에서 BGP Community를 활용한 정밀 라우팅 제어도 시험에 등장한다.
AWS가 광고하는 BGP Community (온프레미스로):
7224:7100 - 리전 내 로컬 라우트
7224:7200 - 리전 내 글로벌 라우트
7224:8100 - 동일 대륙
7224:9100 - 글로벌
온프레미스가 AWS에 광고할 때 MED 사용:
MED 낮은 값 → AWS가 더 선호
MED는 동일 AS에서 들어오는 복수 경로 중 선택할 때 사용
[Dev VPC] ─Association→ RT-Workload
[Prod VPC] ─Association→ RT-Workload
[Stage VPC] ─Association→ RT-Workload
[Shared VPC] ─Association→ RT-Shared
Propagation 설정:
Dev VPC → RT-Shared에 Propagation (Shared VPC가 Dev CIDR 알게 됨)
Prod VPC → RT-Shared에 Propagation (Shared VPC가 Prod CIDR 알게 됨)
Shared VPC → RT-Workload에 Propagation (Dev/Prod가 Shared CIDR 알게 됨)
결과:
Dev→Prod: RT-Workload에 Prod CIDR 없음 → 차단
Prod→Dev: RT-Workload에 Dev CIDR 없음 → 차단
Dev→Shared: RT-Workload에 Shared CIDR 있음 → 허용
Shared→Dev: RT-Shared에 Dev CIDR 있음 → 허용
Association = "나는 이 RT의 결정을 따른다(Follow)". Propagation = "나의 CIDR을 이 RT에 알린다(Advertise)". Dev가 RT-Workload에 Association되어 있고 RT-Workload에 Prod CIDR이 Propagate되지 않으면, Dev→Prod 패킷은 Blackhole이다. TGW의 Blackhole 라우트는 명시적으로 트래픽을 버리는 정적 라우트로 추가할 수도 있는데, 이는 "특정 CIDR이 실수로 Propagate되더라도 강제 차단"하는 방어 목적으로 사용된다.
🎯 5-환경 격리 시나리오: 대형 금융 그룹이 TGW로 개발(Dev), 스테이징(Stage), 프로덕션(Prod), 공유(Shared), 보안(Security) 5개 환경을 운영한다. Dev↔Prod 격리, Stage↔Prod 격리, Dev↔Stage 격리가 필요하지만 모든 환경이 Shared와 Security에 접근해야 한다. 설계: RT-Workload(Dev/Stage/Prod Association, Shared CIDR + Security CIDR만 Propagation), RT-Shared(Shared Association, 모든 CIDR Propagation), RT-Security(Security Association, 모든 CIDR Propagation). Security VPC의 IDS/IPS는 모든 트래픽을 볼 수 있고, 워크로드 환경 간 통신은 라우팅 자체가 없어 차단된다. 이 설계에서 Security VPC는 "Read-Only" 관찰자가 아니라 RT-Security를 통해 모든 CIDR을 알고 있어 필요시 개입(트래픽 인젝션)도 가능하다.
| Endpoint 유형 | 지원 서비스 | CIDR 영향 | 비용 | DNS |
|---|---|---|---|---|
| Interface Endpoint | 대부분 AWS 서비스, PrivateLink 커스텀 | VPC에 ENI 생성 | $0.01/hr + GB | Private DNS 이름 |
| Gateway Endpoint | S3, DynamoDB 만 | 라우팅 테이블 변경 | 무료 | 변경 없음 |
| GWLB Endpoint | 보안 어플라이언스 | GENEVE 터널 | GB당 요금 | 없음 |
2023년 한 국내 핀테크가 해외 결제 처리 SaaS와 연동할 때 금융 규제기관이 "데이터가 공개 인터넷을 통과하지 않아야 한다"는 요건을 제시했다. SaaS 벤더가 AWS PrivateLink Endpoint Service를 제공했고, 핀테크의 VPC에 Interface Endpoint를 생성해 두 회사의 CIDR(10.0.0.0/8이 겹침)에도 불구하고 사설 연결을 완성했다. 구현 시간이 VPN 터널 설계보다 4배 빠르고 운영 인력도 절감됐다는 후기가 있다. 2024년에는 Cross-Region PrivateLink가 GA되어 다른 리전의 Endpoint Service에 Interface Endpoint를 만들 수 있게 됐는데, 이것도 시험 출제 범위에 들어간다.
Gateway Endpoint는 온프레미스(DX/VPN)에서 사용할 수 없다. Gateway Endpoint는 VPC 라우팅 테이블에 prefix list 형태의 라우트를 추가하는 방식이다. 이 라우트는 VPC 내부 트래픽에만 적용되므로 DX나 VPN을 통해 온프레미스에서 들어오는 트래픽은 이 라우트를 타지 않는다. 온프레미스에서 S3에 인터넷 없이 접근하려면 S3 Interface Endpoint 또는 Public VIF를 사용해야 한다. 시험에서 "온프레미스 + S3 + 인터넷 없이"가 나오면 Gateway Endpoint가 아닌 Interface Endpoint나 Public VIF를 선택한다.
5단계 분석으로 네트워킹 문제를 빠르게 해독한다.
1. WHO: 누가 접근하나? (직원 노트북 → Client VPN, 온프레미스 서버 → DX/VPN, VPC→VPC → Peering/TGW)
2. WHAT: 무엇에 접근하나? (S3 → Gateway Endpoint, AWS 서비스 → Interface Endpoint, 커스텀 서비스 → PrivateLink)
3. WHY: 왜 사설 접근이 필요한가? (규제, 보안, 지연, 비용)
4. CONSTRAINTS: 제약이 무엇인가? (CIDR 겹침, SLA, 암호화, 대역폭, 시간)
5. KEYWORD: 결정적 키워드가 무엇인가?
- "CIDR 겹침" → PrivateLink
- "전이적 라우팅" → TGW (Peering 아님)
- "회선 암호화" → MACsec
- "1초 페일오버" → BFD
- "99.99% SLA" → Maximum Resiliency
- "온프레미스 간 AWS 경유 없이" → SiteLink
- "단방향" → PrivateLink
- "운영 최소화 + 글로벌" → Cloud WAN
🎯 시험 전략: SAP-C02 네트워킹 문제는 보통 2-3가지 정답 후보가 있고 제약 조건 1-2개가 정답을 하나로 좁힌다. "DX + VPN 동시 운영 + AWS→온프레미스 DX 우선"이 나오면 AS Path Prepending이 키워드다. "DX + 1초 이내 페일오버"가 나오면 BFD가 키워드다. "50개 VPC + 중앙 API 접근 + CIDR 겹침 가능성"이 나오면 PrivateLink Endpoint Service가 키워드다. 이 패턴 매핑을 반복 연습하면 시험장에서 읽는 시간이 줄고 판단이 빨라진다.
| 키워드 | 즉각 연상 서비스 |
|---|---|
| CIDR 겹침 | PrivateLink (Interface Endpoint) |
| 전이적 라우팅 필요 | TGW (Peering 제외) |
| 글로벌 단일 정책 | Cloud WAN |
| 회선 L2 암호화 | MACsec |
| DX 1초 페일오버 | BFD |
| DX 99.99% SLA | Maximum Resiliency (2 Location × 2회선) |
| 온프레미스→AWS 우선순위 | Local Preference |
| AWS→온프레미스 우선순위 | AS Path Prepending |
| S3/DynamoDB 무료 접근 | Gateway Endpoint |
| 온프레미스에서 S3 사설 접근 | Interface Endpoint 또는 Public VIF |
| 단방향 서비스 노출 | PrivateLink Endpoint Service + NLB |
| 상태저장 어플라이언스 체인 | GWLB + GWLB Endpoint |
| 개별 직원 VPC 접근 | Client VPN (SAML/mTLS/AD) |
| 멀티 VPC 온프레미스 DX | Transit VIF + DXGW + TGW |
| 온프레미스 간 AWS 경유 없이 | DX SiteLink |
| Hosted DX + 멀티 VPC | Transit VIF 불가 → Dedicated 필요 |
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
글로벌 물류 기업이 AWS Organizations로 3개 리전(us-east-1, eu-west-1, ap-northeast-1)에 걸쳐 60개 VPC를 운영한다. 본사 데이터센터(서울)에서 모든 리전의 VPC에 사설로 접근해야 하고, VPC 간에는 개발·스테이징·프로덕션 환경이 서로 격리되어야 한다. 공유 서비스 VPC(DNS, LDAP)에는 모든 환경이 접근 가능해야 한다. 운영 부담을 최소화하는 최적 아키텍처는?
문제 2
금융 회사가 서울 데이터센터와 us-east-1 AWS를 DX로 연결한다. 규제 심사에서 "DX 회선 자체에도 암호화가 필요하다"는 지적을 받았다. 또한 DX 포트 장애 시 자동 페일오버를 1초 이내로 달성해야 한다. 현재 10Gbps Dedicated Connection이 있다. 적합한 기술 조합은?
문제 3
헬스케어 회사가 멀티 계정 환경(HIPAA 규정)을 운영한다. 각 병원 VPC(50개)가 중앙 의료 데이터 분석 VPC의 API에만 접근해야 하고, 병원 VPC 간 통신은 절대 불가능해야 한다. 의료 데이터 분석 VPC의 내부 IP 구조가 병원 VPC에 노출되면 안 된다. CIDR이 중복될 가능성이 있다. 가장 적합한 구성은?
문제 4
e-commerce 기업이 블랙프라이데이를 앞두고 온프레미스 재고 시스템과 AWS Lambda 기반 주문 처리 시스템 간의 연결 대역폭이 부족하다. 현재 VGW에 연결된 Site-to-Site VPN 1개를 운영 중이다. DX 설치는 6개월이 걸린다. 다음 주까지 처리량을 즉시 확장하는 방법은?
문제 5
보안팀이 모든 VPC의 인터넷 아웃바운드 트래픽을 중앙 Palo Alto Networks 방화벽으로 검사하고 싶다. 방화벽 어플라이언스가 상태 저장 검사를 하고 원본 소스 IP를 보존해야 한다. 방화벽은 별도 Security 계정에서 운영되고 워크로드 VPC는 수십 개다. 가장 적합한 아키텍처는?
문제 6
Fintech 스타트업이 온프레미스 뱅킹 코어 시스템과 AWS를 DX와 VPN으로 이중 연결했다. AWS에서 온프레미스로 향하는 트래픽(인바운드)을 DX가 우선되도록 BGP를 설정해야 한다. 올바른 방법은?
문제 7
글로벌 미디어 회사가 us-east-1에서 S3 버킷(비디오 렌더링 결과물), Secrets Manager(API 키), ECR(컨테이너 이미지)에 접근하는 배치 처리 EC2 플릿을 운영한다. 모든 접근이 인터넷을 경유하지 않아야 하고 비용을 최적화해야 한다. 최적 구성은?
문제 8
보험사가 온프레미스 데이터센터 2곳(서울 강남, 서울 가산)에서 AWS DX를 운영한다. 현재 구성: 강남 DC → DX Location A(1G 회선 1개), 가산 DC → DX Location B(1G 회선 1개). 한 DX Location 전체 장애 시 서비스가 중단되는 문제가 발생했다. 99.99% SLA를 달성하려면?
문제 9
회사가 자체 개발한 결제 처리 마이크로서비스를 20개 고객사 VPC에 제공해야 한다. 고객사 VPC의 CIDR이 알 수 없고 겹칠 수 있다. 고객사는 결제 API만 호출할 수 있어야 하고 회사 내부 VPC의 다른 리소스에는 접근 불가능해야 한다. 새 고객사 온보딩 시 운영 부담이 최소화되어야 한다.
문제 10
다국적 제약회사가 임상 데이터를 AWS에서 분석한다. 연구팀 직원 200명이 각자의 노트북에서 AWS 분석 환경(VPC 내 JupyterHub, RStudio)에 접근한다. 회사가 이미 Azure AD를 IdP로 사용하며 SAML 2.0을 지원한다. 직원의 네트워크 위치(사무실, 재택, 출장)와 무관하게 동작해야 한다. 데이터는 VPC 내부에 있어야 하고 인터넷에 노출되면 안 된다. 최적 구성은?
문제 11
다음 중 AWS TGW의 ECMP(Equal-Cost Multi-Path) 동작에 대한 설명으로 옳은 것은?
문제 12
회사가 온프레미스 데이터센터 A(뉴욕)와 데이터센터 B(런던)를 각각 AWS DX로 연결했다. 두 데이터센터 간에 직접 통신이 필요한데 현재는 온프레미스 라우터를 통해 인터넷으로 연결한다. AWS 네트워크를 백본으로 사용해 두 데이터센터 간 안정적인 저지연 통신을 설정하되 AWS 리전 리소스를 경유하지 않으려 한다. 가장 적합한 구성은?
Week 4는 AWS의 경계를 확장하는 서비스들을 다룬다. Outposts(AWS 인프라를 고객 데이터센터에), Local Zones(도시 수준 지연 최소화), Wavelength(통신사 5G 엣지), Storage Gateway(온프레미스 스토리지 통합), Snow Family(대규모 데이터 물리 이동), EKS/ECS Anywhere(컨테이너 on-prem 확장)가 주제다. 공통 키워드는 두 가지다: "온프레미스에서 AWS API를 쓰고 싶다"와 "데이터가 AWS까지 이동하는 대역폭/시간이 문제다". 이 두 축으로 Week 4 서비스를 분류하면 절반은 해결된다.