클라우드 인프라를 제대로 이해하려면 가장 먼저 살펴봐야 하는 개념이 VPC(Virtual Private Cloud) 입니다.
VPC는 클라우드 서비스 제공자가 만들어주는 사용자 전용 가상 네트워크로, AWS·GCP·Azure 등 모든 클라우드의 네트워크 구조에서 핵심 역할을 합니다.
온프레미스에서 우리가 직접 네트워크 장비를 구축하던 것처럼,
클라우드에서는 VPC라는 가상 네트워크 안에 서브넷, 라우팅, 인터넷 연결, 방화벽 규칙을 설계하여 전체 서비스의 안전성과 확장성을 결정합니다.
따라서 VPC 구조를 이해하지 못하면 클라우드 아키텍처 설계는 제대로 할 수 없습니다.
1. VPC란 무엇인가
VPC는 클라우드 내에서 완전히 격리된 사용자 전용 네트워크 공간입니다.
쉽게 말해 “클라우드 속 내 전용 데이터센터”라고 볼 수 있습니다.
VPC 안에서 다음과 같은 요소들을 자유롭게 정의할 수 있습니다.
- IP 대역(CIDR)
- Public / Private Subnet
- 라우팅 테이블
- 인터넷 게이트웨이, NAT 게이트웨이
- 보안그룹, 네트워크 ACL
- 온프레미스와의 전용 연결(VPN, Direct Connect 등)
이것들은 모두 온프레미스 네트워크에서 라우터·스위치·방화벽 같은 역할을 합니다.
2. VPC 설계에서 가장 중요한 IP 대역(CIDR)
VPC 설계의 출발점은 IP 대역(CIDR) 입니다.
예를 들어 10.0.0.0/16을 VPC의 기본 주소 공간으로 지정하면,
여기에서 여러 Subnet을 쪼개어 사용할 수 있습니다.
CIDR 설계는 향후 확장성을 좌우하기 때문에
초기에 충분히 넓은 대역을 잡는 것이 중요합니다.
- 너무 좁으면 인스턴스를 확장할 수 없음
- 너무 넓으면 네트워크 설계가 복잡해짐
- 온프레미스와 IP가 겹치면 VPN 연결 불가
그래서 대부분의 기업은 10.0.0.0/16 혹은 172.31.0.0/16 같은 넉넉한 대역을 선택합니다.
3. Public Subnet / Private Subnet 구조
VPC는 크게 두 종류의 Subnet으로 나눕니다.
Public Subnet
인터넷과 직접 통신 가능한 서브넷입니다.
여기에는 다음과 같은 리소스가 배치됩니다.
- 로드밸런서(ALB/NLB)
- Bastion Host(관리용 접속 서버)
- 인터넷에서 접근 가능한 서버
인터넷과 연결되기 위해서는 인터넷 게이트웨이(IGW) 를 반드시 연결해야 합니다.
Private Subnet
외부에서 직접 접근할 수 없는 내부 서브넷입니다.
여기에 배치되는 대표 리소스는 다음과 같습니다.
- 애플리케이션 서버(EC2)
- 데이터베이스(RDS)
- 캐시 서버(Redis/Elasticache)
- 내부 API 서버
보안이 필요한 서비스 대부분을 Private 영역에 배치하는 것이 기본 원칙입니다.
4. 라우팅 테이블(Route Table)의 역할
VPC 안에서 트래픽이 어디로 갈지 결정하는 것이 라우팅 테이블입니다.
Public Subnet은
0.0.0.0/0 → Internet Gateway
라는 기본 라우팅이 있어 외부와 통신 가능합니다.
Private Subnet은
0.0.0.0/0 → NAT Gateway
로 설정하여, 외부 접근은 차단하지만 내부 → 외부 아웃바운드 트래픽은 가능하게 구성합니다.
예를 들어 Private Subnet의 서버가 업데이트 패키지 설치를 위해 인터넷에 접근해야 하는 경우 이런 구조가 필요합니다.
라우팅 테이블을 잘못 구성하면
서버가 인터넷에 접근하지 못하거나,
DB가 외부로 트래픽을 발송하는 오작동이 발생할 수 있으므로
VPC 설계에서 매우 중요한 요소입니다.
5. 인터넷 게이트웨이(IGW)와 NAT 게이트웨이의 차이
인터넷 게이트웨이(IGW)는 Public Subnet에서 인터넷과 직접 연결하는 장치입니다.
반대로 NAT 게이트웨이는 Private Subnet의 인스턴스가 인터넷으로 나가는 것만 허용하는 장치입니다.
- IGW: 외부 → 내부 / 내부 → 외부 모두 가능
- NAT GW: 내부 → 외부만 가능 (역방향은 불가)
보안 규칙상 데이터베이스나 내부 API 같은 민감한 서버는
절대 Public Subnet에 두지 않고 Private Subnet + NAT Gateway 조합을 사용합니다.
6. 보안 그룹(Security Group)과 네트워크 ACL
VPC는 네트워크 트래픽을 제어하는 두 가지 보안 계층을 제공합니다.
1) 보안 그룹(Security Group)
인스턴스 단위의 방화벽입니다.
허용 기반(Allow-Only) 방식으로 동작하여, 명시적으로 허락한 트래픽만 들어올 수 있습니다.
실무에서는 DB의 보안 그룹을 “API 서버 SG만 접근 허용”처럼 설정합니다.
2) 네트워크 ACL(NACL)
Subnet 단위의 방화벽입니다.
허용·차단을 모두 설정할 수 있으며, 대규모 네트워크 정책에 사용됩니다.
대부분의 서비스에서는 보안 그룹만으로도 충분하고,
규모가 큰 프로젝트에서만 NACL을 추가로 설계하기도 합니다.
7. VPC 피어링·Transit Gateway·하이브리드 연결
기업 환경에서는 보통 VPC 하나로 끝나지 않습니다.
여러 서비스, 사업부, 환경(DEV/STG/PROD)을 나눠 운영하면서
VPC 간 통신이 필요해집니다.
대표적인 연결 방식은 다음과 같습니다.
- VPC Peering: VPC 간 1:1 연결
- Transit Gateway: 여러 VPC를 중앙 라우터처럼 묶는 방식
- VPN 연결: 온프레미스 ↔ VPC 연결
- Direct Connect: 전용선 연결로 기업 데이터센터 ↔ 클라우드 고속 링크
이 기능들을 사용해, 클라우드와 온프레미스를 통합한
하이브리드 인프라 구조를 구성할 수 있습니다.
8. 컨테이너 & 서버리스 시대의 VPC 구조
서비스가 컨테이너(Kubernetes)나 서버리스(Lambda) 기반으로 전환되면서
VPC는 더 중요해졌습니다.
- AWS Lambda의 내부 통신도 VPC Subnet과 보안 그룹이 필요
- EKS(Kubernetes) 노드와 파드 IP 구조는 VPC 설계에 직접적 영향
- API Gateway, ALB, ECS 서비스도 VPC에 의해 라우팅이 결정됨
초기에 VPC를 잘못 설계하면
서브넷 IP 부족, NAT 비용 폭증, 보안 구조 혼잡 같은 문제가 자주 발생합니다.
따라서 컨테이너/서버리스를 운영할수록
“VPC는 제대로 설계된 데이터센터” 수준으로 중요해집니다.
9. VPC 설계 베스트 프랙티스
실무에서 가장 많이 활용되는 VPC 설계 원칙은 다음과 같습니다.
- VPC CIDR은 넉넉하게 잡는다 (예: /16)
- Public / Private Subnet을 AZ별(가용 영역)로 최소 2개 이상 구성
- DB는 반드시 Private Subnet에 배치
- Public Subnet에는 LB와 Bastion만 배치
- NAT Gateway는 최소 1개, 고가용성은 AZ별 구성
- 보안 그룹은 "허용 기반"으로 구성하고 IP 접근 제어는 최소화
- 로그(AWS VPC Flow Logs)를 활성화하여 보안/트래픽 모니터링 강화
이 원칙만 따라도 대부분의 VPC 문제를 예방할 수 있습니다.
10. 결론
VPC는 클라우드 아키텍처의 기반이 되는 핵심 네트워크 구조입니다.
서버, 데이터베이스, 로드밸런서, 컨테이너, 서버리스까지 모두 VPC 안에서 동작하며
보안·성능·확장성은 VPC 설계 품질에 의해 크게 달라집니다.
즉, VPC는 단순 네트워크가 아니라
서비스 전체를 지탱하는 뼈대라고 할 수 있습니다.
초기에 올바르게 설계된 VPC는 장기적으로 운영 복잡도를 줄이고
클라우드 비용과 장애 위험까지 낮출 수 있습니다.