4.3 TGW 트래픽 제어

Update : 2020-03-04

앞서 랩을 통해서 우리는 Transit Gateway 내부에서 Route Table을 나누고, 그룹화 시킨 테이블을 통해서 트래픽을 제어하였습니다.

크게 Green Route Table (IT, D, F, I, Z, O OCTANK VPC), Rest Route Table (A,B OCTANK VPC), Blue Route Table (C OCTANK VPC)으로 구분되었습니다.

하지만 실제 환경에서는 이러한 제어보다 좀 더 상세한 요구를 할 경우가 발생합니다. 이번 "4.3 TGW 트래픽 제어" 에서는 몇가지 케이스를 통해 제어하는 방법을 살펴 봅니다.

Blackhole 기반 제어와 라우팅

먼저 Blackhole 기반 트래픽 제어 방법입니다. 이 방법은 이미 "1.4 Traffic 기반 VPC 트래픽 제어" 에서 살펴 보았습니다. Account A의 US-EAST-1 리전의 Transit Gateway에서 관리의 편의성을 위해 3개의 Transit Gateway Route Table에서 0.0.0.0/0 에 대한 목적지를 IT OCTANK VPC Attach로 설정하였습니다.

이 경우에는 IT OCTANK Attach를 통해 Red/Blue 간에 통신이 되기 때문에, Red/Blue 간에는 Blackhole Routing으로 서로간에 통신을 제어 했습니다.

1.아래 Blackhole로 설정되어 있는 Red/Blue Route Table을 확인해 봅니다.

[A Account] - [US-EAST-1] -[VPC] -[Transit Gateway] - [Transit Gateway Route Table] - [Routes]

[그림 4.3.1. A Account US-EAST-1 Transit Gateway에서의 Blue Route Table 확인]

[그림 4.3.2. A Account US-EAST-1 Transit Gateway에서의 Red Route Table 확인]

고객의 요청으로 A OCTANK의 특정 서버가 Blackhole로 처리된 C OCTANK 특정 EC2 인스턴스로 통신해야 한다면 어떻게 해야 할까요?

가장 쉬운 방법은 Blackhole을 삭제하는 방법이지만, 이런 경우 전체 트래픽이 허용됩니다. 기업 환경에서 매우 빈번한 요청작업이며, 이런 경우에 간단하게 해결 할 수 있는 방법은 요청한 서버에 대해서만 라우팅을 추가하면 해당 라우팅은 통신이 됩니다.

2. 먼저 작업 전에 A OCTANK EC2 인스턴스에서 C OCTANK EC2 인스턴스로 연결이 되는지 확인합니다.

[ec2-user@ip-10-11-14-100 TGW_CF]$ ping CSVR-A
PING CSVR-A (10.21.14.100) 56(84) bytes of data.
^C
--- CSVR-A ping statistics ---
20 packets transmitted, 0 received, 100% packet loss, time 19457ms
## A OCTANK - EC2 인스턴스는 C OCTANK - EC2 인스턴스와 통신이 불가능합니다.

3. 고객이 A OCTANK EC2 (Host name : ASVR-A 10.11.14.100)과 C OCTANK EC2 (Host name : CSVR-A 10.21.14.100)으로 연결을 요청하였고, 이를 허용합니다.

Blue Routing Table과 Red Routing Table에서 32bit Routing (Host Routing)을 허용해 줍니다.

[A Account] - [US-EAST-1] -[VPC] -[Transit Gateway] - [Transit Gateway Route Table] - [Blue Route Table] - [Create Route]

[그림 4.3.3 Transit Gateway - Blue Route Table 에 Host Routing Table 등록]

[A Account] - [US-EAST-1] -[VPC] -[Transit Gateway] - [Transit Gateway Route Table] - [Blue Route Table] - [Route]

[그림 4.3.4 Transit Gateway - Blue Route Table 에 Host Routing Table 확인]

[A Account] - [US-EAST-1] -[VPC] -[Transit Gateway] - [Transit Gateway Route Table] - [Red Route Table] - [Create Route]

[그림 4.3.5 Transit Gateway - Red Route Table 에 Host Routing Table 등록]

[A Account] - [US-EAST-1] -[VPC] -[Transit Gateway] - [Transit Gateway Route Table] - [Red Route Table] - [Route]

[그림 4.3.6 Transit Gateway - Blue Route Table 에 Host Routing Table 확인]

4. 이제 다시 A OCTANK EC2 인스턴스에서 C OCTANK EC2 인스턴스로의 네트워크 통신을 확인합니다.

아래에서 처럼 A SVR-A (10.11.14.100)은 C SVR-A(10.21.14.100)으로만 통신이 가능하며, C SVR-B(10.21.22.100)으로는 통신이 불가능합니다.

[ec2-user@ip-10-11-14-100 TGW_CF]$ ping CSVR-A
PING CSVR-A (10.21.14.100) 56(84) bytes of data.
64 bytes from CSVR-A (10.21.14.100): icmp_seq=1 ttl=254 time=1.00 ms
64 bytes from CSVR-A (10.21.14.100): icmp_seq=2 ttl=254 time=0.438 ms
64 bytes from CSVR-A (10.21.14.100): icmp_seq=3 ttl=254 time=0.479 ms
64 bytes from CSVR-A (10.21.14.100): icmp_seq=4 ttl=254 time=0.444 ms
^C
--- CSVR-A ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3026ms
rtt min/avg/max/mdev = 0.438/0.591/1.006/0.241 ms
[ec2-user@ip-10-11-14-100 TGW_CF]$ ping CSVR-B
PING CSVR-B (10.21.22.100) 56(84) bytes of data.
^C
--- CSVR-B ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8171ms

실제 기업에서는 VPC 내부의 특정 EC2 인스턴스로만으로 통신을 원하고 모두 제어하기를 원할 수도 있습니다. 이런 경우에 매우 유용합니다. (EC2 내부에 파일서버, 공유서버, Repository, DB 등)

Longest prefix matching 제어

앞서 소개한 방식과 유사하게 Longest Prefix matching 제어를 확대해서 적용할 수 있습니다. 기업에서 Account C는 인수합병된 회사이며, IT OCTANK의 공유 서비스를 사용할 필요가 없습니다. 그들은 US-EAST-1과 협업이 필요합니다.

위의 조건에서도 Longest Prefix matching을 사용하게 되면 편리하게 구성이 가능합니다.

[4.3.7 LAB 논리적 구성도]

먼저 적용 이전에 Account C에서 EC2 인스턴스 네트워크 연결 상황을 확인해 봅니다.

[ec2-user@ip-10-100-14-100 TGW_CF]$ ./pingshell.sh
Wed Mar  4 07:06:24 UTC 2020
SERVER www.aws.com is up
SERVER ITSVR-A is up
SERVER ITSVR-B is up
SERVER ASVR-A is down
SERVER ASVR-B is down
SERVER BSVR-A is down
SERVER BSVR-B is down
SERVER CSVR-A is down
SERVER CSVR-B is down
SERVER DSVR-A is up
SERVER DSVR-B is up
SERVER FSVR-A is up
SERVER FSVR-B is up
SERVER ISVR-A is up
SERVER ISVR-B is up
SERVER OSVR-A is up
SERVER OSVR-B is up
SERVER ZSVR-A is up
SERVER ZSVR-B is up

인수합병한 Account C의 O OCTANK는 TransitGateway Peering으로 Account A와 연결되어 Green Routing Table에 참여하는 IT , F, I OCTANK, D OCTANK(On Prem), Z OCTANK 모두와 네트워크 통신이 가능합니다.

하지만 O OCTANK 회사는 OCTANK 계열사 중에서 Z OCTANK와 통신만 되면 됩니다. 나머지 기업과는 비지니스 연관성이 없습니다. 이 경우에 효과적으로 사용할 수 있는 것이 LPM (Longest Prefix Matching) 기법입니다.

Account C의 US-WEST-2 TGW에서 OCTANK 전체 CIDR를 등록하는 것이 아니라 LPM으로 필요한 라우팅만 등록하는 것입니다.

1.Account C의 Transit Gateway Routing에서 Account B의 US-EAST-1 Z OCTANK CIDR에 대해 Static Routing을 등록합니다.

[Account C] - [US-WEST-2] - [VPC] - [Transit Gateway] - [Transit Gateway Route Tables] -[Create Route]

[그림 4.3.7 LAB 논리적 구성도]

2. Account C의 Transit Gateway Routing에서 등록된 Route Table을 확인합니다.

[Account C] - [US-WEST-2] - [VPC] - [Transit Gateway] - [Transit Gateway Route Tables] -[Route]

3. Account C에서 Transit Gateway Routing의 10.0.0.0/8 Supernetting을 삭제하고, Routing Table을 확인합니다.

[Account C] - [US-WEST-2] - [VPC] - [Transit Gateway] - [Transit Gateway Route Tables] -[Route]

4. Account C에서 US-WEST-2 EC2에서 네트워크 통신을 확인합니다.

[ec2-user@ip-10-100-14-100 TGW_CF]$ ./pingshell.sh
Wed Mar  4 07:31:33 UTC 2020
SERVER www.aws.com is up
SERVER ITSVR-A is down
SERVER ITSVR-B is down
SERVER ASVR-A is down
SERVER ASVR-B is down
SERVER BSVR-A is down
SERVER BSVR-B is down
SERVER CSVR-A is down
SERVER CSVR-B is down
SERVER DSVR-A is down
SERVER DSVR-B is down
SERVER FSVR-A is down
SERVER FSVR-B is down
SERVER ISVR-A is down
SERVER ISVR-B is down
SERVER OSVR-A is up
SERVER OSVR-B is up
SERVER ZSVR-A is up
SERVER ZSVR-B is down

Transit Gateway를 통해서 네트워크를 제어하고, 빠른 속도를 보장하며, 편리한 관리성을 제공하는 방법을 모두 확인하였습니다. 다음 Chapter에서는 관리 방법을 소개합니다.