Transit Gateway로 복잡한 네트워크 중앙 집중화 완벽 가이드

AWS Transit Gateway를 활용하여 복잡한 VPC 네트워크를 중앙에서 효율적으로 관리하는 방법을 알아봅니다. Hub-and-Spoke 아키텍처부터 라우팅 테이블 구성까지 실무에 필요한 모든 것을 다룹니다.

1. Transit Gateway의 필요성

김개발 씨는 스타트업에서 클라우드 인프라를 담당하는 주니어 엔지니어입니다. 처음에는 VPC 하나로 시작했던 서비스가 어느새 10개가 넘는 VPC로 늘어났습니다.

각 VPC를 서로 연결하기 위해 VPC 피어링을 설정하다 보니, 연결 개수가 기하급수적으로 늘어나 관리가 불가능한 지경에 이르렀습니다.

Transit Gateway는 한마디로 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브에서 연결하고 관리하는 서비스입니다. 마치 공항의 허브 터미널처럼, 모든 네트워크 트래픽이 한 곳을 거쳐 목적지로 향하게 됩니다.

이를 통해 네트워크 구성이 단순해지고 관리 부담이 크게 줄어듭니다.

다음 코드를 살펴봅시다.

// AWS CDK로 Transit Gateway 필요성을 보여주는 예제
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 문제 상황: 5개 VPC를 피어링으로 연결하면?
// 필요한 피어링 수 = n(n-1)/2 = 5*4/2 = 10개의 연결 필요!

// VPC 피어링 방식 (복잡함)
const vpcA = new ec2.Vpc(this, 'VpcA', { maxAzs: 2 });
const vpcB = new ec2.Vpc(this, 'VpcB', { maxAzs: 2 });
// A-B, A-C, A-D, A-E, B-C, B-D, B-E, C-D, C-E, D-E... 관리 불가!

// Transit Gateway 방식 (단순함)
// 각 VPC는 Transit Gateway에 한 번만 연결하면 됨
// 5개 VPC = 5개 연결만 필요

김개발 씨가 입사했을 때, 회사의 AWS 인프라는 단순했습니다. 프로덕션 VPC 하나, 개발 VPC 하나.

이 둘을 연결하기 위해 VPC 피어링을 설정했고, 모든 것이 깔끔하게 돌아갔습니다. 그런데 서비스가 성장하면서 상황이 복잡해지기 시작했습니다.

스테이징 환경이 추가되고, 데이터 분석팀을 위한 VPC가 생겼습니다. 보안팀에서는 별도의 보안 모니터링 VPC를 요청했고, 파트너사와의 연동을 위한 DMZ VPC도 필요해졌습니다.

VPC 피어링의 특성상, N개의 VPC를 모두 연결하려면 N(N-1)/2개의 피어링이 필요합니다. 5개 VPC만 해도 10개의 피어링 연결이 필요하고, 10개 VPC라면 무려 45개의 연결을 관리해야 합니다.

이것을 풀 메시(Full Mesh) 토폴로지라고 부릅니다. 김개발 씨는 매일 아침 출근하면 피어링 연결 상태를 확인하는 것부터 시작했습니다.

새로운 VPC가 추가될 때마다 기존 모든 VPC에 피어링을 설정하고, 각 VPC의 라우팅 테이블에 경로를 일일이 추가해야 했습니다. 실수라도 하면 서비스 장애로 이어졌습니다.

선배 엔지니어 박시니어 씨가 이 상황을 보고 조언했습니다. "우리 회사 규모가 커졌으니, 이제 Transit Gateway를 도입할 때가 됐어요." Transit Gateway는 마치 공항의 허브 터미널과 같습니다.

인천공항이 아시아의 허브 공항인 것처럼, 여러 도시를 직항으로 연결하는 대신 허브를 거쳐 가면 항공사는 노선 수를 크게 줄일 수 있습니다. 네트워크도 마찬가지입니다.

Transit Gateway를 도입하면, 각 VPC는 오직 Transit Gateway에만 연결하면 됩니다. 10개 VPC가 있어도 연결은 10개면 충분합니다.

새 VPC가 추가되어도 Transit Gateway에 한 번만 연결하면 기존 모든 VPC와 통신이 가능해집니다. 더 좋은 점은 중앙 집중식 관리입니다.

모든 라우팅 정책을 Transit Gateway에서 한 번에 설정할 수 있습니다. 특정 VPC 간 통신을 차단하거나, 트래픽을 검사용 VPC로 우회시키는 것도 손쉽게 가능합니다.

김개발 씨는 Transit Gateway 도입 후, 네트워크 관리에 들이는 시간이 절반 이하로 줄었다고 합니다. 무엇보다 새 VPC를 추가할 때의 스트레스가 사라졌습니다.

이제는 체계적인 네트워크 구성도를 그릴 수 있게 되었습니다.

실전 팁

💡 - VPC가 3개 이상이고 서로 통신이 필요하다면 Transit Gateway 도입을 검토하세요

Transit Gateway는 리전 단위 서비스이므로, 멀티 리전 환경에서는 각 리전에 별도로 생성해야 합니다

2. Hub and Spoke 아키텍처 이해

박시니어 씨가 화이트보드 앞에 섰습니다. "Transit Gateway를 제대로 이해하려면 먼저 Hub-and-Spoke 아키텍처를 알아야 해요." 김개발 씨는 노트를 꺼내 들었습니다.

네트워크 아키텍처의 기본 중의 기본, 하지만 제대로 이해하고 있는 사람은 의외로 많지 않습니다.

Hub-and-Spoke 아키텍처는 중앙의 허브를 중심으로 여러 스포크가 방사형으로 연결되는 네트워크 구조입니다. 마치 자전거 바퀴살이 중앙 축에서 바깥쪽 테두리로 뻗어나가는 모양과 같습니다.

Transit Gateway가 허브 역할을 하고, 각 VPC가 스포크가 됩니다.

다음 코드를 살펴봅시다.

// Hub-and-Spoke 아키텍처 구성 예제 (AWS CDK)
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Hub: Transit Gateway 생성
const transitGateway = new ec2.CfnTransitGateway(this, 'TGW', {
  description: 'Central Hub for all VPCs',
  defaultRouteTableAssociation: 'enable',
  defaultRouteTablePropagation: 'enable',
  tags: [{ key: 'Name', value: 'MainHub-TGW' }]
});

// Spoke 1: Production VPC
const prodVpc = new ec2.Vpc(this, 'ProdVpc', {
  ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'),
  maxAzs: 2
});

// Spoke 2: Development VPC
const devVpc = new ec2.Vpc(this, 'DevVpc', {
  ipAddresses: ec2.IpAddresses.cidr('10.2.0.0/16'),
  maxAzs: 2
});

// 각 Spoke를 Hub에 연결 (Attachment)

박시니어 씨가 화이트보드에 동그라미 하나를 그렸습니다. "이게 허브예요." 그리고 그 주변에 여러 개의 작은 동그라미를 그린 뒤, 선으로 중앙과 연결했습니다.

"이게 스포크고요." 김개발 씨가 고개를 갸웃거렸습니다. "자전거 바퀴 같네요?" 박시니어 씨가 웃으며 답했습니다.

"정확해요! 실제로 자전거 바퀴에서 이름을 따온 거예요." Hub-and-Spoke 아키텍처는 네트워크 설계의 고전적인 패턴입니다.

중앙의 허브가 모든 통신의 교차점이 되고, 각 스포크는 허브를 통해서만 다른 스포크와 통신합니다. 직접 연결은 존재하지 않습니다.

이 구조의 가장 큰 장점은 단순함입니다. 새로운 스포크(VPC)를 추가할 때, 오직 허브와의 연결만 설정하면 됩니다.

기존 스포크들의 설정을 건드릴 필요가 전혀 없습니다. 풀 메시 구조에서 겪었던 복잡성이 완전히 사라집니다.

또 다른 장점은 중앙 집중식 제어입니다. 모든 트래픽이 허브를 거치기 때문에, 허브에서 보안 정책을 적용하거나 트래픽을 모니터링하기가 매우 용이합니다.

방화벽, 침입 탐지 시스템 등을 허브에 배치하면 모든 통신을 검사할 수 있습니다. 박시니어 씨가 실제 사례를 들어 설명했습니다.

"우리 회사로 치면, Transit Gateway가 허브고 프로덕션 VPC, 개발 VPC, 스테이징 VPC가 각각 스포크인 거예요. 개발팀에서 프로덕션 데이터베이스에 접근해야 할 때, 트래픽은 개발 VPC에서 Transit Gateway를 거쳐 프로덕션 VPC로 갑니다." 김개발 씨가 질문했습니다.

"그러면 허브에 문제가 생기면 전체 네트워크가 마비되는 거 아닌가요?" 좋은 질문입니다. 이것을 단일 장애점(Single Point of Failure) 문제라고 합니다.

다행히 AWS Transit Gateway는 이 문제를 해결하기 위해 설계되었습니다. Transit Gateway는 기본적으로 고가용성을 제공합니다.

여러 가용 영역에 걸쳐 자동으로 확장되며, AWS가 내부적으로 이중화를 관리합니다. 사용자가 별도로 이중화를 구성할 필요가 없습니다.

Hub-and-Spoke의 변형으로 Shared Services 모델도 있습니다. 허브 VPC에 공통으로 사용하는 서비스들(Active Directory, DNS, 모니터링 도구 등)을 배치하고, 모든 스포크 VPC에서 이를 공유하는 방식입니다.

김개발 씨는 화이트보드의 그림을 사진으로 찍었습니다. "이제 왜 Transit Gateway가 필요한지 확실히 알겠어요.

복잡한 풀 메시 대신 깔끔한 허브 구조로 가는 거군요."

실전 팁

💡 - Hub-and-Spoke 구조에서 허브는 반드시 고가용성을 갖춰야 합니다. Transit Gateway는 이를 기본 제공합니다

공유 서비스(DNS, AD 등)는 별도의 Shared Services VPC에 두고 Hub를 통해 접근하게 설계하세요

3. Transit Gateway 생성 및 VPC 연결

이론 공부는 충분히 했습니다. 이제 김개발 씨는 실제로 Transit Gateway를 생성하고 VPC를 연결해볼 차례입니다.

AWS 콘솔을 열고 손에 땀을 쥐며 첫 번째 Transit Gateway를 만들어봅니다. 생각보다 간단하지만, 몇 가지 중요한 설정을 놓치면 나중에 큰 문제가 될 수 있습니다.

Transit Gateway를 생성하고 VPC를 연결하는 과정은 크게 두 단계로 나뉩니다. 먼저 Transit Gateway를 생성하고, 그 다음 각 VPC에 대해 Transit Gateway Attachment를 만들어 연결합니다.

Attachment는 VPC의 특정 서브넷을 Transit Gateway에 연결하는 역할을 합니다.

다음 코드를 살펴봅시다.

// AWS CDK로 Transit Gateway 생성 및 VPC 연결
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as cdk from 'aws-cdk-lib';

// 1. Transit Gateway 생성
const tgw = new ec2.CfnTransitGateway(this, 'MainTGW', {
  amazonSideAsn: 64512,  // BGP ASN 번호
  autoAcceptSharedAttachments: 'enable',
  defaultRouteTableAssociation: 'enable',
  defaultRouteTablePropagation: 'enable',
  dnsSupport: 'enable',
  vpnEcmpSupport: 'enable',
  tags: [{ key: 'Name', value: 'Production-TGW' }]
});

// 2. VPC 생성 (프로덕션용)
const prodVpc = new ec2.Vpc(this, 'ProdVpc', {
  ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'),
  maxAzs: 2,
  subnetConfiguration: [
    { name: 'Public', subnetType: ec2.SubnetType.PUBLIC },
    { name: 'Private', subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
    { name: 'TGW', subnetType: ec2.SubnetType.PRIVATE_ISOLATED }
  ]
});

// 3. Transit Gateway Attachment 생성
const tgwAttachment = new ec2.CfnTransitGatewayAttachment(this, 'ProdAttachment', {
  transitGatewayId: tgw.ref,
  vpcId: prodVpc.vpcId,
  subnetIds: prodVpc.selectSubnets({ subnetGroupName: 'TGW' }).subnetIds
});

김개발 씨가 AWS 콘솔에서 VPC 서비스로 이동했습니다. 왼쪽 메뉴에서 Transit Gateway를 클릭하고 "Transit Gateway 생성" 버튼을 누릅니다.

첫 번째로 마주하는 설정은 **ASN(Autonomous System Number)**입니다. 박시니어 씨가 설명합니다.

"BGP 라우팅에 사용되는 번호예요. AWS 기본값인 64512를 사용해도 되고, 온프레미스 네트워크와 연결할 예정이라면 충돌하지 않는 번호를 선택해야 해요." 다음은 몇 가지 중요한 옵션들입니다.

DNS 지원을 활성화하면 Transit Gateway를 통해 연결된 VPC 간에 프라이빗 DNS 호스트 이름이 해석됩니다. 대부분의 경우 활성화하는 것이 좋습니다.

기본 라우팅 테이블 연결 옵션도 있습니다. 이를 활성화하면 새로운 Attachment가 자동으로 기본 라우팅 테이블에 연결됩니다.

처음에는 편리하지만, 복잡한 환경에서는 비활성화하고 수동으로 관리하는 것이 더 안전합니다. Transit Gateway가 생성되었습니다.

상태가 "available"로 바뀌면 VPC를 연결할 수 있습니다. 이제 Transit Gateway Attachment를 생성할 차례입니다.

여기서 중요한 결정을 해야 합니다. 어떤 서브넷을 Transit Gateway에 연결할 것인가?

박시니어 씨가 조언합니다. "Transit Gateway 전용 서브넷을 만드는 것을 추천해요.

가용 영역당 하나씩, /28 정도의 작은 서브넷이면 충분해요." 이렇게 하면 Transit Gateway 트래픽이 애플리케이션 서브넷과 분리되어 관리하기 쉽습니다. 김개발 씨가 프로덕션 VPC에 TGW 서브넷을 추가했습니다.

ap-northeast-2a에 10.1.240.0/28, ap-northeast-2c에 10.1.241.0/28. 작지만 Transit Gateway ENI(Elastic Network Interface)를 배치하기에 충분합니다.

Attachment를 생성하면 AWS가 지정한 서브넷에 ENI를 자동으로 생성합니다. 이 ENI를 통해 VPC의 트래픽이 Transit Gateway로 흘러갑니다.

주의할 점은, 이 ENI가 생성된 서브넷의 라우팅 테이블에서 Transit Gateway로 가는 경로가 설정되어야 한다는 것입니다. 김개발 씨가 개발 VPC, 스테이징 VPC에도 같은 과정을 반복했습니다.

각 VPC에 TGW 서브넷을 만들고, Attachment를 생성합니다. 콘솔에서 Transit Gateway Attachments 목록을 보니 세 개의 VPC가 모두 연결된 것이 보입니다.

하지만 아직 끝이 아닙니다. Attachment만 만들었다고 트래픽이 바로 흐르지는 않습니다.

각 VPC의 라우팅 테이블에 Transit Gateway로 가는 경로를 추가해야 합니다. 이 부분은 다음 섹션에서 자세히 다루겠습니다.

실전 팁

💡 - Transit Gateway 전용 서브넷을 별도로 만들어 관리하면 네트워크 구성이 깔끔해집니다

각 가용 영역에 Attachment 서브넷을 배치해야 고가용성이 보장됩니다

4. 라우팅 테이블 및 Association

Transit Gateway와 VPC Attachment를 생성했지만, 아직 VPC 간 통신이 되지 않습니다. 김개발 씨가 개발 VPC의 EC2에서 프로덕션 VPC의 데이터베이스로 ping을 보내봤지만 응답이 없습니다.

무엇이 빠진 걸까요? 바로 라우팅 테이블 설정입니다.

네트워크에서 길을 알려주는 이정표가 없으면 패킷은 목적지를 찾지 못합니다.

Transit Gateway 환경에서 라우팅은 두 곳에서 설정해야 합니다. 첫째, 각 VPC의 라우팅 테이블에 다른 VPC CIDR로 가는 트래픽을 Transit Gateway로 보내는 경로를 추가합니다.

둘째, Transit Gateway 라우팅 테이블에서 어떤 Attachment로 트래픽을 전달할지 결정합니다. Association은 Attachment와 라우팅 테이블을 연결하는 작업입니다.

다음 코드를 살펴봅시다.

// VPC 라우팅 테이블 및 Transit Gateway 라우팅 설정
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 1. VPC 라우팅 테이블에 Transit Gateway 경로 추가
// 프로덕션 VPC의 Private 서브넷 라우팅 테이블
const prodRouteTable = new ec2.CfnRoute(this, 'ProdToDevRoute', {
  routeTableId: prodPrivateSubnet.routeTable.routeTableId,
  destinationCidrBlock: '10.2.0.0/16',  // 개발 VPC CIDR
  transitGatewayId: tgw.ref
});

// 2. Transit Gateway 라우팅 테이블 생성
const tgwRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'TGWRouteTable', {
  transitGatewayId: tgw.ref,
  tags: [{ key: 'Name', value: 'Main-TGW-RT' }]
});

// 3. Association: Attachment를 라우팅 테이블에 연결
const association = new ec2.CfnTransitGatewayRouteTableAssociation(this, 'ProdAssoc', {
  transitGatewayAttachmentId: prodAttachment.ref,
  transitGatewayRouteTableId: tgwRouteTable.ref
});

// 4. Propagation: 경로 자동 전파 설정
const propagation = new ec2.CfnTransitGatewayRouteTablePropagation(this, 'ProdProp', {
  transitGatewayAttachmentId: prodAttachment.ref,
  transitGatewayRouteTableId: tgwRouteTable.ref
});

김개발 씨가 곤란한 표정으로 박시니어 씨를 찾아왔습니다. "Transit Gateway도 만들고 Attachment도 연결했는데, 왜 통신이 안 되는 거죠?" 박시니어 씨가 차근차근 설명합니다.

"네트워크에서 가장 중요한 게 뭐게요? 바로 라우팅이에요.

패킷이 어디로 가야 하는지 알려주는 이정표가 필요해요." Transit Gateway 환경에서 라우팅은 두 단계로 구성됩니다. 먼저 VPC 내부에서 Transit Gateway로 트래픽을 보내는 것, 그 다음 Transit Gateway에서 목적지 VPC로 트래픽을 전달하는 것입니다.

첫 번째 단계: VPC 라우팅 테이블 설정 개발 VPC(10.2.0.0/16)에서 프로덕션 VPC(10.1.0.0/16)로 트래픽을 보내려면, 개발 VPC의 라우팅 테이블에 다음과 같은 경로가 필요합니다. "목적지가 10.1.0.0/16인 트래픽은 Transit Gateway로 보내라." 김개발 씨가 VPC 콘솔에서 개발 VPC의 Private 서브넷 라우팅 테이블을 열었습니다.

"라우팅 편집"을 클릭하고 새 경로를 추가합니다. 대상에 10.1.0.0/16을 입력하고, 타겟으로 Transit Gateway를 선택합니다.

반대 방향도 마찬가지입니다. 프로덕션 VPC의 라우팅 테이블에도 개발 VPC CIDR로 가는 경로를 Transit Gateway로 설정해야 합니다.

양방향 통신을 위해서는 양쪽 모두 설정이 필요합니다. 두 번째 단계: Transit Gateway 라우팅 테이블 설정 Transit Gateway 내부에도 라우팅 테이블이 있습니다.

이 테이블은 "10.1.0.0/16 트래픽은 프로덕션 VPC Attachment로, 10.2.0.0/16 트래픽은 개발 VPC Attachment로" 보내는 역할을 합니다. 여기서 두 가지 중요한 개념이 등장합니다.

Association과 Propagation입니다. Association은 Attachment가 어떤 라우팅 테이블을 사용할지 결정합니다.

프로덕션 VPC Attachment를 Main 라우팅 테이블에 Associate하면, 이 Attachment에서 나가는 트래픽은 Main 라우팅 테이블의 경로를 따릅니다. Propagation은 Attachment의 CIDR을 라우팅 테이블에 자동으로 등록합니다.

프로덕션 VPC Attachment를 Main 라우팅 테이블에 Propagate하면, 10.1.0.0/16 경로가 자동으로 추가됩니다. 수동으로 경로를 입력할 필요가 없어 편리합니다.

박시니어 씨가 정리합니다. "기본 라우팅 테이블 연결을 활성화했다면, 새 Attachment는 자동으로 기본 테이블에 Associate되고 경로도 Propagate돼요.

하지만 복잡한 환경에서는 직접 관리하는 게 더 안전해요." 김개발 씨가 설정을 마치고 다시 ping을 보내봤습니다. 이번에는 응답이 왔습니다.

"드디어 됐어요!" 라우팅이 네트워크의 핵심이라는 것을 몸소 체험한 순간입니다.

실전 팁

💡 - Propagation을 활용하면 수동으로 경로를 추가하는 수고를 줄일 수 있습니다

VPC CIDR이 겹치지 않도록 IP 주소 체계를 미리 설계하세요. CIDR이 겹치면 라우팅이 꼬입니다

5. Transit Gateway 라우팅 도메인

회사가 계속 성장하면서 보안팀에서 새로운 요구사항을 제시했습니다. "개발 VPC에서 프로덕션 데이터베이스에 직접 접근하면 안 됩니다.

모든 트래픽은 보안 검사 VPC를 거쳐야 합니다." 김개발 씨는 고민에 빠졌습니다. 지금까지는 모든 VPC가 서로 자유롭게 통신했는데, 어떻게 특정 경로만 차단하고 다른 경로는 허용할 수 있을까요?

라우팅 도메인은 Transit Gateway에서 네트워크를 논리적으로 분리하는 방법입니다. 서로 다른 라우팅 테이블을 사용하여 VPC 그룹 간의 통신을 제어할 수 있습니다.

예를 들어, 개발 환경과 프로덕션 환경을 분리하거나, 모든 트래픽을 보안 검사 VPC로 우회시키는 것이 가능합니다.

다음 코드를 살펴봅시다.

// 라우팅 도메인을 활용한 네트워크 분리 예제
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// 1. 환경별 라우팅 테이블 생성
const prodRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'ProdRT', {
  transitGatewayId: tgw.ref,
  tags: [{ key: 'Name', value: 'Production-Domain' }]
});

const devRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'DevRT', {
  transitGatewayId: tgw.ref,
  tags: [{ key: 'Name', value: 'Development-Domain' }]
});

// 2. 프로덕션 Attachment는 프로덕션 라우팅 테이블에 연결
new ec2.CfnTransitGatewayRouteTableAssociation(this, 'ProdAssoc', {
  transitGatewayAttachmentId: prodAttachment.ref,
  transitGatewayRouteTableId: prodRouteTable.ref
});

// 3. 개발 Attachment는 개발 라우팅 테이블에 연결
new ec2.CfnTransitGatewayRouteTableAssociation(this, 'DevAssoc', {
  transitGatewayAttachmentId: devAttachment.ref,
  transitGatewayRouteTableId: devRouteTable.ref
});

// 4. 개발에서 프로덕션으로 직접 경로 없음 (보안 VPC 경유 필요)
// 개발 라우팅 테이블에 프로덕션 CIDR 경로를 보안 VPC로 설정
new ec2.CfnTransitGatewayRoute(this, 'DevToProdViaInspection', {
  transitGatewayRouteTableId: devRouteTable.ref,
  destinationCidrBlock: '10.1.0.0/16',  // 프로덕션 CIDR
  transitGatewayAttachmentId: inspectionAttachment.ref  // 보안 검사 VPC 경유
});

김개발 씨가 보안팀의 요구사항을 듣고 막막해졌습니다. "전부 연결되어 있는데 어떻게 일부만 차단하죠?" 박시니어 씨가 웃으며 화이트보드로 향합니다.

"라우팅 도메인을 사용하면 돼요." Transit Gateway의 강력한 기능 중 하나는 여러 개의 라우팅 테이블을 가질 수 있다는 것입니다. 각 Attachment를 서로 다른 라우팅 테이블에 Associate함으로써, 네트워크를 논리적인 도메인으로 분리할 수 있습니다.

박시니어 씨가 그림을 그립니다. "프로덕션 도메인, 개발 도메인, 공유 서비스 도메인.

이렇게 세 개의 라우팅 테이블을 만들어요." 프로덕션 도메인 라우팅 테이블에는 프로덕션 VPC Attachment만 Associate합니다. 이 테이블에 개발 VPC CIDR 경로가 없으면, 프로덕션에서 개발로 가는 트래픽은 블랙홀에 빠집니다.

개발 도메인 라우팅 테이블에는 개발 VPC, 스테이징 VPC Attachment를 Associate합니다. 여기에 프로덕션 VPC CIDR 경로를 추가하지 않으면 직접 통신이 불가능합니다.

하지만 보안팀의 요구사항은 단순한 차단이 아닙니다. 개발에서 프로덕션으로 가는 트래픽을 보안 검사 VPC를 거쳐서 허용하고 싶은 것입니다.

이것도 가능합니다. 개발 도메인 라우팅 테이블에 프로덕션 CIDR(10.1.0.0/16) 경로를 추가합니다.

단, 타겟을 프로덕션 VPC Attachment가 아닌 보안 검사 VPC Attachment로 설정합니다. 트래픽이 보안 VPC를 먼저 거치고, 거기서 다시 프로덕션으로 갑니다.

보안 검사 VPC에는 AWS Network Firewall이나 서드파티 방화벽을 배치합니다. 모든 트래픽이 이곳을 통과하면서 검사를 받고, 정상적인 트래픽만 목적지로 전달됩니다.

이것을 Inspection VPC 패턴이라고 부릅니다. 김개발 씨가 감탄합니다.

"단순히 차단만 하는 게 아니라, 경유지를 지정할 수도 있군요!" 박시니어 씨가 고개를 끄덕입니다. "네, 이게 Transit Gateway의 진짜 힘이에요.

단순한 연결이 아니라 트래픽 흐름을 설계할 수 있어요." 라우팅 도메인을 설계할 때 주의할 점이 있습니다. 너무 복잡하게 나누면 관리가 어려워집니다.

대부분의 경우 프로덕션/비프로덕션 정도로 나누는 것으로 충분합니다. 필요에 따라 Shared Services 도메인을 추가하는 정도가 적당합니다.

또한 비대칭 라우팅에 주의해야 합니다. A에서 B로 가는 경로와 B에서 A로 돌아오는 경로가 다르면 상태 기반 방화벽이 제대로 동작하지 않을 수 있습니다.

왕복 경로가 동일하도록 신경 써서 설계해야 합니다.

실전 팁

💡 - 라우팅 도메인은 2-4개 정도로 단순하게 유지하세요. 너무 많으면 관리가 복잡해집니다

Inspection VPC 패턴을 사용할 때는 반드시 왕복 경로가 동일하도록 설계하세요

6. VPC 피어링 vs Transit Gateway 비교

신입 개발자 이주니어 씨가 김개발 씨에게 질문했습니다. "선배, VPC 피어링이랑 Transit Gateway 중에 뭘 써야 해요?

둘 다 VPC를 연결하는 건 똑같잖아요." 김개발 씨는 예전에 박시니어 씨에게 배웠던 내용을 떠올리며 차근차근 설명하기 시작합니다.

VPC 피어링과 Transit Gateway는 모두 VPC 간 연결을 제공하지만, 사용 사례가 다릅니다. VPC 피어링은 두 VPC 간의 직접적인 1:1 연결로, 단순하고 비용이 없습니다.

Transit Gateway는 중앙 허브를 통한 다대다 연결로, 확장성과 관리 편의성이 뛰어나지만 비용이 발생합니다.

다음 코드를 살펴봅시다.

// VPC 피어링 vs Transit Gateway 비교 예제

// === VPC 피어링 방식 ===
// VPC A <-> VPC B 직접 연결
const peering = new ec2.CfnVPCPeeringConnection(this, 'AtoB', {
  vpcId: vpcA.vpcId,
  peerVpcId: vpcB.vpcId
});

// 각 VPC 라우팅 테이블에 피어링 경로 추가 필요
// 5개 VPC 연결 시: 10개 피어링 + 40개 이상 라우팅 룰

// === Transit Gateway 방식 ===
// 중앙 허브를 통한 연결
const tgw = new ec2.CfnTransitGateway(this, 'Hub', {
  description: 'Central routing hub'
});

// 각 VPC는 TGW에 한 번만 연결
// 5개 VPC 연결 시: 5개 Attachment + 자동 라우팅

// 비용 비교 (서울 리전 기준, 2024년)
// VPC 피어링: 데이터 전송 비용만 (리전 내 $0.01/GB)
// Transit Gateway:
//   - Attachment: $0.05/시간 (약 $36/월/VPC)
//   - 데이터 처리: $0.02/GB

김개발 씨가 화이트보드에 두 개의 그림을 나란히 그렸습니다. 왼쪽에는 VPC들이 복잡하게 얽힌 그물망, 오른쪽에는 중앙에 허브가 있는 깔끔한 별 모양입니다.

"먼저 VPC 피어링부터 볼게요." 김개발 씨가 왼쪽 그림을 가리킵니다. VPC 피어링은 두 VPC 간의 직접적인 사설 연결입니다.

마치 두 집 사이에 담을 허물고 통로를 만드는 것과 같습니다. 설정이 간단하고, 무엇보다 연결 자체에 비용이 들지 않습니다.

데이터 전송 비용만 발생합니다. VPC 피어링의 가장 큰 장점은 레이턴시입니다.

두 VPC가 직접 연결되어 있기 때문에 중간 단계가 없습니다. Transit Gateway는 허브를 거치므로 아주 약간의 추가 레이턴시가 있습니다.

극도로 낮은 레이턴시가 필요한 경우 피어링이 유리합니다. 하지만 VPC 피어링에는 치명적인 단점이 있습니다.

바로 전이적 라우팅(Transitive Routing) 불가입니다. 이주니어 씨가 고개를 갸웃거립니다.

"전이적 라우팅이 뭐예요?" 김개발 씨가 설명합니다. "VPC A와 B가 피어링되어 있고, B와 C도 피어링되어 있다고 해봐요.

그러면 A에서 C로 B를 거쳐서 갈 수 있을까요? 안 돼요.

A에서 C로 가려면 별도로 A-C 피어링을 만들어야 해요." 이것이 풀 메시 문제의 원인입니다. N개의 VPC를 모두 연결하려면 N(N-1)/2개의 피어링이 필요합니다.

10개 VPC면 45개, 20개면 190개입니다. "이제 Transit Gateway를 보죠." 김개발 씨가 오른쪽 그림을 가리킵니다.

Transit Gateway는 전이적 라우팅을 지원합니다. 모든 VPC가 중앙 허브에 연결되어 있으므로, 어느 VPC에서든 다른 모든 VPC로 갈 수 있습니다.

새 VPC를 추가해도 기존 설정을 건드릴 필요가 없습니다. 또한 라우팅 도메인으로 세밀한 트래픽 제어가 가능합니다.

특정 VPC 그룹 간의 통신을 차단하거나, 보안 VPC를 경유하도록 설정할 수 있습니다. VPC 피어링으로는 이런 복잡한 라우팅이 불가능합니다.

하지만 Transit Gateway는 비용이 발생합니다. 서울 리전 기준으로 Attachment당 시간당 약 $0.05, 월 약 $36입니다.

여기에 데이터 처리 비용 GB당 $0.02가 추가됩니다. VPC가 10개면 Attachment 비용만 월 $360입니다.

언제 무엇을 사용해야 할까요? VPC 피어링을 선택하세요: - VPC가 2-3개뿐이고 늘어날 계획이 없을 때 - 비용을 최소화해야 할 때 - 최저 레이턴시가 필요할 때 Transit Gateway를 선택하세요: - VPC가 4개 이상이거나 계속 늘어날 예정일 때 - 중앙 집중식 네트워크 관리가 필요할 때 - 온프레미스 연결(VPN, Direct Connect)이 필요할 때 - 복잡한 라우팅 정책이 필요할 때 이주니어 씨가 고개를 끄덕입니다.

"우리 회사는 VPC가 계속 늘어나고 있으니까 Transit Gateway가 맞겠네요." 김개발 씨가 웃으며 답합니다. "맞아요.

초기 비용이 들어도 장기적으로는 Transit Gateway가 훨씬 효율적이에요."

실전 팁

💡 - VPC 2-3개까지는 피어링, 4개 이상이면 Transit Gateway를 검토하세요

하이브리드 접근도 가능합니다. 레이턴시가 중요한 연결은 피어링으로, 나머지는 Transit Gateway로 구성할 수 있습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#TransitGateway#VPC#Networking#CloudArchitecture#AWS,Transit Gateway,Network

Transit Gateway로 복잡한 네트워크 중앙 집중화 완벽 가이드

# Transit Gateway로 복잡한 네트워크 중앙 집중화 완벽 가이드 AWS Transit Gateway를 활용하여 복잡한 VPC 네트워크를 중앙에서 효율적으로 관리하는 방법을 알아봅니다. Hub-and-Spoke 아키텍처부터 라우팅 테이블 구성까지 실무에 필요한 모든 것을 다룹니다. --- ## 목차 1. [Transit_Gateway의_필요성](#transit-gateway의-필요성) 2. [Hub_and_Spoke_아키텍처_이해](#hub-and-spoke-아키텍처-이해) 3. [Transit_Gateway_생성_및_VPC_연결](#transit-gateway-생성-및-vpc-연결) 4. [라우팅_테이블_및_Association](#라우팅-테이블-및-association) 5. [Transit_Gateway_라우팅_도메인](#transit-gateway-라우팅-도메인) 6. [VPC_피어링_vs_Transit_Gateway_비교](#vpc-피어링-vs-transit-gateway-비교) --- ## 1. Transit_Gateway의_필요성 김개발 씨는 스타트업에서 클라우드 인프라를 담당하는 주니어 엔지니어입니다. 처음에는 VPC 하나로 시작했던 서비스가 어느새 10개가 넘는 VPC로 늘어났습니다. 각 VPC를 서로 연결하기 위해 VPC 피어링을 설정하다 보니, 연결 개수가 기하급수적으로 늘어나 관리가 불가능한 지경에 이르렀습니다. **Transit Gateway**는 한마디로 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브에서 연결하고 관리하는 서비스입니다. 마치 공항의 허브 터미널처럼, 모든 네트워크 트래픽이 한 곳을 거쳐 목적지로 향하게 됩니다. 이를 통해 네트워크 구성이 단순해지고 관리 부담이 크게 줄어듭니다. 다음 코드를 살펴봅시다. ```typescript // AWS CDK로 Transit Gateway 필요성을 보여주는 예제 import * as ec2 from 'aws-cdk-lib/aws-ec2'; // 문제 상황: 5개 VPC를 피어링으로 연결하면? // 필요한 피어링 수 = n(n-1)/2 = 5*4/2 = 10개의 연결 필요! // VPC 피어링 방식 (복잡함) const vpcA = new ec2.Vpc(this, 'VpcA', { maxAzs: 2 }); const vpcB = new ec2.Vpc(this, 'VpcB', { maxAzs: 2 }); // A-B, A-C, A-D, A-E, B-C, B-D, B-E, C-D, C-E, D-E... 관리 불가! // Transit Gateway 방식 (단순함) // 각 VPC는 Transit Gateway에 한 번만 연결하면 됨 // 5개 VPC = 5개 연결만 필요 ``` 김개발 씨가 입사했을 때, 회사의 AWS 인프라는 단순했습니다. 프로덕션 VPC 하나, 개발 VPC 하나. 이 둘을 연결하기 위해 VPC 피어링을 설정했고, 모든 것이 깔끔하게 돌아갔습니다. 그런데 서비스가 성장하면서 상황이 복잡해지기 시작했습니다. 스테이징 환경이 추가되고, 데이터 분석팀을 위한 VPC가 생겼습니다. 보안팀에서는 별도의 보안 모니터링 VPC를 요청했고, 파트너사와의 연동을 위한 DMZ VPC도 필요해졌습니다. **VPC 피어링**의 특성상, N개의 VPC를 모두 연결하려면 N(N-1)/2개의 피어링이 필요합니다. 5개 VPC만 해도 10개의 피어링 연결이 필요하고, 10개 VPC라면 무려 45개의 연결을 관리해야 합니다. 이것을 **풀 메시(Full Mesh)** 토폴로지라고 부릅니다. 김개발 씨는 매일 아침 출근하면 피어링 연결 상태를 확인하는 것부터 시작했습니다. 새로운 VPC가 추가될 때마다 기존 모든 VPC에 피어링을 설정하고, 각 VPC의 라우팅 테이블에 경로를 일일이 추가해야 했습니다. 실수라도 하면 서비스 장애로 이어졌습니다. 선배 엔지니어 박시니어 씨가 이 상황을 보고 조언했습니다. "우리 회사 규모가 커졌으니, 이제 **Transit Gateway**를 도입할 때가 됐어요." Transit Gateway는 마치 **공항의 허브 터미널**과 같습니다. 인천공항이 아시아의 허브 공항인 것처럼, 여러 도시를 직항으로 연결하는 대신 허브를 거쳐 가면 항공사는 노선 수를 크게 줄일 수 있습니다. 네트워크도 마찬가지입니다. Transit Gateway를 도입하면, 각 VPC는 오직 Transit Gateway에만 연결하면 됩니다. 10개 VPC가 있어도 연결은 10개면 충분합니다. 새 VPC가 추가되어도 Transit Gateway에 한 번만 연결하면 기존 모든 VPC와 통신이 가능해집니다. 더 좋은 점은 **중앙 집중식 관리**입니다. 모든 라우팅 정책을 Transit Gateway에서 한 번에 설정할 수 있습니다. 특정 VPC 간 통신을 차단하거나, 트래픽을 검사용 VPC로 우회시키는 것도 손쉽게 가능합니다. 김개발 씨는 Transit Gateway 도입 후, 네트워크 관리에 들이는 시간이 절반 이하로 줄었다고 합니다. 무엇보다 새 VPC를 추가할 때의 스트레스가 사라졌습니다. 이제는 체계적인 네트워크 구성도를 그릴 수 있게 되었습니다. **실전 팁** 💡 - VPC가 3개 이상이고 서로 통신이 필요하다면 Transit Gateway 도입을 검토하세요 - Transit Gateway는 리전 단위 서비스이므로, 멀티 리전 환경에서는 각 리전에 별도로 생성해야 합니다 --- ## 2. Hub_and_Spoke_아키텍처_이해 박시니어 씨가 화이트보드 앞에 섰습니다. "Transit Gateway를 제대로 이해하려면 먼저 **Hub-and-Spoke 아키텍처**를 알아야 해요." 김개발 씨는 노트를 꺼내 들었습니다. 네트워크 아키텍처의 기본 중의 기본, 하지만 제대로 이해하고 있는 사람은 의외로 많지 않습니다. **Hub-and-Spoke 아키텍처**는 중앙의 허브를 중심으로 여러 스포크가 방사형으로 연결되는 네트워크 구조입니다. 마치 자전거 바퀴살이 중앙 축에서 바깥쪽 테두리로 뻗어나가는 모양과 같습니다. Transit Gateway가 허브 역할을 하고, 각 VPC가 스포크가 됩니다. 다음 코드를 살펴봅시다. ```typescript // Hub-and-Spoke 아키텍처 구성 예제 (AWS CDK) import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; // Hub: Transit Gateway 생성 const transitGateway = new ec2.CfnTransitGateway(this, 'TGW', { description: 'Central Hub for all VPCs', defaultRouteTableAssociation: 'enable', defaultRouteTablePropagation: 'enable', tags: [{ key: 'Name', value: 'MainHub-TGW' }] }); // Spoke 1: Production VPC const prodVpc = new ec2.Vpc(this, 'ProdVpc', { ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'), maxAzs: 2 }); // Spoke 2: Development VPC const devVpc = new ec2.Vpc(this, 'DevVpc', { ipAddresses: ec2.IpAddresses.cidr('10.2.0.0/16'), maxAzs: 2 }); // 각 Spoke를 Hub에 연결 (Attachment) ``` 박시니어 씨가 화이트보드에 동그라미 하나를 그렸습니다. "이게 허브예요." 그리고 그 주변에 여러 개의 작은 동그라미를 그린 뒤, 선으로 중앙과 연결했습니다. "이게 스포크고요." 김개발 씨가 고개를 갸웃거렸습니다. "자전거 바퀴 같네요?" 박시니어 씨가 웃으며 답했습니다. "정확해요! 실제로 자전거 바퀴에서 이름을 따온 거예요." **Hub-and-Spoke 아키텍처**는 네트워크 설계의 고전적인 패턴입니다. 중앙의 허브가 모든 통신의 교차점이 되고, 각 스포크는 허브를 통해서만 다른 스포크와 통신합니다. 직접 연결은 존재하지 않습니다. 이 구조의 가장 큰 장점은 **단순함**입니다. 새로운 스포크(VPC)를 추가할 때, 오직 허브와의 연결만 설정하면 됩니다. 기존 스포크들의 설정을 건드릴 필요가 전혀 없습니다. 풀 메시 구조에서 겪었던 복잡성이 완전히 사라집니다. 또 다른 장점은 **중앙 집중식 제어**입니다. 모든 트래픽이 허브를 거치기 때문에, 허브에서 보안 정책을 적용하거나 트래픽을 모니터링하기가 매우 용이합니다. 방화벽, 침입 탐지 시스템 등을 허브에 배치하면 모든 통신을 검사할 수 있습니다. 박시니어 씨가 실제 사례를 들어 설명했습니다. "우리 회사로 치면, Transit Gateway가 허브고 프로덕션 VPC, 개발 VPC, 스테이징 VPC가 각각 스포크인 거예요. 개발팀에서 프로덕션 데이터베이스에 접근해야 할 때, 트래픽은 개발 VPC에서 Transit Gateway를 거쳐 프로덕션 VPC로 갑니다." 김개발 씨가 질문했습니다. "그러면 허브에 문제가 생기면 전체 네트워크가 마비되는 거 아닌가요?" 좋은 질문입니다. 이것을 **단일 장애점(Single Point of Failure)** 문제라고 합니다. 다행히 AWS Transit Gateway는 이 문제를 해결하기 위해 설계되었습니다. Transit Gateway는 기본적으로 **고가용성**을 제공합니다. 여러 가용 영역에 걸쳐 자동으로 확장되며, AWS가 내부적으로 이중화를 관리합니다. 사용자가 별도로 이중화를 구성할 필요가 없습니다. Hub-and-Spoke의 변형으로 **Shared Services 모델**도 있습니다. 허브 VPC에 공통으로 사용하는 서비스들(Active Directory, DNS, 모니터링 도구 등)을 배치하고, 모든 스포크 VPC에서 이를 공유하는 방식입니다. 김개발 씨는 화이트보드의 그림을 사진으로 찍었습니다. "이제 왜 Transit Gateway가 필요한지 확실히 알겠어요. 복잡한 풀 메시 대신 깔끔한 허브 구조로 가는 거군요." **실전 팁** 💡 - Hub-and-Spoke 구조에서 허브는 반드시 고가용성을 갖춰야 합니다. Transit Gateway는 이를 기본 제공합니다 - 공유 서비스(DNS, AD 등)는 별도의 Shared Services VPC에 두고 Hub를 통해 접근하게 설계하세요 --- ## 3. Transit_Gateway_생성_및_VPC_연결 이론 공부는 충분히 했습니다. 이제 김개발 씨는 실제로 Transit Gateway를 생성하고 VPC를 연결해볼 차례입니다. AWS 콘솔을 열고 손에 땀을 쥐며 첫 번째 Transit Gateway를 만들어봅니다. 생각보다 간단하지만, 몇 가지 중요한 설정을 놓치면 나중에 큰 문제가 될 수 있습니다. Transit Gateway를 생성하고 VPC를 연결하는 과정은 크게 두 단계로 나뉩니다. 먼저 **Transit Gateway**를 생성하고, 그 다음 각 VPC에 대해 **Transit Gateway Attachment**를 만들어 연결합니다. Attachment는 VPC의 특정 서브넷을 Transit Gateway에 연결하는 역할을 합니다. 다음 코드를 살펴봅시다. ```typescript // AWS CDK로 Transit Gateway 생성 및 VPC 연결 import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as cdk from 'aws-cdk-lib'; // 1. Transit Gateway 생성 const tgw = new ec2.CfnTransitGateway(this, 'MainTGW', { amazonSideAsn: 64512, // BGP ASN 번호 autoAcceptSharedAttachments: 'enable', defaultRouteTableAssociation: 'enable', defaultRouteTablePropagation: 'enable', dnsSupport: 'enable', vpnEcmpSupport: 'enable', tags: [{ key: 'Name', value: 'Production-TGW' }] }); // 2. VPC 생성 (프로덕션용) const prodVpc = new ec2.Vpc(this, 'ProdVpc', { ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'), maxAzs: 2, subnetConfiguration: [ { name: 'Public', subnetType: ec2.SubnetType.PUBLIC }, { name: 'Private', subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }, { name: 'TGW', subnetType: ec2.SubnetType.PRIVATE_ISOLATED } ] }); // 3. Transit Gateway Attachment 생성 const tgwAttachment = new ec2.CfnTransitGatewayAttachment(this, 'ProdAttachment', { transitGatewayId: tgw.ref, vpcId: prodVpc.vpcId, subnetIds: prodVpc.selectSubnets({ subnetGroupName: 'TGW' }).subnetIds }); ``` 김개발 씨가 AWS 콘솔에서 VPC 서비스로 이동했습니다. 왼쪽 메뉴에서 Transit Gateway를 클릭하고 "Transit Gateway 생성" 버튼을 누릅니다. 첫 번째로 마주하는 설정은 **ASN(Autonomous System Number)**입니다. 박시니어 씨가 설명합니다. "BGP 라우팅에 사용되는 번호예요. AWS 기본값인 64512를 사용해도 되고, 온프레미스 네트워크와 연결할 예정이라면 충돌하지 않는 번호를 선택해야 해요." 다음은 몇 가지 중요한 옵션들입니다. **DNS 지원**을 활성화하면 Transit Gateway를 통해 연결된 VPC 간에 프라이빗 DNS 호스트 이름이 해석됩니다. 대부분의 경우 활성화하는 것이 좋습니다. **기본 라우팅 테이블 연결** 옵션도 있습니다. 이를 활성화하면 새로운 Attachment가 자동으로 기본 라우팅 테이블에 연결됩니다. 처음에는 편리하지만, 복잡한 환경에서는 비활성화하고 수동으로 관리하는 것이 더 안전합니다. Transit Gateway가 생성되었습니다. 상태가 "available"로 바뀌면 VPC를 연결할 수 있습니다. 이제 **Transit Gateway Attachment**를 생성할 차례입니다. 여기서 중요한 결정을 해야 합니다. 어떤 서브넷을 Transit Gateway에 연결할 것인가? 박시니어 씨가 조언합니다. "Transit Gateway 전용 서브넷을 만드는 것을 추천해요. 가용 영역당 하나씩, /28 정도의 작은 서브넷이면 충분해요." 이렇게 하면 Transit Gateway 트래픽이 애플리케이션 서브넷과 분리되어 관리하기 쉽습니다. 김개발 씨가 프로덕션 VPC에 TGW 서브넷을 추가했습니다. ap-northeast-2a에 10.1.240.0/28, ap-northeast-2c에 10.1.241.0/28. 작지만 Transit Gateway ENI(Elastic Network Interface)를 배치하기에 충분합니다. Attachment를 생성하면 AWS가 지정한 서브넷에 **ENI를 자동으로 생성**합니다. 이 ENI를 통해 VPC의 트래픽이 Transit Gateway로 흘러갑니다. 주의할 점은, 이 ENI가 생성된 서브넷의 라우팅 테이블에서 Transit Gateway로 가는 경로가 설정되어야 한다는 것입니다. 김개발 씨가 개발 VPC, 스테이징 VPC에도 같은 과정을 반복했습니다. 각 VPC에 TGW 서브넷을 만들고, Attachment를 생성합니다. 콘솔에서 Transit Gateway Attachments 목록을 보니 세 개의 VPC가 모두 연결된 것이 보입니다. 하지만 아직 끝이 아닙니다. Attachment만 만들었다고 트래픽이 바로 흐르지는 않습니다. 각 VPC의 라우팅 테이블에 Transit Gateway로 가는 경로를 추가해야 합니다. 이 부분은 다음 섹션에서 자세히 다루겠습니다. **실전 팁** 💡 - Transit Gateway 전용 서브넷을 별도로 만들어 관리하면 네트워크 구성이 깔끔해집니다 - 각 가용 영역에 Attachment 서브넷을 배치해야 고가용성이 보장됩니다 --- ## 4. 라우팅_테이블_및_Association Transit Gateway와 VPC Attachment를 생성했지만, 아직 VPC 간 통신이 되지 않습니다. 김개발 씨가 개발 VPC의 EC2에서 프로덕션 VPC의 데이터베이스로 ping을 보내봤지만 응답이 없습니다. 무엇이 빠진 걸까요? 바로 **라우팅 테이블** 설정입니다. 네트워크에서 길을 알려주는 이정표가 없으면 패킷은 목적지를 찾지 못합니다. Transit Gateway 환경에서 라우팅은 두 곳에서 설정해야 합니다. 첫째, 각 **VPC의 라우팅 테이블**에 다른 VPC CIDR로 가는 트래픽을 Transit Gateway로 보내는 경로를 추가합니다. 둘째, **Transit Gateway 라우팅 테이블**에서 어떤 Attachment로 트래픽을 전달할지 결정합니다. Association은 Attachment와 라우팅 테이블을 연결하는 작업입니다. 다음 코드를 살펴봅시다. ```typescript // VPC 라우팅 테이블 및 Transit Gateway 라우팅 설정 import * as ec2 from 'aws-cdk-lib/aws-ec2'; // 1. VPC 라우팅 테이블에 Transit Gateway 경로 추가 // 프로덕션 VPC의 Private 서브넷 라우팅 테이블 const prodRouteTable = new ec2.CfnRoute(this, 'ProdToDevRoute', { routeTableId: prodPrivateSubnet.routeTable.routeTableId, destinationCidrBlock: '10.2.0.0/16', // 개발 VPC CIDR transitGatewayId: tgw.ref }); // 2. Transit Gateway 라우팅 테이블 생성 const tgwRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'TGWRouteTable', { transitGatewayId: tgw.ref, tags: [{ key: 'Name', value: 'Main-TGW-RT' }] }); // 3. Association: Attachment를 라우팅 테이블에 연결 const association = new ec2.CfnTransitGatewayRouteTableAssociation(this, 'ProdAssoc', { transitGatewayAttachmentId: prodAttachment.ref, transitGatewayRouteTableId: tgwRouteTable.ref }); // 4. Propagation: 경로 자동 전파 설정 const propagation = new ec2.CfnTransitGatewayRouteTablePropagation(this, 'ProdProp', { transitGatewayAttachmentId: prodAttachment.ref, transitGatewayRouteTableId: tgwRouteTable.ref }); ``` 김개발 씨가 곤란한 표정으로 박시니어 씨를 찾아왔습니다. "Transit Gateway도 만들고 Attachment도 연결했는데, 왜 통신이 안 되는 거죠?" 박시니어 씨가 차근차근 설명합니다. "네트워크에서 가장 중요한 게 뭐게요? 바로 **라우팅**이에요. 패킷이 어디로 가야 하는지 알려주는 이정표가 필요해요." Transit Gateway 환경에서 라우팅은 **두 단계**로 구성됩니다. 먼저 VPC 내부에서 Transit Gateway로 트래픽을 보내는 것, 그 다음 Transit Gateway에서 목적지 VPC로 트래픽을 전달하는 것입니다. **첫 번째 단계: VPC 라우팅 테이블 설정** 개발 VPC(10.2.0.0/16)에서 프로덕션 VPC(10.1.0.0/16)로 트래픽을 보내려면, 개발 VPC의 라우팅 테이블에 다음과 같은 경로가 필요합니다. "목적지가 10.1.0.0/16인 트래픽은 Transit Gateway로 보내라." 김개발 씨가 VPC 콘솔에서 개발 VPC의 Private 서브넷 라우팅 테이블을 열었습니다. "라우팅 편집"을 클릭하고 새 경로를 추가합니다. 대상에 10.1.0.0/16을 입력하고, 타겟으로 Transit Gateway를 선택합니다. 반대 방향도 마찬가지입니다. 프로덕션 VPC의 라우팅 테이블에도 개발 VPC CIDR로 가는 경로를 Transit Gateway로 설정해야 합니다. 양방향 통신을 위해서는 양쪽 모두 설정이 필요합니다. **두 번째 단계: Transit Gateway 라우팅 테이블 설정** Transit Gateway 내부에도 라우팅 테이블이 있습니다. 이 테이블은 "10.1.0.0/16 트래픽은 프로덕션 VPC Attachment로, 10.2.0.0/16 트래픽은 개발 VPC Attachment로" 보내는 역할을 합니다. 여기서 두 가지 중요한 개념이 등장합니다. **Association**과 **Propagation**입니다. **Association**은 Attachment가 어떤 라우팅 테이블을 사용할지 결정합니다. 프로덕션 VPC Attachment를 Main 라우팅 테이블에 Associate하면, 이 Attachment에서 나가는 트래픽은 Main 라우팅 테이블의 경로를 따릅니다. **Propagation**은 Attachment의 CIDR을 라우팅 테이블에 자동으로 등록합니다. 프로덕션 VPC Attachment를 Main 라우팅 테이블에 Propagate하면, 10.1.0.0/16 경로가 자동으로 추가됩니다. 수동으로 경로를 입력할 필요가 없어 편리합니다. 박시니어 씨가 정리합니다. "기본 라우팅 테이블 연결을 활성화했다면, 새 Attachment는 자동으로 기본 테이블에 Associate되고 경로도 Propagate돼요. 하지만 복잡한 환경에서는 직접 관리하는 게 더 안전해요." 김개발 씨가 설정을 마치고 다시 ping을 보내봤습니다. 이번에는 응답이 왔습니다. "드디어 됐어요!" 라우팅이 네트워크의 핵심이라는 것을 몸소 체험한 순간입니다. **실전 팁** 💡 - Propagation을 활용하면 수동으로 경로를 추가하는 수고를 줄일 수 있습니다 - VPC CIDR이 겹치지 않도록 IP 주소 체계를 미리 설계하세요. CIDR이 겹치면 라우팅이 꼬입니다 --- ## 5. Transit_Gateway_라우팅_도메인 회사가 계속 성장하면서 보안팀에서 새로운 요구사항을 제시했습니다. "개발 VPC에서 프로덕션 데이터베이스에 직접 접근하면 안 됩니다. 모든 트래픽은 보안 검사 VPC를 거쳐야 합니다." 김개발 씨는 고민에 빠졌습니다. 지금까지는 모든 VPC가 서로 자유롭게 통신했는데, 어떻게 특정 경로만 차단하고 다른 경로는 허용할 수 있을까요? **라우팅 도메인**은 Transit Gateway에서 네트워크를 논리적으로 분리하는 방법입니다. 서로 다른 라우팅 테이블을 사용하여 VPC 그룹 간의 통신을 제어할 수 있습니다. 예를 들어, 개발 환경과 프로덕션 환경을 분리하거나, 모든 트래픽을 보안 검사 VPC로 우회시키는 것이 가능합니다. 다음 코드를 살펴봅시다. ```typescript // 라우팅 도메인을 활용한 네트워크 분리 예제 import * as ec2 from 'aws-cdk-lib/aws-ec2'; // 1. 환경별 라우팅 테이블 생성 const prodRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'ProdRT', { transitGatewayId: tgw.ref, tags: [{ key: 'Name', value: 'Production-Domain' }] }); const devRouteTable = new ec2.CfnTransitGatewayRouteTable(this, 'DevRT', { transitGatewayId: tgw.ref, tags: [{ key: 'Name', value: 'Development-Domain' }] }); // 2. 프로덕션 Attachment는 프로덕션 라우팅 테이블에 연결 new ec2.CfnTransitGatewayRouteTableAssociation(this, 'ProdAssoc', { transitGatewayAttachmentId: prodAttachment.ref, transitGatewayRouteTableId: prodRouteTable.ref }); // 3. 개발 Attachment는 개발 라우팅 테이블에 연결 new ec2.CfnTransitGatewayRouteTableAssociation(this, 'DevAssoc', { transitGatewayAttachmentId: devAttachment.ref, transitGatewayRouteTableId: devRouteTable.ref }); // 4. 개발에서 프로덕션으로 직접 경로 없음 (보안 VPC 경유 필요) // 개발 라우팅 테이블에 프로덕션 CIDR 경로를 보안 VPC로 설정 new ec2.CfnTransitGatewayRoute(this, 'DevToProdViaInspection', { transitGatewayRouteTableId: devRouteTable.ref, destinationCidrBlock: '10.1.0.0/16', // 프로덕션 CIDR transitGatewayAttachmentId: inspectionAttachment.ref // 보안 검사 VPC 경유 }); ``` 김개발 씨가 보안팀의 요구사항을 듣고 막막해졌습니다. "전부 연결되어 있는데 어떻게 일부만 차단하죠?" 박시니어 씨가 웃으며 화이트보드로 향합니다. "**라우팅 도메인**을 사용하면 돼요." Transit Gateway의 강력한 기능 중 하나는 **여러 개의 라우팅 테이블**을 가질 수 있다는 것입니다. 각 Attachment를 서로 다른 라우팅 테이블에 Associate함으로써, 네트워크를 논리적인 도메인으로 분리할 수 있습니다. 박시니어 씨가 그림을 그립니다. "프로덕션 도메인, 개발 도메인, 공유 서비스 도메인. 이렇게 세 개의 라우팅 테이블을 만들어요." **프로덕션 도메인** 라우팅 테이블에는 프로덕션 VPC Attachment만 Associate합니다. 이 테이블에 개발 VPC CIDR 경로가 없으면, 프로덕션에서 개발로 가는 트래픽은 블랙홀에 빠집니다. **개발 도메인** 라우팅 테이블에는 개발 VPC, 스테이징 VPC Attachment를 Associate합니다. 여기에 프로덕션 VPC CIDR 경로를 추가하지 않으면 직접 통신이 불가능합니다. 하지만 보안팀의 요구사항은 단순한 차단이 아닙니다. 개발에서 프로덕션으로 가는 트래픽을 **보안 검사 VPC를 거쳐서** 허용하고 싶은 것입니다. 이것도 가능합니다. 개발 도메인 라우팅 테이블에 프로덕션 CIDR(10.1.0.0/16) 경로를 추가합니다. 단, 타겟을 프로덕션 VPC Attachment가 아닌 **보안 검사 VPC Attachment**로 설정합니다. 트래픽이 보안 VPC를 먼저 거치고, 거기서 다시 프로덕션으로 갑니다. 보안 검사 VPC에는 AWS Network Firewall이나 서드파티 방화벽을 배치합니다. 모든 트래픽이 이곳을 통과하면서 검사를 받고, 정상적인 트래픽만 목적지로 전달됩니다. 이것을 **Inspection VPC 패턴**이라고 부릅니다. 김개발 씨가 감탄합니다. "단순히 차단만 하는 게 아니라, 경유지를 지정할 수도 있군요!" 박시니어 씨가 고개를 끄덕입니다. "네, 이게 Transit Gateway의 진짜 힘이에요. 단순한 연결이 아니라 **트래픽 흐름을 설계**할 수 있어요." 라우팅 도메인을 설계할 때 주의할 점이 있습니다. 너무 복잡하게 나누면 관리가 어려워집니다. 대부분의 경우 프로덕션/비프로덕션 정도로 나누는 것으로 충분합니다. 필요에 따라 Shared Services 도메인을 추가하는 정도가 적당합니다. 또한 **비대칭 라우팅**에 주의해야 합니다. A에서 B로 가는 경로와 B에서 A로 돌아오는 경로가 다르면 상태 기반 방화벽이 제대로 동작하지 않을 수 있습니다. 왕복 경로가 동일하도록 신경 써서 설계해야 합니다. **실전 팁** 💡 - 라우팅 도메인은 2-4개 정도로 단순하게 유지하세요. 너무 많으면 관리가 복잡해집니다 - Inspection VPC 패턴을 사용할 때는 반드시 왕복 경로가 동일하도록 설계하세요 --- ## 6. VPC_피어링_vs_Transit_Gateway_비교 신입 개발자 이주니어 씨가 김개발 씨에게 질문했습니다. "선배, VPC 피어링이랑 Transit Gateway 중에 뭘 써야 해요? 둘 다 VPC를 연결하는 건 똑같잖아요." 김개발 씨는 예전에 박시니어 씨에게 배웠던 내용을 떠올리며 차근차근 설명하기 시작합니다. **VPC 피어링**과 **Transit Gateway**는 모두 VPC 간 연결을 제공하지만, 사용 사례가 다릅니다. VPC 피어링은 두 VPC 간의 직접적인 1:1 연결로, 단순하고 비용이 없습니다. Transit Gateway는 중앙 허브를 통한 다대다 연결로, 확장성과 관리 편의성이 뛰어나지만 비용이 발생합니다. 다음 코드를 살펴봅시다. ```typescript // VPC 피어링 vs Transit Gateway 비교 예제 // === VPC 피어링 방식 === // VPC A VPC B 직접 연결 const peering = new ec2.CfnVPCPeeringConnection(this, 'AtoB', { vpcId: vpcA.vpcId, peerVpcId: vpcB.vpcId }); // 각 VPC 라우팅 테이블에 피어링 경로 추가 필요 // 5개 VPC 연결 시: 10개 피어링 + 40개 이상 라우팅 룰 // === Transit Gateway 방식 === // 중앙 허브를 통한 연결 const tgw = new ec2.CfnTransitGateway(this, 'Hub', { description: 'Central routing hub' }); // 각 VPC는 TGW에 한 번만 연결 // 5개 VPC 연결 시: 5개 Attachment + 자동 라우팅 // 비용 비교 (서울 리전 기준, 2024년) // VPC 피어링: 데이터 전송 비용만 (리전 내 $0.01/GB) // Transit Gateway: // - Attachment: $0.05/시간 (약 $36/월/VPC) // - 데이터 처리: $0.02/GB ``` 김개발 씨가 화이트보드에 두 개의 그림을 나란히 그렸습니다. 왼쪽에는 VPC들이 복잡하게 얽힌 그물망, 오른쪽에는 중앙에 허브가 있는 깔끔한 별 모양입니다. "먼저 **VPC 피어링**부터 볼게요." 김개발 씨가 왼쪽 그림을 가리킵니다. VPC 피어링은 두 VPC 간의 **직접적인 사설 연결**입니다. 마치 두 집 사이에 담을 허물고 통로를 만드는 것과 같습니다. 설정이 간단하고, 무엇보다 **연결 자체에 비용이 들지 않습니다**. 데이터 전송 비용만 발생합니다. VPC 피어링의 가장 큰 장점은 **레이턴시**입니다. 두 VPC가 직접 연결되어 있기 때문에 중간 단계가 없습니다. Transit Gateway는 허브를 거치므로 아주 약간의 추가 레이턴시가 있습니다. 극도로 낮은 레이턴시가 필요한 경우 피어링이 유리합니다. 하지만 VPC 피어링에는 치명적인 **단점**이 있습니다. 바로 **전이적 라우팅(Transitive Routing) 불가**입니다. 이주니어 씨가 고개를 갸웃거립니다. "전이적 라우팅이 뭐예요?" 김개발 씨가 설명합니다. "VPC A와 B가 피어링되어 있고, B와 C도 피어링되어 있다고 해봐요. 그러면 A에서 C로 B를 거쳐서 갈 수 있을까요? 안 돼요. A에서 C로 가려면 별도로 A-C 피어링을 만들어야 해요." 이것이 풀 메시 문제의 원인입니다. N개의 VPC를 모두 연결하려면 N(N-1)/2개의 피어링이 필요합니다. 10개 VPC면 45개, 20개면 190개입니다. "이제 **Transit Gateway**를 보죠." 김개발 씨가 오른쪽 그림을 가리킵니다. Transit Gateway는 **전이적 라우팅을 지원**합니다. 모든 VPC가 중앙 허브에 연결되어 있으므로, 어느 VPC에서든 다른 모든 VPC로 갈 수 있습니다. 새 VPC를 추가해도 기존 설정을 건드릴 필요가 없습니다. 또한 **라우팅 도메인**으로 세밀한 트래픽 제어가 가능합니다. 특정 VPC 그룹 간의 통신을 차단하거나, 보안 VPC를 경유하도록 설정할 수 있습니다. VPC 피어링으로는 이런 복잡한 라우팅이 불가능합니다. 하지만 Transit Gateway는 **비용**이 발생합니다. 서울 리전 기준으로 Attachment당 시간당 약 $0.05, 월 약 $36입니다. 여기에 데이터 처리 비용 GB당 $0.02가 추가됩니다. VPC가 10개면 Attachment 비용만 월 $360입니다. 언제 무엇을 사용해야 할까요? **VPC 피어링을 선택하세요:** - VPC가 2-3개뿐이고 늘어날 계획이 없을 때 - 비용을 최소화해야 할 때 - 최저 레이턴시가 필요할 때 **Transit Gateway를 선택하세요:** - VPC가 4개 이상이거나 계속 늘어날 예정일 때 - 중앙 집중식 네트워크 관리가 필요할 때 - 온프레미스 연결(VPN, Direct Connect)이 필요할 때 - 복잡한 라우팅 정책이 필요할 때 이주니어 씨가 고개를 끄덕입니다. "우리 회사는 VPC가 계속 늘어나고 있으니까 Transit Gateway가 맞겠네요." 김개발 씨가 웃으며 답합니다. "맞아요. 초기 비용이 들어도 장기적으로는 Transit Gateway가 훨씬 효율적이에요." **실전 팁** 💡 - VPC 2-3개까지는 피어링, 4개 이상이면 Transit Gateway를 검토하세요 - 하이브리드 접근도 가능합니다. 레이턴시가 중요한 연결은 피어링으로, 나머지는 Transit Gateway로 구성할 수 있습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,Transit Gateway,Network

언어: TypeScript

태그: AWS, TransitGateway, VPC, Networking, CloudArchitecture, AWS,Transit Gateway,Network

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

Transit Gateway로 복잡한 네트워크 중앙 집중화 완벽 가이드

목차

1. Transit Gateway의 필요성

2. Hub and Spoke 아키텍처 이해

3. Transit Gateway 생성 및 VPC 연결

4. 라우팅 테이블 및 Association

5. Transit Gateway 라우팅 도메인

6. VPC 피어링 vs Transit Gateway 비교

댓글 (0)

함께 보면 좋은 카드 뉴스

대규모 트래픽을 위한 확장 가능한 아키텍처 완벽 가이드

AWS Organizations로 멀티 계정 거버넌스 구축

멀티 리전 아키텍처로 글로벌 서비스 설계

Transit Gateway 피어링으로 글로벌 네트워크 구축

VPC 피어링으로 VPC 간 프라이빗 통신 완벽 가이드