
클라우드 컴퓨팅 환경에서 네트워크 설계는 애플리케이션의 성능, 보안, 확장성을 결정하는 가장 근본적인 요소이다. AWS VPC(Virtual Private Cloud)는 사용자가 AWS 클라우드 내에 논리적으로 격리된 가상 네트워크를 직접 정의하고 완벽하게 제어할 수 있도록 지원하는 핵심 서비스이다. 본 문서는 VPC의 개념적 이해를 돕고, 실제 운영 환경에 적용할 수 있는 구체적인 절차와 모범 사례를 제공하는 것을 목표로 한다.
1. AWS VPC(Virtual Private Cloud)란 무엇인가?
Amazon Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용으로 논리적으로 분리된 가상 네트워크 공간을 제공하는 서비스이다. 이는 마치 전통적인 데이터 센터에서 운영하던 물리적 네트워크 환경을 클라우드로 그대로 옮겨온 것과 유사한 경험을 제공한다. 사용자는 이 가상 네트워크 안에서 IP 주소 범위, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 네트워크 환경에 대한 완전한 통제권을 갖는다.
VPC의 가장 중요한 역할은 '논리적 격리'이다. 이를 통해 사용자는 자신의 리소스(예: EC2 인스턴스, RDS 데이터베이스)를 다른 AWS 사용자의 리소스와 완벽하게 분리하여 보안을 강화할 수 있다. 또한, 네트워크를 퍼블릭 영역과 프라이빗 영역으로 분리하여 인터넷과 직접 통신해야 하는 리소스와 내부적으로만 통신해야 하는 리소스를 체계적으로 관리할 수 있다.
2. VPC의 핵심 구성 요소
VPC는 여러 네트워킹 구성 요소들의 조합으로 이루어진다. 각 요소의 역할과 상호작용을 이해하는 것이 VPC를 효과적으로 설계하는 첫걸음이다.
2.1. VPC와 서브넷 (Subnet)
VPC를 생성하는 것은 가상 네트워크의 전체적인 경계를 설정하는 것과 같다. 이 경계 내에서 네트워크는 더 작은 단위인 서브넷(Subnet)으로 분할된다. 서브넷은 VPC의 IP 주소 범위를 논리적으로 나눈 것으로, 모든 AWS 리소스는 반드시 특정 서브넷 내에 위치해야 한다. 각 서브넷은 단일 가용 영역(Availability Zone, AZ)에 종속되므로, 여러 가용 영역에 걸쳐 애플리케이션을 배포하여 고가용성을 확보하려면 여러 서브넷을 생성해야 한다.
서브넷은 인터넷 연결 여부에 따라 두 가지 유형으로 나뉜다.
- 퍼블릭 서브넷 (Public Subnet): 라우팅 테이블이 인터넷 게이트웨이(IGW)로의 경로를 가지고 있어 외부 인터넷과 직접 통신이 가능한 서브넷이다. 주로 웹 서버, 로드 밸런서 등 외부 사용자의 접근이 필요한 리소스가 위치한다.
- 프라이빗 서브넷 (Private Subnet): 인터넷 게이트웨이로의 경로가 없어 외부에서 직접 접근할 수 없는 서브넷이다. 데이터베이스, 내부 API 서버 등 보안이 중요한 리소스를 배치하여 외부 공격으로부터 보호한다. 필요시 NAT 게이트웨이를 통해 외부 인터넷으로의 아웃바운드 통신만 허용할 수 있다.
2.2. IP 주소 지정 (CIDR)
VPC와 서브넷을 생성할 때는 CIDR(Classless Inter-Domain Routing) 표기법을 사용하여 IPv4 주소 범위를 할당해야 한다. 예를 들어, 10.0.0.0/16
은 10.0.0.0부터 10.0.255.255까지의 65,536개 IP 주소를 포함하는 VPC를 정의한다. 서브넷의 CIDR 블록은 반드시 상위 VPC의 CIDR 블록에 속해야 한다 (예: 10.0.1.0/24
).
AWS는 각 서브넷 CIDR 블록에서 처음 4개의 IP 주소와 마지막 1개의 IP 주소를 내부 네트워킹 목적으로 예약한다. 따라서 사용자가 리소스에 할당할 수 없다.
10.0.1.0
: 네트워크 주소10.0.1.1
: VPC 라우터용10.0.1.2
: DNS 서버용10.0.1.3
: 향후 사용을 위해 예약10.0.1.255
: 네트워크 브로드캐스트 주소
2.3. 라우팅 테이블 (Route Table)
라우팅 테이블은 VPC 내의 네트워크 트래픽이 어디로 가야 할지를 결정하는 규칙, 즉 '라우트(Route)'의 집합이다. 각 서브넷은 반드시 하나의 라우팅 테이블과 연결되어야 하며, 이 테이블의 규칙에 따라 해당 서브넷에서 발생하는 트래픽의 목적지가 정해진다. VPC를 생성하면 기본 라우팅 테이블이 자동으로 생성되며, 필요에 따라 사용자 정의 라우팅 테이블을 만들어 특정 서브넷에 연결할 수 있다.
2.4. 게이트웨이 (Gateway)
게이트웨이는 VPC가 외부 네트워크와 통신할 수 있도록 하는 관문 역할을 수행한다.
- 인터넷 게이트웨이 (Internet Gateway, IGW): VPC와 인터넷 간의 양방향 통신을 가능하게 하는 핵심 요소이다. IGW를 VPC에 연결하고, 퍼블릭 서브넷의 라우팅 테이블에 인터넷(
0.0.0.0/0
)으로 향하는 트래픽을 IGW로 보내는 규칙을 추가해야 인터넷 통신이 가능하다. - NAT 게이트웨이 (NAT Gateway): 프라이빗 서브넷에 위치한 리소스(예: DB 서버)가 외부 인터넷으로 접속(예: 소프트웨어 패치 다운로드)해야 할 때 사용된다. NAT 게이트웨이는 프라이빗 IP 주소를 자신의 퍼블릭 IP 주소로 변환하여 아웃바운드 통신을 허용하고, 외부에서는 먼저 연결을 시작할 수 없도록 하여 보안을 유지한다. NAT 게이트웨이 자체는 반드시 퍼블릭 서브넷에 생성되어야 한다.
3. VPC 보안 구성 요소: 방화벽 설정
VPC는 두 가지 계층의 가상 방화벽을 제공하여 리소스를 안전하게 보호한다.
3.1. 보안 그룹 (Security Group)
보안 그룹은 EC2 인스턴스와 같은 개별 리소스 수준에서 트래픽을 제어하는 방화벽이다. 특정 포트와 IP 주소에 대한 인바운드/아웃바운드 트래픽을 허용하는 규칙을 정의한다.
- Stateful 방식: 인바운드 규칙을 통과한 트래픽에 대한 응답 트래픽은 아웃바운드 규칙과 상관없이 자동으로 허용된다. 예를 들어, 포트 80(HTTP) 인바운드를 허용하면, 웹 서버의 응답은 별도 규칙 없이 외부로 나갈 수 있다.
- 허용(Allow) 규칙만 설정 가능: 기본적으로 모든 트래픽을 차단하며, 명시적인 허용 규칙을 추가하는 방식으로 동작한다. 거부(Deny) 규칙은 없다.
- 인스턴스 단위 적용: 하나의 인스턴스에 최대 5개의 보안 그룹을 적용할 수 있다.
3.2. 네트워크 ACL (Network Access Control List)
네트워크 ACL은 서브넷 수준에서 트래픽을 제어하는 방화벽으로, 서브넷의 모든 리소스에 동일한 규칙을 적용한다. 보안 그룹보다 앞단에서 트래픽을 필터링하는 역할을 한다.
- Stateless 방식: 인바운드 트래픽에 대한 응답 트래픽을 명시적으로 아웃바운드 규칙에서 허용해야 한다. 예를 들어, 인바운드 포트 80을 허용했다면, 아웃바운드 ephemeral 포트(1024-65535)도 허용해야 정상적인 통신이 가능하다.
- 허용(Allow) 및 거부(Deny) 규칙 설정 가능: 특정 IP 주소로부터의 악의적인 접근을 명시적으로 차단하는 데 유용하다.
- 규칙 번호 기반 처리: 규칙마다 번호를 부여하며, 낮은 번호의 규칙부터 순서대로 평가하여 일치하는 첫 번째 규칙을 적용한다.
일반적으로는 상태 저장(Stateful) 기능으로 관리가 용이한 보안 그룹을 주로 사용하여 세밀한 접근 제어를 수행한다. 네트워크 ACL은 서브넷 전체에 대한 광범위한 방어(예: 특정 악성 IP 대역 전체 차단)가 필요할 때 보조적으로 사용하는 것이 일반적인 모범 사례이다.
4. VPC 연결 옵션
4.1. VPC 피어링 (VPC Peering)
VPC 피어링은 두 개의 VPC 간에 프라이빗 IP 주소를 사용하여 트래픽을 직접 라우팅할 수 있도록 하는 1:1 연결 방식이다. 마치 두 VPC가 동일한 네트워크에 있는 것처럼 통신할 수 있으며, 다른 AWS 계정이나 다른 리전의 VPC와도 연결이 가능하다. 단, 연결하려는 VPC 간의 CIDR 블록이 겹치지 않아야 하며, 연결 구조가 복잡해지면 관리가 어려운 Full-Mesh 형태가 된다는 단점이 있다.
4.2. Transit Gateway
Transit Gateway는 다수의 VPC와 온프레미스 네트워크를 중앙 허브(Hub)에 연결하여 네트워크를 간소화하는 서비스이다. Hub-and-Spoke 모델을 사용하여 모든 네트워크 트래픽이 Transit Gateway를 통해 라우팅되므로, 연결 관리가 중앙 집중화되고 확장성이 크게 향상된다. 수십, 수백 개의 VPC를 연결해야 하는 대규모 환경에 적합한 솔루션이다.
5. VPC 생성 실습 가이드
이론적인 내용을 바탕으로, AWS 관리 콘솔에서 직접 웹-DB 아키텍처를 위한 기본적인 VPC를 생성하는 과정을 단계별로 진행한다.
5.1. VPC 생성하기
가장 먼저 네트워크의 전체적인 틀이 될 VPC를 생성한다.
- AWS Management Console에서 VPC 서비스로 이동한다.
- 'VPC 생성' 버튼을 클릭한다.
- 아래와 같이 설정을 입력한다.
- 리소스 생성: VPC만
- 이름 태그: my-vpc
- IPv4 CIDR 블록: 10.0.0.0/16
- 테넌시: 기본값
5.2. 서브넷 생성하기
생성된 VPC 내부에 퍼블릭 서브넷과 프라이빗 서브넷을 각각 생성한다.
- VPC 대시보드의 '서브넷' 메뉴에서 '서브넷 생성'을 클릭한다.
- 퍼블릭 서브넷 생성:
- VPC ID: my-vpc 선택
- 서브넷 이름: public-subnet-1
- 가용 영역: ap-northeast-2a 선택
- IPv4 CIDR 블록: 10.0.1.0/24
- 프라이빗 서브넷 생성:
- VPC ID: my-vpc 선택
- 서브넷 이름: private-subnet-1
- 가용 영역: ap-northeast-2c 선택
- IPv4 CIDR 블록: 10.0.2.0/24
5.3. 인터넷 게이트웨이 및 라우팅 테이블 구성
퍼블릭 서브넷이 인터넷과 통신할 수 있도록 인터넷 게이트웨이를 생성하고 라우팅 테이블을 설정한다.
- 인터넷 게이트웨이 생성 및 연결:
- '인터넷 게이트웨이' 메뉴에서 '인터넷 게이트웨이 생성' 클릭 (이름: my-igw).
- 생성된 IGW를 선택하고, '작업' -> 'VPC에 연결'을 선택하여
my-vpc
에 연결한다.
- 퍼블릭 라우팅 테이블 생성 및 설정:
- '라우팅 테이블' 메뉴에서 '라우팅 테이블 생성' 클릭 (이름: public-rtb, VPC:
my-vpc
). - 생성된
public-rtb
를 선택하고 '라우팅' 탭 -> '라우팅 편집' 클릭. - '라우팅 추가'를 눌러 대상
0.0.0.0/0
, 대상(Target)인터넷 게이트웨이 > my-igw
를 선택하고 저장한다.
- '라우팅 테이블' 메뉴에서 '라우팅 테이블 생성' 클릭 (이름: public-rtb, VPC:
- 서브넷 연결:
public-rtb
의 '서브넷 연결' 탭 -> '서브넷 연결 편집' 클릭.public-subnet-1
을 선택하고 저장한다.
이로써 public-subnet-1
은 인터넷과 통신이 가능한 퍼블릭 서브넷이 되었다. 프라이빗 서브넷은 별도의 라우팅 설정을 하지 않았으므로 VPC 생성 시 함께 만들어진 기본 라우팅 테이블(Main Route Table)과 연결되어 인터넷 접근이 차단된 상태를 유지한다.
6. 실행 및 결과 확인
모든 설정이 완료되면 VPC 대시보드에서 생성된 리소스들을 확인할 수 있다. VPC, 서브넷 2개, 라우팅 테이블 2개(기본+생성), 인터넷 게이트웨이 1개가 정상적으로 생성되었는지 확인한다.

VPC, 서브넷, 라우팅 테이블, 인터넷 게이트웨이가 생성된 콘솔 화면 예시
이후 퍼블릭 서브넷에 웹 서버용 EC2 인스턴스를, 프라이빗 서브넷에 데이터베이스용 RDS 인스턴스를 배포하여 실제 아키텍처를 완성할 수 있다.
결론
지금까지 AWS VPC의 핵심 개념과 구성 요소, 그리고 기본적인 생성 실습을 진행하였다. VPC는 AWS 클라우드 인프라의 근간을 이루는 서비스로, 견고하고 안전한 아키텍처를 설계하기 위해서는 이에 대한 깊이 있는 이해가 필수적이다. 본 튜토리얼에서 다룬 내용을 바탕으로 VPC 흐름 로그(Flow Logs)를 통한 모니터링, VPC 엔드포인트(Endpoint)를 통한 보안 강화 등 고급 기능을 학습하여 더욱 정교한 네트워크 환경을 구축하는 기반을 마련할 수 있다.
추가적인 문의 사항이 있거나 더 나은 설계 방식에 대한 의견이 있다면 댓글을 통해 자유롭게 논의할 수 있다.
'기술' 카테고리의 다른 글
AWS VPC 확장: 다른 가용 영역에 서브넷을 추가하는 방법 (0) | 2025.06.24 |
---|---|
AWS VPC 생성 전 필수 체크! CIDR 블록과 예약 IP 완벽 분석 (0) | 2025.06.24 |
Docker Desktop 라이선스가 부담된다면? Colima 설치부터 Coolify 활용까지 (0) | 2025.06.23 |
GitLab CI/CD로 main → dev 브랜치 자동 역방향 머지(Merge-Back) 구현하기 (0) | 2025.06.23 |
Cursor IDE에서 AI 개발 생산성 10배 높이는 방법 (MCP, OpenRouter) (0) | 2025.06.23 |