Public Subnet과 Private Subnet 차이: Route Table, 보안, 비용 기준으로 정리

Public Subnet과 Private Subnet의 차이는 Subnet 자체의 속성이 아니라, Route Table에 Internet Gateway 경로가 있는지 여부로 결정됩니다.

핵심 요약

기준	Public Subnet	Private Subnet
인터넷 접근	직접 가능 (IGW 경로)	직접 불가 (NAT Gateway 필요)
외부 노출	Public IP로 인바운드 가능	외부에서 직접 접근 불가
비용	IGW 자체 무료	NAT Gateway 시간당 + 데이터 전송 비용
보안 수준	노출 면적이 넓음	노출 면적이 좁음
배치 대상	ALB, Bastion, NAT Gateway	애플리케이션 서버, DB, 내부 서비스

1. 비교 대상 개요

실무 상황

EC2 인스턴스를 하나 띄웠는데, 외부에서 SSH로 바로 접속이 됩니다. 보안팀에서 "왜 DB 서버가 인터넷에 노출되어 있냐"고 물어봅니다. 이 상황은 리소스를 Public Subnet에 배치했기 때문에 발생합니다.

Public Subnet과 Private Subnet을 구분하는 것은 AWS 네트워크 설계의 가장 기본적인 보안 결정입니다.

Public Subnet이란

Route Table에 0.0.0.0/0 → Internet Gateway 경로가 있는 Subnet입니다. 이 Subnet에 배치된 리소스는 Public IP를 할당받으면 인터넷과 양방향 통신이 가능합니다.

Private Subnet이란

Route Table에 Internet Gateway 경로가 없는 Subnet입니다. 외부에서 직접 접근할 수 없으며, 외부 인터넷 접근이 필요하면 NAT Gateway를 경유해야 합니다.

Tip
AWS 콘솔에서 Subnet을 생성할 때 "Public" 또는 "Private"을 선택하는 옵션은 없습니다. Route Table 연결에 따라 동작이 결정됩니다.

2. 핵심 차이 표

기준	Public Subnet	Private Subnet
Route Table 경로	0.0.0.0/0 → IGW	0.0.0.0/0 → NAT GW (또는 없음)
Public IP 할당	가능 (자동 할당 설정 가능)	일반적으로 불필요
인바운드 접근	인터넷에서 직접 가능	불가 (VPN, Bastion 등 경유 필요)
아웃바운드 접근	IGW를 통해 직접	NAT Gateway를 통해 간접
대표 리소스	ALB, NAT Gateway, Bastion Host	EC2 App Server, RDS, ElastiCache
보안 노출 면적	넓음	좁음

3. 구조 차이

aws-public-private-subnet-structure

Public Subnet의 트래픽 흐름

인터넷 → Internet Gateway → Public Subnet → 리소스 (Public IP 필요)
리소스 → Public Subnet → Internet Gateway → 인터넷

양방향 통신이 가능합니다. 외부에서 리소스의 Public IP로 직접 요청을 보낼 수 있고, 리소스도 인터넷으로 직접 나갈 수 있습니다.

Private Subnet의 트래픽 흐름

리소스 → Private Subnet → NAT Gateway (Public Subnet) → Internet Gateway → 인터넷
인터넷 → ✕ (직접 접근 불가)

아웃바운드만 가능합니다. 리소스가 외부 API를 호출하거나 패키지를 다운로드할 수 있지만, 외부에서 이 리소스로 직접 요청을 보낼 수는 없습니다.

Route Table 비교

Public Subnet Route Table:

Destination	Target	설명
10.0.0.0/16	local	VPC 내부 통신
0.0.0.0/0	igw-xxxxxxxx	인터넷 양방향

Private Subnet Route Table:

Destination	Target	설명
10.0.0.0/16	local	VPC 내부 통신
0.0.0.0/0	nat-xxxxxxxx	NAT Gateway 경유 아웃바운드

Security Note
Route Table에서 0.0.0.0/0 → IGW 경로를 제거하면 해당 Subnet은 즉시 Private Subnet으로 동작합니다. 반대로 이 경로를 추가하면 Public Subnet이 됩니다. 운영 중 실수로 경로를 변경하지 않도록 주의해야 합니다.

4. 비용 차이

aws-public-private-subnet-cost

Public Subnet 비용

항목	비용
Internet Gateway	자체 무료
Public IPv4 주소	$0.005/IP/시간 (2024.02~)
데이터 전송 (아웃바운드)	$0.09/GB (처음 10TB, 리전별 상이)

Private Subnet 비용

항목	비용
NAT Gateway 시간당	$0.045/시간 (서울 리전 기준)
NAT Gateway 데이터 처리	$0.045/GB
데이터 전송 (아웃바운드)	$0.09/GB (처음 10TB, 리전별 상이)

비용 시나리오 비교

시나리오: 월 100GB 아웃바운드 트래픽이 발생하는 서버 1대

구성	월 예상 비용
Public Subnet (IGW 직접)	Public IP $3.6 + 데이터 전송 $9.0 = 약 $12.6
Private Subnet (NAT GW 경유)	NAT GW $32.4 + 데이터 처리 $4.5 + 데이터 전송 $9.0 = 약 $45.9

주의
Private Subnet은 보안상 유리하지만 NAT Gateway 비용이 추가됩니다. 월 $32 이상의 고정 비용이 발생하므로, 개발/테스트 환경에서는 비용 대비 효과를 검토해야 합니다. Multi-AZ로 NAT Gateway를 배치하면 비용이 AZ 수만큼 증가합니다.

비용 절감 방법

• VPC Endpoint 활용: S3, DynamoDB 등 AWS 서비스 접근 시 NAT Gateway를 거치지 않도록 Gateway Endpoint를 설정하면 데이터 처리 비용을 줄일 수 있습니다.
• NAT Instance 대체: 트래픽이 적은 환경에서는 t3.nano NAT Instance로 대체할 수 있습니다. 다만 가용성과 관리 부담이 증가합니다.
• 개발 환경 분리: 개발/테스트 환경은 단일 AZ + 단일 NAT Gateway로 구성하여 비용을 줄일 수 있습니다.

5. 보안 차이

공격 표면(Attack Surface) 비교

관점	Public Subnet	Private Subnet
인터넷 노출	Public IP로 직접 노출	노출되지 않음
포트 스캔 위험	있음	없음
DDoS 직접 대상	될 수 있음	되기 어려움
접근 경로	인터넷 → 리소스	VPN/Bastion → 리소스

보안 설계 원칙

최소 노출 원칙: 외부 접근이 반드시 필요한 리소스만 Public Subnet에 배치합니다.

Public Subnet에 배치해야 하는 리소스: - Application Load Balancer (ALB) - NAT Gateway - Bastion Host (또는 Session Manager로 대체) - VPN Gateway

Private Subnet에 배치해야 하는 리소스: - 애플리케이션 서버 (EC2, ECS, EKS Worker Node) - 데이터베이스 (RDS, ElastiCache, DynamoDB) - 내부 마이크로서비스 - 배치 처리 서버

Security Note
Public Subnet에 리소스를 배치하더라도 Security Group으로 인바운드를 제한해야 합니다. 다만 Security Group은 "허용 규칙"만 설정할 수 있으므로, 실수로 0.0.0.0/0을 열면 즉시 노출됩니다. Private Subnet은 이런 실수가 있어도 Route Table 수준에서 외부 접근이 차단됩니다.

Defense in Depth 관점

Private Subnet은 다중 방어 계층을 제공합니다.

1. Route Table: Internet Gateway 경로 없음 → 외부 접근 원천 차단
2. NACL: Subnet 단위 인바운드/아웃바운드 규칙
3. Security Group: 인스턴스 단위 허용 규칙
4. OS 방화벽: 인스턴스 내부 추가 방어

Public Subnet은 1번 계층이 없으므로 2~4번에만 의존합니다.

6. 운영 복잡도 차이

관점	Public Subnet	Private Subnet
초기 설정	간단 (IGW + Route Table)	NAT Gateway 추가 설정 필요
SSH 접근	Public IP로 직접	Bastion 또는 Session Manager 필요
패키지 설치	직접 인터넷 접근	NAT Gateway 경유 또는 VPC Endpoint
모니터링	표준	NAT Gateway 상태 추가 모니터링
장애 포인트	적음	NAT Gateway 장애 시 외부 통신 불가

Private Subnet 운영 시 추가 고려사항

• NAT Gateway 가용성: 단일 AZ에 NAT Gateway를 두면 해당 AZ 장애 시 외부 통신이 불가합니다. 운영 환경에서는 AZ별 NAT Gateway를 배치하는 것이 일반적입니다.
• 접근 방법: SSH 접근을 위해 Bastion Host를 운영하거나, AWS Systems Manager Session Manager를 사용할 수 있습니다. Session Manager는 SSH 포트를 열지 않아도 되므로 보안상 유리합니다.
• 패키지 저장소 접근: yum, apt, pip 등 패키지 설치 시 NAT Gateway를 통해 외부에 접근합니다. 대량 다운로드 시 NAT Gateway 비용이 증가할 수 있습니다.

7. 선택 기준

이 리소스를 Public Subnet에 둘 것인가, Private Subnet에 둘 것인가?

다음 질문으로 판단할 수 있습니다.

1. 이 리소스에 외부 인터넷에서 직접 접근해야 하는가?
   → Yes: Public Subnet 후보
   → No: Private Subnet

2. 이 리소스가 인터넷으로 나가야 하는가?
   → Yes: Private Subnet + NAT Gateway
   → No: Private Subnet (NAT Gateway 불필요)

3. 이 리소스가 ALB 뒤에 있는가?
   → Yes: Private Subnet (ALB만 Public)
   → No: 직접 접근이 필요하면 Public Subnet

상황별 선택 가이드

상황	선택	이유
웹 서버 (ALB 뒤)	Private Subnet	ALB가 트래픽을 중계하므로 직접 노출 불필요
웹 서버 (ALB 없이 직접 서빙)	Public Subnet	외부에서 직접 접근 필요
RDS 데이터베이스	Private Subnet	외부 접근 불필요, 보안 최우선
Bastion Host	Public Subnet	SSH 접근 진입점
배치 서버 (외부 API 호출)	Private Subnet + NAT GW	아웃바운드만 필요
개발용 EC2 (비용 절감)	Public Subnet 가능	NAT GW 비용 절감, 다만 Security Group 관리 필수

8. 실무 예시

사례 1: 스타트업 웹 서비스 (3-Tier)

팀원 5명, 월 트래픽 10만 PV 수준의 웹 서비스를 운영한다고 가정합니다.

VPC (10.0.0.0/16)
├── Public Subnet (10.0.1.0/24, 10.0.2.0/24)
│   ├── ALB (외부 트래픽 수신)
│   └── NAT Gateway (Private Subnet 아웃바운드용)
├── Private Subnet (10.0.11.0/24, 10.0.12.0/24)
│   └── ECS Fargate (애플리케이션)
└── DB Subnet (10.0.21.0/24, 10.0.22.0/24)
    └── RDS PostgreSQL (Multi-AZ)

설계 이유: - ALB만 Public Subnet에 배치하여 외부 노출을 최소화합니다. - 애플리케이션은 Private Subnet에서 ALB를 통해서만 접근 가능합니다. - RDS는 별도 DB Subnet에 격리하여 애플리케이션 서버에서만 접근 가능하도록 Security Group을 설정합니다. - NAT Gateway는 ECS 태스크가 외부 API(결제, 알림 등)를 호출할 때 사용합니다.

사례 2: 개발 환경 (비용 최적화)

개발 환경에서는 보안보다 비용 효율이 우선될 수 있습니다.

VPC (10.1.0.0/16)
├── Public Subnet (10.1.1.0/24)
│   ├── EC2 (개발 서버, Public IP)
│   └── RDS (개발용, Public Accessible)

trade-off: - NAT Gateway 비용 월 $32+를 절감할 수 있습니다. - 다만 Security Group을 엄격하게 관리해야 합니다 (개발자 IP만 허용). - 운영 환경과 구조가 달라 환경 간 차이로 인한 문제가 발생할 수 있습니다. - 개발 DB에 실제 데이터가 있다면 이 구조는 적합하지 않습니다.

사례 3: 규제 환경 (금융, 의료)

규제 요건이 있는 환경에서는 모든 리소스를 Private Subnet에 배치하고, 접근 경로를 엄격히 통제합니다.

VPC (10.2.0.0/16)
├── Public Subnet (10.2.1.0/24)
│   └── ALB (WAF 연동)
├── Private Subnet (10.2.11.0/24)
│   └── EKS Worker Node
├── DB Subnet (10.2.21.0/24)
│   └── RDS (암호화 활성화)
└── Management Subnet (10.2.31.0/24)
    └── VPN 연결 (온프레미스 → 관리 접근)

설계 이유: - Bastion Host 대신 VPN + Session Manager를 사용하여 SSH 포트를 완전히 제거합니다. - ALB에 AWS WAF를 연동하여 웹 공격을 필터링합니다. - VPC Flow Logs를 활성화하여 모든 네트워크 트래픽을 감사합니다. - NAT Gateway 비용보다 보안 사고 비용이 훨씬 크므로 비용 trade-off가 명확합니다.

9. 자주 하는 실수

실수 1: 모든 리소스를 Public Subnet에 배치

"설정이 간단하니까" 또는 "NAT Gateway 비용이 아까우니까"라는 이유로 DB, 애플리케이션 서버를 모두 Public Subnet에 두는 경우가 있습니다. Security Group 하나의 실수로 전체 서비스가 노출될 수 있습니다.

실수 2: Public Subnet에 Auto-assign Public IP를 켜놓고 잊는 것

Subnet 설정에서 "Auto-assign public IPv4 address"를 활성화하면, 해당 Subnet에 생성되는 모든 인스턴스에 자동으로 Public IP가 할당됩니다. Private Subnet으로 사용할 Subnet에 이 설정이 켜져 있으면 의도치 않게 리소스가 노출될 수 있습니다.

실수 3: NAT Gateway를 단일 AZ에만 배치

운영 환경에서 NAT Gateway를 하나의 AZ에만 두면, 해당 AZ 장애 시 다른 AZ의 Private Subnet 리소스도 외부 통신이 불가능해집니다.

실수 4: Main Route Table에 IGW 경로 추가

Main Route Table에 Internet Gateway 경로를 넣으면, 명시적으로 Route Table을 연결하지 않은 모든 새 Subnet이 자동으로 Public Subnet이 됩니다.

실수 5: Private Subnet인데 NAT Gateway 없이 운영

Private Subnet의 리소스가 외부 패키지 저장소나 API에 접근해야 하는데 NAT Gateway가 없으면, 패키지 설치 실패나 API 호출 타임아웃이 발생합니다. 이 경우 CloudWatch Logs나 S3로의 로그 전송도 실패할 수 있습니다.

10. 정리

• Public Subnet과 Private Subnet의 차이는 Route Table에 Internet Gateway 경로가 있는지 여부로 결정됩니다.
• 보안 관점에서는 외부 접근이 필요한 최소한의 리소스만 Public Subnet에 배치하고, 나머지는 Private Subnet에 두는 것이 기본 원칙입니다.
• 비용 관점에서는 Private Subnet이 NAT Gateway 비용을 추가로 발생시키므로, 환경과 요구사항에 따라 trade-off를 판단해야 합니다.
• 운영 환경에서는 보안이 우선이므로 Private Subnet + NAT Gateway 구성이 일반적입니다. 개발 환경에서는 비용 절감을 위해 Public Subnet을 활용할 수 있지만, Security Group 관리가 필수입니다.

관련 글

• AWS VPC란 무엇인가: Subnet, Route Table, Internet Gateway 개념 정리

참고 문서

• AWS 공식 문서: VPC 및 서브넷
• AWS 공식 문서: 인터넷 게이트웨이
• AWS 공식 문서: NAT 게이트웨이
• AWS 공식 문서: 라우팅 테이블