# VPC 연결 전략 — Peering과 Transit Gateway
## 소개글
> [!abstract] Introduction
> 엔터프라이즈 환경은 단일 VPC로 구성되지 않는다. 환경 분리(Production/Staging/Dev), 팀별 격리, 인수합병 등의 이유로 수십에서 수천 개의 VPC가 운영되며, 온프레미스 데이터 센터와의 연결도 필수적이다. 이 포스트에서는 VPC 간, 그리고 VPC와 온프레미스를 연결하는 핵심 옵션인 VPC Peering, Transit Gateway, VPN, Direct Connect의 동작 원리와 선택 기준을 다룬다.
## VPC Peering
### 동작 원리
VPC Peering은 두 VPC 사이에 1:1 직접 연결을 생성한다. 트래픽은 AWS 백본 네트워크를 통해 암호화되어 전송되며, 게이트웨이나 중간 장비를 거치지 않고 직접 라우팅된다. 따라서 지연 시간이 가장 낮고 대역폭 제한이 없다(인스턴스 성능에 종속).
피어링을 설정하려면 양쪽 VPC의 [[VPC 라우팅과 게이트웨이|라우팅 테이블]]에 상대 VPC의 CIDR을 타겟으로 하는 경로를 추가해야 한다.
```
VPC-A 라우팅 테이블:
10.1.0.0/16 → pcx-xxxxxxxx (Peering Connection)
VPC-B 라우팅 테이블:
10.0.0.0/16 → pcx-xxxxxxxx (Peering Connection)
```
VPC Peering은 동일 리전뿐 아니라 다른 리전(Inter-Region Peering)과 다른 AWS 계정의 VPC와도 연결할 수 있다. 전제 조건은 두 VPC의 CIDR 블록이 겹치지 않아야 한다는 것이다. CIDR이 겹치면 라우팅 충돌이 발생하여 피어링 자체가 불가능하다. 이것이 [[VPC와 Subnet|CIDR 설계]]에서 IP 중복 방지를 강조하는 이유다.
### 비전이성의 한계
VPC Peering의 핵심 제약은 비전이성(*non-transitivity*)이다. VPC-A가 VPC-B와 피어링되고, VPC-B가 VPC-C와 피어링되어 있더라도, VPC-A와 VPC-C는 VPC-B를 경유하여 통신할 수 없다. A와 C가 통신하려면 별도의 피어링 연결이 필요하다.
```mermaid
flowchart LR
A["VPC-A"] <-->|"피어링"| B["VPC-B"]
B <-->|"피어링"| C["VPC-C"]
A -.->|"❌ 불가능<br/>(비전이성)"| C
```
이 특성 때문에 VPC 수가 늘어나면 필요한 피어링 연결 수가 기하급수적으로 증가한다.
$
\text{필요 연결 수} = \frac{N(N-1)}{2}
$
VPC가 5개이면 10개, 10개이면 45개, 50개이면 1,225개의 피어링이 필요하다. 이는 관리가 불가능한 수준이며, 이 문제를 해결하기 위해 Transit Gateway가 등장했다.
### Peering의 적합한 사용 사례
비전이성에도 불구하고, VPC Peering은 다음 상황에서 여전히 최선의 선택이다.
첫째, VPC 수가 적고(2~5개), 앞으로도 크게 늘어나지 않는 환경. 둘째, 두 VPC 간 대량의 트래픽을 최저 지연으로 전송해야 하는 경우. Transit Gateway는 트래픽이 중간 허브를 거치면서 미세한 지연이 추가되지만, Peering은 직접 연결이므로 지연이 없다. 셋째, Transit Gateway의 데이터 처리 비용을 회피하고 싶은 경우. Peering 자체에는 처리 비용이 없고, 일반적인 데이터 전송 비용만 부과된다.
## Transit Gateway (TGW)
### 허브 앤 스포크 모델
Transit Gateway는 대규모 네트워크의 복잡성을 해결하기 위한 중앙 집중형 허브다. 하나의 TGW에 수천 개의 VPC, VPN 연결, Direct Connect를 연결하여 허브 앤 스포크(*hub-and-spoke*) 토폴로지를 구성한다.
```mermaid
flowchart TB
TGW["Transit Gateway<br/>(중앙 허브)"]
VPC1["VPC-A"] <--> TGW
VPC2["VPC-B"] <--> TGW
VPC3["VPC-C"] <--> TGW
VPC4["VPC-D"] <--> TGW
VPN["VPN<br/>온프레미스"] <--> TGW
DX["Direct Connect"] <--> TGW
```
### 전이적 라우팅
Peering과 달리 TGW는 전이적 라우팅(*transitive routing*)을 지원한다. VPC-A와 VPC-C가 모두 TGW에 연결되어 있으면, A ↔ TGW ↔ C 경로로 통신이 가능하다. 새로운 VPC를 추가할 때도 TGW에 연결하기만 하면 기존의 모든 VPC와 자동으로 통신할 수 있다.
### 라우팅 도메인 분리
TGW의 강력한 기능 중 하나는 라우팅 테이블을 분리하여 트래픽 격리(*segmentation*)를 구현할 수 있다는 점이다.
```mermaid
flowchart LR
subgraph PROD["Production 라우팅 도메인"]
VP1["VPC-Prod-1"]
VP2["VPC-Prod-2"]
end
subgraph DEV["Development 라우팅 도메인"]
VD1["VPC-Dev-1"]
VD2["VPC-Dev-2"]
end
subgraph SHARED["Shared Services"]
VS["VPC-Shared<br/>(DNS, 모니터링)"]
end
TGW["Transit Gateway"]
VP1 <--> TGW
VP2 <--> TGW
VD1 <--> TGW
VD2 <--> TGW
VS <--> TGW
```
이 구성에서 Production VPC들은 서로 통신할 수 있지만 Development VPC와는 격리된다. Shared Services VPC는 양쪽 모두와 통신할 수 있다. 이를 통해 환경 간 격리를 유지하면서도 공통 서비스는 공유하는 아키텍처가 가능해진다.
### TGW 비용 구조
| 항목 | 비용 (us-east-1 기준) |
| :--- | :--- |
| VPC 연결(Attachment) | $0.05/시간 (≈ $36/월) |
| 데이터 처리 | $0.02/GB |
10개의 VPC를 연결하고 월 1TB의 트래픽이 TGW를 통과하면, 월 비용은 약 $380($360 연결 + $20 처리)이다. Peering은 연결 비용이 없으므로, 트래픽이 많은 소수의 VPC 쌍에는 Peering이 비용 면에서 유리하고, 다수의 VPC를 효율적으로 관리해야 하는 경우에는 TGW가 적합하다.
## Peering vs Transit Gateway 선택 기준
| 기준 | VPC Peering | Transit Gateway |
| :--- | :--- | :--- |
| VPC 수 | 소규모 (2~5개) | 대규모 (10개 이상) |
| 토폴로지 | 1:1 직접 연결 | 허브 앤 스포크 |
| 전이적 라우팅 | ❌ 불가 | ✅ 지원 |
| 지연 시간 | 최저 (직접 연결) | 미세하게 추가 (허브 경유) |
| 데이터 처리 비용 | 없음 | $0.02/GB |
| 관리 복잡성 | VPC 수 증가 시 기하급수적 | 선형적 |
| 온프레미스 연결 | 불가 | VPN/DX 통합 가능 |
| 라우팅 도메인 분리 | 불가 | 지원 |
실무에서는 두 서비스를 혼합하여 사용하는 패턴이 일반적이다. 대량의 데이터를 교환하는 두 VPC 사이에는 Peering을, 나머지 VPC들은 TGW로 연결하여 비용과 관리 효율의 균형을 맞춘다.
## 하이브리드 연결
### Site-to-Site VPN
AWS Site-to-Site VPN은 인터넷을 통해 IPSec[^ipsec-definition] 암호화 터널을 연결한다. 구축이 빠르고(수 분 내) 비용이 저렴하지만, 인터넷 품질에 따라 성능 변동성이 있다.
[^ipsec-definition]: IPSec(Internet Protocol Security) — IP 패킷을 암호화하고 인증하는 프로토콜 모음이다. 터널 모드에서는 원본 IP 패킷 전체를 암호화하여 새로운 IP 헤더로 감싸므로, VPN 통신의 기밀성과 무결성을 보장한다.
VPN의 대역폭은 터널당 최대 1.25Gbps이며, 두 개의 터널이 활성-대기(*active-standby*) 또는 활성-활성(*active-active*) 구성으로 고가용성을 제공한다. Accelerated VPN 기능을 사용하면 AWS Global Accelerator 네트워크를 이용하여 인터넷 구간의 지연과 지터를 줄일 수 있다.
| 항목 | 비용 |
| :--- | :--- |
| VPN 연결 | $0.05/시간 (≈ $36/월) |
| 데이터 전송 (아웃바운드) | $0.09/GB (리전에 따라 상이) |
### Direct Connect (DX)
Direct Connect는 전용 물리 회선을 통해 AWS와 직접 연결하는 서비스다. 인터넷을 거치지 않으므로 일관된 성능과 낮은 지연 시간을 보장하며, 대용량 데이터 전송 시 비용 절감 효과가 크다.
| 항목 | VPN | Direct Connect |
| :--- | :--- | :--- |
| 연결 매체 | 인터넷(IPSec 암호화) | 전용 물리 회선 |
| 구축 시간 | 수 분 | 수 주 ~ 수 개월 |
| 대역폭 | 최대 1.25Gbps/터널 | 1Gbps, 10Gbps, 100Gbps |
| 지연 시간 | 변동적 (인터넷 의존) | 일관적 (전용 회선) |
| 암호화 | 기본 제공 (IPSec) | MACsec[^macsec-definition] 또는 VPN over DX |
| 비용 | 저렴 | 포트 시간 요금 + 데이터 전송 |
| 고가용성 | 이중 터널 | 이중 연결 필요 (별도 비용) |
[^macsec-definition]: MACsec(Media Access Control Security) — 이더넷 프레임 수준에서 암호화를 제공하는 IEEE 802.1AE 표준이다. Direct Connect의 물리적 연결 구간을 암호화하여, 전용 회선이더라도 데이터가 도청될 수 없도록 보장한다.
일반적인 권장 패턴은 Direct Connect를 주 연결로 사용하고, Site-to-Site VPN을 백업으로 구성하는 것이다. DX 회선에 장애가 발생하면 VPN으로 자동 전환(*failover*)되어 연결 가용성을 확보할 수 있다.
### VPN과 DX의 TGW 통합
Transit Gateway는 VPN과 Direct Connect를 모두 수용할 수 있다. 온프레미스에서 TGW로 연결하면, TGW에 연결된 모든 VPC에 자동으로 도달할 수 있다. 이는 VPC마다 별도의 VPN을 설정하던 과거 방식과 비교해 관리 복잡성을 획기적으로 줄여준다.
```mermaid
flowchart TB
ON["온프레미스<br/>데이터 센터"] <-->|"DX / VPN"| TGW["Transit Gateway"]
TGW <--> V1["VPC-A"]
TGW <--> V2["VPC-B"]
TGW <--> V3["VPC-C"]
```
## Cloud WAN
최근 도입된 AWS Cloud WAN은 여러 리전의 Transit Gateway와 온프레미스 연결을 글로벌 네트워크라는 단일 정책으로 통합 관리하는 서비스다. 기존에는 리전별로 TGW를 생성하고, 이들을 다시 피어링하며, 라우팅을 수동으로 관리해야 했다.
Cloud WAN은 세그먼트(*segment*)라는 논리적 그룹을 정의하고 정책을 적용하면, 전 세계 리전에 자동으로 설정이 전파된다. 글로벌 규모에서 수십 개의 리전과 수천 개의 VPC를 운영하는 대규모 엔터프라이즈에 적합하며, TGW의 상위 추상화 계층이라 할 수 있다.
## 정리
VPC 연결 전략은 규모와 요구사항에 따라 달라진다. 소규모 환경에서는 Peering의 단순성과 저비용이 적합하고, 대규모 환경에서는 Transit Gateway의 중앙 집중식 관리가 필수적이다. 하이브리드 연결에서는 Direct Connect로 안정적인 성능을, VPN으로 빠른 구축과 백업을 확보한다.
이 포스트를 마지막으로 [[AWS VPC|VPC의 핵심 구성요소]]를 모두 다루었다. 허브 페이지로 돌아가 전체 학습 경로를 확인하고, 각 구성요소 간의 관계를 복습하는 것을 권장한다.
---
## 출처
- Amazon Web Services (2026) *VPC peering.* Available at: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
- Amazon Web Services (2026) *Transit gateways.* Available at: https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
- Amazon Web Services (2026) *AWS Site-to-Site VPN.* Available at: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
- Amazon Web Services (2026) *AWS Direct Connect.* Available at: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
- Amazon Web Services (2026) *What is AWS Cloud WAN?* Available at: https://docs.aws.amazon.com/network-manager/latest/cloudwan/what-is-cloudwan.html
- Patel, A. (2024) *AWS — Difference between VPC Peering and Transit Gateway.* Medium. Available at: https://medium.com/awesome-cloud/aws-difference-between-vpc-peering-and-transit-gateway-3640a464be2d