NAT 게이트웨이로 프라이빗 서브넷 인터넷 연결 완벽 가이드

AWS VPC의 프라이빗 서브넷에서 인터넷에 접근하는 방법을 NAT 게이트웨이를 통해 배웁니다. 보안을 유지하면서 외부 API 호출, 패키지 업데이트 등을 수행하는 핵심 네트워크 아키텍처를 쉽게 이해할 수 있습니다.

---

목차

1. NAT_게이트웨이의_필요성
2. NAT_Gateway_vs_NAT_Instance_비교
3. Elastic_IP_할당_및_NAT_Gateway_생성
4. 프라이빗_라우팅_테이블_구성
5. 프라이빗_서브넷_아웃바운드_통신_테스트
6. NAT_Gateway_비용_최적화_팁

---

1. NAT 게이트웨이의 필요성

어느 날 김개발 씨는 프라이빗 서브넷에 배포된 백엔드 서버에서 외부 API를 호출해야 하는 상황에 맞닥뜨렸습니다. 분명히 보안을 위해 프라이빗 서브넷에 서버를 배치했는데, 정작 외부 서비스와 통신이 안 되는 겁니다.

"인터넷이 안 되면 어떻게 npm 패키지를 설치하죠?"

NAT 게이트웨이는 프라이빗 서브넷의 리소스가 인터넷으로 나가는 통신은 허용하면서, 외부에서 들어오는 접근은 차단하는 네트워크 장치입니다. 마치 회사 건물의 경비원이 직원들은 자유롭게 외출하게 해주지만, 외부인은 함부로 들어오지 못하게 막는 것과 같습니다.

이를 통해 보안과 편의성이라는 두 마리 토끼를 모두 잡을 수 있습니다.

다음 코드를 살펴봅시다.

# 프라이빗 서브넷의 EC2에서 인터넷 연결 테스트
# NAT Gateway가 없을 때 - 실패
$ curl https://api.github.com
curl: (7) Failed to connect to api.github.com

# NAT Gateway 설정 후 - 성공
$ curl https://api.github.com
{
  "current_user_url": "https://api.github.com/user",
  "message": "API 응답 성공!"
}

# 외부에서 프라이빗 서브넷 접근 시도 - 차단됨
# 프라이빗 IP는 외부에서 접근 불가

김개발 씨는 입사 6개월 차 클라우드 엔지니어입니다. 오늘 그에게 새로운 미션이 주어졌습니다.

회사의 핵심 백엔드 서버를 AWS 프라이빗 서브넷으로 이전하라는 것이었죠. "프라이빗 서브넷이요?

보안이 중요하니까 당연히 그래야죠!" 김개발 씨는 자신 있게 작업을 시작했습니다. EC2 인스턴스를 프라이빗 서브넷에 띄우고, 데이터베이스도 잘 연결했습니다.

그런데 문제가 생겼습니다. 서버에서 외부 결제 API를 호출해야 하는데, 연결이 되지 않는 겁니다.

npm 패키지 업데이트도 안 되고, 심지어 시간 동기화를 위한 NTP 서버 접속도 실패했습니다. "선배님, 프라이빗 서브넷에서는 인터넷을 아예 못 쓰는 건가요?" 김개발 씨가 박시니어 씨에게 물었습니다.

박시니어 씨가 웃으며 대답했습니다. "아, NAT 게이트웨이를 설정 안 했구나.

프라이빗 서브넷은 기본적으로 인터넷과 완전히 격리되어 있어. 그래서 NAT 게이트웨이라는 중간 다리가 필요해." 그렇다면 NAT 게이트웨이란 정확히 무엇일까요?

쉽게 비유하자면, NAT 게이트웨이는 마치 호텔 컨시어지와 같습니다. 투숙객이 외부 레스토랑에 예약 전화를 하고 싶다면, 컨시어지가 대신 전화를 걸어줍니다.

레스토랑에서는 호텔 대표 번호만 보이지, 투숙객의 객실 내선 번호는 알 수 없습니다. 반대로 외부에서 특정 객실로 직접 전화를 거는 것도 불가능하죠.

NAT는 Network Address Translation의 약자입니다. 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환해주는 역할을 합니다.

프라이빗 서브넷의 EC2가 외부 API를 호출하면, NAT 게이트웨이가 그 요청을 받아서 자신의 퍼블릭 IP로 바꿔서 인터넷에 전달합니다. 응답이 돌아오면 NAT 게이트웨이는 원래 요청을 보낸 EC2에게 응답을 전달합니다.

외부에서는 NAT 게이트웨이의 IP만 보이고, 실제 EC2의 프라이빗 IP는 절대 노출되지 않습니다. 이것이 왜 중요할까요?

데이터베이스 서버, 애플리케이션 서버 같은 핵심 인프라는 외부에서 직접 접근할 수 없어야 합니다. 해커가 IP를 알아도 접근 자체가 불가능해야 하죠.

하지만 이 서버들도 외부 서비스를 호출해야 할 때가 있습니다. 결제 게이트웨이 API 호출, 소프트웨어 패키지 업데이트, 외부 데이터 수집 등 아웃바운드 통신은 필수입니다.

NAT 게이트웨이가 바로 이 딜레마를 해결해줍니다. 나가는 건 되고, 들어오는 건 안 되는 일방통행 도로를 만들어주는 것이죠.

김개발 씨는 고개를 끄덕였습니다. "아, 그래서 프라이빗 서브넷이라고 해도 완전히 고립된 게 아니라, 필요할 때 외부와 안전하게 통신할 수 있는 거군요!"

실전 팁

💡 - 프라이빗 서브넷에 있는 모든 리소스가 인터넷 접근이 필요한지 먼저 검토하세요

• NAT 게이트웨이 없이 VPC 엔드포인트로 AWS 서비스에 접근하는 것이 더 효율적일 수 있습니다

---

2. NAT Gateway vs NAT Instance 비교

박시니어 씨가 화이트보드 앞에 섰습니다. "NAT 기능을 구현하는 방법에는 두 가지가 있어.

NAT 게이트웨이와 NAT 인스턴스야. 어떤 걸 써야 할지 비교해볼까?" 김개발 씨는 펜을 들고 열심히 받아 적기 시작했습니다.

NAT 게이트웨이는 AWS에서 완전 관리해주는 서비스이고, NAT 인스턴스는 EC2에 NAT 소프트웨어를 설치해서 직접 운영하는 방식입니다. NAT 게이트웨이가 자동 확장, 고가용성을 제공하는 반면, NAT 인스턴스는 더 세밀한 제어가 가능하지만 직접 관리해야 합니다.

대부분의 경우 NAT 게이트웨이를 권장합니다.

다음 코드를 살펴봅시다.

# NAT Gateway 생성 (AWS CLI)
aws ec2 create-nat-gateway \
    --subnet-id subnet-0abc123def456 \
    --allocation-id eipalloc-0xyz789 \
    --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=prod-nat-gw}]'

# NAT Instance 생성 시 필요한 추가 설정
# 1. Source/Destination Check 비활성화 필수
aws ec2 modify-instance-attribute \
    --instance-id i-0abc123def456 \
    --no-source-dest-check

# 2. 보안 그룹에서 인바운드/아웃바운드 규칙 직접 관리 필요

박시니어 씨가 화이트보드를 두 칸으로 나눴습니다. 왼쪽에는 'NAT Gateway', 오른쪽에는 'NAT Instance'라고 적었습니다.

"먼저 NAT 인스턴스부터 설명할게. 이건 예전 방식이야.

일반 EC2 인스턴스에 Amazon Linux AMI를 올리고, NAT 설정을 해서 사용하는 거지." NAT 인스턴스는 말 그대로 EC2 서버입니다. 직접 인스턴스를 관리해야 하고, 장애가 나면 직접 복구해야 합니다.

트래픽이 급증하면 인스턴스 타입을 수동으로 올려야 하고, Source/Destination Check도 비활성화해야 합니다. "그럼 NAT 게이트웨이는 뭐가 다른 거예요?" 김개발 씨가 물었습니다.

"NAT 게이트웨이는 AWS가 완전히 관리해주는 서비스야. 네가 할 일은 그냥 만들기만 하면 끝이야." NAT 게이트웨이의 장점은 명확합니다.

첫째, 고가용성입니다. AWS가 가용 영역 내에서 자동으로 이중화를 해줍니다.

장애가 나도 자동으로 복구됩니다. 둘째, 자동 확장입니다.

트래픽이 아무리 늘어나도 최대 45Gbps까지 자동으로 처리합니다. 인스턴스 타입 고민할 필요가 없습니다.

셋째, 관리 부담 제로입니다. 패치, 업데이트, 모니터링을 AWS가 알아서 해줍니다.

운영팀의 야근을 줄여주는 고마운 존재입니다. "그럼 NAT 인스턴스는 왜 쓰는 거예요?

무조건 게이트웨이가 좋은 거 아닌가요?" 박시니어 씨가 비용 항목을 가리켰습니다. "비용이 다르거든.

NAT 게이트웨이는 시간당 요금 + 데이터 처리 요금이 있어. 트래픽이 적으면 NAT 인스턴스가 더 저렴할 수 있지." 하지만 여기서 중요한 점이 있습니다.

NAT 인스턴스를 운영하려면 인건비도 고려해야 합니다. 장애 대응, 패치 관리, 모니터링 설정 등에 드는 시간을 생각하면 NAT 게이트웨이가 총비용 관점에서 유리한 경우가 많습니다.

또 다른 차이점은 보안 그룹입니다. NAT 인스턴스는 보안 그룹을 적용할 수 있어서 세밀한 트래픽 제어가 가능합니다.

NAT 게이트웨이는 보안 그룹을 지원하지 않습니다. 대신 네트워크 ACL로 제어해야 합니다.

"마지막으로 중요한 거 하나. NAT 게이트웨이는 Bastion 호스트로 사용할 수 없어.

SSH 접속 같은 건 안 되거든." 김개발 씨가 표를 정리했습니다. 운영 편의성과 안정성이 중요하면 NAT 게이트웨이, 극한의 비용 절감이나 세밀한 제어가 필요하면 NAT 인스턴스.

하지만 신규 프로젝트라면 99%는 NAT 게이트웨이를 선택한다는 게 결론이었습니다.

실전 팁

💡 - 개발/테스트 환경에서 비용을 아끼려면 NAT 인스턴스를 t3.micro로 사용하는 것도 방법입니다

• 프로덕션 환경에서는 무조건 NAT 게이트웨이를 권장합니다

---

3. Elastic IP 할당 및 NAT Gateway 생성

이제 본격적으로 NAT 게이트웨이를 만들 차례입니다. 김개발 씨가 AWS 콘솔에 로그인했습니다.

"선배님, NAT 게이트웨이 만들기 전에 뭘 먼저 해야 하죠?" 박시니어 씨가 대답했습니다. "Elastic IP부터 할당받아야 해.

NAT 게이트웨이에게 줄 고정 공인 IP 주소가 필요하거든."

NAT 게이트웨이를 생성하려면 먼저 Elastic IP를 할당받아야 합니다. Elastic IP는 AWS에서 제공하는 고정 퍼블릭 IP 주소입니다.

NAT 게이트웨이는 반드시 퍼블릭 서브넷에 생성해야 하며, 이 Elastic IP를 통해 인터넷과 통신합니다.

다음 코드를 살펴봅시다.

# 1. Elastic IP 할당
aws ec2 allocate-address \
    --domain vpc \
    --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=Name,Value=nat-gateway-eip}]'

# 응답 예시
# {
#     "PublicIp": "52.78.123.45",
#     "AllocationId": "eipalloc-0abc123def456789",
#     "Domain": "vpc"
# }

# 2. NAT Gateway 생성 (퍼블릭 서브넷에!)
aws ec2 create-nat-gateway \
    --subnet-id subnet-public-0abc123 \
    --allocation-id eipalloc-0abc123def456789 \
    --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=prod-nat-gateway}]'

# 3. NAT Gateway 상태 확인 (available이 될 때까지 대기)
aws ec2 describe-nat-gateways \
    --nat-gateway-ids nat-0xyz789abc123

김개발 씨가 AWS 콘솔을 열었습니다. VPC 대시보드로 이동해서 NAT 게이트웨이 메뉴를 찾았습니다.

"NAT 게이트웨이 생성" 버튼을 누르려는데, 뭔가 빠진 느낌이 들었습니다. "잠깐, Elastic IP가 필요하다고 하셨죠?" 박시니어 씨가 고개를 끄덕였습니다.

Elastic IP란 AWS에서 할당받는 고정 퍼블릭 IP 주소입니다. 일반적으로 EC2 인스턴스를 중지했다가 다시 시작하면 퍼블릭 IP가 바뀝니다.

하지만 Elastic IP는 계정에 할당된 고정 IP라서 바뀌지 않습니다. NAT 게이트웨이에 Elastic IP가 필요한 이유는 간단합니다.

프라이빗 서브넷의 트래픽이 외부로 나갈 때, 일관된 IP 주소를 사용해야 하기 때문입니다. 외부 API 서버에 특정 IP만 허용하는 화이트리스트가 있다면, Elastic IP를 등록해두면 됩니다.

김개발 씨가 먼저 EC2 콘솔에서 "Elastic IP 주소" 메뉴로 이동했습니다. "탄력적 IP 주소 할당" 버튼을 클릭합니다.

네트워크 경계 그룹은 기본값을 유지하고, 태그만 "nat-gateway-eip"로 지정했습니다. 할당받은 Elastic IP 주소를 확인했습니다.

52.78.123.45 같은 형식의 공인 IP가 부여됩니다. 이 IP는 해제하기 전까지 계속 이 계정에 귀속됩니다.

이제 진짜 NAT 게이트웨이를 만들 차례입니다. VPC 콘솔에서 "NAT 게이트웨이" 메뉴로 이동합니다.

여기서 가장 중요한 점이 있습니다. NAT 게이트웨이는 반드시 퍼블릭 서브넷에 생성해야 합니다.

프라이빗 서브넷에 만들면 안 됩니다! NAT 게이트웨이 자체가 인터넷과 통신해야 하므로, 인터넷 게이트웨이와 연결된 퍼블릭 서브넷에 있어야 합니다.

서브넷을 선택하고, 아까 할당받은 Elastic IP를 선택합니다. 연결 유형은 "퍼블릭"을 선택합니다.

참고로 "프라이빗" 옵션도 있는데, 이건 다른 VPC나 온프레미스와 통신할 때 사용하는 것으로 인터넷 접속 용도가 아닙니다. 생성 버튼을 누르면 NAT 게이트웨이가 만들어지기 시작합니다.

상태가 "Pending"에서 "Available"로 바뀌는 데 보통 1-2분 정도 걸립니다. "선배님, 근데 가용 영역마다 NAT 게이트웨이를 따로 만들어야 하나요?" 좋은 질문입니다.

NAT 게이트웨이는 가용 영역에 종속됩니다. 하나의 AZ에 장애가 나면, 그 AZ의 NAT 게이트웨이도 같이 다운됩니다.

고가용성을 위해서는 각 AZ마다 NAT 게이트웨이를 하나씩 만들고, 각 프라이빗 서브넷이 같은 AZ의 NAT 게이트웨이를 사용하도록 설정하는 것이 좋습니다.

실전 팁

💡 - Elastic IP는 사용하지 않으면 비용이 발생하므로, NAT 게이트웨이 삭제 시 함께 해제하세요

• 프로덕션 환경에서는 각 가용 영역마다 NAT 게이트웨이를 만들어 고가용성을 확보하세요

---

4. 프라이빗 라우팅 테이블 구성

NAT 게이트웨이를 만들었지만, 아직 프라이빗 서브넷에서 인터넷이 안 됩니다. 김개발 씨가 EC2에서 curl을 쳐봤지만 여전히 타임아웃입니다.

"왜 안 되죠?" 박시니어 씨가 웃으며 말했습니다. "라우팅 테이블을 수정 안 했잖아.

네비게이션 없이 운전하려고 하면 안 되지."

NAT 게이트웨이를 만들었다고 자동으로 작동하는 게 아닙니다. 프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이로 향하는 경로를 추가해야 합니다.

0.0.0.0/0(모든 외부 트래픽)을 NAT 게이트웨이로 보내는 규칙을 설정하면 비로소 인터넷 통신이 가능해집니다.

다음 코드를 살펴봅시다.

# 프라이빗 서브넷용 라우팅 테이블 생성
aws ec2 create-route-table \
    --vpc-id vpc-0abc123def456 \
    --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=private-rt}]'

# NAT Gateway로 향하는 라우트 추가 (핵심!)
aws ec2 create-route \
    --route-table-id rtb-private-0abc123 \
    --destination-cidr-block 0.0.0.0/0 \
    --nat-gateway-id nat-0xyz789abc123

# 프라이빗 서브넷에 라우팅 테이블 연결
aws ec2 associate-route-table \
    --route-table-id rtb-private-0abc123 \
    --subnet-id subnet-private-0def456

# 라우팅 테이블 확인
aws ec2 describe-route-tables \
    --route-table-ids rtb-private-0abc123

박시니어 씨가 비유를 들었습니다. "네가 지금 서울에서 부산으로 가려고 해.

고속도로(NAT 게이트웨이)는 이미 있어. 근데 네비게이션에 경로 설정을 안 하면 어떻게 될까?" 김개발 씨가 바로 이해했습니다.

"아, 길을 모르니까 못 가겠네요." 바로 그겁니다. 라우팅 테이블은 네트워크 세계의 네비게이션입니다.

어떤 목적지로 가려면 어떤 경로를 타야 하는지 알려주는 이정표 역할을 합니다. 먼저 현재 라우팅 테이블 구조를 이해해야 합니다.

VPC를 만들면 기본 라우팅 테이블이 생깁니다. 여기에는 VPC 내부 통신을 위한 로컬 라우트만 있습니다.

퍼블릭 서브넷의 라우팅 테이블에는 0.0.0.0/0이 **인터넷 게이트웨이(IGW)**를 가리키고 있습니다. 그래서 퍼블릭 서브넷의 리소스는 직접 인터넷과 통신할 수 있습니다.

프라이빗 서브넷의 라우팅 테이블에는 기본적으로 로컬 라우트만 있습니다. 0.0.0.0/0에 대한 규칙이 없으므로, 외부로 나가는 트래픽은 어디로 가야 할지 몰라서 버려집니다.

해결책은 간단합니다. 프라이빗 서브넷의 라우팅 테이블에 새 규칙을 추가합니다.

"0.0.0.0/0으로 가려면 NAT 게이트웨이를 통해 가라"고 알려주는 것입니다. 김개발 씨가 콘솔에서 작업을 시작했습니다.

VPC 대시보드에서 "라우팅 테이블" 메뉴로 이동합니다. 프라이빗 서브넷과 연결된 라우팅 테이블을 찾습니다.

"라우팅" 탭을 클릭하고 "라우팅 편집" 버튼을 누릅니다. "라우팅 추가"를 클릭합니다.

대상에는 0.0.0.0/0을 입력합니다. 이것은 "모든 IP 주소"를 의미합니다.

더 정확히는 "이 라우팅 테이블의 다른 규칙에 해당하지 않는 모든 트래픽"입니다. 대상 게이트웨이에는 방금 만든 NAT 게이트웨이를 선택합니다.

nat-0xyz789abc123 같은 ID가 드롭다운에 나타납니다. 저장을 누르면 끝입니다.

이제 프라이빗 서브넷의 EC2에서 외부로 나가는 트래픽은 자동으로 NAT 게이트웨이를 경유하게 됩니다. 여기서 중요한 점이 있습니다.

라우팅은 더 구체적인 규칙이 우선입니다. VPC 내부 통신(예: 10.0.0.0/16)은 로컬 라우트가 처리하고, 그 외 모든 트래픽(0.0.0.0/0)만 NAT 게이트웨이로 갑니다.

"근데 만약 프라이빗 서브넷이 여러 개면 어떻게 해요?" 같은 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다. 또는 각 서브넷마다 별도 라우팅 테이블을 만들어서 다른 NAT 게이트웨이를 사용하게 할 수도 있습니다.

실전 팁

💡 - 라우팅 테이블 변경은 즉시 적용되므로 주의해서 작업하세요

• 0.0.0.0/0 라우트를 잘못 설정하면 인터넷 접속이 완전히 끊길 수 있습니다

---

5. 프라이빗 서브넷 아웃바운드 통신 테스트

모든 설정을 마친 김개발 씨가 떨리는 마음으로 프라이빗 서브넷의 EC2에 접속했습니다. "이제 진짜 되는지 테스트해볼게요!" 터미널에서 curl 명령어를 입력하기 전, 박시니어 씨가 조언했습니다.

"단순히 되는지만 확인하지 말고, 어떤 IP로 나가는지도 확인해봐."

NAT 게이트웨이 설정을 완료했다면 실제로 통신이 되는지 테스트해야 합니다. 외부 API 호출 테스트, 퍼블릭 IP 확인, DNS 조회 테스트 등을 통해 정상 작동을 검증합니다.

외부에서 보이는 IP가 NAT 게이트웨이의 Elastic IP와 일치하는지 확인하는 것이 핵심입니다.

다음 코드를 살펴봅시다.

# 프라이빗 서브넷 EC2에서 테스트 (Bastion 또는 SSM으로 접속)

# 1. 기본 인터넷 연결 테스트
$ curl -I https://www.google.com
HTTP/2 200
# 성공! 인터넷 연결 확인

# 2. 외부에서 보이는 IP 확인 (NAT Gateway의 EIP가 나와야 함)
$ curl ifconfig.me
52.78.123.45
# NAT Gateway의 Elastic IP와 일치하면 성공!

# 3. DNS 조회 테스트
$ nslookup google.com
Server:		10.0.0.2
Address:	10.0.0.2#53
Non-authoritative answer:
Name:	google.com

# 4. 패키지 업데이트 테스트
$ sudo yum update -y
# 또는 Ubuntu
$ sudo apt update

설정은 완료했지만, 테스트 없이 "됐겠지"하고 넘어가면 안 됩니다. 실제로 트래픽이 NAT 게이트웨이를 통해 나가는지 확인해야 합니다.

김개발 씨가 먼저 프라이빗 서브넷의 EC2에 접속해야 합니다. 프라이빗 서브넷이므로 직접 SSH 접속은 불가능합니다.

Bastion Host를 통해 접속하거나, AWS Systems Manager Session Manager를 사용해야 합니다. Session Manager를 사용하면 SSH 없이도 웹 콘솔에서 바로 터미널에 접속할 수 있습니다.

프라이빗 서브넷에서도 VPC 엔드포인트만 설정하면 사용 가능합니다. EC2 터미널에 접속한 김개발 씨가 첫 번째 테스트를 시작했습니다.

curl -I https://www.google.com HTTP/2 200 응답이 돌아왔습니다! 드디어 인터넷 연결이 성공했습니다.

하지만 이것만으로는 부족합니다. 정말 NAT 게이트웨이를 통해 나가는지 확인해야 합니다.

다른 경로로 우회하고 있을 수도 있으니까요. 두 번째 테스트입니다.

외부에서 보이는 IP를 확인합니다. curl ifconfig.me 52.78.123.45가 출력됐습니다.

이 IP가 NAT 게이트웨이에 할당한 Elastic IP와 일치합니다. 완벽합니다!

만약 다른 IP가 나온다면 문제가 있는 겁니다. 라우팅 테이블이 잘못 설정됐거나, 다른 경로로 트래픽이 빠져나가고 있을 수 있습니다.

세 번째로 DNS 조회를 테스트합니다. VPC에는 기본적으로 Amazon Provided DNS(VPC CIDR의 두 번째 IP)가 있습니다.

이 DNS가 정상 작동하는지 확인합니다. nslookup google.com Server 주소가 10.0.0.2(VPC DNS)로 나오고, google.com의 IP가 정상적으로 조회됩니다.

마지막으로 실제 업무에서 가장 많이 사용하는 패키지 업데이트를 테스트합니다. sudo yum update -y 패키지 목록을 가져오고, 업데이트가 진행됩니다.

이것까지 성공하면 NAT 게이트웨이가 완벽하게 작동하는 겁니다. 박시니어 씨가 추가로 조언했습니다.

"테스트할 때 보안 그룹도 확인해야 해. NAT 게이트웨이가 잘 작동해도, EC2의 보안 그룹에서 아웃바운드를 막으면 안 되거든." EC2 보안 그룹의 아웃바운드 규칙에 HTTPS(443)와 HTTP(80)가 허용되어 있는지 확인합니다.

기본 보안 그룹은 모든 아웃바운드를 허용하지만, 커스텀 보안 그룹을 사용한다면 확인이 필요합니다. 또한 네트워크 ACL도 체크 포인트입니다.

서브넷 레벨에서 트래픽을 막고 있을 수 있습니다. 기본 NACL은 모든 트래픽을 허용하지만, 수정했다면 확인해야 합니다.

실전 팁

💡 - curl ifconfig.me 결과가 NAT Gateway EIP와 다르면 라우팅 테이블을 재점검하세요

• 보안 그룹 아웃바운드 규칙에서 필요한 포트가 열려 있는지 확인하세요

---

6. NAT Gateway 비용 최적화 팁

한 달 뒤, 김개발 씨가 AWS 청구서를 보다가 깜짝 놀랐습니다. "NAT 게이트웨이 비용이 이렇게 많이 나왔어요?" 박시니어 씨가 청구서를 살펴보며 말했습니다.

"NAT 게이트웨이는 시간당 요금 + 데이터 처리 요금 구조야. 트래픽이 많으면 비용이 꽤 나올 수 있어.

최적화 방법을 알려줄게."

NAT 게이트웨이는 시간당 약 $0.045 + 처리 데이터 GB당 $0.045의 비용이 발생합니다. 트래픽이 많은 서비스에서는 상당한 비용이 될 수 있습니다.

VPC 엔드포인트, NAT 게이트웨이 통합, 비사용 시간 삭제 등의 전략으로 비용을 최적화할 수 있습니다.

다음 코드를 살펴봅시다.

# 1. S3 VPC 엔드포인트 생성 (NAT 우회 - 무료!)
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0abc123def456 \
    --service-name com.amazonaws.ap-northeast-2.s3 \
    --route-table-ids rtb-private-0abc123

# 2. DynamoDB VPC 엔드포인트 (Gateway 타입 - 무료!)
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0abc123def456 \
    --service-name com.amazonaws.ap-northeast-2.dynamodb \
    --route-table-ids rtb-private-0abc123

# 3. NAT Gateway 데이터 처리량 모니터링
aws cloudwatch get-metric-statistics \
    --namespace AWS/NATGateway \
    --metric-name BytesOutToDestination \
    --dimensions Name=NatGatewayId,Value=nat-0xyz789abc123 \
    --start-time 2024-01-01T00:00:00Z \
    --end-time 2024-01-31T23:59:59Z \
    --period 86400 \
    --statistics Sum

NAT 게이트웨이 비용 구조를 먼저 이해해야 합니다. 서울 리전 기준으로 시간당 약 $0.045, 데이터 처리량 GB당 $0.045입니다.

한 달을 계산해보면, 시간당 비용만 $0.045 x 24시간 x 30일 = $32.4입니다. 여기에 데이터 처리 비용이 추가됩니다.

만약 하루 100GB씩 한 달간 전송한다면, 100GB x 30일 x $0.045 = $135가 추가됩니다. 고가용성을 위해 AZ마다 NAT 게이트웨이를 만들면 비용이 2배, 3배로 늘어납니다.

프로덕션 환경에서는 쉽게 월 $200-500 이상 나올 수 있습니다. 첫 번째 최적화 전략은 VPC 엔드포인트입니다.

프라이빗 서브넷에서 S3에 파일을 업로드한다고 가정해봅시다. NAT 게이트웨이를 통해 나가면 데이터 처리 비용이 발생합니다.

하지만 S3 VPC 엔드포인트를 사용하면 트래픽이 AWS 내부망을 통해 직접 S3로 갑니다. NAT 게이트웨이를 거치지 않으므로 비용이 전혀 발생하지 않습니다.

S3와 DynamoDB는 Gateway 타입 VPC 엔드포인트를 사용합니다. 이 엔드포인트 자체도 무료입니다!

라우팅 테이블에 S3/DynamoDB 경로가 자동으로 추가되어, 해당 트래픽은 NAT를 우회합니다. 다른 AWS 서비스(ECR, CloudWatch, SSM 등)는 Interface 타입 엔드포인트를 사용합니다.

이건 시간당 비용이 있지만, 대량의 트래픽이 있다면 NAT보다 저렴할 수 있습니다. "그럼 모든 AWS 서비스에 VPC 엔드포인트를 만들면 되겠네요?" 꼭 그렇지는 않습니다.

Interface 엔드포인트도 비용이 있고, 관리 복잡도도 증가합니다. 트래픽 양을 분석해서 ROI가 나오는 서비스에만 적용하세요.

두 번째 전략은 불필요한 트래픽 줄이기입니다. CloudWatch에서 NAT 게이트웨이의 BytesOutToDestination 메트릭을 확인하세요.

어떤 시간대에 트래픽이 많은지, 예상보다 많은 데이터가 나가는지 파악할 수 있습니다. 의외로 로그 전송, 메트릭 수집, 불필요한 헬스체크 등이 트래픽을 잡아먹는 경우가 많습니다.

로그는 CloudWatch Logs VPC 엔드포인트를 통해 보내고, 메트릭도 CloudWatch 엔드포인트를 활용하세요. 세 번째 전략은 개발 환경 NAT 게이트웨이 관리입니다.

개발/테스트 환경은 업무 시간에만 사용합니다. 그런데 NAT 게이트웨이는 24시간 켜져 있으면서 비용이 발생합니다.

개발 환경에서는 업무 종료 시 NAT 게이트웨이를 삭제하고, 다음 날 다시 생성하는 자동화를 고려해보세요. 또는 개발 환경에서는 NAT 인스턴스(t3.micro)를 사용하는 것도 방법입니다.

성능은 떨어지지만 비용을 크게 줄일 수 있습니다. 네 번째로, 같은 리전 내 AWS 서비스 통신은 원래 무료이지만, NAT를 거치면 데이터 처리 비용이 붙습니다.

VPC 엔드포인트를 적극 활용하면 이 비용을 없앨 수 있습니다. 김개발 씨가 정리했습니다.

"S3랑 DynamoDB VPC 엔드포인트부터 만들고, CloudWatch로 트래픽 패턴을 분석해봐야겠네요!"

실전 팁

💡 - S3, DynamoDB Gateway 엔드포인트는 무료이므로 무조건 생성하세요

• CloudWatch에서 NAT Gateway 데이터 전송량을 주기적으로 모니터링하세요
• 개발 환경에서는 NAT Instance(t3.micro)로 비용을 90% 이상 절감할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!