2개의 각 워크로드 VPC (VPC01,02)은 Account내에 구성된 GWLB 기반의 보안 VPC를 통해서 내, 외부 트래픽을 처리하는 구성입니다. GWLB 기반의 보안 VPC는 2개의 AZ에 4개의 가상 Appliance가 로드밸런싱을 통해 처리 됩니다.
이러한 구성은 VPC Endpoint를 각 VPC에 분산하고, GWLB에 VPC Endpoint Service를 연결하는 분산형 구조입니다. 각 VPC01,02는 외부에 서비스를 제공하기 위해 ALB를 통해 웹 서비스를 제공하고 있으며, Private Subnet의 인스턴스는 타겟 그룹으로 연결되어 있습니다. 해당 인스턴스들을 패치 관리를 위해서 NAT Gateway를 통해 Source NAT 서비스를 받게 됩니다.
이러한 구성은 VPC Endpoint를 각 VPC에 분산하고, GWLB에 VPC Endpoint Service를 연결하는 분산형 구조이지만, 앞선 GWLB Design1 구성보다는 외부 서비스에 더 중점을 둔 디자인입니다.
아래 그림은 목표 구성도 입니다.
Cloudformation기반 VPC 배포
1.VPC yaml 파일 다운로드
Code-Server Terminal에서 아래 github로 부터 VPC yaml 파일을 다운로드 합니다. (앞선 LAB에서 다운로드 받은 경우에는 실행하지 않습니다.)
git clone https://github.com/whchoi98/gwlb.git
2.AWS 관리콘솔에서 VPC 배포
아래와 같이 Code-Server Terminal에서 Cloudformation을 실행합니다.
스택 세부 정보 지정에서 , **스택이름**과 **VPC Parameters**를 지정합니다. 대부분 기본값을 사용하면 됩니다.
AWS 관리 콘솔 - EC2 - 로드밸런싱 - 로드밸런서 메뉴를 선택합니다. Gateway LoadBalancer 구성을 확인할 수 있습니다. ELB 유형이 **"gateway"**로 구성된 것을 확인 할 수 있습니다.
4.GWLB Target Group 구성
**AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹**을 선택합니다. GWLB가 로드밸런싱을 하게 되는 대상그룹(Target Group)을 확인 할 수 있습니다.
프로토콜 : GENEVE 6081 (포트 6081의 GENGEVE 프로토콜을 사용하여 모든 IP 패킷을 수신하고 리스너 규칙에 지정된 대상 그룹에 트래픽을 전달합니다.)
등록된 대상 : GWLB가 로드밸런싱을 하고 있는 Target 장비를 확인합니다.
AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹 - 상태검사 메뉴를 확인합니다.
ELB와 동일하게 대상그룹(Target Group)에 상태를 검사할 수 있습니다. 이 랩에서는 HTTP Path / 를 통해서 Health Check를 하도록 구성했습니다.
5. VPC Endpoint Service 확인
Workload VPC(VPC01,02)들과 Private link로 연결하기 위해, GWLB VPC에 Endpoint Service를 구성하였습니다. 이를 확인해 봅니다.
**AWS 관리 콘솔 - VPC - 엔드포인트 서비스**를 선택합니다. 생성된 VPC Endpoint Service를 확인할 수 있습니다.
서비스 이름 - 예 com.amazonaws.vpce.ap-northeast-2.vpce-svc-03f01aa9fbb85beb4
유형 : GatewayLoadBalancer
가용영역 : ap-northeast-2a, ap-northeast-2b
2개 영역에 걸쳐서 GWLB에 대해 VPC Endpoint Service를 구성하고 있습니다.
**AWS 관리 콘솔 - VPC - 엔드포인트 서비스-엔드포인트 연결**를 선택합니다.
Workload VPC (VPC01,02)의 각 가용영역들과 연결된 것을 확인 할 수 있습니다. 각 VPC별 2개의 가용영역을 구성하였기 때문에 VPC별 2개의 Endpoint가 연결됩니다. (VPC 2개를 생성해서 VPC Endpoint를 각 리전별로 구성하기 때문에 이 랩에서는 4개가 보이게 됩니다.)
6. Appliance 확인
AWS 관리 콘솔 - EC2 - 인스턴스 메뉴를 선택하고, "appliance" 키워드로 필터링 해 봅니다. 4개의 리눅스 기반의 appliance가 설치되어 있습니다.
Appliance 구성 정보를 확인해 봅니다.
**AWS 관리콘솔 - Cloudformation - 스택**을 선택하면, 앞서 배포했던 Cloudformation 스택들을 확인 할 수 있습니다. "GWLBVPC"를 선택합니다. 그리고 출력을 선택합니다. 값을 확인해 보면 공인 IP 주소를 확인 할 수 있습니다.
앞서 사전 준비에서 생성한 Code-Server 터미널에서 Appliance로 직접 접속해 봅니다.
#기존 Appliance 정보를 삭제
sudo sed '/Appliance/d' ~/.bash_profile
#SSM 연결을 위한 Shell 실행
~/gwlb/appliance_ssm.sh
각 Appliance에서 아래 명령을 통해 , GWLB IP와 어떻게 매핑되었는지 확인합니다. Code-Server Terminal에서 새로운 터미널 4개를 탭에서 추가해서 4개 Appliance를 모두 확인해 봅니다.
GENEVE 터널링의 GWLB IP주소는 10.254.12.101 이며, Appliance IP와 터널링 된 것을 확인 할 수 있습니다.
이렇게 GWLB 에서 생성된 IP주소와 각 Appliance의 IP간에 UDP 6081 포트로 터널링되어 , 외부의 IP 주소와 내부의 IP 주소를 그대로 유지할 수 있습니다. 또한 터널링으로 인입시 5Tuple (출발지 IP, Port, 목적지 IP, Port, 프로토콜)의 정보를 TLV로 Encapsulation하여 분산처리할 때 사용합니다.
Workload VPC 확인
이제 각 VPC에서 실제 구성과 트래픽을 확인해 봅니다.
VPC Endpoint 확인
GWLB Subnet Route Table 확인
Public Subnet Route Table 확인
ALB 확인
Private Subnet Route Table 확인
Ingress Routing Table 확인
외부 트래픽은 인터넷 게이트웨이로 접근
Ingress Route Table에 의해 GWLB Endpoint로 트래픽 처리
GWLB Subnet의 VPC Endpoint는 GWLB VPC Endpoint Service로 전달
GWLB로 트래픽 전달
AZ A,AZ B Target Group으로 LB 처리 - UDP 6081 GENEVE로 Encapsulation (TLV Header - 5Tuple)
Appliance으로 트래픽 인입
Appliance에서 트래픽 반환
GWLB로 트래픽 반환
Decap 해서 다시 VPC Endpoint Service로 전달
GWLB Subnet VPC Endpoint로 전달
Public Subnet ALB로 전달
ALB (Internet Facing) 은 Private Target Group에 포함된 인스턴스로 전달. (Private EC2 인스턴스)
Return되는 트래픽은 ALB를 거쳐서, GWLB EP-GWLB-Internet Gateway로 다시 전달
**AWS 관리콘솔 - VPC - 라우팅 테이블**을 선택하고 VPC01,02-IGW-Ingress-RT 이름의 라우팅 테이블을 확인해 봅니다. Ingress Routing Table에 대한 구성을 확인 할 수 있습니다. GWLB Subnet,Public Subnet으로 인입 되는 트래픽을 특정 경로로 보내는 역할을 합니다. 여기에서는 GWLB VPC Endpoint로 구성하도록 되어 있습니다.
Ingress Routing에서 Private Subnet에 대한 라우팅 설정은 왜 없을까요?
외부에서 Ingress Routing 접근은 Internet Gateway에서 공인 IP로 설정된 트래픽만 설정할 수 있습니다. 이 랩에서는 외부에서 ALB로 접근할 것입니다. ALB는 Public Subnet에 할당 되어 있고, 공인 IP를 받을 수 있도록 설정되어 있습니다. Private Subnet에 대한 라우팅 설정은 Ingress Routing에서 설정해도 동작하지 않습니다.
7.VPC Endpoint 확인
**AWS 관리 콘솔 - VPC - Endpoint**를 선택하여 실제 구성된 VPC Endpoint를 확인해 봅니다. 2개의 VPC에 2개씩 구성된 AZ를 위해 총 4개의 Endpoint가 구성되어 있습니다. (VPC Endpoint는 AZ Subnet당 연결됩니다.)
8. GWLB Subnet Route Table 확인
**AWS 관리콘솔 - VPC - 라우팅 테이블**을 선택하고 VPC01,02-GWLBe-A,B-RT 이름의 라우팅 테이블을 확인해 봅니다. Egress(외부로 향하는 트래픽) 트래픽은 모두 IGW(Internet Gateway)로 향하도록 구성되어 있습니다.
9. Public Subnet Route Table 확인
**AWS 관리콘솔 - VPC - 라우팅 테이블**을 선택하고 VPC01,02-Public-A,B-RT 이름의 라우팅 테이블을 확인해 봅니다. Egress(외부로 향하는 트래픽) 트래픽은 모두 GWLB VPC Endpoint로 향하도록 구성되어 있습니다.
10. ALB 확인
AWS 관리콘솔 - EC2 - 로드밸런싱 - 로드밸런서 를 선택하고, VPC01,02-alb를 선택합니다. ALB의 외부 노출되어 있는 DNS A 레코드를 확인합니다.
아래 Shell을 실행시켜, VPC01-alb, VPC02-alb 의 FQDN을 저장해 둡니다.
#VPC01,02 ALB FQDN 변수에 저장
~/.bash_profile
~/gwlb/Case3/alb_fqdn.sh
AWS 관리콘솔 - EC2 - 로드밸런싱- 대상그룹 를 선택하고, VPC01,02-ALB-tg 를 선택합니다. 하단의 세부 정보를 확인하면 Private Subnet에 속한 4개의 인스턴스가 정상적으로 Target Group에 선택된 것을 확인 할 수 있습니다.
AWS 관리콘솔 - EC2 - 로드밸런싱- 대상그룹 를 선택하고, VPC01,02-ALB-tg 를 선택합니다. 하단에서 상태검사를 선택합니다. Private Subnet에 속한 4개의 인스턴스의 "/ec2meta-webpage/index.php" 로 상태검사를 하고 있는 것을 확인 할 수 있습니다. 이 랩에서는 이후에 해당 URL로 외부에서 접속해서 로드밸런싱이 제대로 되는지 확인할 것입니다.
11. Private Subnet Route Table 확인
**AWS 관리콘솔 - VPC - 라우팅 테이블**을 선택하고 VPC01,02-Private-A,B-RT 이름의 라우팅 테이블을 확인해 봅니다. Egress(외부로 향하는 트래픽) 트래픽은 모두 NAT Gateway로 향하도록 구성되어 있습니다.
트래픽 확인
12. Workload VPC의 EC2에서 트래픽 확인
VPC 01,02의 EC2에서 외부로 정상적으로 트래픽이 처리되는 지 확인 해 봅니다.
Code-Server Terminal을 다시 접속해서 , VPC 01,02의 Private Subnet 에 배치된 EC2 인스턴스에 접속해 봅니다. Private Subnet은 직접 연결이 불가능하기 때문에 Session Manager를 통해 접속합니다.
VPC01,02 을 Cloudformation을 통해 배포할 때 해당 인스턴스들에 Session Manager 접속을 위한 Role과 Session Manager 연결을 위한 Endpoint가 이미 구성되어 있습니다.
아래 그림에서 처럼 확인해 볼 수 있습니다.
session manager 기반으로 접속하기 위해, 아래 명령을 실행하여 ec2 인스턴스의 id값을 확인합니다.
