VPC란 무엇인가
VPC(Virtual Private Cloud)는 AWS 안에서 논리적으로 격리된 가상 네트워크입니다. 물리 데이터센터에서 내부망과 외부망을 나누듯, AWS에서는 VPC 안에 IP 범위와 서브넷, 라우팅, 보안 정책을 설계합니다.
AWS 계정에는 리전별 기본 VPC가 제공됩니다. 기본 VPC는 빠른 테스트에는 편리하지만, 실제 서비스에서는 주소 체계와 보안 경계를 직접 설계한 커스텀 VPC를 사용하는 편이 관리하기 좋습니다.
CIDR 블록
VPC를 만들 때 10.0.0.0/16처럼 CIDR 표기법으로 IP 주소 범위를 정합니다. 뒤의 숫자가 작을수록 네트워크 범위가 커집니다.
10.0.0.0/16은 큰 아파트 단지처럼 약 65,536개의 IPv4 주소 범위를 담습니다. 이 큰 범위를 10.0.1.0/24, 10.0.2.0/24처럼 나누면 각 /24는 256개 주소를 가진 작은 동 하나가 됩니다.즉 VPC /16 = 큰 전체 부지, Subnet /24 = 그 안에 나눈 구역이라고 먼저 이해하면 됩니다. AWS IPv4 서브넷에서는 예약 주소 때문에 /24의 실제 사용 가능 주소는 251개입니다.
| CIDR | IP 범위 | 전체 주소 수 | 용도 예시 |
|---|---|---|---|
10.0.0.0/8 | 10.0.0.0 ~ 10.255.255.255 | 약 1,677만 | 대규모 사설 주소 체계 |
10.0.0.0/16 | 10.0.0.0 ~ 10.0.255.255 | 65,536 | 일반적인 VPC 설계 |
10.0.0.0/24 | 10.0.0.0 ~ 10.0.0.255 | 256 | 소규모 서브넷 |
IPv4 서브넷에서는 첫 4개 주소와 마지막 1개 주소를 AWS가 예약합니다. 따라서 /24 서브넷의 256개 주소 중 실제 리소스에 할당 가능한 주소는 251개입니다.
서브넷 — 퍼블릭과 프라이빗
서브넷은 VPC의 주소 공간을 더 작은 네트워크 단위로 나눈 것입니다. 하나의 서브넷은 반드시 하나의 가용 영역(AZ)에 속합니다.
멀티 AZ 구성
| 서브넷 | AZ-a | AZ-b |
|---|---|---|
| 퍼블릭 | 10.0.1.0/24 | 10.0.3.0/24 |
| 프라이빗 | 10.0.2.0/24 | 10.0.4.0/24 |
인터넷 게이트웨이 (IGW)
인터넷 게이트웨이(IGW)는 VPC와 인터넷 사이의 통신을 가능하게 하는 VPC 구성 요소입니다. 퍼블릭 서브넷은 라우팅 테이블에 IGW로 향하는 기본 경로를 둡니다.
IGW 연결 절차
0.0.0.0/0 → IGW 추가 → ④ EC2에 퍼블릭 IPv4 또는 EIP 할당
서브넷에 IGW 경로가 있어도 EC2가 퍼블릭 IPv4 주소를 갖지 않으면 인터넷에서 해당 EC2로 직접 접근할 수 없습니다.
라우팅 테이블
라우팅 테이블(Route Table)은 목적지 네트워크에 따라 패킷을 어디로 보낼지 정하는 규칙 목록입니다. 서브넷은 하나의 라우팅 테이블과 연결됩니다.
퍼블릭 서브넷 예시
| 목적지 | 대상 | 설명 |
|---|---|---|
10.0.0.0/16 | local | VPC 내부 통신 |
0.0.0.0/0 | igw-xxx | 그 외 IPv4 트래픽을 인터넷 게이트웨이로 |
프라이빗 서브넷 예시
| 목적지 | 대상 | 설명 |
|---|---|---|
10.0.0.0/16 | local | VPC 내부 통신 |
0.0.0.0/0 | nat-xxx | 외부 IPv4 통신을 NAT로 |
10.0.0.0/16과 0.0.0.0/0이 동시에 있으면 VPC 내부 주소에는 더 구체적인 local 경로가 적용됩니다.NAT 게이트웨이
프라이빗 서브넷의 EC2가 패치 다운로드나 외부 API 호출처럼 인터넷으로 아웃바운드 통신해야 할 때 NAT 게이트웨이를 사용할 수 있습니다. 일반적인 퍼블릭 NAT 게이트웨이는 퍼블릭 서브넷에 배치하고 EIP를 연결합니다.
시간과 처리 데이터에 따라 비용이 발생하므로 학습용으로 만들었다면 실습이 끝난 뒤 반드시 정리합니다. 정확한 금액은 리전과 현재 AWS 가격표를 기준으로 확인해야 합니다.
NAT 게이트웨이 vs NAT 인스턴스
| 항목 | NAT 게이트웨이 | NAT 인스턴스 |
|---|---|---|
| 관리 | AWS 관리형 | 사용자 직접 운영 |
| 확장·가용성 | 관리형 서비스 특성 활용 | 직접 설계 필요 |
| 운영 부담 | 낮음 | 패치·장애 대응 필요 |
| 권장 | 일반적인 프로덕션 구성 | 특수 요구나 직접 제어가 필요한 경우 |
보안 그룹 vs NACL
Stateful vs Stateless
허용된 요청에 대한 응답 트래픽은 상태를 추적해 반환 경로가 자동 허용됩니다.
인바운드와 아웃바운드를 각각 평가하므로 반환 트래픽 규칙도 별도로 고려해야 합니다.
보안 그룹 인바운드 예시
| 유형 | 프로토콜 | 포트 | 소스 | 설명 |
|---|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 | 공개 웹 트래픽 |
| HTTPS | TCP | 443 | 0.0.0.0/0 | 공개 HTTPS 트래픽 |
| SSH | TCP | 22 | 관리자 IP/32 | 관리자 접속만 허용 |
| MySQL/Aurora | TCP | 3306 | 앱 서버 SG | 앱 계층에서만 DB 접근 |
Bastion Host
Bastion Host는 퍼블릭 네트워크에 둔 경유 서버를 통해 프라이빗 EC2에 관리 접속하는 전통적인 패턴입니다.
SSH 인바운드는 관리자 IP처럼 최소 범위로 제한하고, 프라이빗 서버로 필요한 관리 통신만 허용합니다.
SSH가 필요하다면 Bastion의 보안 그룹을 소스로 참조해 불특정 인터넷 접근을 막습니다.
관리 포트를 인터넷에 노출하지 않고 IAM 기반으로 EC2 세션을 열 수 있어, 신규 환경에서는 Bastion Host 없이 운영하는 구성을 우선 검토할 수 있습니다.
VPC Peering
VPC Peering은 두 VPC를 AWS 네트워크를 통해 프라이빗하게 연결하는 기능입니다. 같은 계정뿐 아니라 다른 계정, 리전 간 연결도 지원합니다.
① 겹치는 CIDR을 사용할 수 없습니다.
② Peering은 전이(Transitive) 라우팅을 제공하지 않습니다.
③ 연결 후 양쪽 라우팅 테이블과 보안 정책을 각각 설정해야 합니다.
VPC가 많다면 Transit Gateway
VPC 수가 늘어나면 Peering 연결을 일대일로 관리하기 복잡해집니다. 이때 Transit Gateway를 중앙 허브처럼 사용하면 다수 VPC와 네트워크 연결을 한 곳에서 관리하기 쉬워집니다.
전형적인 3-Tier 아키텍처
외부 진입점, 애플리케이션, 데이터베이스 계층을 네트워크 경계로 나누면 인터넷 노출 범위를 최소화하면서 장애와 보안을 분리할 수 있습니다.
| 계층 | 서브넷 | 리소스 예시 | 인터넷 접근 |
|---|---|---|---|
| 웹 | 퍼블릭 | ALB | 외부 요청 수신 |
| 앱 | 프라이빗 | EC2 / 컨테이너 | 필요 시 NAT 아웃바운드 |
| DB | 프라이빗 | RDS | 인터넷 직접 노출 차단 |