AWS Trainsit Gateway이란?

AWS의 네트웍은 Transit Gateway의 등장 이전과 이후에 다른 아키텍처 패턴을 가질 수 있게 되었다. 

 

Amazon VPC 요약

AWS 고객 간 격리 되어있는 네트웍

VPC CIDR + Expand(최대 추가 4개) + IPv6의 IP대역을 할당할 수 있다.

On-Premise의 Public/Private/DMZ 네트웍과 유사하다.

---

라우팅

서브넷 당 1개 이상의 라우팅이 들어간다. 퍼블릭과 프라이빗 서브넷의 용도에 따라 라우팅이 달라지게 된다.

퍼블릭 서브넷

• Local
• Internet Gateway
  - S3/DynamoDB/Lambda/AmazonSNS/AmazonIot 역시 접속을 위해 인터넷 접속이 필요하다.
• VPC Endpoint(S3/DynamoDB)
  - VPC 내부에 위치하지 않은 자원에 엑세스 하기 위해 엔드포인트가 필요하다. (인터넷 오픈하지 않고 접속 가능하도록 구성)
• Virtual Gateway(On-Premise)
  - On-Premise에 존재하는 리소스와 AWS VPC를 연결
  - VPN/Direct Connect 필요 (Direct Connect Gateway 추가됨)
• VPC Peering/Inter Region VPC Peering
  - VPC간의 상호 연결

프라이빗 서브넷

• Local
• NAT Gateway: 외부로 나가는 트래픽은 NAT로 라우팅 된다. 인스턴스 관리하는 부담을 없애기 위해 관리형 서비스 제공
• VPC Endpoint
• Virtual Gateway
• VPC Peering

Private Link

• VPC Peering은 기본적으로 네트웍 단위의 연결
• LB-PrivateLink 구성을 하게 되면 서비스 단위의 연결이 가능하다.
  - 네트웍이 열리는 것이 아니라, 443/80등의 좀더 안전한 연결이 가능하다.
• Native AWS Service 제공
  - IGW/NGW 없이/라우팅 테이블 등록 없이 VPC 내부와 AWS 관리형 자원간의 연동 가능

Global Accelerator

• 모든 엣지/로케이션에서 유일한 하나의 IP로 Anycast를 제공하는 서비스(Globally Anycast)
• 여러개의 ISP를 거쳐서 AWS 까지 들어오는 미들마이를 AWS 백본을 통해 쾌적하게 사용

Bring Your Own IP

• On-Premise에서 사용하던 IP를 그대로 사용

Private Link 서비스 확장

• Interface/Gateway 타입 추가

 

VPC Sharing(Multi-Account VPC)

VPC Sharing 이전의 VPC 자체의 자원은 오직 해당 VPC 자체의 자원이었다. Resource Manager를 통해 자원을 다른 VPC와 공유할 수 있게 되었다.

VPC Peering

• VPC 자체가 하나의 데이터센터 이고, 지금까지는 VPC를 연결하기 위해 VPC Peering을 사용했음
• Peering이 증가하게 되면 점점 라우팅이 복잡하게 됨 → FullMesh를 구현하기 위해 많은 피어링 추가 필요(nC2)
• VPC Route Table의 Static Route 수: 100
• VPC 최대 Peering 갯수: 125

VPC Sharing

• VPC 소유자와 사용자가 존재: 여러개의 계정이 한 VPC 내부의 리소스를 프로비저닝
• 소유자(Owner)
  - VPC 생성
  - 큰 정책 결정(서브넷/IGW//RT/NACL 등)
  - Resource Access Manager(RAM)을 통해 공유할 서브넷 지정
  - 소유자는 사용자의 자원 삭제 불가능
• 사용자(Participants)
  - 공유한 VPC의 서브넷에 자원을 생성하고 관리
  - 소유자가 생성/정의한 자원을 크게 변경할 수 없다.
• 목적
  - IP 공간의 효율적인 사용- VPC마다 CIDR 생성할 필요 없음
  - 손쉬운 상호 연결 - Peering이 필요 없음/자원 중복 최소화
  - 역할/책임 분리
  - 빌링/보안

Resource Access Manager

• VPC Sharing 뿐 아니라 TransitGateway/Route53 Resolver Rule/License Configuration에 대해 자원 관리 가능
• 어떤 Account에 대해 허용할 것인지 결정

 

Transit Gateway

Transit VPC/Global Transit VPC

Transit Gateway는 VPC Peering의 한계를 넘어 연결된 모든 VPC/On-premise간의 연결을 가능하게 한다.

기존의 VPC Peering을 통한 연결 형태는 다중VPC간의 연결이 필요한 상황에서 Full Mesh를 유지하기 위해 VPC의 수가 증가함에 따라 필요한 피어링이 계속해서 증가하여 복잡도가 늘어나는 구조였지만, Transit Gateway의 등장을 통해 모든 피어링이 TGW 하나로 가능하게 되었다.

Trainsit Gateway 개요

수 많은 VPC와 On-Premise 네트워크를 쉽고 자유롭게 연결할 수 있도록 하는 AWS Hyperplane 기반의 Regional Virtual Router

Hyperplane: AWS가 완전 관리하고 완전 제공하는 Layer3 기반의 라우팅 서비스 → TGW/ELB/NGW/EFS가 해당되며, SLA와 가용성에 대해 신뢰할 수 있는 서비스이다.

Region: 리전 단위로 라우팅이 이뤄지며, Region-to-Region 라우팅이 2019년 12월부로 가능하게 되었다.

핵심 기능

• 수 많은 VPC를 자유롭게 연결
• 지점/지사/On-Premise를 단순하게 통합
• 라우팅 도메인을 활용하여 다양한 구성(Consolidation/Isolation)

기존의 연결 형태

• VPC Peering을 Full Mesh 형태로 맺음
• 모든 VPC 마다 VPN Tunnel을 생성해야함

Transit Gateway

VPC간의 Peering 연결이 더 이상 불필요하며, VPN마다 터널을 생성 할 필요가 없어졌다.

모든 라우팅을 Consolidation(통합) 또는 Isolation(격리) 할 수 있다.

Transit Gateway 구성 요소

• Attachment
  - VPC/VPN/TGW간 모든 연결을 의미
  - Direct Connect
• Association
  - Transit Gateway의 Route Table 연결
  - 하나의 TGW Route Table에 단일/다중 Attachment 가능
• Propagation
  - Route Table을 전파
  - BGP/Static Routing
  - CIDR은 API를 통해 동적으로 Propagation (VPC는 BGP가 아닌 별도의 API 활용)

TGW 생성

• Amazon side ASN: Direct Connect Gateway, VPN,과 BGP 연동 시 필요한 Amazon Side의 Private ASN
• VPN ECMP support: 단일 대상에 대한 다수의 VPN 연결이 있는 경우 ECMP를 사용할지에 대한 구성 → 동일한 destination에 대해서 VPN을 여러개 가지고 있을 때/ 현재 VPN은 1.25GB의 BW를 가짐으로 여러개를 묶어 더 큰 BW를 갖기 위해
• Default route table association: TGW에 Attach되는 VPC또는 VPN을 Default Route Table에 포함시킬 것 인지에 대한 선택
• Default Route Table Propagation: Association된 대상(VPC/VPN/DX)을 자동으로 Default Route Table에 적용, 설정 없이 진행하면 모두가 통신이 됨
• Auto accept shared attachments: 다른 계정과 공유하는 경우(RAM), 자동 요청 수락 여부

TGW Attachment

• 높은 고가용성을 위해서 모든 가용영역 활용을 권고: 각각의 가용영역마다 TGW와 통신하는 eni가 프로비저닝 됨
• 하나의 가용영역에 문제가 생기더라도, 나머지 가용영역으로 포워딩됨

TGW Route Table

• Association: Association을 생성하면 VPC 내부 네트웍에 변경이 생기더라도 TGW 라우팅테이블에 자동적으로 반영된다
• Propagation: Association으로 연결한 네트웍이 자동적으로 propagation됨
• Route: 앞서 설정한 모든 vpc가 propagate 됨
• static routing: association 없이 수동으로 static하게 고정, association의 원본 변화(네트웍 추가)가 자동적으로 반영되므로, 허가 없이 라우팅테이블에 반영되는것을 막을 수 있음
• blackhole routing: 특정 대역을 통신 불가능하게 설정하기 위해, VPC 수준에서는 NACL/SG를 통해 가능하지만 모두 override 해서 통신을 차단하고 싶을 때, 이 대역 이면 drop 시키게됨

TGW 라우팅 통합(Consolidation)

TGW의 라우팅 테이블과 VPC의 라우팅 테이블은 별개의 테이블로 관리 되며, VPC는 라우팅 테이블에 제한이 있다. TGW는 더 많은 테이블과 연결되어 있다.

• local: VPC 내부의 트래픽에 대한 라우팅
• IGW/NAT/TGW: 외부로 나가는 트래픽은 VPC에 직접 연결된 IGW 또는 NAT, TGW 등의 라우팅을 갖게 된다.
• TGW: 연결된 다른 VPC로의 라우팅은 모두 다 Transit Gateway로 통합 된다.

VPN 연결 구성

On-Premise 환경으로의 네트웍 구성은 VPN으로 연결해야 하며, 2019년 10월부로 서울 리전에서 Direct Connect를 통한 네트웍 구성이 가능해지게 되었다.

CGW(Customer Gateway Definition): VPN으로 연결 시 On-Premise의 Firewall/Router/VPN 장비의 IP Definition를 Customer Gateway의 형태로 AWS 내부에서 관리한다. 생성 시에 BGP/Static의 라우팅 방법을 결정한다.

TGW에 의해 Site-to-Site Connection이 자동으로 생성되며, Configuration을 다운로드 받아 On-Premise에 적용하면 IPSec Tunnel이 UP 상태가 되게 된다.

라우팅 격리(Isolation)

라우팅 테이블을 2개를 만든다(VPC용 Route Table/VPN이 사용할 Route Table)

RT1: VPC Attach

RT2: On-Premise Attach

목적

• East-West 통신 차단: VPC-A/VPC-B/VPC-C는 서로 통신 불가
• North-South 통신 허용: On-Premise는 ABC와 통신이 가능

NAT Gateway - Transit Gateway 통합

특정 VPC를 통해 밖으로 나가고 싶을 때 과거에는 SharedVPC를 활용했다. TGW를 NAT와 함께 활용하면 아웃바운드 트래픽을 효과적으로 제어할 수 있다. 인터넷 통신용 VPC를 다른 VPC와 Transit Gateway를 통해 연결하게 되면 각각의 VPC는 NAT/IGW가 존재하지 않으며, 하나의 VPC를 통해서만 아웃바운드가 나가게 된다.

VPC-A: local 라우팅과 0.0.0.0/0 → NAT의 라우팅만 존재

VPC-B/C: local 라우팅과 VPC-A로의 라우팅

Transit Gateway Limits

• Account당 최대 TGW/VPC당 최대 TGW 연결: 5
• 연결(Attachment)당 최대 BW: 50Gbps(per AZ)
• VPN연결 당 최대 BW: 1.26Gbps
• TGW당 Route: 10,000 리전과 리전을 TGW로 향후 연결하게 되더라도 부족하지 않을 것
• TGW 최대 연결(Per Region/Per Account): 1,000

Reference Architecture

• 하나의 VPC(Sharing+RAM)에 다중의 Account를 놓고 VPC를 가볍게/정책적으로 가져갈 수 있음
• 여전히 Shared Service를 사용 가능, 모든 것들이 Shared Service를 통해 먼저 필터링 되게 할 수 있음
• 라우팅 테이블로 인해 Inline 서비스가 가능해짐
• TGW의 런칭파트너: F5/시스코/팔로알토 등 호환되는 서비스들이 계속해서 추가되고 있음
• OnPremise를 연결 가능한 다양한 구성을 하나로 TGW와 연결 가능
• 외부로 나가는 트래픽 컨트롤 가능
• 엣지 서비스: 인바운드 서비스를 하나의 VPC로 분리하여 잘 정돈된 아키텍쳐 운영 가능