오늘은 TGW(transit Gateway)를 사용하여 다른 VPC의 WEB과 통신 해보겠습니다.
https://bigco-growth-diary.tistory.com/53
오늘 실습할 아키텍처입니다.
VPC1의 IN ALB의 타겟그룹을 VPC2의 web으로 지정 해줬습니다.
Transit Gateway
Transit Gateway는 VPC Peering과 마찬가지로 서로 다른 VPC간에 통신이 가능하게 하는 서비스입니다.
VPC Peering은 1 대 1 VPC 연결만 지원하여 직접적으로 연결되어있지 않은 VPC에 바로 접근할 수 없었다면 Transit Gateway는 중앙 허브를 통해 여러 VPC간 연결 정책을 중앙에서 관리할 수 있고, VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.
Transit Gateway 특징
- 중앙 허브와 VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.
- 복잡한 피어링 관계를 제거하여 네트워크를 간소화 시킬 수 있습니다.
- 클라우드 라우터 역할을 하므로 새로운 연결을 한 번만 추가하면 됩니다.
- 다른 리전간의 Transit Gateway와 피어링 연결이 가능합니다.
Transit Gateway 사용 이유
VPC Peering을 사용해 같은 리전에 있는 VPC와 다른 리전에 있는 VPC를 연결하고 VPN을 통해 온프레미스 네트워크와 연결하기위해서는 다음과 같은 구조로 인프라를 구성해야 됩니다.
VPC Peering을 사용하는 경우에 더욱 더 큰 규모의 서비스일수록 인프라를 관리하기가 매우 까다로워 집니다. 온프레미스 네트워크와 연결하기 위해 VGW(Virtual Private Gateway)를 구성해야 하며 VPC를 한개만 추가하는 것만으로도 수많은 Peering Connection이 추가될 수도 있습니다.
Transit Gateway를 사용하면 중앙허브를 통해 위 인프라를 더욱더 관리하기 쉽고 확장성있는 구조로 변경할 수 있습니다.
VPC를 Transit Gateway에 연결해주기만하면 Transit Gateway에 연결된 모든 다른 VPC와 통신이 가능하게 됩니다.
또한 CGW(Customer Gateway)와 Transit Gateway를 연결하게 되면 Transit Gateway에 연결된 VPC는 VPN을 통해 온프레미스 네트워크와도 통신이 가능합니다.
따라서 연결해야하는 VPC 개수가 많으며, 온프레미스와의 VPN연결 까지 관리해야한다면 Transit Gateway를 사용하는 것이 관리적인 측면에서 훨씬 유리 합니다.
참고자료
Bastion, Web Server1,2의 생성과정은 생략하였습니다.
3개의 서버들을 만들고 bastion에서 아직 web으로 접근할 수 없을겁니다.
저희는 vpc2에 접속하기 위해 TGW를 생성하여 라우팅 테이블을 만들어줘서 라우팅테이블의 각각의 VPC대역을 추가해 줄 겁니다.
VPC서비스의 왼쪽 바를 쭉 내리다보면 TGW를 발견하실 수 있습니다.
여기서 잠깐 몇 가지 중요한 옵션들에 대해 간략히 설명하고 넘어가도록 하겠습니다.
- ASN(Autonomous System Number, 자율 시스템 번호)
- AS(Autonomous System)는 일관된 라우팅 정책을 가지고 있는 라우터의 집단입니다.
- AS간에 연결하는데 있어서 유일한 통신규약이 BGP(Border Gateway Protocol, TCP 179)인데 이 BGP를 사용하기 위해서는 ASN을 지정해줘야 합니다. 쉽게 말해 각각의 시스템을 식별하기 위한 식별 번호라고 생각하시면 됩니다.
- 지정 가능한 ASN의 범위는 64512~65534 혹은 4200000000~4294967294 입니다.
- 지정하지 않을 경우 default ASN(64512)이 부여됩니다.
- DNS support(DNS 지원)
- 해당 옵션을 활성화하면 인스턴스의 Public IPv4 DNS가 가르키는 IP를 Public IP에서 Private IP로 전환합니다.
- 인터넷을 통해 외부로 통신하는 것이 아닌 내부로 통신하기 때문에 보안성을 향상시킬 수 있습니다.
- 해당 옵션을 사용하기 위해서는 VPC 옵션에서 DNS hostnames 옵션을 활성화 해야합니다.
- VPN ECMP support(VPN ECMP 지원)
- 해당 옵션을 활성화하면 VPN 터널 간에 ECMP(Equal Cost Multipath, 동일 비용 다중 경로) 라우팅을 지원합니다.
- 예를 들어 동일한 CIDR를 가진 2개의 VPN 터널을 통해 트래픽을 전송하려 하는 경우 트래픽을 1:1로 균등하게 분산하여 전송합니다.
- Default route table association(기본 라우팅 테이블 연결)
- 해당 옵션을 활성화하면 Transit Gateway 라우팅을 위한 기본 라우팅 테이블이 생성됩니다.
- VPC를 Transit Gateway와 연결하면 VPC의 라우팅 테이블이 자동으로 Transit Gateway의 기본 라우팅 테이블에 연결됩니다.
- Default route table propagation(기본 라우팅 테이블 전파)
- 해당 옵션을 활성화하면 VPN 연결과 함께 동적 라우팅을 사용하는 경우 VPN 연결과 연결된 라우팅 테이블의 경로가 BGP를 통해 CGW(Customer Gateway)에 전달됩니다.
- Auto accept shared attachments(공유 첨부 파일 자동 수락)
- AWS Resource Access Manager를 사용해 Transit Gateway를 다른 계정과 공유할 수 있습니다.
- 다른 계정과 Transit Gateway를 공유하기 위해 공유를 요청한 경우 해당 옵션을 활성화하면 별도의 수락을 하지 않아도 자동으로 수락됩니다.
- Transit Gateway CIDR Block(선택 사항)
- 지정한 CIDR의 범위에 해당되는 VPC만 Transit Gateway와 연결할 수 있습니다.
- 169.254.0.0/16 과 온프레미스 네트워크와 겹치는 CIDR는 지정할 수 없습니다.
서브넷ID에서 서브넷을 public, private중 아무거나 선택해도 AZ로 설정되기 때문에 상관없습니다.
이렇게 TGW에 통신하려고 하는 VPC를 등록해줍니다.
그리고 여기서 끝이 아니라 각각의 VPC의 라우팅테이블에 TGW를 추가 시켜줘야합니다.
이렇게 VPC1에서 public RT VPC2에서 private RT에 TWG를 등록시켜 줍니다.
이제는 Transit gateway를 통해서 두 vpc가 통신을 할 수 있는 상태입니다.
그래서 저는 vpc1의 bastion을 통해서 vpc2의 web에 ssh접근으로 들어가서 aphach 서버를 설치 해주겠습니다.
1. pem key 를 사용하여 EC2 접속
ssh -i "본인의 pem 경로" ec2-user@"EC2 IP"
2. User 및 Password 설정
sudo adduser "유저명" # 유저 생성
sudo passwd "유저명" # 비밀번호 설정
3. sudoers 파일에, 생성한 User 추가
- 설정 파일 권한 변경 및 접근
// 파일 권한 변경
sudo chmod u+w /etc/sudoers
// 파일접근
sudo vi /etc/sudoers
맨 하단에 아래 내용 추가 (sudo 접근 가능하도록 설정)
// 서비스 재시작
sudo service sshd restart
ssh 접근을 위해 bastion에 키를 옮겨줬습니다.
TGW를 통해서 SSh로 VPC1 -> VPC2에 접속은 성공했습니다.
이렇게 vpc2에 있는 Web에 접속하여 Aphach 서버를 설치해줍니다.
(httpd설치는 생략하도록 하겠습니다.)
(NLB, ALB도 전 게시물의 LB들을그대로 사용하기에 설치는 생략하도록 하겠습니다.)
이제 vpc1의 ALB의 TG을 vpc2의 web으로 잡아주겠습니다.
우선 TG부터 생성해주겠습니다.
이렇게 ALB에서 사용할 TG을 만들었습니다.
그럼 이제 ALB의 리스너에 등록을 해주겠습니다.
이렇게 접속을 완료했습니다.
'AWS > Transit Gateway (TGW)' 카테고리의 다른 글
[ Transit Gateway #2] TGW Route Table 활용 (0) | 2023.09.18 |
---|---|
[ Transit Gateway #1 ] Transit Gateway란? (0) | 2023.09.12 |