[network] NAT 게이트웨이
안에서 밖으로는 나가야 하지만, 밖에서 안으로는 막고 싶다. 프라이빗 서버의 이 딜레마를 NAT가 풀어줍니다.
One-Line Summary
NAT Gateway는 프라이빗 서브넷의 리소스가 인터넷(또는 외부)으로 나갈 수는 있지만, 인터넷에서 먼저 들어오는 접속은 막는 관리형 아웃바운드 관문이다. 프라이빗 서버가 OS 패치·외부 API 호출은 해야 하지만 외부에 노출되면 안 될 때 쓴다. public 서브넷에 놓고 Elastic IP를 붙이며, private 서브넷의 라우트 테이블이 이 NAT를 가리킨다.
Why It Exists
프라이빗 서브넷의 서버는 보안상 인터넷에서 직접 접근하지 못하게 막는다. 그런데 이 서버도 소프트웨어 업데이트를 받거나 외부 API를 호출하려면 인터넷으로 나가야 한다. "나가는 건 되고, 밖에서 먼저 들어오는 건 안 되는" 비대칭 통신이 필요하다.
NAT Gateway가 이 역할을 한다.
프라이빗 서버가 직접 인터넷에 나가려면
-> 공인 IP가 필요하고, 그 순간 외부에서 접근 가능해짐(위험)
NAT Gateway 경유
-> 프라이빗 서버는 사설 IP만 유지(외부에서 못 봄)
-> 아웃바운드는 NAT의 공인 IP로 대신 나감
-> 그 응답만 돌아오고, 외부가 먼저 시작하는 연결은 차단
시험 감각:
"프라이빗 인스턴스가 아웃바운드 인터넷만 필요, 인바운드는 막아라" = NAT Gateway.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
NAT | Network Address Translation | 사설 IP ↔ 공인 IP 주소 변환 |
NAT GW | NAT Gateway | AWS 관리형 NAT 서비스 |
EIP | Elastic IP | NAT Gateway에 붙이는 고정 공인 IPv4 |
IGW | Internet Gateway | VPC의 인터넷 관문(NAT도 최종적으로 이걸 통해 나감) |
AZ | Availability Zone | 가용 영역 (NAT Gateway는 AZ 단위 리소스) |
Egress-only IGW | Egress-only Internet Gateway | IPv6 아웃바운드 전용(NAT 대응) |
동작 원리
Internet
▲
┌───┴───┐
│ IGW │
└───▲───┘
│ (public 라우트: 0.0.0.0/0 ─► IGW)
┌─ VPC ───────┼───────────────┐
│ ┌───────────┴───────┐ │
│ │ public subnet │ │
│ │ NAT Gateway (EIP) │ │ ← 출발지를 NAT 공인 IP로 치환
│ └───────────────────┘ │
│ ▲ │
│ │ 0.0.0.0/0 ─► NAT GW │ (private 라우트)
│ ┌──────────────────────┐ │
│ │ private subnet │ │
│ │ App EC2 (private IP) │ │ ← 아웃바운드만, 외부 시작 연결은 차단
│ └──────────────────────┘ │
└─────────────────────────────┘
| 단계 | 내용 |
|---|---|
| 1 | 프라이빗 EC2가 외부로 요청 → 라우트 테이블이 NAT Gateway로 보냄 |
| 2 | NAT가 출발지 사설 IP를 자신의 공인 IP(EIP)로 치환해 IGW로 전달 |
| 3 | 인터넷에서 온 응답은 NAT가 다시 사설 IP로 되돌려 EC2에 전달 |
| 4 | 외부에서 먼저 시작하는(inbound-initiated) 연결은 NAT가 받지 않음 → 차단 |
배치·구성 요건 (빈출)
NAT Gateway가 동작하려면 아래가 모두 갖춰져야 한다.
| # | 요건 | 설명 |
|---|---|---|
| 1 | Public 서브넷에 배치 | NAT 자신이 인터넷으로 나가야 하므로 IGW 경로가 있는 서브넷에 둔다 |
| 2 | Elastic IP 연결 | NAT Gateway는 고정 공인 IP(EIP)를 가진다 |
| 3 | VPC에 IGW 부착 | NAT의 트래픽도 결국 IGW를 통해 인터넷으로 |
| 4 | Private 서브넷 라우트 | private RT에 0.0.0.0/0 → nat-xxxx 추가 |
흔한 실수: NAT Gateway를 private 서브넷에 놓는 것. NAT는 자기가 인터넷에 나가야 하므로 반드시 public 서브넷에 있어야 한다. private에 두면 NAT 자체가 인터넷에 못 나가 동작하지 않는다.
고가용성(HA) — AZ 단위 리소스라는 점이 핵심 (빈출)
NAT Gateway는 하나의 AZ 안에서만 이중화·고가용으로 동작한다. 즉 AZ 단위 리소스다. 그 AZ가 통째로 장애나면 그 NAT도 함께 죽는다.
[나쁜 구성 - 단일 NAT]
AZ-a private ─┐
AZ-c private ─┴─► NAT(AZ-a) ← AZ-a 장애 시 AZ-c도 인터넷 끊김 + 교차 AZ 요금
[권장 구성 - AZ별 NAT]
AZ-a private ─► NAT(AZ-a) ─► IGW
AZ-c private ─► NAT(AZ-c) ─► IGW ← 각 AZ가 자기 NAT 사용(장애 격리 + 요금 절감)
| 항목 | 내용 |
|---|---|
| 가용성 범위 | AZ 내부에서만 자동 이중화 (multi-AZ 아님) |
| HA 설계 | 각 AZ마다 NAT Gateway 1개 배치, 각 AZ의 private 서브넷은 자기 AZ의 NAT로 라우팅 |
| 교차 AZ 요금 | 다른 AZ의 NAT를 쓰면 cross-AZ 데이터 전송 요금 발생 → AZ별 배치가 비용에도 유리 |
| 성능 | 5 Gbps에서 시작해 자동으로 최대 100 Gbps까지 확장 |
시험 감각:
"NAT Gateway를 고가용성으로" = AZ마다 하나씩 두고 각 AZ가 자기 NAT를 쓰게 한다.
비용 감각 (빈출)
| 요금 요소 | 내용 |
|---|---|
| 시간당 요금 | NAT Gateway가 떠 있는 시간만큼 |
| 데이터 처리 요금 | NAT를 통과한 GB당 과금 |
| 절감 포인트 | S3·DynamoDB 트래픽은 Gateway VPC Endpoint로 빼면 NAT 데이터 요금 회피 |
"프라이빗 서브넷에서 S3로 대량 전송하는데 NAT 비용이 크다" = S3 Gateway Endpoint로 우회(인터넷·NAT 안 거침).
NAT Gateway vs NAT Instance (빈출 비교)
NAT는 원래 EC2로 직접 구성(NAT Instance)했지만, 지금은 관리형 NAT Gateway가 표준이다.
| 구분 | NAT Gateway | NAT Instance |
|---|---|---|
| 관리 | AWS 완전관리 | 사용자가 EC2로 직접 운영 |
| 가용성 | AZ 내 자동 이중화 | 직접 이중화 구성 필요(스크립트 등) |
| 대역폭 | 자동 확장(최대 100 Gbps) | 인스턴스 타입에 종속 |
| 보안 그룹 | 적용 불가(NACL로 제어) | 적용 가능 |
| Source/Dest Check | 해당 없음 | 비활성화 필수(안 하면 동작 안 함) |
| Bastion 겸용 | 불가 | 가능(포트 포워딩 등) |
| 유지보수/패치 | 불필요 | 사용자 책임 |
| 권장 | 기본 선택 | 특수 요구(포트포워딩·비용 극한 최적화)일 때만 |
시험 감각:
특별한 이유가 없으면 NAT Gateway. "관리 오버헤드 최소화" 키워드면 확정.
참고: NAT Gateway엔 Private NAT Gateway 변형도 있다 — 인터넷이 아니라 다른 VPC/온프레미스로 나갈 때(사설 대역 IP 중복 회피 등) 쓰는 특수 케이스다. 시험의 기본값은 인터넷 아웃바운드용 Public NAT Gateway.
IPv6는 NAT Gateway를 쓰지 않는다
IPv6에는 사설/공인 개념이 없어 NAT가 필요 없다. IPv6 리소스의 아웃바운드 전용은 Egress-only Internet Gateway로 처리한다. (NAT Gateway는 IPv4 전용)
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| NAT Gateway를 private 서브넷에 배치 | NAT는 인터넷에 나가야 하므로 public 서브넷에 둬야 함 |
| NAT로 인바운드(외부→내부) 접속 허용하려 함 | NAT는 아웃바운드 전용. 인바운드는 IGW+public 또는 ALB |
| NAT Gateway 하나로 모든 AZ 커버하며 HA라고 생각 | AZ 단위 리소스 → AZ마다 하나씩 배치해야 진짜 HA |
| 다른 AZ의 NAT를 공용으로 사용 | 교차 AZ 데이터 요금 + AZ 장애 시 동시 단절 |
| NAT Gateway에 보안 그룹 붙이려 함 | NAT GW는 SG 미지원(NAT Instance는 지원) |
| S3 대량 전송 비용을 NAT로 감내 | Gateway Endpoint로 NAT 데이터 요금 회피 |
| IPv6 아웃바운드에 NAT Gateway | IPv6는 Egress-only IGW |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "private instances need outbound internet, block inbound" | NAT Gateway |
| "download updates / call external API from private subnet" | NAT Gateway |
| "make NAT highly available across AZs" | AZ마다 NAT Gateway + AZ별 라우팅 |
| "reduce operational overhead of NAT" | NAT Gateway(관리형, NAT Instance 아님) |
| "reduce NAT data cost for S3/DynamoDB" | Gateway VPC Endpoint |
| "NAT with security group / act as bastion / port forwarding" | NAT Instance |
| "IPv6 outbound only" | Egress-only Internet Gateway |
| "outbound to on-prem/other VPC without internet" | Private NAT Gateway |
Memory Sentence
NAT Gateway는 프라이빗 서브넷의 아웃바운드 전용 관문(인바운드 차단). public 서브넷에 EIP 달아 놓고, private 라우트 테이블이
0.0.0.0/0 → nat을 가리킨다. AZ 단위 리소스라 HA는 AZ마다 하나씩. 관리형이라 NAT Instance보다 기본 선택이고, S3/DynamoDB 대량 트래픽은 Gateway Endpoint로 빼 비용을 아낀다. IPv6는 Egress-only IGW.
References
댓글
아직 댓글이 없습니다.