[AWS] NAT Gateway 사용법·설정 가이드 — Private Subnet 인터넷 연결과 비용 최적화
1. NAT Gateway가 필요한 이유
그림 1. NAT Gateway 유무에 따른 Private Subnet 통신 구조 비교
VPC 내부의 Private Subnet에 위치한 인스턴스는 보안을 위해 공인(Public) IP를 갖지 않는다. 하지만 보안 패치 업데이트(apt·yum·dnf)나 외부 API 통신을 위해서는 인터넷 연결이 필수다. 이때 보안은 유지하면서 아웃바운드(Outbound) 통신만 허용하는 통로 역할을 하는 것이 NAT Gateway다.
- 그림 1 왼쪽 — NAT Gateway가 없으면 Private Subnet 내 EC2는 외부와 단절되어 업데이트조차 불가능하다.
- 그림 1 오른쪽 — NAT Gateway를 구성하면 보안은 유지하면서 내부 서버들이 아웃바운드 인터넷 통신을 할 수 있다. 실제 서비스 중인 EC2가
apt등으로 외부 라이브러리를 받아오려면 반드시 이 구조가 필요하다.
2. NAT Gateway 생성 및 설정 단계
실제 구축 과정을 통해 NAT Gateway가 어떻게 동작하는지 살펴본다.
2.1 인프라 구성 환경 (Pre-requisites)
먼저 테스트를 위해 그림 1과 같이 Public Subnet(Bastion EC2 위치)과 Private Subnet(테스트 EC2 위치)을 미리 구성했다.
2.2 NAT 게이트웨이 구성
Step 1. 사전 점검 — 인터넷 연결 확인
그림 2. NAT 설정 전 — EC2 인터넷 연결 오류
NAT 게이트웨이가 없는 상태에서 Private Subnet 내 EC2에 접속해 sudo apt update를 실행하면, 그림 2처럼 외부와 통신이 되지 않아 막혀 있는 것을 확인할 수 있다. 이제 그림 1 오른쪽 아키텍처를 목표로 구성을 시작한다.
참고: 설정 전, 탄력적 IP(Elastic IP, EIP)를 미리 생성해 두는 것이 좋다. 자동 할당 옵션도 있지만, 실무에서는 관리의 일관성을 위해 수동 할당을 권장한다.
Step 2. NAT 게이트웨이 생성
그림 3. AWS VPC 콘솔의 NAT 게이트웨이 메뉴
그림 4. NAT 게이트웨이 생성 버튼 (우측 상단)
AWS 콘솔에서 VPC → NAT 게이트웨이 메뉴로 이동한 뒤, 우측 상단의 [NAT 게이트웨이 생성] 버튼을 클릭한다.
Step 3. 생성 옵션 및 탄력적 IP(EIP) 연결
그림 5. NAT 게이트웨이 생성 옵션
그림 6. 탄력적 IP(EIP) 연결
생성 화면에서 다음 옵션을 선택한다(그림 5·6).
- VPC 선택 — NAT 게이트웨이를 생성할 대상 VPC를 지정한다.
- 연결 유형 — '퍼블릭'을 선택한다.
- 탄력적 IP 할당 — 그림 6처럼 수동으로 만들어 둔 EIP를 연결한다. 고정 공인 IP가 있어야 외부 통신 시 신뢰성을 확보할 수 있다.
그림 7. NAT 게이트웨이 생성 후 세부 정보
설정을 마치고 생성을 완료하면 그림 7처럼 nat-xxxx 형태의 ID와 함께 연결된 IP 주소를 확인할 수 있다.
Step 4. 라우팅 테이블(Route Table) 업데이트
그림 8. Private Subnet 라우팅 테이블 — NAT 게이트웨이 연결
그림 9. 라우팅 테이블 업데이트 결과
NAT Gateway를 만들었으니, 이제 Private Subnet의 트래픽이 이 통로를 타도록 길을 만들어 준다.
- 해당 VPC의 Private Subnet 라우팅 테이블로 이동한다.
- 라우팅 편집에서
0.0.0.0/0(모든 인터넷 트래픽)의 대상을 방금 생성한 NAT 게이트웨이(nat-xxxx)로 지정하고 저장한다(그림 8). - 저장 후 그림 9처럼 라우팅 정보가 활성화된 것을 확인한다.
Step 5. Private Subnet 인터넷 연결 최종 확인
그림 10. NAT 게이트웨이 연결 후 — apt update 성공
다시 Private Subnet 내 EC2로 돌아가 sudo apt update를 실행한다. 그림 10처럼 외부 리포지토리에 정상 접근하여 업데이트가 진행되는 것을 확인할 수 있다.
3. NAT Gateway 비용 분석 (서울 리전 기준)
NAT Gateway는 관리형 서비스로 높은 안정성을 제공하지만, 고정 비용이 발생하므로 설계 단계에서 고려가 필요하다.
| 항목 | 요금 단위 | 월 예상 비용 (데이터 전송 제외) |
|---|---|---|
| 시간당 고정 요금 | $0.045 / hour | 약 $32.4 (약 45,000원) |
| 데이터 처리 요금 | $0.045 / GB | 실제 사용량에 따라 별도 합산 |
NAT Gateway는 생성만 해두고 쓰지 않아도 시간당 약 60원(월 4.5만 원)의 고정비가 무조건 청구된다. 테스트 목적이라면 사용 직후 반드시 삭제하는 습관이 필요하다.
상세한 AWS 요금 체계는 별도 정리한 비용 절감 글을 참고하자.
4. 엔터프라이즈급 비용 최적화 전략
단순히 쓰는 법을 넘어, 아키텍처 관점에서 비용을 줄이는 포인트 3가지.
- VPC 엔드포인트(Endpoint) 활용 — S3·DynamoDB 같은 AWS 내부 서비스와 통신할 때 NAT Gateway를 거치면 데이터 처리 비용이 과다 발생한다. VPC Endpoint를 쓰면 데이터 처리 요금을 0원으로 만들 수 있다.
- 가용 영역(AZ) 설계 최적화 — AZ 간 데이터 전송은 추가 비용(Data Transfer Out)이 발생한다. 트래픽이 많은 서버와 NAT Gateway는 동일 AZ에 배치하는 것이 유리하다.
- NAT 인스턴스로 대체 — 트래픽이 적은 소규모·개인 프로젝트라면
t3.nano급 인스턴스로 NAT 인스턴스를 직접 구축해 고정비를 90% 이상 절감할 수 있다.
5. 요약: NAT Gateway vs NAT 인스턴스
| 비교 항목 | NAT Gateway | NAT Instance |
|---|---|---|
| 관리 주체 | AWS (Managed Service) | 사용자 직접 관리 |
| 가용성 | 매우 높음 (자동 확장) | 사용자 설계에 의존 |
| 비용 | 높음 (월 약 4.5만 원+) | 낮음 (EC2 사양에 따라 결정) |
| 추천 환경 | 대규모 서비스·기업 환경 | 소규모 스타트업·테스트 환경 |
비용을 아끼고 싶다면, 기존에 구축한 Bastion 서버를 활용해 NAT Instance로 구성하는 방법이 가장 효율적이다. 상세한 구축 과정은 아래 글에서 확인할 수 있다.
📦 이 글은 제가 운영하던 티스토리 블로그에서 옮겨온(migration) 글입니다. 원문: taehyuklee.tistory.com/34



댓글