🔥 VPC란 무엇인가: 가상 네트워크의 경계

한 AWS 계정에 VPC가 이미 만들어져 있다. 2013년 12월 이후에 AWS 계정을 만들면 AWS가 모든 리전에 default VPC를 하나씩 넣어 둔다. 그래서 콘솔에서 EC2 인스턴스를 처음 띄우면 그 인스턴스가 default VPC에서 바로 올라가고, 인터넷에서도 곧장 접근 여부가 드러난다. 이제 default VPC가 어떤 구성으로 시작하는지 확인하자.

섹션 1에서는 IAM이 사람과 시스템에 어떤 작업 권한을 줄 수 있는지를 다뤘다. 이제는 그 시스템들이 어느 네트워크에 놓이고 서로 어떻게 통신하는지가 주제다. EC2 인스턴스, RDS 데이터베이스, in-VPC Lambda 함수가 패킷을 주고받는 그 네트워크가 VPC다.

VPC라는 단어 풀어 읽기

VPC는 Virtual Private Cloud의 줄임말이다. "가상의 사설 클라우드"인데, 이 이름이 정확히 무엇을 가리키는지 한 번 짚고 가자.

먼저 Virtual. 물리 케이블을 깔지 않았는데 네트워크가 있다. 콘솔에서 클릭 몇 번, 또는 ec2:CreateVpc 호출 한 번이면 새 네트워크가 태어난다. AWS의 거대한 물리 인프라 위에 소프트웨어로 그어진 가상의 경계라는 뜻이다.

다음 Private. 다른 AWS 계정의 자원도 같은 계정 안의 다른 VPC도 기본 상태에서는 이 VPC와 트래픽을 주고받지 않는다. 격리가 기본값이라는 뜻이다. 두 VPC 사이에 통로를 두려면 VPC Peering과 Transit Gateway: VPC를 잇는 두 방법에서 다룰 연결 자원을 따로 만들어야 하고, S3나 DynamoDB 같은 AWS 관리형 서비스에 공용 인터넷 없이 접근하려면 VPC Endpoint: S3·DynamoDB에 나가지 않고 접근하기에서 다룰 엔드포인트를 별도로 만들어야 한다. 가만히 두면 아무 데도 안 통한다는 점이 이 단어가 약속하는 의미다.

마지막으로 Cloud. 다른 AWS 서비스처럼 VPC도 내가 서버를 사거나 라우터를 설치하지 않아도 된다. VPC를 만들거나 지우면 AWS가 몇 분 안에 처리를 끝낸다. VPC를 아직 직접 써본 적이 없어도 AWS는 계정 안에 default VPC를 하나 넣어 두는 경우가 많다. 2013년 12월 4일 이후에 만든 계정이라면 모든 리전에서 그렇다고 AWS 문서가 명시한다. 그 뒤로 AWS는 EC2-Classic이라는 옛 모델을 단계적으로 종료했고, 2022년 8월 15일이 공식 은퇴 기한이었다. AWS는 2023년 8월에 마이그레이션이 전부 끝났다고 블로그에서 공지했다(verified 2026-04-25).

정확하게 말하면 VPC는 AWS 리전 안에서 내가 정의하는, 다른 자원과 격리된, 소프트웨어로 그어진 가상 네트워크다.

VPC가 놓이는 곳: 리전과 가용영역

VPC가 어디에 놓이는지 한 번 짚자. 세 단계의 계층이 있다.

가장 바깥에는 리전(Region)이 있다. 설명은 이 101편을 어떻게 읽어야 할까에서 잡은 기준대로 서울 리전(ap-northeast-2)을 기준으로 삼는다. 리전은 지리적인 위치다. 서울, 도쿄(ap-northeast-1), 버지니아 북부(us-east-1) 같은 곳들.

리전 안에 가용영역(Availability Zone, AZ)이 들어간다. 한 리전 안에 물리적으로 분리된 데이터센터 묶음을 최소 세 개 두도록 AWS가 못 박아 둔 구조다. 서울 리전은 현재 네 개의 AZ를 갖는다(verified 2026-04-25). 한 AZ가 정전이 나도 다른 AZ는 살아 있게 만든 게 이 격벽의 존재 이유다.

여기서 한 가지를 먼저 잡자. VPC는 리전 자원이고, 서브넷은 AZ 자원이다. 그래서 같은 VPC 안에 여러 AZ의 서브넷을 둘 수는 있어도 한 서브넷을 두 AZ에 걸치게 만들 수는 없다. VPC 자체는 리전을 넘지 못하고, 한국과 일본에 동시에 걸친 VPC 같은 건 없다.

AZ를 부르는 이름에는 까다로운 함정이 하나 있다. 콘솔은 보통 ap-northeast-2a, 2b, 2c, 2d 같은 알파벳 이름을 보여준다. 그런데 이 알파벳 매핑은 계정마다 무작위다. 내 계정에서 ap-northeast-2a라고 부르는 AZ가 너의 계정에서는 ap-northeast-2c일 수 있다. 그래서 AZ ID라는 별도의 식별자가 있다. 서울 리전이면 apne2-az1부터 apne2-az4까지 네 개. AZ ID는 모든 계정에서 같은 물리 위치를 가리키고, 멀티 계정으로 같은 데이터센터를 다시 가리켜야 할 때 또 등장한다.

CIDR 블록: VPC가 가질 IP 주소 범위

VPC를 만들 때 가장 먼저 정하는 게 CIDR 블록이다. 이름이 무서워 보이지만 결국은 "이 네트워크 안에서 쓸 수 있는 사설 IP 주소의 범위"다.

표기는 이렇다. 10.0.0.0/16이라고 쓴다. 앞부분은 시작 주소, /16은 마스크라고 부르는데 처음 16비트가 고정이라는 뜻이다. 32비트짜리 IPv4 주소에서 16비트가 고정이면 나머지 16비트가 자유로우니까, 10.0.0.0부터 10.0.255.255까지 65,536개의 주소가 이 VPC 안에 산다는 의미다.

VPC가 받을 수 있는 마스크 범위는 /16부터 /28까지다(verified 2026-04-25). /16이면 65,536개, /28이면 16개. 가장 큰 칸과 가장 작은 칸의 차이는 4,000배쯤이다. 어떤 마스크를 고를지는 솔직히 말해서 나중에 늘리기 어려운 결정이라서 처음에 좀 넉넉하게 잡는 게 보통이다. 한 번 만든 VPC의 primary CIDR 블록은 바꿀 수 없고, 뒤에 secondary CIDR을 더 붙일 수만 있다. AWS는 VPC 하나당 primary 1개에 secondary 4개, 합쳐서 총 5개의 IPv4 CIDR 블록을 허용한다. IPv6도 5개까지(verified 2026-04-25).

그리고 한 가지 더. RFC 1918에서 예약한 사설 주소 범위 안에서 고르는 게 권장이다. 즉 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 안에서. 이 범위 밖의 공인 IP도 VPC CIDR에 넣을 수는 있다. 그런데 그러면 AWS 외부의 인터넷 라우팅과 충돌할 수 있어서 거의 모두가 사설 범위만 쓴다.

# 시각적 인용 — 이 글에서 직접 실행하지는 않는다
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --instance-tenancy default

# 시각적 인용 — 이 글에서 직접 실행하지는 않는다
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --instance-tenancy default

이 글은 개념 지도가 목적이라 직접 만들지는 않는다. 실제 명령은 다음 편들의 맥락에서 다시 나온다.

VPC를 채우는 부품들: 전체 구성

VPC를 만들었다고 해서 바로 쓸 만한 네트워크가 되지는 않는다. 안쪽을 채우는 부품이 더 있고, 그 부품들을 섹션 2의 나머지 글에서 차례로 다룬다. 먼저 전체 구성을 잡자.

VPC 안쪽에서 가장 먼저 볼 대상은 Subnet: Public과 Private의 진짜 차이에서 다룰 서브넷이다. VPC의 CIDR을 더 작은 조각으로 잘라 각 AZ에 두는 단위인데, 이 서브넷이 공용이냐 사설이냐를 가르는 기준은 의외로 단순하다. 그건 다음 편에서 풀자.

서브넷을 만든 뒤에는 패킷의 경로를 정하는 라우팅 테이블: 패킷이 어디로 가는지가 따라온다. 외부로 나가는 길이 필요한 서브넷에는 Internet Gateway: 외부로 나가는 유일한 길을 붙이고, 외부로 나가야 하지만 외부에서 들어오는 연결은 막아야 하는 사설 서브넷에는 NAT Gateway: Private Subnet의 외부 연결을 둔다.

방화벽 역할은 두 군데에 나뉜다. 인스턴스 한 대에는 Security Group: 인스턴스 레벨 방화벽을 붙이고, 서브넷 전체에는 Network ACL: Subnet 레벨 방화벽과의 차이를 건다. 둘이 어떻게 다르고 언제 어느 쪽을 써야 하는지를 그 두 편에서 짚는다.

VPC끼리 연결할 때는 작은 규모에서 1:1로 잇는 VPC Peering과 큰 규모에서 중앙 연결점으로 여러 VPC를 묶는 Transit Gateway를 구분해서 써야 한다. 둘의 차이는 VPC Peering과 Transit Gateway: VPC를 잇는 두 방법에서 짚는다.

S3나 DynamoDB처럼 AWS 안쪽에서 관리하는 서비스에 공용 인터넷 없이 접근하는 방법은 VPC Endpoint: S3·DynamoDB에 나가지 않고 접근하기에서 다룬다. 마지막에는 VPC 설계 패턴: 3-tier, Hub-and-Spoke, 그 외에서 이 부품들을 어떻게 조합하는지 짚는다.

위 구성도가 한 장에 다 담기지는 않는다. 그래서 한 편씩 줌인한다. 지금 단계에서는 어떤 부품이 있고 어떤 편으로 가면 다시 등장하는지 정도만 머리에 들어와도 충분하다.

Default VPC와 Custom VPC

VPC를 직접 만든 적이 없는 사람도 사실은 default VPC를 쓰고 있다는 말을 위에서 했다. 좀 더 자세히 보자.

2013년 12월 이후에 새 AWS 계정을 만들면 AWS가 모든 리전에 default VPC를 하나씩 만든다. CIDR은 172.31.0.0/16이다. AWS는 그 안에 각 AZ마다 /20 크기의 서브넷을 하나씩 두고, 이 서브넷들은 기본적으로 public이다. AWS가 인터넷 게이트웨이를 연결해 두고, 인스턴스를 띄우면 공인 IPv4 주소도 자동으로 붙인다(verified 2026-04-25).

그래서 맨 처음 EC2 인스턴스를 띄우는 시점부터 인터넷에서 그 인스턴스가 바로 드러난다. 손에 익은 콘솔 스크린샷에서 인스턴스를 만들자마자 SSH가 되는 건 default VPC와 default subnet의 기본 구성 덕분이다. 학습 환경에는 친절한 설계다.

운영 환경에서는 default VPC의 기본 구성을 그대로 받아들이면 곤란하다. 모든 서브넷을 public으로 두는 설정도, 쓰지 않을 AZ까지 같은 방식으로 미리 열어 두는 구성도 운영 목적에는 맞지 않을 때가 많다. 그래서 진지한 환경에서는 default VPC를 건드리지 않고 별도의 custom VPC를 새로 만든다. CIDR은 직접 정하고, 서브넷은 public/private을 의도적으로 나누고, 라우팅 테이블도 일부러 새로 적는다.

여기서 한 thread를 다시 꺼내자. '관리형'이라는 단어가 감추는 비용. Default VPC는 분명 편하다. 그런데 그 편함은 기본값을 모두 그대로 받아들이는 비용과 맞바꾼 결과다. 운영 환경에서 default VPC를 그대로 쓴다는 건, 모르는 사이에 그 기본값들에 의존하게 된다는 뜻이다. 보안 사고가 나면 거의 항상 이 기본값 어딘가가 도화선이다.

이어지는 글부터는 custom VPC에서 CIDR, 서브넷, 라우팅 테이블을 직접 설계하는 순서로 설명을 이어간다. Default VPC는 콘솔 첫 화면이 뜨자마자 거기 있을 거라는 사실 정도만 기억해 두자.

언제 VPC를 쓰지 말아야 하는가

대부분의 AWS 워크로드는 어떤 형태로든 VPC와 관계를 맺는다. 모든 EC2, 모든 RDS, 모든 in-VPC Lambda는 어떤 VPC 안에서 동작한다. 그래서 실제 선택지는 VPC를 쓸지 말지가 아니라 어느 VPC를 쓸지에 가깝다.

그래도 한 가지 의미 있는 분기점이 있다. 직접 정의하는 custom VPC를 만드느냐, default VPC에 그냥 얹느냐. 학습용 계정이거나 진짜로 일회성인 실험이라면 default VPC도 충분하다. 30분짜리 데모를 위해 라우팅 테이블 두 장을 손으로 작성할 필요는 없다.

운영에 쓸 가능성이 있다면 처음부터 custom으로 가자. CIDR과 서브넷 경계를 일찍 정해서 나중에 다른 VPC와 peering을 맺을 때 충돌을 피하고, 서브넷을 의도적으로 나눠 두면 보안 그룹이나 NACL 규칙도 더 분명하게 적을 수 있다. 나중에 갈아끼우는 비용이 처음에 잘 잡는 비용보다 훨씬 크다.

반대로 일반 Lambda, SQS, DynamoDB만 쓰는 단순한 서버리스 구성이라면 초반에 VPC를 직접 다루지 않아도 된다. 이 경우엔 default VPC도 손대지 않는다. 그래도 나중에 RDS나 ElastiCache처럼 VPC 안에 둬야 하는 자원을 붙일 가능성은 자주 생긴다. 그래서 워크로드가 작을 때 VPC 구조를 미리 잡아 두는 편이 훨씬 낫다.

다음 편 예고

다음은 Subnet: Public과 Private의 진짜 차이다. VPC라는 컨테이너 안을 자르는 첫 번째 분할 단계이고, 의외로 public인지 private인지를 가르는 진짜 기준이 무엇인지가 정리되지 않은 채 쓰는 사람이 많다. 그 부분을 풀자.