[network] VPC와 서브넷

One-Line Summary

VPC는 AWS 클라우드 안에 만드는 논리적으로 격리된 나만의 가상 네트워크 공간이고, Subnet은 그 VPC의 IP 범위를 더 작게 쪼갠 구획이다. VPC는 리전 전체에 걸치고, 서브넷은 하나의 AZ(가용 영역)에 묶인다. 서브넷을 인터넷에 연결하느냐 마느냐로 public / private을 나누는 것이 네트워크 설계의 출발점이다.

Why It Exists

여러 애플리케이션·서버를 한 네트워크에 아무 통제 없이 두면, 외부에 노출되면 안 되는 DB까지 인터넷에 열리거나 서로 간섭한다. 온프레미스에서 방화벽·서브넷·라우터로 망을 나누던 것을 클라우드에서도 그대로 하고 싶다.

VPC와 Subnet은 이 문제를 해결한다.

통제 없는 단일 네트워크
  -> 웹 서버도 DB도 다 같은 공간, 외부 노출/간섭 위험

VPC + Subnet
  -> VPC로 격리된 사설 공간을 만들고(내 IP 대역 지정)
  -> Subnet으로 "인터넷에 열 곳(public)"과 "숨길 곳(private)"을 분리
  -> 라우팅/방화벽으로 흐름을 세밀하게 통제

시험 감각:

"격리된 사설 네트워크" = VPC. "그 안을 용도/AZ별로 나눈 구획" = Subnet. "웹은 열고 DB는 숨긴다" = public/private subnet 분리.

Abbreviations

VPC란 무엇인가 (상세)

VPC는 AWS 리전 안에 만드는 논리적으로 격리된 가상 네트워크다. 물리 장비는 AWS가 공유·관리하지만, 논리적으로는 내 계정 전용 네트워크처럼 완전히 분리되어 있다.

참고: 주 CIDR은 생성 후 변경 불가하지만, 나중에 보조(secondary) CIDR을 추가해 확장할 수 있다. 그래서 처음에 IP 대역을 넉넉하고 신중하게 잡는 것이 중요하다(피어링/VPN 시 대역이 겹치면 안 됨).

Subnet이란 무엇인가 (상세)

Subnet은 VPC의 큰 IP 대역을 더 작게 나눈 구획이다. 실제 EC2·RDS 같은 리소스는 VPC가 아니라 특정 서브넷 안에 배치된다.

예약되는 5개 IP (예: 10.0.1.0/24):

10.0.1.0    네트워크 주소
10.0.1.1    VPC 라우터
10.0.1.2    AWS DNS
10.0.1.3    향후 사용을 위해 예약
10.0.1.255  브로드캐스트 주소(관례상 예약)

그래서 /24(256개)라도 실제 사용 가능한 IP는 251개다.

VPC와 Subnet의 관계 (직관 비교)

포함 관계 그림:

Region (예: ap-northeast-2 서울)
└── VPC  10.0.0.0/16                     ← 리전 전체에 걸침
    ├── AZ-a
    │   ├── Subnet(public)  10.0.1.0/24  ← 웹/ALB/NAT 배치
    │   └── Subnet(private) 10.0.2.0/24  ← 앱/DB 배치
    └── AZ-c
        ├── Subnet(public)  10.0.3.0/24
        └── Subnet(private) 10.0.4.0/24

핵심 감각: VPC = 리전, Subnet = AZ. 그래서 고가용성(HA)을 원하면 여러 AZ에 서브넷을 나눠 배치한다. 한 AZ가 죽어도 다른 AZ 서브넷의 리소스로 서비스가 유지된다.

Public Subnet vs Private Subnet (가장 많이 쓰는 분할)

VPC를 나눌 때 가장 흔한 방식은 외부에서 접근 가능한 네트워크(public)와 접근 불가능한 네트워크(private)로 나누는 것이다.

무엇이 public/private를 결정하나? → 서브넷 자체에 스위치가 있는 게 아니라, 그 서브넷에 연결된 라우트 테이블이 IGW로 가는 경로(0.0.0.0/0 → igw-xxxx)를 갖느냐가 결정한다.

Public Subnet 라우트 테이블
  10.0.0.0/16 -> local        (VPC 내부 통신)
  0.0.0.0/0   -> igw-xxxx     (인터넷) ← 이 줄이 있으면 public

Private Subnet 라우트 테이블
  10.0.0.0/16 -> local
  0.0.0.0/0   -> nat-xxxx     (아웃바운드만, NAT 경유) ← IGW 직접 경로 없음

실제 사용 패턴 — 3-Tier 아키텍처

가장 전형적인 웹 서비스 구성이다. 여러 AZ에 걸쳐 public/private를 나눈다.

   Internet
      │
      ▼
┌─ VPC ───────────────────────────┐
│ ┌─ public subnet ─────────────┐ │
│ │ ALB · Bastion · NAT Gateway │ │  ← 인터넷 접점
│ └─────────────────────────────┘ │
│             │                   │
│             ▼                   │
│ ┌─ private subnet (App) ──┐     │
│ │ App EC2                 │     │  ← 외부 직접 접근 불가(ALB 통해서만)
│ └─────────────────────────┘     │
│             │                   │
│             ▼                   │
│ ┌─ private subnet (DB) ──┐      │
│ │ RDS                    │      │  ← App tier에서만 접근, 인터넷 차단
│ └────────────────────────┘      │
└─────────────────────────────────┘

프라이빗 서브넷의 앱 서버가 OS 패치나 외부 API 호출로 인터넷에 나가야 하지만 외부에서 들어오는 것은 막고 싶을 때, public 서브넷의 NAT Gateway를 경유시킨다. (NAT는 별도 노트에서 상세히)

CIDR·IP 설계 시 주의 (실무 감각)

실무 시나리오 — 3-Tier를 넘어서 (SAA 빈출)

시나리오 1. 서브넷 IP 고갈 (Auto Scaling·EKS·Lambda)

프라이빗 서브넷을 /24(251개)로 잡았는데 오토스케일로 인스턴스가 급증하거나, EKS 파드가 ENI마다 사설 IP를 소비하거나, VPC-연결 Lambda가 동시성만큼 ENI를 잡으면 IP가 빠르게 고갈된다 → 신규 인스턴스/파드 기동 실패.

• 대응: 서브넷을 넉넉히(/22, /20) 설계하거나, 보조(secondary) CIDR을 추가해 새 서브넷을 붙인다.
• 시험 감각: "instances fail to launch / cannot assign IP in subnet" → 서브넷 CIDR이 작아 IP 고갈 → 더 큰 대역/보조 CIDR.

시나리오 2. 대역 확장 — 주 CIDR은 못 바꾼다

운영 중 IP가 부족한데 주 CIDR은 변경 불가다. → VPC에 보조 CIDR 블록을 추가하고 거기에 새 서브넷을 만든다. (기존 대역과, 그리고 피어링/VPN 상대 대역과 겹치지 않아야 함.)

시나리오 3. Multi-AZ 고가용성 설계

각 계층(웹/앱/DB)의 서브넷을 최소 2개 AZ에 쌍으로 만든다. ALB는 여러 AZ 서브넷에 걸치고, RDS는 Multi-AZ로 대기 인스턴스를 다른 AZ 서브넷에 둔다 → 한 AZ 장애에도 서비스 유지.

AZ-a: [pub-a][app-a][db-a]      AZ-c: [pub-c][app-c][db-c]
 ALB는 pub-a·pub-c에 걸침 / RDS 기본=db-a, 대기=db-c (Multi-AZ)

시나리오 4. 여러 계정이 같은 네트워크 공유 — VPC Sharing

중앙 네트워크 계정이 **RAM(Resource Access Manager)**으로 서브넷을 다른 계정과 공유 → 각 팀 계정은 공유 서브넷에 리소스를 띄우되 네트워크는 중앙이 일괄 관리. (계정마다 VPC를 난립시키지 않는 대규모 조직 패턴.)

시험 트리거: "share subnets across accounts, central network management" → VPC Sharing(RAM).

Common Wrong Directions

Exam Triggers

Memory Sentence

VPC는 리전 전체에 걸친 격리된 사설 네트워크(내 CIDR 지정), 서브넷은 그것을 단일 AZ 단위로 쪼갠 구획. IGW로 가는 라우트가 있으면 public·없으면 private. 웹/ALB는 public, 앱·DB는 private에 두고, private의 아웃바운드는 NAT로 내보낸다. HA는 여러 AZ에 서브넷을 나눠서.

References

• What is Amazon VPC
• VPC CIDR blocks
• Subnets for your VPC
• Subnet sizing and reserved IP addresses
• Default VPCs