Isolation
외부에 노출하면 안 되는 서버를 분리하기 어렵습니다
애플리케이션 서버와 데이터베이스는 인터넷에서 직접 접근할 수 없어야 하지만, 업데이트 다운로드 같은 아웃바운드 통신은 필요합니다. 계층별로 접근 경로를 나누지 않으면 보안 요구사항과 운영 요구사항을 함께 맞추기 어렵습니다.
Amazon Virtual Private Cloud (Amazon VPC) · 가상 네트워크
Amazon VPC는 사용자가 정의한 논리적으로 격리된 가상 네트워크입니다. 기존 데이터 센터에서 운영하던 네트워크와 비슷한 구조를 AWS 인프라 위에서 구성합니다. VPC 자체에는 추가 요금이 없고, NAT 게이트웨이 같은 일부 구성 요소에만 요금이 부과됩니다.
Customer challenges
Isolation
애플리케이션 서버와 데이터베이스는 인터넷에서 직접 접근할 수 없어야 하지만, 업데이트 다운로드 같은 아웃바운드 통신은 필요합니다. 계층별로 접근 경로를 나누지 않으면 보안 요구사항과 운영 요구사항을 함께 맞추기 어렵습니다.
IP plan
온프레미스나 다른 VPC와 IP 대역이 겹치면 VPC 간 연결이나 하이브리드 연결을 구성할 수 없습니다. 처음 정한 CIDR의 크기는 바꿀 수 없어서, 계획 없이 만든 네트워크는 확장할 때 다시 설계해야 합니다.
Scale
사업 단위, 환경, 리전이 늘면서 VPC가 수백 개로 늘어납니다. VPC 간 연결, 온프레미스 연결, 인터넷 출구와 보안 규칙을 VPC마다 따로 관리하면 운영 부담이 커집니다.
Benefits
EC2, RDS, 로드 밸런서 같은 대부분의 리소스는 VPC의 서브넷 안에서 IP 주소를 받아 동작합니다. 그래서 VPC 설계가 이후 보안, 연결, 확장성의 기준이 됩니다.
Isolate
워크로드나 조직 단위로 VPC를 나누어 인프라를 격리합니다. 하나의 VPC 안에서는 서브넷으로 웹, 애플리케이션, 데이터베이스 계층을 분리합니다.
Route
라우팅 테이블이 서브넷과 게이트웨이에서 나가는 트래픽의 목적지를 결정합니다. 인터넷 게이트웨이, NAT 게이트웨이, VPC 엔드포인트, Transit Gateway 중 어디로 보낼지 경로 단위로 지정합니다.
Control
보안 그룹이 리소스 단위의 기본 통제 수단이고, 네트워크 ACL이 서브넷 단위의 보조 통제를 맡습니다. VPC Block Public Access로 계정 전체의 인터넷 접근을 한 번에 차단할 수도 있습니다.
How it works
VPC는 리전 단위 리소스이고, 서브넷은 하나의 가용 영역(AZ)에 속합니다. 서브넷의 유형은 연결된 라우팅 테이블의 경로로 결정됩니다.
VPC를 만들 때 IPv4 CIDR 블록을 지정하며, RFC 1918 사설 대역 사용을 권장합니다. 생성 후 보조 IPv4 CIDR와 IPv6 CIDR를 추가할 수 있지만 기존 CIDR의 크기는 바꿀 수 없습니다.
서브넷은 VPC의 IP 대역 일부이며 하나의 AZ 안에만 존재합니다. 리소스를 여러 AZ의 서브넷에 나누어 배치하면 단일 AZ 장애에 대비할 수 있습니다.
인터넷 게이트웨이로 가는 직접 경로가 있으면 퍼블릭 서브넷, 없으면 프라이빗 서브넷입니다. VPC 밖으로 가는 경로가 전혀 없으면 격리된 서브넷이 됩니다.
인터넷 게이트웨이는 인터넷과, NAT 게이트웨이는 프라이빗 서브넷의 아웃바운드 통신을 연결합니다. VPC 엔드포인트를 쓰면 인터넷 게이트웨이나 NAT 장치 없이 AWS 서비스에 프라이빗으로 접근합니다.
Key features
서브넷은 IPv4 전용, 듀얼 스택, IPv6 전용으로 만들 수 있습니다. 라우팅 테이블 구성에 따라 퍼블릭, 프라이빗, VPN 전용, 격리된 서브넷으로 구분됩니다.
자세히 보기 →보안 그룹은 상태 저장 방식의 리소스 단위 방화벽이고, 다른 보안 그룹을 규칙에서 참조할 수 있습니다. 네트워크 ACL은 서브넷 단위의 상태 비저장 규칙으로 특정 트래픽을 거부하는 보조 통제에 씁니다.
자세히 보기 →프라이빗 서브넷의 인스턴스가 VPC 밖으로 연결을 시작할 수 있게 하고, 외부에서 시작하는 연결은 받지 않습니다. 퍼블릭 NAT 게이트웨이는 탄력적 IP 주소로 인터넷에, 프라이빗 NAT 게이트웨이는 Transit Gateway나 가상 프라이빗 게이트웨이를 거쳐 다른 VPC나 온프레미스에 연결합니다.
자세히 보기 →하나의 NAT 게이트웨이가 워크로드가 있는 AZ를 따라 자동으로 확장·축소됩니다. 퍼블릭 서브넷이 필요 없고, AZ가 늘어나도 라우팅 테이블을 고칠 필요가 없습니다. 프라이빗 NAT 용도에는 영역별 NAT 게이트웨이를 사용합니다.
자세히 보기 →인터넷 게이트웨이나 NAT 장치 없이 Amazon S3와 DynamoDB에 접근합니다. 라우팅 테이블에 서비스의 접두사 목록을 목적지로 하는 경로가 추가되며, 추가 요금은 없습니다.
자세히 보기 →리전 내 VPC 안과 VPC 간 트래픽의 전송 중 암호화 상태를 모니터링하고 강제합니다. 모니터 모드에서 VPC Flow Logs의 encryption-status 필드로 평문 트래픽을 찾고, 정리한 뒤 적용 모드로 전환합니다.
자세히 보기 →AWS 워크로드의 IP 주소를 계획, 추적, 모니터링하는 VPC 기능입니다. 비즈니스 규칙에 따라 VPC에 CIDR를 자동 할당하고, 조직 전체의 IP 할당 이력을 확인합니다.
자세히 보기 →VPC 공유는 VPC 소유 계정이 같은 AWS Organizations의 다른 계정에 서브넷을 공유하는 방식입니다. VPC Flow Logs는 네트워크 인터페이스를 오가는 IP 트래픽 정보를 CloudWatch Logs, S3, Data Firehose로 보내며 네트워크 성능에 영향을 주지 않습니다.
자세히 보기 →Compare
| 항목 | 보안 그룹 | 네트워크 ACL |
|---|---|---|
| 적용 위치 | 인스턴스(ENI) 단위 | 서브넷 단위 |
| 적용 범위 | 보안 그룹이 연결된 모든 인스턴스 | 연결된 서브넷 안의 모든 인스턴스 |
| 규칙 유형 | 허용 규칙만 지원 | 허용과 거부 규칙 모두 지원 |
| 규칙 평가 | 모든 규칙을 평가한 뒤 허용 여부를 결정 | 번호가 낮은 규칙부터 순서대로 평가하고 처음 일치한 규칙을 적용 |
| 응답 트래픽 | 자동 허용 (상태 저장) | 명시적으로 허용해야 함 (상태 비저장) |
| 권장 용도 | 기본 접근 통제 수단 | 특정 트래픽 차단, 서브넷 단위 가드레일 |
Use cases
웹 서버, 애플리케이션 서버, 데이터베이스를 서로 다른 서브넷에 두고 계층 간 연결과 제한을 정의합니다. 인터넷에서 들어오는 트래픽은 퍼블릭 서브넷에서만 받습니다.
AWS 제품 페이지에서 보기 ↗VPC를 Site-to-Site VPN이나 Direct Connect로 데이터 센터와 연결하고, VPC 피어링이나 Transit Gateway로 다른 VPC와 연결합니다. 클라우드 리소스와 기존 인프라를 하나의 네트워크처럼 사용합니다.
AWS 문서에서 보기 ↗네트워크 계정이 VPC를 소유하고 같은 AWS Organizations의 다른 계정에 서브넷을 공유합니다. 각 계정은 공유받은 서브넷에 자기 리소스만 만들고 관리하며, 관리할 VPC 수는 줄어듭니다.
AWS 문서에서 보기 ↗Reference architecture
VPC에 2개 AZ마다 퍼블릭 서브넷과 프라이빗 서브넷을 하나씩 둡니다. 사용자 요청은 인터넷 게이트웨이를 거쳐 퍼블릭 서브넷의 Application Load Balancer로 들어오고, 프라이빗 서브넷에서 Auto Scaling 그룹으로 실행되는 서버로 전달됩니다. 서버의 인터넷 아웃바운드 트래픽은 각 AZ의 NAT 게이트웨이로, S3 트래픽은 게이트웨이 VPC 엔드포인트로 나갑니다.
자세히 보기 →
각 AZ에 영역별 NAT 게이트웨이와 퍼블릭 서브넷을 두는 대신, VPC에 리전별 모드 NAT 게이트웨이 하나를 만듭니다. 모든 AZ의 프라이빗 서브넷 라우팅 테이블이 같은 NAT 게이트웨이 ID를 가리키고, NAT 게이트웨이는 자체 라우팅 테이블의 경로로 인터넷 게이트웨이에 트래픽을 보냅니다. 새 AZ에 리소스가 생기면 NAT 게이트웨이가 그 AZ로 자동 확장합니다.
자세히 보기 →Customer stories
제조 (HVAC·냉장·화재 안전)
Amazon VPC로 팀별 네트워크 환경을 구성하고 Transit Gateway로 VPC를 허브 앤 스포크 방식으로 연결했습니다. 이후 Amazon VPC IPAM으로 새 계정에 표준 기준과 가드레일을 적용해 계정 생성 시간을 3일에서 몇 분으로 줄였습니다.
사례 보기금융 소프트웨어 (디지털 뱅킹)
민감한 워크로드 리소스를 VPC의 프라이빗 서브넷에 배치해, 인바운드·아웃바운드 트래픽 검사 없이 인터넷으로 바로 나가는 경로를 두지 않았습니다. VPC 내부 동서 트래픽은 AWS Network Firewall 규칙으로 통제합니다.
사례 보기Pricing
VPC 자체 사용에는 추가 요금이 없습니다. NAT 게이트웨이, 퍼블릭 IPv4 주소, IPAM, Traffic Mirroring, Reachability Analyzer, Network Access Analyzer 같은 구성 요소에 요금이 부과됩니다.
What's new
리전 내 VPC 안과 VPC 간 트래픽의 전송 중 암호화 상태를 모니터링하고 강제합니다. 모니터 모드에서 VPC Flow Logs의 encryption-status 필드로 평문 트래픽을 찾고, 정리한 뒤 적용 모드로 전환합니다.
하나의 NAT 게이트웨이가 워크로드가 있는 AZ를 따라 자동으로 확장·축소됩니다. 퍼블릭 서브넷이 필요 없고, AZ가 늘어나도 라우팅 테이블을 고칠 필요가 없습니다. 프라이빗 NAT 용도에는 영역별 NAT 게이트웨이를 사용합니다.
Getting started
온프레미스와 다른 VPC와 겹치지 않는 RFC 1918 대역을 고릅니다. 기존 CIDR의 크기는 바꿀 수 없으므로 확장 여유를 두고, 여러 계정이라면 IPAM으로 할당을 관리합니다.
최소 2개 AZ에 서브넷을 만들고 웹, 애플리케이션, 데이터베이스 계층을 서브넷으로 분리합니다. 인터넷에서 직접 접근할 필요가 없는 리소스는 프라이빗 서브넷에 둡니다.
서브넷별 라우팅 테이블에 필요한 최소 경로만 넣습니다. 인터넷 아웃바운드는 NAT 게이트웨이로, S3·DynamoDB는 게이트웨이 엔드포인트로, 다른 VPC와 온프레미스는 Transit Gateway나 VPN·Direct Connect로 연결합니다.
보안 그룹을 기본 통제 수단으로 쓰고, 필요한 경우 네트워크 ACL을 보조로 둡니다. 인터넷 노출을 막아야 하는 계정에는 VPC Block Public Access를, 암호화 요구사항이 있으면 VPC Encryption Controls를 검토합니다.
VPC Flow Logs로 트래픽을 기록하고, 연결 문제는 Reachability Analyzer로 라우팅 테이블과 보안 그룹 설정을 점검합니다.
Next steps
IP 대역, 가용 영역, 인터넷 연결 방식을 순서대로 정한 뒤 VPC를 만듭니다. 공식 문서의 Plan your VPC 절차를 따라 개발 환경에 먼저 구성해 봅니다.
계정과 VPC가 늘어날 경우를 대비해 IP 주소 계획, VPC 간 연결, 중앙 집중 이그레스, DNS 설계 기준을 미리 확인합니다.
VPC 자체는 무료이므로 NAT 게이트웨이, 퍼블릭 IPv4 주소, 데이터 전송량처럼 과금되는 구성 요소를 중심으로 월 비용을 계산합니다.
현재 온프레미스 IP 대역과 연결 요구사항을 공유해 주시면 VPC 구성안을 함께 검토합니다. 대표 워크로드 하나로 서브넷, 라우팅, 보안 통제를 검증하는 PoC를 제안합니다.
Resources
이 페이지는 아래 AWS 공식 자료를 바탕으로 정리했습니다. 마지막 갱신 2026-10-17.