서브넷 관리 정책

AWS & GCP 2026. 4. 26. 16:12

1. 개요

서브넷(Subnet)은 Virtual Private Cloud(VPC) 내에서 IP 주소 범위를 논리적으로 분할한 네트워크 단위입니다. 서브넷 관리 정책은 보안, 운영 효율성, 확장성에 직접적인 영향을 미치므로 클라우드 인프라 설계의 핵심 요소 중 하나입니다.

서브넷은 단순히 IP를 나누는 행위가 아니라, 트래픽 흐름을 통제하고 보안 경계를 정의하는 아키텍처 결정입니다. 어떤 방식으로 서브넷을 설계하느냐에 따라 보안 침해 시 피해 범위, 서비스 확장 비용, 운영팀의 부담이 크게 달라집니다.

2. 주요 서브넷 관리 방식

2-1. Public / Private 구분 방식

가장 기본적인 방식으로, 인터넷 접근 여부에 따라 서브넷을 두 종류로 분류합니다.

구성 방식:

Public Subnet: 인터넷 게이트웨이(IGW)와 연결되어 외부 인터넷과 통신 가능합니다. ALB, NAT 게이트웨이 등이 배치됩니다.
Private Subnet: 인터넷에 직접 노출되지 않으며, NAT 게이트웨이를 통해 아웃바운드만 허용합니다. 애플리케이션 서버, DB 등이 배치됩니다.

장점:

구성이 단순하고 관리가 쉽습니다.
기본적인 보안 경계를 확보할 수 있습니다.
AWS Well-Architected Framework의 기본 권장 구조에 부합합니다.
소규모~중규모 서비스에 적합합니다.

단점:

같은 Private 서브넷 내 서비스들이 서로 접근 가능하여 서비스 간 격리가 어렵습니다.
세밀한 네트워크 수준의 격리가 불가능합니다.
서비스 규모가 커질수록 서브넷 내 IP 소진 문제가 발생할 수 있습니다.

Public/Private 서브넷 구성도 — 2개의 가용 영역에 걸쳐 Public 서브넷(NAT Gateway, Load Balancer)과 Private 서브넷(애플리케이션 서버)이 구성된 VPC 아키텍처 (출처: AWS 공식 문서)

권장 IPv4 서브넷 설계 패턴 — Public, Private, Spare 서브넷으로 구성된 AWS VPC 서브넷 레이아웃 (출처: AWS Architecture Blog)

2-2. 서비스별(기능별) 서브넷 방식

각 서비스 또는 기능별로 독립적인 서브넷을 할당하는 방식으로, 마이크로서비스 아키텍처나 SaaS 멀티테넌트 환경에서 주로 활용됩니다.

구성 방식:

서비스 A 전용 서브넷, 서비스 B 전용 서브넷 등 목적별로 서브넷을 분리합니다.
예시: ALB 서브넷(/28), 애플리케이션 서버 서브넷(/24), DB 서브넷(/26)으로 계층을 세분화합니다.
SaaS 환경에서는 테넌트별 서브넷(Subnet Silo)으로 격리하기도 합니다.

장점:

서비스 간 블라스트 반경(Blast Radius)을 최소화할 수 있습니다.
세밀한 네트워크 ACL 정책을 서비스별로 적용할 수 있습니다.
보안 침해 발생 시 영향 범위를 제한할 수 있습니다.
서비스별 트래픽 모니터링이 용이합니다.

단점:

서비스 증가에 따라 서브넷 관리 복잡도가 급격히 상승합니다.
대규모 멀티테넌트 환경에서는 관리가 매우 어려워집니다.
VPC CIDR 소진 위험이 높아집니다.
운영팀에 높은 수준의 네트워크 전문성이 요구됩니다.

서비스별(Subnet Silo) 격리 구성도 — 테넌트 또는 서비스별로 독립 서브넷을 할당하는 Subnet Silo Isolation 아키텍처 (출처: AWS SaaS Tenant Isolation Strategies)

마이크로서비스 Silo 격리 패턴 — 서비스 단위로 격리된 마이크로서비스 사일로 아키텍처 (출처: AWS SaaS Tenant Isolation Strategies)

2-3. 하이브리드(계층형) 방식

Public/Private 구분과 서비스별 분리를 조합한 방식으로, 계층(Tier)별로 서브넷을 구성합니다. 현실에서 가장 널리 사용되는 방식입니다.

구성 방식:

Presentation Layer: Public 서브넷 (ALB, CloudFront 오리진 등)
Application Layer: Private 서브넷 (WAS, Fargate, Lambda)
Data Layer: Isolated 서브넷 (RDS, ElastiCache, OpenSearch 등)
민감도가 높은 서비스는 별도 VPC로 분리하여 추가 격리합니다.

장점:

보안과 운영 편의성의 균형을 맞출 수 있습니다.
데이터 민감도에 따른 단계적 격리가 가능합니다.
AWS Well-Architected Framework의 고급 권장 구조에 부합합니다.
장애 폭발 반경을 계층 단위로 최소화할 수 있습니다.

단점:

초기 설계 시 충분한 CIDR 계획이 필요합니다.
레이어 간 통신 정책 수립과 지속적인 관리가 필요합니다.
단순 Public/Private 방식보다 초기 설계 비용이 높습니다.

하이브리드(계층형) 서브넷 구성도 — Public 서브넷(웹 서버/ALB), Private 서브넷(애플리케이션), Isolated 서브넷(데이터베이스)의 3계층 VPC 아키텍처 (출처: AWS 공식 문서)

2-4. 허브-스포크(Hub-Spoke) 토폴로지

앞선 세 가지 방식이 단일 VPC 내 서브넷 구성에 관한 것이라면, 허브-스포크는 복수 VPC 또는 계정을 연결하는 네트워크 토폴로지입니다. 조직 규모가 커지고 멀티 계정 환경이 필요해질 때 하이브리드(계층형) 방식의 자연스러운 확장 형태입니다.

구성 방식:

Hub VPC (중앙 허브): 조직 공통 서비스를 배치합니다.
- 중앙 방화벽 / Egress 게이트웨이 (AWS Network Firewall, 3rd-party NGFW)
- DNS 해석기 (Route 53 Resolver)
- 모니터링 / 로깅 / 감사 서비스
- Direct Connect / VPN 연결 엔드포인트
Spoke VPC (개별 서비스/팀 VPC): 서비스, 팀, 환경(dev/prod)별로 독립적인 VPC를 운영합니다.
- 각 Spoke VPC 내부는 계층형 또는 서비스별 서브넷으로 구성합니다.
- 모든 이그레스 트래픽은 Hub VPC를 경유하여 통제됩니다.
연결 수단: AWS Transit Gateway(TGW)가 Hub ↔ Spoke 간 통신의 핵심 라우터 역할을 합니다.

장점:

방화벽 정책, 이그레스 통제, DNS 등을 Hub에서 중앙 관리하여 보안 일관성을 보장합니다.
Spoke VPC를 독립적으로 추가·제거할 수 있어 조직 성장에 유연하게 대응합니다.
NAT Gateway 등 공유 리소스를 Hub에 집중하여 비용을 절감합니다.
침해 발생 시 Spoke 단위로 격리하여 블라스트 반경(Blast Radius)을 VPC 경계로 최소화합니다.

단점:

Hub가 단일 장애점(SPOF)이 될 수 있으므로 Multi-AZ 고가용성 설계가 필수입니다.
Transit Gateway 데이터 처리 비용이 추가됩니다.
Hub의 대역폭 및 처리량 한계를 사전에 계획해야 합니다.
초기 설계와 구현이 단일 VPC 방식보다 복잡합니다.

AWS Transit Gateway 허브-스포크 아키텍처 — Hub VPC와 여러 Spoke VPC가 Transit Gateway를 통해 연결되는 구성도 (출처: AWS VPC Connectivity Options 백서)

3. 방식 비교 요약

구분	Public/Private 구분	서비스별 서브넷	하이브리드(계층형)	허브-스포크
격리 단위	서브넷	서브넷	서브넷(계층)	VPC
보안 격리 수준	낮음	높음	중간~높음	매우 높음
관리 복잡도	낮음	높음	중간	높음
확장성	중간	낮음 (CIDR 소진)	높음	매우 높음
적합한 서비스 규모	소~중규모	소~중규모	중~대규모	대규모~엔터프라이즈
멀티테넌트 적합성	부적합	소규모 한정	적합	매우 적합
WAF 정렬도	기본 권장	부분 권장	고급 권장	엔터프라이즈 권장

4. 클라우드 제공사별 Well-Architected Framework

AWS의 Well-Architected Framework와 같이, GCP, Azure, Oracle OCI, IBM 등 주요 클라우드 제공사도 각자의 아키텍처 검토 프레임워크를 운영하고 있습니다. Pillar 수, 네트워킹 철학, 고유 강조점이 제공사마다 다릅니다.

4-1. 전체 비교

항목	AWS	GCP	Azure	Oracle OCI	IBM Cloud
프레임워크명	Well-Architected Framework	Cloud Architecture Framework	Well-Architected Framework	Well-Architected Framework	Well-Architected Framework
Pillar 수	6개	6개	5개	5개	6개
고유 Pillar	Sustainability	Sustainability	(없음)	Distributed Cloud	Portable and Hybrid
자체 평가 도구	AWS Well-Architected Tool	—	Azure Well-Architected Review	—	—
네트워크 격리 단위	Subnet (VPC)	Subnet + Service Account (VPC)	Subnet + NSG (VNet)	Subnet (VCN)	Subnet (VPC)
서브넷 전략 기조	계층 분리 강조	통합 서브넷 권장	Segment·Filter·Transform	DB 특화 격리	하이브리드 일관성 강조

4-2. AWS — Well-Architected Framework

6개 핵심 원칙:

운영 우수성(Operational Excellence): 워크로드 실행·모니터링과 지속적인 개선 프로세스
보안(Security): 데이터, 시스템, 자산 보호 및 위험 관리
안정성(Reliability): 장애 복구 및 수요 변화에 대응하는 능력
성능 효율성(Performance Efficiency): 컴퓨팅 자원의 효율적 사용
비용 최적화(Cost Optimization): 최저 비용으로 비즈니스 가치 실현
지속 가능성(Sustainability): 환경적 영향 최소화

서브넷 관련 주요 섹션:

Security Pillar

SEC05: Protect your network resources
- SEC05-BP01: Create network layers — 위험 레벨: HIGH
  - 데이터 민감도와 접근 요구사항에 따라 네트워크 토폴로지를 세분화해야 합니다.
  - 공개 엔드포인트는 ALB/CloudFront/API Gateway를 활용하고, 컴퓨팅 자원은 Private 서브넷에 배치합니다.
- SEC05-BP02: Control traffic at all layers
- SEC05-BP03: Automate network protection
- SEC05-BP04: Implement inspection and protection

Reliability Pillar

REL02: Plan your network topology
- REL02-BP01: Use highly available network connectivity
- REL02-BP02: Provision redundant connectivity
- REL02-BP03: Ensure IP subnet allocation accounts for expansion and availability — 위험 레벨: MEDIUM
  - 서브넷 CIDR은 미래 성장을 고려하여 넉넉하게 설계해야 합니다.
  - 가장 큰 VPC CIDR: /16, 가장 작은 VPC CIDR: /28입니다.
  - 안티패턴: CIDR 너무 작게 설계, ELB IP 소모량 과소 추정, IP 소비량 모니터링 부재

추가로 참고하면 좋은 AWS 관련 문서

문서	핵심 내용
Building Scalable and Secure Multi-VPC Network Infrastructure	Transit Gateway, VPC Sharing, Multi-Account 구조 설계 지침
SaaS Tenant Isolation Strategies	멀티테넌트 환경에서 서브넷 격리 전략 (Subnet Silo, Pooled, Hybrid)
Amazon VPC IP Address Manager (IPAM)	대규모 계정의 CIDR 중앙 관리 방법
EKS Best Practices: VPC and Subnet Considerations	컨테이너 환경에서의 서브넷 설계 (Prefix Delegation 등)
AWS Security Maturity Model: Network Segmentation	보안 성숙도 단계별 VPC/서브넷 설계 가이드

4-3. GCP — Cloud Architecture Framework

6개 핵심 원칙:

운영 우수성(Operational Excellence): CloudOps 기반 워크로드 실행·모니터링·자동화
보안·개인정보·컴플라이언스(Security, Privacy, and Compliance): Zero Trust 구현, AI 보안, 규제 준수
안정성(Reliability): 수평 확장, 페일오버 설계, 포스트모템
비용 최적화(Cost Optimization): 비용 인식 문화, 지속 최적화
성능 최적화(Performance Optimization): 탄력성 활용, 모듈형 설계
지속 가능성(Sustainability): 저탄소 리전 사용, AI/ML 워크로드 최적화

서브넷/네트워킹 핵심 권장사항:

Custom mode VPC: 프로덕션 환경에서는 auto mode 대신 custom mode를 사용하여 IP 주소 관리 체계를 온프레미스와 통합합니다.
통합 서브넷 전략: GCP는 소프트웨어 정의 네트워킹 특성상 서브넷 수가 라우팅 동작에 직접 영향을 주지 않으므로, 관련 애플리케이션을 더 적고 넓은 서브넷으로 통합하는 방식을 권장합니다.
Shared VPC: 멀티팀 조직에서는 단일 호스트 프로젝트의 Shared VPC를 사용하며, 서비스 프로젝트는 비-네트워크 리소스만 관리합니다.
NCC 허브-스포크: 하이브리드 환경에서는 Network Connectivity Center를 허브로 두고 모든 스포크를 연결합니다.
서비스 계정 기반 격리: 서브넷 경계보다 서비스 계정(Service Account)/태그로 방화벽 규칙을 적용하는 방식을 강조합니다.

AWS와의 핵심 차이: AWS는 서브넷 계층 분리로 격리를 실현하지만, GCP는 서비스 계정/태그 기반 정책으로 더 세밀한 제어를 구현합니다. 서브넷 수를 줄이고 정책 레이어를 강화하는 방향이 권장됩니다.

관련 문서	링크
Google Cloud Architecture Framework	docs.cloud.google.com/architecture/framework
VPC 설계 모범 사례	docs.cloud.google.com/architecture/best-practices-vpc-design
네트워킹 랜딩존 설계	cloud.google.com/architecture/framework/system-design/networking

4-4. Azure — Well-Architected Framework

5개 핵심 원칙:

안정성(Reliability): 비즈니스 요구사항, 복원력, 복구 설계
보안(Security): 기밀성·무결성·가용성 보호
비용 최적화(Cost Optimization): 사용량 최적화, 낭비 제거
운영 우수성(Operational Excellence): 포괄적 모니터링, 안전한 배포 관행
성능 효율성(Performance Efficiency): 수평 확장, 부하 테스트

서브넷/네트워킹 핵심 권장사항 (SE:06):

3대 전략: Segment(서브넷 격리로 방어 깊이 구현), Filter(NSG/방화벽으로 트래픽 검증), Transform(TLS 재협상 등 패킷 변환)
NSG(Network Security Group): 서브넷 또는 NIC 레벨에 적용하는 L3/L4 방화벽으로 AWS의 Security Group + NACL 역할을 통합합니다.
Hub-Spoke 토폴로지: Azure Firewall을 중앙 이그레스 게이트웨이로 배치합니다.
Private Endpoint: PaaS 서비스에 프라이빗 IP를 부여하여 VNet 내에서만 통신하도록 구성합니다.
Azure Bastion: 퍼블릭 IP 없이 브라우저 기반 SSH/RDP를 제공합니다.
Application Security Group(ASG): 서브넷 재설계 없이 태그 기반으로 트래픽 규칙을 그룹화할 수 있습니다.

AWS와의 핵심 차이: NSG는 서브넷 레벨 적용이 강조됩니다. ASG는 AWS에 없는 개념으로 태그 기반 트래픽 규칙 그룹화를 지원합니다. Azure Private Endpoint는 AWS PrivateLink에 대응합니다.

관련 문서	링크
Azure Well-Architected Framework	learn.microsoft.com/azure/well-architected
Security: Networking 전략	learn.microsoft.com/.../security/networking
Virtual Network 모범 사례	learn.microsoft.com/.../service-guides/virtual-network
Azure Well-Architected Review	assessments/azure-architecture-review

4-5. Oracle OCI — Well-Architected Framework

5개 핵심 원칙:

보안 및 컴플라이언스(Security and Compliance): VCN 네트워크 보안, 데이터 보호, 모니터링
안정성 및 복원력(Reliability and Resilience): 내결함성 네트워크 아키텍처, DR 전략
성능 및 비용 최적화(Performance and Cost Optimization): 컴퓨팅 사이징, 네트워크 모니터링·튜닝
운영 효율성(Operational Efficiency): 배포 전략, 워크로드 모니터링
분산 클라우드(Distributed Cloud): 온프레미스·멀티클라우드 통합, 컴플라이언스·소버린티

서브넷/네트워킹 핵심 권장사항:

VCN(Virtual Cloud Network) 기반 서브넷 설계: AWS의 VPC에 해당합니다.
VCN 설계, Security List/NSG 전략, 로드 밸런서 구성, FastConnect(Direct Connect 대응) 하이브리드 연결이 핵심 역할입니다.
DB 워크로드 특화 격리: Oracle DB, Autonomous DB를 위한 전용 서브넷 설계가 강조됩니다.

AWS와의 핵심 차이: Sustainability Pillar 대신 Distributed Cloud를 5번째 Pillar로 가집니다. 엔터프라이즈 DB 워크로드 격리에 강점이 있으며, OCI의 Security List는 AWS의 NACL에 대응합니다.

관련 문서	링크
OCI Well-Architected Framework	docs.oracle.com/solutions/oci-best-practices

4-6. IBM Cloud — Well-Architected Framework

6개 핵심 원칙 (IBM 고유: Portable and Hybrid 포함):

보안 및 컴플라이언스(Security and Compliance): 기밀성·무결성·가용성, 하이브리드 환경 위협 대응
성능 및 확장성(Performance & Scalability): 응답 시간, 처리량, 유기적 부하 수용
운영 우수성(Operational Excellence): 클라우드 운영 효율화, 자동화
안정성(Reliability): 장애 복구, 지속적 가용성
재무 운영 및 지속 가능성(FinOps and Sustainability): 비용·자원 효율성, 크로스 팀 재무 정렬
포터블 및 하이브리드(Portable and Hybrid): 퍼블릭·프라이빗 클라우드·온프레미스 간 워크로드 이식성

서브넷/네트워킹 핵심 권장사항:

퍼블릭·프라이빗·온프레미스 환경에 일관된 네트워크 정책을 적용하는 것이 최우선 원칙입니다.
IBM Cloud Satellite를 활용하여 분산 환경 전반의 서브넷 정책을 통일합니다.
특정 제공사의 고유 기능에 종속되지 않도록 이식 가능한 서브넷 설계를 유지합니다.

AWS와의 핵심 차이: Portable and Hybrid Pillar는 IBM 고유의 원칙입니다. AWS가 클라우드 네이티브를 강조하는 반면, IBM은 기존 온프레미스 자산과의 통합을 핵심으로 봅니다.

관련 문서	링크
IBM Well-Architected Framework	ibm.com/think/architectures/well-architected
Security and Compliance Pillar	ibm.com/.../well-architected/security

5. 상황별 추천 전략

섹션 2의 서브넷 관리 방식과 섹션 4의 클라우드별 프레임워크를 교차하면, 다음과 같이 상황별 최적 전략을 도출할 수 있습니다.

5-1. 서브넷 관리 방식 선택 기준

상황	권장 방식	참조 프레임워크
클라우드 초기 도입, 소규모 팀	Public/Private 구분	AWS WAF 기본 / Azure Reliability
금융·의료 등 규제 준수 필요	서비스별 서브넷 (부분 적용)	AWS SEC05-BP01 / Azure SE:06
마이크로서비스 + 데이터 파이프라인 복합 운영	하이브리드(계층형)	AWS SEC05 + REL02 / GCP Security Pillar
SaaS 멀티테넌트 (소규모 테넌트)	서비스별 서브넷 (Subnet Silo)	AWS SaaS Isolation / Oracle OCI Security
온프레미스 연동 하이브리드 클라우드	하이브리드(계층형) + 허브-스포크	GCP NCC / Azure Hub-Spoke / IBM Portable & Hybrid
멀티클라우드 이식성 중시	하이브리드(계층형) + 표준 설계	IBM Portable and Hybrid Pillar
DB 중심 엔터프라이즈 워크로드	서비스별 서브넷 (DB 전용 격리)	Oracle OCI WAF / AWS RDS 서브넷 격리
보안 감사·Well-Architected Review 준비	하이브리드(계층형)	AWS WAF Tool / Azure Well-Architected Review

5-2. 클라우드 제공사별 서브넷 전략 요약

AWS를 사용하는 경우

서브넷 계층 분리(Presentation → Application → Data)를 기본으로 설계합니다.
SEC05-BP01(네트워크 레이어 생성)과 REL02-BP03(CIDR 여유 확보)을 반드시 충족해야 합니다.
멀티 계정 환경에서는 Transit Gateway + IPAM으로 CIDR을 중앙 관리합니다.
초기에는 Public/Private 구분으로 시작하고, 서비스가 복잡해지면 하이브리드(계층형)으로 전환합니다.

GCP를 사용하는 경우

AWS처럼 서브넷을 세분화하지 않고, 관련 워크로드를 더 넓은 서브넷으로 통합하는 방향이 권장됩니다.
격리가 필요한 경우 추가 서브넷보다 서비스 계정(Service Account)/태그 기반 방화벽 정책으로 구현합니다.
멀티팀 환경에서는 Shared VPC 단일 호스트 프로젝트를 사용합니다.

Azure를 사용하는 경우

Segment(서브넷) → Filter(NSG) → Transform(TLS) 3단계 방어 전략을 서브넷 설계의 기준으로 삼습니다.
모든 서브넷에 NSG를 적용하고, Hub-Spoke 토폴로지에서 Azure Firewall을 중앙 이그레스로 사용합니다.
PaaS 서비스는 Public Endpoint 대신 Private Endpoint로 VNet에 통합합니다.

Oracle OCI를 사용하는 경우

VCN 기반 서브넷 설계에서 DB·미션 크리티컬 워크로드는 전용 서브넷으로 격리합니다.
Security List(NACL 대응)와 NSG를 함께 활용하여 계층적 방어를 구성합니다.
Distributed Cloud Pillar를 고려하여 멀티 사이트·소버린 요구사항을 서브넷 설계에 반영합니다.

IBM Cloud를 사용하는 경우

퍼블릭·프라이빗·온프레미스 환경에 일관된 서브넷 정책을 적용하는 것이 최우선 원칙입니다.
특정 제공사의 고유 기능에 종속되지 않도록 이식 가능한 서브넷 설계를 유지합니다.
Portable and Hybrid Pillar를 기준으로 서브넷 설계의 이식성을 정기적으로 검토합니다.

5-3. 진화 경로 (Evolution Path)

대부분의 조직은 아래 순서로 서브넷 전략을 발전시키는 것이 현실적입니다.

[1단계] Public/Private 구분
  → 빠른 시작, 소규모 서비스
  → 참조: AWS WAF 기본 / Azure Reliability Pillar

[2단계] 하이브리드(계층형)
  → 서비스 복잡도 증가, 보안 요구 강화
  → 참조: AWS SEC05 + REL02 / GCP Security Pillar / Azure SE:06

[3단계] 서비스별 서브넷 (부분 적용)
  → 특정 고위험 서비스(결제, 인증, DB)에 선택 적용
  → 참조: AWS SaaS Isolation / Oracle OCI Security / Azure NSG 세분화

[4단계] 멀티 계정 + 허브-스포크 + IPAM
  → 대규모 조직, 멀티클라우드, 규제 준수
  → 참조: AWS Control Tower + Transit Gateway / GCP NCC / IBM Portable & Hybrid

핵심 원칙: 서비스별 서브넷 방식을 전체에 적용하기보다, 하이브리드(계층형)을 기반으로 두고 보안 민감 서비스에만 선택적으로 더 세밀한 격리를 추가하는 방식이 운영 부담과 보안 수준의 최적 균형점입니다.

5-4. 단계별 구성 예시 (Terraform)

각 진화 단계별로 실제 AWS 환경에서 구성할 수 있는 Terraform 코드 예시와 아키텍처 다이어그램을 제공합니다. 각 단계는 이전 단계를 기반으로 점진적으로 확장됩니다.

Stage 1 — Public/Private 기본 분리

단순한 VPC에 Public 서브넷과 Private 서브넷을 분리하는 최소 구성입니다. NAT Gateway를 통해 Private 서브넷의 아웃바운드 트래픽을 허용합니다.

variable "vpc_cidr" { default = "10.0.0.0/16" }
variable "region"   { default = "ap-northeast-2" }

locals {
  public_cidr  = "10.0.0.0/24"
  private_cidr = "10.0.1.0/24"
  az           = "${var.region}a"
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "stage1-vpc" }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = local.public_cidr
  availability_zone       = local.az
  map_public_ip_on_launch = true
  tags                    = { Name = "stage1-public" }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.private_cidr
  availability_zone = local.az
  tags              = { Name = "stage1-private" }
}

resource "aws_eip" "nat" { domain = "vpc" }

resource "aws_nat_gateway" "ngw" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
  depends_on    = [aws_internet_gateway.igw]
  tags          = { Name = "stage1-ngw" }
}

# Public 라우트: 인터넷 직접 연결
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "rt-public" }
}

# Private 라우트: NAT 경유 아웃바운드
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ngw.id
  }
  tags = { Name = "rt-private" }
}

resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}

Stage 2 — 하이브리드(계층형) 3계층 구성

Presentation(Public) → Application(Private) → Data(Isolated) 3계층으로 분리합니다. Data 계층은 라우트 테이블에 기본 경로를 추가하지 않아 인터넷 접근을 차단하며, NACL로 Application 계층에서만 접근 가능하도록 제한합니다.

locals {
  vpc_cidr = "10.1.0.0/16"
  az       = "ap-northeast-2a"
  cidrs = {
    presentation = "10.1.0.0/24"  # Public — ALB, CloudFront 오리진
    application  = "10.1.1.0/24"  # Private — WAS, API 서버
    data         = "10.1.2.0/24"  # Isolated — RDS, ElastiCache
  }
}

resource "aws_vpc" "main" {
  cidr_block           = local.vpc_cidr
  enable_dns_hostnames = true
  tags                 = { Name = "stage2-vpc" }
}

resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.main.id }
resource "aws_eip" "nat" { domain = "vpc" }

resource "aws_nat_gateway" "ngw" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.presentation.id
  depends_on    = [aws_internet_gateway.igw]
}

resource "aws_subnet" "presentation" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = local.cidrs.presentation
  availability_zone       = local.az
  map_public_ip_on_launch = true
  tags                    = { Name = "stage2-presentation" }
}

resource "aws_subnet" "application" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.cidrs.application
  availability_zone = local.az
  tags              = { Name = "stage2-application" }
}

resource "aws_subnet" "data" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.cidrs.data
  availability_zone = local.az
  tags              = { Name = "stage2-data" }
}

resource "aws_route_table" "presentation" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = { Name = "rt-presentation" }
}

resource "aws_route_table" "application" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ngw.id
  }
  tags = { Name = "rt-application" }
}

# Data 계층: 기본 경로 없음 — 인터넷 완전 차단
resource "aws_route_table" "data" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "rt-data-isolated" }
}

resource "aws_route_table_association" "presentation" {
  subnet_id      = aws_subnet.presentation.id
  route_table_id = aws_route_table.presentation.id
}
resource "aws_route_table_association" "application" {
  subnet_id      = aws_subnet.application.id
  route_table_id = aws_route_table.application.id
}
resource "aws_route_table_association" "data" {
  subnet_id      = aws_subnet.data.id
  route_table_id = aws_route_table.data.id
}

# NACL: Data 계층은 Application 서브넷에서만 인바운드 허용
resource "aws_network_acl" "data" {
  vpc_id     = aws_vpc.main.id
  subnet_ids = [aws_subnet.data.id]

  ingress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = local.cidrs.application
    from_port  = 0
    to_port    = 65535
  }
  egress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = local.cidrs.application
    from_port  = 1024
    to_port    = 65535
  }
  tags = { Name = "nacl-data-isolated" }
}

Stage 3 — 서비스별 서브넷 부분 적용

2단계 기반 위에 결제(Payment), 인증(Auth) 등 고위험 서비스의 서브넷을 추가로 분리합니다. 각 서비스 전용 NACL을 적용해 필요한 포트만 허용합니다.

# 2단계 리소스를 기반으로 서비스 전용 서브넷만 추가 정의
locals {
  service_cidrs = {
    payment = "10.1.10.0/24"  # PCI-DSS 범위 격리
    auth    = "10.1.11.0/24"  # 인증 서비스 격리
  }
  # application_cidr: 2단계에서 정의된 "10.1.1.0/24"
  application_cidr = "10.1.1.0/24"
}

resource "aws_subnet" "payment" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.service_cidrs.payment
  availability_zone = "ap-northeast-2c"
  tags = {
    Name       = "stage3-payment"
    Compliance = "PCI-DSS"
  }
}

resource "aws_subnet" "auth" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = local.service_cidrs.auth
  availability_zone = "ap-northeast-2c"
  tags = { Name = "stage3-auth" }
}

resource "aws_route_table" "payment" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ngw.id
  }
  tags = { Name = "rt-payment" }
}

resource "aws_route_table" "auth" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ngw.id
  }
  tags = { Name = "rt-auth" }
}

resource "aws_route_table_association" "payment" {
  subnet_id      = aws_subnet.payment.id
  route_table_id = aws_route_table.payment.id
}
resource "aws_route_table_association" "auth" {
  subnet_id      = aws_subnet.auth.id
  route_table_id = aws_route_table.auth.id
}

# Payment NACL: Application 서브넷에서 443 포트만 허용
resource "aws_network_acl" "payment" {
  vpc_id     = aws_vpc.main.id
  subnet_ids = [aws_subnet.payment.id]

  ingress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = local.application_cidr
    from_port  = 443
    to_port    = 443
  }
  egress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
  tags = { Name = "nacl-payment" }
}

# Auth NACL: Application 서브넷에서 8080, Data 서브넷으로 DB 접근만 허용
resource "aws_network_acl" "auth" {
  vpc_id     = aws_vpc.main.id
  subnet_ids = [aws_subnet.auth.id]

  ingress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = local.application_cidr
    from_port  = 8080
    to_port    = 8080
  }
  egress {
    rule_no    = 100
    protocol   = "tcp"
    action     = "allow"
    cidr_block = "10.1.2.0/24"  # Data 서브넷 (RDS)
    from_port  = 5432
    to_port    = 5432
  }
  tags = { Name = "nacl-auth" }
}

Stage 4 — 멀티 계정 + 허브-스포크 + IPAM

Transit Gateway로 Hub VPC와 Spoke VPC를 연결하고, IPAM으로 조직 전체의 CIDR을 중앙 관리합니다. 각 Spoke VPC는 IPAM 풀에서 CIDR을 자동 할당받아 주소 충돌을 방지합니다.

AWS Transit Gateway 허브-스포크 아키텍처 — Hub VPC와 여러 Spoke VPC가 Transit Gateway를 통해 연결되는 구성도 (출처: AWS VPC Connectivity Options 백서)

AWS VPC IPAM — 조직 전체의 IP 주소를 루트 풀, 리전 풀, 팀 풀로 계층적으로 관리하는 구조도 (출처: AWS 공식 문서)

AWS Control Tower Multi-Account 랜딩존 — OU 단위로 계정을 구조화하고 보안/로그/샌드박스 계정을 분리하는 Control Tower 아키텍처 (출처: AWS 공식 문서)

# IPAM: 조직 전체 IP 주소 풀 중앙 관리
resource "aws_vpc_ipam" "org" {
  operating_regions {
    region_name = "ap-northeast-2"
  }
  tags = { Name = "org-ipam" }
}

resource "aws_vpc_ipam_pool" "root" {
  address_family = "ipv4"
  ipam_scope_id  = aws_vpc_ipam.org.private_default_scope_id
  tags           = { Name = "ipam-root-pool" }
}

resource "aws_vpc_ipam_pool_cidr" "root" {
  ipam_pool_id = aws_vpc_ipam_pool.root.id
  cidr         = "10.0.0.0/8"  # 전체 조직 할당 범위
}

# 리전 풀: 리전별 CIDR 범위 위임
resource "aws_vpc_ipam_pool" "regional" {
  address_family      = "ipv4"
  ipam_scope_id       = aws_vpc_ipam.org.private_default_scope_id
  source_ipam_pool_id = aws_vpc_ipam_pool.root.id
  locale              = "ap-northeast-2"
  tags                = { Name = "ipam-apne2-pool" }
}

resource "aws_vpc_ipam_pool_cidr" "regional" {
  ipam_pool_id = aws_vpc_ipam_pool.regional.id
  cidr         = "10.100.0.0/14"  # 리전 전용 범위
}

# Hub VPC: 공유 서비스, Egress, Inspection
resource "aws_vpc" "hub" {
  ipv4_ipam_pool_id   = aws_vpc_ipam_pool.regional.id
  ipv4_netmask_length = 22  # IPAM에서 /22 자동 할당
  tags                = { Name = "hub-vpc", Role = "hub" }
}

resource "aws_subnet" "hub_transit" {
  vpc_id            = aws_vpc.hub.id
  cidr_block        = cidrsubnet(aws_vpc.hub.cidr_block, 2, 0)
  availability_zone = "ap-northeast-2a"
  tags              = { Name = "hub-transit-attach" }
}

# Spoke-A VPC: 서비스/팀 계정
resource "aws_vpc" "spoke_a" {
  ipv4_ipam_pool_id   = aws_vpc_ipam_pool.regional.id
  ipv4_netmask_length = 22
  tags                = { Name = "spoke-a-vpc", Role = "spoke" }
}

resource "aws_subnet" "spoke_a_app" {
  vpc_id            = aws_vpc.spoke_a.id
  cidr_block        = cidrsubnet(aws_vpc.spoke_a.cidr_block, 2, 0)
  availability_zone = "ap-northeast-2a"
  tags              = { Name = "spoke-a-app" }
}

# Transit Gateway: 허브-스포크 연결 중심
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Org Transit Gateway"
  auto_accept_shared_attachments  = "enable"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  tags                            = { Name = "org-tgw" }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "hub" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.hub.id
  subnet_ids         = [aws_subnet.hub_transit.id]
  tags               = { Name = "tgw-attach-hub" }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "spoke_a" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.spoke_a.id
  subnet_ids         = [aws_subnet.spoke_a_app.id]
  tags               = { Name = "tgw-attach-spoke-a" }
}

# Spoke-A: 모든 이그레스를 TGW(Hub 경유) 로 라우팅
resource "aws_route_table" "spoke_a_egress" {
  vpc_id = aws_vpc.spoke_a.id
  route {
    cidr_block         = "0.0.0.0/0"
    transit_gateway_id = aws_ec2_transit_gateway.main.id
  }
  tags = { Name = "spoke-a-rt-via-tgw" }
}

resource "aws_route_table_association" "spoke_a_app" {
  subnet_id      = aws_subnet.spoke_a_app.id
  route_table_id = aws_route_table.spoke_a_egress.id
}

6. 실제 기업 사례

Netflix

Netflix는 AWS로 마이그레이션 완료(2016년) 이후 기능별 서브넷 분리 + 다중 리전 전략을 채택하고 있습니다.

External ELBs 전용 서브넷: 외부 로드 밸런서를 별도 서브넷으로 분리하여 ELB 스케일링 시 인스턴스와 IP 경쟁이 발생하지 않도록 설계했습니다.
External Instances 서브넷: 외부 접근이 필요한 인스턴스를 별도 운영합니다.
Internal Instances 서브넷: 내부 통신용 인스턴스를 격리하여 운영합니다.
VPC Flow Logs를 Hyper Scale로 수집·분석하는 별도 데이터 파이프라인을 구축하여 서브넷 간 트래픽 이상 징후를 실시간으로 탐지합니다.
컨테이너 관리 플랫폼(Titus)과 마이크로서비스 아키텍처에 맞춰 서브넷을 유연하게 확장할 수 있는 구조를 유지하고 있습니다.

AWS 엔터프라이즈 패턴 (Control Tower 기반)

대규모 기업 고객들이 채택하는 Multi-Account + 계층형 서브넷 방식입니다.

Security OU: Log Archive, Audit 전용 계정에 격리된 VPC를 배치합니다.
Sandbox OU: 개발자 실험용 공유 서브넷을 운영합니다.
Production OU: Transit Gateway를 통한 허브-스포크 네트워크를 구성하고, 계층형 서브넷으로 운영합니다.
AWS VPC IP Address Manager(IPAM)를 통해 수백 개 계정의 CIDR을 중앙에서 관리합니다.

일반 엔터프라이즈 통계

적절한 서브넷 세그먼테이션을 적용한 조직은 측면 이동(Lateral Movement) 공격이 58% 감소했습니다.
보안 인시던트 봉쇄 속도가 미적용 조직 대비 73% 향상되었습니다.

7. 참고 자료

저작자표시 (새창열림)

ABOUT ME

불곰 불곰

1. 개요

2. 주요 서브넷 관리 방식

2-1. Public / Private 구분 방식

2-2. 서비스별(기능별) 서브넷 방식

2-3. 하이브리드(계층형) 방식

2-4. 허브-스포크(Hub-Spoke) 토폴로지

3. 방식 비교 요약

4. 클라우드 제공사별 Well-Architected Framework

4-1. 전체 비교

4-2. AWS — Well-Architected Framework

4-3. GCP — Cloud Architecture Framework

4-4. Azure — Well-Architected Framework

4-5. Oracle OCI — Well-Architected Framework

4-6. IBM Cloud — Well-Architected Framework

5. 상황별 추천 전략

5-1. 서브넷 관리 방식 선택 기준

5-2. 클라우드 제공사별 서브넷 전략 요약

5-3. 진화 경로 (Evolution Path)

5-4. 단계별 구성 예시 (Terraform)

Stage 1 — Public/Private 기본 분리

Stage 2 — 하이브리드(계층형) 3계층 구성

Stage 3 — 서비스별 서브넷 부분 적용

Stage 4 — 멀티 계정 + 허브-스포크 + IPAM

6. 실제 기업 사례

Netflix

AWS 엔터프라이즈 패턴 (Control Tower 기반)

일반 엔터프라이즈 통계

7. 참고 자료

티스토리툴바

ABOUT ME

1. 개요

2. 주요 서브넷 관리 방식

2-1. Public / Private 구분 방식

2-2. 서비스별(기능별) 서브넷 방식

2-3. 하이브리드(계층형) 방식

2-4. 허브-스포크(Hub-Spoke) 토폴로지

3. 방식 비교 요약

4. 클라우드 제공사별 Well-Architected Framework

4-1. 전체 비교

4-2. AWS — Well-Architected Framework

4-3. GCP — Cloud Architecture Framework

4-4. Azure — Well-Architected Framework

4-5. Oracle OCI — Well-Architected Framework

4-6. IBM Cloud — Well-Architected Framework

5. 상황별 추천 전략

5-1. 서브넷 관리 방식 선택 기준

5-2. 클라우드 제공사별 서브넷 전략 요약

5-3. 진화 경로 (Evolution Path)

5-4. 단계별 구성 예시 (Terraform)

Stage 1 — Public/Private 기본 분리

Stage 2 — 하이브리드(계층형) 3계층 구성

Stage 3 — 서비스별 서브넷 부분 적용

Stage 4 — 멀티 계정 + 허브-스포크 + IPAM

6. 실제 기업 사례

Netflix

AWS 엔터프라이즈 패턴 (Control Tower 기반)

일반 엔터프라이즈 통계

7. 참고 자료

관련글 관련글 더보기

티스토리툴바