VPC와 Subnet - Passion Project

# VPC와 Subnet ## 소개글 > [!abstract] Introduction > VPC(Virtual Private Cloud)의 설계는 CIDR 블록의 선택과 서브넷의 배치에서 시작된다. 이 결정은 향후 확장성, 고가용성, 보안 격리를 좌우하는 기초 공사에 해당한다. 이 포스트에서는 VPC의 주소 공간 설계부터 계층적 서브넷 아키텍처, 가용 영역(AZ) 분산 전략, 그리고 DHCP/DNS 구성까지 VPC의 기반 계층을 다룬다. ## CIDR 블록 설계 ### CIDR이란 CIDR(Classless Inter-Domain Routing)[^cidr-definition]은 IP 주소 범위를 표기하는 방법이다. 예를 들어 `10.0.0.0/16`은 `10.0.0.0`부터 `10.0.255.255`까지 총 65,536개의 IP 주소를 포함하는 범위를 의미한다. 슬래시 뒤의 숫자는 네트워크 프리픽스의 비트 수를 나타내며, 이 숫자가 작을수록 더 많은 호스트 주소를 사용할 수 있다. [^cidr-definition]: CIDR(Classless Inter-Domain Routing) — 과거의 클래스 기반 IP 할당(Class A/B/C)을 대체하여, 가변 길이의 서브넷 마스크로 IP 주소 공간을 유연하게 분할하는 방식이다. VPC 생성 시 가장 먼저 결정하는 것이 바로 이 CIDR 블록이다. AWS는 RFC 1918에서 정의한 사설 IP 대역의 사용을 권장한다. | 대역 | 범위 | 용도 | | :--- | :--- | :--- | | `10.0.0.0/8` | 10.0.0.0 ~ 10.255.255.255 | 대규모 엔터프라이즈 | | `172.16.0.0/12` | 172.16.0.0 ~ 172.31.255.255 | 중규모 조직 | | `192.168.0.0/16` | 192.168.0.0 ~ 192.168.255.255 | 소규모·개발 환경 | AWS VPC는 `/16`(65,536개 IP)부터 `/28`(16개 IP)까지의 넷마스크를 지원한다. 가용 IP의 수는 다음과 같이 계산한다. $ \text{가용 호스트 수} = 2^{(32 - \text{prefix})} - 5 $ 여기서 5를 빼는 이유는 AWS가 각 서브넷에서 다섯 개의 IP를 예약하기 때문이다. | 예약 IP | 용도 | | :--- | :--- | | 첫 번째 (x.x.x.0) | 네트워크 주소 | | 두 번째 (x.x.x.1) | VPC 라우터 | | 세 번째 (x.x.x.2) | AWS DNS 서버 | | 네 번째 (x.x.x.3) | AWS 예약 (향후 사용) | | 마지막 (x.x.x.255) | 브로드캐스트 주소[^broadcast-address-reserved] | [^broadcast-address-reserved]: AWS VPC는 브로드캐스트를 지원하지 않지만, 네트워크 표준에 따라 이 주소를 예약한다. ### CIDR 설계 원칙 엔터프라이즈 환경에서 CIDR 설계의 가장 큰 과제는 IP 주소 중복 방지다. 여러 VPC를 [[VPC 연결 전략 — Peering과 Transit Gateway|피어링하거나 Transit Gateway로 연결]]할 때, CIDR이 겹치면 라우팅 충돌이 발생하여 통신이 불가능해진다. 이는 나중에 수정하기 매우 어려운 아키텍처 부채가 된다. 이를 해결하기 위한 전략은 다음과 같다. 첫째, 초기에 충분히 큰 CIDR을 할당한다. VPC 생성 후 CIDR을 축소할 수 없으므로, `/16` 크기로 시작하고 서브넷을 작게 나누는 것이 안전하다. 보조 CIDR 블록을 추가할 수 있지만, 라우팅 복잡성이 증가하므로 초기 설계가 중요하다. 둘째, Amazon VPC IPAM(IP Address Manager)을 활용한다. IPAM은 조직 전체의 IP 주소 할당을 중앙에서 자동화하고 모니터링하여, 중복 할당을 원천적으로 차단하고 IP 사용률을 시각화한다. 대규모 멀티 VPC 환경에서는 사실상 필수적인 도구다. 셋째, 환경별로 대역을 구분한다. 예를 들어 `10.0.0.0/8` 대역을 다음과 같이 나눈다. ``` Production: 10.0.0.0/16 ~ 10.49.0.0/16 Staging: 10.50.0.0/16 ~ 10.59.0.0/16 Development: 10.60.0.0/16 ~ 10.69.0.0/16 On-premises: 10.100.0.0/16 ~ ``` 이렇게 대역을 사전에 할당하면, 새로운 VPC를 생성할 때 기존 네트워크와의 충돌을 걱정할 필요가 없다. ## 서브넷 아키텍처 ### 서브넷의 개념 서브넷(*Subnet*)은 VPC의 CIDR 블록을 더 작은 단위로 나눈 논리적 파티션이다. 각 서브넷은 물리적으로 단일 가용 영역(AZ)[^availability-zone-definition]에 종속된다. 이는 서브넷이 특정 데이터 센터 건물(AZ)에 위치한다는 의미이며, 서브넷 안에 배치된 리소스는 해당 AZ의 물리적 인프라를 사용한다. [^availability-zone-definition]: 가용 영역(Availability Zone, AZ) — 하나의 AWS 리전 내에서 물리적으로 분리된 독립적인 데이터 센터 그룹이다. 각 AZ는 독립된 전원, 냉각, 네트워크를 갖추고 있어, 하나의 AZ 장애가 다른 AZ에 영향을 미치지 않는다. 서브넷은 그 자체로는 퍼블릭도 프라이빗도 아니다. 서브넷에 연결된 [[VPC 라우팅과 게이트웨이|라우팅 테이블]]이 인터넷 게이트웨이(IGW)로의 경로를 포함하느냐에 따라 퍼블릭 또는 프라이빗이 결정된다. | 유형 | 라우팅 특성 | 배치 리소스 | | :--- | :--- | :--- | | 퍼블릭 서브넷 | `0.0.0.0/0` → IGW | ALB, Bastion Host, NAT Gateway | | 프라이빗 서브넷 | `0.0.0.0/0` → NAT Gateway | 애플리케이션 서버, 컨테이너 | | 데이터 서브넷 | 인터넷 경로 없음 | RDS, ElastiCache, Redshift | ### 3계층 서브넷 설계 프로덕션 환경에서 가장 널리 사용되는 패턴은 3계층(3-Tier) 서브넷 설계다. 이 패턴은 네트워크 레벨에서 심층 방어(*Defense in Depth*)를 구현한다. ```mermaid flowchart TB INET["인터넷"] <-->|IGW| PUB subgraph VPC["VPC 10.0.0.0/16"] PUB["퍼블릭 서브넷 Presentation Tier ALB · Bastion · NAT GW"] PRI["프라이빗 서브넷 Application Tier EC2 · ECS · Lambda"] DAT["데이터 서브넷 Data Tier RDS · ElastiCache"] end PUB -->|"NAT GW (아웃바운드 전용)"| PRI PRI -->|"DB 포트만 허용"| DAT ``` 각 계층의 역할과 보안 원칙은 다음과 같다. **퍼블릭 서브넷 (Presentation Tier)** — 외부 인터넷과의 직접 통신을 담당한다. Application Load Balancer(ALB)가 외부 요청을 수신하고, Bastion Host[^bastion-host-definition]가 관리자의 SSH 접속을 중개한다. 인바운드 트래픽은 `80`(HTTP)과 `443`(HTTPS) 포트만 허용하며, [[NACL]]로 추가적인 경계 방어를 적용한다. [^bastion-host-definition]: Bastion Host — 외부 네트워크에서 내부 프라이빗 네트워크에 접근할 수 있는 유일한 진입점 역할을 하는 서버다. 점프 서버(*Jump Server*)라고도 부른다. **프라이빗 서브넷 (Application Tier)** — 비즈니스 로직을 처리하는 서버가 위치한다. 인터넷에서 직접 접근할 수 없으며, 아웃바운드 인터넷 통신(패치 다운로드, 외부 API 호출 등)은 퍼블릭 서브넷의 [[VPC 라우팅과 게이트웨이|NAT Gateway]]를 경유한다. 인바운드는 퍼블릭 서브넷의 ALB에서 오는 트래픽만 허용한다. **데이터 서브넷 (Data Tier)** — 데이터베이스와 캐시가 위치한다. 인터넷으로의 경로가 아예 존재하지 않는다. 인바운드는 오직 프라이빗 서브넷의 애플리케이션 서버에서 오는 트래픽만 허용한다. AWS 서비스 접근이 필요한 경우(예: S3 백업) [[VPC Endpoint와 PrivateLink|VPC Endpoint]]를 사용하여 인터넷을 완전히 우회한다. 이 설계의 핵심 가치는 한 계층이 침해되더라도 다른 계층으로의 수평 이동(*lateral movement*)을 네트워크 수준에서 차단한다는 점이다. 웹 서버가 해킹되어도 데이터베이스에 직접 접근할 수 없고, 반드시 애플리케이션 계층을 거쳐야 한다. ### 가용 영역 분산 전략 고가용성을 확보하려면 각 계층의 서브넷을 최소 2개 이상의 AZ에 분산 배치해야 한다. 하나의 AZ가 전체 장애를 겪더라도 다른 AZ의 서브넷이 서비스를 유지할 수 있기 때문이다. 실제 프로덕션 환경의 서브넷 배치 예시는 다음과 같다. | 서브넷 | AZ-A | AZ-B | AZ-C | | :--- | :--- | :--- | :--- | | 퍼블릭 | `10.0.1.0/24` | `10.0.11.0/24` | `10.0.21.0/24` | | 프라이빗 | `10.0.2.0/24` | `10.0.12.0/24` | `10.0.22.0/24` | | 데이터 | `10.0.3.0/24` | `10.0.13.0/24` | `10.0.23.0/24` | 이 배치에서 주목할 점은 CIDR 블록의 두 번째 옥텟 규칙이다. AZ-A는 `x.x.1~3.x`, AZ-B는 `x.x.11~13.x`, AZ-C는 `x.x.21~23.x`처럼 체계적으로 번호를 부여하면, 서브넷 ID만 보고도 어떤 AZ의 어떤 계층인지 즉시 파악할 수 있다. 이러한 네이밍 규칙은 대규모 환경에서 운영 효율을 크게 높인다. ## DHCP 옵션 세트와 DNS ### DHCP 옵션 세트 VPC 내 인스턴스가 네트워크에 합류할 때 `TCP/IP` 설정을 자동으로 구성하는 것이 DHCP(Dynamic Host Configuration Protocol) 옵션 세트다. 기본적으로 AWS는 VPC CIDR의 +2 주소(예: `10.0.0.2`)를 DNS 서버로 제공한다. 하이브리드 환경에서는 온프레미스의 Active Directory 도메인 컨트롤러를 DNS 서버로 지정해야 할 수 있다. 이 경우 커스텀 DHCP 옵션 세트를 구성하여, 인스턴스가 사내 도메인 이름을 올바르게 해석하도록 설정한다. DHCP 옵션 세트에서 구성할 수 있는 항목은 다음과 같다. | 항목 | 설명 | 기본값 | | :--- | :--- | :--- | | `domain-name` | 인스턴스의 FQDN 접미사 | `ec2.internal` (us-east-1) | | `domain-name-servers` | DNS 서버 IP | `AmazonProvidedDNS` | | `ntp-servers` | 시간 동기화 서버 | Amazon Time Sync Service | | `netbios-name-servers` | NetBIOS 이름 서버 | 없음 | | `netbios-node-type` | NetBIOS 노드 유형 | 없음 | 주의할 점은 DHCP 옵션 세트는 생성 후 수정할 수 없다는 것이다. 변경이 필요하면 새로운 옵션 세트를 만들어 VPC에 연결해야 하며, 기존 인스턴스는 DHCP 갱신 주기(보통 1시간)에 맞춰 새 설정을 적용받는다. ### Route 53 Resolver와 프라이빗 DNS VPC 내부에서의 DNS 해석에는 Route 53 Resolver가 핵심 역할을 한다. `enableDnsSupport`를 `true`로 설정하면 VPC의 +2 주소에서 DNS 질의를 처리하고, `enableDnsHostnames`를 `true`로 설정하면 각 인스턴스에 퍼블릭 DNS 호스트 이름이 자동 할당된다. 하이브리드 환경에서는 Route 53 Resolver의 인바운드·아웃바운드 엔드포인트를 구성하여, VPC와 온프레미스 DNS 서버 간의 양방향 DNS 질의 전달(*forwarding*)을 설정할 수 있다. 이를 통해 온프레미스 애플리케이션이 VPC 내부의 프라이빗 리소스 이름을 해석하고, VPC 내 인스턴스가 온프레미스 도메인 이름을 해석하는 양방향 이름 해석이 가능해진다. ## 정리 VPC와 서브넷의 설계는 클라우드 아키텍처의 가장 기본이자, 한 번 잘못 설계하면 수정 비용이 가장 큰 영역이다. 핵심 원칙을 요약하면 다음과 같다. 첫째, CIDR은 충분히 크게, 서브넷은 체계적으로 나눈다. 둘째, 최소 2개 이상의 AZ에 서브넷을 분산하여 고가용성을 확보한다. 셋째, 3계층 아키텍처로 네트워크 수준의 격리를 구현한다. 넷째, IPAM으로 IP 주소를 중앙 관리하여 주소 충돌을 방지한다. 서브넷이 준비되면, 다음 단계는 트래픽이 서브넷 사이와 외부 세계로 어떻게 흐르는지를 제어하는 [[VPC 라우팅과 게이트웨이|라우팅과 게이트웨이]]를 이해하는 것이다. --- ## 출처 - Amazon Web Services (2026) *How Amazon VPC works.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html - Amazon Web Services (2026) *VPC CIDR blocks.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html - Amazon Web Services (2026) *DHCP option sets in Amazon VPC.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html - Stratus10 (2025) *Unleashing the Power of 3-Tier Network Architecture.* Available at: https://stratus10.com/blog/aws-best-practices-components-3-tier-architecture - Amazon Web Services (2026) *What is IPAM?* Available at: https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html