본문 바로가기
Cloud AWS, Azure, GCP

AWS 인프라 구축 실습 2회 - VPC Peering

by SB리치퍼슨 2021. 10. 25.

AWS 인프라 구축 실습 2회 - VPC Peering

VPC Peering(VPC 피어링 연결)이란 별도의 두 VPC 사이에서 비공개로 트래픽을 라우팅할 수 있도록 하는 네트워킹 연결입니다. 해당 VPC의 인스턴스는 동일한 네트워크 안에 있는 것처럼 서로 통신할 수 있습니다. 자체 VPC, 다른 AWS 계정의 VPC 또는 다른 AWS 리전의 VPC 사이에서 VPC 피어링 연결을 생성할 수 있습니다.

동 기업간 또는 타 기업간의 VPC 서비스간에 원할한 네트워킹을 위해서 필요한 기능일 수 있습니다.

AWS 인프라 구축 실습을 시작하도록 하겠습니다.


1. VPC Peering 연결


이 방식은 VPC간 외부망(퍼블릭IP)이 아닌 내부망(프라이빗IP)로 연결하여 통신하는 방법입니다.
즉, 동일한 VPC에 있는 인스턴스와 통신하는 것처럼 통신이 가능합니다.
실습에서는 서울 리전과 도쿄 리전을 연결하는 실습을 진행해보겠습니다. 

VPC peering 구조도


ping 사용을 위한 보안그룹 유형은 '모든 ICMP-IPv4 (모두, 0.0.0.0/0)입니다.
구조도의 서브넷 CIDR 넷마크만 변경해서 실습해보겠습니다.

* 이번 실습에서 서브넷의 구성은 중요하지 않으므로 public subnet 1개 이상만 있으면 됩니다.

도쿄에서 요청하고 서울에서 수락하는 방법으로 실습합니다.
(참고로, 다른 계정도 가능하고 다른 리전과 피어링이 가능합니다.)

도쿄 라우팅 설정(my-rtb) 대상1, 대상2 설정 (서울의 private IP, 피어링 연결 선택)
서울 라우팅 설정(my-rtb) 대상1, 대상2 설정 (도쿄의 private IP, 피어링 연결 선택)

1.1. 서울 리전 설정
서울리전은 지금 도쿄리전으로 이동하여 VPC, subnet, EC2, Internet Gateway, Routing Table 을 설정합니다.

퍼블리서브넷에 EC2를 생성하면 됩니다. 

1.2. 도쿄 리전 설정
도쿄리전은 지금 도쿄리전으로 이동하여 VPC, subnet, EC2, Internet Gateway, Routing Table 을 설정합니다.


도쿄리전은 서울리전과 동일한 방법으로 도쿄리전을 생성하도록 하겠습니다. 


1.2.1. VPC 생성
VPC 이름 : "my-vpc-01"
DNS 호스트 이름 편집
  DNS 호스트 이름 : 활성화 체크

1.2.2. 서브넷 생성 (도쿄예시)
VPC ID : "my-vpc-01" 선택
서브넷 : "my-subnet-1a"
  가용영역 : ap-northeast-1a
  CIDR : 10.0.0.0/20
서브넷 : "my-subnet-1c"
  가용영역 : ap-northeast-1c
  CIDR : 10.0.16.0/20
서브넷 : "my-subnet-1d"
  가용영역 : ap-northeast-1d
  CIDR : 10.0.32.0/20

1.2.3. 인터넷 게이트 웨이 생성
  이름 : "my-IG-01"
  VPC 연결 : "my-vpc-01"
  라우팅 테이블 연결

1.2.4. 라우팅 테이블 생성
VPC를 생성하면 라우팅 테이블이 기본 생성됩니다.
  태그 이름 : "my-rtb-01"
  VPC : "my-vpc-01"
  라우팅 테이블 메뉴에서 라우팅 행의 빈 영역을 클릭하면 상세 정보가 표시됩니다.  라우팅 탭을 클릭하고 "라우팅 편집"을 클릭합니다.
라우팅 추가를 클릭합니다. 대상에서 "0.0.0.0/0" 을 선택하고 인터넷 게이트웨이를 선택하여 선택가능한 인터넷 게이트웨이를 추가합니다. 

1.2.5. EC2 생성
서울 리전과 동일하게 Amazon Linux 2 AMI를 선택하고 t2.micro선택하고 '단계3: 인스턴스 세부정보 구성'에서 VPC, 서브넷, 퍼블릭IP 자동할당, 사용자 데이터를 설정합니다.
태그명 : "my-web-01"
새 보안그룹명 : "my-sg-01", "모든 ICMP-IPv4", Anywhere
(* 서울리전에도 동일하게 보안그룹에 "모든 ICMP-IPv4", Anywhere를 추가 설정합니다.)
새 키페어 생성 : my-aws-train-02
ssh 연결 할 수 있도록 키페어 파일을 ssh 연결을 위한 폴더로 이동합니다. 키페어 파일접근모드를 변경합니다. shell 파일명 seoul.sh, tokyo.sh로 생성합니다. 파일접근모드를 변경합니다. (shell파일명에 ssh연결명령을 추가하고 저장합니다)

$ chmod 400 my-aws-train-02.pem
$ vi seoul.sh
ssh -i "my-aws-train.pem" ec2-user@ec2-3-36-114-145.ap-northeast-2.compute.amazonaws.com
$ chmod 700 seoul.sh
$ vi kokyo.sh
ssh -i "my-aws-train-02.pem" ec2-user@ec2-18-183-229-189.ap-northeast-1.compute.amazonaws.com
$ chmod 700 tokyo.sh


 ↓ 서울 리전의 EC2 인스턴스 퍼블릭IP와 프라이빗IP


 ↓ 도쿄 리전의 EC2 인스턴스 퍼블릭IP와 프라이빗IP




1.3. 서울 리전과 도쿄 리전 퍼블릭 연결 테스트
서울 리전과 도쿄 리전을 퍼블릭 IP로 연결해봅니다. 
서울 리전에서 도쿄 리전으로 ping을 날려봅니다.

[ec2-user@ip-10-0-3-15 ~]$ ping 18.183.229.189
PING 18.183.229.189 (18.183.229.189) 56(84) bytes of data.
64 bytes from 18.183.229.189: icmp_seq=1 ttl=230 time=34.6 ms
64 bytes from 18.183.229.189: icmp_seq=2 ttl=230 time=34.6 ms
64 bytes from 18.183.229.189: icmp_seq=3 ttl=230 time=34.6 ms
64 bytes from 18.183.229.189: icmp_seq=4 ttl=230 time=34.7 ms
^C


이번에는 도쿄 리전에서 서울 리전으로 ping을 날려봅니다.

[ec2-user@ip-172-31-47-127 ~]$ ping 3.36.114.145
PING 3.36.114.145 (3.36.114.145) 56(84) bytes of data.
64 bytes from 3.36.114.145: icmp_seq=1 ttl=230 time=37.6 ms
64 bytes from 3.36.114.145: icmp_seq=2 ttl=230 time=34.5 ms
64 bytes from 3.36.114.145: icmp_seq=3 ttl=230 time=34.6 ms
64 bytes from 3.36.114.145: icmp_seq=4 ttl=230 time=34.6 ms
^C

퍼블릭 연결이 된다는 것을 확인할 수 있습니다.

1.4. 서울 리전과 도쿄 리전 프라이빗 연결 테스트
서울 리전과 도쿄 리전을 프라이빗 IP로 연결해봅니다.
서울 리전에서 도쿄 리전으로 ping을 날려봅니다.

[ec2-user@ip-10-0-3-15 ~]$ ping 172.31.47.127
PING 172.31.47.127 (172.31.47.127) 56(84) bytes of data.
^C
--- 172.31.47.127 ping statistics ---
186 packets transmitted, 0 received, 100% packet loss, time 189424ms


도쿄 리전에서 서울 리전으로 ping을 날려봅니다.

[ec2-user@ip-172-31-47-127 ~]$ ping 10.0.3.15
PING 10.0.3.15 (10.0.3.15) 56(84) bytes of data.
^C
--- 10.0.3.15 ping statistics ---
55 packets transmitted, 0 received, 100% packet loss, time 55277ms

현재 프라이빗 IP(내부망)로는 연결이 불가능합니다.
이제, VPC Peering을 설정하고 나서 프라이빗IP로 ping을 실행해보겠습니다.


1.5. 피어링 연결


1.5.1. 피어링 생성

도쿄리전의 피어링 연결 메뉴로 이동합니다. "피어링연결생성"을 클릭합니다. (서울리전에서 하여도 됩니다)

다음과 같이 입력합니다.
로컬 VPC(도쿄리전)와 피어링할 다른 VPC(서울리전)를 선택합니다. 
피어링명 : "my-pc-01"
다른리전에는 서울리전의 vpc id를 입력합니다.

피어링 수락 대기중 표시


1.5.2. 피어링수락
서울리전의 피어링 연결 메뉴로 이동합니다.

수락 기간내에 수락을 하면 됩니다.

작업메뉴에서 '요청 수락'을 선택하여 요청을 수락합니다.


AWS는 "프로비저닝" 작업을 진행하고 이 처리과 완료되면 상태는 '활성'이 됩니다.


1.6. 라우팅 (피어링연결) 설정


이제 라우팅 테이블을 설정해야 합니다.


서울리전에서 대상(destination, target)서울리전으로 라우팅 테이블을 편집합니다.
라우팅 추가 버튼을 눌러서 대상 VPC의 CIDR을 입력하고 대상을 "인터넷 게이트웨이"로 선택합니다.


서울리전에서 일본리전의 VPC 를 연결하는 설정을 완료합니다.


이제는 도쿄리전에서 대상(destination, target)서울리전으로 라우팅 테이블을 편집합니다.


설정 완료된 상태입니다.



1.7. 피어링연결 테스트
이제 서울리전 EC2에서 도쿄리전 EC2로 ping을 프라이빗IP로 요청해봅니다.

[ec2-user@ip-10-0-3-15 ~]$ ping 172.31.47.127
PING 172.31.47.127 (172.31.47.127) 56(84) bytes of data.
64 bytes from 172.31.47.127: icmp_seq=1 ttl=255 time=32.2 ms
64 bytes from 172.31.47.127: icmp_seq=2 ttl=255 time=32.3 ms
64 bytes from 172.31.47.127: icmp_seq=3 ttl=255 time=32.2 ms
64 bytes from 172.31.47.127: icmp_seq=4 ttl=255 time=32.3 ms
64 bytes from 172.31.47.127: icmp_seq=5 ttl=255 time=32.4 ms
^C


다음으로, 도쿄리전 EC2에서 서울리전 EC2로 ping을 요청해봅니다.

[ec2-user@ip-172-31-47-127 ~]$ ping 10.0.3.15
PING 10.0.3.15 (10.0.3.15) 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=255 time=32.4 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=255 time=32.5 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=255 time=32.5 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=255 time=32.9 ms
^C

이렇게 VPC 피어링 연결을 설정하여 외부망(퍼블릭IP)이 아닌 내부망(프라이빗IP)으로 VPC간 통신이 가능한 것을 확인할 수 있습니다.

AWS 인프라 구축 실습 2회 - VPC Peering에 대하여 알아봤습니다.
다음 회에는 AWS 인프라 구축 실습 3회 - Route53, EBS에 대하여 실습해도보록 하겠습니다.

반응형

댓글