VPC(Virtual Private Cloud) 내에서 Public Subnet과 Private Subnet을 분리하여 안전한 네트워크 아키텍처를 구성하는 방법. 웹 서버는 외부에 노출하고, 데이터베이스는 내부에만 접근 가능하도록 설계하는 전형적인 3-Tier 아키텍처의 기본 패턴
구성 요소
VPC (Virtual Private Cloud)
AWS에서 논리적으로 격리된 네트워크 공간. 사설 IP 대역(예: 10.0.0.0/16)을 할당받아 그 안에 서브넷들을 생성하여 리소스를 배치. VPC는 기본적으로 외부와 완전히 격리되어 있으며, 인터넷 게이트웨이나 NAT 게이트웨이를 연결해야만 외부 통신 가능
Availability Zone (AZ)
AWS 리전 내의 물리적으로 분리된 데이터센터 그룹. 각 AZ는 독립적인 전원, 네트워크, 냉각 시스템을 가지고 있어서 한 AZ에 장애가 발생해도 다른 AZ는 정상 동작. 고가용성을 위해 최소 2개 이상의 AZ에 리소스를 분산 배치하는 것이 권장되며, 그림에서도 2개 AZ를 사용하고 있음
Public Subnet (공개 서브넷)
특징
인터넷 게이트웨이(Internet Gateway)가 연결된 서브넷으로, 외부 인터넷과 직접 통신 가능. 이 서브넷에 배치된 EC2 인스턴스는 퍼블릭 IP 주소를 할당받을 수 있으며, 사용자가 인터넷을 통해 직접 접속 가능. 라우팅 테이블에 0.0.0.0/0 → Internet Gateway 경로가 설정되어 있어서, 모든 외부 트래픽이 인터넷 게이트웨이로 향함
EC2 인스턴스 배치
Public Subnet에는 주로 웹 서버, API 서버, Bastion Host 같이 외부에서 접근해야 하는 리소스를 배치. 각 인스턴스는 보안 그룹으로 보호되며, 필요한 포트만 선택적으로 열어둠. 예를 들어 웹 서버는 80(HTTP), 443(HTTPS) 포트를 외부에 개방하고, SSH 접근을 위한 22번 포트는 특정 IP에만 허용하는 방식
다중 AZ 배치
고가용성을 위해 2개 이상의 AZ에 걸쳐 Public Subnet을 생성하고, 각 서브넷에 EC2 인스턴스를 배치. 앞단에 로드밸런서(ALB 또는 NLB)를 두면, 한 AZ에 장애가 발생해도 다른 AZ의 인스턴스가 트래픽을 처리하여 서비스 중단 방지. 로드밸런서 자체도 다중 AZ에 분산되어 있어서 단일 장애점(SPOF)이 없음
Private Subnet (비공개 서브넷)
특징
인터넷 게이트웨이가 연결되지 않은 서브넷으로, 외부에서 직접 접근 불가능. 라우팅 테이블에 인터넷으로 향하는 경로가 없거나, NAT Gateway를 통해서만 외부 접근이 가능하도록 설정됨. 데이터베이스나 캐시 서버처럼 외부 노출이 필요 없는 백엔드 리소스를 배치하여 보안 강화
RDS 배치
Private Subnet에 RDS(Relational Database Service) 인스턴스를 배치하면, 인터넷에서 직접 데이터베이스에 접근할 수 없어서 보안이 크게 향상됨. RDS는 VPC 내부에서만 접근 가능한 프라이빗 IP 주소만 가지며, 같은 VPC 내의 EC2 인스턴스나 Lambda 함수 등에서만 연결 가능. 외부에서 데이터베이스를 직접 공격할 수 없으므로, SQL Injection 같은 공격의 리스크가 줄어듦
DB Subnet Group
RDS를 생성할 때는 최소 2개 이상의 AZ에 걸친 Private Subnet으로 구성된 DB Subnet Group이 필요. RDS는 Multi-AZ 배포 옵션을 사용하면 Primary 인스턴스와 Standby 인스턴스가 서로 다른 AZ에 생성되어, 장애 발생 시 자동으로 Failover됨. 이때 각 인스턴스가 다른 AZ의 Private Subnet에 배치되므로, 물리적 장애에도 데이터베이스 가용성이 유지됨
Security Group (보안 그룹)
개념
인스턴스 레벨의 가상 방화벽으로, 인바운드(들어오는)와 아웃바운드(나가는) 트래픽을 제어. 네트워크 ACL과 달리 상태 기반(Stateful)으로 동작하여, 허용된 인바운드 트래픽에 대한 응답은 자동으로 허용됨. 각 EC2 인스턴스나 RDS 인스턴스는 하나 이상의 보안 그룹에 연결되며, 보안 그룹의 규칙에 따라 트래픽이 허용 또는 차단됨
EC2 보안 그룹 설정
Public Subnet의 EC2 웹 서버라면, 인바운드 규칙에서 80, 443 포트를 0.0.0.0/0(모든 IP)에 개방하여 인터넷 사용자들이 접근할 수 있도록 설정. SSH 접근을 위한 22번 포트는 회사 IP나 VPN IP 같은 특정 IP 대역으로만 제한하는 것이 안전. 아웃바운드는 기본적으로 모든 트래픽을 허용하지만, 보안을 더 강화하려면 필요한 대상과 포트만 명시적으로 허용 가능
일반적인 웹 서버 인바운드 규칙:
- HTTP: 포트 80, 소스 0.0.0.0/0 (모든 인터넷)
- HTTPS: 포트 443, 소스 0.0.0.0/0
- SSH: 포트 22, 소스 관리자 IP만 (예: 203.0.113.0/24)
RDS 보안 그룹 설정
Private Subnet의 RDS는 EC2의 보안 그룹만 소스로 허용하는 인바운드 규칙을 설정. 예를 들어 MySQL RDS라면 3306 포트에 대해 "EC2 웹 서버의 보안 그룹"을 소스로 지정하면, 해당 보안 그룹에 속한 EC2 인스턴스에서만 데이터베이스 접근 가능. IP 주소 대신 보안 그룹 ID를 소스로 사용하면, EC2 인스턴스가 늘어나거나 IP가 바뀌어도 규칙을 수정할 필요가 없어서 관리가 편함
RDS 인바운드 규칙 예시:
- Type: MySQL/Aurora
- Protocol: TCP
- Port: 3306
- Source: sg-xxxxx (EC2 웹 서버의 보안 그룹 ID)
네트워크 통신 흐름
사용자 → EC2 (인터넷 접근)
사용자가 웹 브라우저에서 도메인이나 EC2의 퍼블릭 IP로 접속하면, 트래픽은 인터넷 게이트웨이를 거쳐 Public Subnet의 EC2 인스턴스에 도달. 이때 EC2 보안 그룹의 인바운드 규칙에서 80 또는 443 포트가 허용되어 있어야 접속 가능. 로드밸런서를 사용하는 경우, 사용자 트래픽은 먼저 로드밸런서에 도착하고, 로드밸런서가 백엔드의 EC2 인스턴스들에게 트래픽을 분산
트래픽 경로:
사용자 브라우저
→ 인터넷
→ Route 53 (DNS 조회)
→ 로드밸런서 또는 EC2 퍼블릭 IP
→ 인터넷 게이트웨이
→ VPC 라우팅 테이블
→ Public Subnet
→ EC2 보안 그룹 검사
→ EC2 인스턴스EC2 → RDS (내부 통신)
EC2 인스턴스에서 애플리케이션이 데이터베이스에 연결할 때는, RDS의 프라이빗 엔드포인트 주소를 사용하여 VPC 내부 네트워크로만 통신. RDS 엔드포인트는 mydb.abc123.ap-northeast-2.rds.amazonaws.com 같은 형태이며, 이 주소는 Private Subnet 내의 프라이빗 IP로 해석됨. 트래픽은 인터넷 게이트웨이를 거치지 않고 VPC 내부에서만 라우팅되므로 빠르고 안전
트래픽 경로:
EC2 인스턴스 (애플리케이션)
→ VPC 내부 라우팅
→ Private Subnet
→ RDS 보안 그룹 검사
→ RDS 인스턴스이 과정에서 RDS 보안 그룹은 소스가 EC2의 보안 그룹인지 확인하고, 맞으면 연결을 허용. 만약 외부 IP에서 RDS로 직접 접근하려고 하면, Private Subnet이므로 라우팅 자체가 불가능하고, 설령 도달한다 해도 보안 그룹에서 차단됨
