NAT 게이트웨이 요금이 갑자기 늘었을 때 확인할 순서

NAT 게이트웨이는 시간당 요금과 데이터 처리 요금이 따로 붙는다. 트래픽이 없어도 떠 있기만 하면 시간당 요금은 계속 나간다.
청구서가 튀었다면 대부분 원인은 셋 중 하나다. S3·DynamoDB 트래픽이 NAT를 지나가거나, 가용영역을 넘나들거나, 안 쓰는 NAT가 떠 있는 경우다.
게이트웨이 엔드포인트로 옮길 수 있는 트래픽부터 걷어내는 것이 효과가 가장 크다. 시간당 요금도 데이터 처리 요금도 붙지 않는다.

요금이 어떻게 붙는지부터

AWS는 NAT 게이트웨이가 사용 가능한 상태로 있는 매 시간과, 처리한 데이터 기가바이트당으로 나누어 과금한다고 명시하고 있다. (문서)

두 가지를 구분해야 한다.

• 시간당 요금 — NAT 게이트웨이가 프로비저닝되어 있는 매 시간. 트래픽 0이어도 나간다.
• 데이터 처리 요금 — NAT 게이트웨이를 통과한 GB당. 나가는 트래픽과 들어오는 응답 트래픽이 모두 계산된다.

서울 리전(ap-northeast-2)은 시간당 USD 0.059, 처리 데이터 GB당 USD 0.059다. 미국 동부(오하이오)의 $0.045보다 비싸니 해외 리전 기준으로 계산한 글을 그대로 믿으면 안 된다. (VPC 요금)

트래픽이 0이어도 한 달(730시간)이면 시간당 요금만 약 USD 43이다. NAT 게이트웨이 하나당이고, AZ마다 하나씩 두면 그만큼 곱해진다.

여기에 놓치기 쉬운 세 가지가 붙는다.

1. 데이터 처리 요금은 소스나 대상과 무관하게 붙는다. 인터넷으로 나가든 같은 리전의 S3로 가든, NAT 게이트웨이를 통과했으면 GB당 요금이 계산된다.
2. 1시간 미만도 1시간으로 청구된다. 잠깐 만들었다 지운 것도 한 시간치가 나간다.
3. 표준 AWS 데이터 전송 요금이 별도로 발생한다. NAT 데이터 처리 요금과 전송 요금은 다른 항목이고 둘 다 청구된다.

첫 번째 항목에서 첫 번째 확인 대상이 나온다.

확인 1. S3·DynamoDB 트래픽이 NAT를 지나고 있나

프라이빗 서브넷의 EC2가 S3에 파일을 올리고 내린다면, 라우팅 테이블에 게이트웨이 엔드포인트가 없는 한 그 트래픽은 NAT 게이트웨이를 지난다. 로그 적재나 배치 작업이 있다면 이 한 갈래가 청구서의 대부분일 수 있다.

게이트웨이 타입 VPC 엔드포인트는 시간당 요금도 데이터 처리 요금도 붙지 않는다. AWS 요금 페이지에 그렇게 적혀 있다. (문서)

먼저 NAT를 얼마나 지나는지 실제 수치를 본다.

# 최근 7일간 NAT 게이트웨이가 외부로 내보낸 바이트 (일 단위 합계)
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0123456789abcdef0 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time   "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Sum \
  --query 'Datapoints[].{Day:Timestamp,Bytes:Sum}' --output table

BytesOutToDestination은 "NAT 게이트웨이를 통해 목적지로 나간 바이트"다. 함께 볼 만한 지표는 BytesInFromDestination(목적지에서 받은 바이트), ActiveConnectionCount(동시 활성 TCP 연결 수)다.

수치가 크다면 S3 게이트웨이 엔드포인트를 만든다.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.ap-northeast-2.s3 \
  --route-table-ids rtb-0123456789abcdef0

라우트 테이블에 엔드포인트가 붙으면 해당 프리픽스 목적지 트래픽이 NAT를 거치지 않는다. DynamoDB도 같은 방식이다.

S3·DynamoDB가 아닌 서비스(ECR, CloudWatch Logs, SSM 등)는 인터페이스 엔드포인트(PrivateLink)를 써야 하고, 이쪽은 게이트웨이 엔드포인트와 달리 요금이 붙는다. 서울 리전 기준 AZ별 엔드포인트당 시간당 USD 0.013, 처리 데이터는 리전 월 합계 1PB까지 GB당 USD 0.01이다(그 이상은 더 싸진다). (VPC 요금)

NAT와 비교하면 GB당 0.059에서 0.01로 떨어지니 GB당 0.049를 아낀다. 대신 AZ마다 시간당 고정 요금이 새로 붙는다. AZ 하나에 월 약 USD 9.5이므로 손익분기는 AZ당 월 194GB다. 2개 AZ에 걸면 약 390GB. 그 서비스로 나가는 트래픽이 이보다 적으면 엔드포인트를 만드는 쪽이 오히려 비싸다.

주의할 점은 NAT 게이트웨이의 시간당 요금은 그대로 남는다는 것이다. 인터페이스 엔드포인트는 데이터 처리 요금만 줄인다. 시간당 요금까지 없애려면 NAT를 통과하는 트래픽을 전부 걷어내고 NAT 자체를 삭제해야 한다.

확인 2. 가용영역을 넘고 있나

NAT 게이트웨이는 특정 가용영역에 만들어지고, 그 영역 안에서만 이중화된다. 영역을 넘어 자동으로 대체되지 않는다. (문서)

AZ-a의 NAT 하나로 AZ-a·AZ-c의 인스턴스를 모두 내보내고 있다면, AZ-c 트래픽은 AZ를 넘어간다. AWS가 요금 절감 전략의 첫 항목으로 드는 것이 이 경우다. AZ 간 전송량이 많다면 리소스를 NAT 게이트웨이와 같은 AZ에 두거나, 리소스가 있는 AZ마다 NAT를 만들라고 권한다. (문서)

가용성 측면에서도 같은 결론이 나온다. NAT 하나를 여러 AZ가 공유하면 그 AZ가 죽을 때 나머지 AZ의 인스턴스도 인터넷이 끊긴다.

다만 AZ마다 NAT를 만들면 시간당 요금이 AZ 수만큼 늘어난다. AZ 간 전송량이 적은 소규모 환경이라면 NAT 하나가 더 쌀 수 있다. 실제 전송량을 보고 정하는 편이 맞다.

확인 3. 안 쓰는 NAT가 떠 있나

시간당 요금은 트래픽과 무관하다. 테스트용으로 만들고 지우지 않은 것, 서브넷 구조를 바꾸면서 라우팅에서 빠진 것이 한 달에 USD 43씩 조용히 나간다. 트래픽이 0이라 CloudWatch 대시보드에서도 눈에 띄지 않는다.

# 계정의 모든 available 상태 NAT 게이트웨이
aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{Id:NatGatewayId,VPC:VpcId,Subnet:SubnetId,Created:CreateTime}' \
  --output table

목록의 각 NAT에 대해 ActiveConnectionCount가 계속 0이면 라우팅에서 빠진 것이다. BytesOutToDestination이 0인데 상태가 available이면 시간당 요금만 나가고 있다.

대안 비교

서울 리전 기준이다.

방식	시간당 요금	데이터 처리 요금	관리 부담	적합한 경우
NAT 게이트웨이	USD 0.059	USD 0.059/GB	없음 (관리형)	기본 선택
게이트웨이 엔드포인트 (S3·DynamoDB)	없음	없음	낮음	S3·DynamoDB 트래픽 전량
인터페이스 엔드포인트 (PrivateLink)	USD 0.013 (AZ당)	USD 0.01/GB	낮음	해당 서비스 트래픽이 AZ당 월 194GB 이상일 때
NAT 인스턴스 (EC2 직접 운영)	EC2 + EBS + EIP	데이터 전송 요금	높음	아래 세 조건을 모두 만족할 때

NAT 인스턴스 비용을 "NAT 게이트웨이보다 싸다"로 단순화하면 안 된다. EC2 인스턴스 요금에 EBS 볼륨, Elastic IP, 데이터 전송 요금이 각각 따로 붙고, 이중화를 하면 그 전부가 두 배가 된다. 트래픽 패턴과 이중화 여부에 따라 결과가 뒤집히므로 손익분기를 숫자 하나로 말할 수 없다.

판단은 비용 계산이 아니라 조건으로 하는 편이 낫다. 월 데이터 처리량이 적고, 짧은 다운타임을 감수할 수 있고, 인스턴스를 관리할 사람이 있을 때만 검토할 만하다. 셋 중 하나라도 아니면 NAT 게이트웨이가 낫다.

관리형이라는 것의 실질도 여기 있다. NAT 게이트웨이는 5 Gbps에서 시작해 100 Gbps까지, 초당 100만 패킷에서 1,000만 패킷까지 자동으로 확장된다. NAT 인스턴스는 이 확장을 인스턴스 타입 변경으로 직접 해야 하고, 그동안 트래픽은 끊긴다.

줄이기 전에 알아둘 제약

• 보안 그룹을 NAT 게이트웨이에 붙일 수 없다. 트래픽 제어는 인스턴스 쪽 보안 그룹이나 서브넷 네트워크 ACL로 한다. NAT 게이트웨이는 1024–65535 포트를 쓴다.
• 연결은 항상 VPC 안에서 시작해야 한다. 외부에서 들어오는 연결은 NAT 게이트웨이로 받을 수 없다.
• IPv4 주소 하나당 동일 목적지에 대해 동시 연결 55,000개까지다. 목적지는 IP·포트·프로토콜 조합으로 구분한다. 부족하면 보조 IPv4 주소를 최대 8개까지 붙일 수 있다.
• ErrorPortAllocation 지표가 0보다 크면 동시 연결이 너무 많아 소스 포트를 할당하지 못한 것이다. 요금이 아니라 장애로 이어지는 신호다.

FAQ

NAT 게이트웨이를 껐다 켜면 요금이 줄어드나
시간당 요금은 삭제해야만 멈춘다. 정지 상태라는 것이 없어서 요금을 안 내려면 삭제하는 수밖에 없다. 다만 1시간 미만 사용도 1시간으로 청구되므로 자주 만들었다 지우면 절감 폭이 생각보다 작다. 삭제 후 다시 만들면 Elastic IP가 바뀌어 외부 IP 화이트리스트 연동이 끊기는 것도 문제다. 배치 시간대에만 필요한 구조라면 EIP를 미리 할당해두고 재사용하는 방식으로 자동화해야 한다.

게이트웨이 엔드포인트를 만들면 기존 라우팅이 깨지지 않나
게이트웨이 엔드포인트는 지정한 라우트 테이블에 S3 프리픽스 리스트 경로를 추가하는 방식이다. 해당 프리픽스 목적지만 엔드포인트로 가고 나머지는 기존 경로를 그대로 탄다. 다만 라우트 테이블을 지정하지 않으면 아무 효과가 없으니 --route-table-ids를 빠뜨리지 않아야 한다.

프라이빗 NAT 게이트웨이를 쓰면 요금이 안 나오나
나온다. 프라이빗 NAT 게이트웨이도 시간당 요금과 데이터 처리 요금이 붙는다. 퍼블릭과의 차이는 인터넷 게이트웨이로 나가지 않고 Transit Gateway나 가상 프라이빗 게이트웨이를 통해 다른 VPC·온프레미스로 간다는 점이다. Elastic IP를 붙일 수 없다.