LabHub

클라우드 네트워크 설계 · 밖으로 나가는 길 · 이론

NAT 게이트웨이가 요금 청구서 1위인 이유

LabHub 에서 이어서 보기

한 줄 요약

프라이빗 자원이 밖으로 나가는 길은 세 가지이고, **요금과 보안이 각각
다릅니다.** 아무 생각 없이 NAT 를 쓰면 청구서 상위권에 올라옵니다.

왜 이게 필요했나

프라이빗 서브넷을 만들면 그 안의 인스턴스는 밖으로 나갈 길이 없습니다. 그런데 패키지 업데이트도 받아야 하고, 로그도 올려야 하고, 컨테이너 이미지도 받아야 합니다.

가장 쉬운 답이 NAT 게이트웨이를 하나 놓는 것이라 대개 그렇게 하고, 그 뒤로 아무도 다시 보지 않습니다. 프라이빗 서브넷의 모든 아웃바운드가 그 한 곳으로 모이고, 요금은 지나간 데이터 양만큼 붙습니다.

몇 달 뒤 청구서를 항목별로 나눠 보면 NAT 가 1위에 올라와 있습니다. 그 트래픽이 불필요했던 것이 아니라 길을 잘못 골랐을 뿐인 경우가 대부분이라, 경로만 바꿔도 그 금액이 사라집니다. 그래서 나가는 길을 세 가지로 구분해 두고 무엇을 언제 쓰는지 정해 둡니다.

세 가지 길

| 방법 | 무엇 | 요금 | 보안 |
| --- | --- | --- | --- |
| 인터넷 게이트웨이(IGW) | 퍼블릭 서브넷의 양방향 통로 | 게이트웨이 자체는 무료 | 공인 IP 노출 |
| NAT 게이트웨이 | 프라이빗 → 인터넷 단방향 | 시간당 + 데이터 처리량 | 안전. 밖에서 못 들어옴 |
| VPC 엔드포인트 | 클라우드 서비스로 직행 | 게이트웨이형 무료 / 인터페이스형 유료 | 인터넷을 안 거침 |

NAT 요금이 커지는 구조

NAT 게이트웨이는 두 가지로 과금됩니다.

1. 시간당 요금        — 켜 두기만 해도 나간다2. 처리 데이터 요금   — GB 당. 나가는 것도 들어오는 것도

여기에 AZ 별로 하나씩 두면(가용성을 위해 그래야 합니다) 그 배수가 됩니다.
3개 AZ 면 NAT 3개입니다.

문제는 2번입니다. 프라이빗 서브넷의 인스턴스가 S3 에서 대용량을 읽으면
그 트래픽이 전부 NAT 를 지나갑니다. 같은 리전의 S3 인데도 말입니다.
로그 적재, 백업, 컨테이너 이미지 풀 — 전부 여기로 흐릅니다.

VPC 엔드포인트가 해결하는 것

엔드포인트는 클라우드 서비스로 가는 전용 통로를 VPC 안에 만듭니다.
트래픽이 인터넷을 거치지 않고, NAT 도 지나가지 않습니다.

S3 게이트웨이 엔드포인트를 만드는 것만으로 NAT 요금이 절반 이하로 떨어지는
경우가 흔합니다. 클라우드 비용 최적화에서 가장 먼저 확인하는 항목 중 하나입니다.

보안 이점도 큽니다 — 엔드포인트 정책으로 우리 계정의 버킷에만 접근하도록
제한할 수 있습니다. 데이터 반출 경로를 좁히는 수단이 됩니다.

배스천 대신 쓰는 것들

프라이빗 인스턴스에 접속하려고 배스천(점프 서버)을 두는 구성이 오래
쓰였는데, 요즘은 대안이 낫습니다.

배스천은 그 자체가 관리 대상이고(패치, 키 관리, 로그), 22번 포트가 열려
있어야 합니다. 없앨 수 있으면 없애는 편이 낫습니다.

온프레미스와 잇기

| 방법 | 특징 |
| --- | --- |
| 사이트 간 VPN | 인터넷 위 암호화 터널. 빠르게 구성. 대역·지연은 인터넷에 좌우 |
| 전용선 | 안정적인 대역·지연. 구축에 수 주~수 개월, 비쌈 |
| 전송 게이트웨이 | VPC 여러 개와 온프레미스를 별 모양으로 연결. 관리가 단순해짐 |

VPC 가 서너 개를 넘어가면 피어링을 그물처럼 잇는 것이 곧 한계에 부딪힙니다
(N개면 N(N-1)/2 개의 연결). 그때가 전송 게이트웨이를 도입할 시점입니다.

현장에서 만나는 모습

다음에 볼 것

이름 해석과 부하 분산 — 트래픽이 실제로 어디로 가는지 정하는 마지막 층.