AWS - Routing Table & Router

클라우드 네트워크 설계에서 라우터(Router) 와 라우팅 테이블(Routing Table) 은 트래픽 흐름을 제어하는 핵심 구성 요소입니다. 라우터는 네트워크 패킷이 어느 방향으로 흘러가야 하는지를 결정하는 관문이며, 라우팅 테이블은 그 결정을 위한 경로 정보의 집합입니다. 쉽게 말해, 라우터가 운전사라면 라우팅 테이블은 도로 지도가 됩니다. AWS VPC 환경에서는 라우터가 VPC 내에 논리적으로 기본 제공되며, 사용자는 이를 직접 제어할 수는 없고 라우팅 테이블(Route Table) 을 통해 동작 방식을 정의합니다.

1. Router와 Routing Table의 개념

네트워크 요청이 발생하면 데이터는 우선 라우터로 전달됩니다. 이 라우터는 패킷의 목적지 IP 주소를 확인한 뒤, 연결된 라우팅 테이블을 조회하여 패킷을 어디로 전송할지를 결정합니다. 라우팅 테이블은 여러 개의 경로(Route) 규칙을 가지고 있으며, 각 규칙은 다음과 같은 요소로 구성됩니다.

Destination (CIDR 범위): 어떤 네트워크 대역을 대상으로 하는지 (172.31.0.0/16, 0.0.0.0/0 등)
Target: 해당 요청을 어디로 보낼지 (local, NAT Gateway, Internet Gateway, Transit Gateway 등)

예를 들어, 서브넷 A의 라우팅 테이블에 172.31.0.0/16 → local 이 정의되어 있다면, VPC 내부 통신은 로컬에서 처리됩니다. VPC를 생성할 때 172.31.0.0/16 을 VPC CIDR로 잡았다면, 그 내부에 있는 모든 서브넷과 인스턴스 IP가 이 범위 안에 들어가게 됩니다. local 은 AWS에서 예약된 특별한 키워드로, 트래픽은 VPC 내부에서 라우팅된다는 의미입니다. 목적지가 같은 VPC의 IP 대역이면 외부 게이트웨이나 장치를 거칠 필요 없이 자동으로 라우터가 내부에서 직접 전달합니다.

예시로, VPC CIDR이 172.31.0.0/16 이라면 기본 라우팅 테이블에는 다음과 같은 규칙이 자동으로 추가됩니다.

Destination: 172.31.0.0/16
Target: local

이는 VPC 내부 인스턴스 간의 통신은 로컬 네트워크 안에서 직접 처리됨을 의미합니다. 즉, 같은 VPC에 속한 두 인스턴스는 라우터를 거치지만 외부 게이트웨이로 나가지 않고 바로 통신할 수 있습니다. 조금 더 확인해 봅시다.

VPC CIDR: 172.31.0.0/16
Subnet A: 172.31.1.0/24
Subnet B: 172.31.2.0/24
인스턴스 A IP: 172.31.1.10
인스턴스 B IP: 172.31.2.20

인스턴스 A가 인스턴스 B로 패킷을 보낼 때, 이 트래픽의 목적지는 172.31.2.20이고 172.31.0.0/16 범위 안 입니다. 따라서 위의 Destination( 172.31.0.0/16 )과 Target( local )을 라우터 테이브에서 확인합니다. 따라서 같은 VPC 내부 통신으로 판단하고 트래픽은 외부로 나가지 않고 VPC 내부 라우터를 통해 직접 Subnet B로 전달됩니다.

2. 인터넷 게이트웨이와 외부 통신

VPC 생성 시 기본으로 제공되는 라우팅 테이블은 오직 VPC 내부 통신(local) 만 허용합니다. 같은 VPC 내의 인스턴스들은 Destination: <VPC CIDR> → Target: local 규칙에 따라 서로 자유롭게 통신할 수 있지만, 그 외의 트래픽(예: 인터넷, 다른 VPC, 온프레미스 네트워크)은 전달할 수 없습니다. 따라서 외부와 연결하기 위해서는 반드시 추가 경로(Route) 가 필요합니다.

2-1. 퍼블릭 인터넷과의 연결

퍼블릭 인터넷과 연결하려면 인터넷 게이트웨이(IGW) 를 VPC에 연결하고, 라우팅 테이블에 다음 규칙을 추가해야 합니다.

Destination: 0.0.0.0/0
Target: igw-xxxxxxxx

0.0.0.0/0 : 모든 IPv4 주소를 의미하는 기본 경로(Default Route)로 VPC 내부(local) CIDR 범위 외의 모든 요청을 대상으로 합니다.
igw-xxxxxxxx : 해당 VPC에 연결된 인터넷 게이트웨이로 트래픽의 출구를 인터넷 게이트웨이(IGW) 로 지정한 것입니다.

이 경로가 있어야 VPC 내부 인스턴스에서 인터넷으로 나가는 아웃바운드 트래픽이 정상적으로 전달됩니다. 따라서 이 경로가 없으면 VPC 내부 인스턴스에서 인터넷으로 아웃바운드 요청을 보내더라도 IGW로 전달되지 못하고 드롭됩니다.

위 규칙만 있으면 아웃바운드 트래픽(VPC → 인터넷)은 가능해집니다. 그러나 인스턴스가 인터넷으로부터 인바운드 요청(예: 외부에서 SSH, HTTP 접속)을 받으려면 아래의 조건이 더 필요합니다.

인스턴스가 퍼블릭 IP 또는 Elastic IP 를 가지고 있어야 합니다.
서브넷이 IGW가 연결된 라우팅 테이블에 속해야 합니다.
보안 그룹(Security Group) 과 네트워크 ACL 에서 외부 트래픽을 허용해야 합니다.

라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있고 그 라우팅 테이블과 해당 서브넷이 연결되어 있으며 인스턴스가 퍼블릭 IP를 할당받은 경우에 우리는 AWS의 퍼블릭 서브넷이라고 부릅니다.

2-2. 외부 사설망과의 연결

기업 환경에서는 온프레미스 데이터센터와 클라우드를 연결하는 경우가 많습니다. 이때는 VPN Gateway(VGW) 또는 AWS Direct Connect(DX) 가 사용됩니다.

VPN Gateway (VGW) : VPC 측에 설치되는 가상 게이트웨이로, 온프레미스 장비(Customer Gateway)와 암호화된 VPN 터널을 형성해 안전하게 통신합니다.
Direct Connect (DX) : 고객 데이터센터와 AWS를 전용선으로 연결하여 안정적이고 지연 시간이 낮은 네트워크 환경을 제공합니다. DX는 Virtual Interface(VIF)를 통해 VGW 또는 Transit Gateway와 연결되어 라우팅 테이블에 반영됩니다.

라우팅 테이블에는 외부 사설망의 CIDR(예: 10.0.0.0/8) 을 Destination 으로 하고, Target 을 VPN Gateway(VGW) 또는 Transit Gateway(TGW)를 통해 Direct Connect로 연결되도록 지정합니다.

2-3. VPC 간 연결

여러 VPC 간 트래픽을 허용하려면 VPC 피어링(Peering) 또는 Transit Gateway(TGW) 를 사용합니다.

VPC 피어링 : 두 VPC를 직접 연결하는 방식입니다. 일대일(1:1) 관계로만 구성되며, 양쪽 라우팅 테이블에 상대 VPC의 CIDR을 경로로 추가해야 통신이 가능합니다.
Transit Gateway (TGW) : 허브-스포크 구조의 중앙 라우터 역할을 하는 서비스입니다. 다수의 VPC와 온프레미스 네트워크를 한 번에 연결할 수 있어 확장성이 높습니다.

정리하면, 각 VPC의 라우팅 테이블에 상대 CIDR(또는 TGW 경로)을 명시하지 않으면 트래픽은 전달되지 않습니다.

정리

라우터는 네트워크 요청이 어디로 가야 하는지 판단하는 관문이며, 라우팅 테이블은 그 판단을 위한 경로 정보를 담고 있는 지도와 같습니다. AWS VPC에서는 기본적으로 VPC 내부 통신을 위해 Destination: <VPC CIDR> → Target: local 규칙이 자동으로 포함되어, 같은 VPC 내 인스턴스 간 통신이 가능해집니다.

하지만 외부와 통신하려면 반드시 인터넷 게이트웨이(IGW) 가 필요합니다. 라우팅 테이블에 0.0.0.0/0 → IGW 규칙을 추가해야 인터넷으로 나가는 경로가 열리며, 이 규칙이 포함된 라우팅 테이블과 서브넷이 연결되어야 해당 서브넷은 퍼블릭 서브넷이 됩니다. 즉, VPC 내부 통신은 기본(local) 규칙으로 처리되지만, 인터넷 등 외부와의 통신은 IGW를 통한 명시적 경로 설정이 반드시 요구됩니다.