[AWS] VPC 구조와 설계: 클라우드 사설 네트워크의 기본 개념

AWS VPC(Virtual Private Cloud)는 물리 장비로 구성하던 온프레미스 네트워크를 소프트웨어 정의 방식으로 재구성한 것에 해당한다.

이번 포스팅에서는 VPC를 구성하는 핵심 요소들(CIDR, 서브넷, 라우팅 테이블, 게이트웨이, 보안 계층  등)을 온프레미스 개념과 비교해서 살펴본다.

1. VPC의 정의와 특성

VPC는 AWS 클라우드 내부에 사용자가 정의하는 격리된 가상 네트워크다.

온프레미스로 치면 자체 데이터센터의 사설 네트워크에 해당하며, 이 안에서 EC2, RDS, Lambda 등 컴퓨트·데이터·서버리스 리소스가 실행된다.

물리 라우터·스위치·방화벽으로 구축하던 계층을 SDN(소프트웨어 정의 네트워크)으로 대체한 것이 VPC의 본질이다.

VPC의 핵심 특성은 세 가지로 요약된다.

• 논리적 격리: 동일 리전 안이라도 다른 AWS 계정의 VPC와는 완전히 분리된 주소 공간을 갖는다.
• 리전 스코프: 하나의 VPC는 리전 내 여러 가용 영역(AZ)에 걸쳐 존재하지만, 리전 경계는 넘지 못한다.
• 사용자 정의 주소 체계: IP 대역, 서브넷 분할, 라우팅 정책을 설계자가 직접 결정한다.

2. CIDR 블록 설계

VPC 생성 시 가장 먼저 결정하는 값이 CIDR 블록이다.

10.0.0.0/16은 65,536개의 사설 IP를 확보한다는 의미이며, 크기는 /16에서 /28 사이에서 지정할 수 있다.

대역은 RFC 1918 사설 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 중에서 선택하는 것이 표준 관행이다.

 

CIDR 설계에서 가장 중요한 원칙은 연결 가능성이 있는 모든 네트워크와 대역이 겹치지 않도록 설계하는 것이다.

VPN, VPC Peering, Transit Gateway로 온프레미스나 다른 VPC와 연결하는 시점에 대역이 중복되면 라우팅 결정이 성립하지 않아 연결 자체가 불가능해진다.

GRE-over-IPsec 터널 실습에서 양단의 사설 대역이 겹치면 라우팅이 모호해지는 것과 동일한 문제다.

초기 설계 단계에서 온프레미스 대역, 향후 추가될 VPC 대역, 파트너사 연동 대역까지 함께 계획하여 서로 겹치지 않는 주소 공간을 배정해야 한다.

 

3. 서브넷과 라우팅 테이블

1️⃣ 서브넷의 구조

VPC의 CIDR을 잘게 쪼갠 것이 서브넷이며, 각 서브넷은 정확히 하나의 AZ에 속한다.

10.0.0.0/16 VPC를 다음과 같이 분할하는 방식이 전형적이다.

서브넷	AZ	성격
10.0.1.0/24	ap-northeast-2a	Public
10.0.2.0/24	ap-northeast-2c	Public
10.0.11.0/24	ap-northeast-2a	Private
10.0.12.0/24	ap-northeast-2c	Private

여기서 Public/Private의 구분은 물리적 속성이 아니다.

연결된 라우팅 테이블에 인터넷 게이트웨이로 향하는 기본 경로가 존재하는가의 문제일 뿐이다.

서브넷 자체는 동일한 논리 구조를 가지며, 트래픽의 출구가 어디를 향하느냐로 성격이 갈린다.

각 서브넷에서 앞 4개 IP(.0 네트워크, .1 VPC 라우터, .2 DNS, .3 예약)와 마지막 1개 IP(.255 브로드캐스트)는 AWS가 예약한다.

/24 서브넷의 실사용 가능 IP는 251개다.

2️⃣ 라우팅 테이블의 역할

서브넷에 연결된 라우팅 테이블이 트래픽 방향을 결정한다.

리눅스의 ip route와 동일한 개념이다.

모든 라우팅 테이블에는 10.0.0.0/16 → local 로컬 경로가 자동 포함되므로 VPC 내부 통신은 항상 성립한다.

여기에 추가되는 기본 경로가 서브넷의 성격을 규정한다.

• Public 서브넷: 0.0.0.0/0 → igw-xxxx
• Private 서브넷: 0.0.0.0/0 → nat-xxxx
• 완전 격리 서브넷: 기본 경로 자체를 만들지 않는다 (DB 티어에서 자주 쓰는 패턴)

4. 인터넷 게이트웨이와 NAT 게이트웨이

1️⃣ Internet Gateway (IGW)

IGW는 VPC와 인터넷을 연결하는 논리적 관문이며, VPC당 1개만 부착할 수 있다.

수평 확장과 고가용성은 AWS가 관리한다.

IGW는 순수 라우팅 장치가 아니라 1:1 NAT 기능을 같이 수행한다.

EC2 인스턴스에 Public IP나 Elastic IP가 부여되어 있을 때, IGW가 사설 IP와 공인 IP 간 정적 매핑을 수행한다.

2️⃣ NAT Gateway

NAT Gateway는 Private 서브넷의 인스턴스가 아웃바운드로만 인터넷에 접근할 수 있게 해주는 매니지드 서비스다.

패치 다운로드, 외부 API 호출 등이 주 용도이며, 외부에서 인스턴스로 들어오는 세션은 성립하지 않는다.

 

iptables와 비교해 보면, 동작상 POSTROUTING에 SNAT/MASQUERADE 규칙을 넣어 내부 IP를 게이트웨이의 공인 IP로 치환하는 것과 동일하다.

 

배치 조건은 두 가지다.

• Public 서브넷에 위치해야 한다 (인터넷으로 나가야 하므로).
• Elastic IP가 부착되어야 한다.

5. Security Group과 NACL

VPC의 보안은 두 계층에서 독립적으로 동작한다.

두 구성 요소는 이름이 비슷하지만 적용 대상, 상태 관리 방식, 규칙 평가 순서가 모두 다르다.

1️⃣ 두 계층의 비교

구분	Security Group	Network ACL
적용 대상	ENI(인스턴스) 단위	서브넷 단위
상태 관리	Stateful (응답 자동 허용)	Stateless (인바운드/아웃바운드 별도 규칙)
규칙 종류	Allow만 가능	Allow, Deny 모두 가능
평가 방식	모든 규칙을 종합적으로 평가	규칙 번호 오름차순으로 순차 평가
기본값	인바운드 전체 거부, 아웃바운드 전체 허용	기본 NACL은 양방향 전체 허용

2️⃣ Stateful과 Stateless의 실질적 차이

Security Group의 Stateful 특성은 iptables의 conntrack 모듈이 세션 상태를 추적하여 ESTABLISHED, RELATED 규칙 하나로 응답 패킷을 자동 통과시키는 방식과 동일한 개념이다. (참고: https://nanujahope.tistory.com/358)

인바운드에서 80/tcp를 허용하면 응답 트래픽에 대한 아웃바운드 규칙을 별도로 만들 필요가 없다.

 

반면 NACL은 세션 상태를 유지하지 않는다.

인바운드에서 80/tcp를 허용해도, 응답이 사용하는 임시 포트(대개 1024–65535)에 대한 아웃바운드 허용 규칙을 별도로 명시해야 한다.

 

iptables의 filter 테이블에 stateful 매치 없이 정적 룰만 걸어둔 상태와 동일하다.

트래픽이 인스턴스에 도달하기까지 두 계층을 순차적으로 통과하는 흐름은 다음과 같다.

 

파란색 경로는 클라이언트 → NACL(인바운드) → Security Group → EC2로 진입하는 요청이며, 붉은색 경로는 응답이 반대 방향으로 빠져나가는 흐름이다.

 

Security Group은 요청 시점의 세션을 기억하므로 응답에 별도 규칙이 필요 없지만, NACL은 인바운드에서 허용된 세션의 응답이라 하더라도 아웃바운드 규칙에서 다시 판정한다.

6. 3-Tier VPC 아키텍처

3-Tier 구조는 VPC의 표준 아키텍처 패턴이다.

각 티어를 최소 2개 AZ에 걸쳐 배치하여 AZ 장애 시에도 가용성을 유지한다.

각 티어의 역할은 다음과 같이 구분된다.

• Public 티어: 인터넷과 직접 통신해야 하는 리소스가 위치한다. ALB(Application Load Balancer), NAT Gateway, Bastion Host가 대표적이며, 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 존재한다.
• Private App 티어: 애플리케이션 실행 계층. 외부에서 직접 접근할 수 없으며, ALB를 통해 요청을 받는다. 아웃바운드는 NAT Gateway를 경유한다.
• Private DB 티어: 데이터베이스 계층. 인터넷과 완전히 격리하는 것이 원칙이며, 패치를 외부에서 받을 필요가 없다면 NAT를 통한 아웃바운드 경로조차 만들지 않는다. App 티어에서만 접근 가능하도록 Security Group으로 제한한다.

7. VPC 확장 개념

1️⃣ VPC Endpoint

S3, DynamoDB 등 AWS 서비스에 접근할 때 인터넷을 경유하지 않고 AWS 내부 백본망으로 직접 통신하도록 하는 진입점이다. Gateway 타입(S3, DynamoDB 전용)과 Interface 타입(대부분의 서비스, PrivateLink 기반)으로 나뉜다. Private 서브넷의 인스턴스가 NAT Gateway를 거치지 않고 AWS 서비스에 접근할 수 있어, 데이터 전송 비용 절감과 트래픽 노출면 축소 양쪽에서 이득이 있다.

2️⃣ VPC Peering과 Transit Gateway

VPC Peering은 두 VPC를 1:1로 연결하는 방식이며, 전이적 라우팅(transitive routing)이 성립하지 않는다. A-B, B-C가 각각 Peering으로 연결되어 있어도 A에서 C로 직접 통신할 수는 없다. 이 한계를 해소하기 위해 도입된 것이 Transit Gateway이며, 여러 VPC와 온프레미스 네트워크를 허브-스포크 구조로 통합한다.

3️⃣ VPC Flow Logs

ENI 단위로 트래픽 메타데이터(5-tuple, action, packet/byte 수)를 CloudWatch Logs 또는 S3에 저장한다. 실제 페이로드는 포함되지 않지만, SIEM과 이상 탐지의 핵심 데이터 소스로 활용된다. Snort 기반의 mini-SOAR가 IDS 알람을 트리거로 삼는다면, Flow Logs는 그보다 상위 계층에서 서브넷 단위의 트래픽 패턴 이상을 포착하는 원천 데이터가 된다.

4️⃣ Bastion Host와 Session Manager

Private 서브넷의 인스턴스에 접근하기 위한 관문이다. 전통적으로는 Public 서브넷에 SSH 포트를 연 Bastion Host를 두는 방식이 사용되었으나, 현재 권장되는 방식은 AWS Systems Manager Session Manager다. 인스턴스에 SSH 포트를 아예 열지 않고, SSM Agent를 통해 IAM 인증 기반으로 셸 세션을 열기 때문에 노출면과 키 관리 부담을 동시에 줄일 수 있다.

8. . iptables/netfilter와 AWS VPC 비교

VPC의 구성 요소는 iptables/netfilter 기반 리눅스 방화벽의 구성 요소와 비교해 보면 다음과 같이 대응된다.

AWS VPC	iptables/netfilter 대응
VPC	방화벽 뒤에 구성된 사설 네트워크 전체
서브넷	인터페이스별로 분리된 네트워크 세그먼트
라우팅 테이블	커널 라우팅 테이블 (ip route)
Internet Gateway	-t nat -A POSTROUTING -j SNAT(1:1 매핑) + 경계 라우팅
NAT Gateway	-t nat -A POSTROUTING -j MASQUERADE
Security Group	filter 테이블 + conntrack 기반 stateful 규칙
Network ACL	filter 테이블의 정적(stateless) 규칙
VPC Endpoint	사설 회선을 통한 서비스 직결 경로
Flow Logs	iptables LOG 타깃 + NetFlow/sFlow

 

VPC는 라우팅과 필터링이라는 네트워크의 기본 원리에 입각해서, 물리 장비와 명령어로 조합하던 구성을 매니지드 서비스로 추상화한 계층이다.

CIDR 설계로 주소 공간을 확보하고, 서브넷과 라우팅 테이블로 트래픽 방향을 결정하며, Security Group과 NACL로 두 계층의 필터링을 구성한다.

이 네 개의 축은 VPC 위에 어떤 아키텍처를 얹더라도 동일하게 작동하는 설계의 기본 골격이다.