온프레미스에서 사내망을 설계할 때는 코어 스위치에서 VLAN을 나누고, 서브넷마다 게이트웨이를 두고, 인터넷으로 나가는 구간에는 방화벽을 세웁니다. AWS에서 EC2 인스턴스를 띄우기 전에도 똑같은 결정이 필요합니다 — 다만 물리 장비 대신 VPC라는 논리적인 네트워크를 먼저 설계해야 합니다. 이름 그대로 "가상 사설 클라우드"이지만, CIDR(Classless Inter-Domain Routing — 10.0.0.0/16처럼 IP 대역의 범위를 표기하는 방식, 사내망의 서브넷 마스크 표기와 같은 역할) 로 지정한 IP 대역을 나중에 넓힐 수 없다거나 서브넷이 특정 위치에 고정된다거나 하는, 물리 네트워크에서는 신경 쓰지 않던 제약이 있습니다. 이 글은 VPC가 정확히 무엇이고, 사내망을 설계해 본 사람이 이걸 처음 만졌을 때 어디서 헷갈리는지를 다룹니다.
사내망에서 코어 스위치로 VLAN을 나누고 서브넷마다 방화벽 정책을 걸어 온 네트워크 관리자가 이번 프로젝트에서 VPC를 처음부터 설계하게 됐다. CIDR을 10.0.0.0/24로 작게 잡았는데, 몇 달 뒤 서브넷이 모자라 대역을 넓히려 하니 콘솔에서 막힌다. 그리고 "일단 되나 보자"며 기본 제공되는 VPC에 테스트 서버를 하나 올렸는데, 나중에 보니 인터넷에서 그대로 접근되는 상태였다. "사내망에서는 안 이랬는데"라는 질문에서 시작한다.
이 글은 실제 AWS 콘솔 화면이나 CLI 실행 결과를 캡처하지 않습니다. CIDR 블록 크기 규칙, 서브넷과 가용 영역의 관계, 퍼블릭·프라이빗 서브넷을 가르는 기준, 기본 VPC의 구성, 보안 그룹의 동작 방식처럼 이 글이 다루는 사실 하나하나는 전부 AWS 공식 문서(Amazon VPC User Guide)를 직접 열어 원문을 대조한 것입니다. 정확한 가격은 리전과 시점에 따라 바뀌므로, 구체적인 숫자보다 "무엇이 과금 대상이고 무엇이 아닌가"에 초점을 둡니다.
목차
1. VPC가 정확히 뭔가
AWS 공식 문서는 VPC를 이렇게 정의합니다.
"With Amazon Virtual Private Cloud (Amazon VPC), you can launch AWS resources in a logically isolated virtual network that you've defined. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS."
온프레미스에서 직접 설계·운영하던 사내망을 논리적으로 그대로 옮겨 놓은 것에 가깝습니다. 다만 AWS 문서가 나열하는 핵심 구성 요소를 보면 사내망과 매핑되는 지점이 분명해집니다.
"Subnets: A subnet is a range of IP addresses in your VPC... Routing: Use route tables to determine where network traffic from your subnet or gateway is directed... Gateways and endpoints: A gateway connects your VPC to another network. For example, use an internet gateway to connect your VPC to the internet... Peering connections: Use a VPC peering connection to route traffic between the resources in two VPCs."
서브넷(IP 대역을 나눈 것)·라우팅 테이블(트래픽을 어디로 보낼지)·게이트웨이(다른 네트워크와의 연결점)·피어링(VPC끼리의 연결) — 사내망을 설계할 때 다루던 개념과 이름만 다를 뿐 역할은 같습니다. 그리고 VPC는 리전 하나에 종속됩니다 — 계정을 만들면 리전마다 기본 VPC가 하나씩 자동으로 생깁니다.
"Your AWS account includes a default VPC in each AWS Region."
2. 온프레미스 대응표
같은 물건이 아니라 "가장 가까운 것"입니다. 대응시켜 놓고 다른 점을 무시하면 3·4장에서 다루는 오해로 바로 이어집니다.
| 온프레미스 | AWS | 같은 점 | 다른 점 |
|---|---|---|---|
| 사내망 전체 설계 | VPC | 논리적으로 격리된 네트워크 | 리전 하나에 종속(1장) |
| VLAN | 서브넷 | IP 대역을 나눈 구획 | 가용 영역 하나에 고정(3장) |
| 코어 스위치의 라우팅 테이블 | (VPC) 라우팅 테이블 | 트래픽 목적지 결정 | 서브넷마다 자동으로 하나씩 연결(3장) |
| 인터넷 경계 라우터 | 인터넷 게이트웨이(IGW) | 인터넷으로 나가는 관문 | 라우팅 테이블에 경로가 있어야 실제로 열림(3장) |
| DMZ / 내부망 구분 | 퍼블릭 서브넷 / 프라이빗 서브넷 | 인터넷 노출 여부로 구획 | 물리 분리가 아니라 라우팅 설정 차이(3장) |
| 사내망 IP 대역 설계(고정) | VPC CIDR 블록 | 처음에 크게 잡아야 함 | 기존 블록 크기 변경 자체가 불가능(3장) |
| 사이트 간 전용선·VPN | Direct Connect·Site-to-Site VPN | 원격 네트워크 연결 | 이 글에서는 존재만 언급(6장) |
| 방화벽 규칙 | 보안 그룹·네트워크 ACL | 트래픽 허용/차단 | 이 글에서는 깊이 다루지 않음(6장) |
3. 실무에서 반드시 알아야 하는 것
CIDR 블록은 처음 크기가 사실상 최종 크기다
AWS 공식 문서는 VPC의 IPv4 CIDR 블록 규칙을 이렇게 명시합니다.
"When you create a VPC, you must specify an IPv4 CIDR block for the VPC. The allowed block size is between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses)."
그리고 크기 변경에 대해서는 이렇게 못 박습니다.
"You cannot increase or decrease the size of an existing CIDR block."
온프레미스에서 사내망 대역이 부족해지면 스위치 설정을 바꿔 서브넷 마스크를 조정하는 것도 가능했지만, VPC는 한번 만든 CIDR 블록의 크기 자체를 바꿀 수 없습니다. 대신 추가 CIDR 블록을 붙이는 것(/28~/16 범위 안에서, 기존과 겹치지 않게)은 가능합니다. 도입부 시나리오에서 /24(256개 주소)로 작게 잡았다가 막힌 것이 바로 이 제약입니다 — 부족하면 새 대역을 추가하는 것이지, 기존 /24를 /20으로 넓히는 것 자체가 불가능합니다. 그래서 실무에서는 처음부터 여유 있게(/16 쪽으로) 잡아 두는 것이 정석입니다.
서브넷은 가용 영역 하나에 고정된다
AWS 공식 문서는 서브넷의 기본 제약을 이렇게 설명합니다.
"A subnet is a range of IP addresses in your VPC... Each subnet must reside entirely within one Availability Zone and cannot span zones."
VLAN을 스위치 설정만 바꾸면 다른 랙, 다른 층으로 유연하게 옮길 수 있던 것과 달리, 서브넷은 만들 때 지정한 가용 영역(AZ, Availability Zone — 물리적으로 분리된 데이터센터 단위)에 그대로 고정됩니다. 다른 AZ로 옮기려면 그 AZ에 새 서브넷을 만들고 리소스를 재배치해야 합니다. VPC 전체가 여러 AZ에 걸쳐 있더라도, 그 안의 서브넷 하나하나는 각각 AZ 하나씩만 담당합니다.
퍼블릭 서브넷과 프라이빗 서브넷은 물리적 차이가 아니라 라우팅 설정 차이다
AWS 공식 문서는 서브넷 유형을 라우팅 기준으로 정의합니다.
"The subnet type is determined by how you configure routing for your subnets... Public subnet – The subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet. Private subnet – The subnet does not have a direct route to an internet gateway."
온프레미스의 DMZ는 보통 물리적으로 별도 스위치·별도 방화벽 인터페이스로 분리하지만, VPC의 퍼블릭·프라이빗 구분은 순전히 그 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는지로 갈립니다. 서브넷 자체에는 "이건 퍼블릭, 이건 프라이빗"이라는 물리적 표식이 없습니다 — 라우팅 테이블의 경로 하나가 그 서브넷의 성격을 결정합니다. 그리고 서브넷 라우팅은 이렇게 동작합니다.
"Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet. Every subnet that you create is automatically associated with the main route table for the VPC."
서브넷을 새로 만들면 별도로 지정하지 않는 한 자동으로 VPC의 메인 라우팅 테이블에 연결됩니다. 이 메인 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지 없는지가, 그 서브넷이 프라이빗인지 퍼블릭인지를 가르는 실질적인 기준입니다.
시나리오 — 온프레미스 IP 대역 설계를 그대로 옮긴다면
사내망에서 본사 10.0.0.0/16, 부서별 VLAN을 /24로 쪼개 쓰던 조직이 AWS로 전환하면서 같은 감각으로 VPC를 설계한다고 가정합니다.
- VPC CIDR부터 여유 있게 잡는다. 나중에 크기를 못 바꾸므로(위 사실), 당장 필요한 서버 수만 보고 작게 잡지 않고
/16(65,536개 주소) 근처로 시작합니다. 온프레미스에서 본사 대역을/16으로 잡던 것과 같은 이유입니다 — 조직이 커질 걸 감안한 여유입니다. - AZ 개수만큼 서브넷을 쪼갠다. 서브넷이 AZ 하나에 고정되므로(위 사실), 최소한 사용할 AZ 개수만큼 서브넷이 필요합니다. 흔한 패턴은 AZ마다 퍼블릭 서브넷 하나, 프라이빗 서브넷 하나를 두는 것입니다 — 부서별 VLAN을 나누던 감각을 "AZ별 + 용도별"로 확장한 것에 가깝습니다.
- 부서 대신 용도로 나눈다. 온프레미스에서는 부서(영업팀·개발팀)로 VLAN을 나누는 경우가 많지만, VPC 서브넷은 보통 역할(웹 서버용 퍼블릭 서브넷, DB용 프라이빗 서브넷)로 나눕니다. 인터넷 노출 여부가 곧 서브넷 구분 기준이라는 3장의 원칙과 맞닿아 있습니다.
- 라우팅 테이블로 성격을 확정한다. 퍼블릭으로 쓸 서브넷의 라우팅 테이블에만 인터넷 게이트웨이 경로를 추가합니다. 이 경로 하나가 그 서브넷을 "퍼블릭"으로 만드는 전부입니다 — 별도 물리 배선이 필요한 게 아닙니다.
CIDR 크기와 AZ 배치는 나중에 되돌리기 어려운 결정이라는 점에서, 온프레미스의 사내망 설계만큼(혹은 그 이상으로) 처음에 신중해야 하는 단계입니다.
4. 온프레미스 관리자가 자주 하는 오해
오해 1. "VPC CIDR이 좁으면 나중에 넓히면 되지"
거꾸로입니다. 이미 만든 CIDR 블록은 크기를 늘리거나 줄일 수 없습니다(3장) — 부족하면 새 CIDR 블록을 추가하는 방식으로만 대응할 수 있고, 그마저도 기존 블록과 겹치지 않아야 합니다. 온프레미스에서 스위치 설정으로 서브넷 마스크를 넓히던 유연함이 VPC에는 없습니다. 처음 설계 단계에서 여유 있게 잡는 것이 사실상 유일한 대응책입니다.
오해 2. "서브넷도 나중에 다른 위치로 옮기면 되지"
서브넷은 만들 때 지정한 가용 영역에 고정됩니다(3장). VLAN을 스위치 설정 변경만으로 다른 랙에 옮기던 감각과 다릅니다 — 다른 AZ로 옮기려면 그 AZ에 새 서브넷을 만들고 리소스를 재배치해야 합니다.
오해 3. "프라이빗 서브넷은 물리적으로 격리돼 있으니 더 안전하겠지"
방향은 맞지만 근거를 잘못 짚은 오해입니다. 프라이빗 서브넷이 안전한 이유는 물리적 격리가 아니라, 그 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 없기 때문입니다(3장). 만약 실수로 그 라우팅 테이블에 인터넷 게이트웨이 경로를 추가하면, 서브넷 이름이 "프라이빗"이어도 그 순간부터 퍼블릭처럼 동작합니다. 이름표가 아니라 라우팅 테이블의 실제 내용을 확인해야 합니다.
오해 4. "기본 제공되는 VPC를 그냥 쓰면 무난하겠지"
AWS 공식 문서는 기본 VPC의 구성을 이렇게 설명합니다.
"A default VPC comes with a public subnet in each Availability Zone, an internet gateway, and settings to enable DNS resolution."
기본 VPC의 서브넷은 전부 퍼블릭입니다 — 빠르게 시작할 수 있도록 처음부터 인터넷 게이트웨이 경로가 걸려 있는 구성입니다. 온프레미스에서 "기본값이니까 무난하게 안전할 것"이라는 감각으로 접근하면 안 됩니다. 도입부 시나리오에서 테스트 서버가 인터넷에 그대로 노출된 이유가 이것입니다 — 프로덕션 워크로드는 보통 프라이빗 서브넷을 포함해 VPC를 직접 설계하는 쪽을 권장합니다.
오해 5. "VPC도 유료 서비스니까 안 쓰면 비용이 나가겠지"
거꾸로입니다. AWS 공식 문서는 이렇게 명시합니다.
"There's no additional charge for using a VPC."
VPC 자체, 서브넷, 라우팅 테이블, 보안 그룹은 만들어 두는 것만으로는 비용이 발생하지 않습니다. 비용은 그 안에 얹는 컴포넌트(NAT 게이트웨이, 퍼블릭 IPv4 주소 등)에서 발생합니다. 자세한 내용은 5장에서 다룹니다.
시나리오 — 서로 다른 리전의 VPC를 하나로 묶으려 한다
두 리전(예: 서울·도쿄)에 각각 VPC를 만들어 애플리케이션을 이중화한 뒤, 두 VPC 안의 서버가 서로 사설 IP로 직접 통신하게 만들려는 요청이 들어옵니다. 담당자는 "VPC 하나에 리전 두 개를 걸치도록 서브넷만 추가하면 되겠지"라고 생각하고 콘솔에서 리전을 바꿔 서브넷을 추가하려 하지만, 애초에 다른 리전에서는 그 VPC 자체가 보이지 않습니다.
원인은 1장에서 확인한 그대로입니다 — VPC는 리전 하나에 종속되는 자원이라, 서울 리전에서 만든 VPC는 도쿄 리전에 존재하지 않습니다. 사내망에서 본사와 지사를 전용선으로 묶어 하나의 IP 대역처럼 쓰던 것과 달리, VPC는 애초에 리전을 넘어 확장되는 개념이 아닙니다.
당장 취할 조치는 VPC 피어링을 검토하는 것입니다. 두 리전 각각에 VPC를 그대로 두고, VPC 피어링 연결로 두 VPC의 라우팅 테이블에 서로를 향하는 경로를 추가합니다. AWS 공식 문서는 이 방식을 이렇게 안내합니다.
"Use a VPC peering connection to route traffic between the resources in two VPCs."
VPC 자체를 합치는 것이 아니라, 별개인 두 VPC를 네트워크 수준에서 연결하는 방식입니다.
연결할 VPC나 VPN이 여러 개로 늘어날 것 같다면 전송 게이트웨이(Transit Gateway)를 검토합니다. 피어링은 VPC 쌍마다 개별로 맺어야 해서, 리전이나 VPC 수가 늘어나면 관리가 급격히 복잡해집니다. AWS 공식 문서는 이런 경우를 위한 중앙 허브 방식을 안내합니다.
"Use a transit gateway, which acts as a central hub, to route traffic between your VPCs, VPN connections, and Direct Connect connections."
사내망에서 지사가 늘어날수록 개별 전용선 대신 허브 앤 스포크 구조로 전환하던 것과 같은 방향의 해법입니다.
어느 방식을 택하든 CIDR이 겹치지 않는지부터 먼저 확인해야 합니다. 피어링이든 전송 게이트웨이든, 두 VPC의 CIDR 블록이 겹치면 연결 자체가 불가능합니다. 처음 설계 단계에서 리전별 VPC의 대역을 서로 겹치지 않게 나눠 둬야 합니다(3장의 "여유 있게 잡는다"에 "리전별로 겹치지 않게"도 추가해야 하는 이유입니다).
"VPC는 리전 경계를 넘지 않는다"는 것을 인프라 설계 초기에 반영해 두지 않으면, 멀티 리전 이중화 계획 자체를 다시 짜야 하는 상황을 만날 수 있습니다.
5. 비용·운영 감각
온프레미스에서는 스위치·라우터·방화벽 장비를 구매하는 순간 네트워크 인프라 비용 대부분이 확정됩니다. VPC는 이 감각과 크게 다릅니다.
VPC·서브넷·라우팅 테이블·보안 그룹 자체는 무료입니다. 몇 개를 만들든, 얼마나 정교하게 나누든 그 자체로는 과금되지 않습니다. 온프레미스에서 "물리 장비를 늘릴 때마다 비용이 든다"는 감각을 VPC 설계에 그대로 옮기면, 필요 이상으로 서브넷을 아끼거나 단순하게 설계하는 방향으로 흘러갈 수 있습니다 — 비용 부담 없이 용도별로 세분화해도 됩니다.
비용은 VPC 안에 얹는 컴포넌트에서 발생합니다. 대표적으로 NAT 게이트웨이(프라이빗 서브넷이 인터넷에 나갈 때 거치는 컴포넌트, 5번 글에서 다룰 주제)가 있고, 트래픽 미러링·Reachability Analyzer 같은 부가 기능도 별도 과금됩니다.
퍼블릭 IPv4 주소는 이제 과금 대상입니다. AWS 공식 문서는 이렇게 설명합니다.
"A public IPv4 address is an IPv4 address that is routable from the internet. A public IPv4 address is necessary for a resource to be directly reachable from the internet over IPv4."
"Private IPv4 addresses (RFC 1918) are not charged."
온프레미스에서 공인 IP가 회선 계약에 딸려 오는 경우가 많아 IP 자체 비용을 잘 의식하지 않는 것과 달리, VPC에서는 사설 IP(RFC 1918 대역 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16처럼 인터넷에 직접 노출되지 않는 사설 IP 대역을 정의한 IETF 표준 문서)는 무료지만 퍼블릭 IP는 유료입니다(EC2 글 5장에서 다룬 탄력적 IP 과금과 같은 원칙의 연장선입니다). 프라이빗 서브넷 위주로 설계하는 것이 단순히 보안뿐 아니라 비용 측면에서도 유리한 이유입니다.
6. 관련 개념
- 보안 그룹·네트워크 ACL — 서브넷·인스턴스 단위의 트래픽 제어. 이 글에서는 존재만 언급하고 깊이 다루지 않았다.
- NAT 게이트웨이·인터넷 게이트웨이 — 프라이빗 서브넷이 인터넷으로 나가는 경로, 퍼블릭 서브넷이 인터넷과 만나는 관문.
- ALB·NLB — VPC 안 여러 서브넷에 걸쳐 트래픽을 분산하는 로드밸런서.
- Direct Connect·Site-to-Site VPN — 온프레미스 네트워크와 VPC를 연결하는 전용선·VPN.
- IAM — 누가 VPC·서브넷·라우팅 테이블을 만들고 고칠 수 있는지를 통제하는 권한 체계.
7. 한눈에 정리
| 항목 | 확인할 것 |
|---|---|
| VPC | 리전 하나에 종속, 다른 리전으로 자동 확장되지 않는다 |
| CIDR 블록 | /16~/28 범위, 생성 후 기존 블록 크기 변경 불가 — 추가만 가능하다 |
| 서브넷 | 가용 영역 하나에 고정, VPC의 CIDR을 나눠 쓴다 |
| 퍼블릭·프라이빗 구분 | 물리적 분리가 아니라 라우팅 테이블에 인터넷 게이트웨이 경로가 있는지로 결정된다 |
| 라우팅 테이블 | 서브넷마다 하나씩 연결, 지정 안 하면 메인 라우팅 테이블이 자동 적용된다 |
| 기본 VPC | 서브넷이 전부 퍼블릭으로 구성되어 있다 |
| VPC·서브넷·라우팅 테이블 | 그 자체로는 무료 |
| 퍼블릭 IPv4 | 유료, 사설 IP(RFC 1918)는 무료 |
| 여러 리전 연결 | VPC 피어링(개별 연결) 또는 전송 게이트웨이(중앙 허브)가 필요하다 |
참고
'AWS > 이게 뭐야?' 카테고리의 다른 글
| Route 53 — DNS 서버 하나가 하던 일을 세 갈래로 나눈 이유 (0) | 2026.09.03 |
|---|---|
| ALB·NLB·CLB — L4/L7 스위치 한 대가 세 갈래로 나뉜 이유 (0) | 2026.09.02 |
| NAT 게이트웨이·인터넷 게이트웨이 — 온프레미스 경계 라우터 하나가 둘로 갈라진 이유 (0) | 2026.09.01 |
| 보안 그룹 vs 네트워크 ACL — 온프레미스 방화벽 감각으로 읽는 AWS의 이중 방어선 (1) | 2026.09.01 |
| EBS·EFS — 온프레미스 SAN·NAS 감각으로 읽는 AWS의 스토리지 (0) | 2026.08.29 |
| EC2 — 온프레미스 서버 감각으로 읽는 AWS의 "가상 서버" (0) | 2026.08.27 |