Hook

클라우드에서 “네트워크”라고 하면 결국 하나의 질문으로 귀결됩니다. “누가, 어디로, 어떻게 통신할 수 있는가?” AWS VPC는 이 질문에 대한 답을 설계하는 캔버스입니다.

데이터베이스는 인터넷에 노출되면 안 됩니다. 애플리케이션 서버는 패치를 위해 아웃바운드로만 인터넷에 접근해야 합니다. 본사 데이터센터와 AWS를 전용선으로 연결해야 합니다. 수십 개의 VPC를 서로 연결해야 합니다. 이 모든 요구사항이 하나의 VPC 설계로 표현됩니다.

이 글에서는 VPC의 16가지 핵심 개념을 기초 → 보안 → 확장 세 영역으로 정리합니다. ASCII 다이어그램과 비교 테이블로, 면접과 실무에 모두 쓸 수 있는 참조서를 만듭니다.

TL;DR

• VPC = 격리된 가상 네트워크: CIDR 블록으로 IP 범위를 정의하고, 서브넷으로 AZ별로 분할합니다
• 보안은 두 층: Security Group(인스턴스, Stateful) + NACL(서브넷, Stateless)으로 심층 방어합니다
• 연결은 규모에 따라: 2~5 VPC는 Peering, 5+ VPC는 Transit Gateway, 온프레미스는 VPN 또는 Direct Connect로 연결합니다
• 엔드포인트로 비용 절감: S3/DynamoDB는 무료 Gateway Endpoint, 나머지는 Interface Endpoint(PrivateLink)로 인터넷을 거치지 않습니다

Part 1: VPC 기초: CIDR, 서브넷, 라우팅, NAT

VPC 개요와 CIDR 설계

Amazon VPC(Virtual Private Cloud)는 AWS 계정 전용으로 프로비저닝되는 논리적으로 격리된 가상 네트워크입니다. 리전 단위 리소스이며, 리전 내 모든 가용 영역(AZ)에 걸쳐 서브넷을 생성할 수 있습니다.

VPC 생성 시 CIDR 블록을 지정해야 하며, /16(최대)에서 /28(최소)까지 가능합니다.

VPC에서는 RFC 1918 사설 IP 대역 사용을 권장합니다.

VPC CIDR은 온프레미스 네트워크, 다른 VPC와 절대 겹쳐서는 안 됩니다. 향후 Peering이나 VPN 연결 시 충돌이 발생하며, 생성 후 변경이 제한적이므로 초기 설계가 결정적입니다.

서브넷: Public vs Private

서브넷은 VPC 내에서 더 작은 네트워크 세그먼트입니다. 하나의 서브넷은 하나의 AZ에만 속하며, 고가용성을 위해서는 최소 2개 이상의 AZ에 분산 배치해야 합니다.

각 서브넷에는 5개의 예약 IP가 있습니다. 10.0.0.0/24의 경우:

/24 서브넷은 256개 중 5개 예약으로 251개 IP 사용 가능, /28은 16개 중 5개 예약으로 11개만 사용 가능합니다. 서브넷 설계 시 반드시 고려합니다.

ENI (Elastic Network Interface)

ENI는 VPC 내 가상 네트워크 인터페이스입니다. EC2 인스턴스가 VPC와 통신하려면 반드시 ENI가 필요합니다. 구성 요소는 사설 IPv4(필수), 공인 IPv4(선택), 탄력적 IP(선택), MAC 주소, 보안 그룹(최대 5개)입니다.

하나의 인스턴스에 여러 ENI를 연결할 수 있어, 방화벽 어플라이언스, 관리/데이터 네트워크 분리(Dual-Homed), 빠른 장애 조치(Failover)에 활용합니다. ENI를 다른 인스턴스로 이동하면 탄력적 IP도 함께 이동합니다.

라우팅 테이블

라우팅 테이블은 트래픽이 어디로 전달될지 결정하는 규칙 집합입니다. 가장 구체적인 경로가 우선합니다. 0.0.0.0/0보다 10.0.1.0/24가 더 구체적이므로 먼저 적용됩니다.

핵심 규칙: 하나의 서브넷은 하나의 라우팅 테이블에만 연결되지만, 하나의 라우팅 테이블은 여러 서브넷에 연결될 수 있습니다. 명시적으로 연결하지 않은 서브넷은 Main Route Table을 사용합니다.

인터넷 게이트웨이(IGW)와 NAT Gateway

IGW는 VPC와 인터넷 간의 출입문입니다. 수평 확장, 중복 고가용성 컴포넌트이며, VPC와 1:1로 연결됩니다. IGW는 사설 IP ↔ 공인 IP NAT 변환을 수행합니다.

인스턴스가 인터넷에 접근하려면 4가지 조건이 모두 충족되어야 합니다:

[인터넷 접근 4대 조건]
  1. VPC에 IGW 연결
  2. 라우팅 테이블에 0.0.0.0/0 → igw-xxx 경로
  3. 인스턴스에 공인 IP 또는 탄력적 IP 할당
  4. 보안 그룹과 NACL이 트래픽 허용

NAT Gateway는 Private Subnet의 인스턴스가 아웃바운드로만 인터넷에 접근할 수 있게 하는 관리형 서비스입니다. 최대 45Gbps까지 자동 확장되며, 탄력적 IP 연결이 필수입니다. NAT Gateway 자체에는 보안 그룹을 연결할 수 없고, NACL로 제어합니다.

고가용성을 위해 각 AZ마다 NAT Gateway를 배치하고, 해당 AZ의 Private Subnet 라우팅 테이블이 같은 AZ의 NAT Gateway를 가리키도록 설계합니다. 하나의 AZ 장애에도 다른 AZ에서 인터넷 접근이 유지됩니다.

IPv6 아웃바운드 전용으로는 Egress-only Internet Gateway를 사용합니다. NAT 변환 없이 아웃바운드만 허용하고 인바운드는 차단합니다.

Part 2: 보안 계층: Security Groups vs NACL

Security Group (인스턴스 수준)

보안 그룹은 EC2 인스턴스(ENI) 수준의 가상 방화벽입니다. Stateful(상태 저장)이므로, 인바운드로 들어온 트래픽에 대한 응답은 아웃바운드 규칙과 무관하게 자동 허용됩니다. 반대 방향도 마찬가지입니다.

다른 보안 그룹을 소스로 참조할 수 있습니다. 예를 들어 DB 보안 그룹의 인바운드 규칙을 sg-app-xxx에서만 3306포트 접근 허용으로 설정하면, App 보안 그룹이 적용된 인스턴스만 DB에 접근할 수 있습니다.

Network ACL (서브넷 수준)

NACL은 서브넷 수준의 방화벽입니다. Stateless(상태 비저장)이므로, 인바운드를 허용해도 그 응답(아웃바운드)을 별도로 허용해야 합니다. 이것이 보안 그룹과의 가장 큰 차이점입니다.

핵심 비교

실무에서는 심층 방어(Defense in Depth) 원칙으로 두 층을 함께 사용합니다. NACL로 서브넷 단위의 coarse 차단을, SG로 인스턴스 단위의 세밀한 제어를 수행합니다. 특정 IP 대역을 명시적으로 차단(Deny)해야 하는 경우에는 NACL만 가능합니다.

Part 3: 네트워크 확장: Peering, Transit Gateway, 엔드포인트, 하이브리드

VPC Peering

VPC Peering은 두 VPC 간에 AWS 프라이빗 네트워크를 통해 트래픽을 직접 전송하는 연결입니다. 인터넷을 거치지 않습니다.

• 다른 리전, 다른 계정 간 가능 (Inter-Region, Cross-Account)
• 전이적 라우팅 불가: A-B, B-C가 각각 Peering되어 있어도 A→C로 트래픽 전달 불가. 별도 A-C Peering 필요
• CIDR 겹침 불가: 두 VPC의 CIDR이 overlap이면 연결할 수 없음
• N개 VPC 상호 연결 시 N×(N-1)/2 개의 Peering 연결 필요

Peering 수가 폭발하는 환경(5개 이상 VPC 상호 연결)에서는 Transit Gateway로 전환해야 관리 복잡도를 낮출 수 있습니다.

Transit Gateway

Transit Gateway는 다수의 VPC와 온프레미스 네트워크를 중앙 허브(Hub)를 통해 연결합니다. Peering의 전이적 라우팅 제한을 해결하며, N개의 연결만으로 모든 VPC를 상호 연결합니다.

Transit Gateway는 Direct Connect, Site-to-Site VPN 연동과 멀티캐스트 지원(비디오 스트리밍, 주식 시세 분배)을 제공합니다. Network Manager 대시보드로 글로벌 네트워크 토폴로지와 트래픽 흐름을 시각화할 수 있습니다.

VPC Endpoint

VPC Endpoint를 사용하면 퍼블릭 IP, NAT Gateway, 인터넷 게이트웨이 없이 AWS 서비스에 비공개로 연결합니다. 트래픽이 인터넷을 거치지 않으므로 보안과 성능이 향상됩니다.

S3와 DynamoDB는 무료 Gateway Endpoint를 사용해 NAT Gateway 데이터 처리 비용을 절감하고 보안을 강화합니다. 나머지 AWS 서비스는 Interface Endpoint(PrivateLink)로 연결합니다. 2026년에는 VPC Endpoint Policy로 특정 버킷만 접근, 조건부 접근 등 세분화된 제어가 가능합니다.

Site-to-Site VPN vs Direct Connect

온프레미스와 AWS를 연결하는 두 가지 방법입니다.

VPN의 구성 요소는 Customer Gateway(온프레미스 라우터), Virtual Private Gateway(VPC 측 종단점)이며, Transit Gateway를 VPN 종단점으로 사용할 수도 있습니다. 기본적으로 2개의 IPSec 터널로 고가용성을 제공하고, 정적/동적(BGP) 라우팅을 선택합니다.

Direct Connect는 Direct Connect Gateway를 통해 하나의 전용선으로 여러 리전의 VPC에 접근할 수 있습니다.

VPC Flow Logs

Flow Logs는 ENI의 송수신 트래픽 메타데이터를 캡처합니다. VPC / 서브넷 / ENI 세 가지 레벨에서 활성화할 수 있으며, CloudWatch Logs(실시간 모니터링), S3(Athena SQL 분석, 장기 보관), Kinesis Data Firehose(실시간 스트리밍)로 전송합니다.

Flow Logs는 페이로드(내용)를 캡처하지 않으며, 실시간이 아닙니다 (수분 지연). DHCP, DNS, 인스턴스 메타데이터 트래픽은 기록되지 않습니다.

아키텍처 패턴

퍼블릭/프라이빗 서브넷 패턴: 가장 기본적인 구조입니다.

[인터넷] ←→ [Internet Gateway]
                  |
            [VPC: 10.0.0.0/16]
                  |
    ┌─────────────┼─────────────┐
    |             |             |
 [AZ-a]        [AZ-b]        [AZ-c]
    |             |             |
 [Public]     [Public]      [Public]  ← ALB, NAT GW, Bastion
    |             |             |
 [Private]    [Private]     [Private] ← App Server, DB

Public Subnet에는 ALB, NAT Gateway, Bastion Host를 배치하고, Private Subnet에는 애플리케이션 서버와 데이터베이스를 배치합니다.

3계층 아키텍처 (Web-App-DB): 엔터프라이즈 표준 구조입니다.

[인터넷] → [IGW] → [ALB (Public)]
                        |
                   [Web Server (Public)]
                        |
                   [App Server (Private)]  ← NAT GW로 아웃바운드
                        |
                   [RDS DB (Private/격리)]

VPC 설계 모범 사례:

1. CIDR 계획: 향후 확장을 고려해 /16 권장, 온프레미스/다른 VPC와 겹치지 않게 설계
2. 다중 AZ: 최소 2개, 권장 3개 AZ에 서브넷 분산 배치
3. 심층 방어: NACL(서브넷) + SG(인스턴스) 동시 사용
4. 최소 권한: 0.0.0.0/0 전체 허용을 피하고 필요한 최소 트래픽만 허용
5. NAT Gateway 다중 배치: 각 AZ마다 배치하여 단일 장애점(SPOF) 제거
6. Gateway Endpoint 활용: S3/DynamoDB는 무료 엔드포인트로 NAT 비용 절감
7. Flow Logs 활성화: 모든 VPC에 트래픽 모니터링 설정
8. 환경 분리: 개발/스테이징/프로덕션을 별도 VPC로 분리

마치며

네트워크는 클라우드에서 가장 추상적이고 다루기 어려운 영역이라고만 생각했는데, VPC를 CIDR 설계부터 차근차근 따라가 보니 모든 것이 논리적으로 연결된다는 걸 깨달았습니다. IP 대역을 한 번 잘못 잡으면 온프레미스나 다른 VPC와 충돌해 복구가 어렵다는 점은, 초기 설계의 무게를 실감하게 합니다.

보안 설계에서도 새로운 통찰을 얻었습니다. Security Group과 NACL을 단순히 “방화벽”이라고만 생각했는데, Stateful과 Stateless, 인스턴스 단위와 서브넷 단위라는 차이가 각자 다른 역할을 부여한다는 걸 알게 되었습니다. 그리고 연결 규모에 따라 Peering과 Transit Gateway를 선택하는 기준이 명확해지니, 네트워크 아키텍처가 체계적으로 그려지기 시작했습니다.

VPC는 클라우드 인프라 전체의 뼈대이자 보안의 시작점입니다. 앞으로 실제 환경에서 다중 AZ 서브넷을 구성하고, NAT Gateway와 엔드포인트로 비용까지 최적화한 견고한 네트워크를 직접 설계해 보고 싶습니다.

AWS 시리즈 4/16

← S3 객체 스토리지 기초. 버킷부터 수명주기까지
	로드밸런싱 & 오토스케일링. ELB와 Auto Scaling Groups →