VPC 서브넷과 연결 경로 설계

VPC(Virtual Private Cloud)를 설계할 때는 주소 대역만 정한다고 끝나지 않는다. 각 서브넷의 경로, 인바운드·아웃바운드 제어, 다른 VPC나 온프레미스와의 연결 방식이 실제 통신 가능 여부를 결정한다. 이 글은 요청이 어디서 출발해 어떤 경로와 정책을 통과하는지 순서대로 살펴본다.

1. VPC 기본 구조

VPC를 만들면 그 안에서 IP 대역(CIDR)을 직접 정의하고, 서브넷으로 나누어 사용한다.

VPC (예: 10.0.0.0/16)
├── 퍼블릭 서브넷  (10.0.1.0/24) — AZ-a
├── 퍼블릭 서브넷  (10.0.2.0/24) — AZ-b
├── 프라이빗 서브넷 (10.0.3.0/24) — AZ-a
└── 프라이빗 서브넷 (10.0.4.0/24) — AZ-b

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

선택 근거: 서브넷 자체가 퍼블릭/프라이빗을 결정하는 것이 아니라, 라우팅 테이블에 IGW 경로가 있는지가 결정한다.

2. 핵심 구성 요소

인터넷 게이트웨이 (IGW)

VPC와 인터넷 사이의 문. VPC당 하나만 붙일 수 있고, 고가용성이 기본 제공된다.

인터넷
  ↕
IGW (VPC에 붙음)
  ↕
퍼블릭 서브넷의 EC2 (공인 IP 필요)

NAT 게이트웨이

프라이빗 서브넷의 EC2가 외부로 나가는 트래픽(패치, API 호출)만 허용하는 장치. 외부에서 프라이빗 서브넷으로 들어오는 연결은 차단된다.

프라이빗 서브넷 EC2
  → NAT 게이트웨이 (퍼블릭 서브넷에 위치)
    → IGW
      → 인터넷

선택 근거: NAT 게이트웨이는 AZ당 하나를 배치해야 고가용성이 된다. 하나만 두면 그 AZ 장애 시 다른 AZ의 프라이빗 서브넷도 인터넷 차단된다.

라우팅 테이블

서브넷마다 어디로 트래픽을 보낼지 규칙을 정의한다.

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

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

3. 보안: 보안 그룹 vs NACL

두 가지 모두 트래픽을 제어하지만 작동 방식이 완전히 다르다.

Stateful vs Stateless 차이 (중요)

보안 그룹(Stateful): 인바운드 허용하면 응답 트래픽은 자동으로 아웃바운드 허용. NACL(Stateless): 인바운드와 아웃바운드를 각각 별도로 설정해야 한다. 아웃바운드 임시 포트(1024-65535)도 열어줘야 한다.

선택 근거: "특정 IP를 완전히 차단해야 한다"는 요구사항 → 보안 그룹은 Deny 규칙이 없으므로 NACL이 정답이다.

4. VPC 연결 옵션 (SAP 핵심)

SAP에서 가장 많이 출제되는 부분이다. 상황마다 어떤 연결 방식을 쓰는지 정확히 구분해야 한다.

4-1. VPC Peering

두 VPC를 1:1로 연결하는 방식. 같은 리전, 다른 리전, 다른 계정 모두 가능.

VPC-A (10.0.0.0/16)  ←→  VPC-B (172.16.0.0/16)

제약사항:

• CIDR 중복 불가 (겹치면 피어링 불가)
• 전이적 라우팅 불가 — A↔B, B↔C 피어링이 있어도 A에서 C로 직접 통신 불가. A↔C 피어링을 별도로 만들어야 함

선택 근거: VPC가 5개라면 모두 연결하려면 피어링이 10개 필요 (n*(n-1)/2). VPC가 많아질수록 관리가 복잡해진다 → Transit Gateway 사용 신호.

4-2. Transit Gateway (TGW)

여러 VPC와 온프레미스를 중앙 허브 하나로 연결하는 서비스.

VPC-A ──┐
VPC-B ──┤
VPC-C ──┼── Transit Gateway ── 온프레미스 (VPN/DX)
VPC-D ──┤
온프레미스┘

VPC Peering과 비교:

선택 근거: "VPC 수가 많고 온프레미스도 연결해야 한다" → Transit Gateway. "VPC 2~3개, 단순 연결" → VPC Peering.

4-3. Site-to-Site VPN

온프레미스 데이터센터와 AWS VPC를 인터넷을 통해 암호화 터널로 연결.

온프레미스 라우터
    ↕ (IPsec 암호화, 인터넷 경유)
Virtual Private Gateway (VGW) — VPC에 붙음

특징:

• 빠른 구축 (수 시간 이내)
• 인터넷 경유이므로 대역폭·지연 시간 불안정
• 기본 제공 이중화 (터널 2개)
• 비용 저렴

4-4. Direct Connect (DX)

온프레미스와 AWS를 전용 물리 회선으로 연결.

온프레미스
  → DX 파트너 코로케이션 시설
    → AWS Direct Connect 로케이션
      → AWS 리전

선택 근거: "대용량 데이터 전송, 안정적 지연 시간 필요" → Direct Connect. "빠른 구축, 백업 용도" → VPN. DX + VPN 병행 구성(DX 장애 시 VPN 페일오버)도 자주 출제된다.

4-5. VPC Endpoint

VPC 내부에서 인터넷을 거치지 않고 AWS 서비스(S3, DynamoDB 등)에 접근하는 방법. 프라이빗 서브넷의 EC2가 NAT 없이 S3에 접근할 때 사용한다.

Gateway Endpoint (무료):

• S3, DynamoDB만 지원
• 라우팅 테이블에 경로 추가 방식
• VPC 내부에서만 사용 가능

Interface Endpoint (유료, PrivateLink):

• 대부분의 AWS 서비스 지원 (EC2 API, CloudWatch, SSM 등)
• ENI(사설 IP) 방식으로 동작
• 온프레미스에서 DX/VPN 통해 접근 가능

프라이빗 서브넷 EC2
  → VPC Endpoint (Gateway/Interface)
    → S3 / DynamoDB / 기타 서비스
    (인터넷 미경유, NAT 불필요)

선택 근거: "프라이빗 서브넷 EC2가 S3에 접근해야 하는데 인터넷에 노출되면 안 된다" → Gateway Endpoint(S3/DynamoDB 무료) 또는 Interface Endpoint. NAT 게이트웨이 비용도 절감된다.

5. 전형적인 3-Tier 아키텍처

SAP에서 자주 등장하는 표준 구성이다.

인터넷
  ↓
IGW
  ↓
ALB (퍼블릭 서브넷, Multi-AZ)
  ↓
EC2 앱 서버 (프라이빗 서브넷, Multi-AZ)
  ↓
RDS (프라이빗 서브넷, Multi-AZ)

• ALB만 퍼블릭 서브넷에 두고 EC2·RDS는 프라이빗 서브넷
• EC2에서 인터넷 아웃바운드 필요 시 NAT 게이트웨이 사용
• EC2 → S3 접근은 Gateway Endpoint로 인터넷 미경유
• 보안 그룹으로 계층 간 트래픽만 허용 (ALB → EC2 포트만, EC2 → RDS 포트만)

6. SAP 시험 출제 유형

유형 1 — 온프레미스 연결 선택

"제조업체가 온프레미스 ERP와 AWS를 연결해야 한다. 매일 수 TB의 데이터를 안정적으로 전송해야 하고, 지연 시간이 일정해야 한다."

→ Direct Connect (대용량·안정·전용선) → VPN은 인터넷 경유라 지연 불안정, 대역폭 제한

유형 2 — 다수 VPC 연결

"계정 10개, 각 계정마다 VPC 3개씩 있다. 모든 VPC가 서로 통신하고 온프레미스와도 연결해야 한다."

→ Transit Gateway (VPC Peering으로는 관리 불가능한 규모)

유형 3 — 보안 차단

"특정 악성 IP에서 오는 트래픽을 서브넷 수준에서 완전히 차단해야 한다."

→ NACL (보안 그룹은 Deny 불가, NACL은 특정 IP Deny 가능)

유형 4 — 비용 절감

"프라이빗 서브넷 EC2가 S3에 자주 접근한다. NAT 게이트웨이 비용이 높다."

→ S3 Gateway Endpoint 추가 (무료, NAT 통하지 않음)

7. 패킷 흐름으로 VPC 장애를 좁히는 방법

“연결이 안 된다”는 현상만으로 보안 그룹부터 바꾸면 원인을 놓치기 쉽다. 출발지와 목적지를 정한 뒤 다음 네 층을 순서대로 확인한다.

예를 들어 프라이빗 EC2에서 S3로 요청이 실패하면 NAT를 무조건 추가하기 전에 S3 Gateway Endpoint와 엔드포인트 정책을 확인한다. 같은 리전의 S3 트래픽은 Gateway Endpoint로 인터넷과 NAT를 거치지 않게 만들 수 있어 비용과 장애 지점을 함께 줄일 수 있다.

배포 전 체크리스트

• 각 AZ의 프라이빗 서브넷에 올바른 라우팅 테이블 연결
• NAT Gateway를 사용할 경우 해당 NAT가 있는 퍼블릭 서브넷의 IGW 경로 확인
• 보안 그룹은 계층 간 필요한 포트만 허용
• NACL은 요청과 응답의 ephemeral port 범위를 함께 고려
• Reachability Analyzer 또는 VPC Flow Logs로 예상 경로 검증

8. 공식 문서로 다시 확인하기

• 프라이빗 서브넷과 NAT Gateway 예시 — AZ별 NAT와 라우팅 구성
• VPC 라우팅 테이블 — 서브넷과 경로의 관계
• VPC Reachability Analyzer — 네트워크 경로 분석

이 시리즈에서 이어 읽기

• 01. 글로벌 인프라와 AZ 설계 — 네트워크를 배치할 장애 경계
• 04. EC2와 스토리지 — 프라이빗 서브넷의 컴퓨팅·스토리지 선택
• 05. 고가용성과 확장성 — VPC 위에 ELB·Auto Scaling 구성

정리

인스턴스 타입 선택, 구매 옵션(On-Demand·Reserved·Spot), 스토리지 종류별 특성과 SAP에서 요구하는 설계 패턴을 정리할 예정이다.