GWLB Design 2

Update : 2024-08-04/ 1h

목표 구성 개요

3개의 각 워크로드 VPC (VPC01,02,03)은 Account내에 구성된 GWLB 기반의 보안 VPC를 통해서 내, 외부 트래픽을 처리하는 구성입니다. GWLB 기반의 보안 VPC는 2개의 AZ에 4개의 가상 Appliance가 로드밸런싱을 통해 처리 됩니다.

이러한 구성은 VPC Endpoint를 특정 VPC에 구성하고, TransitGateway를 통해 GWLB에 VPC Endpoint Service를 연결하는 중앙집중 구조입니다.

아래 그림은 목표 구성도 입니다.

Cloudformation기반 VPC 배포

1.VPC yaml 파일 다운로드

Code-Server 터미널에서 아래 github로 부터 VPC yaml 파일을 다운로드 합니다. (앞서 다운로드 하였으면 생략합니다.)

아래와 같은 순서로 Cloudformation에서 Yaml파일을 배포합니다.

  1. GWLBVPC.yml

  2. N2SVPC.yml

  3. VPC01.yml, VPC02.yml

  4. GWLBTGW.yml

계정에서 VPC 기본 할당량은 Default VPC 포함 5개입니다. 이 랩에서는 VPC03 은 생성하지 않습니다.

2.GWLB VPC 배포

Code-Server 터미널에서 GWLBVPC를 배포합니다

스택 세부 정보 지정에서 , 스택이름과 VPC Parameters를 지정합니다. 대부분 기본값을 사용하면 됩니다.

  • 스택이름 : GWLBVPC

  • AvailabilityZone A : ap-northeast-2a

  • AvailabilityZone B : ap-northeast-2b

  • VPCCIDRBlock: 10.254.0.0/16

  • PublicSubnetABlock: 10.254.11.0/24

  • PublicSubnetBBlock: 10.254.12.0/24

  • InstanceTyep: t3.small

3~4분 후에 GWLBVPC가 완성됩니다.

AWS 관리콘솔 - VPC - 가상 프라이빗 클라우드 - 엔드포인트 서비스 를 선택합니다. Cloudformation을 통해서 VPC Endpoint 서비스가 이미 생성되어 있습니다. 이것을 선택하고 **세부 정보**를 확인합니다.

VPC Endpoint Service Name을 복사해 둡니다. 뒤에서 생성할 VPC들의 Cloudformation에서 사용할 것입니다.

VPCEndpointServiceName 값을 아래에서 처럼 환경변수에 저장해 둡니다.

3.N2SVPC 배포

외부 인터넷으로 통신하는 North-South 트래픽 처리를 하는 VPC를 생성합니다.

N2SVPC를 Cloudformation에서 앞서 과정과 동일하게 생성합니다. 다운로드 받은 Yaml 파일들 중에 N2SVPC 선택해서 생성합니다.스택 이름을 생성하고, GWLBVPC의 VPC Endpoint 서비스 이름을 "VPCEndpointServiceName" 에 입력합니다. 또한 나머지 파라미터들도 입력합니다. 대부분 기본값을 사용합니다.

  • 스택이름 : N2SVPC

  • AvailabilityZone A : ap-northeast-2a

  • AvailabilityZone B : ap-northeast-2b

  • VPCCIDRBlock: 10.11.0.0

  • PublicSubnetABlock: 10.11.11.0/24

  • PublicSubnetBBlock: 10.11.12.0/24

  • PrivateSubnetABlock:10.11.21.0/24

  • PrivateSubnetBBlock:10.11.22.0/24

  • TGWSubnetABlock:10.11.251.0/24

  • TGWSubnetBBlock:10.11.252.0/24

  • DefaultRouteBlock: 0.0.0.0/0 (Default Route Table 주소를 선언합니다.)

  • VPC1CIDRBlock : 10.1.0.0/16 (VPC1의 CIDR Block 주소를 선언합니다.)

  • VPC2CIDRBlock: 10.2.0.0/16 (VPC2의 CIDR Block 주소를 선언합니다.)

  • VPCEndpointServiceName : 앞서 복사해둔 GWLBVPC의 VPC endpoint service name을 입력합니다.

  • InstanceTyep: t3.small

나머지 VPC01,VPC02,VPC03 의 Cloudformation Yaml 파일을 업로드 합니다.

VPC는 계정당 기본 5개가 할당되어 있습니다. 1개는 Default VPC로 사용 중이고, 4개를 사용 가능하므로 일반 계정에서는 GWLBVPC, N2SVPC, VPC01,VPC02 까지만 생성 가능합니다.

  • 스택이름 : VPC01,VPC02

  • AvailabilityZone A : ap-northeast-2a

  • AvailabilityZone B : ap-northeast-2b

  • VPCCIDRBlock: 10.1.0.0 (VPC01), 10.2.0.0 (VPC02)

  • PrivateSubnetABlock:10.1.21.0/24 (VPC01), 10.2.22.0/24(VPC02)

  • PrivateSubnetBBlock:10.1.22.0/24 (VPC01), 10.2.22.0/24(VPC02)

  • TGWSubnetABlock:10.1.251.0/24 (VPC01), 10.2.251.0/24 (VPC02)

  • TGWSubnetBBlock:10.1.252.0/24 (VPC01), 10.2.252.0/24 (VPC02)

  • InstanceTyep: t3.small

  • KeyPair : 사전에 만들어 둔 keyPair를 사용합니다.(예. gwlbkey)

N2SVPC, VPC01,02,03 을 연결할 TGW를 생성합니다. N2STGW는 TGW Routing Table과 각 VPC들이 Route Table을 자동으로 구성해 줍니다.

  • Stack Name : GWLBTGW

  • DefaultRouteBlock: 0.0.0.0/0

  • VPC01CIDRBlock: 10.1.0.0/16

  • VPC02CIDRBlock: 10.2.0.0/16

AWS 관리 콘솔 - VPC 대시 보드 - VPC

AWS 관리 콘솔 - VPC 대시 보드 - 서브넷

5. TransitGateway 배포

N2SVPC, VPC01,VPC02을 연결하기 위한 TransitGateway를 배포합니다. 앞서 git을 통해 다운 받은 파일 중 GWLBTGW.yml 파일을 Cloudformation을 통해서 배포합니다.

**Default Route Table**과 VPC01, VPC02 CIDR 주소를 입력합니다. (기본 값으로 설정되어 있습니다.)

6. 라우팅 테이블 확인

TransitGateway 구성과 RouteTable을 아래에서 확인합니다.

AWS 관리 콘솔 - VPC 대시보드 - TransitGateway 에서 TransitGateway가 정상적으로 구성되었는지 확인합니다.

AWS 관리 콘솔 - VPC 대시보드 - TransitGateway- TransitGateway 연결(Attachment) 에서 TransitGateway와 VPC가 정상적으로 연결되었는지 확인합니다.

AWS 관리콘솔 - VPC 대시보드 -TransitGateway-TransitGateway 라우팅 테이블-Route 에서 "GWLBTGW-RT-VPC-OUT, "GWLBTGW-RT-VPC-IN" 라우팅 테이블을 확인합니다.

  • GWLBTGW-RT-VPC-OUT : VPC01,VPC02 에서 인터넷으로 향하는 트래픽

  • GWLBTGW-RT-VPC-IN: VPC01,VPC02 로 내부로 향하는 트래픽

**AWS 관리 콘솔 -VPC 대시보드 - 가상 프라이빗 클라우드 - 라우팅테이블**에서 각 Private-Subnet-A,B-RT 라우팅 테이블을 확인합니다.

  • VPC01,02-Private-Subnet-A,B-RT : 0.0.0.0/0 - tgw

GWLB 구성 확인

GWLBVPC 구성을 확인해 봅니다.

  1. GWLB 구성

  2. GWLB Target Group 구성

  3. VPC Endpoint 와 Service 확인

  4. Appliance 확인

7.GWLB 구성

AWS 관리 콘솔 - EC2 - 로드밸런싱 - 로드밸런서 메뉴를 선택합니다. Gateway LoadBalancer 구성을 확인할 수 있습니다. ELB 유형이 **"gateway"**로 구성된 것을 확인 할 수 있습니다.

8.GWLB Target Group 구성

**AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹**을 선택합니다. GWLB가 로드밸런싱을 하게 되는 대상그룹(Target Group)을 확인 할 수 있습니다.

  • 프로토콜 : GENEVE 6081 (포트 6081의 GENGEVE 프로토콜을 사용하여 모든 IP 패킷을 수신하고 리스너 규칙에 지정된 대상 그룹에 트래픽을 전달합니다.)

  • 등록된 대상 : GWLB가 로드밸런싱을 하고 있는 Target 장비를 확인합니다.

AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹 - 상태검사 메뉴를 확인합니다.

ELB와 동일하게 대상그룹(Target Group)에 상태를 검사할 수 있습니다. 이 랩에서는 HTTP Path / 를 통해서 **Health Check**를 하도록 구성했습니다.

9. VPC Endpoint Service 확인

N2SVPC Private link로 연결하기 위해, GWLB VPC에 Endpoint Service를 구성하였습니다. 이를 확인해 봅니다.

**AWS 관리 콘솔 - VPC - 엔드포인트 서비스**를 선택합니다. 생성된 VPC Endpoint Service를 확인할 수 있습니다.

  • 서비스 이름 - 예 com.amazonaws.vpce.ap-northeast-2.vpce-svc-082d152b9180f8ad0

  • 유형 : GatewayLoadBalancer

  • 가용영역 : ap-northeast-2a, ap-northeast-2b

2개 영역에 걸쳐서 GWLB에 대해 VPC Endpoint Service를 구성하고 있습니다.

**AWS 관리 콘솔 - VPC - 엔드포인트 서비스-엔드포인트 연결**를 선택합니다.

N2SVPC의 각 가용영역들과 연결된 것을 확인 할 수 있습니다. VPC별 2개의 가용영역의 Private Subnet에 배치된 VPC Endpoint에 연결된 것을 확인 합니다.

10. Appliance 확인

AWS 관리 콘솔 - EC2 - 인스턴스 메뉴를 선택하고, "appliance" 키워드로 필터링 해 봅니다. 4개의 리눅스 기반의 appliance가 설치되어 있습니다.

Appliance 구성 정보를 확인해 봅니다.

**AWS 관리콘솔 - Cloudformation - 스택**을 선택하면, 앞서 배포했던 Cloudformation 스택들을 확인 할 수 있습니다. **"GWLBVPC"**를 선택합니다. 그리고 출력을 선택합니다. 값을 확인해 보면 공인 IP 주소를 확인 할 수 있습니다.

앞서 사전 준비에서 생성한 Code-Server 터미널에서 Appliance로 직접 접속해 봅니다.

아래와 같이 구성합니다.

각 Appliance에서 아래 명령을 통해 , GWLB IP와 어떻게 매핑되었는지 확인합니다. Code-Server에서 새로운 터미널 4개를 탭에서 추가해서 4개 Appliance를 모두 확인해 봅니다.

각 Appliance에서 아래 명령을 통해 , GWLB IP와 어떻게 매핑되었는지 확인합니다.

AZ A에 배포된 Appliance는 다음과 같이 출력됩니다.

GENEVE 터널링의 GWLB IP주소는 10.254.11.60 이며, Appliance IP와 터널링 된 것을 확인 할 수 있습니다.

AZ B에 배포된 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하여 분산처리할 때 사용합니다.

외부 연결용 VPC 확인

이제 외부 연결 VPC에서 실제 구성과 트래픽을 확인해 봅니다.

  1. VPC Endpoint 확인

  2. Private Subnet Route Table 확인

  3. Ingress Routing Table 확인

아래 흐름과 같이 트래픽이 처리됩니다.

  1. VPC1,2 인스턴스는 외부로 향하기 위해 TransitGateway로 접근

  2. VPC 1,2 Private Subnet Route Table을 참조해서, Transit Gateway로 전

  3. TransitGateway Routing Table을 참조해서, N2SVPC Attachment로 전

  4. N2SVPC 로 인입된 트래픽은 N2SVPC TGW Routing Table에 의해 VPC Endpoint로 전달.

  5. VPC Endpoint는 GWLBVPC Private Link의 VPC Endpoint Service로 전달하고, VPC EndpointService는 GWLB로 트래픽 전달.

  6. AZ A,AZ B Target Group으로 LB 처리 - UDP 6081 GENEVE로 Encapsulation (TLV Header - 5Tuple)

  7. Appliance에서 트래픽 처리 후 다시 Return

  8. Decap 해서 다시 VPC Endpoint Service로 전달하고, N2SVPC VPC Endpoint로 전달

  9. Private Subnet Route Table에서 Public Subnet의 NAT Gateway로 트래픽 전달하고, 외부로 전송.

11.VPC Endpoint 확인

**AWS 관리 콘솔 - VPC - Endpoint**를 선택하여 실제 구성된 VPC Endpoint를 확인해 봅니다. N2SVPC에 2개씩 구성된 AZ를 위해 2개의 Endpoint가 구성되어 있습니다. (VPC Endpoint는 AZ Subnet당 연결됩니다.)

12. N2S VPC Route Table 확인

AWS 관리콘솔 - VPC - 라우팅 테이블을 선택하고 각 라우팅 테이블을 확인해 봅니다.

AWS 관리 콘솔 - VPC 대시보드 - 라우팅 테이블 - N2SVPC TGW Routing Table 확인

AWS 관리 콘솔 - VPC 대시보드 - 라우팅 테이블 - N2SVPC Private Routing Table 확인

AWS 관리 콘솔 - VPC 대시보드 - 라우팅 테이블 - N2SVPC Public Routing Table 확인

트래픽 확인

13. Workload VPC의 EC2에서 트래픽 확인

VPC01,02의 EC2에서 외부로 정상적으로 트래픽이 처리되는 지 확인 해 봅니다.

Code-Serve터미널을 다시 접속해서 , VPC 01,02의 Private Subnet 에 배치된 EC2 인스턴스에 접속해 봅니다. Private Subnet은 직접 연결이 불가능하기 때문에 Session Manager를 통해 접속합니다.

session manager 기반으로 접속하기 위해, 아래 명령을 실행하여 ec2 인스턴스의 id값을 확인합니다.

아래와 같이 결과를 확인 할 수 있습니다.

session manager 명령을 통해 해당 인스턴스에 연결해 봅니다. (예. VPC01-Private-A-10.1.21.101)

터미널에 접속한 후에 , 아래 명령을 통해 bash로 접근해서 외부로 트래픽을 전송해 봅니다.

아래와 같은 결과를 확인할 수 있습니다. 해당 터미널에서 ping을 계속 실행해 둡니다.

앞서 Session manager를 통해 www.aws.com으로 ping을 실행했습니다. 해당 터미널을 실행한 상태에서 Code-Server 터미널을 2개로 추가로 열어 봅니다.

아래와 같이 2개의 Appliance에 SSH로 연결해서 명령을 실행해 보고, Appliance로 Traffic이 들어오는지 확인해 봅니다.

Code-Server 터미널 1

Code-Server 터미널 2

다음과 같이 1개의 터미널에서 icmp가 처리되는 것을 확인 할 수 있습니다.

Source IP와 Destination IP가 모두 유지된 채로 통신하는 것을 확인 할 수 있습니다.

이제 다른 VPC(VPC01,VPC02)와 다른 서브넷의 EC2에서도 트래픽이 정상적으로 처리되는지 확인해 봅니다.

자원 삭제

AWS 관리콘솔 - Cloudformation - 스택 을 선택하고 생성된 Stack을 삭제합니다.

GWLBTGW,VPC01,VPC02,N2SVPC,GWLBVPC 순으로 삭제합니다.(Code-Server은 계속 사용하기 위해 삭제 하지 않습니다.)

  1. GWLBTGW를 삭제합니다. (3~4분 소요됩니다.)

  2. VPC01,VPC02를 삭제합니다. (3~4분 소요됩니다. 동시 진행합니다.)

  3. N2SVPC를 삭제 합니다. (3~4분 소요됩니다.)

  4. GWLBVPC를 삭제 합니다. (3~4분 소요됩니다.)

PreviousGWLB Design 1NextGWLB Design 3

Last updated

Was this helpful?