[AWS] VPC란 (Virtual Private Cloud)

VPC란? (Virtual Private Cloud)

이번 포스팅에서는 VPC가 무엇인지 개념부터 차근차근 짚고, 구성 요소들을 하나씩 정리해보겠습니다.

---

VPC가 나오기 전에는 어땠을까?

VPC 이전 AWS 초기에는 EC2-Classic 이라는 방식으로 운영됐습니다. 모든 사용자의 인스턴스가 하나의 거대한 공유 네트워크 위에 뒤섞여 있었고, 인스턴스를 추가할 때마다 기존 인스턴스 설정을 모두 수정해야 했습니다.

 

네트워크 구조가 복잡해질수록 관리가 어려워지고, 다른 사용자의 인스턴스와 동일한 네트워크를 공유하다 보니 보안적으로도 문제가 생길 수 있었습니다.

한줄 비유: 담장도 없이 건물들이 마구잡이로 세워진 공터 같은 상태였다고 보시면 됩니다.

 

2011년 AWS에서 VPC를 출시하면서 이 문제가 해결됐습니다. 이후 EC2-Classic은 사용이 중단되고, 현재는 VPC 사용이 사실상 의무화되어 있습니다.

---

VPC란?

VPC(Virtual Private Cloud) 는 AWS 클라우드 내에서 사용자가 직접 정의하는 논리적으로 격리된 가상 네트워크입니다.

 

사용자는 VPC 안에서 IP 주소 범위, 서브넷, 라우팅 테이블, 게이트웨이 등을 직접 설정해서 원하는 네트워크 환경을 자유롭게 구성할 수 있습니다. 물리적 인프라는 AWS와 공유하지만, 네트워크 수준에서는 완전히 독립된 나만의 공간입니다.

 

AWS에서는 계정을 생성하면 리전별로 기본 VPC(Default VPC)가 자동으로 만들어집니다. 별도로 커스텀 VPC를 생성해서 사용하는 것도 가능합니다.

한줄 비유: 담장으로 둘러싸인 나만의 아파트 단지를 AWS 도시 안에 짓는 것입니다.

---

VPC의 핵심 특징

VPC를 만들고 사용할 때 반드시 알아야 할 규칙들입니다.

리전 단위로 존재

VPC는 하나의 리전(Region) 에 종속됩니다. 서울 리전에 만든 VPC는 서울 리전 안에서만 동작하고, 다른 리전에 걸쳐 확장할 수 없습니다.

단, VPC 안에 있는 서브넷은 해당 리전의 여러 가용 영역(AZ) 에 걸쳐 배포할 수 있습니다.

사설 IP 대역 사용 (RFC 1918)

VPC는 인터넷에서 직접 라우팅되지 않는 사설 IP 대역으로 설계합니다. IETF의 RFC 1918 표준에서 정의한 세 가지 사설 대역 중 하나를 선택합니다.

사설 IP 대역	범위	호스트 수
10.0.0.0/8	10.0.0.0 ~ 10.255.255.255	약 1,677만 개
172.16.0.0/12	172.16.0.0 ~ 172.31.255.255	약 104만 개
192.168.0.0/16	192.168.0.0 ~ 192.168.255.255	약 6만 5천 개

CIDR 범위 제한

AWS는 /16 ~ /28 범위의 서브넷 마스크만 허용합니다.

CIDR	사용 가능한 IP 수
/16	최대 65,536개 (가장 큰 VPC)
/24	최대 256개 (일반적으로 자주 사용)
/28	최대 16개 (가장 작은 VPC)

실제로는 AWS가 각 서브넷에서 5개의 IP를 내부 용도로 예약해두기 때문에, 사용 가능한 IP는 명시된 수보다 5개 적습니다.

한번 설정한 IP 대역은 수정 불가

VPC 생성 후에는 CIDR 범위를 변경할 수 없습니다. 처음 설계할 때 충분한 IP 공간을 확보해두는 게 중요합니다. 나중에 공간이 부족해지면 새 VPC를 만들어야 하는 번거로움이 생깁니다.

각 VPC는 독립적

기본적으로 VPC끼리는 서로 통신이 불가능합니다. 같은 AWS 계정 내의 VPC라도 마찬가지입니다. VPC 간 통신이 필요하면 VPC 피어링이나 Transit Gateway를 별도로 설정해야 합니다.

---

VPC 구성 요소

VPC는 단순히 네트워크 공간 하나를 만드는 게 아니라, 여러 구성 요소를 조합해서 완성되는 인프라입니다.

---

서브넷 (Subnet)

개념

서브넷(Subnet)은 VPC의 IP 주소 범위를 더 작은 단위로 나눈 것입니다. VPC가 네트워크 전체를 정의한다면, 서브넷은 그 안에서 실제로 리소스가 배치되는 구체적인 IP 주소 블록입니다.

 

EC2, RDS 같은 AWS 리소스들은 VPC가 아니라 서브넷 안에 배치됩니다. 각 서브넷은 반드시 하나의 가용 영역(AZ) 에 속하며, 하나의 AZ에는 여러 서브넷이 존재할 수 있습니다.

 

서브넷을 여러 개로 나누는 이유는 보안 레이어를 구분하기 위해서입니다. 외부에서 접근 가능한 리소스와 내부에서만 사용하는 리소스를 같은 네트워크에 두면 보안 정책을 세밀하게 적용하기 어렵습니다.

퍼블릭 서브넷 vs 프라이빗 서브넷

인터넷 연결 여부에 따라 두 가지로 구분됩니다.

 

퍼블릭 서브넷 (Public Subnet)

라우팅 테이블에 0.0.0.0/0 → 인터넷 게이트웨이 경로가 설정되어 있는 서브넷입니다. 인터넷과 직접 통신이 가능하기 때문에 외부에서 접근이 필요한 리소스를 배치합니다.

• 배치하는 리소스: 웹 서버, 로드 밸런서, NAT 게이트웨이, Bastion Host

프라이빗 서브넷 (Private Subnet)

인터넷 게이트웨이로 향하는 경로가 없는 서브넷입니다. 외부에서 직접 접근이 불가능하고, 외부로 나가는 트래픽도 NAT 게이트웨이를 통해서만 가능합니다.

• 배치하는 리소스: DB 서버, 내부 앱 서버, 캐시 서버

한줄 비유: 퍼블릭 서브넷은 외부인도 이용할 수 있는 단지 내 상가, 프라이빗 서브넷은 거주민만 출입하는 주거동입니다.

---

라우팅 테이블 (Routing Table)

개념

라우팅 테이블은 서브넷에서 발생하는 네트워크 트래픽의 경로를 정의하는 규칙 집합입니다.

 

네트워크 패킷이 목적지로 향할 때, 라우팅 테이블을 조회해서 "이 목적지 주소는 어디로 보내야 하는가"를 결정합니다. 서브넷마다 라우팅 테이블이 하나씩 연결되며, 여러 서브넷이 동일한 라우팅 테이블을 공유할 수도 있습니다.

 

라우팅 테이블의 각 항목은 목적지(Destination) 와 대상(Target) 으로 구성됩니다.

퍼블릭 서브넷 라우팅 테이블 예시

목적지 (Destination)	대상 (Target)	설명
10.0.0.0/16	local	VPC 내부 통신은 로컬에서 처리
0.0.0.0/0	igw-xxxxxxxx	그 외 모든 트래픽은 인터넷 게이트웨이로

프라이빗 서브넷 라우팅 테이블 예시

목적지 (Destination)	대상 (Target)	설명
10.0.0.0/16	local	VPC 내부 통신은 로컬에서 처리
0.0.0.0/0	nat-xxxxxxxx	그 외 모든 트래픽은 NAT 게이트웨이로

라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있느냐 없느냐가 퍼블릭/프라이빗 서브넷을 구분하는 기준입니다.

한줄 비유: 단지 곳곳에 설치된 안내판. "저쪽 목적지는 이 경로로 가세요"를 알려주는 이정표입니다.

---

인터넷 게이트웨이 (Internet Gateway, IGW)

개념

인터넷 게이트웨이(IGW)는 VPC와 인터넷을 연결해주는 AWS에서 관리하는 게이트웨이입니다.

 

퍼블릭 서브넷의 리소스가 인터넷과 통신하려면 라우팅 테이블에 IGW를 대상으로 하는 경로가 있어야 하고, 해당 EC2에 공인 IP(퍼블릭 IP 또는 탄력적 IP)가 할당되어 있어야 합니다.

 

IGW는 양방향 통신을 지원합니다. 퍼블릭 서브넷의 EC2가 외부로 나가는 것(아웃바운드)도, 외부에서 해당 EC2에 접근하는 것(인바운드)도 모두 가능합니다.

 

주요 특징:

• VPC당 1개만 연결 가능
• AWS가 직접 관리하는 고가용성 서비스 — 별도로 이중화 구성 불필요
• 수평 확장을 지원하기 때문에 대역폭에 제한이 없음
• IGW 자체 비용 없음 (외부로 나가는 데이터 전송 비용은 별도 청구)

한줄 비유: 단지와 외부 도로를 연결하는 정문. 단지마다 정문은 하나뿐입니다.

---

NAT 게이트웨이 (NAT Gateway)

개념

NAT 게이트웨이는 프라이빗 서브넷의 리소스가 인터넷과 아웃바운드 통신을 할 수 있도록 해주는 AWS 관리형 서비스입니다.

 

프라이빗 서브넷의 EC2는 보안상 외부에서의 직접 접근을 차단하고 있지만, 소프트웨어 업데이트나 외부 API 호출처럼 인터넷으로 나가야 하는 상황이 종종 생깁니다. 이때 NAT 게이트웨이가 프라이빗 서브넷 EC2의 사설 IP를 NAT 게이트웨이 자신의 공인 IP(EIP)로 변환해서 인터넷에 요청을 보내고, 응답을 받아 다시 해당 EC2에 전달해주는 역할을 합니다.

프라이빗 EC2 (사설 IP) → NAT GW (공인 IP로 변환) → IGW → 인터넷
                              ← 응답 ←
(외부에서 NAT GW를 통해 프라이빗 EC2로 먼저 연결 시도하는 것은 불가)

NAT 게이트웨이는 아웃바운드 전용입니다. 외부에서 NAT 게이트웨이를 통해 프라이빗 서브넷으로 먼저 접속하는 인바운드 트래픽은 허용하지 않습니다.

 

주요 특징:

• 반드시 퍼블릭 서브넷에 생성해야 함
• 탄력적 IP(EIP) 를 할당해야 함
• AWS 관리형 서비스로 고가용성 자동 보장
• 시간당 요금 발생 (서울 리전 기준 약 $0.059/h + 데이터 처리 요금)

한줄 비유: 호수(프라이빗 EC2)에 설치된 공유기. 집에서 밖으로 나가는 건 되지만, 외부에서 공유기 뒤 기기로 직접 연결하는 건 안 됩니다.

NAT 관련 자세한 내용은 이전 포스팅 [NAT란?], [NAT Gateway vs NAT Instance]를 참고해주세요!

---

보안 그룹 (Security Group)

개념

보안 그룹은 EC2 인스턴스에 직접 적용되는 가상 방화벽입니다. 인스턴스로 들어오는 인바운드 트래픽과 나가는 아웃바운드 트래픽을 제어하는 규칙을 정의합니다.

 

보안 그룹의 가장 중요한 동작 방식은 Stateful(상태 저장) 입니다. 인바운드 요청을 허용하면, 그 요청에 대한 응답 아웃바운드는 아웃바운드 규칙과 상관없이 자동으로 허용됩니다. 연결 상태를 추적하기 때문입니다.

 

규칙 설정 시에는 허용할 프로토콜, 포트 범위, 출발지(인바운드) 또는 목적지(아웃바운드) IP 대역을 지정합니다.

 

주요 특징:

• 인스턴스 단위 적용 — 동일 서브넷 내에서도 인스턴스마다 다르게 설정 가능
• Stateful — 인바운드 허용 시 응답 아웃바운드 자동 허용
• 허용 규칙만 설정 가능 — 명시적 거부 규칙은 없으며, 허용하지 않은 트래픽은 모두 차단
• 기본값: 모든 인바운드 차단, 모든 아웃바운드 허용
• 하나의 인스턴스에 여러 보안 그룹 적용 가능

보안 그룹 설정 예시:

[웹 서버 보안 그룹]
인바운드:
  TCP 80  (HTTP)   0.0.0.0/0     허용 ← 누구나 웹 접속 가능
  TCP 443 (HTTPS)  0.0.0.0/0     허용 ← 누구나 HTTPS 접속 가능
  TCP 22  (SSH)    10.0.1.5/32   허용 ← Bastion Host IP만 SSH 허용

아웃바운드:
  전체              0.0.0.0/0     허용 (기본값)

한줄 비유: 각 호수의 현관 도어락. 허용된 사람만 들어올 수 있고, 한번 들어온 손님은 나갈 때 자동으로 문이 열립니다 (Stateful).

---

네트워크 ACL (Network ACL, NACL)

개념

네트워크 ACL은 서브넷 수준에서 동작하는 방화벽입니다. 서브넷으로 들어오거나 나가는 트래픽을 제어하며, 해당 서브넷에 속한 모든 인스턴스에 일괄 적용됩니다.

 

보안 그룹과의 가장 큰 차이는 Stateless(상태 미저장) 동작 방식입니다. 인바운드를 허용해도 그 응답에 대한 아웃바운드는 별도로 허용 규칙을 설정해야 합니다. 연결 상태를 추적하지 않기 때문입니다.

 

또한 NACL은 허용 규칙과 거부 규칙을 모두 설정할 수 있습니다. 규칙에는 번호가 있으며 낮은 번호부터 순서대로 평가해서 첫 번째로 매칭되는 규칙을 적용하고 나머지는 평가하지 않습니다.

 

주요 특징:

• 서브넷 단위 적용 — 서브넷 내 모든 인스턴스에 일괄 적용
• Stateless — 인바운드와 아웃바운드를 각각 별도 설정 필요
• 허용 + 거부 규칙 모두 설정 가능
• 규칙 번호 순서대로 평가 (낮은 번호 우선)
• 기본값: 모든 트래픽 허용

NACL 설정 예시:

[프라이빗 서브넷 NACL]
인바운드:
  규칙 100: TCP 8080  10.0.1.0/24  허용 ← 퍼블릭 서브넷에서 앱 서버 접근
  규칙 200: TCP 22    10.0.1.5/32  허용 ← Bastion Host에서 SSH
  규칙 *  : 전체      0.0.0.0/0   거부 ← 나머지 전부 차단

아웃바운드:
  규칙 100: TCP 1024-65535  0.0.0.0/0  허용 ← 임시 포트 응답 허용
  규칙 *  : 전체            0.0.0.0/0  거부

한줄 비유: 단지 출입구의 차량 게이트. 들어올 때와 나갈 때를 각각 따로 확인하고 (Stateless), 특정 차량은 아예 출입 금지시킬 수도 있습니다 (거부 규칙).

보안 그룹 vs 네트워크 ACL — 핵심 비교

이 둘은 서로 다른 레이어에서 동작하는 상호 보완적인 방화벽입니다.

항목	보안 그룹	네트워크 ACL
적용 레벨	인스턴스	서브넷
동작 방식	Stateful (연결 추적)	Stateless (연결 추적 없음)
기본 정책	인바운드 차단 / 아웃바운드 허용	모든 트래픽 허용
규칙 유형	허용만	허용 + 거부
규칙 평가	모든 규칙 종합 평가	번호 순서대로 평가, 첫 매칭 적용
우선순위 충돌	보안 그룹이 더 높은 우선순위	-

트래픽이 인스턴스에 도달하는 경로는 이렇습니다.

[외부 트래픽]
    ↓
[네트워크 ACL 인바운드 규칙 검사] ← 서브넷 레벨 1차 방어
    ↓ (허용 시)
[보안 그룹 인바운드 규칙 검사] ← 인스턴스 레벨 2차 방어
    ↓ (허용 시)
[EC2 인스턴스]

---

Bastion Host — 프라이빗 서버 접근을 위한 중간 서버

개념

Bastion Host(배스천 호스트) 는 외부에서 프라이빗 서브넷의 인스턴스에 안전하게 접근하기 위한 중간 점프 서버입니다.

프라이빗 서브넷의 EC2는 외부에서 직접 SSH 접속이 불가능하기 때문에, 퍼블릭 서브넷에 Bastion Host를 두고 이 서버를 경유해서 접속하는 방식을 사용합니다.

[개발자 로컬 PC]
    ↓ SSH (키 페어)
[Bastion Host] — 퍼블릭 서브넷, 공인 IP 보유
    ↓ SSH
[프라이빗 서브넷 EC2]

Bastion Host의 보안 그룹은 SSH(22번 포트)를 관리자 IP에서만 허용하도록 설정하는 것이 중요합니다. Bastion Host가 뚫리면 내부 전체가 위험에 노출될 수 있는 단일 장애 지점(SPOF)이 되기 때문입니다.

한줄 비유: 주거동에 방문하려는 외부인이 반드시 들러야 하는 단지 경비실입니다.

Bastion Host와 AWS Session Manager 비교는 [Bastion Host vs AWS Session Manager]을 참고해주세요!

---

VPC 피어링 (VPC Peering)

개념

VPC 피어링은 두 VPC 간에 프라이빗 네트워크 통신이 가능하도록 연결하는 기능입니다.

 

피어링이 설정된 두 VPC 간의 트래픽은 인터넷을 경유하지 않고 AWS 내부 네트워크를 통해 전달됩니다. 같은 리전, 다른 리전, 다른 AWS 계정의 VPC 간에도 피어링을 구성할 수 있습니다.

 

피어링 연결 후에는 양쪽 VPC의 라우팅 테이블에 상대방 VPC의 CIDR 대역을 대상으로 하는 경로를 추가해야 합니다.

 

주의사항:

• CIDR 대역이 겹치면 피어링 불가 — IP 충돌이 발생하기 때문
• 전이적 피어링(Transitive Peering) 불가 — A↔B, B↔C 피어링이 있어도 A에서 C로는 통신 불가. A↔C를 따로 설정해야 함

A (10.0.0.0/16) ←피어링→ B (10.1.0.0/16) ←피어링→ C (10.2.0.0/16)
    ↑                                                       ↑
    └────────── A↔C 통신이 필요하면 직접 피어링 필요 ─────────┘

VPC 수가 많아지면 피어링 연결이 N(N-1)/2 개로 폭발적으로 증가합니다. 이런 경우에는 *AWS Transit Gateway**를 허브로 사용해서 모든 VPC를 연결하는 방식이 더 효율적입니다.

한줄 비유: 두 단지 담장 사이에 전용 통로를 개설하는 것. 단, A-B-C가 연결돼도 A와 C 사이에는 직접 통로를 따로 뚫어야 합니다.

---

VPC Flow Logs

개념

VPC Flow Logs는 VPC의 네트워크 인터페이스를 오가는 IP 트래픽 정보를 캡처해서 기록하는 기능입니다.

 

각 트래픽 흐름에 대해 출발지/목적지 IP, 포트, 프로토콜, 전송된 패킷/바이트 수, 허용/거부 여부 등을 로그로 남깁니다. VPC 전체, 특정 서브넷, 특정 네트워크 인터페이스 단위로 활성화할 수 있습니다.

 

수집된 로그는 Amazon CloudWatch Logs 또는 Amazon S3에 저장합니다.

 

활용 예시:

• 비정상적인 트래픽 패턴 탐지 및 보안 감사
• 보안 그룹/NACL 규칙이 의도대로 동작하는지 검증
• 컴플라이언스 규정 준수를 위한 접근 이력 보관
• 네트워크 장애 원인 분석

한줄 비유: 단지 곳곳에 설치된 CCTV의 녹화 기록. 누가 언제 어디서 들어오고 나갔는지, 출입이 허용됐는지 거부됐는지 모두 남습니다.

---

VPC의 장점

보안

VPC는 다른 AWS 사용자와 논리적으로 완전히 격리된 네트워크를 제공합니다. 보안 그룹과 NACL을 통한 세밀한 트래픽 제어, 프라이빗 서브넷을 통한 리소스 차단으로 다층적 보안을 구현할 수 있습니다.

 

유연성

서브넷 설계, IP 대역 할당, 라우팅 설정 등을 직접 제어할 수 있어 단순한 웹 서버부터 복잡한 멀티 티어 아키텍처까지 원하는 구조를 자유롭게 구성할 수 있습니다.

 

고가용성

여러 가용 영역(AZ)에 서브넷을 배포하고 로드 밸런서와 조합하면, 특정 AZ에 장애가 발생해도 서비스를 무중단으로 유지할 수 있습니다.

 

비용 효율

VPC 핵심 구성 요소 대부분은 추가 비용 없이 사용할 수 있습니다. 물리적 인프라 구축 비용 없이 필요한 만큼만 네트워크를 설계하고 사용합니다.

---

전체 구성 요소 정리

구성 요소	역할	적용 단위	방화벽 동작	비용
VPC	독립된 가상 네트워크 정의	리전	-	무료
서브넷	VPC IP 범위 분할	가용 영역(AZ)	-	무료
인터넷 게이트웨이	VPC ↔ 인터넷 양방향 연결	VPC	-	무료
NAT 게이트웨이	프라이빗 → 인터넷 아웃바운드	서브넷	-	유료
라우팅 테이블	트래픽 경로 규칙 정의	서브넷	-	무료
보안 그룹	인스턴스 단위 방화벽	인스턴스	Stateful / 허용만	무료
네트워크 ACL	서브넷 단위 방화벽	서브넷	Stateless / 허용+거부	무료
Bastion Host	프라이빗 서버 접근 중계	인스턴스	-	EC2 비용
VPC 피어링	VPC 간 프라이빗 통신	VPC	-	데이터 전송 비용
VPC Flow Logs	네트워크 트래픽 로그 기록	VPC/서브넷/ENI	-	저장 비용

---

참고

본 포스팅은 해당 사이트의 내용을 참고 및 인용하여 작성했습니다.

Inpa Dev - AWS 📚 VPC 개념 & 사용 - 인프라 구축 (Subnet / Routing / Internet Gateway)
Harry The Great - AWS 가장쉽게 VPC 개념잡기
IBM - 가상 프라이빗 클라우드란 무엇인가요?
Spidy web - VPC 정리 2. AWS VPC와 연관된 개념...
AWS - 네트워크 액세스 제어 목록으로 서브넷 트래픽 제어
AWS - Amazon VPC Flow Logs에 추가 메타 데이터를 통한 효율적인 로그 분석