transit gateway는 Hyperplane 기반으로 생성되므로 , 3분 정도의 시간 소요됩니다.
해당 랩에서는 앞서 생성된 VPC들과 자동으로 연계하도록 구성되어 있습니다.
Cloudformation이 정상적으로 구성되면 A,B,C,IT OCTANK가 자동으로 연결 구성됩니다.
TGW cloudformation에는 Transit Gateway Attachment 와 Transit Gateway Route Table 등이 자동으로 생성됩니다.
Cloudformation을 통해 정상적으로 배포가 되었다면, 아래와 같이 VPC Transit Gateway 메뉴에서 Transit Gateway 와 Transit Gateway Attachments, Route Table이 생성됩니다.
[VPC] - [ Transit Gateway]
Transit Gateway Attachment는 아래와 같이 구성이 됩니다.
앞서 4개의 VPC를 생성했고, 4개의 VPC에 대해 Attachment를 생성한 결과입니다.
랩에서는 Red, Green, Blue Route Table을 구성했습니다.
각 Route Table은 앞서 살펴본 Transit Gateway Attachment를 여러개 설정할 수 있으며, 또한 라우팅 테이블을 전파할 것인지, Static Route, Blackhole Route를 처리할 것인지 등을 설정할 수 있습니다.
아래 그림은 Cloudformation을 통해 설정된 Red Route Table에 2개의 VPC를 Attachment를 통해 연결한 것입니다. AOCTANK,BOCTANK VPC가 연결되어 있습니다.
Transit Gateway에 연결되면, 그룹화된 Route Table에 다른 VPC Routing Table을 선택적으로 전파할 수 있습니다. Red Route Table에는 아래와 같이 ITOCTANK,AOCTANK,BOCTANK Table등 3개의 VPC 네트워크을 전파합니다.
TGW Route Table에서는 Static Route와 Blackhole Route를 처리할 수 있습니다.
Cloudformation을 통해 구성한 아래 Red Route Table에서는 0.0.0.0/0 (Default Route)에 대해서 모두 ITOCTANK VPC로 향하게 구성되어 있습니다.
Cloudformation Stack이 올바르게 구성되었다면, 각 VPC에는 System Manager 기반 Session Manager 접속을 위해 VPC Endpoint가 설치되며, EC2 Instance에는 IAM SSM Role이 부여되어 생성됩니다.
랩에서 생성된 EC2 Instance 의 Private IP를 접속하기 위해서는 Bastion Server를 통해서 접속해야 합니다.
하지만 관리상 불편하기 때문에, 랩에서는 Session Manager를 통해서 접속합니다.
아래와 같은 구성을 통해 콘솔에서 Private IP로 접속할 수 있습니다.
사전에 관리자 콘솔에서는 AWS CLI 가 설치되어 있어야 하며, 랩에서는 맥 OS 기반에서 AWS CLI SSM Plugin을 설치하여 사용하는 예를 제공합니다.
1.aws cli ssm plugin 설치
brew tap dkanejs/aws-session-manager-plugin
brew install aws-session-manager-plugin
2.VPC 에 설치된 EC2 Instance의 id를 아래와 같은 AWS CLI 명령을 통해 확인합니다.
[ec2-user@ip-10-0-14-100 ~]$ ./pingshell.sh
Tue Feb 25 05:25:06 UTC 2020
target www.aws.com is up
target ITSVR-A is up
target ITSVR-B is up
target ASVR-A is down
target ASVR-B is down
target BSVR-A is down
target BSVR-B is down
target CSVR-A is down
target CSVR-B is down
target DSVR-A is down
target DSVR-B is down
target FSVR-A is down
target FSVR-B is down
target ZSVR-A is down
target ZSVR-B is down
[ec2-user@ip-10-11-14-100 ~]$ ./pingshell.sh
Tue Feb 25 00:54:43 UTC 2020
node www.aws.com is down
node ITSVR-A is down
node ITSVR-B is down
node ASVR-A is up
node ASVR-B is up
node BSVR-A is down
node BSVR-B is down
node CSVR-A is down
node CSVR-B is down
node DSVR-A is down
node DSVR-B is down
node FSVR-A is down
node FSVR-B is down
node ZSVR-A is down
node ZSVR-B is down
[ec2-user@ip-10-11-22-100 ~]$ ./pingshell.sh
Tue Feb 25 03:56:11 UTC 2020
node www.aws.com is down
node ITSVR-A is down
node ITSVR-B is down
node ASVR-A is up
node ASVR-B is up
node BSVR-A is down
node BSVR-B is down
node CSVR-A is down
node CSVR-B is down
node DSVR-A is down
node DSVR-B is down
node FSVR-A is down
node FSVR-B is down
node ZSVR-A is down
node ZSVR-B is down
[ec2-user@ip-10-21-14-100 ~]$ ./pingshell.sh
Tue Feb 25 05:37:38 UTC 2020
target www.aws.com is down
target ITSVR-A is down
target ITSVR-B is down
target ASVR-A is down
target ASVR-B is down
target BSVR-A is down
target BSVR-B is down
target CSVR-A is up
target CSVR-B is up
target DSVR-A is down
target DSVR-B is down
target FSVR-A is down
target FSVR-B is down
target ZSVR-A is down
target ZSVR-B is down
각 VPC 의 Private Subnet에 할당된 EC2 인스턴스에서 PING을 체크해 보면, IT OCTANK VPC에서는 외부로 통신이 가능하지만 나머지 모든 VPC의 EC2 인스턴스는 외부로 통신되지 않습니다.
또한 모든 VPC 의 EC2 인스턴스는 TGW에 연결되어 있지만 마찬가지로 서로간에 통신되지 않습니다.
이것은 우리가 원치 않은 결과 입니다.
이 랩의 목적은 A,B,C OCTANK VPC는 IT OCTANK VPC에서 제공되는 AWS 완전관리형 NAT Gateway를 공유하기 위함입니다. 또한 목적에 따라 IT OCTANK VPC 및 일부 VPC 간에는 필요에 따라 통신이 가능해야 합니다.
각 VPC에서 네트워크가 되지 않는 이유를 "1.4 TGW기반의 트래픽 제어" 랩에서 확인해 보고, 트래픽을 제어해 보겠습니다.
해당 웹사이트는 크롬, 파이어폭스, 사파리 웹 브라우저에 최적화되어 있습니다. 인터넷 익스플로러에서는 원할하게 보이지 않을 수 있습니다.
