SAP-C02에서 네트워크 연결 전략은 단일 태그 기준으로 가장 많은 문제가 출제되는 영역입니다. 실무에서도 멀티 VPC, 하이브리드 환경, 서비스 간 프라이빗 연결은 아키텍처 설계의 출발점이 됩니다.
핵심은 "어떤 연결 방식이 이 시나리오에 가장 적합한가?"를 판단하는 능력입니다. VPC Peering, Transit Gateway, Direct Connect, VPN, PrivateLink는 각각 쓰임새가 다르고, 시험에서는 이들을 혼동하게 만드는 시나리오가 자주 출제됩니다.
VPC 간 연결 — Peering vs Transit Gateway
두 VPC를 연결하는 가장 기본적인 방법은 VPC Peering입니다. 두 VPC 사이에 직접 1:1 연결을 만들어 프라이빗 IP로 통신합니다. 설정이 간단하고 추가 비용이 거의 없지만, 전이적 라우팅(Transitive Routing)이 불가능합니다. VPC A-B, B-C를 피어링해도 A에서 C로 직접 통신할 수 없습니다.
VPC가 3개 이상이면 Transit Gateway가 훨씬 효율적입니다. Transit Gateway는 허브-스포크 모델의 중앙 라우터 역할을 합니다. 모든 VPC를 Transit Gateway에 연결하면 어떤 VPC에서든 다른 VPC로 통신할 수 있고, 라우트 테이블로 세밀하게 제어할 수 있습니다.
| 기준 | VPC Peering | Transit Gateway | |------|-------------|-----------------| | 연결 모델 | 1:1 직접 연결 | 허브-스포크 (중앙 라우터) | | 전이적 라우팅 | 불가 | 가능 | | VPC 수 증가 시 | 연결 수 폭증 (N*(N-1)/2) | 허브에 추가만 하면 됨 | | 비용 | 데이터 전송 비용만 | 시간당 연결 비용 + 데이터 전송 | | 적합한 경우 | 2~3개 VPC 연결 | 10개 이상 VPC, 온프레미스 통합 |
Transit Gateway는 AWS RAM(Resource Access Manager)으로 다른 계정과 공유할 수 있어 멀티 계정 환경에서 특히 유용합니다.
!VPC Peering vs Transit Gateway
Direct Connect — 전용선 연결
Direct Connect는 온프레미스 데이터센터와 AWS를 전용 물리 회선으로 연결합니다. 인터넷을 거치지 않으므로 대역폭이 안정적이고 지연 시간이 일정합니다.
Direct Connect Gateway를 사용하면 하나의 Direct Connect 연결로 여러 리전의 VPC에 동시에 접근할 수 있습니다. 글로벌 기업이 단일 물리 회선으로 전 세계 리전에 연결하는 시나리오에서 출제됩니다.
이중화가 핵심 주제입니다. 단일 Direct Connect는 단일 장애 지점이 됩니다. 시험에서는 두 번째 DX 연결을 다른 위치에 설치하는 Active-Active 또는 Active-Passive 구성을 자주 묻습니다. VPN을 백업으로 사용하는 하이브리드 구성도 출제됩니다.
| 구성 | 특징 | |------|------| | 단일 DX | 비용 절감, 단일 장애 지점 | | 이중 DX (같은 위치) | 회선 이중화, 위치 장애에 취약 | | 이중 DX (다른 위치) | 최고 복원력, 비용 높음 | | DX + VPN 백업 | 비용 효율적 이중화, VPN 대역폭 제한 |
VPN — Site-to-Site vs Client VPN
Site-to-Site VPN은 온프레미스 네트워크 전체를 AWS VPC에 연결합니다. 인터넷 위에 암호화 터널을 만들어 통신하며, Direct Connect보다 설정이 빠르고 비용이 낮지만 대역폭과 지연이 인터넷 품질에 의존합니다.
Client VPN은 개인 기기(노트북, 모바일)에서 VPC에 접속하는 원격 접근 솔루션입니다. OpenVPN 호환 클라이언트를 사용하며, IAM 또는 Active Directory로 인증합니다. 재택근무 시나리오에서 온프레미스 VPN 장비 없이 AWS 리소스에 접근할 때 사용합니다.
PrivateLink — 서비스 단위 프라이빗 연결
PrivateLink는 VPC 간 또는 VPC-서비스 간에 프라이빗 연결을 제공합니다. 전체 네트워크를 연결하는 것이 아니라 특정 서비스(NLB 뒤의 애플리케이션)에만 접근을 허용합니다.
SaaS 제공 업체가 자사 서비스를 고객 VPC에 노출할 때, 고객의 VPC와 전체 피어링을 할 필요 없이 PrivateLink로 해당 서비스만 노출할 수 있습니다. 보안과 네트워크 격리를 동시에 달성하는 패턴입니다.
Interface VPC Endpoint는 PrivateLink 기술을 사용하여 AWS 서비스(S3, DynamoDB 제외)에 프라이빗으로 접근합니다. Gateway VPC Endpoint는 S3와 DynamoDB 전용이며, 라우트 테이블에 추가하는 방식으로 동작합니다. Gateway Endpoint는 추가 비용이 없습니다.
하이브리드 DNS — Route 53 Resolver
온프레미스와 AWS를 함께 운영하면 DNS 해석이 복잡해집니다. 온프레미스의 내부 도메인을 AWS에서 해석하거나, AWS의 프라이빗 호스티드 존을 온프레미스에서 해석해야 합니다.
Route 53 Resolver의 Inbound Endpoint는 온프레미스에서 AWS 프라이빗 DNS로 쿼리를 보낼 수 있게 합니다. Outbound Endpoint는 AWS에서 온프레미스 DNS로 쿼리를 전달합니다. Resolver Rule을 만들어 특정 도메인의 쿼리를 지정 IP로 포워딩하고, AWS RAM으로 여러 계정에 공유할 수 있습니다.
멀티 계정 환경에서는 Resolver Rule을 OU 단위로 공유하면 신규 계정이 추가될 때 자동으로 DNS 설정이 적용됩니다. 호스티드 존을 계정마다 수정할 필요가 없어 운영 오버헤드가 크게 줄어듭니다.
실무에서 자주 만나는 시나리오
시나리오 1: 50개 VPC를 가진 기업이 온프레미스와 연결해야 합니다. VPC Peering으로는 연결 수가 1,225개 필요하지만, Transit Gateway를 사용하면 각 VPC를 허브에 연결하고 온프레미스도 VPN 또는 Direct Connect로 허브에 연결하면 됩니다.
시나리오 2: SaaS 서비스를 고객에게 제공하는데, 고객 VPC의 IP 대역과 충돌하지 않아야 합니다. PrivateLink를 사용하면 IP 대역 충돌 걱정 없이 NLB 뒤의 서비스만 노출할 수 있습니다.
시나리오 3: 온프레미스 Active Directory 도메인을 AWS EC2에서 해석해야 합니다. Route 53 Resolver Outbound Endpoint를 생성하고, Resolver Rule에 온프레미스 DNS IP를 지정하면 됩니다.
시험 핵심 정리
"VPC 간 전이적 라우팅이 필요" -- Transit Gateway
"2개 VPC만 간단히 연결" -- VPC Peering
"온프레미스-AWS 전용선 연결" -- Direct Connect
"단일 DX로 여러 리전 접근" -- Direct Connect Gateway
"특정 서비스만 프라이빗으로 노출" -- PrivateLink
"S3/DynamoDB 프라이빗 접근, 추가 비용 없음" -- Gateway VPC Endpoint
"온프레미스에서 AWS 프라이빗 DNS 해석" -- Route 53 Resolver Inbound Endpoint
"AWS에서 온프레미스 DNS로 쿼리 전달" -- Route 53 Resolver Outbound Endpoint
"멀티 계정 DNS 규칙 공유" -- Resolver Rule + AWS RAM
"DX 이중화 + 비용 효율" -- DX + Site-to-Site VPN 백업
"개인 기기에서 VPC 원격 접근" -- Client VPN