퍼블릭/프라이빗 서브넷, NAT Gateway
1. VPC
Virtual Private Cloud
AWS 상에서 내가 원하는 네트워크 구조를 직접 설계하고, 격리된 공간에서 운영할 수 있도록 해주는 서비스
핵심 개념
- AWS 리전 내에서 내가 정의한 IP 대역(CIDR 블록)을 기준으로 구성
- 서브넷, 라우팅 테이블, 보안 그룹, 인터넷 게이트웨이, NAT 등 다양한 네트워크 구성 요소 포함
- 온프레미스와 연결(VPN/Direct Connect) 하거나, 다중 계정 연결(Transit Gateway) 도 가능
예시
VPC (10.0.0.0/16)
├── Subnet A (10.0.1.0/24)
└── Subnet B (10.0.2.0/24)2. 서브넷
VPC 안에서 IP 주소 범위를 작게 나누는 단위
왜 나눌까
- 서로 다른 용도의 리소스를 격리
- 퍼블릭/프라이빗 서브넷 구분을 통해 보안 계층 구성
- 고가용성(HA)을 위해 여러 AZ(가용영역)에 분산 가능
퍼블릭/프라이빗 구분 기준
- 퍼블릭 서브넷: 인터넷 게이트웨이(IGW)에 연결된 서브넷
- 프라이빗 서브넷: IGW와 연결되지 않음. 대신 NAT Gateway를 통해 외부와 통신
3. 퍼블릭 vs 프라이빗 서브넷 상세 비교
| 항목 | 퍼블릭 서브넷 | 프라이빗 서브넷 |
|---|---|---|
| 외부 인터넷 통신 | 가능 (IGW 연결) | 기본적으로 차단됨 |
| 대표 용도 | 웹 서버, Bastion Host | DB 서버, 백엔드 API 서버 |
| 라우팅 테이블 | 0.0.0.0/0 → IGW | 0.0.0.0/0 → NAT Gateway |
| 보안 성격 | 외부 노출 가능성 높음 | 내부망으로 보호 |
| 예시 서비스 | ALB, EC2 Web | RDS, Redis, EC2 백엔드 |
퍼블릭은 외부에서 접속 가능한 리소스가 위치
프라이빗은 외부에서는 접근 불가, 내부 서비스 전용
4. NAT Gateway
프라이빗 서브넷에 있는 리소스가 외부로 나가는 통로
왜 필요한가?
- 프라이빗 서브넷에 있는 EC2 인스턴스나 Lambda가 외부 API 호출, 소프트웨어 업데이트, S3 접근 등 인터넷 연결이 필요한 경우가 많음
- 보안을 위해 직접 인터넷 게이트웨이를 연결하지는 않음
- 이때 NAT Gateway를 경유해 외부로 나갈 수 있음
핵심 특징
| 항목 | 설명 |
|---|---|
| 통신 방향 | 내부 → 외부만 허용, 외부 → 내부는 차단 |
| 보안 효과 | 외부 접근은 막되, 내부 자원은 인터넷 이용 가능 |
| 과금 | 시간 + 데이터 처리량 기준 |
| 대안 | NAT 인스턴스 (하지만 관리 복잡도 높음) |
5. 실전 구조 예시: 3-Tier 아키텍처
📦 VPC (10.0.0.0/16)
├── 🌐 퍼블릭 서브넷 (10.0.1.0/24)
│ ├── EC2 웹 서버
│ └── 인터넷 게이트웨이 (IGW)
│
├── 🔒 프라이빗 서브넷 (10.0.2.0/24)
│ ├── EC2 백엔드 서버
│ └── NAT Gateway 연결
│
├── 🔐 프라이빗 서브넷 (10.0.3.0/24)
│ └── RDS DB 인스턴스- 웹 서버는 외부에서 접속 가능
- 백엔드 서버는 외부에서는 접속 불가하지만, 외부로 요청은 가능
- DB는 백엔드 서버에서만 접근 가능
📌 실제로는 AZ 분산(다중 가용영역) 구성 권장
6. AZ(가용영역) 분산 구성
"하나의 서버실이 문제가 생겨도, 서비스는 계속되어야 한다."
🔹 AZ
- Availability Zone (가용영역) 의 약자
- 하나의 AWS 리전(예: ap-northeast-2, 서울)에는 2개 이상의 독립된 AZ가 존재
- 각 AZ는 전력, 네트워크, 냉각, 재난에 독립적인 물리적 데이터 센터
AZ 간에는 저지연, 고속 네트워크로 연결되어 있음
🔹 왜 분산해야 할까?
| 단일 AZ 구성 시 | 다중 AZ 구성 시 |
|---|---|
| 장애 발생 시 서비스 전체 중단 가능 | 한 AZ가 다운되어도 다른 AZ에서 서비스 유지 가능 |
| 가용성이 낮음 | 고가용성(High Availability, HA) 확보 |
| 장애 대응이 수동적 | 자동 복구(Auto Recovery) 또는 멀티 AZ 전환 가능 |
🔹 적용 예시: 2-Tier 웹 시스템
VPC
├── Subnet-A (ap-northeast-2a)
│ ├── EC2 Web 서버
│ └── RDS DB (멀티 AZ)
│
├── Subnet-B (ap-northeast-2c)
│ ├── EC2 Web 서버 (Auto Scaling)
│ └── Standby RDS- EC2 Auto Scaling Group: 2개 AZ에 인스턴스 분산 배포
- RDS: 멀티 AZ 옵션 활성화 시 Active-Standby 구성
- ALB (Application Load Balancer)는 자동으로 다중 AZ 트래픽 분산
🔹 구성 전략
- 서브넷은 최소 2개 이상 (각기 다른 AZ에)
- Auto Scaling Group + ALB + 멀티 AZ RDS = 기본 고가용성 조합
- EC2, NAT Gateway, ALB 등 비용이 조금 더 들지만, 서비스 안정성 극대화
🔹 정리
"VPC 안에서 가용성 확보 = AZ 분산 설계가 기본이다"
- 단일 AZ → 비용은 적지만 리스크 큼
- 멀티 AZ → 구성은 복잡하지만 기업 서비스에서는 사실상 필수
7. 서브넷 간 통신과 라우팅 테이블의 실제 역할
🔹 라우팅 테이블(Route Table)이란?
VPC 내의 서브넷이 어디로 트래픽을 전달할지 결정하는 설정표
- 각 서브넷은 하나의 라우팅 테이블에 연결
- 라우팅 테이블은 여러 서브넷과 공유할 수 있음
- 트래픽 목적지(CIDR)와 대상(Target)을 명시
🔹 기본 구성 예시
퍼블릭 서브넷 라우팅 테이블:
Destination: 0.0.0.0/0 → Target: igw-abc123 # 인터넷 게이트웨이프라이빗 서브넷 라우팅 테이블:
Destination: 0.0.0.0/0 → Target: nat-xyz789 # NAT Gateway🔹 서브넷 간 통신
같은 VPC 내 서브넷끼리는 기본적으로 통신 가능
다만, 라우팅 테이블과 보안 그룹 설정이 맞아야 실질적 통신 가능
| 조건 | 통신 가능 여부 |
|---|---|
| 같은 VPC, 서로 다른 서브넷 | ✅ 가능 |
| 라우팅 테이블에 서로를 향한 경로 없음 | ❌ 불가 |
| 보안 그룹 인바운드 허용 없음 | ❌ 불가 |
🔹 인터넷 접근은 라우팅 설정이 핵심
| 목적 | 설정 방식 |
|---|---|
| 퍼블릭 서브넷에서 외부로 | 0.0.0.0/0 → IGW |
| 프라이빗 서브넷에서 외부로 | 0.0.0.0/0 → NAT Gateway |
| 내부 통신 (ex. Web → DB) | 별도 라우팅 필요 없음 (같은 VPC일 경우) |
🔹 다중 AZ 구성 시 라우팅 전략
- 퍼블릭 서브넷이 여러 AZ에 걸쳐 있다면, 각 서브넷은 같은 라우팅 테이블을 공유하거나 각각의 라우팅 테이블을 가질 수 있음
- NAT Gateway가 특정 AZ에만 있을 경우, 해당 AZ의 프라이빗 서브넷에만 연결되는지 확인 필요
[ 퍼블릭 서브넷 ] --IGW-->
EC2 Web
[ 프라이빗 서브넷 ] --NAT GW--> 인터넷
EC2 App
[ 프라이빗 서브넷 ] --- 내부 통신 --->
RDS DB정리하면…
- 서브넷은 라우팅 테이블을 통해 외부/내부 목적지를 향해 통신
- IGW와 NAT Gateway 설정 여부에 따라 인터넷 사용 가능성 달라짐
- 보안 그룹 + 라우팅 테이블 조합이 실제 통신 가능 여부를 결정
8. 보안 그룹 vs 네트워크 ACL
| 항목 | 보안 그룹 (SG) | 네트워크 ACL (NACL) |
|---|---|---|
| 작동 방식 | 상태 저장(Stateful) | 비상태 저장(Stateless) |
| 적용 범위 | 인스턴스 단위 | 서브넷 단위 |
| 기본 설정 | 모든 인바운드 차단 / 아웃바운드 허용 | 모든 트래픽 허용 |
| 보통 역할 | 방화벽 역할 | 추가 네트워크 필터링 용도 |
실무에서는 대부분 SG로 제어하고, NACL은 특별한 보안 요구 시 사용
9. 마무리
- 퍼블릭 서브넷: 외부와 통신이 필요한 자원 배치
- 프라이빗 서브넷: 보호되어야 할 리소스 (DB 등) 배치
- NAT Gateway: 프라이빗 자원의 아웃바운드 전용 통로
- VPC 구성은 보안과 확장성을 위한 네트워크 설계의 핵심
10. VPC Peering이란?
서로 다른 VPC 간의 네트워크 연결을 직접 구성하는 방식
마치 하나의 VPC처럼 통신할 수 있도록 만들어주는 기능
🔹 VPC Peering의 정의
- VPC Peering은 두 개의 VPC 사이에 1:1 네트워크 터널을 만드는 것
- 서로 다른 VPC 내의 리소스 간에 프라이빗 IP로 직접 통신 가능
- 같은 계정, 다른 계정, 다른 리전 간에도 연결 가능
🔹 왜 필요한가?
| 사용 상황 | 이유 |
|---|---|
| 마이크로서비스 간 분리된 VPC | 서비스 별 격리는 유지하면서도 통신은 필요 |
| 계정/환경 별 VPC 구성 (예: dev/prod) | 서로 리소스를 참조하거나 호출해야 함 |
| 조직 간 협업 (다른 계정) | 서비스 연동, 내부 API 호출 등 |
| 비용 절감 및 성능 향상 | NAT, Transit Gateway 없이 바로 연결 가능 |
💡 S3, RDS, EC2 등 모든 서비스에서 프라이빗 IP로 호출 가능
🔹 예시 구조
📦 VPC-A (10.0.0.0/16)
└── Subnet-A (10.0.1.0/24)
└── EC2-A
📦 VPC-B (192.168.0.0/16)
└── Subnet-B (192.168.1.0/24)
└── EC2-B
==> VPC Peering 연결 생성 후:
EC2-A → EC2-B (프라이빗 IP로 ping 가능)
🔹 설정 순서 요약
- Peering 연결 생성
VPC A → VPC B요청- 같은 계정/다른 계정 지정 가능
- Peering 연결 승인
- 상대 VPC 소유자가 수락해야 함
- 라우팅 테이블 수정
- 각 VPC의 라우팅 테이블에 상대 VPC CIDR 추가
- 보안 그룹 설정
- 통신 대상 포트를 보안 그룹에서 허용해야 정상 작동
🔹 라우팅 테이블 예시
VPC A 라우팅 테이블
Destination: 192.168.0.0/16 → Target: pcx-abc123
VPC B 라우팅 테이블
Destination: 10.0.0.0/16 → Target: pcx-abc123
pcx-abc123는 Peering Connection ID
🔹 주의 사항
| 제한/주의점 | 설명 |
|---|---|
| 양방향 설정 필수 | 라우팅, 보안 그룹 모두 서로 허용해야 통신 가능 |
| 중첩 CIDR 불가 | 두 VPC의 IP 범위가 겹치면 Peering 불가 |
| 전이(transitive) 불가 | A ↔ B, B ↔ C 연결되어 있어도 A → C 불가 |
| 인터넷 게이트웨이 공유 불가 | IGW는 각 VPC에서 별도로 설정해야 함 |
| 비용 | Peering 연결 자체는 무료, 트래픽에 따라 요금 발생 |
✅ 언제 VPC Peering을 쓰면 좋을까?
- 단순히 2~3개의 VPC만 연결할 때
- 고속 통신이 필요한 내부 서비스 간 연결
- VPN이나 Transit Gateway 대신 가볍게 연결하고 싶을 때
❌ 언제는 피하는 게 좋을까?
- VPC 간 연결이 10개 이상으로 늘어날 때 → Transit Gateway 권장
- 리소스 공유가 복잡한 경우 (ex. Lambda ↔ EC2 ↔ RDS)
- CIDR이 중복될 가능성이 있는 경우
💡 요약:
"VPC Peering은 서로 떨어진 가상 사설망을 하나처럼 연결하는 안전한 통로"
구성 수가 많아질수록 확장성의 한계가 생기므로, 구조 설계 단계에서 필요성과 규모를 먼저 판단
참고
- AWS 공식 VPC 설명
- AWS 서브넷 및 라우팅 튜토리얼
- NAT Gateway 공식 문서
- draw.io - AWS 아키텍처 그리기
- VPC Hands-on 실습 가이드 (AWS)
- AWS 리전과 가용영역 개념
- 멀티 AZ 배포 아키텍처 예시 (AWS Well-Architected)
- VPC Peering 공식 문서 (AWS)
- VPC Peering 설정 튜토리얼
- VPC Peering vs Transit Gateway 비교
하고 싶은 거 하면, 할 수 있게 되는 매직