[AWS] VPC : 서브넷과 구성 요소 (Public/Private Subnet, IGW, NAT Gateway)

VPC는 AWS의 계정 전용 가상 네트워크로서 클라우드 운영에 있어서 필수적인 개념이다. 이번 포스팅에서는 VPC의 기본적인 구성 요소들에 대해서 살펴보려고 한다.
기본 단위인 서브넷의 종류인 Public Subnet과 Private Subnet을 구축하는 방법과, 그에 따라 필요한 구성 요소들을 살펴보자.
1. VPC의 개념
2. 서브넷의 개념과 네트워크 분할 방식
3. VPC 기본 구성 요소
- Public & Private Subnet
- IGW (인터넷 게이트웨이)
- NAT Gateway
- 트래픽 라우팅 : VPC Router, Routing Table
4. Public Subnet과 Private Subnet 구성 예시
5. 직접 AWS에서 VPC와 서브넷 구성하기
- VPC 생성하기
- 두 개의 서브넷 분리하기
- Public Subnet 설정 : IGW 연결과 라우팅 테이블 설정
- Private Subnet 설정 : NAT Gateway 연결과 라우팅 테이블 설정
VPC (Virtual Private Cloud)
AWS 계정 전용 가상 네트워크로, 다른 가상 네트워크와 논리적으로 분리된 독립적인 환경을 제공한다.
온프레미스 환경에서 네트워크 담당자는 물리적 네트워크 장비를 관리하고, 사설망을 구성하며, 방화벽 설정 및 IP 대역 관리를 통해 서버의 네트워크를 구성한다.
클라우드 환경에서의 이러한 작업은 VPC를 통해 수행 가능하다. 온프레미스 환경에서 네트워크 담당자가 하던 역할을 클라우드 내에서 구현할 수 있게 해준다.
- 사설 네트워크의 개념
- 내 계정의 AWS라는 가상 데이터센터에서 사설망을 구축하는 것으로 이해할 수 있다.
- 기본적으로 Private Network로 구성되며, 외부와 격리된 네트워크 환경을 제공한다.
- 리전 단위로 구분된다. 예를 들어 서울 리전의 데이터센터 내부망과 홍콩 리전의 데이터센터 내부망이 각각 독립적으로 관리된다.
- 가상 네트워크 구성
- VPC 내부에서 AWS 리소스를 실행할 수 있는 환경 제공
- IP 주소 범위 및 VPC 범위를 사용자 정의로 설정
- 서브넷 추가, 보안 그룹 연결, 라우팅 테이블 구성 등을 통해 세부적인 네트워크 관리
- VPC 사용 사례
- 부여된 VPC의 IP 대역을 분할하여 다양한 서브넷을 구성.
- EC2, RDS 등 AWS의 컴퓨팅 서비스를 특정 네트워크에서 실행하여 리소스를 보호하고 관리.
- 보안 설정을 통해 외부 접근 제어 : IP 블록 설정. 방화벽 역할을 하는 보안 그룹 구성.
사설망
- 사설망 내부는 외부 인터넷 망으로 통신이 불가능한 사설 IP로 구성됨
- 외부로 통신할 때에는 공인 IP로 사용 (NAT을 통해 사설망 내부의 사설 IP 주소를 외부에서 사용할 수 있는 공인 IP 주소로 변환)
- 하나의 망에는 Private IP를 부여받은 기기 + NAT 기능을 갖춘 Gateway로 구성
NAT
- 사설 IP가 공용 IP로 통신할 수 있도록 주소를 변환해 주는 방법
- Dynamic NAT : N개의 Public IP : 사설 IP에 Public IP Pool(가용 가능한 공인 IP) 중 현재 사용 가능한 한개를 임대해주어 외부와 통신
- Static NAT : 여러 개의 Public IP : 사설 IP 하나하나에 각각 다른 Public IP를 할당해주는 것.
- Port Address Translation (PAT) : 하나의 Public IP를 Port로 구분하여 여러 사설 IP에 할당해주는 방식 (Gateway = NAT)
서브넷 (Subnet)
온프레미스 환경에서 네트워크 담당자는 대규모 네트워크를 효율적으로 관리하기 위해 물리적 또는 논리적으로 네트워크를 나누어 서브넷을 구성한다. 서브넷은 각 부서나 서비스에 적합한 네트워크를 제공하며, 네트워크 트래픽을 분리하고 보안을 강화하는 데 중요한 역할을 한다.
AWS에서는 VPC 내부에서 서브넷을 구성하여 이와 같은 네트워크 분리 및 관리 작업을 클라우드 상에서 구현할 수 있다.
- 서브넷 : VPC에 할당된 IP 주소 공간을 더 작은 네트워크로 분할한 논리적 단위
- 각각의 서브넷은 특정 가용 영역(AZ, Availability Zone) 안에서 동작
네트워크 분할
1. CIDR Block Range로 IP주소 지정 (IPv4, IPv6)
2. IPv4의 경우 4개의 Host Bit (/28) ~ 16개의 Host Bit (/16)의 범위 안에서 지정 가능
3. 즉 하나의 서브넷은 2^4 ~ 2^16개 범위 내의 Address를 소유할 수 있다. (예약 주소 5개를 제외하고 Host IP로 사용 가능)
4. VPC 생성 시 할당한 IP 대역을 CIDR을 통해서 범위를 분할하는 것이 서브넷 생성의 기본 개념이다.

1. VPC에 할당된 IP 대역이 10.0.0.0/24일 경우, 네트워크 주소와 호스트 주소를 계산해보면 다음과 같다.
- 10.0.0.0/24 : 00001010.00000000.00000000.00000000 (네트워크 / 호스트)
- 즉 해당 VPC는 2^8개의 Address를 소유할 수 있다. (예약주소 제외)
2. 위의 그림에서는 해당 VPC를 두 개의 서브넷으로 분할하였다.
- Subnet A 10.0.0.0/25 : 00001010.00000000.00000000.00000000
- Subnet B 10.0.0.128/25 : 00001010.00000000.00000000.10000000
- 즉 추가된 1비트로 서브넷 A와 B를 구분하고, 각각 2^7개의 Address를 소유할 수 있다. (예약주소 제외)
3. AWS 서비스 및 인스턴스 등을 위처럼 분리된 네트워크(서브넷)에서 프로비저닝 할 수 있으며, 서브넷 단위로 보안 설정, 트래픽 제어 등을 수행할 수 있다.
4. 특정 서비스나 인스턴스의 집합을 관리하기 위한 맞춤형 네트워크 그룹을 생성하는 것이 서브넷 생성의 의의이다.
- 예: Public Subnet에는 외부에서 접근 가능한 웹 서버를 배치하고, Private Subnet에는 데이터베이스 서버와 같은 민감한 리소스를 배치하여 보안을 강화한다.
VPC 기본 구성 요소
1. Public Subnet : 외부에서 인터넷을 통해 연결할 수 있는 서브넷.
- 웹서버 등 유저에게 노출되어야 하는 인프라를 프로비저닝하기 위한 용도
- 외부 인터넷과 통신 : IGW(인터넷 게이트웨이) 사용 → 외부 인터넷으로 요청 가능 & 외부 인터넷에서 접근 가능 (서브넷에 프로비전된 웹 서버 등에 인터넷을 통해 접근 가능)
- 서브넷 내부의 서비스에 Public IP 부여 가능.
2. Private Subnet : 외부에서 인터넷을 통해 연결할 수 없는 서브넷
- 데이터베이스 등 노출되어서 안되는 인프라를 프로비저닝하기 위한 용도
- 외부 인터넷과 통신 : 외부 인터넷과 경로가 없어 통신 불가능.
- NAT Gateway : Public Subnet에 위치한 NAT Gateway를 매개체로 하여 외부 인터넷에 요청 가능(접근은 불가능)
- Private Subnet 접근 : 기본적으로는 접근 불가능. Bastion Host, VPC Endpoint 등의 방식을 사용하여 접근.
- 서브넷 내의 AWS 서비스(EC2, RDS 등)에 기본적인 인터넷 기반 방식으로 접근 불가능
- 서브넷 내부의 서비스에 Public IP 부여 불가능.
- 같은 VPC 내부의 리소스와는 통신이 가능하다.
3. IGW (인터넷 게이트웨이) : VPC가 외부 인터넷과 통신할 수 있도록 경로를 만들어 주는 리소스
- IGW와의 연결 여부 : Public 서브넷과 Private 서브넷을 결정적으로 구분하는 기준
- Route Table에서 경로 설정 후 접근 가능. (해당 서브넷의 Route Table에서 IGW 경로 추가)
- VPC당 하나의 인터넷 게이트웨이만 생성 가능, 직접 생성 후 VPC 연동 필요.
4. NAT Gateway : Private 서브넷의 리소스가 외부 인터넷과 통신하기 위한 매개체 역할을 하는 AWS 관리형 서비스
- Private Subnet에서 인터넷 요청이 필요한 경우 사용. : ex) Private 서브넷 내의 EC2 인스턴스에 배포 시 패키지 다운로드
- 시간 당 비용 발생, 트래픽 당 비용 발생. Public Subnet에 위치해야 한다.
- NAT Instance : 단일 EC2 인스턴스를 통로로 이용 (비권장)
- NAT Gateway : AWS에서 제공하는 서비스 → 고가용성이 확보된 관리형 서비스(권장)
<함께 보기> Private EC2 연결 방법 : Bastion Host & SSM & Instance Connect Endpoint
https://sjh9708.tistory.com/256
[AWS] Private EC2 연결 방법 : Bastion Host & SSM & Instance Connect Endpoint
Private Subnet에 위치한 EC2는 인터넷 게이트웨이(IGW)와 퍼블릭 IP가 없기 때문에 외부에서 직접 접근할 수 없다. 따라서 인스턴스에 접속하거나 접근하려면 우회적인 방식을 사용해야 한다. 이번
sjh9708.tistory.com
트래픽 라우팅
1. VPC Router : 서브넷에서 오고가는 트래픽을 라우팅해주는 VPC의 가상 라우터. VPC당 1개의 VPC Router만 존재.
- 서브넷의 트래픽은 VPC 라우터를 거쳐서 목적지에 도달
- 같은 VPC의 서브넷 A와 B 간 통신, 서로 다른 VPC 간 통신 → 라우터 경유
- 같은 서브넷의 리소스 간 통신 → 라우터 경유 X, 직접 통신
- VPC 생성 시 자동으로 생성되며, 별도로 관리할 필요가 없음.
- 별도의 설정이 불가능하며 Routing Table만 관리 가능
2. 라우팅 테이블 : VPC 라우터에서 트래픽을 매핑해주는 Table.
- 각 서브넷은 서로 다른 라우팅 테이블을 통해 VPC Router와 연결.
- 구성 요소
- Destination : 트래픽의 주소
- Target (Route) : 트래픽을 실제로 보내줄 대상 → 논리적 리소스의 아이디로 표현
보안
1. 보안 그룹 : 인스턴스 단위에서 트래픽을 제어하는 방화벽 역할
2. NACL (Network Access Control List) : 서브넷 단위에서 트래픽을 제어하는 방화벽 역할
<함께 보기> 보안그룹와 NACL
https://sjh9708.tistory.com/254
[AWS] VPC : 보안 그룹과 NACL(Network Access Conrol List)
AWS의 가상 네트워크인 VPC에서 네트워크 보안을 제공하기 위한 두 가지 중요한 구성 요소로서 보안 그룹과 NACL가 있다. 이번 포스팅에서는 해당 두 종류 방식의 사용 목적과 차이점에 대해서 살
sjh9708.tistory.com
통신 방식 비교
Private Subnet | Public Subnet | |
같은 VPC 안의 서브넷 및 서비스 간의 통신 | 기본적으로 가능 : Private IP를 통해 가능 | 기본적으로 가능 : Private IP를 통해 가능 |
외부 인터넷과의 통신 | 기본적으로 직접 통신 불가능 & 간접 통신 가능 : NAT Gateway 또는 NAT 인스턴스 사용 | 직접 통신 가능 : 퍼블릭 IP와 IGW를 통해 통신 |
AWS 서비스와의 통신 | 1. NAT Gateway를 통해 인터넷 경유 통신 2. VPC Endpoint로 퍼블릭 인터넷 없이 프라이빗하게 통신 |
1. IGW를 통해 퍼블릭 인터넷으로 통신 2. VPC Endpoint로 퍼블릭 인터넷 없이 프라이빗하게 통신 |
다른 VPC와의 통신 | 1. 통신할 대상 VPC들의 내부 리소스를 퍼블릭 네트워크에 노출시키는 방식 (비효율적) 2. VPC Peering, VPN, Transit Gateway 등 활용 |
Public Subnet의 구성 예시

- VPC 대역을 2개의 Public Subnet으로 구성한 모습이다.
- Public Subnet은 IGW를 경유하여 외부 인터넷과 통신한다.
- 서브넷마다 Routing Table을 설정하여, 트래픽의 목적지에 따라 요청을 어디로 보낼지 결정한다.
- CIDR 매핑 규칙에 따라서 트래픽을 해당 영역으로 보낸다. local은 로컬 VPC 내부, igw는 인터넷 게이트웨이를 의미한다.
- 라우팅 테이블의 우선순위는 보다 구체적인 경로가 우선 적용된다. 즉 10.0.0.0/16(local)과 0.0.0.0/0(igw)가 동시에 매칭되면, 더 구체적인 10.0.0.0/16 경로가 먼저 사용된다.
- 즉 local 대역대의 트래픽을 우선적으로 매칭하여 VPC 내부로 트래픽을 보내고 나머지는 인터넷 게이트웨이를 통해 외부 인터넷으로 트래픽을 전송하게 된다.
Private Subnet의 구성 예시

- VPC 대역을 2개의 AZ에 각각 1쌍의 Public Subnet과 Private Subnet으로 구성한 모습이다.
- Public Subnet은 IGW를 경유하여 외부 인터넷과 통신한다.
- Private Subnet은 외부 인터넷으로 아웃바운드 요청을 보내기 위해서 NAT Gateway을 중간 매개체로 사용한다.
- NAT Gateway는 Public Subnet에 위치하여 외부 인터넷과 통신이 가능하다.
- 위와 마찬가지로 각 서브넷마다 Routing Table을 설정하여, 트래픽의 목적지에 따라 요청을 어디로 보낼지 결정한다.
- Private Subnet의 라우팅 테이블에는 NAT Gateway에 대한 트래픽 규칙을 매핑시켜야 한다.
AWS에서 직접 VPC 구축해보기
1. VPC 생성하기
VPC 생성 방법은 크게 두 가지가 있다.
- VPC와 다른 리소스 자동 생성 → VPC, 서브넷, 라우팅 테이블, 네트워크 연결 등을 쉽게 생성 가능
- 수동으로 VPC 및 구성 리소스 생성
1-1. VPC와 다른 리소스 자동 생성

다음 사진은 VPC와 다른 리소스들을 자동으로 구성하는 방식이다. 인터페이스를 보면 가용 영역마다 Public Subnet과 Private Subnet을 어떻게 배치할 것인지, NAT 게이트웨이, VPC 엔드포인트 등의 리소스들을 자동으로 구성해준다.
범용성이 높고 편리한 방식이기 때문에 자주 사용되는 방식이지만, 일단 위에서 살펴본 요소들을 하나하나 살펴보기 위해서 수동으로 구성해보는 방식을 사용해보려고 한다.
1-2. VPC 직접 생성

- VPC 네트워크 전체의 CIDR을 10.0.0.0/16으로 설정하여 2^16개의 Host를 가질 수 있도록 설정하였다. (예약 주소 제외)
- 앞에서 말했듯 CIDR Block의 범위는 IPv4의 경우 4개의 Host Bit (/28) ~ 16개의 Host Bit (/16)의 범위 안에서 지정 가능하다.

- VPC 생성 시 라우팅 테이블, 보안그룹, NACL이 디폴트로 1개씩 자동으로 생성된다.
2. 서브넷 생성


- VPC를 두 개의 서브넷으로 분리시켰다. 10.0.0.0/16 → Subnet A(10.0.0.0/24) & Subnet B(10.0.1.0/24)
- 각 서브넷을 위치시킬 가용 영역 AZ를 설정해야 한다. 두 서브넷을 각각 다른 가용영역에 위치시켰다.
- 앞으로 A 서브넷을 Public Subnet, B 서브넷을 Private Subnet으로 설정하는 과정을 살펴볼 것이다.
3. Public 서브넷 설정
3-1. Public IP 주소 할당 설정

- 자동 IP 할당 설정 체크 : 해당 서브넷에 프로비저닝한 웹 서버에 접근가능하게 하기 위해서 IP를 자동으로 할당해주도록 하자.
- Public Subnet 내부 서비스들에는 Public IP를 할당할 수 있다고 했었다. (Private Subnet은 IGW 연결이 없으므로 불가능)
3-2. 인터넷 게이트웨이 생성 및 VPC 연결

- Public Subnet이 외부 인터넷과 통신하기 위한 인터넷 게이트웨이 한 개를 생성해주었다.
- Public Subnet이 Private Subnet과 구분되는 결정적인 요소가 IGW와의 연결이었다.
- VPC당 IGW는 단 1개만 존재할 수 있다는 점을 다시 언급한다. (AWS Certification 단골 문제라고 한다.)
3-3. Public Subnet 전용 라우팅 테이블 생성

- 서브넷 별로 라우팅 테이블을 설정할 수 있다고 하였다. Public Subnet을 위한 라우팅 테이블을 만들어주자.

- 생성된 라우팅 테이블을 확인해보자. 해당 라우팅 테이블에 IGW로의 경로 매핑 정보를 추가해줄 것이다.
3-4. 라우팅 테이블 편집

- 라우팅 편집으로 들어가면 기본적으로 존재하는 로컬 VPC로의 매핑 정보를 확인할 수 있다.
- 이곳에 IGW로의 경로를 매핑 추가해 줄 것이다.
- 해당 경로 외의 모든 경로는 외부 인터넷으로 매핑하기 위해 0.0.0.0/0을 Destination으로 설정하고 Target으로 아까 생성한 IGW를 설정해주었다.
3-5. 라우팅 테이블에 서브넷 연결

- 서브넷을 생성하면 기본적으로 라우팅 테이블과 명시적으로 연결되어 있지 않다.
- Public Subnet으로 사용될 서브넷을 라우팅 테이블에 명시적으로 연결하여, 해당 서브넷은 해당 라우팅 테이블의 규칙을 따르겠다는 것을 설정해주자.
3-6. EC2 프로비전 및 테스트


- 우리가 지금까지 설정한 Public 서브넷에 EC2 인스턴스 하나를 생성해주자.
- 외부에서 접근이 가능하도록 인바운드 규칙을 적절히 설정해주자 (지금은 모든 트래픽을 모든 포트 범위에 대해서 허용해주었다)
- Public IP 자동 할당 옵션을 위에서 활성화시켜주었으므로 사용 가능하다. Public IP를 부여하여 외부에서 접근 가능하도록 설정해보자.

- 외부 인터넷으로부터 패키지를 Install 가능 (Outbound 트래픽 허용)
- 외부 인터넷에서 접근 가능 : 기본 EC2 Connection으로 접속 가능 (Inbound 트래픽 허용)
- IGW 연결: Outbound 트래픽(외부 인터넷으로 나가는 트래픽)을 허용. (반환되는 응답 트래픽(인바운드)는 보안 그룹과 관계없이 자동 허용됨)
- 보안 그룹 인바운드 설정: 외부에서 들어오는 신규 Inbound 트래픽을 허용.
4. Private 서브넷 설정
4-1. EC2 프로비전 및 접근

- 위와 마찬가지로 Private Subnet에 EC2 인스턴스를 프로비저닝 해보자.
- Private Subnet은 Public IP 자동 할당이 불가능하다.

- 인스턴스에 연결하려고 보니 Pubic 서브넷에 프로비저닝 했을 때와 달리 연결이 불가능하다.
- 인터넷 게이트웨이가 없기 때문에 Bastion Host나 VPC Endpoint 등을 활용하여 연결해야 한다. 해당 과정은 이후 포스팅에서 다루어보려고 한다.
Private Subnet의 EC2에서는 인터넷 게이트웨이가 연결되어 있지 않기 때문에 소스코드를 다운로드받거나 패키지를 다운로드 받는 등의 운영에 필요한 인터넷 작업이 불가능한 상태이다.
따라서 Public Subnet에 NAT 게이트웨이를 생성하고, Private Subnet의 라우팅 테이블을 NAT Gateway로의 규칙을 추가해주어 중간 매개체를 통해 인터넷 통신이 가능하도록 설정해보자.
4-2. NAT 게이트웨이 생성

- NAT 게이트웨이가 위치할 서브넷은 IGW 연결이 되어있는 Public Subnet이어야 한다.
4-3. 라우팅 테이블 생성


- Private Subnet의 라우팅 규칙을 정의하기 위해서 앞의 과정과 유사하게 라우팅 테이블을 생성하고 서브넷과 연결시켜주자.
4-4. 라우팅 편집

- Public Subnet에서는 나머지 트래픽에 대해서 IGW와 매핑시켜주었었다.
- Private Subnet에서는 IGW 대신 앞서 생성한 NAT Gateway와 매핑시켜주자. 즉, Local 트래픽이 아니라면 NAT Gateway를 통해 외부로 나가도록 설정해주자.
4-5. 아웃바운드 요청 확인

- EC2 내부에서 curl 요청을 보냈을 때 응답이 오는 것을 확인할 수 있다.
- 즉 NAT Gateway를 경유하여 외부 인터넷과 통신이 이루어진다는 것을 확인할 수 있다.
References
https://docs.aws.amazon.com/
docs.aws.amazon.com
쉽게 설명하는 AWS 기초 강의 강의 | AWS 강의실 - 인프런
AWS 강의실 | AWS 여정을 시작하기 위해 가장 필요한 내용을 담았습니다., 안녕하세요. AWS 강의실입니다.AWS 공식 커뮤니티 빌더이자 2만명의 구독자를 보유한 AWS Only 강의 유튜브의 경험으로 AWS를
www.inflearn.com
'Backend > AWS' 카테고리의 다른 글
[AWS] VPC Endpoint : Private 네트워크에서 AWS 서비스 접근 (0) | 2025.02.04 |
---|---|
[AWS] VPC : 보안 그룹과 NACL(Network Access Control List) (0) | 2025.02.04 |
[AWS] ELB : 개념 및 구성 요소 (+ EC2 Autoscaling X ALB 적용) (0) | 2025.01.15 |
[AWS] Autoscaling : EC2 클러스터 구성 및 스케일링 정책 적용 (1) | 2025.01.14 |
[AWS] EC2 : ENI & Elastic IP 설정을 통한 Public IP 고정시키기 (1) | 2025.01.13 |