Transit gateway
VPC Peering과 마찬가지로 서로 다른 VPC간에 통신이 가능하게 하는 서비스로 Peering은 1ㄷ1 VPC연결만 지원하지만 Transit gateway는 중앙 허브 즉 단일게이트웨이를 통해 여러 VPC를 중앙집중적으로 관리할 수 있습니다.
특징
- peering 처럼 vpn을 통해 온 프레미스와 연결할 수 있음
- 복잡한 피어링 관계를 정리해 네트워크 간소화
- 클라우드 라우터 역할로써 새로운 연결을 한번만 추가하면 됨
- 다른 리전간의 transit gateway와 피어링 연결이 가능
VPC PEERING VS Transit Gateway
| VPC PEERING | TRANSIT GATEWAY | |
| 리전과의 VPC 연결 | O | O |
| 다른 계정과의 VPC 연결 | O | O |
| 대역폭 | 제한 없음 | 50Gbps |
| 최대 구성 가능 개수 | 125 | 5000 |
| 구성 개수 | n(n-1)/2 | n |
| VPC 연결 비용 | 없음 | 시간당 0.07$(서울 리전 기준) |
| VPC 데이터 전송량 비용 | Gbp 0.02$ | Gbp 0.02$ |
같은 조건을 기준으로 Transit이 peering보다 약 1.5배 비싸다고 합니다.
실습으로 들어가기 전 알아야 할 것
실습 해보기 전에 간단하게 알아두면 좋을 것들을 공식 문서에서 가져와 봤습니다.
가용 영역
transit gateway는 가용 영역 선택(attachment에서 설정하는거 얘기가 맞는 것 같음)에서 트래픽을 vpc 서브넷의 리소스로 라우팅 해야합니다. transit gateway는 서브넷의 남는 IP 하나를 사용하여 해당 서브넷에 네트워크 인터페이스를 배치해야 합니다.
가용 영역의 퍼블릭 존, 프라이빗 존 얘기는 따로 없지만 위 얘기를 들어보면 ALB처럼 인터넷과 연결되는 퍼블릭 존에 두어야지 통신이 될 수 있을 것 같습니다.
라우팅 테이블
라우팅 테이블을 생성하여 연결하고 각 서브넷의 라우팅 테이블에도 게이트웨이를 추가하여야지 서로 통신할 수 있습니다.
여러개의 라우팅 테이블을 생성하여 서브넷을 격리할 수도 있습니다. (VRF처럼 사용할 수 있는듯)
경로 전파
가장 이해가 안되는 부분인데,,,transit gateway의 라우팅 테이블은 경로 전파와 연결(attachment로 생성하는)로 구성되어 있습니다.
각 연결에는 하나 이상의 Transit Gateway 라우팅 테이블에 설치할 수 있는 경로가 있습니다. 연결이 Transit Gateway 라우팅 테이블에 전파되면 이러한 경로가 라우팅 테이블에 설치됩니다.
VPC 연결의 경우 VPC의 CIDR 블록이 Transit Gateway 라우팅 테이블로 전파됩니다.
VPN 연결이나 Direct Connect 게이트웨이 연결과 함께 동적 라우팅이 사용되는 경우 BGP를 통해 온프레미스 라우터에서 학습한 경로를 Transit Gateway 라우팅 테이블로 전파할 수 있습니다.
VPN 연결과 함께 동적 라우팅을 사용하는 경우 VPN 연결과 연결된 라우팅 테이블의 경로가 BGP를 통해 고객 게이트웨이에 전달됩니다.
Connect 연결 파일의 경우 Connect 연결 파일과 연결된 라우팅 테이블의 경로가 BGP를 통해 VPC에서 실행되는 SD-WAN 어플라이언스와 같은 서드 파티 가상 어플라이언스에 전달됩니다.
Direct Connect 게이트웨이 연결의 경우 허용되는 접두사 상호 작용은 AWS에서 고객 네트워크로 전달되는 경로를 제어합니다.
정적 경로와 전파 경로의 대상이 동일한 경우 정적 경로의 우선순위가 높으므로 전파 경로는 라우팅 테이블에 포함되지 않습니다. 정적 경로를 제거하면 중복 전파 경로가 라우팅 테이블에 포함됩니다.
위 인용은 AWS 문서에서의 경로 전파에 대한 설명입니다.
피어링 연결에 대한 라우팅
두 개의 Transit Gateway를 피어링하고 두 게이트웨이 간에 트래픽을 라우팅할 수 있습니다. 이렇게 하려면 Transit Gateway에서 피어링 연결을 생성하고 함께 피어링 연결을 생성할 피어 Transit Gateway를 지정해야 합니다. 그런 다음 Transit Gateway 라우팅 테이블에서 정적 경로를 생성하여 트래픽을 Transit Gateway 피어링 연결로 라우팅합니다. 피어 Transit Gateway로 라우팅된 트래픽은 피어 Transit Gateway에 대한 VPC 및 VPN 연결로 라우팅될 수 있습니다.
실습
일반 동일 리전간 VPC 연결
TGW 생성
vpc → transit gateway 이동
| 용어 | 설명 |
| ASN | 자율 시스템 번호로 BGP를 통한 라우팅을 위해 지정해줘야 한다. 64512~65534번, 4200000000~4294967294를 사용할 수 있고 지정하지 않을 시 기본값 64512가 부여된다. |
| DNS 지원 : 인스턴스의 PUBLIC IP가 PRIVATE IP로 전환되게 함 | |
| VPN ECMP SUPPORT | VPN 터널 간에 ECMP 라우팅(동일 비용 다중 경로)을 지원한다. |
| ex) 동일한 CIDR을 가진 2개의 VPN 터널을 통해 트래픽을 전송하는 경우 1:1로 균등하게 분산하여 전송 | |
| Default route table association(기본 라우팅 테이블 연결) | 기본 transit gateway 라우팅 테이블이 생성된다. vpc를 transit gateway와 연결하면 자동으로 테이블에 추가된다. |
| Default route table propagation(기본 라우팅 테이블 전파) | 동적 라우팅을 이용할 경우 VPN 연결과 연결된 라우팅 테이블이 BGP를 통해 CGW(Customer Gateway)에 전달 |
| 용어 | 설명 |
| Auto accept shared attachments(공유 첨부 파일 자동 수락) | transit gateway를 다른 계정과 공유할 수 있는데 이때 이 설정을 활성화하면 공유 오청에 대한 수락 없이 자동으로 수락된다. |
| Transmit Gateway CIDR | 이 란에 지정된 CIDR만 해당 Transit gateway와 통신할 수 있어 매우 중요한 부분이다. |
TGW ATTACHMENT(연결하는 VPC당 하나씩 추가) : transit gateway attachment로 이동
이름, 연결할 transit gateway id 연결, vpc 선택 및 가용 영역 선택
DNS 지원 옵션 : DNS를 외부에 요청하고 받아오는게 아닌 내부에서 처리하도록 하여 완전히 외부와의 접촉 없이 내부로 통신하게 하는 기술
vpc에 연결할 시 가용영역 지정에서는 퍼블릭을 지정해야 합니다.
라우팅 테이블에 TGW 추가 : vpc → routing table로 이동
연결할 서브넷의 라우팅 테이블에 transit gateway 추가
결과 :
A-private에서 B-public의 private 주소로 핑 테스트가 성공하는 것을 볼 수 있습니다.
위 토폴로지처럼 A-private 에서 B-private와도 통신되는 것을 확인할 수 있습니다.
동일 계정 타리전간 VPC 연결
이번 실습은 이미 다른 리전에도 트랜짓 게이트웨이가 생성돼 있다고 가정하고 시작합니다. 필자는 한계정의 하나의 트랜짓 게이트웨이로 여러 리전을 묶을 수 있는 줄 알았으나 그렇지 않습니다. 한 리전에는 하나씩의 트랜짓 게이트웨이가 필요합니다.
TGW ATTACHMENT(PEERING 연결로 생성)
tgw attachment를 생성하는데 이번에는 연결 유형을 peering connection으로 연결합니다. 이름에서처럼 이런 모드는 타 리전과의 transitgateway를 연결해주는데 vpc peering과 비슷하게 동작한다고 합니다. 연결해야하는 리전을 선택하고 수락자 란에 연결해야하는 transit gateway의 id를 붙여넣습니다.
tansit gateway attachment로 이동 필자의 사진은 available로 뜨지만 요청 수락 대기 상태의 연결이 하나 생성되어 있을 것입니다.
transit gateway attachment id 클릭 → 작업 → transit gateway attachment 수락 작업을 통해 연결 수락을 해줍니다.
Transit gateway route table 정적 경로 추가
• Transit Gateway 피어링 - Transit Gateway 피어링은 동적 라우팅을 지원하지도 않고, 서로 다른 두 대상에 대하여 같은 정적 경로를 구성할 수도 없기 때문에 ECMP를 지원하지 않습니다.
피어링 연결 요청을 생성한 후에는 피어 Transit Gateway의 소유자(수락자 Transit Gateway 라고도 함)가 요청을 수락해야 합니다. Transit Gateway 간에 트래픽을 라우팅하려면 Transit Gateway 피어링 연결을 가리키는 Transit Gateway 라우팅 테이블에 정적 경로를 추가합니다.
위 공식 문서의 두 문장을 보면 peering 연결은 동적으로 경로가 생성되지 않는다는 것을 알 수 있습니다.
앞에서도 말했듯이 peering 연결은 기본 연결과 다르게 동적으로 경로 생성이 되지 않기 때문에 양 transit gateway route table에 정적 경로 생성을 해줘야 합니다.
transit gateway route table → routing table 선택 → 경로 선택 → 정적 경로 생성
상대방이 이용하고 있는 transit gateway의 CIDR을 입력하고 연결 선택에서는 앞서 생성한 트랜짓 피어링 연결을 선택합니다.
이 후 각 서브넷의 라우팅 테이블에 트랜짓 게이트웨이를 추가해주는 것은 똑같습니다
결과
서울 리전에서 버지니아 리전으로 성공적으로 통신이 되는 것을 볼 수 있습니다.
Flow log 생성 및 모니터링
flow-log를 생성하여 모니터링 할 수 있는데 vpc flow log와 생성 방법은 동일한 것 같다. 정말 정말 한번 간단하게 설명하고 끝내보도록 하겠습니다.
IAM 역할 생성 및 신뢰간계 생성
이런 리소스들이 직접 CloudWatch에 로그를 남기려면 권한이 필요하고 역할 기반 접근정책에 따라 부여할 수 있는 역할이 필요하다. 따라서 최소한 아래의 권한을 가진 역할을 생성합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
}
]
}
신뢰간계 입력(사실 이 신뢰관계라는 친구는 뭔지 잘 모르겠다)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "vpc-flow-logs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
CloudWatch에서 로그 그룹 생성
CloudWatch → 로그 → 로그 그룹 → 로그 그룹 생성
Flow-log 생성
VPC → transit gateway → 게이트웨이 선택 → 흐름 로그 → 흐름 로그 생성
앞에서 만들어준 역할을 부여하고 로그를 남긴 그룹을 선택하면 끝입니다.
이런 모습으로 로그가 남게된다. CloudWatch 대시보드에서 보기 이쁘게 요로코롬 만져보는게 좋을 것 같습니다.
'네트워크 > 클라우드 컴퓨팅' 카테고리의 다른 글
| System manager - Session manager (1) | 2023.03.06 |
|---|---|
| System manager - Patch manager (0) | 2023.03.05 |
| AWS 내부 ELB 구축 (1) | 2023.01.28 |
| AWS auto scaling (0) | 2023.01.27 |
| 인프라 스트럭쳐 자동화 (Cloudformation) (0) | 2023.01.20 |
