AWS VPC 구성

개요

AWS에서 웹 서버를 구성할 때 흔히 퍼블릭 서브넷과 프라이빗 서브넷을 나눠 웹서비스를 운영합니다. 이 때, 아래와 같은 장점이 있습니다.

• 웹 서버가 인터넷에 직접 노출되지 않아 보안성 확보
• 내부 EC2는 외부로의 패치 또는 API 호출만 안전하게 수행

따라서, 본 포스팅을 통해 VPC 요소들의 역할과 트래픽 흐름을 살펴보고, 라우팅 테이블 구성 방법을 살펴봅니다.

인프라 구성도

인바운드 트래픽 흐름

1. 클라이언트가 my-alb-xxxx.elb.amazonaws.com (ALB의 DNS 이름)으로 접속
2. DNS 조회를 통해 AWS 관리 퍼블릭 IP 중 하나를 할당받아 IGW → ALB로 전달
3. ALB는 리스너(HTTP/HTTPS) 설정에 따라 프라이빗 서브넷의 EC2로 요청 포워딩
4. EC2는 퍼블릭 IP 없이도 ALB의 보안 그룹 규칙으로부터 인바운드를 허용받아 응답

포인트: ALB에는 고정 EIP를 붙이지 않고, AWS가 관리하는 동적 퍼블릭 IP 풀과 DNS 이름을 사용합니다.

아웃바운드 트래픽 흐름

1. 프라이빗 EC2의 라우팅 테이블에

0.0.0.0/0 → nat-xxxxxxxx (NAT Gateway)

1. NAT Gateway (퍼블릭 서브넷, EIP 부여)에서 SNAT 처리
2. NAT Gateway가 배치된 퍼블릭 서브넷의 라우팅 테이블에

0.0.0.0/0 → igw-xxxxxxxx (Internet Gateway)

1. IGW를 통해 외부(패치 서버, 외부 API)로 트래픽 송출

포인트:

• 프라이빗 EC2는 퍼블릭 IP 없이도 외부와 통신 가능
• NAT Gateway에는 반드시 Elastic IP가 필요하며, 이를 통해 공인 IP로 변환 후 IGW로 전달합니다.

Internet Gateway(IGW)의 역할

• VPC와 인터넷 간에 트래픽을 주고받는 단일 관문
• 퍼블릭 서브넷의 라우팅 테이블(0.0.0.0/0 → igw-…)에 연결되어야만 퍼블릭 자원이 인터넷과 통신 가능
• NAT Gateway, ALB 등 퍼블릭 리소스도 모두 IGW를 통해 외부와 송수신

라우팅 테이블 구성

• cccr-rt-public
  • 대상: 0.0.0.0/0 → igw-xxxx
  • 연관 서브넷: 퍼블릭 서브넷 1, 퍼블릭 서브넷 2
  • 이유:
    1. 퍼블릭 서브넷 모두 같은 인터넷 경로를 갖도록 일관성 유지
    2. AZ 이중화 시 어느 AZ의 퍼블릭 리소스든 인터넷 접근 보장
    3. 서브넷 추가 시 라우팅 재설정 불필요 → 관리 효율성 ↑
• cccr-rt-private
  • 대상: 0.0.0.0/0 → nat-xxxx
  • 연관 서브넷: 프라이빗 서브넷 1, 프라이빗 서브넷 2

EIP 필요 여부 정리

리소스	EIP 할당 가능/필요 여부	비고
NAT Gateway	필수 (직접 할당 또는 자동)	퍼블릭 IP로 SNAT 처리 위해 필요
ALB	불가 (동적 퍼블릭 IP + DNS 사용)	고정 IP 필요 시 NLB 사용 권장
Bastion Host	선택(Elastic IP 할당 추천)	관리 편의·IP 고정 목적

결론

• 퍼블릭·프라이빗 서브넷 설계를 통해 보안과 가용성을 모두 확보
• IGW, NAT GW, ALB의 역할을 명확히 이해하고 라우팅 테이블을 일관되게 구성
• 운영 중 서브넷 추가·AZ 확장 시에도 손쉽게 확장 가능