[CS/네트워크] VPC와 Subnet(서브넷)

Gemini

 

VPC(Virtual Private Cloud)란?

VPC(Virtual Private Cloud)를 뜻하는 것으로,
Virtual Private에 주목해보면 말 그대로 가상 사설 네트워크임을 알 수 있다.

내가 그린 리소스들..^^

즉, 가상 네트워크 환경을 직접 구성해 그 안에 다양한 리소스를 배치하고 관리할 수 있는 서비스이다.

이전의 포스트에서는 IP와 포트에 대하여 다뤘다면, 이제는 그 IP가 어떤 네트워크 환경에서 동작하는가?

이걸 공부하기 위해 하는 것이 VPC 개념이다.

 

 

1-1. VPC 특징과 구성 요소

VPC는 사설 네트워크(Private Network) 기반으로 네트워크 망을 구성하며, 내부에 여러 리소스를 탑재할 수 있는 서비스이다.
대표적인 리소스는 다음과 같다.

• EC2 : 가상 서버(인스턴스)
• ELB : 로드 밸런서
• RDS : 데이터베이스 서비스
• Security Group(보안 그룹)
• Network ACL(네트워크 접근 제어 목록)

 

VPC에 포함되는 모든 리소스는 고유한 사설(Private) IP 주소와 네트워크 인터페이스를 가지며,
외부에서 접근이 필요할 경우 공인(Public) IP를 할당받을 수도 있다.

 

1-2. VPC의 사설 IP 대역

AWS에서 VPC를 구성할 때 사용할 수 있는 사설 IPv4 대역은 다음3개이다( 이전 포스트 폭습(폭풍복습의 줄임말입니다)한다)
(※ VPC는 사설 IPv4 주소만 할당 가능하며, 서브넷도 마찬가지임)

• 10.0.0.0/8 (Class A)
• 172.16.0.0/12 (Class B)
• 192.168.0.0/24 (Class C)

-> class A, class B, class C 이렇게 절대 겹치지 않는 3개의 대역으로 나뉘는 것을 확인할 수 있다( 사설 IP 포스트에서도 확인 가능)

| 중요 : 한 리전 내 여러 VPC가 있을 경우, IP 대역이 서로 겹치면 안 된다. 당연하면서도 중요한 이야기!

 

 

또한 한 리전(Region)에는 최대 5개의 VPC를 생성할 수 있으며,
각 리전에는 기본적으로 기본 VPC(Default VPC) 가 하나씩 제공된다.

 

 

1-3. VPC와 서브넷

VPC에는 위에서 언급한 사설 IP 대역을 직접 지정하거나,
그 하위 대역인 Subnet 을 나누어 할당할 수 있다.

예를 들어 10.0.0.0/8 대역을 선택했다면,
그 하위 서브넷인 10.0.0.0/16을 만들어 VPC에 할당하는 방식도 가능하다.

 

 

1-3-1. 서브넷(Subnet) 구성

VPC는 생성 시 지정한 사설 IP 대역을 그대로 사용하는 것이 아니라
서브넷으로 나누어 각 가용영역(AZ: Availability Zone)에 배치해 사용한다.

예를 들어, 10.0.0.0/16 대역을 VPC에 할당했다고 가정해보자.
이때 10.0.1.0/24, 10.0.2.0/24와 같이 다시 세분화하여 서브넷을 구성할 수 있다.

단! 서브넷을 다시 서브넷으로 세분화할 수는 없다(Subnet of Subnet 불가능). 서브넷이 가장 작은 단위라고 이해하면 된다.

이렇게 나눈 서브넷을 원하는 가용 영역(AZ)에 배치하여
고가용성·분산 배치를 실현할 수 있다.

1-3-2. 서브넷의 IP 주소 예약 규칙

서브넷을 구성할 때, 할당된 IP 전체를 인스턴스에 사용할 수 있는 것은 아니다.

AWS VPC는 각 서브넷마다 5개의 IP 주소를 자동으로 예약하여 사용자에게 제공하지 않는다.
그러면 어떤식으로 주소를 예약할까??

예약 순번용도

1	네트워크 주소 (서브넷 식별용)
2	VPC 라우터 (내부 라우팅)
3	AWS 제공 DNS
4	미래 확장을 위한 예약
5	브로드캐스트 주소

따라서 예를 들어 /24 대역(총 256개 IP)을 가진 서브넷을 만들면,
실제로 인스턴스에 할당 가능한 IP는 256 - 5 = 251개가 된다.

1-3-3. 서브넷 간 통신과 구성 전략

VPC 내부에는 가상 라우터가 내장되어 있다.

같은 VPC 내의 서브넷 간에는 기본적으로 자유로운 통신이 가능하다.

이 특성을 활용해 다음과 같이 서브넷을 역할별로 분리하는 것이 일반적이다.

• Public Subnet : 인터넷 게이트웨이를 통해 외부와 직접 통신하는 영역 (예: 웹 서버, 로드 밸런서 등)
• Private Subnet : 외부와 직접 연결되지 않는 내부 전용 영역
  (예: 데이터베이스, 백엔드 애플리케이션 등)

이런 설계를 통해 보안 강화와 서비스 안정성을 동시에 확보할 수 있다.

 

1-4. vpc와 외부 통신

VPC는 사설 IP 대역(Private IP Range)을 기반으로 구축되므로,
기본적으로는 공인 IP 대역(Public IP Range)과 직접 통신할 수 없는 것이 기본이다.

그러면 문득 의문이 들 것이다.
그럼 어덯게 외부와 통신하는 거지?

가령, 우리의 EC2 인스턴스 생성의 사례만 봐도,
EC2 인스턴스가 외부 인터넷과 통신할 수 있는 경우가 많다.
이는 VPC가 자체적으로 Public Subnet과 Private Subnet을 구분해 구성할 수 있기 때문이다.

 

Public Subnet

외부와 직접 통신 가능한 서브넷

주로 웹 서버, 로드 밸런서(ELB), Bastion Host(관리용 서버) 등 외부에서 접근이 필요한 리소스를 배치

Public Subnet의 인스턴스는 공인(Public) IP 또는 Elastic IP를 할당받고
인터넷 게이트웨이(Internet Gateway, IGW)를 통해 인터넷과 양방향 통신

💡 만약 인스턴스를 Public Subnet이 아닌 곳에 놓으면
외부에서 직접 접근할 수 없으며, 통신이 되지 않습니다.

• Internet Gateway(IGW) 생성

인터넷과 VPC를 연결하는 게이트웨이 역할을 수행
서브넷이 외부와 통신하려면 반드시 IGW가 존재해야 한다!

• 라우팅 테이블(Route Table) 설정

IGW만 만들어 놓는다고 퍼블릭 서브넷이 바로 되는 건 아니다
서브넷의 라우팅 테이블에 다음과 같이 기본 라우트(0.0.0.0/0)를 추가해야 한다!

즉,

0.0.0.0/0 → Internet Gateway

이 설정을 통해 네트워크 패킷이 인터넷으로 나갈 수 있는 경로(Route)가 생기는 것이다.
퍼블릭 서브넷 = IGW + 라우팅 테이블(0.0.0.0/0 → IGW)

양방향 통신이 가능한 두 가지 조건

 

Private Subnet

외부와 직접 통신이 불가능한 서브넷

주로 데이터베이스, 내부 서비스 서버, 백엔드 애플리케이션 등
외부 노출이 필요 없는 리소스를 배치

기본적으로 공인 IP가 없으며, 인터넷 게이트웨이(IGW)와도 직접 연결되지 않음

필요한 경우 NAT Gateway / NAT Instance를 통해
아웃바운드(내부 → 외부) 통신만 허용할 수 있음
(예: 보안 업데이트 다운로드, 외부 API 호출 등)

그래도 이런 경우도 내부 인스턴스가 인터넷으로 나가는 경우만 허용하고, 외부에서 내부로의 직접 접근은 차단한다.

 

 

 

 

 

---

 

이를 실제로 경험한 적이 있는데,
람다 함수에서 데이터베이스 접근에 실패했던 경험이 있다.

언뜻 보면 간단해 보였던 문제였는데, 알고 보니 AWS의 네트워크 아키텍처와 NAT Gateway의 동작 방식을 정확히 이해하지 못해서 발생했던 일이었다.

 

문제의 시작: 람다의 데이터베이스 접근 실패 !

 

데이터베이스(DB)는 보안을 위해 Private Subnet에 위치

NAT Gateway를 사용해 Private Subnet의 인스턴스들이 외부 인터넷으로 나갈 수 있게는 해두었다.

문제는 AWS Lambda 함수가 이 데이터베이스에 접근해서 데이터를 넣고(INSERT), 업데이트(UPDATE)하는 작업이 계속 실패했던 것.

 

처음에는 단순히 네트워크 설정 문제라고 생각했으나 아니었음...

 

• NAT Gateway의 방향성

이 문제를 풀기 위해서는 NAT Gateway의 방향성(Directionality)을 이해해야한다

 

NAT는 이름 그대로 네트워크 주소 변환(Network Address Translation)을 수행하는 장치이지만
단순히 주소를 바꿔주는 역할만 하는 게 아니라, 트래픽의 방향을 엄격하게 통제하기도 한다

 

방향동작예시

Outbound (내부 → 외부)	허용	Private Subnet의 서버가 OS 업데이트를 다운로드하는 경우
Inbound (외부 → 내부)	차단	외부 사용자가 Private Subnet의 DB에 직접 접근하려는 경우

 

즉, NAT Gateway는 내부에서 시작된 요청이 외부로 나갈 수 있도록 중개하는 역할을 한다.
반대로, 외부에서 시작된 요청이 내부로 들어오는 것은 구조적으로 막혀있다.

 

 

• 🤔람다가 데이터베이스에 접근하지 못한 이유

람다의 네트워크 위치에 따라 원인이 달랐다.

 

1. 람다가 VPC 외부에 있을 때

람다 함수는 기본적으로 VPC 외부에 존재하며,
인터넷과 직접 통신할 수 있는 환경에서 실행된다.

하지만 우리 DB는 Private Subnet에 있었고, Public IP도 없었다. NAT Gateway는 오직 내부에서 외부로 나가는 요청만 허용.
따라서 외부에 있는 람다가 내부의 DB로 직접 들어오는 요청은 NAT에 의해 차단될 수밖에 없었다.

 

 

2. 그렇다면 람다가 VPC 내부에 있을 때는?

 

람다 함수를 VPC에 연결하는 경우, 같은 VPC 내부에 있는 DB에는 당연히 접근이 가능할 거라고 생각했으나,
이 경우에도 접근이 실패했습니다!ㅜㅜ

 

람다와 DB가 같은 VPC에 있더라도, 보안 그룹(Security Group), 라우팅 테이블, 네트워크 ACL(Network Access Control List) 같은 세부 네트워크 설정이 올바르지 않으면 내부 통신이 막힐 수 있다.

 

 

해결 방법과 얻은 교훈
문제의 원인을 파악한 후, 해결책은 생각보다 간단해졌다.

 

람다가 VPC 외부 람다 함수를 DB와 같은 VPC(또는 같은 Private Subnet)로 이동시키고, DB의 보안 그룹에서 람다의 IP 또는 보안 그룹을 허용한다.
람다가 VPC 내부 DB의 보안 그룹, 네트워크 ACL, 라우팅 테이블 설정을 꼼꼼히 점검하여 내부 통신이 원활하게 이루어지도록 수정한다.

 

가장 중요한 교훈은 바로 이것이다.

 

NAT Gateway는 외부로 나가는 통신을 위한 것이지, 외부에서 내부로 들어오는 접근을 허용하는 수단이 아니다.

따라서 람다 함수가 Private Subnet에 있는 DB에 접근하려면, NAT Gateway를 통하는 외부 통신 경로가 아닌, VPC 내부 통신 경로를 설계해야 한다. 즉, DB와 람다를 같은 VPC 안에 두는 것이 가장 근본적인 해결책!

 

포트 포워딩 개념과 유사

 

가정용 공유기가 한 개의 공인 IP를 사용하면서 포트를 기준으로 내부 디바이스에 데이터를 전달하는 원리와 비슷

단, 여기서 말하는 포트 포워딩의 ‘포트’는 TCP 소켓 포트와 직접적 연관은 없음

 

• 통신 구조 정리

구분공인 IP 할당인터넷 게이트웨이 연결통신 방향

Public Subnet	가능	가능	외부 ↔ 내부 (양방향)
Private Subnet	불가	불가	내부 → 외부 (NAT 통해 제한적 허용)

다시 한 줄씩 정리해보자면,

VPC는 원래 사설 네트워크이므로 외부와 직접 통신 불가

Public Subnet : 공인 IP + 인터넷 게이트웨이를 통해 양방향 통신 가능
Private Subnet : 공인 IP가 없고 기본적으로 외부와 직접 통신 불가

Private Subnet이 외부로 나가야 할 때는 NAT Gateway/Instance를 사용