Why the NAT Gateway Tops the Bill

한국어 원문으로 표시합니다.

한 줄 요약

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

Concept map: 길을 잘못 골랐을 뿐 · 시간당 + 데이터 처리량 · 인터넷을 안 거침 · S3 에서 대용량을 읽으면

왜 이게 필요했나

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

가장 쉬운 답이 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, DynamoDB) — 라우팅 테이블에 경로가 추가됩니다. 요금이 없습니다. 안 쓸 이유가 없습니다.
인터페이스형 (그 외 대부분) — 서브넷에 ENI 가 생깁니다. 시간당 + 데이터 요금이 있지만 대개 NAT 보다 쌉니다.

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

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

배스천 대신 쓰는 것들

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

세션 관리자 계열 — 에이전트가 밖으로 연결을 맺는 방식이라 인바운드 포트를 하나도 안 열어도 됩니다. 접속 기록도 남습니다.
VPN / 제로트러스트 접근 제어 — 사용자 단위 인증과 감사.

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

온프레미스와 잇기

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

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

나가는 길을 통제하면 무엇이 달라지나

들어오는 길은 대부분 잘 막는다. 나가는 길을 열어 두는 이유는 "안에서 밖으로 나가는 건 안전하니까" 인데, 침해 이후의 모든 단계가 밖으로 나가는 통신이다. 도구를 내려받고, 명령을 받고, 데이터를 보낸다.

기본을 막고 필요한 것만 여는 순서로 간다. 다만 한 번에 막으면 서비스가 멈추므로, 실제로 어디로 나가는지 먼저 센다. 흐름 로그의 거부 기록이 아니라 허용 기록을 세는 것이 시작이다.

허용 목록은 IP 가 아니라 이름으로 관리해야 오래 간다. 외부 API 의 주소는 수시로 바뀐다. IP 로 적으면 어느 날 조용히 끊기고, 그때 임시로 넓게 열어 둔 규칙이 영구히 남는다. 이름 기반 정책이나 프록시를 두고 그 목록을 관리한다.

프록시를 거치게 하면 두 가지가 함께 온다. 어디로 나가는지 기록이 남고, 목록에 없는 곳을 막을 수 있다. 대신 프록시가 단일 장애점이 되고 TLS 를 어떻게 다룰지 정해야 한다. 내용을 보려면 중간에서 인증서를 갈아 끼워야 하는데, 그러면 그 프록시가 모든 통신을 평문으로 보는 자리가 된다. 대부분의 조직은 목적지 이름(SNI)만 보고 내용은 안 보는 선에서 멈춘다.

메타데이터 서비스로 나가는 길이 가장 특별하다. 클라우드에서 169.254.169.254 는 인스턴스의 자격 증명을 준다. 애플리케이션에 SSRF 취약점이 있으면 공격자는 이 주소를 부르게 해서 권한을 통째로 가져간다. 이 경로는 방화벽이 아니라 메타데이터 서비스 자체의 설정(IMDSv2 강제, 홉 수 제한)으로 막는 것이 확실하다.

DNS 도 나가는 길이다. 모든 포트를 막아도 DNS 질의가 나간다면 그것으로 데이터를 조금씩 내보낼 수 있다. 내부 리졸버만 쓰게 하고, 그 리졸버의 질의 로그를 남기고, 평소와 다른 질의 양을 보는 것이 실무적인 대응이다.

현장에서 만나는 모습

청구서 1위가 NAT → S3 엔드포인트가 없었다.
컨테이너 이미지 풀 트래픽이 NAT 로 → 레지스트리 엔드포인트나 캐시 필요.
VPC 6개를 피어링으로 다 이음 → 15개 연결. 전송 게이트웨이로 정리.

다음에 볼 것

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