[Part1 기본 개념 2편] VPC와 서브넷

들어가며: "왜 VPC부터 만들어야 하지?"

제가 느꼈을 때 처음 AWS를 배울 때 가장 어렵고 좌절하는 지점은 크게 2곳인 것 같습니다. 하나는 IAM 이고 다른 하나는 글에서 다룰 Network 입니다.

많은 블로그와 강의에서 Ec2 하나 띄울 때 VPC, Subnet 설정이나 설계는 대충하고 넘어가거나 아예 다루지 않습니다. Ec2를 띄울 때는 다음과 같은 질문에 답변할 수 있어야 하고 설정할 수 있어야 합니다.

처음 이 질문을 봤다면 아마 답변하지 못하시는 분들이 대부분일 것입니다. 우리가 배웠던 (혹은 배울) 네트워크 용어와 클라우드에서 사용하는 네트워크 용어가 연결이 안되고 약간 다르게 생겼기 때문입니다.

이 글을 다 읽고 위 4가지 질문에 대답할 수 있게 되고, 이론으로만 존재했던 지식을 클라우드 네트워크 설계/구현할 때 활용할 수 있게 될 것입니다.

복습

OSI 7계층 - 네트워크 통신 책임 분리

VPC, Subnet으로 넘어가기 전에 네트워크 가장 기본기인 OSI 7계층과 TCP/IP 5계층을 짚고 넘어가겠습니다. 소프트웨어 설계 원칙을 공부해보셨던 분이라면 "단일 책임 원칙" 이라는 단어를 들어보셨을겁니다. 좋은 소프트웨어는 하나의 모듈이 하나의 책임만 진다는 원칙인데, 네트워크도 통신이라는 복잡한 문제를 "이 계층은 이것만 책임진다"는 원칙하에 잘게 쪼갠 설계를 OSI 7계층이라고 부릅니다.

OSI 7계층 vs TCP/IP 5계층

네트워크 전공 서적에서는 OSI 7계층을 기준으로 배웁니다. 하지만 막상 실무에서는 TCP/IP 5계층을 더 자주 듣고, 사용합니다. 결국엔 둘 다 네트워크를 설명하는 모델이긴 합니다만, 약간의 차이가 존재합니다.

OSI 7계층은 ISO(국제표준화기구)가 만든 이론 모델입니다. "네트워크 통신을 이렇게 설계하면 어떨까요?"라는 질문에 기반한 표준에 가깝습니다. 즉, 실제 구현보다 개념 정의와 교육 목적이 짙습니다.

그와 달리 TCP/IP 모델을 인터넷이 실제로 구현된 방식을 정리한 실용 모델입니다. OSI에서 잘 쓰이지 않거나 함께 처리되는 계층을 통합해서 OSI 7계층보다 단순하게 만들었습니다.

1OSI 7계층                     TCP/IP 5계층 (4계층으로 보기도 함)
2┌─────────────────┐
3│  7. Application │ ──┐
4├─────────────────┤   │         ┌─────────────────┐
5│  6. Presentation│ ──┼────────▶│  5. Application │  HTTP, gRPC, DNS...
6├─────────────────┤   │         └─────────────────┘
7│  5. Session     │ ──┘
8├─────────────────┤             ┌─────────────────┐
9│  4. Transport   │ ──────────▶│  4. Transport    │  TCP, UDP
10├─────────────────┤             └─────────────────┘
11│  3. Network     │ ──────────▶ ┌─────────────────┐
12├─────────────────┤             │  3. Network     │  IP, ICMP
13│  2. Data Link   │ ──┐         └─────────────────┘
14├─────────────────┤   │         ┌─────────────────┐
15│  1. Physical    │ ──┼────────▶│  2. Data Link   │  Ethernet, Wi-Fi
16└─────────────────┘   │         ├─────────────────┤
17                      └────────▶│  1. Physical    │  케이블, 광섬유
18                                └─────────────────┘
Copy

각 계층이 하는 일

지금부터는 TCP/IP 5계층을 기준으로 설명하겠습니다. 더 하위의 계층으로 갈수록(숫자가 더 작아질수록) 물리적인 구현에 가깝고, 상위 계층으로 갈수록 논리적 구현에 가깝습니다. 또한 각 계층은 아래 계층의 구체적인 구현은 몰라도 됩니다(관심사 분리). 예를 들어 HTTP(L7)는 자신의 데이터가 광섬유(L1)로 전달되는지 Wi-Fi(L1)으로 전달되는지 신경쓰지 않습니다.

각 계층을 지나는 방법 - 캡슐화,역캡슐화

여러분의 요청을 각각의 네트워크 계층이 맡은 일을 수행할 수 있도록 정보를 기록해야 합니다. ISO 는 이 정보를 헤더에 기록하기로 약속했습니다.

예를 들어 브라우저에서 google.com도메인으로 HTTP를 통해 데이터를 요청할 때를 가정해보겠습니다. 여러분의 "구글 웹페이지를 가져와줘"라는 요청이 네트워크 계층을 타고 내려오면서 구글의 웹페이지가 컴퓨터가 있는 곳까지 떠날 준비를 하고(캡슐화, Encapsulation), 구글의 웹페이지가 있는 컴퓨터에 도착한 이 요청("구글 웹페이지를 가져와줘")은 각 계층에서 필요한 정보만 파악한 후 위로 보냅니다(역캡슐화, Decapsulation).

1데이터가 계층을 내려오며 헤더가 쌓이는 과정
2
3L7  [HTTP 데이터 (GET /index.html)]
4         │ TCP 헤더 추가 (포트 443)
5         ▼
6L4  [TCP 헤더 |  HTTP 데이터]
7         │ IP 헤더 추가 (목적지 IP)
8         ▼
9L3  [IP 헤더 | TCP 헤더 |  HTTP 데이터]
10         │ Ethernet 헤더 추가 (목적지 MAC)
11         ▼
12L2  [ETH 헤더 | IP 헤더 | TCP 헤더 |  HTTP 데이터  | ETH 트레일러]
13         │
14         ▼
15L1  010101001110101010... (전기 신호)
Copy

이 구조가 중요한 이유는 클라우드의 보안 그룹·NACL·로드밸런서가 모두 특정 계층의 헤더를 기준으로 동작하기 때문입니다. 나중에 배울 Security Group은 L4(포트+프로토콜) 기준, ALB는 L7(HTTP 헤더, URL 경로) 기준으로 트래픽을 처리합니다. 이 차이를 이해하고 있어야 어떤 상황에서 무엇을 써야 하는지가 명확해집니다.

L2와 L3분리 - VPC와 Sunet의 핵심

모든 계층 중 VPC와 서브넷 설계에서 가장 중요한 구분은 L2와 L3의 경계입니다.
VPC와 서브넷의 모든 설계는 L2와 L3에서 출발합니다.

- L2: 같은 네트워크(브로드캐스트 도메인) 안에서는 라우터 없이 MAC 주소로 바로 통신한다.
- L3: 다른 네트워크에 있는 호스트와 통신하려면 반드시 라우터(L3 장비) 를 거쳐야 한다.

1L2 통신 (같은 서브넷)                 L3 통신 (다른 서브넷)
2
3Host A ◀──────────▶ Host B        Host A ──▶ 라우터 ──▶ Host C
410.0.1.10           10.0.1.20     10.0.1.10  (L3 장비)  10.0.2.10
5      └── 같은 서브넷 ──┘                └── 다른 서브넷 ──┘
6      라우터 없이 직접 통신                  반드시 라우터 경유
Copy

CIDR 계산하기

이제 마지막으로 VPC, Subnet 설계시 반드시 알고 있어야 할 CIDR을 간단하게 설명하고 복습을 마무리 하겠습니다.
CIDR(Classless Inter-Domain Routing)은 앞쪽 N비트는 네트워크, 뒤쪽 32-N비트를 호스트로 나누는 표기법입니다.

/16이라고 쓰면 "앞 16비트가 네트워크 식별자"라는 뜻입니다. 즉 10.0.x.x인 모든 주소는 같은 네트워크에 속합니다.

110.0.0.0/16
2└┬─┘ └┬┘
3네트워크 호스트
416비트 16비트 → 65,536개 주소 사용 가능
Copy

데이터센터의 기본구조

클라우드에서 VPC, Subnet을 이해하려면, 온프레미스(물리환경)에서 네트워크 구조를 알고 있어야 합니다. 회사가 운영하는 데이터센터의 모습을 매우 축약해서 그려보면 아래와 같습니다.

1              [ 인터넷 ]
2                  │
3            ┌─────┴─────┐
4            │   라우터    │  ← 외부와 연결되는 단 하나의 출입구
5            └─────┬─────┘
6                  │
7            ┌─────┴─────┐
8            │ 방화벽/NAT  │  ← 내부 IP ↔ 공인 IP 변환
9            └─────┬─────┘
10                  │
11       ┌──────────┼──────────┐
12       │          │          │
13   [Web LAN]  [App LAN]  [DB LAN]   ← 용도별로 분리된 네트워크 대역
14   10.0.1.0/24 10.0.2.0/24 10.0.3.0/24
Copy

여기서 우리가 설계 시 결정한 것은 4가지입니다.
1. 사설IP대역을 하나 정한다 - 위의 예시에서는 10.0.0.0/16으로 정했습니다.
2. 이 사설IP대역을 용도별로 분리합니다. - Web, App, DB 으로 분리
3. 외부와 통신할 출입구(라우터, NAT)를 배치합니다.
4. 누가 누구한테 갈 수 있는지(라우팅 테이블, 방화벽 규칙)을 정의합니다.

VPC가 하는 일이 위 4가지입니다. 온프레미스와 클라우드의 차이는 물리 케이블을 사용하는지, 소프트웨어로 정의된 네트워크(SDN: Software-Defined Networking)을 사용하는지의 차이일뿐입니다.

소프트웨어로 네트워크 정의하기

위에서도 언급했지만 결국 VPC, Subnet, Internet Gateway 는 물리 케이블과 환경을 SDN을 통해 클라우드 회사(CSP)의 인프라를 사용할 수 있도록 만든 가상 데이터 센터입니다.

VPC

VPC(Virtual Private Cloud)는 AWS가 운영하는 거댛나 물리 네트워크 위에서 나(고객)만 볼 수 있는 사설 네트워크 공간을 소프트웨어로 잘라 준 것입니다.

여기서 핵심은 "나(고객)만 볼 수 있다"입니다. 다른 고객의 Ec2가 AWS 데이터센터의 같은 물리 호스트에 떠 있더라도, 그 Ec2의 패킷은 내 VPC로 절대 들어오지 못합니다. AWS에서는 이를 가능하게 하기 위해 Mapping Service + VXLAN/GENEVE류 오버레이네트워크를 사용했습니다. (관련 내용은 아래에서 설명하겠습니다.)

우리가 처음 VPC를 설계할 때 설계해야할 5가지의 큰 골격은 아래와 같습니다.

1[ 1. VPC CIDR 정하기 ]         예: 10.10.0.0/16
2        │
3        ▼
4[ 2. 서브넷으로 잘게 쪼개기 ]      예: 10.10.1.0/24 (web), 10.10.11.0/24 (db)
5        │
6        ▼
7[ 3. 라우팅 테이블로 길 만들기 ]   "0.0.0.0/0 → IGW", "10.0.0.0/16 → local"
8        │
9        ▼
10[ 4. 외부 출입구 달기 ]          IGW(공용) 또는 NAT GW(사설)
11        │
12        ▼
13[ 5. 보안 규칙 정하기 ]          SG(Secutiry Group) / NACL
Copy

Subnet - VPC를 쪼개는 이유

왜 VPC를 Subnet으로 굳이 쪼개야할까?

반대로 질문을 해보겠습니다. "10.10.0.0/16 한 덩어리 안에 EC2든 RDS든 다 넣으면 되지 않나?" 물론 기술적으로는 가능합니다. 하지만 크게 2가지 이유때문에 이렇게 만들지 않습니다.

1. 가용 영역(Availability zone 이하 AZ) 분리
서브넷은 단 하나의 AZ에만 속합니다. (이 부분은 AWS에서 정한 규칙이므로 다른 CSP와는 다를 수 있습니다.) 즉, "서울 리전의 ap-northeast-2a에 있는 서브넷"과 "ap-northeast-2c에 있는 서브넷"은 다른 영역에 있는 네트워크입니다.
가용 영역을 분리하는 것은 고가용성(High Availabilty 이하 HA)의 필수 조건입니다. 지금은 "AZ를 분리하면 서비스를 정상 운영할 수 있는 토대가 되는구나"정도로 넘어가겠습니다.

2. 외부 접근 가능 여부 분리
"인터넷에서 직접 볼 수 있는 서버(웹서버, ALB 등)"과 "절대 인터넷에 노출되면 안되는 서버(RDS, 내부 워커 등)"는 명확히 분리되어 관리해야 합니다. 이걸 라우팅 테이블 레벨에서 관리할 수 있게 하는 게 Public/Private Subnet 입니다.

Public Subnet vs Private Subnet - 차이는 라우팅이다

Subnet 자체에는 "public", "private"이라는 토글 스위치나 설정 방법이 없습니다. 서브넷의 라우팅 테이블에 0.0.0.0/0(Internet Gateway 이하 IGW)가 있는지 없는지로 정해지는 논리적인 분류입니다. Subnet 을 설계할 때 아래의 다이어그램을 기억하시면 됩니다.

1┌─ 퍼블릭 서브넷 (10.10.1.0/24) ─────────────────┐
2│  Route Table:                               │
3│    10.10.0.0/16  → local                    │
4│    0.0.0.0/0     → igw-xxxx   ← IGW로 직빵    │
5│                                             │
6│  여기 있는 EC2는 퍼블릭 IP만 붙으면                │
7│  인터넷과 양방향 통신 가능                         │
8└──────────────────────────────────────────────┘
9
10┌─ 프라이빗 서브넷 (10.10.11.0/24) ──────────────┐
11│  Route Table:                              │
12│    10.10.0.0/16  → local                   │
13│    0.0.0.0/0     → nat-xxxx   ← NAT GW 경유 │
14│                                            │
15│  여기 있는 EC2는 인터넷에서 직접 접속 불가능         │
16│  단, NAT를 통해 밖으로 나가는 트래픽은 가능         │
17└────────────────────────────────────────────┘
Copy

표준 서브넷 구성

가장 많이 사용하는 서브넷 구성 패턴입니다(2-AZ 기준) . 아래의 구성을 기준으로 설계하신다면 보다 편하게 설계하실 수 있을겁니다.

라우팅 테이블 - 네트워크 트래픽 표지판

네트워크 라우팅 테이블, OS의 라우팅 테이블, VPC의 라우팅 테이블은 모두 같은 자료구조입니다.
셋의 차이는 단순히 운영 주체가 누구인가? 뿐 입니다. (네트워크 엔지니어->시스템 관리자->AWS API)

OS의 라우팅 테이블을 살펴보겠습니다. Linux 환경에서 route -n 이나 ip route 을 쳐 본 적이 있다면 아래의 출력을 본 적이 있으실 겁니다.

1# 일반 Linux 호스트의 라우팅 테이블
2ip route
3
4# 출력 예시
5[외부망 통신 규칙]
6default via 192.168.1.1 dev eth0
7[내부망 통신 규칙]
8192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42
Copy

출력 예시의 두 줄이 의미하는 바를 풀어보면 단순합니다.
"192.168.1.x 대역 패킷은 같은 LAN에 직접 보내고, 그 외 모든 것(default = 0.0.0.0/0)은 게이트웨이 192.168.1.1로 넘긴다."
VPC의 라우팅 테이블도 위와 동일한 원리로 동작합니다. 단지 소유권이 VPC에 있고 적용 대상이 서브넷 단위라는 점입니다.

라우팅 매칭 규칙: Longest Prefix Match

Longest Prefix Match 방식은 IP 라우팅의 표준 동작 방식입니다.여러 라우트가 동시에 매치될 때는 가장 긴 프리픽스를 따릅니다.

1Destination       Target
210.10.0.0/16   →  local
310.10.5.0/24   →  pcx-xxx (피어링)
40.0.0.0/0      →  igw-xxx
Copy

만약 패킷의 도착지가 10.10.5.42 라면, /16 과 /24 둘 다 매치되지만 /24 가 선택됩니다. 이 규칙을 모르면, "VPC Peering을 걸었는데 왜 트래픽이 IGW로 가버리지? 같은 흔한 디버깅 함정에 빠질 수 있습니다.

local 라우트의 의미

모든 AWS VPC 라우팅 테이블에는 삭제할 수 없는 한 줄이 있습니다.

110.10.0.0/16  →  local
Copy

local 의 의미는 "우리 VPC안에 있는 IP는 어떤 게이트웨이도 거치지 말고, 가상 스위치가 알아서 같은 VPC내 ENI(Elastic Network Interface)로 보내라"는 뜻입니다. 즉, 같은 VPC안의 EC2끼리 또는 EC2 ↔ RDS가 별다른 설정 없이 통신되는 이유가 local 라우트 덕분입니다.

IGW(Internet Gateway)와 NAT - 외부와 연결하는 통로

Internet Gateway: 양방향 출입구

IGW는 단 한 가지만 기억하면 됩니다. "IGW는 퍼블릭 IP를 가진 인스턴스의 트래픽을 양방향으로 통과시키는 논리적 라우터이다"

여기서 "퍼블릭 IP"는 크게 2가지입니다.
- Public IPv4: 인스턴스 시작 시 자동 할당되고 재시작하면 바뀜
- Elastic IP: AWS가 계정에 할당해준 고정 공인IP

NAT Gateway: 단 방향 출입구(내부에서 외부로만 가능)

NAT Gateway는 Private Subnet의 인스턴스가 인터넷으로 '나가기만'하게 해주는 장치입니다.

Private Subnet 요청에 대한 응답 패킷은 NAT가 갖고 있는 conntract table 을 보고 원래 EC2로 되돌려줍니다. 즉, 외부에서 먼저 들어오는 연결 conntract table 에 없기 때문에 차단됩니다.

1[ Private EC2 10.10.11.5 ]
2        │  src=10.10.11.5, dst=1.1.1.1
3        ▼
4[ NAT GW 10.10.1.50 (퍼블릭 서브넷) ]
5        │  src=NAT의 EIP, dst=1.1.1.1   ← 출발지 IP를 자기 걸로 바꿈
6        ▼
7[ IGW ] → [ 인터넷 ]
Copy

VPC는 실제로 어떻게 구현되어 있을까

VPC를 설명하면서 Mapping Service 를 간단하게 언급했습니다. AWS 데이터센터에서 같은 데이터센터 안에 있는 EC2가 서로의 영역을 침범하지 않도록 격리한 방법을 간단하게 살펴보겠습니다.

1[ EC2-A in VPC1 ]                       [ EC2-B in VPC1 ]
2사설 IP 10.10.1.5                         사설 IP 10.10.1.6
3        │                                       │
4        ▼                                       ▲
5┌──────────────────┐                  ┌──────────────────┐
6│ 호스트 하이퍼바이저   │                  │ 호스트 하이퍼바이저   │
7│ (가상 스위치)       │                  │ (가상 스위치)       │
8└────────┬─────────┘                  └────────▲─────────┘
9         │  매핑 서비스에 질의:                        │
10         │  "10.10.1.6은 어느 물리 호스트?"            │
11         │  → 물리 IP 192.0.2.42                    │
12         │                                         │
13         │   원본 패킷에 외부 헤더(VXLAN/GENEVE)        │
14         │   를 씌워서 물리 네트워크로 전송               │
15         │                                         │
16         └────────────[ 물리 네트워크 ]───────────────┘
Copy

AWS는 자체 기술인 Hyperplane + Nitro System 위의 가상 스위치를 통해 사용자들의 VPC를 격리했습니다. 우리가 AWS 콘솔에서 보는 "VPC, Subnet, 라우팅 테이블"은 모두 이 매핑 서비스에 저장되는 정책 데이터입니다. 즉, 라우팅 테이블을 수정하면 Mapping Service 의 라우트 룰이 갱신되고, 새로 들어온 패킷부터 다른 결정이 적용되는 방식입니다.

보안 그룹은 어디서 동작하는거지?

가끔 Secutiry Group 이 EC2 안에 있는 iptables 로 착각하는 경우가 있습니다. 하지만 Security Group 역시 하이퍼바이저 레벨에서 관리됩니다. 즉, EC2 안에서 root 권한을 얻어도 Security Group 규칙은 변경할 수가 없습니다. OS의 iptables를 끄더라도 Security Group 은 동작합니다. 이 점 때문에 사내망의 호스트 방화벽보다 훨씬 강력한 격리 환경을 제공할 수 있습니다.

"하이퍼바이저" 가 무엇인지는 아래의 글에서 자세하게 다뤘으니 참고해주세요.

[Part1. 기본 개념 다지기] 컴퓨터 자원의 추상화

클라우드는 "추상화"에서 시작해서 "추상화"로 끝납니다. 이 글에서는 과거의 물리 서버가 어떻게 VM 이 됐고, VM 이 어떻게 컨테이너가 됐는지 설명합니다.

https://heonlabs.dev/ko/posts/cloud-architecture-virtualization-vm-container

트러블 슈팅

클라우드가 익숙하지 않을 때 자주 접하는 문제상황과 디버깅 방법을 간단하게 정리했습니다. 참고용으로만 봐주세요!

상황 1. "EC2를 켰는데 SSH가 안 붙어요"

증상: 퍼블릭 IP 받은 EC2에 22번 포트가 안 열린다.

가능한 원인 (체크 순서):
1. 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW가 있는가? → 없으면 그건 사실상 프라이빗 서브넷이다.
2. EC2에 퍼블릭 IP가 실제로 붙었는가? → "Auto-assign public IPv4" 옵션이 비활성화된 서브넷에서 만든 인스턴스는 IP가 없다.
3. 보안 그룹 inbound에 22/tcp가 열려 있는가?
3. NACL이 22번 또는 임시 포트(1024-65535)를 막지 않는가?
4. OS 내부 방화벽(iptables/firewalld)이 막고 있지 않은가?

해결책: 위에서 아래 순서로 한 항목씩 확인합니다. 첫 번째에서 막혀 있는 경우가 압도적으로 많습니다.

상황 2. "RDS가 EC2를 못 봐요" (반대 방향도 마찬가지)

증상: 같은 VPC인데 EC2 → RDS 연결 시 timeout.

원인: SG 체이닝이 잘못된 경우가 흔합니다. RDS의 SG inbound에 EC2의 SG ID 를 허용해야 하는데, IP 대역만 적어두는 식.

해결책: 보안 그룹의 source는 IP 대역이 아닌 다른 SG의 ID 도 받습니다. 동적으로 변하는 EC2 IP를 따라잡지 않아도 되니, 사내 통신은 SG → SG 형태로 적는 게 표준 입니다.

상황 3. "프라이빗 서브넷 EC2가 갑자기 외부 통신이 안 돼요"

증상: 어제까지 잘 됐는데 오늘 NAT를 통한 outbound가 죽었다.

원인 후보:
- NAT GW가 떠 있는 AZ에서 장애가 발생.
- NAT GW가 실수로 삭제되거나 EIP가 분리됨.
- 라우팅 테이블이 잘못 수정되어 0.0.0.0/0 → NAT가 사라짐.
- NAT GW의 포트 고갈 (한 NAT GW 당 NAT 포트 수가 유한합니다, 보통 ~55K). 동시 연결 폭주 시 발생.

해결책: CloudWatch에서 ErrorPortAllocation 메트릭을 확인합니다. 0이 아니면 포트 고갈이 의심되며, NAT를 AZ별로 분산하거나 트래픽이 많은 서비스는 VPC Endpoint로 빼야 합니다.

상황 4. "VPC Peering 했는데도 통신이 안 돼요"

증상: Peering Connection은 active인데 ping이 안 간다.

원인: Peering은 연결만 만들어 주고 라우팅은 자동으로 안 깔립니다.

해결책: 양쪽 VPC의 라우팅 테이블에 상대 VPC CIDR → pcx-xxx 를 모두 수동으로 추가해야 합니다. 한쪽만 추가하면 ICMP 요청은 가는데 응답이 못 돌아오는 식의 미스터리한 동작이 나옵니다.