Day 4 - VPC Peering, Transit Gateway, VPC Endpoint: VPC 너머의 연결

VPC 하나로 시작했다가 곧 다음 질문이 떠오른다. "다른 VPC와 통신해야 한다", "온프레미스 DC와 연결해야 한다", "S3에 비공개로 접근하고 싶다." 각각 다른 답이 있고, 그 답을 고르는 기준이 SAA 시험 시나리오의 핵심이다. 이 네 가지 연결 방식 — Peering, Transit Gateway, VPC Endpoint, VPN/Direct Connect — 의 trade-off를 명확히 매핑할 수 있으면 네트워크 영역 시험의 절반은 풀린다.

이 글에서는 각 연결 방식의 언제, 왜, 어떤 trade-off를 같이 본다. 단순히 키워드 매핑이 아니라 "왜 이 시나리오에 이게 답인가"를 한 번 더 짚는다.

VPC Peering: 1:1 직접 연결

Peering은 두 VPC를 1:1 사설 라우팅으로 연결한다. 같은 리전·계정·다른 리전·다른 계정 모두 가능.

[ VPC A: 10.0.0.0/16 ] ──── pcx-xxx ──── [ VPC B: 10.1.0.0/16 ]
       │                                          │
   라우팅 추가:                              라우팅 추가:
   10.1.0.0/16 → pcx-xxx                     10.0.0.0/16 → pcx-xxx

특성:

• non-transitive: A↔B, B↔C가 있어도 A↔C는 불가. 모든 쌍을 개별 peering 해야 함.
• CIDR overlap 금지: 겹치면 라우팅 불가.
• DNS 해석 옵션: 활성화하면 상대 VPC의 사설 호스트네임이 해석됨.
• 비용: peering 자체는 무료. cross-AZ/region 데이터 전송만 과금.

⚠️ 함정: Peering의 non-transitive 특성은 N개 VPC를 모두 연결하려면 N(N-1)/2 개의 peering이 필요하게 만든다. 10개 VPC면 45개 peering. 운영 불가능한 수준. 이게 Transit Gateway가 필요한 이유. 또 Peering은 MTU 9001(jumbo frame)을 지원하지만 인터넷 경유로 가는 트래픽은 1500으로 fragment되므로, 큰 데이터 전송에서는 MTU 차이가 throughput에 영향을 준다.

Peering은 내부적으로 static 라우팅 테이블 entry로 구현된다. 두 VPC가 peering되면 AWS Mapping Service가 두 VPC의 ENI 매핑 테이블을 서로 참조 가능하게 만든다. 그러나 peering 자체에 transitive route가 없는 건 security boundary 때문이다 — VPC A가 VPC B와 peering 했다고 해서 VPC B의 다른 peer를 자동으로 신뢰하면 transitive trust 취약점이 생긴다. AWS는 이를 명시적으로 차단해서 보안을 강제한다. 같은 원칙이 IAM의 cross-account role assumption에도 적용된다 — A가 B의 role을 빌릴 수 있어도 B가 C의 role을 빌릴 수 있는 게 자동으로 A에게 위임되지 않는다.

Peering의 non-transitive 특성은 그래프 이론의 complete graph K_n과 직결된다. n개 노드를 모두 연결하면 n(n-1)/2 개의 edge가 필요한데, 이게 scale-free network가 아니라 fully-connected mesh가 되는 한계다. Hub-and-spoke 토폴로지(TGW)는 star graph로 n-1 edge만 필요해서 O(n²) → O(n) 으로 복잡도가 떨어진다.

Transit Gateway: 라우팅 허브

TGW는 여러 VPC와 온프레미스를 hub-and-spoke로 연결한다. 2018년 출시. AWS Hyperplane 위에서 동작해 60+ Tbps의 집계 throughput.

        [ VPC A ]
            ↑
[ VPC B ] ─┼─ TGW ─┬─ [ VPC C ]
            ↓       └─ [ On-Prem (VPN/DX) ]
        [ VPC D ]

• Transitive routing: A→TGW→B 자동 가능.
• 5000개까지 attachment: VPC, VPN, DX, Peering, Connect 등.
• Route Tables: TGW 자체에 여러 라우팅 도메인 분리 가능(prod/dev 분리 등).
• Multi-region peering: TGW 간 peering으로 글로벌 backbone 구성.

사례: AWS 자체 사례 — 2018년 re:Invent 발표에서 TGW 출시 이전 한 고객사가 100+ VPC를 운영했고, 풀 메시 peering이 약 4,950개에 달해 누구도 라우팅 토폴로지를 이해할 수 없었다. TGW로 전환 후 attachment 100개 + 라우팅 테이블 5개로 단순화.

TGW의 hub-and-spoke는 네트워크 토폴로지 디자인의 고전. 풀 메시는 redundancy가 최고지만 cost가 N²로 증가, 트리는 cost는 낮지만 SPOF, hub-and-spoke는 hub만 잘 만들면 둘의 균형. AWS Hyperplane이 그 hub의 SPOF 위험을 SDN 분산으로 해결한다. 통신 사업자의 Multiprotocol Label Switching(MPLS, RFC 3031)도 같은 hub-and-spoke 모델을 IP 라우팅 위에 구현한 것이고, TGW는 MPLS의 클라우드 버전이라고 볼 수 있다.

TGW의 라우팅 테이블은 한 TGW 안에 여러 개 둘 수 있고, 각 attachment를 다른 라우팅 테이블에 연결할 수 있다. 이게 route domain 분리 기능이다. 예: prod attachment는 prod 라우팅 테이블에, dev는 dev 라우팅 테이블에 연결하면 prod ↔ dev 간 라우팅이 자동 차단된다. 같은 패턴으로 shared service VPC는 양쪽 모두에 라우팅이 가능하게 두면 공통 도구(Active Directory, 로그 수집)는 공유하되 워크로드는 격리할 수 있다. 이 segmented hub-and-spoke 패턴이 SRA가 권장하는 표준이다.

⚠️ 함정: TGW는 attachment마다 appliance mode를 켜면 flow stickiness가 유지된다(같은 흐름이 같은 ENI/AZ로 라우팅). 이걸 안 켜면 ECMP(Equal-Cost Multi-Path)로 트래픽이 분산되는데, stateful inspection appliance(예: 가상 방화벽)를 거치면 응답이 다른 경로로 가서 conntrack이 깨질 수 있다. 시험에는 자주 안 나오지만 실무 디테일.

VPC Endpoint: 인터넷 안 거치고 AWS 서비스 접근

프라이빗 서브넷의 인스턴스가 S3에 접근하려면 NAT GW를 거쳐 인터넷으로 나갔다 돌아와야 한다 — 비싸고 우회. 대안이 VPC Endpoint. AWS 서비스에 VPC 내부에서 직접 비공개 접근.

두 종류가 있고 시험에서 헷갈리기 쉬운 부분이다.

Gateway Endpoint: S3와 DynamoDB만

• 라우팅 테이블에 prefix list로 경로 추가.
• 무료.
• S3와 DynamoDB 두 서비스만 지원.
• 같은 리전만.

Route Table에 자동 추가:
  pl-XXXX (S3 prefix list) → vpce-xxxx (Gateway Endpoint)

Interface Endpoint (PrivateLink): 나머지 모두

• ENI를 VPC에 생성, AWS 서비스에 DNS 매핑.
• 시간당 + GB당 과금.
• 거의 모든 AWS 서비스 지원 + ISV SaaS 지원.
• 같은 리전 + Cross-region (2023년 GA).

Interface Endpoint는 사실상 AWS PrivateLink의 한 종류다. PrivateLink는 ENI를 통한 비공개 L4 노출 메커니즘이고, AWS 서비스든 ISV 서비스든 같은 모델을 쓴다. Datadog, Snowflake, MongoDB Atlas 등 다수 SaaS가 PrivateLink endpoint를 제공한다. 이게 "AWS 안에서 인터넷 안 거치고 SaaS와 통신"하는 표준 패턴. PrivateLink는 내부적으로 NLB를 endpoint service에 노출시키는 모델이고, 양쪽이 같은 PrivateLink endpoint로 연결되면 트래픽이 NLB → ENI 흐름으로 전달된다.

PrivateLink는 service mesh의 east-west traffic과 비슷한 개념이지만 layer가 다르다. Service mesh(Istio, Linkerd)는 L7 proxy(Envoy)로 mTLS와 retry/timeout을 처리하는 반면, PrivateLink는 L4 TCP 터널이다. 둘은 같이 쓸 수 있다 — PrivateLink로 VPC 간 보안 터널을 만들고, 그 위에 service mesh가 L7 보안과 관찰성을 얹는 패턴. 이게 zero-trust 마이크로서비스의 표준 아키텍처다.

사례: 2019년 Capital One 사건(Day 1 참조) 이후 많은 회사가 IMDSv2 + Egress 차단으로 SSRF·exfiltration 대비를 강화했다. 이때 S3 Gateway Endpoint + 강력한 endpoint policy + VPC 안의 모든 outbound NAT 차단 조합이 "데이터를 VPC 밖으로 못 보내는" 패턴의 표준이 됐다. 2023년 한 정부 기관은 모든 AWS 서비스를 Interface Endpoint로만 접근하게 강제하고 NAT GW를 아예 제거했다 — 이 fully private VPC 패턴이 정부·금융권의 새 표준이 되는 중이다.

Endpoint Policy: 엔드포인트별 권한 제한

Endpoint에 IAM-스타일 정책을 붙일 수 있다. 예: "이 VPC Endpoint를 통해서는 우리 회사 S3 버킷만 접근 가능".

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

이 정책이 없으면 endpoint를 통해 임의의 S3 버킷(타사 포함)에 접근 가능. data exfiltration 방어의 핵심 도구.

Endpoint Policy + IAM Identity Policy + S3 Bucket Policy + (Org SCP) 네 정책이 모두 교차 평가된다. 한 곳에서 명시 Deny가 있으면 거부. 모든 곳에서 Allow가 필요. 이 layered policy 덕분에 다른 계정의 다른 IAM identity가 우리 endpoint를 통해 우리 의도하지 않은 S3 버킷에 접근하는 우회 경로를 차단할 수 있다. 2020년 출시된 VPC Endpoint Policy with aws:PrincipalOrgID는 "내 Org에 속한 identity만"이라는 가장 강력한 차단 조건을 가능하게 만들었다.

함정: Endpoint Policy를 적용하지 않으면 모든 S3 버킷에 접근 가능이 기본이다. 즉 endpoint를 만든 것만으로는 데이터 유출이 막히지 않는다 — 항상 명시적 endpoint policy로 내 버킷만 또는 내 Org의 버킷만 으로 좁혀야 한다.

AWS Site-to-Site VPN

온프레미스 ↔ AWS를 IPsec VPN으로 연결. 두 IPsec 터널이 자동 HA로 구성된다.

• CGW (Customer Gateway): 온프레미스 측 VPN 장비 표현.
• VGW (Virtual Private Gateway) 또는 TGW: AWS 측 종점.
• BGP 또는 정적 라우팅.
• 처리량: 터널당 ~1.25 Gbps.

빠른 구성·저비용이 장점. 단점은 공용 인터넷 경유라 latency 변동·throughput 제한.

AWS VPN은 IPsec/IKEv2를 사용하고 NIST SP 800-77이 권장하는 암호 스위트(AES-256-GCM, SHA-2, DH Group 14+)를 지원한다. Accelerated Site-to-Site VPN(2020 출시)은 VPN 트래픽을 가장 가까운 Global Accelerator 엣지로 보낸 후 AWS 백본망으로 전달해 throughput과 jitter를 개선한다. 대규모 throughput이 필요한 경우 ECMP로 여러 터널을 묶어 사용 가능(TGW + multiple tunnels 패턴).

IPsec(RFC 4301, 2005)은 transport mode(host-to-host)와 tunnel mode(gateway-to-gateway)가 있고, AWS VPN은 tunnel mode를 쓴다. IKEv2(RFC 7296)는 IKEv1 대비 빠른 rekey, NAT-T(NAT traversal), MOBIKE(mobile/multihoming) 같은 현대 기능을 제공한다. 같은 표준이 Cisco ASA, Palo Alto, FortiGate, OPNsense 등 거의 모든 방화벽 벤더에서 호환된다.

Direct Connect: 전용선

물리 전용선(1/10/100 Gbps)으로 AWS와 직결. AWS Direct Connect Location에 양측 라우터를 두고 cross-connect.

• Latency 안정성: 인터넷 경유 대비 변동 1/10 이하.
• Bandwidth: 1/10/100 Gbps dedicated 또는 partner의 50/100/200/300/400/500 Mbps sub-rate.
• Hybrid 표준: 대용량·저지연·일관성 요구 시.
• 단점: 설치에 weeks ~ months, 비용.

하이브리드 클라우드의 두 모델 — VPN(논리적 터널)과 Direct Connect(물리적 회선)는 trade-off가 명확하다. NIST SP 800-77(IPsec VPN)과 ITU-T G.694.1(WDM)이 각 기술의 표준. 큰 금융·통신 회사는 DX 1Gbps × 2(HA) + VPN backup의 3중 패턴을 표준으로 쓴다. MACsec(IEEE 802.1AE)은 L2 암호화로 DX의 물리 회선을 보호하는데, 2022년부터 AWS DX에서도 옵션으로 제공한다.

DX는 Public VIF와 Private VIF로 나뉜다. Private VIF는 VPC와 직접 연결, Public VIF는 AWS Public Service(S3, DynamoDB Public Endpoint)에 직접 연결. Transit VIF(2019 출시)는 TGW와 연결되어 한 DX 회선이 수십 VPC에 동시 접근 가능. Direct Connect Gateway는 한 DX 회선을 여러 리전의 VPC에 연결할 수 있게 해주는 글로벌 라우팅 엔티티다.

사례(가상): 2019년 한 한국 금융 그룹이 본사 ↔ AWS 서울 리전 사이 10Gbps DX 회선 2개를 다른 통신사로 이중화하고 그 위에 VPN backup까지 3중으로 구성한 사례를 공개했다. 비용은 월 수억 원이었지만, 단 한 번의 장애도 사업에 영향을 주지 않아야 한다는 금융 규제 요구를 충족시켰다. 일반 SaaS는 이렇게까지 안 가도 되고, DX 1개 + VPN backup 정도가 표준이다.

ClientVPN: 사용자별 원격 접속

위 VPN이 site-to-site였다면 ClientVPN은 사용자 단말 ↔ AWS VPC. TLS 기반 OpenVPN 프로토콜. SAML/AD 인증 통합.

코로나19 시기 원격 근무 폭증으로 사용량 폭발했고, 사내 인프라 접근의 표준 도구가 됐다.

ClientVPN은 OpenVPN 프로토콜이라 일반 OpenVPN 클라이언트(macOS Tunnelblick, Windows OpenVPN GUI, iOS/Android 앱)에서 모두 호환된다. SAML 통합으로 Okta, Azure AD, Google Workspace에서 SSO 가능하고, MFA가 IdP 측에서 강제된다. split-tunnel 옵션을 켜면 VPC 트래픽만 터널을 타고 일반 인터넷 트래픽은 직접 나가서 throughput과 사용자 경험이 좋아진다. 다만 full-tunnel이 보안상 더 안전(모든 트래픽이 회사 통제 하).

ClientVPN은 VPN-based remote access의 클라우드 버전이지만, Zero Trust 시대에는 이마저도 legacy로 분류된다. Cloudflare Access, Tailscale, Twingate 같은 ZTNA 솔루션이 VPN-less로 같은 기능을 제공하면서 device posture check과 continuous authentication을 추가한다. AWS 자체는 Verified Access(2023 출시)로 이 영역에 진출했다.

정리

이 표를 머리에 박아두면 시나리오 첫 줄만 봐도 후보가 2개로 좁혀진다. 그 다음은 비용·복잡도·HA 요구치를 비교해 최종 답을 정한다. 마지막으로 한 가지 — 2021년 출시된 AWS Cloud WAN은 TGW의 글로벌 backbone 확장이고, 다중 리전 멀티 계정 네트워크를 policy as code로 관리하게 해준다. 수십 리전·수백 계정 규모에서는 Cloud WAN이 TGW + TGW Peering 조합보다 운영이 훨씬 단순하다.