안녕하세요 :)
오늘은 TGW의 Route table을 분리해서 각 VPC A, B와 VPC C, D가 통신되도록 설정해 보겠습니다.
실습 전에 전에 포스팅한 게시물을 참고하시면 좋을 거 같습니다.
https://bigco-growth-diary.tistory.com/53
실습의 핵심은 TGW의 네트워크 흐름을 파악하는 것입니다. 그래서 TGW의 Route Table을 보고 Accosiation(연결), propagatoion(전파), Routes(경로)를 활용해서 VPC끼리 통신을 할 수 있게 설정을 해보겠습니다.
VPC4대를 모두 TGW에 연결시켜주지만 VPC A, B와 VPC C, D가 서로만 통신이 가능하게 설정해 주겠습니다.
TGW에 Attach된 각 VPC마다 TGW Route table을 생성하겠습니다.
Route Table을 분리하는 이유
- 세분화된 라우팅 제어 : 각 VPC의 트래픽 흐름을 더 세밀하게 제어할 수 있습니다.
- 보안 강화 : 각 라우팅 테이블을 독립적으로 관리하면, 특정 VPC가 다른 VPC에 접근할 수 없도록 보안 설정을 할 수 있습니다.
- 쉬운 관리 : 문제가 발생했을 때, 각 VPC에 대한 라우팅 테이블을 개별적으로 분석하면 문제를 더 쉽게 파악하고 해결할 수 있습니다.
- 정책 기반 라우팅 : 특정 VPC끼리만 통신을 허용하거나, 특정 VPC를 다른 VPC에 접근할 때 다른 경로를 통해 접근하도록 설정할 수 있습니다.
정답은 아니지만 각 VPC에 대한 개별 TGW 라우팅 테이블 설정은 유연한 네트워크 아키텍처를 구축하는데 도움을 줄 수 있습니다.
Transit Gateway 생성
Transit Gateway를 생성하겠습니다.
TGW 라우팅테이블을 각 VPC마다 개별 구성할 것이기 때문에 TGW구성에 [기본 라우팅 테이블 연결], [기본 라우팅 테이블 전파] 설정은 비활성화를 했습니다.
Transit Gateway Attachment 생성
VPC A,B,C,D 이렇게 4대의 VPC를 TGW에 Attach 시켜줬습니다.
Transit Gateway 라우팅 테이블 생성
저번 포스팅에서는 TGW는 생성할 때 [기본 라우팅 테이블 연결], [기본 라우팅 테이블 전파] 두 옵션을 활성화해서 Attachment를 생성하면 자동으로 라우팅테이블이 생겨났는데 이번에는 VPC마다 개별로 테이블을 생성하기 위해 해당 옵셥들을 비활성화했습니다. 그래서 직접 TGW Route Table을 생성해 줍니다.
같은 방법으로 각 VPC마다 TGW 라우팅 테이블을 생성해 줬습니다.
라우팅테이블 설정 / Association(연결), Propagation, Routes
Association(연결), Propagation(전파), Routes(경로)를 활용하여 VPC A와 VPC B 통신, VPC C와 VPC D가 통신하도록 설정해 보겠습니다.
1. Association 연결 설정부터 해주겠습니다.
Association(연결) 설정은 TGW의 라우팅테이블과 Attachment의 VPC를 연결하는 설정 입니다.
모든 VPC에 해당 설정을 해줘서 각 TGW 라우팅테이블에 VPC를 연결시켜줍니다.
생성된 TGW 라우팅테이블에 VPC를 연결을 시켜줬습니다.
라우팅테이블 설정 / Association, Propagation(전파), Routes
2. Association 연결을 완료했으면 Propagation(전파) 설정을 해주겠습니다.
Propagation(전파) 설정은 Transit Gateway에 연결된 VPC나 다른 네트워크의 리소스 정보를 Transit Gateway의 라우팅 테이블에 자동으로 전파합니다. 연결되어 있는 각 라우팅테이블에 변화(추가, 수정)가 생길 시, 서로 테이블을 공유하며 전파를 하여 Transit Gateway 라우팅 테이블에 자동으로 업데이트해 주는 기능입니다.
VPC A 라우팅테이블의 전파목록에는 A, B (Attachment)를, VPC B 라우팅테이블의 전파목록에도 A, B를 추가해 줍니다.
즉, 서로 통신을 하고자 하는 VPC들은 각각 자신과 상대 VPC의 Attachment 정보를 Transit Gateway의 라우팅 테이블에 추가해야 합니다.
TGW-RT VPC A에 A, B Attachment를 추가해 줬습니다. 같은 방식으로 다른 테이블에도 추가를 해줍니다.
각 라우팅테이블에 전파시킬 Attachment들을 추가해 줬습니다.
라우팅테이블 설정 / Association, Propagation, Routes(경로)
3. 전파 설정까지 완료 하면 경로(Routes)가 자동으로 생성됩니다.
해당 경로는 propagation에서 전파시켜 준 리소스 정보입니다. Transit Gateway에 연결된 VPC들은 자신들의 네트워크 정보를 전파합니다.이 정보가 Transit Gateway 라우팅테이블에 공유되어 VPC들끼리 통신할 수 있는 경로가 생기게 됩니다.
전파유형으로는 propagated(전파됨), Static(정적경로) 두 가지가 있습니다.
VPC Route Table 설정
VPC도 당연히 라우팅테이블에 TGW를 추가시켜줘야 합니다.
VPC의 라우팅 테이블에도 각각 통신하고자 하는 VPC의 대역을 대상으로 하여 TGW를 추가시켜줍니다.
Ping Test
VPC A에서 Ping test
VPC D에서 Ping test
이렇게 간단하게 핑 테스트를 완료했습니다.
Routes(경로) - Static 정적 경로
TGW 라우팅테이블의 Routes의 경로 유형에 대해서 조금 더 알아보겠습니다.
[경로 유형]
# Propagated(전파됨)
Propagated 유형에서는 Propagation에서 TGW와 연결된 VPC들이 통신을 위해 서로의 네트워크 정보를 전파, ,공유하고 전파된 정보를 바탕으로 경로가 생성됩니다. 즉, Propagated(전파됨)에서 전파설정을 하면 자동으로 경로가 생성됩니다.
# Static(정적 경로)
정적경로는 수동으로 경로를 추가해 주는 것입니다. 예를 들어 VPC A와 B가 TGW에 연결되어 통신하는 중이라고 할 때, VPC A는 전파를 통해 자신의 네트워크 정보를 공유하지만, VPC B는 Private 하게 운영하고 싶을 수 있습니다. 또한 자신의 VPC에 CIDR가 추가되거나 수정사항이 생겼을 때 이를 알리고 싶지 않은 상황을 가정하면, 정적 경로를 사용하면 됩니다. 정적경로를 설정하면 변경되는 자신의 네트워크 정보를 전파하지 않으므로 네트워크를 공유하지 않게 됩니다.
즉, 정적(Static)으로 경로 설정을 하면 Propagate와 반대로 변경되는 VPC 네트워크 및 리소스 정보가 자동으로 공유되지 않습니다.
#경로를 정적으로 잡는 이유
보안 강화
모든 VPC 간의 통신을 허용하지 않기 위해 수동으로 경로를 설정할 수 있습니다. 예를 들어, 특정 VPC는 중요한 데이터를 저장하고 있기 때문에 선택적으로 다른 VPC와의 연결만을 허용하고 싶을 수 있습니다.
효율적인 트래픽 흐름
어떤 VPC는 다른 VPC와의 통신이 필요 없을 수 있습니다. 이럴 경우, 불필요한 라우팅 엔트리를 제거하여 트래픽 흐름을 최적화할 수 있습니다.
기존 아키텍처에 VPC-E 대역을 추가했습니다. E는 전파설정을 해서 C, D의 대역의 네트워크를 공유하고, VPC C, D에서는 정적설정을 해서 VPC-E대역의 추가되는 네트워크 정를 공유받지 못하도록 설정하겠습니다.
- 1. Transit gateway에 VPC E를 연결
- 2. VPC A, E에 CIDR추가
- 3. A의 추가된 CIDR가 전파를 통해 B 라우팅테이블 경로에 자동으로 추가됐는지 확인.
- 4. C, D 라우팅테이블에는 E대역을 정적으로 연결해서 추가된 CIDR가 경로에 전파되는 확인.
TGW에 E를 연결한 후, 라우팅테이블 생성 및 경로설정
VPC-E를 추가했습니다. CIDR는 10.0.50.0/24 입니다.
TGW Attachment 연결, 라우팅테이블을 생성합니다.
VPC E - TGW의 라우팅테이블에서 전파생성, 경로확인을 해줍니다.
VPC C, D - 정적경로를 추가해 줘서 E대역의 네트워크 정를 공유하지 못하도록 설정해 줍니다.
VPC D도 같은 방법으로 설정해 줍니다.
Ping Test
VPC에 CIDR 추가로 전파기능 알아보기
VPC에 CIDR를 추가해서 Propagation을 통해 VPC의 네트워크 정보가 공유되는지 확인해 보고, 정적으로 경로를 잡은 VPC E의 네트워크 공유를 하지 않는 것 확인을 해보겠습니다.
VPC A에 CIDR 100.0.10.0/24를 추가, VPC E에 CIDR 100.0.50.0/24를 추가했습니다.
TGW 라우팅테이블 확인
VPC A와 TGW 전파연결을 해놓은 VPC B는 자동으로 경로가 생긴 것을 확인할 수 있습니다.
하지만 반대로 VPC C, D 라우팅테이블에는 추가된 CIDR를 확인할 수 없습니다.
왜냐하면 VPC E를 정적 경로로 추가해서 VPC E의 추가된 네트워크 정보가 공유되지 않기 때문입니다.
이렇게 TGW의 여러 기능에 대해서 알아봤습니다.
감사합니다.
'AWS > Transit Gateway (TGW)' 카테고리의 다른 글
[ Transit Gateway #1 ] Transit Gateway란? (0) | 2023.09.12 |
---|---|
[ Transit Gateway ] TGW를 사용하여 다른 대역의 VPC와 통신 해보기 (0) | 2023.07.07 |