VPC 퍼블릭 서브넷 프라이빗 서브넷 차이와 NAT 게이트웨이가 필요한 이유
VPC 퍼블릭 서브넷 프라이빗 서브넷 차이는 AWS 네트워크를 설계할 때 가장 먼저 이해해야 하는 개념입니다. 서버를 만들 때 서브넷을 선택하는 항목이 나오는데, 여기서 어떤 서브넷을 고르느냐에 따라 그 서버가 인터넷에서 직접 접근 가능한지 아닌지가 결정됩니다. 데이터베이스를 실수로 퍼블릭 서브넷에 두면 불필요하게 외부 공격에 노출될 수 있고, 반대로 웹 서버를 프라이빗 서브넷에 두면 사용자가 접속하지 못하는 문제가 생깁니다.
저도 예전에는 서브넷 이름에 public이나 private이라고 붙어 있으면 그것만으로 성격이 정해지는 줄 알았습니다. 그런데 직접 VPC를 만들어보니 서브넷 자체에는 공개나 비공개를 정하는 스위치가 없었고, 연결된 라우팅 테이블이 인터넷 게이트웨이로 향하느냐에 따라 달라진다는 것을 알게 되었습니다. 이 원리를 이해하고 나서야 네트워크 구성도가 제대로 읽히기 시작했습니다.
오늘 제가 준비한 포스팅에서는 VPC 퍼블릭 서브넷 프라이빗 서브넷 차이를 중심으로 VPC와 서브넷의 기본 구조, 두 서브넷을 구분하는 라우팅 원리, 프라이빗 서브넷의 서버가 인터넷을 사용하기 위해 NAT 게이트웨이가 필요한 이유, 그리고 비용을 줄이는 방법까지 차근차근 정리해보겠습니다.
결론부터 말씀드리면 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는 서브넷이 퍼블릭 서브넷이고, 그 경로가 없는 서브넷이 프라이빗 서브넷입니다. 프라이빗 서브넷의 서버가 업데이트 다운로드처럼 바깥으로 나가는 통신을 하려면 퍼블릭 서브넷에 있는 NAT 게이트웨이를 거쳐야 합니다.
VPC와 서브넷의 기본 구조부터 이해하기
VPC(Virtual Private Cloud)는 AWS 안에서 나만 사용하는 논리적으로 분리된 가상 네트워크입니다. VPC를 만들 때는 10.0.0.0/16 같은 CIDR 표기법으로 사용할 사설 IP 주소 범위를 정합니다. 이 범위 안에서 서버와 데이터베이스 같은 리소스에 IP 주소가 할당됩니다.
서브넷은 VPC의 IP 주소 범위를 더 작게 나눈 구역입니다. 예를 들어 10.0.1.0/24, 10.0.2.0/24처럼 나누어 용도별로 리소스를 배치합니다. 중요한 특징은 하나의 서브넷이 하나의 가용 영역에만 속한다는 점입니다. 그래서 여러 가용 영역에 서버를 분산하려면 가용 영역마다 서브넷을 따로 만들어야 합니다.
각 서브넷에서는 AWS가 네트워크 관리용으로 사용하는 IP 주소 5개가 예약되어 사용자에게 할당되지 않습니다. /24 서브넷이면 256개 가운데 251개를 사용할 수 있습니다. 서브넷을 너무 작게 만들면 나중에 IP가 부족해질 수 있으므로 여유 있게 설계하는 것이 좋습니다.
모든 리전에는 계정 생성 시 기본 VPC가 준비되어 있고, 기본 VPC의 서브넷은 퍼블릭 서브넷으로 구성되어 있습니다. 실습에서 서버를 만들면 바로 인터넷 접속이 되는 이유가 여기에 있습니다. 운영 서비스라면 기본 VPC 대신 용도에 맞게 직접 설계한 VPC를 사용하는 것이 권장됩니다.
서브넷은 VPC의 주소 범위를 나눈 구역이며 반드시 하나의 가용 영역에 속하므로, 멀티 AZ 구성을 하려면 가용 영역마다 서브넷을 따로 만들어야 합니다.
퍼블릭 서브넷과 프라이빗 서브넷을 나누는 기준은 라우팅입니다
서브넷에는 라우팅 테이블이 연결되어 있고, 라우팅 테이블은 목적지별로 트래픽을 어디로 보낼지 정합니다. 모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 경로가 기본으로 들어 있어 같은 VPC 안의 서브넷끼리는 서로 통신할 수 있습니다.
여기에 0.0.0.0/0, 즉 모든 외부 주소로 향하는 트래픽을 인터넷 게이트웨이(Internet Gateway)로 보내는 경로를 추가하면 그 서브넷은 퍼블릭 서브넷이 됩니다. 인터넷 게이트웨이는 VPC와 인터넷을 연결하는 출입구 역할을 합니다.
다만 퍼블릭 서브넷에 있다고 해서 서버가 자동으로 인터넷과 통신하는 것은 아닙니다. 서버에 퍼블릭 IPv4 주소나 탄력적 IP 주소가 할당되어 있어야 하고, 보안 그룹에서도 해당 트래픽이 허용되어야 합니다. 라우팅, 공인 IP, 보안 그룹 세 가지 조건이 모두 맞아야 외부 접속이 가능합니다.
프라이빗 서브넷은 라우팅 테이블에 인터넷 게이트웨이 경로가 없는 서브넷입니다. 서버에 공인 IP를 할당하더라도 인터넷에서 들어오는 경로 자체가 없기 때문에 외부에서 직접 접근할 수 없습니다. 데이터베이스나 내부 애플리케이션 서버처럼 외부에 노출될 필요가 없는 리소스를 두기에 적합합니다.
퍼블릭과 프라이빗 서브넷은 이름이 아니라 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지로 결정되며, 외부 접속에는 공인 IP와 보안 그룹 허용까지 함께 필요합니다.
프라이빗 서브넷에 NAT 게이트웨이가 필요한 이유
프라이빗 서브넷의 서버도 바깥으로 나가는 통신이 필요할 때가 많습니다. 운영체제 보안 업데이트를 내려받거나, 외부 결제 API를 호출하거나, 소프트웨어 패키지를 설치하는 경우입니다. 그런데 인터넷 게이트웨이 경로가 없으니 이런 통신도 할 수 없습니다.
이 문제를 해결하는 것이 NAT 게이트웨이(NAT Gateway)입니다. NAT 게이트웨이를 퍼블릭 서브넷에 만들고, 프라이빗 서브넷의 라우팅 테이블에서 0.0.0.0/0 트래픽을 NAT 게이트웨이로 보내도록 설정합니다. 그러면 프라이빗 서버의 요청이 NAT 게이트웨이의 공인 IP로 바뀌어 인터넷으로 나갔다가 응답이 돌아옵니다.
핵심은 방향입니다. NAT 게이트웨이는 내부에서 시작된 연결의 응답만 돌려보내고, 외부에서 먼저 시작된 연결은 받아들이지 않습니다. 그래서 프라이빗 서버는 인터넷에서 필요한 자료를 가져올 수 있지만 외부에서 직접 접속할 수는 없는 상태를 유지할 수 있습니다.
NAT 게이트웨이는 특정 가용 영역의 서브넷에 만들어지는 리소스입니다. 한 가용 영역에만 두고 모든 프라이빗 서브넷이 이를 공유하면, 그 가용 영역에 문제가 생겼을 때 다른 가용 영역의 서버도 인터넷 통신을 할 수 없게 됩니다. 운영 환경에서는 가용 영역마다 NAT 게이트웨이를 두는 구성이 권장됩니다.
NAT 게이트웨이는 프라이빗 서버가 밖으로 나가는 통신만 허용하고 외부에서 들어오는 연결은 막아주므로, 보안을 유지하면서 업데이트와 외부 API 호출을 가능하게 해줍니다.
퍼블릭 서브넷과 프라이빗 서브넷 구성 비교
두 서브넷과 NAT 게이트웨이의 역할을 정리하면 다음과 같습니다. 제가 만든 아래 표를 참고해보세요.
| 구분 | 라우팅 테이블 기본 경로(0.0.0.0/0) | 외부에서 직접 접속 | 주로 배치하는 리소스 |
|---|---|---|---|
| 퍼블릭 서브넷 | 인터넷 게이트웨이 | 가능 (공인 IP·보안 그룹 허용 시) | 로드 밸런서, NAT 게이트웨이, 배스천 호스트 |
| 프라이빗 서브넷 (NAT 사용) | NAT 게이트웨이 | 불가 (나가는 통신만 가능) | 애플리케이션 서버, 배치 서버 |
| 프라이빗 서브넷 (격리형) | 경로 없음 | 불가 (인터넷 통신 전혀 없음) | 데이터베이스, 민감 데이터 처리 서버 |
일반적인 웹 서비스 구조는 사용자의 요청을 퍼블릭 서브넷의 로드 밸런서가 받고, 실제 처리는 프라이빗 서브넷의 애플리케이션 서버가 하며, 데이터는 가장 안쪽의 격리된 프라이빗 서브넷에 있는 데이터베이스에 저장하는 3계층 형태입니다. 이렇게 하면 외부에 직접 노출되는 리소스를 최소화할 수 있습니다.
NAT 게이트웨이 비용과 줄이는 방법
NAT 게이트웨이는 편리하지만 비용이 적지 않은 리소스입니다. 만들어두기만 해도 시간당 요금이 발생하고, 여기에 NAT 게이트웨이를 통과하는 데이터 양에 따라 GB당 처리 요금이 추가됩니다. 실습 후 삭제하지 않고 방치하면 서버를 쓰지 않아도 매달 요금이 청구됩니다.
비용을 줄이는 대표적인 방법은 VPC 엔드포인트입니다. 프라이빗 서버가 S3나 DynamoDB에 접근하는 트래픽은 게이트웨이 엔드포인트를 만들면 NAT 게이트웨이를 거치지 않고 AWS 내부 경로로 전달됩니다. 게이트웨이 엔드포인트는 별도 요금이 없어 대용량 데이터를 S3와 주고받는 환경에서 절감 효과가 큽니다.
다른 AWS 서비스에 접근할 때는 인터페이스 엔드포인트를 사용할 수 있지만 이는 시간당 요금과 데이터 처리 요금이 발생하므로 트래픽 양을 비교해 결정해야 합니다. 개발 환경처럼 비용이 중요한 곳에서는 필요할 때만 NAT 게이트웨이를 만들고 작업 후 삭제하는 방식도 사용됩니다.
NAT 게이트웨이는 시간당 요금과 데이터 처리 요금이 함께 발생하므로 S3 트래픽은 무료 게이트웨이 엔드포인트로 우회하고, 실습용 NAT 게이트웨이는 사용 후 반드시 삭제해야 합니다.
VPC 퍼블릭 서브넷 프라이빗 서브넷 차이 총정리
퍼블릭 서브넷은 라우팅 테이블에 인터넷 게이트웨이 경로가 있는 서브넷이고, 프라이빗 서브넷은 그 경로가 없는 서브넷입니다. 프라이빗 서버가 밖으로 나가는 통신을 하려면 퍼블릭 서브넷에 둔 NAT 게이트웨이를 거쳐야 하며, NAT 게이트웨이는 외부에서 들어오는 연결은 막아줍니다. 로드 밸런서는 퍼블릭, 애플리케이션과 데이터베이스는 프라이빗에 두는 구조가 기본이며, NAT 비용은 VPC 엔드포인트로 줄일 수 있습니다.
질문 QnA
프라이빗 서브넷의 서버에는 어떻게 SSH로 접속하나요?
퍼블릭 서브넷에 배스천 호스트를 두고 경유하거나, AWS Systems Manager Session Manager를 사용하면 인바운드 포트를 열지 않고도 접속할 수 있습니다. 보안 측면에서는 Session Manager 방식이 많이 권장됩니다.
NAT 게이트웨이 대신 NAT 인스턴스를 사용해도 되나요?
EC2 인스턴스로 직접 NAT를 구성할 수도 있지만 가용성 확보와 패치, 확장을 직접 관리해야 합니다. 관리 부담을 줄이려면 관리형 NAT 게이트웨이가 일반적으로 권장됩니다.
기본 VPC를 삭제해도 괜찮나요?
삭제할 수는 있지만 일부 서비스 기본 동작이나 실습 과정에서 기본 VPC를 전제로 하는 경우가 있습니다. 사용하지 않더라도 보안 그룹 규칙을 점검하는 수준으로 관리하는 경우가 많습니다.
IPv6만 사용하는 서버도 NAT 게이트웨이가 필요한가요?
IPv6에서는 밖으로 나가는 통신만 허용하려면 이그레스 전용 인터넷 게이트웨이를 사용합니다. IPv4용 NAT 게이트웨이와는 별도의 리소스입니다.
VPC 네트워크는 처음에는 복잡해 보이지만 라우팅 테이블이 트래픽의 방향을 결정한다는 원리 하나만 잡으면 대부분의 구성도를 이해할 수 있습니다. 어떤 리소스를 외부에 보이고 어떤 리소스를 숨길지 결정하는 것이 클라우드 보안 설계의 출발점입니다.
지금 사용 중인 VPC 콘솔에서 서브넷 목록을 열고 각 서브넷에 연결된 라우팅 테이블을 확인해보세요. 데이터베이스가 인터넷 게이트웨이 경로가 있는 서브넷에 있지는 않은지, 사용하지 않는 NAT 게이트웨이가 요금을 발생시키고 있지는 않은지 함께 점검해보시길 권해드립니다.
※ 본 글은 2026년 9월 기준 Amazon VPC, NAT 게이트웨이, VPC 엔드포인트 공식 문서와 요금 페이지를 참고해 작성했으며, 기능과 요금 기준은 변경될 수 있으니 최신 내용은 AWS 공식 페이지에서 확인해 주세요.