AWS NAT 게이트웨이 비용 줄이기, AZ별 배치·엔드포인트 판단표

프라이빗 서브넷을 만들고 NAT 게이트웨이를 붙이는 것까지는 콘솔 마법사가 알아서 해 줘요. 운영에서 고민이 시작되는 건 그다음이에요. NAT 를 AZ마다 둘지, 청구서에 찍힌 'NatGateway-Bytes' 를 어떻게 줄일지, 가끔 외부 API 호출이 멈추는 이유가 뭔지 같은 질문이요. 결론부터 말하면 운영 환경은 AZ마다 NAT 를 두고(또는 리전 NAT), S3·DynamoDB 는 무료 게이트웨이 엔드포인트로 빼고, 나머지 AWS 서비스는 서비스당 월 수백 GB 를 넘을 때만 인터페이스 엔드포인트를 붙이는 것이 기본값이에요.

이 글은 패킷이 어떻게 변환되는지보다 어떤 값을 언제 고르나에 집중해요. 단가는 AWS 공식 가격 파일(Price List, 서울 리전 ap-northeast-2, 2026-11-01 적용분)에서 직접 뽑았고, 한도와 장애 증상은 AWS VPC 사용 설명서의 NAT 게이트웨이 기본 사항과 NAT 게이트웨이 문제 해결 문서로 확인했어요. 계산은 한 달을 730시간으로 잡았어요.

NAT 게이트웨이 요금 구조 — 무엇에 돈이 나가나

NAT 게이트웨이 청구서는 네 줄로 나뉘어요. 서울 리전 값이에요.

두 가지를 자주 놓쳐요. 첫째, Amazon VPC 요금 페이지는 데이터 처리 요금이 트래픽의 출발지·목적지와 관계없이 GB마다 붙는다고 적어요. 패키지를 내려받는 것처럼 "들어오는" 트래픽도 NAT 를 지나면 처리 요금이 나가요. 둘째, NAT 를 지난 뒤 인터넷으로 나가는 데이터에는 일반 데이터 전송 요금이 따로 붙어요. NAT 처리 요금은 그 위에 얹히는 몫이에요.

AZ 간 전송은 Amazon EC2 온디맨드 요금 페이지의 데이터 전송 항목대로 "각 방향 0.01달러"라, 다른 AZ 의 NAT 로 보낸 1GB 는 보내는 쪽과 받는 쪽에서 합쳐 0.02달러가 돼요. 리전 NAT 게이트웨이는 활성화된 AZ 마다 시간 요금이 붙어서, AZ 3개에 걸쳐 있으면 영역 NAT 3대와 시간 요금이 같아요.

NAT 하나 공유 vs AZ마다 — 월 7TB 손익분기

가장 흔한 질문이에요. AZ 3개에 워크로드가 고르게 퍼져 있고, 한 달에 NAT 를 지나는 트래픽이 T GB 라고 해 볼게요.

• NAT 1대 공유: 고정비 46.72달러 + 처리 0.059T + 다른 두 AZ 에서 넘어오는 3분의 2 트래픽의 AZ 간 요금 0.02×(2/3)T
• AZ마다 1대: 고정비 46.72×3 = 140.16달러 + 처리 0.059T, AZ 간 요금 없음

두 식이 같아지는 지점은 93.44 = 0.0133T, 즉 T ≈ 7,008GB 예요. 월 7TB 아래면 1대 공유가 싸고, 위면 AZ마다 두는 쪽이 싸요.

돈만 보면 작은 서비스는 1대가 맞아 보여요. 하지만 NAT 게이트웨이 문서는 NAT 가 자기 AZ 안에서만 이중화된다고 적어요. NAT 가 있는 AZ 가 멈추면 다른 두 AZ 의 서버도 외부 결제 API, 푸시 알림, 패키지 저장소에 닿지 못해요. 멀티 AZ 로 배포한 의미가 외부 통신에서 사라지는 거예요. 그래서 판단은 이렇게 해요.

리전 NAT 게이트웨이 문서에 적힌 제약도 같이 봐요. 새 AZ 에 리소스가 생기면 그 AZ 로 확장하는 데 최대 60분이 걸리고, 그동안 트래픽은 다른 AZ 의 NAT 를 거쳐요. 이 시간에는 AZ 간 요금이 붙고, 그 AZ 의 장애 격리도 아직 안 된 상태예요. 대신 AZ 하나에 IP 를 32개까지 붙일 수 있어서 연결 수가 많은 서비스에 여유가 커요.

S3·DynamoDB 는 게이트웨이 엔드포인트로 — 처리 요금 0

비용을 가장 쉽게 줄이는 곳이에요. 게이트웨이 엔드포인트 문서는 사용에 추가 요금이 없다고 적어요. 프라이빗 서브넷에서 S3 로 월 5TB(5,000GB)를 올리고 내리는 배치가 있다면, NAT 를 지날 때 처리 요금만 5,000×0.059 = 295달러예요. 엔드포인트 하나로 이 줄이 0이 돼요.

만들 때 확인할 것은 세 가지예요.

1. 라우팅 테이블 선택: 엔드포인트를 만들 때 고른 라우팅 테이블에만 프리픽스 목록(pl-…) 경로가 들어가요. AZ마다 프라이빗 라우팅 테이블을 나눴다면 전부 골라야 해요. 하나만 고르면 그 서브넷만 엔드포인트를 타고 나머지는 계속 NAT 요금을 내요.
2. 같은 리전만: 프리픽스 목록은 리전마다 달라서, 다른 리전 버킷으로 가는 트래픽은 그대로 NAT 를 지나요. 리전 간 복제나 다른 리전 로그 버킷이 있으면 따로 계산해요.
3. 버킷 정책: 엔드포인트를 붙인 뒤 버킷 정책에 aws:sourceVpce 조건을 걸면, 엔드포인트 밖(로컬 PC, 다른 VPC)에서의 접근이 막혀요. 정책은 엔드포인트가 모든 라우팅 테이블에 붙은 것을 확인한 다음에 바꿔요.

컨테이너 이미지를 ECR 에서 받는 경우도 S3 와 엮여 있어요. Amazon ECR VPC 엔드포인트 문서는 프라이빗 서브넷에서 이미지를 받으려면 ecr.api·ecr.dkr 인터페이스 엔드포인트와 S3 게이트웨이 엔드포인트가 함께 필요하다고 적어요. 배포 때마다 수 GB 이미지를 노드 수십 대가 받는 클러스터라면 S3 게이트웨이 엔드포인트만으로도 NAT 처리량이 눈에 띄게 줄어요. 월 몇 TB 인지 감이 안 오면 이미지 크기와 노드 수, 배포 횟수를 곱해 데이터 용량 변환기로 GB 단위를 맞춰 보면 돼요.

인터페이스 엔드포인트 손익분기 — 서비스당 월 581GB

S3·DynamoDB 말고 다른 AWS 서비스(ECR, CloudWatch Logs, STS, Secrets Manager 등)는 인터페이스 엔드포인트(PrivateLink)를 써요. 이건 공짜가 아니에요. 서울 리전에서 엔드포인트 하나가 AZ 하나에 시간당 0.013달러, 처리 GB당 0.01달러(월 1PB 까지)예요. AZ 3개에 걸면 고정비가 0.013×730×3 = 28.47달러예요.

NAT 를 지나면 GB당 0.059달러, 엔드포인트를 지나면 0.01달러라 GB당 0.049달러를 아껴요. 고정비를 메우는 지점은 28.47 ÷ 0.049 ≈ 581GB/월(AZ 2개면 387GB)이에요.

여기서 함정은 "엔드포인트를 서비스마다 다 만들자"예요. CloudWatch Logs 로 월 50GB 를 보내는 서비스에 3 AZ 엔드포인트를 걸면 NAT 로 보낼 때(2.95달러)보다 월 26달러 가까이 더 내요. 엔드포인트는 트래픽이 큰 서비스부터 하나씩, 아니면 보안 요구(인터넷 경로 금지) 때문에 비용과 상관없이 필요할 때 붙여요. 반대로 모든 AWS 호출을 엔드포인트로 뺄 수 있고 외부 인터넷 호출이 없다면, NAT 자체를 없애 대당 월 47달러의 고정비를 지울 수 있어요.

연결 한도와 350초 끊김 — 숫자로 미리 계산하기

같은 목적지 55,000 연결

NAT 게이트웨이 기본 사항의 한도는 "IP 주소 하나가 고유 목적지 하나에 동시 연결 55,000개"예요. 고유 목적지는 목적지 IP·포트·프로토콜의 조합이에요. 전체 연결 수가 아니라 한 곳에 몰리는 연결 수가 문제라는 뜻이에요.

계산 예를 들어 볼게요. 파드 200개가 각각 외부 결제 API 하나에 커넥션 풀 300개를 열면 60,000개예요. 그 API 가 IP 하나로 응답한다면 IP 하나짜리 NAT 는 한도를 넘어요. 필요한 IP 수는 올림(60,000 ÷ 55,000) = 2개예요. 영역 NAT 는 기본 1개 + 보조 7개로 최대 8개(440,000 연결), 리전 NAT 는 AZ 하나에 32개까지 붙일 수 있어요. 다만 퍼블릭 NAT 하나에 붙일 수 있는 탄력적 IP 는 기본 2개로 묶여 있어서, 더 붙이려면 서비스 할당량 증가를 먼저 요청해요. IP 를 늘리면 하나마다 공인 IPv4 요금(월 3.65달러)도 붙어요.

한도에 닿았는지는 CloudWatch 의 ErrorPortAllocation 으로 봐요. NAT 게이트웨이 CloudWatch 지표 문서는 이 값이 0보다 크면 "NAT 를 지나는 동시 연결이 너무 많다"는 뜻이라고 적어요. IP 를 늘리기 전에 커넥션 풀 크기부터 줄일 수 있는지 봐요. 파드마다 300개 풀은 대개 과해요.

350초 유휴 타임아웃

NAT 를 지나는 연결이 350초 이상 아무 패킷도 없으면 끊겨요. 문제 해결 문서는 이때 NAT 가 뒤쪽 리소스에 RST 를 보낸다고 적어요. 앱 입장에서는 커넥션 풀에서 꺼낸 연결로 요청을 보냈더니 "connection reset" 이 나는 증상이에요. 6분 넘게 쉬는 시간대가 있는 배치, 밤새 조용한 관리자 API, 롱 폴링에서 잘 보여요.

리눅스 기본값으로는 막을 수 없어요. 리눅스 커널 ip-sysctl 문서의 tcp_keepalive_time 기본값이 2시간(7,200초)이라, keepalive 를 켜도 첫 탐지 패킷이 나가기 전에 NAT 가 이미 연결을 지워요. 손볼 곳은 두 군데예요.

커널 값은 앱이 소켓에 keepalive 옵션(SO_KEEPALIVE)을 켠 연결에만 적용돼요. 그래서 실무에서는 풀의 유휴 연결 만료를 350초보다 짧게 두는 쪽이 더 확실해요. 끊길 연결을 처음부터 쓰지 않게 하는 거예요. 지표로는 IdleTimeoutCount 가 늘어나는지 봐요. 지표 문서는 이 값이 증가하면 "오래된 연결을 다시 쓰고 있을 수 있다"고 설명해요.

프라이빗 서브넷에서 인터넷이 안 될 때 확인 순서

새 서브넷에서 curl 이 타임아웃 나면 원인은 대부분 다섯 군데 중 하나예요. 위에서부터 보면 빠르게 좁혀져요.

1. NAT 상태가 Available 인가. Failed 로 끝난 NAT 는 자동 삭제되니 목록에서 사라졌을 수도 있어요. 라우팅 테이블에 대상이 blackhole 로 남아 있으면 이 경우예요.
2. 인스턴스 서브넷의 라우팅 테이블. 0.0.0.0/0 이 NAT 를 가리키는지, 그리고 더 구체적인 경로(예: 사내망 대역을 VPN 으로)가 목적지를 먼저 가로채지 않는지 봐요. 서브넷을 명시적으로 연결하지 않았다면 메인 라우팅 테이블을 타요.
3. NAT 가 놓인 서브넷의 라우팅 테이블. 여기에 인터넷 게이트웨이 경로가 있어야 해요. NAT 를 실수로 프라이빗 서브넷에 만들면 1·2번이 멀쩡해도 나가지 못해요. 리전 NAT 는 자체 라우팅 테이블을 쓰니 이 단계가 없어요.
4. 보안 그룹과 네트워크 ACL. 보안 그룹은 아웃바운드만 열려 있으면 응답이 자동으로 들어와요. ACL 은 응답도 다시 검사하니 퍼블릭·프라이빗 두 서브넷 모두 인바운드에 임시 포트 범위가 열려 있어야 해요. ping 으로 시험한다면 ICMP 도 열어요.
5. 도구로 확정. VPC 플로우 로그에서 REJECT 가 찍히는 지점을 찾거나, Reachability Analyzer로 인스턴스에서 인터넷 게이트웨이까지 경로를 분석해요. 분석 1회에 0.10달러(서울 리전)라 추측으로 설정을 여러 번 바꾸는 것보다 싸요.

증상별로는 이렇게 좁혀요.

서브넷 크기와 도입 전에 따질 것

NAT 와 함께 정하는 게 서브넷 크기예요. 서브넷 크기 문서대로 서브넷은 /16~/28 사이이고, 앞 4개와 마지막 1개 주소는 AWS 가 가져가요. 쓸 수 있는 주소는 /24 가 251개, /26 이 59개, /28 은 11개예요. 퍼블릭 서브넷은 NAT·로드 밸런서 정도만 두니 작게, 프라이빗 서브넷은 인스턴스·컨테이너·인터페이스 엔드포인트 ENI 가 모두 주소를 쓰니 넉넉하게 잡아요. 대역 나누기는 IP 서브넷 계산기로 바로 확인되고, 마스크 계산 원리는 서브넷 마스크·CIDR 계산법에 정리돼 있어요.

도입 전 체크리스트예요.

• 외부로 나가는 트래픽이 실제로 얼마인가. 처리 요금이 시간 요금보다 큰 경우가 많아요. NAT 지표 BytesOutToDestination 과 BytesInFromDestination 을 한 달 합쳐 보면 처리 GB 가 나와요.
• 그중 AWS 서비스 몫은 얼마인가. S3·DynamoDB 는 무조건 게이트웨이 엔드포인트, 나머지는 서비스당 월 수백 GB 기준으로 판단해요.
• IPv6 로 충분한 목적지인가. egress-only 인터넷 게이트웨이는 게이트웨이 요금이 없어요(데이터 전송 요금은 있음). IPv4 전용 목적지에는 쓸 수 없어요.
• NAT 인스턴스로 아낄 만한가. NAT 인스턴스 문서대로 직접 만들 수는 있지만 패치·이중화·대역폭 관리가 모두 내 몫이에요. 개발 환경 정도에서만 따져 볼 만해요.
• 인프라 코드로 AZ 수만큼 만들어지는가. NAT 를 늘려 놓고 프라이빗 라우팅 테이블을 하나로 두면 모두 한 NAT 로 몰려요. 테라폼이라면 NAT·라우팅 테이블·연결을 같은 AZ 목록으로 반복시켜요. 여러 리소스를 한 번에 바꿀 때의 순서 문제는 테라폼 parallelism·depends_on 판단표를 참고해요.

자주 묻는 질문

NAT 게이트웨이 비용이 갑자기 늘었어요. 어디부터 보나요?

비용 탐색기에서 사용 유형을 NatGateway-Hours 와 NatGateway-Bytes 로 나눠 봐요. 대부분 Bytes 쪽이 원인이에요. 그다음 NAT 의 CloudWatch 처리량 지표가 어느 시간대에 튀는지 보고, 그 시간에 도는 배치·이미지 배포·로그 전송을 찾아요. S3·ECR 트래픽이면 엔드포인트로 바로 줄일 수 있어요.

개발 환경에서는 NAT 를 아예 꺼 둬도 되나요?

업무 시간에만 쓴다면 NAT 를 삭제했다가 다시 만드는 자동화로 시간 요금을 줄일 수 있어요. 다만 새로 만들면 NAT ID 가 바뀌니 라우팅 테이블도 함께 갱신해야 하고, 탄력적 IP 를 외부 허용 목록에 등록해 뒀다면 같은 EIP 를 다시 붙여야 해요. NAT 를 지운 뒤 붙어 있지 않은 EIP 도 유휴 공인 IPv4 요금(시간당 0.005달러)이 나가요.

리전 NAT 게이트웨이로 바꾸면 비용이 줄어드나요?

요금 단가는 영역 NAT 와 같고 활성 AZ마다 시간 요금이 붙어서, AZ 3개면 영역 NAT 3대와 비슷해요. 얻는 건 비용보다 관리 단순화예요. 퍼블릭 서브넷이 필요 없고, AZ마다 라우팅 테이블을 따로 둘 필요가 없어요. 프라이빗 연결 유형이 필요하거나 새 AZ 확장 대기(최대 60분)가 문제라면 영역 NAT 를 유지해요.

보안 그룹을 NAT 게이트웨이에 붙일 수 있나요?

없어요. NAT 게이트웨이에는 보안 그룹을 연결할 수 없고, NAT 가 놓인 서브넷의 네트워크 ACL 만 적용돼요. 나가는 트래픽을 제한하고 싶다면 인스턴스 쪽 보안 그룹의 아웃바운드 규칙이나 서브넷 ACL 로 막아요.

외부 API 가 우리 IP 를 허용 목록에 넣어 달래요. 어떤 IP 를 주나요?

NAT 에 붙인 탄력적 IP 를 줘요. AZ마다 NAT 를 두면 IP 가 AZ 수만큼이고, 연결 한도 때문에 보조 IP 를 붙였다면 그것까지 모두 등록해야 해요. 일부만 등록하면 특정 AZ 나 특정 연결에서만 간헐적으로 거부되는, 찾기 어려운 장애가 생겨요.

정리

• 서울 리전 NAT 게이트웨이는 대당 월 약 47달러(시간+IPv4)에 처리 GB당 0.059달러예요. 청구서의 큰 몫은 대개 처리 요금이에요.
• AZ 3개에 고른 트래픽이라면 월 7TB 아래는 1대 공유가 싸지만, 운영 환경은 장애 격리를 위해 AZ마다 또는 리전 NAT 로 둬요.
• S3·DynamoDB 는 게이트웨이 엔드포인트(무료)로 빼고, 인터페이스 엔드포인트는 서비스당 월 약 581GB(AZ 3개 기준)를 넘을 때 붙여요.
• 운영 사고는 350초 유휴 타임아웃과 목적지당 55,000 연결에서 많이 나요. 풀 유휴 만료를 300초 이하로, IdleTimeoutCount·ErrorPortAllocation 에 경보를 걸어 둬요. 단가는 2026-11-07 확인 기준이니 도입 전에 가격표를 다시 봐요.

더 깊이 읽기

이 글은 실무에서 판단할 때 필요한 것 위주로 정리했어요. 같은 주제의 내부 동작 원리는 devboi 기술 블로그의 AWS VPC 패킷 흐름 원리 — 서브넷·라우팅 테이블·NAT에서 도식과 코드로 단계별로 풀었어요.