AWS NAT Gateway로 하루 900달러 날린 이유와 진짜 해결책

AWS를 오래 써온 사람도 한 번 헛디디면, 하루 만에 900달러를 태워버릴 수 있습니다. 특히 NAT Gateway와 S3, VPC Endpoint가 얽히면 더더욱 그렇죠.

오늘은 "EC2에서 S3로 가는 트래픽은 무료"라는 말을 그대로 믿었다가, 며칠 만에 1,000달러 넘는 요금을 맞이한 실제 사례를 바탕으로, 왜 이런 일이 벌어졌는지, 어떻게 막을 수 있는지, 그리고 지금 당장 무엇을 확인해야 하는지까지 한 번에 정리해 드리겠습니다.

AWS 초보는 물론이고, 몇 년째 운영 중인 분들에게도 꽤 아픈 일깨움이 될 이야기예요.

NAT Gateway 때문에 AWS 요금 폭발하는 전형적인 시나리오

이야기는 꽤 단순하게 시작됩니다.

한 회사가 미국·캐나다 주소 지오코딩 서비스를 운영하면서, 내부에서 사용하는 대용량 지리 데이터들을 S3에 미러링하기로 했습니다. 주소 포인트, 경계 데이터, 센서스 정보 같은 파일들이고, 크기는 몇 GB에서 수백 GB까지 다양합니다.

데이터는 이렇게 움직였습니다.

• ETL 플랫폼: Hetzner에 호스팅

• AWS 쪽: EC2 기반의 처리 인프라

• S3: 내부 데이터 미러링용 버킷

설계자는 AWS 데이터 전송 비용을 꼼꼼히 확인했습니다.

• S3로 유입(in)되는 트래픽: 무료

• 같은 리전에 있는 EC2 ↔ S3 간 데이터 전송: 무료

"좋아, 이 정도면 비용 예측 끝났다." 그렇게 생각하고 안심한 채, 테라바이트 단위의 동기화를 돌리기 시작했습니다.

그리고 며칠 뒤, AWS Cost Anomaly Detection에서 알림이 하나 날아옵니다.

하루 만에 NAT Gateway 데이터 처리량이 20TB를 넘었고, 그날 요금만 907.53달러. 월 누적은 이미 1,000달러를 넘어 있었습니다.

"아니, EC2에서 S3로 가는 전송은 무료라면서요…?" 문제는 요금 정책이 아니라, 네트워크 경로에 숨어 있었습니다.

EC2에서 S3로 가는데, 왜 NAT Gateway 요금이 나오나

핵심은 이겁니다. VPC 안에 있는 EC2 인스턴스가 S3에 접근할 때, "기본값으로는" 어떤 경로를 타고 나가느냐입니다.

대부분의 프로덕션 환경은 이렇게 구성돼 있습니다.

• 프라이빗 서브넷에 EC2 배치

• 인터넷 접근은 NAT Gateway를 통해서만 가능

• 퍼블릭 서브넷에는 NAT Gateway 또는 ALB 등 배치

이 상태에서 EC2가 S3에 요청을 보내면, 보통은 이렇게 흐릅니다.

1. EC2 → 프라이빗 서브넷 라우팅 테이블

2. S3는 퍼블릭 서비스이므로, 라우팅 규칙상 NAT Gateway로 향함

3. NAT Gateway를 통해 인터넷으로 나갔다가

4. 다시 AWS 내부에서 S3로 들어감

즉, "같은 리전의 S3로 가는 트래픽"이라도, VPC 입장에서 보면 "인터넷으로 나가는 트래픽"처럼 NAT Gateway를 거쳐버립니다.

문제는 여기서부터입니다.

• S3 자체의 데이터 전송 요금: EC2 → S3는 무료

• 하지만 NAT Gateway의 데이터 처리 요금: 약 $0.045/GB

테라바이트 단위로 왔다 갔다 하면, 순식간에 수백·수천 달러로 튀어 버립니다.

정리하자면:

• "EC2↔S3 전송 무료"는 맞는 말이지만,

• "NAT Gateway를 통과하는 데이터 처리 비용"은 별도입니다.

• 이걸 피하지 않으면, 요금 폭탄은 시간문제입니다.

그리고 이를 완벽하게 우회하는 비밀通로가 바로 VPC Endpoint입니다.

S3 VPC Endpoint로 NAT Gateway 비용 깔끔하게 없애는 방법

AWS가 이런 상황을 모르고 있을 리는 당연히 없습니다. 이미 답도 깔끔하게 준비해 두었죠. 이름은 "VPC Endpoint", 그중에서도 "Gateway Endpoint for S3"입니다.

Gateway Endpoint는 쉽게 말해서 이런 역할을 합니다.

• "이 VPC에서 S3 갈 때, 굳이 NAT Gateway 거치지 말고,

• 내부 전용 통로로 바로 가세요."

조금 더 기술적으로 보면 다음과 같습니다.

• VPC에 "S3용 Gateway Endpoint" 리소스를 생성하고

• 특정 라우팅 테이블에 "S3로 가는 트래픽은 이 Endpoint로"라고 설정

• 그러면 S3 트래픽은 인터넷이나 NAT Gateway를 통과하지 않고

• AWS 내부망을 통해 직접 S3로 향합니다

그리고 가장 중요한 포인트:

• Gateway Endpoint 자체는 시간당 비용이 없습니다.

• 이 Endpoint를 통해 흐르는 데이터에 "추가 전송 요금"도 없습니다.

• NAT Gateway를 통과하지 않으니 NAT 비용도 0입니다.

즉, 설정만 제대로 하면:

• EC2 ↔ S3 트래픽: 여전히 무료

• NAT Gateway 데이터 처리비: 발생하지 않음

• 보안 측면에서도 공용 인터넷을 안 타서 더 좋음

이걸 몰라서 하루에 900달러를 태웠다… 라고 생각하면, 정말 허탈하지만, 동시에 많은 팀들이 똑같은 실수를 반복하고 있다는 점이 더 무섭습니다.

Terraform으로 S3 Gateway Endpoint 설정할 때의 핵심 포인트

실제 사례에서는 Terraform으로 인프라를 관리하고 있어서, 수정은 비교적 간단했습니다. 코드 한두 개 리소스만 추가하면 끝나는 일이었죠.

일반적인 구성 흐름은 이렇습니다.

1. S3용 Gateway Endpoint 리소스 생성

2. 해당 Endpoint를 연결할 VPC 지정

3. 프라이빗 서브넷이 사용하는 라우팅 테이블에 이 Endpoint를 연결

4. 이후 EC2에서 S3로 나가는 경로가 NAT가 아닌 Endpoint로 변경

Terraform을 쓰든, 콘솔로만 쓰든 핵심은 같아요.

• "프라이빗 서브넷 라우팅 테이블에 S3용 Gateway Endpoint가 연결되어 있는가?"

• "0.0.0.0/0 → NAT Gateway만 있는 건 아닌가?"

이 두 가지만 확인해도, NAT Gateway 비용 폭탄을 피할 수 있습니다.

코드 인프라를 운영 중이라면, 한 번 고쳐두면 이후 동일 패턴의 VPC에 자동으로 적용되니, 장기적으로도 이득이 큽니다.

AWS 요금 폭탄을 피하기 위한 세 가지 필수 체크리스트

이번 사건에서 얻은 가장 큰 교훈은 "클라우드는 늘 뭔가를 숨기고 있다"는 사실이었습니다. 특히 네트워킹과 과금 구조가 맞물리는 지점이 그렇습니다.

비슷한 실수를 막기 위해, 다음 세 가지는 지금 바로 점검해 보시는 걸 추천합니다.

첫째, AWS Cost Anomaly Detection을 꼭 켜두세요. 이번 사례처럼, 며칠 안에 이상 징후를 잡아주지 않았다면, 한 달 뒤 청구서를 보고 더 큰 멘붕을 겪었을 겁니다. 권장 설정은 간단합니다. 주요 서비스별(예: NAT Gateway, Data Transfer, S3, CloudFront 등) 이상 비용 감지를 켜두고, 이메일이나 Slack으로 알림을 받도록 설정하세요.

둘째, VPC Endpoint(S3, DynamoDB)는 "선택"이 아니라 "필수"입니다.

• EC2가 프라이빗 서브넷에 있고

• S3나 DynamoDB에 자주 접근한다면 Gateway Endpoint를 안 쓰는 건 그냥 돈을 버리는 일입니다. 게다가 성능도 좋아지고, 보안 면에서도 내부 경로를 쓰니 이득뿐입니다.

셋째, "당연히 무료겠지"라고 생각한 구간은 반드시 실측해 보세요.

• 소량의 데이터를 먼저 전송해 보고

• 하루 정도 요금 변화를 모니터링한 뒤

• 이상 징후가 없는 것을 확인하고 나서

• 대규모 작업을 돌리는 습관이 필요합니다.

"EC2에서 S3는 무료" 같은 문장은 반은 진실이고, 나머지 반은 맥락을 요구합니다. 그 맥락이 바로 NAT Gateway, VPC 라우팅, Endpoint입니다.

다른 회사도 당한 AWS 비용 함정들

이런 일이 특정 팀만의 실수일까요? 그렇지 않습니다.

최근 몇 년 사이에 공개된 사례들만 봐도, 꽤 많은 회사가 AWS 네트워크와 관련된 요금 함정에 빠졌습니다.

예를 들어, Recall.ai는 WebSocket 데이터 처리 비용 구조를 잘못 이해해서, 연간 100만 달러 가까운 예상치 못한 사용료를 지불하고 있었습니다. 서비스가 잘 성장하는 만큼 트래픽도 함께 늘었는데, 그에 따라 요금도 폭발적으로 따라 올라간 것이죠.

이 공통점은 분명합니다.

• 팀도 유능했고

• AWS 경험도 어느 정도 있었고

• 문서도 나름대로 읽었지만

과금 구조의 "구체적인 경로"까지는 깊게 파고들지 못했다는 것.

클라우드에서는 "작게 시작해서, 비용과 아키텍처를 함께 검증하며 키워가는 습관"이 없으면, 언제든지 이런 요금 폭탄을 맞을 수 있습니다.

지금 당장 점검해야 할 AWS 인프라 체크 포인트

이 글을 여기까지 읽으셨다면, 이제 할 일은 생각보다 명확합니다.

우선, 현재 운영 중인 VPC들을 한 번 훑어보세요.

• 프라이빗 서브넷에서 S3로 자주 접근하는가?

• 해당 VPC에 S3용 Gateway Endpoint가 설정돼 있는가?

• 라우팅 테이블에서 S3가 NAT Gateway로 향하고 있지는 않은가?

그다음에는 비용 모니터링 설정입니다.

• AWS Cost Anomaly Detection이 켜져 있는지

• NAT Gateway, Data Transfer, S3 등 주요 서비스별 비용 그래프에 이상치는 없는지

• 지난 3~6개월간 패턴을 봤을 때, 점점 기울기가 커지는 항목은 없는지

마지막으로, 새로 설계하는 아키텍처에는 다음 두 문장을 아예 원칙으로 박아두면 좋습니다.

• "프라이빗 서브넷에서 S3·DynamoDB 접근 시, 반드시 Gateway Endpoint를 사용한다."

• "대규모 데이터 이동이나 신규 프로토콜(WebSocket 등)은, 먼저 소량 테스트 후 비용 패턴을 확인한다."

마무리: 1,000달러짜리 실수, 여러분은 안 겪었으면 좋겠습니다

이번 이야기의 결론은 아주 단순합니다.

• NAT Gateway는 "지나는 모든 트래픽"에 대해 비용을 청구합니다.

• S3처럼 자체 전송 요금은 무료라도, NAT를 타면 NAT 요금이 발생합니다.

• 이를 피하려면 VPC Endpoint, 특히 S3 Gateway Endpoint를 반드시 써야 합니다.

클라우드는 강력하지만, 그만큼 복잡합니다. 10년, 20년 AWS를 써도, 새로운 함정은 계속 등장합니다.

그렇다고 겁먹을 필요는 없습니다.

• 비용 감지(Anomaly Detection)를 켜두고

• VPC 라우팅과 Endpoint 설정을 습관적으로 점검하고

• "무료일 것 같다" 싶은 구간은 꼭 검증해 보는 것만으로도

대부분의 큰 사고는 충분히 막을 수 있습니다.

혹시 이 글을 읽고 "우리 NAT Gateway 요금 한 번 봐야겠다…"라는 생각이 들었다면, 이미 1,000달러짜리 교훈은 충분히 건진 셈입니다. 이제 여러분 차례입니다. 콘솔을 열고, VPC와 NAT, 그리고 S3 Endpoint 설정을 한 번만 점검해 보세요. 그 몇 분이, 다음 달 청구서에서 큰 차이를 만들어 줄 겁니다.

출처 및 참고 : The $1,000 AWS mistake | Blog