Datacenter & Cloud - 05. 클라우드 네트워크 서비스

VPC를 넘어서 — 클라우드 네트워크 서비스

이전 글에서 VPC의 기본 빌딩 블록(VPC·서브넷·보안 그룹·라우팅 테이블)을 다뤘다. 하지만 — 실제 클라우드 서비스는 그 기본 위에 더 많은 네트워크 서비스를 얹는다. Private 서브넷의 DB가 인터넷으로 나가려면? 두 개의 VPC를 연결하려면? 수십 개의 VPC를 하나로 묶으려면? S3에 인터넷을 거치지 않고 접근하려면? 이 질문들에 답하는 것이 이 글의 주제 — 클라우드 네트워크 서비스다. NAT 게이트웨이·VPC 피어링·Transit Gateway·PrivateLink·ELB가 어떻게 VPC의 한계를 넘어서는지를 본다.

NAT 게이트웨이 — private 서브넷이 인터넷으로 나가는 문

private 서브넷의 DB 서버는 — 인터넷에서 직접 접근을 받지 않는다(보안). 하지만 — OS 패키지 업데이트(apt update)·외부 API 호출·인증서 갱신을 위해 — 인터넷으로 나갈 수는 있어야 한다. 인터넷 게이트웨이(IGW)는 — 양방향(들어오는 것도 허용)이니 — private 서브넹에 직접 연결하면 보안이 무너진다.

NAT 게이트웨이(Network Address Translation Gateway) 는 — 나가는 방향만 허용하는 문이다. private 서브넷의 서버가 NAT를 통해 인터넷으로 나가면 — NAT가 사설 IP를 자기 공인 IP로 변환(SNAT)해서 보낸다. 응답은 NAT가 받아 — 원래 서버에게 전달한다. 하지만 — 외부에서 NAT의 공인 IP로 들어오는 연결은 — private 서브넷의 서버가 "요청을 먼저 보낸 적이 있는" 연결에만 응답이 전달된다. 즉 — 아웃바운드만 가능, 인바운드는 불가다.

특성	인터넷 게이트웨이 (IGW)	NAT 게이트웨이
방향	양방향 (inbound + outbound)	단방향 (outbound만)
적용 서브넷	Public	Private
IP 변환	1:1 (공인 IP가 인스턴스에 직접 할당)	N:1 (여러 인스턴스가 NAT의 공인 IP 공유)
비용	무료	사용량 기반 (GB당 요금 + 시간당 요금)
전형 사례	웹 서버, 로드 밸런서	DB 서버, 내부 앱 서버

NAT 게이트웨이는 — AZ 수만큼 두는 것이 권장된다. 한 AZ에만 NAT를 두면 — 그 AZ가 장애 나면 — 모든 private 서브넷이 인터넷에 못 나간다. foundations 04에서 본 fault domain이 여기서도 적용된다.

VPC 피어링 — 두 VPC를 직접 연결

VPC 피어링(VPC Peering) 은 — 두 개의 VPC를 인터넷을 거치지 않고 직접 연결하는 기술이다. 서로 다른 AWS 계정의 VPC도 연결할 수 있고, 다른 리전의 VPC도 연결할 수 있다(인터리전 피어링). 트래픽은 AWS 내부망을 통해 전달되니 — 빠르고 안전하다.

비유하자면 — 두 개의 아파트 단지(VPC) 사이에 — 전용 통로(피어링)를 놓는 것. 통로를 지나는 주민(패킷)은 — 밖(인터넷)으로 나가지 않고 — 바로 상대 단지로 간다.

VPC 피어링의 문제는 — VPC가 늘어나면 조합 폭발이 일어난다는 것이다. VPC 10개를 전부 서로 연결하려면 — 45개의 피어링 연결(10 * 9 / 2)이 필요하다. 100개면 4,950개. 각 피어링을 설정·관리하는 부담이 기하급수한다. 또한 — CIDR이 겹치면 피어링이 안 된다(라우팅 모호성). 이 문제를 해결하는 것이 Transit Gateway다.

Transit Gateway — 모든 VPC를 하나로 묶는 허브

Transit Gateway(TGW) 는 — 여러 VPC를 하나의 허브에 연결하는 클라우드 라우터다. hub-and-spoke 토폴로지. 각 VPC가 TGW에 하나씩 연결되니 — VPC N개를 연결하는 데 N개의 연결만 필요하다. 피어링의 N*(N-1)/2에서 N으로 줄어든다.

flowchart TD
    TGW["Transit Gateway<br/>(중앙 라우터)"]
    VPC_A["VPC A (운영)"] --> TGW
    VPC_B["VPC B (개발)"] --> TGW
    VPC_C["VPC C (보안)"] --> TGW
    ONPREM["온프레미스<br/>(VPN/Direct Connect)"] --> TGW
    TGW -->|"라우팅 규칙"| VPC_A
    TGW -->|"라우팅 규칙"| VPC_B
    TGW -->|"라우팅 규칙"| VPC_C

TGW의 장점:

• 중앙 라우팅 — 모든 VPC 간 트래픽이 TGW를 거치니 — 라우팅 규칙을 한 곳에서 관리
• 접근 제어 — "VPC B(개발)에서 VPC A(운영)로는 못 가게" 같은 정책을 TGW에서 설정
• 온프레미스 연결 — VPN이나 Direct Connect도 TGW에 연결 — 온프레미스와 모든 VPC를 한 곳에서 잇는다
• 확장성 — 새 VPC를 추가할 때 — TGW에 연결 하나만 추가하면 됨

특성	VPC 피어링	Transit Gateway
연결 수 (N개 VPC)	N*(N-1)/2	N
토폴로지	mesh (전부 연결)	hub-and-spoke (중앙 경유)
라우팅	분산 (각 VPC별)	중앙 (TGW)
전송 비용	무료	TGW 데이터 처리 요금
복잡도	VPC 증가 시 폭발	선형 증가
적합 규모	소수 VPC (~5개)	다수 VPC (10개+)

PrivateLink — AWS 서비스를 VPC 안으로

PrivateLink(AWS PrivateLink) 또는 VPC 엔드포인트(VPC Endpoint) 는 — AWS 서비스(S3·DynamoDB·SQS 등)를 인터넷을 거치지 않고 VPC 내부에서 직접 접근하게 해주는 기술이다.

원래 — private 서브넷의 서버가 S3에 접근하려면 — NAT 게이트웨이를 통해 인터넷으로 나가서 — S3의 공인 엔드포인트로 접속했다. 이건 — 같은 AWS 안에 있는데 인터넷을 거친다는 점에서 비효율적이고, 비용(NAT 데이터 처리 요금)도 들고, 보안상(인터넷 경유)으로도 이상하다.

PrivateLink는 — AWS 서비스의 프라이빗 엔드포인트를 VPC 안에 만든다. 서버가 이 엔드포인트로 접근하면 — 인터넷을 거치지 않고 AWS 내부망을 통해 서비스에 도달한다. 보안이 강화되고, 비용이 절감되며, 지연이 줄어든다.

PrivateLink의 다른 용도 — 자체 서비스를 다른 AWS 계정에 프라이빗하게 제공. "내 계정의 API를 — 인터넷에 노출하지 않고 — 파트너 계정에서만 접근하게" — PrivateLink로 가능하다. SaaS 서비스(B2B)에서 많이 쓰인다.

ELB — 클라우드 로드 밸런서

network fundamentals 영역의 마지막 글에서 로드 밸런싱을 다뤘다. AWS의 ELB(Elastic Load Balancing) 는 그 클라우드 버전이다. 세 가지 타입이 있다.

ELB 타입	계층	전형 사례	특징
ALB (Application LB)	L7	HTTP/HTTPS 트래픽	URL 경로별 라우팅, TLS 종단
NLB (Network LB)	L4	TCP/UDP 트래픽	초저지연, 고처리량
GWLB (Gateway LB)	L3/GW	보안 어플라이언스	트래픽 검사를 위한 삽입

ALB가 가장 많이 쓰인다 — HTTP 요청의 URL·헤더·쿠키를 검사해서 여러 타겟(서버 그룹)으로 분배. /api/*는 서버 그룹 A로, /static/*는 CDN으로. blue-green 배포·카나리 배포도 ALB의 가중치 기반 타겟 그룹으로 가능하다.

실습 — 클라우드 네트워크 서비스 확인

1. NAT 게이트웨이 확인

aws ec2 describe-nat-gateways --query 'NatGateways[*].[NatGatewayId,State,SubnetId]' --output table 2>/dev/null

확인할 것: NAT가 여러 AZ에 있는지. 하나뿐이면 — SPOF(단일 장애점).

2. VPC 피어링 확인

aws ec2 describe-vpc-peering-connections --query 'VpcPeeringConnections[*].[VpcPeeringConnectionId,Status.Code]' --output table 2>/dev/null

확인할 것: 피어링 상태가 active인지. deleted나 failed면 — 연결이 안 되고 있는 것.

3. Transit Gateway 확인

aws ec2 describe-transit-gateways --query 'TransitGateways[*].[TransitGatewayId,State]' --output table 2>/dev/null

확인할 것: TGW가 available 상태인지. 연결된 VPC 수가 expected와 맞는지.

4. VPC 엔드포인트 확인

aws ec2 describe-vpc-endpoints --query 'VpcEndpoints[*].[VpcEndpointId,ServiceName,VpcEndpointType]' --output table 2>/dev/null

확인할 것: com.amazonaws.<region>.s3 같은 서비스 엔드포인트가 있는지. Gateway 타입은 무료, Interface 타입은 비용 발생.

미검증: AWS CLI는 자격증명 설정된 환경에서만 동작. GCP는 gcloud compute routers list, Azure는 az network lb list로 동일 정보 확인.

클라우드 네트워크 서비스는 "연결성"의 층이다

VPC가 "격리"를 만든다면 — 이 글의 서비스들이 "연결"을 만든다. NAT로 인터넷에 연결하고, 피어링·TGW로 VPC 간 연결하고, PrivateLink로 AWS 서비스에 연결하고, ELB로 사용자와 서버를 연결한다. 이 모든 서비스가 — foundations 06의 IaC로 코드로 정의되고, foundations 03의 fault domain을 고려해 다중 AZ에 배치된다.

클라우드 네트워크 서비스의 설계는 — foundations 05의 "비용 vs 복잡도 vs 안정성 삼각형" 안에서 결정된다. NAT 게이트웨이를 다중 AZ에 두면 안정적이지만 비용이 든다. TGW로 중앙 라우팅하면 관리가 쉽지만 데이터 처리 요금이 발생한다. 각 선택이 — 비용·복잡도·가용성 사이의 트레이드오프를 갖는다. "정답"이 없고 — 서비스 요구사항(SLO·예산·팀 규모)에서 역산된다.

다음 글에서는 이 네트워크를 소프트웨어로 정의하는 기술을 다룬다 — SDN. 네트워크의 컨트롤 플레인과 데이터 플레인을 분리하고, OpenFlow·OVS·OVN이 어떻게 "소프트웨어 정의 네트워크"를 만드는지.

클라우드 네트워크 서비스를 이해하면 — "왜 VPC 간 통신이 느린가?"(TGW 데이터 처리 요금을 줄이려면 같은 VPC에 두기), "왜 S3 비용이 예상보다 큰가?"(NAT 경유 요금 — VPC 엔드포인트로 해결), "왜 한 AZ가 장애 나면 일부 서비스가 안 되나?"(NAT이나 ELB가 단일 AZ에만 있어서)에 답할 수 있다. 이 모든 것이 — "연결성"의 설계에서 비롯된다.

NAT 게이트웨이 비용 — 함정

NAT 게이트웨이는 비용 함정이 자주 발생하는 서비스다. 두 가지 요금이 있다 — 시간당 요금(인스턴스가 켜져 있는 동안) + 데이터 처리 요금(GB당). 특히 — S3에서 대용량 데이터를 다운로드할 때 NAT를 거치면 — 데이터 처리 요금이 폭발한다. 1TB 다운로드에 약 $45(2026년 기준). 이걸 피하려면 — S3 VPC 엔드포인트(Gateway 타입, 무료)를 쓴다.

또 다른 함정 — NAT 게이트웨이는 AZ별로 별도 요금이 부과된다. 3개 AZ에 NAT를 두면 — 시간당 요금이 3배. 하지만 — 단일 AZ NAT는 SPOF니 — 비용과 가용성의 트레이드오프다. 보통 — 운영 환경은 다중 AZ(비용 감수), 개발 환경은 단일 AZ(비용 절감)로 간다.

VPC 피어링 vs Transit Gateway — 언제 무엇을

두 서비스 모두 "VPC를 연결"하지만 — 적용 시점이 다르다.

VPC 피어링이 유리한 경우:

• VPC 수가 적다 (2 ~ 5개)
• VPC 간 트래픽이 많다 (피어링은 데이터 처리 요금이 무료)
• 영구적 연결 (한 번 설정하면 오래 씀)

Transit Gateway가 유리한 경우:

• VPC 수가 많다 (10개+)
• 자주 VPC가 추가/삭제된다
• 중앙 라우팅 정책이 필요하다
• 온프레미스 연결도 같이 관리해야 한다

현대 엔터프라이즈 클라우드는 — 대부분 Transit Gateway로 간다. 관리 편의성이 비용(TGW 데이터 처리 요금)보다 크기 때문이다. 작은 규모에서는 피어링으로 시작하고, VPC가 늘어나면 TGW로 마이그레이션한다.

ELB와 foundations의 연결

ELB의 헬스체크·세션 어피니티·TLS 종단은 — foundations 04(redundancy)와 network fundamentals 10(로드 밸런싱)에서 다룬 개념의 클라우드 실천이다. foundations 03에서 본 "장애 대응의 90%는 사전 설계에서 끝난다"는 원칙이 — ELB의 다중 AZ 배치와 헬스체크 설정에서 물리적으로 구현된다. ELB 없이 다중 AZ를 쓰면 — 어느 AZ로 트래픽을 보낼지 결정할 주체가 없다. ELB가 그 "트래픽 분배자" 역할을 한다.

실제 아키텍처에서의 서비스 조합

전형적인 3계층 클라우드 아키텍처에서 — 이 글의 서비스들이 어떻게 조합되는지 보자:

flowchart TD
    INTERNET["인터넷"] --> ALB["ALB (L7 로드 밸런서)<br/>public 서브넷, 다중 AZ"]
    ALB --> APP1["앱 서버<br/>private 서브넷 AZ-A"]
    ALB --> APP2["앱 서버<br/>private 서브넷 AZ-B"]
    APP1 --> S3_EP["S3 VPC 엔드포인트<br/>(PrivateLink, 무료)"]
    APP2 --> S3_EP
    APP1 --> NAT1["NAT GW AZ-A"]
    APP2 --> NAT2["NAT GW AZ-B"]
    NAT1 --> INTERNET
    NAT2 --> INTERNET
    APP1 --> DB["DB<br/>data 서브넷 AZ-A"]
    APP2 --> DB
    DB --> REPL["DB 복제본<br/>data 서브넷 AZ-B"]
    TGW["Transit Gateway"] --> APP1
    TGW --> ONPREM["온프레미스<br/>(Direct Connect)"]

이 다이어그램에서 — ALB(트래픽 분산)·NAT(인터넷 아웃바운드)·S3 엔드포인트(프라이빗 S3 접근)·TGW(온프레미스 연결)가 — 각자 다른 "연결성"을 담당한다. 모든 서비스가 foundations 03의 fault domain(다중 AZ)을 준수하고, foundations 06의 IaC(Terraform)로 정의된다.

클라우드 네트워크 서비스의 핵심 — "연결성"을 코드로 정의하는 것. NAT·피어링·TGW·PrivateLink·ELB가 — 각자 다른 연결 문제를 풀고, 이 조합이 클라우드 아키텍처를 만든다.

ELB 상세 — ALB vs NLB 선택 기준

ALB와 NLB의 선택은 — "어디까지 열어볼 것인가"에 달려 있다. network fundamentals 영역의 로드 밸런싱 글에서 본 L4 vs L7 차이가 그대로 적용된다.

ALB(Application Load Balancer) 를 쓰는 경우:

• HTTP/HTTPS 트래픽 (웹 서비스)
• URL 경로별 라우팅 (/api/* → 서버 그룹 A, /static/* → CDN)
• TLS 종단 (인증서를 ALB에 설치)
• WebSocket·HTTP/2 지원
• Blue-green 배포 (가중치 기반 타겟 그룹)

NLB(Network Load Balancer) 를 쓰는 경우:

• TCP/UDP 트래픽 (게임 서버, IoT, DNS)
• 초저지연 필요 (마이크로초 단위)
• 고정 IP 필요 (탄력적 IP 할당 가능)
• TLS 통과(passthrough) — 서버에서 직접 암호화

# ALB 생성 예시 (AWS CLI)
aws elbv2 create-load-balancer --name my-alb --subnets subnet-aaa subnet-bbb --scheme internet-facing --type application
# 타겟 그룹 생성
aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 --vpc-id vpc-xxx --health-check-path /health
# 리스너 규칙 (80 → 443 리다이렉트)
aws elbv2 create-listener --load-balancer-arn <alb-arn> --protocol HTTP --port 80 --default-actions Type=redirect,RedirectConfig='{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

클라우드 네트워크 서비스 설계 체크리스트

• NAT 게이트웨이가 다중 AZ에 있는가? (단일 AZ는 SPOF)
• S3 접근에 VPC 엔드포인트(Gateway 타입, 무료)를 쓰는가?
• VPC가 5개 이상이면 — 피어링 대신 Transit Gateway를 검토했는가?
• ELB 헬스체크 경로(/health)가 — 의존성(DB 등)까지 검사하는가?
• ALB에서 80 → 443 리다이렉트를 설정했는가? (HTTPS 강제)
• PrivateLink로 — 타사 SaaS를 프라이빗하게 연결하고 있는가?

VPC 간 통신의 보안 — 데이터 흐름 제어

VPC 피어링이나 Transit Gateway로 VPC를 연결하면 — 네트워크 연결은 되지만 — "어느 VPC에서 어느 VPC로 접근을 허용할 것인가?"를 별도로 제어해야 한다. 이걸 — 보안 그룹(인스턴스 수준)과 라우팅 테이블(서브넷 수준)과 Transit Gateway의 라우팅 정책(TGW 수준)으로 다층 방어한다.

예: "개발 VPC에서 운영 VPC의 DB로는 접근 금지, 운영 VPC의 모니터링 API로만 접근 허용" — TGW 라우팅 테이블에서 특정 CIDR만 허용 + 보안 그룹에서 특정 포트만 개방. foundations 03의 "defense in depth"가 — 클라우드 네트워크 서비스에서 다층으로 실천된다.

비용 최적화 — 네트워크 서비스의 숨은 비용

클라우드 네트워크 서비스는 — "보이지 않는 비용"이 자주 발생한다:

• NAT 게이트웨이 데이터 처리 요금 — private 서브넷의 모든 아웃바운드 트래픽이 NAT를 거치니 — GB당 요금이 쌓인다. S3 다운로드를 VPC 엔드포인트로 옮기면 — 이 비용이 사라진다.
• Transit Gateway 데이터 처리 요금 — TGW를 거치는 모든 트래픽에 GB당 요금. VPC 간 대용량 데이터 전송이 빈번하면 — 비용이 크다.
• 데이터 전송 요금(cross-AZ) — 같은 VPC 안에서도 — AZ 간 데이터 전송에 GB당 요금이 발생(AWS). 같은 AZ는 무료. DB 복제 같은 대용량 트래픽은 — 같은 AZ에 두면 비용이 절감되지만 HA가 희생된다. 트레이드오프다.
• 인터넷 송신(egress) 요금 — 클라우드에서 인터넷으로 나가는 트래픽은 — GB당 요금이 가장 비쌈. foundations 05에서 본 egress 비용이 여기서 발생한다.

클라우드 네트워크 서비스는 "연결성"의 층이다. NAT·피어링·TGW·PrivateLink·ELB가 — 각자 다른 연결 문제를 풀고, 이 조합이 클라우드 아키텍처를 만든다. 핵심은 — 비용·보안·가용성의 균형을 잡는 것. 모든 서비스를 쓰면 편하지만 비용이 폭발하고, 최소한만 쓰면 비용은 싸지만 관리가 복잡해진다.

클라우드 네트워크 서비스는 — VPC의 "격리" 위에 "연결"을 더하는 층이다.
NAT·피어링·TGW·PrivateLink·ELB가 각자 다른 연결 문제를 푼다.
설계는 비용·복잡도·가용성의 트레이드오프에서 결정된다.

---

참고

• AWS, "Amazon VPC User Guide — VPC Networking" — NAT·피어링·TGW·PrivateLink. 접근 2026-07-21
• AWS, "Transit Gateway Documentation" — TGW 설계·운용. 접근 2026-07-21
• AWS, "AWS PrivateLink Documentation" — PrivateLink 설정. 접근 2026-07-21
• AWS, "Elastic Load Balancing Documentation" — ALB/NLB/GWLB. 접근 2026-07-21
• GCP, "Cloud NAT, VPC Peering, Cloud Router" — GCP 동급 서비스. 접근 2026-07-21
• Azure, "Virtual Network Peering, Azure Load Balancer" — Azure 동급. 접근 2026-07-21
• AWS, "AWS Well-Architected Framework — Networking" — 네트워크 설계 원칙. 접근 2026-07-21
• Cloud Industry Forum, "Cloud Network Cost Optimization" — 비용 함정 가이드. 접근 2026-07-21
• AWS, "VPC Flow Logs" documentation — 트래픽 분석. 접근 2026-07-21
• FinOps Foundation, "Cloud Networking Cost Management" — 비용 최적화. 접근 2026-07-21
• HashiCorp, "Terraform AWS Provider — Networking Resources" — IaC로 네트워크 서비스 정의. 접근 2026-07-21
• Antoniou, I. "Enterprise Cloud Networking", O'Reilly, 2023 — 클라우드 네트워크 설계 실무. 접근 2026-07-21