TestForge Blog
← 전체 포스트
#cloud #aws #vpc #network #architecture

AWS VPC 설계 기본 가이드 - 서브넷, 라우팅, NAT, 보안그룹까지

AWS 환경을 처음 설계할 때 반드시 알아야 할 VPC 기본기. 퍼블릭/프라이빗 서브넷, 라우팅 테이블, NAT Gateway, Internet Gateway, 보안그룹과 NACL까지 실무 관점으로 정리합니다.

TestForge Team ·

왜 VPC 설계가 중요한가

AWS에서 애플리케이션을 운영할 때 VPC는 모든 네트워크의 출발점입니다.

초기 설계를 대충 하면 나중에 이런 문제가 반복됩니다.

  • 서브넷 구성이 꼬여서 서비스 분리가 안 됨
  • NAT 비용이 예상보다 크게 증가
  • 보안그룹 규칙이 복잡해져 장애 원인 추적이 어려움
  • 멀티 AZ 확장 시 라우팅 구성이 비효율적임

VPC는 한 번 만들고 끝나는 자원이 아니라, 서비스 성장에 따라 계속 확장되는 기반입니다.

가장 먼저 정해야 할 것

설계 전에 아래 질문에 답해야 합니다.

  • 서비스가 단일 리전인지, 멀티 리전인지
  • 인터넷 공개 자원이 무엇인지
  • DB와 내부 API를 외부에서 완전히 차단할지
  • VPC Peering, Transit Gateway, VPN 연결 계획이 있는지
  • EKS, ECS, EC2 중 어떤 워크로드를 주로 운영할지

이 질문에 따라 CIDR 대역과 서브넷 개수가 달라집니다.

권장하는 기본 구조

가장 일반적인 실무 구조는 아래와 같습니다.

VPC (10.0.0.0/16)
├─ Public Subnet A   (10.0.1.0/24)
├─ Public Subnet B   (10.0.2.0/24)
├─ Private App A     (10.0.11.0/24)
├─ Private App B     (10.0.12.0/24)
├─ Private Data A    (10.0.21.0/24)
└─ Private Data B    (10.0.22.0/24)

역할은 명확하게 분리합니다.

  • Public Subnet: ALB, Bastion, NAT Gateway
  • Private App Subnet: API 서버, 워커, EKS Node
  • Private Data Subnet: RDS, ElastiCache, 내부 데이터 계층

이 구조의 장점은 애플리케이션과 데이터 계층을 분리하기 쉽고, 보안정책도 계층별로 나누기 좋다는 점입니다.

퍼블릭 서브넷과 프라이빗 서브넷 차이

핵심 차이는 Internet Gateway로 직접 나갈 수 있느냐입니다.

퍼블릭 서브넷:

  • 라우팅 테이블에 0.0.0.0/0 -> Internet Gateway
  • 퍼블릭 IP를 가진 리소스는 외부와 직접 통신 가능

프라이빗 서브넷:

  • 외부로 직접 나가지 않음
  • 필요 시 0.0.0.0/0 -> NAT Gateway
  • 외부에서 직접 접근 불가

운영 서버와 DB는 기본적으로 프라이빗 서브넷에 두는 것이 안전합니다.

라우팅 테이블 설계 원칙

서브넷이 많아질수록 라우팅 테이블을 무분별하게 늘리지 않는 것이 중요합니다.

권장 원칙:

  • Public Subnet용 라우팅 테이블 1개
  • App Private Subnet용 라우팅 테이블 1개
  • Data Private Subnet용 라우팅 테이블 1개

예시:

Public RT
- 10.0.0.0/16 local
- 0.0.0.0/0 igw-xxxx

Private App RT
- 10.0.0.0/16 local
- 0.0.0.0/0 nat-xxxx

Private Data RT
- 10.0.0.0/16 local

Data 서브넷은 인터넷 아웃바운드가 정말 필요한지부터 검토해야 합니다. 패치나 패키지 다운로드가 필요 없다면 NAT를 거치지 않게 두는 편이 더 안전합니다.

NAT Gateway를 어떻게 배치할까

많이 나오는 질문이 “NAT Gateway를 AZ마다 둘까, 하나만 둘까”입니다.

선택 기준은 아래와 같습니다.

  • 비용 우선: NAT Gateway 1개
  • 가용성 우선: AZ별 NAT Gateway 1개씩

실무에서는 운영 서비스라면 보통 AZ별로 분산합니다. NAT 하나에 장애가 나면 해당 프라이빗 서브넷 전체 아웃바운드가 막히기 때문입니다.

주의할 점:

  • 다른 AZ의 NAT를 타면 Cross-AZ 데이터 비용이 발생할 수 있음
  • EKS나 대규모 워커 환경에서는 NAT 비용이 생각보다 커질 수 있음

그래서 S3, DynamoDB 같은 서비스는 VPC Endpoint로 우회하는 것이 좋습니다.

보안그룹과 NACL은 어떻게 나눌까

많은 팀이 보안그룹만 써도 되는데 NACL까지 복잡하게 만듭니다.

권장 기준:

  • 보안그룹: 기본 접근제어의 중심
  • NACL: 특별한 네트워크 차단 정책이 있을 때만 사용

예시:

ALB SG
- Inbound: 80, 443 from 0.0.0.0/0
- Outbound: 8080 to App SG

App SG
- Inbound: 8080 from ALB SG
- Outbound: 5432 to DB SG
- Outbound: 443 to external APIs

DB SG
- Inbound: 5432 from App SG

IP 기반 허용보다 보안그룹 간 참조를 우선하면 운영이 훨씬 단순해집니다.

VPC Endpoint는 초기에 고려하자

AWS 서비스 접근을 모두 NAT Gateway로 우회하면 비용도 늘고 보안성도 떨어집니다.

대표적으로 초기에 고려할 만한 Endpoint:

  • S3 Gateway Endpoint
  • DynamoDB Gateway Endpoint
  • ECR Interface Endpoint
  • Secrets Manager Interface Endpoint
  • CloudWatch Logs Interface Endpoint
  • STS Interface Endpoint

EKS를 운영한다면 ECR, STS, CloudWatch Logs Endpoint 유무가 네트워크 비용과 안정성에 직접 영향을 줍니다.

실무에서 자주 하는 실수

1. CIDR 대역을 너무 작게 잡는 경우

처음엔 /24면 충분해 보여도, 서브넷 분리와 확장을 반복하다 보면 금방 부족해집니다. 가능하면 VPC는 /16 또는 충분히 여유 있는 대역으로 시작하는 편이 낫습니다.

2. 데이터 계층을 퍼블릭에 두는 경우

RDS를 퍼블릭 접근 가능하게 두는 것은 정말 특별한 사유가 아니면 피해야 합니다.

3. 보안그룹 인바운드를 광범위하게 여는 경우

0.0.0.0/0 허용은 ALB 같은 공개 진입점에만 제한적으로 사용해야 합니다.

4. NAT 비용을 예측하지 않는 경우

이미지 다운로드, 로그 전송, 외부 API 호출이 많은 환경은 NAT 비용이 크게 나옵니다.

추천 설계 순서

아래 순서로 설계하면 실패 확률이 낮습니다.

  1. VPC CIDR 결정
  2. AZ 개수 결정
  3. 서브넷 역할 분리
  4. 라우팅 테이블 설계
  5. 보안그룹 정책 수립
  6. NAT 및 VPC Endpoint 비용 검토
  7. 운영 접속 방식 결정

마무리

AWS VPC 설계의 핵심은 기능보다 경계를 먼저 정하는 것입니다.

  • 무엇을 외부에 공개할지
  • 무엇을 내부에 격리할지
  • 어떤 경로로만 통신을 허용할지

이 기준이 명확하면 이후의 EKS, RDS, CI/CD, 보안 설계까지 훨씬 쉬워집니다.

초기 서비스라면 단순하게 시작하되, 멀티 AZ와 계층 분리만큼은 처음부터 고려하는 것이 가장 좋은 투자입니다.