CloudFormation : Transit Gateway
- VGW 대신 TGW 사용하기
- 다른 리전 간 연결
1교시
어제 했던 실습 이어서. 다시 설명
AWS-VPC에 TGW 연결 용도의 서브넷을 하나 만든다. 가용 영역은 기존 퍼블릭 서브넷과 같게.
TransitGatewayAttachment로 이 서브넷과 TGW 연결
-> 여기에서 두 서브넷의 가용 영역이 같으니 Attachment 시 퍼블릭 서브넷만 작성
IDC-CGW에서 vpnconfig.sh를 작동, 터널이 작동하는 것을 봤지만 통신은 안됐었다.
-> 기존 VGW에서는 어떻게 했었지? : VGW 생성, VPC에 VGW 연결, AWS-VPC에 CGW가 무엇인지 인지시켰고 다 비슷하다.
-> VGW 연결 부분에 IDC-VPC의 라우팅 정보를 AWS-VPC의 퍼블릭 라우팅 테이블에 정적 라우팅으로 전파했었다.
-> 전파 작업에서 VGW 넣는 부분만 있고 TGW 넣는 부분이 없었다. VPNGatewayRoutePropagation을 쓸 수 없다는 것.
TGW의 연결은 2가지
1. VPC와의 연결
2. VPN과의 연결
AWS-VPC의 CIDR에 해당하면 VPC와의 연결로 보내야 한다
IDC-VPC의 CIDR에 해당하면 VPN과의 연결로 보내야 한다.
이 내용이 라우팅 테이블에 들어가야 한다.
무슨 말인지는 이해했다.
실행해봤는데 안되는 것을 보니 그전에 다른 곳에서 문제가 있나 보다.
2~4교시
다른 리전을 전송 게이트웨이로 연결하기 실습
서울/싱가포르 리전, 각각 퍼블릭 서브넷 1개와 IGW 1개씩
yml 파일 2개로 서울, 싱가포르 리전의 인프라 구축(리전만 바꾸면 된다)
그리고 각 TGW를 하나씩 만들어 VPC에 Attachment
실습 전 기본 환경 구축 결과 확인
1. 서울 리전에 VPC가 한 개, 서브넷이 2개(인스턴스가 들어갈 서브넷, TGW 연동할 서브넷) 있어야 한다.
2. 서브넷이 2개니까 라우팅 테이블도 2개(1개여도 상관은 없지만) : 인스턴스가 들어갈 서브넷의 엔트리는 3개(기본, IGW, 싱가포르 TGW로 갈 경로), TGW 연동 서브넷 라우팅 테이블의 엔트리는 기본값만
3. TGW 하나, 서울 VPC와 TGW의 연결 1개
* 리전마다 AMI ID가 다르다. 해당 리전의 인스턴스에서 사용하는 ami-id를 찾아야 한다.
아무래도 Transit Gateway와 VPC의 연결이 이해하기 어려운 감이 있다.
5~6교시
구축에 성공하긴 했는데, 확신이 들지 않는다.
기본 구조와 어떤 차이가 있는지 기억하자.
-> 퍼블릭 라우팅 테이블의 기본 경로/IGW로의 경로 외에 이 리전의 TGW로의 경로가 있어야 한다. 대상은?
-> 싱가포르 리전 VPC의 CIDR
-> TGW 연결용 서브넷 생성 : 가용 영역은 퍼블릭 서브넷과 같게
-> TGW 생성
-> TGW와 서브넷 연동(Attachment) : 방금 만든 연결용 서브넷과 연결
-> 외부 인터넷을 통한 연결이 아닌 TGW 간 피어링으로 연결할 예정
다행히 작성했던 내용들이 맞았다.
결과적으로 각 리전 VPC의 퍼블릭 서브넷에 3개 엔트리가 있어야 한다.
이제 리전 연결을 해보자.
어떤 계정에서, 어느 리전의 TGW로, 내 소유의 TGW와 연동
PeerAccountId는 연결할 대상 리전의 소유 계정 고유 번호. 이번 실습에서는 두 리전 모두 내 계정이니 상관없다. 우측 상단의 계정명을 눌러보면 '내 계정' 옆에 있는 숫자다.
PeerRegion은 연결할 상대의 리전
PeerTransitGatewayId는 상대의 TGW Id인데, 당연히 참조 불가. 2가지 방법이 있다.
-> 첫 번째 방법 : 싱가포르 리전쪽 스택을 배포한 뒤에 콘솔에서 TGW ID를 긁어온다.
-> 두 번째 방법
이 부분을 작성하면 싱가폴 리전의 스택 파일이 실행된 후 '출력' 탭으로 가보면 SingaporeTransitGatewayID라는 이름으로 싱가포르 리전의 TGW를 참조한 반환 값이 나와 있다. 이 값을 긁어서 가져다 붙인다.
정적 라우팅 경로 생성
TransitGatewayRouteTableId는 자신 VPC에 있는 정보인데, 기본 생성된 값이라 참조가 불가능하다. 콘솔에서 긁어와야 한다.
-> 이 의미는 이 작업을 실행하기 전에 서울/싱가포르 양쪽에 TGW 배포는 이미 되어 있어야 한다는 것.
한 번에 싹 배포는 불가능하고, 최초 배포 후 업데이트로 진행해야 한다.
TransitGatewayAttachmentId는 아래에서 Peering 연결 수락 후 활성화될 Peering 연결의 ID를 작성해야 한다.
위 코드들을 모두 작성 후...
서울 리전 쪽에서 Peering 요청을 보냈으니, 싱가포르 리전의 Transit Gateway 연결로 가보면, Peering 연결이 수락 대기 중 상태다.
-> 우측 상단의 작업 > 연결 수락
연결 수락하는 작업은 코드로는 구현하는 것이 아닌 것 같다. 실습에서도 콘솔에서 수작업으로 했다.
요청 수락 후 대충 5분 안으로 연결이 완료된다.
이제 핑을 날려서 테스트해보자.
-> 안된다.
어디에서 막힌 것인지 확인해 보자.
1. 해당 리전 서브넷의 퍼블릭 라우팅 테이블에 경로가 있는가?
2. 해당 리전 TGW 라우팅 테이블에 경로가 있는가?
나는 TGW 라우팅 테이블에 경로 설정 문제였다. 수정하니 서울-싱가포르 간 핑 테스트 성공.
TGW 실습 때마다 연결용 서브넷을 따로 만들었는데, 나름의 이유가 있다.
-> TGW를 통과하는 경로를 따로 만드는 것이다.
-> 다른 트래픽과 섞이지 않고, 충돌도 없이 오가기 위해
부하 분산이라고 하기도 뭐하고, 더 편해서도 아니고, 트래픽 구분 목적도 아니다.
요약해서 뭐라 하긴 애매한데, 아무튼 TGW를 위한 길을 따로 만드는 것이라고 알고 있자.
7~8교시는 자습.
오늘은 좀 전체적으로 아득하다. 다 들어야 하나?
'교육' 카테고리의 다른 글
| [56일 차] 21.10.13 : 개인 프로젝트 (0) | 2021.10.13 |
|---|---|
| [55일 차] 21.10.12 : AWS 15 (0) | 2021.10.12 |
| [53일 차] 21.10.07 : AWS 13 (0) | 2021.10.07 |
| [52일 차] 21.10.06 : AWS 12 (0) | 2021.10.06 |
| [51일 차] 21.10.05 : AWS 11 (0) | 2021.10.05 |
댓글