해외 SaaS 기업이 AWS로 이전한 지 3개월 만에 심각한 보안 사고를 겪었습니다. RDS 데이터베이스 인스턴스가 공용 서브넷에 잘못 배치되었고 보안 그룹 규칙이 너무 관대하여 데이터베이스 포트가 공용 네트워크에 노출되었고, 이로 인해 데이터 유출 위험 경고가 발생했습니다.
이러한 상황은 해외 클라우드 마이그레이션을 초기 단계에 있는 기업에서 흔히 발생합니다. 많은 팀이 마이그레이션을 완료하는 데만 급급하여 VPC 네트워크 아키텍처에 대한 이해가 "일단 작동만 하면 된다"는 수준에 그치는 경우가 많아, 향후 보안 및 운영 유지 관리에 있어 숨겨진 위험을 초래합니다.
VPC(가상 사설 클라우드)는 AWS의 모든 리소스를 위한 네트워크 기반입니다. 이 글에서는 핵심 개념부터 실제 구성까지 VPC의 기반을 탄탄히 다지는 데 도움을 드립니다.
AWS VPC란 무엇인가요?
VPC는 AWS 클라우드 내의 전용 가상 네트워크 환경입니다. 물리적 하드웨어를 구매하지 않고도 마치 자체 데이터 센터의 네트워크를 관리하는 것처럼 네트워크의 IP 주소 범위, 서브넷팅, 라우팅 규칙 및 네트워크 보안 정책을 완벽하게 제어할 수 있습니다.
각 AWS 계정은 리소스 시작 속도를 높이기 위해 각 리전에 기본 VPC를 자동으로 생성합니다. 하지만 프로덕션 환경에서는 보다 세밀한 제어를 위해 사용자 지정 VPC를 생성하는 것이 좋습니다.
VPC의 핵심 구성 요소
| 구성 요소 | 효과 |
|---|---|
| CIDR 블록 | VPC에 사용할 IP 주소 범위를 정의합니다(예: 10.0.0.0/16). |
| 서브넷 | VPC를 더 작은 네트워크 세그먼트로 나누고 이를 서로 다른 가용 영역에 분산시킵니다. |
| 경로 테이블 | 서브넷 내 트래픽에 대한 전달 규칙 |
| 인터넷 게이트웨이(IGW) | 공용 서브넷이 인터넷과 통신할 수 있도록 허용합니다. |
| NAT 게이트웨이 | 사설 서브넷이 인터넷에 접속할 수 있도록 허용하되, 허가되지 않은 외부 접속은 차단합니다. |
| 보안 그룹 | 인스턴스 수준의 가상 방화벽은 인바운드/아웃바운드 트래픽을 제어합니다. |
| 네트워크 ACL(NACL) | 서브넷 수준 방화벽은 추가적인 접근 제어 계층을 제공합니다. |
서브넷팅: 공용 서브넷 vs. 사설 서브넷
적절한 서브넷팅은 VPC 아키텍처 설계에서 가장 중요하고 첫 번째 단계입니다.
공개 서브넷
공용 서브넷은 라우팅 테이블에 인터넷 게이트웨이(IGW)를 가리키는 경로가 포함된 서브넷입니다. 공용 서브넷에 있는 리소스는 공용 IP 주소를 가질 수 있으며 인터넷과 직접 통신할 수 있습니다.
공용 서브넷에 배치하기에 적합한 리소스:
- 애플리케이션 로드 밸런싱(ALB/ELB)
- NAT 게이트웨이
- 바스티온 호스트
- 인터넷에 직접 연결되는 웹 서버가 필요합니다(특수 시나리오).
개인 서브넷
프라이빗 서브넷의 라우팅 테이블에는 IGW(인터페이스 게이트웨이)로 가는 직접 경로가 포함되어 있지 않으므로, 프라이빗 서브넷 내의 리소스는 인터넷에서 직접 접근할 수 없습니다. 프라이빗 서브넷 내에서 인터넷에 접근해야 하는 리소스(예: 소프트웨어 패키지 다운로드 또는 외부 API 호출)는 NAT 게이트웨이를 거쳐야 합니다.
프라이빗 서브넷에 배치하기에 적합한 리소스:
- 애플리케이션 서버(EC2 인스턴스)
- 데이터베이스(RDS, Aurora, ElastiCache)
- 내부 API 서비스
- 일괄 처리 작업
표준 3계층 아키텍처 다이어그램
인터넷 ↓ [공용 서브넷] — 로드 밸런서(ALB) ↓ [프라이빗 서브넷] — 애플리케이션 서버(EC2) ↓ [프라이빗 서브넷] — 데이터베이스(RDS)
이러한 계층형 아키텍처는 데이터베이스 및 애플리케이션 서버가 공용 네트워크에 직접 노출되지 않도록 보장하여 공격 표면을 크게 줄입니다.
다중 AZ 계획
프로덕션 환경에서는 최소 두 개 이상의 가용 영역에 서브넷을 배포해야 합니다. AWS 가용 영역은 서로 독립적인 물리적 데이터 센터이며, 여러 가용 영역에 배포하면 단일 가용 영역에 장애가 발생하더라도 서비스 연속성을 보장할 수 있습니다.
권장 서브넷 계획 (ap-northeast-1 도쿄 지역을 예로 들면):
| 서브넷 이름 | CIDR | 가용성 영역 | 유형 |
|---|---|---|---|
| 공용 서브넷 1a | 10.0.1.0/24 | ap-북동-1a | 공공의 |
| 공용 서브넷 1c | 10.0.2.0/24 | ap-북동-1c | 공공의 |
| 개인 앱 1a | 10.0.11.0/24 | ap-북동-1a | 사적인 |
| 개인 앱 1c | 10.0.12.0/24 | ap-북동-1c | 사적인 |
| 개인 데이터베이스 1a | 10.0.21.0/24 | ap-북동-1a | 사적인 |
| 개인-db-1c | 10.0.22.0/24 | ap-북동-1c | 사적인 |
라우팅 테이블 구성
각 서브넷은 라우팅 테이블과 연결되어야 합니다. 라우팅 테이블은 해당 서브넷 내의 트래픽이 어떻게 전달되는지를 결정합니다.
공용 서브넷 라우팅 테이블
공용 서브넷 라우팅 테이블에는 두 개의 코어 경로가 포함되어야 합니다.
첫 번째 경로는 VPC의 CIDR 블록(예: 10.0.0.0/16)을 대상으로 하는 로컬 경로입니다. 대상은 "로컬"입니다. 이 경로는 AWS에서 자동으로 추가되며 VPC 내의 리소스들이 서로 통신할 수 있도록 합니다.
두 번째 경로는 목적지가 0.0.0.0/0(모든 트래픽)이고 인터넷 게이트웨이(igw-xxxxxxxx)를 가리키는 인터넷 경로입니다. 이 경로를 통해 공용 서브넷의 리소스가 인터넷에 액세스하고 인터넷으로부터 액세스될 수 있습니다.
개인 서브넷 라우팅 테이블
프라이빗 서브넷의 라우팅 테이블에는 로컬 경로(자동으로 생성됨)가 포함되어 있지만, IGW(인터페이스 게이트웨이)로의 직접 경로는 포함되어 있지 않습니다. 프라이빗 서브넷의 리소스가 인터넷에 액세스해야 하는 경우 NAT 게이트웨이를 가리키는 0.0.0.0/0 경로를 추가해야 합니다.
중요 사항NAT 게이트웨이 자체는 공용 서브넷에 배포되어야 하며 탄력적 IP(EIP)를 가져야 합니다. 단일 장애 지점을 방지하기 위해 각 가용 영역은 독립적인 NAT 게이트웨이를 배포해야 합니다.
보안 그룹 구성 모범 사례
보안 그룹은 AWS에서 가장 일반적으로 사용되는 네트워크 보안 제어 방법입니다. 인스턴스 수준에서 작동하며 상태 저장 방화벽(인바운드 트래픽은 허용하고 리턴 트래픽은 자동으로 허용)입니다.
최소 권한의 원칙
보안 그룹 구성의 핵심 원칙은 필요한 포트만 열고 필요한 소스만 허용하는 것입니다.
반례(위험한 구성):
| 유형 | 규약 | 포트 | 원천 |
|---|---|---|---|
| 역에 진입하며 | TCP | 22 (SSH) | 0.0.0.0/0 |
| 역에 진입하며 | TCP | 3306 (MySQL) | 0.0.0.0/0 |
| 역에 진입하며 | 모든 교통 | 모두 | 0.0.0.0/0 |
위 설정은 SSH 및 데이터베이스 포트를 전 세계 모든 IP 주소에 노출시키므로 매우 위험합니다.
긍정적인 예시 (권장 구성):
애플리케이션 서버 보안 그룹:
| 유형 | 규약 | 포트 | 원천 |
|---|---|---|---|
| 역에 진입하며 | TCP | 80/443 | ALB 안전 그룹 ID |
| 역에 진입하며 | TCP | 22 | Bastion 호스트 보안 그룹 ID |
| 출구 | 모두 | 모두 | 0.0.0.0/0 |
데이터베이스 보안 그룹:
| 유형 | 규약 | 포트 | 원천 |
|---|---|---|---|
| 역에 진입하며 | TCP | 3306 | 애플리케이션 서버 보안 그룹 ID |
| 출구 | 모두 | 모두 | 0.0.0.0/0 |
IP 주소 대신 보안 그룹 ID를 사용하여 서로를 참조하면 EC2 인스턴스의 IP 주소가 변경되더라도 보안 규칙이 계속 유효하게 유지됩니다.
보안 그룹과 네트워크 ACL의 차이점
| 특성 | 보안 그룹 | 네트워크 ACL |
|---|---|---|
| 적용 범위 | 인스턴스 수준 | 서브넷 수준 |
| 상태 유형 | 주에서 | 무국적자 |
| 규칙 유형 | 규칙만 허용 | 허용 및 거부 규칙 |
| 규칙 순서 | 순서가 지정되지 않음 (합의를 취함) | 순서대로 정렬됨 (번호로 일치) |
| 적용 가능한 시나리오 | 일상적인 접근 제어 | 추가 보안 계층/긴급 봉쇄 |
대부분의 시나리오에서는 보안 그룹으로 충분합니다. 네트워크 ACL은 특정 IP 범위를 명시적으로 차단해야 하는 시나리오(예: 알려진 악성 IP 차단) 또는 추가적인 규정 준수 감사 계층을 추가해야 하는 시나리오에 주로 사용됩니다.
VPC 피어링 및 트랜짓 게이트웨이
기업의 사업이 확장되어 여러 VPC(예: 개발, 테스트 및 운영 환경이 서로 다른 VPC에 위치) 간의 네트워크 연결을 구축해야 하는 경우, 주요 솔루션은 두 가지입니다.
VPC 피어링
두 VPC 간에 일대일 사설 네트워크 연결이 설정되며, 트래픽이 인터넷을 거치지 않으므로 지연 시간이 짧고 비용이 절감됩니다.
적합한 시나리오: 간단한 피어 투 피어 연결이 필요한 소수의 VPC(3개 이하).
제한 사항: VPC 피어링은 전이적 라우팅을 지원하지 않습니다. 즉, A와 B 또는 B와 C 간의 피어링이 있다고 해서 A가 C에 액세스할 수 있는 것은 아닙니다.
트랜짓 게이트웨이
Transit Gateway는 AWS에서 제공하는 네트워크 허브 서비스로, 여러 VPC와 온프레미스 네트워크를 동일한 중앙 노드에 연결하여 완전 상호 연결 또는 제어된 상호 연결을 가능하게 합니다.
적합한 시나리오: VPC 수가 많은 기업(4개 이상), 하이브리드 클라우드(온프레미스 데이터 센터 + 클라우드) 환경, 라우팅 정책의 중앙 집중식 관리가 필요한 기업.
VPC 구성 시 흔히 발생하는 오류와 이를 방지하는 방법
해외 기업의 클라우드 마이그레이션을 지원하면서 얻은 경험을 바탕으로 가장 흔한 VPC 구성 오류는 다음과 같습니다.
오류 1: 데이터베이스가 공용 서브넷에 있습니다.
많은 초보자들이 RDS를 공용 서브넷에 배치하고 쉽게 접속할 수 있도록 공개적으로 액세스 가능하게 합니다. 하지만 올바른 방법은 RDS를 항상 프라이빗 서브넷에 배치하고 배스천 호스트 또는 AWS Systems Manager 세션 관리자를 통해 유지 관리 액세스하는 것입니다.
오류 2: 프로덕션 환경에서 기본 VPC를 사용하고 있습니다.
기본 VPC의 보안 그룹 및 라우팅 구성이 너무 관대하여 모든 서브넷이 퍼블릭입니다. 프로덕션 환경에서는 사용자 지정 VPC를 사용해야 합니다.
오류 3: NAT 게이트웨이가 하나만 배포되었습니다.
NAT 게이트웨이가 하나의 가용 영역(AZ)에만 배포된 경우, 해당 AZ에 장애가 발생하면 모든 프라이빗 서브넷에서 나가는 트래픽이 중단됩니다. 고가용성 아키텍처를 위해서는 각 가용 영역에 독립적인 NAT 게이트웨이가 있어야 합니다.
오류 4: VPC 스트림 로그 무시
VPC 흐름 로그는 VPC로 들어오고 나가는 모든 네트워크 트래픽을 기록하므로 보안 감사 및 문제 해결에 중요한 도구입니다. VPC 설정 시점부터 흐름 로깅을 활성화하고 CloudWatch Logs 또는 S3에 출력하는 것이 좋습니다.
요약: VPC 아키텍처 설계의 핵심 원칙
견고한 AWS VPC 아키텍처는 다음 원칙을 따라야 합니다.
- 심층 수비공용 서브넷 + 개인 애플리케이션 서브넷 + 개인 데이터베이스 서브넷, 3계층 격리.
- 최소 권한보안 그룹은 필요한 포트만 열고, 소스는 보안 그룹 ID까지 지정합니다.
- 고가용성최소 두 개 이상의 가용 영역에 배포되며, 각 가용 영역에 대해 독립적인 NAT 게이트웨이가 있습니다.
- 주목할 만한VPC 스트리밍 로그를 활성화하고 CloudWatch 모니터링 및 알림을 통합합니다.
- 맞춤 제작 선호기본 VPC는 프로덕션 환경에서 사용해서는 안 됩니다.
VPC는 AWS 아키텍처의 핵심입니다. 사전에 제대로 계획하면 나중에 시간과 노력을 절약할 수 있습니다. 기업의 AWS 클라우드 아키텍처를 계획 중이거나 기존 VPC 구성에 보안 취약점이 있는 경우, 무료 클라우드 아키텍처 평가를 위해 저희에게 문의해 주세요.
→ AWS 아키텍처 무료 평가를 요청하세요:aws-oncloudai.com/contact
이 글은 aws-oncloudai.com의 클라우드 아키텍처 팀에서 작성했습니다. 저희 팀은 해외 진출을 계획하는 중국 기업들을 대상으로 AWS 클라우드 서비스 컨설팅, 아키텍처 설계 및 비용 최적화 서비스를 제공하는 데 주력하고 있습니다.
