Canvas 1 Layer 1

AWS VPC 피어링
서로 다른 VPC 간에 통신하기

들어가며

AWS VPCVirtual Private Cloud를 사용하면 격리된 네트워크 환경을 구성할 수 있습니다. 네트워크를 어떻게 설계할 지는 전적으로 사용자에게 달려있습니다. VPC 하나에서 모든 리소스를 관리할 수도 있고, 목적에 따라 여러 VPC를 생성해서 관리할 수도 있습니다. 다수의 VPC를 사용하는 경우 둘 혹은 그 이상의 VPC 간에 연결이 필요한 경우가 있습니다. VPC 간에 리소스를 이전하는 경우에도 네트워크 연결이 필요합니다. 하지만 기본적으로 각각의 VPC는 격리된 네트워크 환경을 가지고 있기 때문에 서로 통신하는 것이 불가능합니다.

서로 다른 VPC의 리소스가 통신하기 위한 2가지 방법이 있습니다. 첫 번째는 VPC 내부의 리소스를 인터넷(퍼블릭 네트워크)에 노출 시키는 방법입니다. 이 방법은 쉽고 직관적이지만 예상하지 못 한 위험에 노출 될 수 있으며 내부망에서 직접 통신하는 것보다는 속도 면에서 불리합니다. 또한 아마존 엘라스틱캐시Amazon Elasticache와 같이 서비스에 따라서는 퍼블릭 IP를 할당하는 게 불가능한 경우도 있습니다.

두 번째 방법은 피어링 연결Peering Connection을 사용하는 방법입니다. VPC는 바로 이런 경우에 사용할 수 있도록 두 개의 VPC를 가상 네트워크 상에서 직접 연결하는 기능을 제공합니다. 이 방법을 통해 서로 다른 VPC에 속한 리소스들이 통신할 수 있습니다.

AWS는 VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성합니다. 이는 게이트웨이도, VPN 연결도 아니며 물리적 하드웨어 각각에 의존하지 않습니다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없습니다.

VPC 피어링 - Amazon Virtual Private Cloud

이 글에서는 VPC 피어링 개념과 피어링 연결을 생성하고 설정하는 법을 소개하고자 합니다.

첫 번째 VPC

2개의 VPC가 있을 때 두 VPC 간에는 기본적으로 서로 통신하는 것이 불가능합니다. 최종적으로 다음과 같이 2개의 VPC를 구성하고 피어링 연결을 통해서 VPC간에 통신이 가능하도록 구성해보겠습니다.

VPC 피어링을 통한 두 VPC의 EC2인스턴스 간의 통신
VPC 피어링을 통한 두 VPC의 EC2인스턴스 간의 통신

먼저 다음과 같이 첫 번째 VPC를 만들고 단일 VPC의 네트워크를 살펴보겠습니다.

하나의 VPC에서 두 인스턴스 간의 통신
하나의 VPC에서 두 인스턴스 간의 통신

VPC 마법사로 VPC 생성

VPC와 관련된 네트워크 리소스를 일일히 구성하는 것도 가능하지만, 이 글에서는 아마존에서 제공하는 VPC 마법사를 사용해서 VPC를 만들어보겠습니다. 새로 생성할 VPC의 기본적인 네트워크 구성은 다음과 같습니다.

VPC를 생성하기 위해 AWS VPC 콜솔로 이동합니다.

AWS의 VPC 대시보드 화면
AWS의 VPC 대시보드 화면

VPC 마법사 시작하기Start VPC Wizard를 클릭해 VPC 생성을 시작합니다.

1단계: VPC 마법사는 VPC 생성을 위한 4가지 시나리오를 제공합니다
1단계: VPC 마법사는 VPC 생성을 위한 4가지 시나리오를 제공합니다

하나의 퍼블릭 서브넷으로 구성된 VPCVPC with Single Public Subnet선택Select합니다.

2단계: VPC의 구체적인 설정들을 지정합니다
2단계: VPC의 구체적인 설정들을 지정합니다

앞서 정의한 네트워크 구성대로 값을 채워넣습니다. 중요한 속성들은 다음과 같습니다.

잠시 후 VPC가 생성되고 나면 VPC 목록Your VPCs에서 다음과 같이 새로 생성된 VPC를 확인할 수 있습니다.

peering_test_1 VPC를 목록에서 확인할 수 있습니다
peering_test_1 VPC를 목록에서 확인할 수 있습니다

퍼블릭 서브넷의 라우트 테이블(Route Table)

VPC 마법사로 VPC를 생성하면, default 시큐리티 그룹과 퍼블릭 서브넷에서 사용하는 라우트 테이블이 함께 생성됩니다. 이 둘은 VPC 내부의 네트워크 환경을 정의하는 핵심적인 요소입니다. 하나씩 살펴보도록 하겠습니다.

라우트 테이블 먼저 살펴보겠습니다. VPC 내의 서브넷 목록Subnets이나 라우트 테이블 목록Route Tables에서 확인할 수 있습니다.

peering_test_1_public 서브넷의 라우트 테이블
peering_test_1_public 서브넷의 라우트 테이블

화면에서 확인 가능하듯이 peering_test_1_pubilc 서브넷은 rtb-64b5d11c* 라우트 테이블을 사용합니다. 이 라우트 테이블에는 2개의 규칙이 정의되어있습니다.

* 이름을 직접 지정하는 경우와 달리 리소스의 ID 값은 생성할 때마다 달라집니다. 서브넷, 라우트 테이블, 인터넷 게이트웨이를 비롯한 대부분의 리소스는 생성할 때마다 다른 ID를 가집니다.

첫 번째 규칙은 같은 VPC 내부의 자원에 접근할 때 사용되는 규칙입니다. 목적지Destination가 VPC CIDR(10.255.0.0/24)과 같은 것을 확인할 수 있습니다. 이 규칙은 라이트 테이블이 속한 VPC의 CIDR을 사용해 자동으로 생성되며 삭제할 수 없습니다.

두 번째 규칙은 VPC 내부의 CIDR 접근 이외의 모든 IP에 적용되는 규칙으로, VPC의 구성 요소 중 하나인 인터넷 게이트웨이 연결되어있습니다.*

* 인터넷 게이트웨이는 VPC당 하나가 만들어집니다. 앞서 VPC 마법사에서 퍼블릭 서브넷을 생성했습니다. 퍼블릭 서브넷은 인터넷 게이트웨이에 연결되어있는 서브넷을 의미합니다. 인터넷 게이트웨이는 가정집에 비유하자면 벽에 있는 인터넷 포트라고 생각할 수 있습니다.

아직 생성하진 않았지만 두 번째 VPC의 CIDR은 10.255.1.0/24으로 지정할 계획입니다. 라우트 테이블에는 0.0.0.0/0에 대한 규칙 이외에 10.255.0.0/24에 대한 규칙만 설정되어있습니다. 10.255.1.0/24를 풀어쓰면 10.255.1.0부터 10.255.1.255까지가 됩니다. 따라서 10.255.1.0/24는 이 규칙에 해당하지 않고 나머지 모두를 의미하는 0.0.0.0/0 규칙을 따릅니다.이 IP 대역에 대한 접근은 인터넷 게이트웨이로 연결되어 있습니다. 하지만 인터넷에서는 기본적으로 이 범위를 사용하지 않습니다. 10.0.0.0부터 10.255.255.255는 프라이빗 네트워크를 위해 예약된 공간입니다. whois 명령어를 사용해 이 대역의 IP를 조회해보면, Private Use로 예약된 IP라는 것을 확인할 수 있습니다.

$ whois 10.0.0.0
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

inetnum:      10.0.0.0 - 10.255.255.255
organisation: IANA - Private Use
status:       RESERVED

remarks:      Reserved for Private-Use Networks [RFC1918].Complete
remarks:      registration details for 10.0.0.0/8 are found
remarks:      iniana-ipv4-special-registry.

changed:      1995-06
source:       IANA

인터넷 게이트웨이를 통해 프라이빗 영역에는 접근할 수 없습니다. 이와 같이 자동 생성된 퍼블릭 서브넷의 라우트 테이블 규칙들을 살펴보았을 때, 첫 번째 VPC(10.255.0.0/24) 두 번째 VPC(10.255.1.0/24)와 통신하는 것은 당연히 불가능해보입니다. 뒤에서 살펴보겠지만 두 VPC 간에 통신을 하려면 라우트 테이블에 새로운 규칙을 추가해주어야합니다.

기본 시큐리티 그룹(default Security Group)

두 번째로 살펴볼 리소스는 시큐리티 그룹입니다.* 이 역시 VPC가 생성될 때 함께 생성됩니다.

* VPC 콘솔의 시큐리티 그룹은 EC2 콘솔에서 확인할 수 있는 시큐리티 그룹과 같은 리소스입니다.

기본 시큐리티 그룹의 인바운드 규칙
기본 시큐리티 그룹의 인바운드 규칙

인바운드 룰Inbound Rules에 한 가지 규칙이 등록되어있습니다. ‘sg-9fdbd9e0으로부터 들어오는 모든 트래픽을 허용한다는 규칙’입니다. 자세히 살펴보면 sg-9fdbd9e0은 바로 이 시큐리티 그룹의 이름이라는 것을 알 수 있습니다. 이 규칙은 ‘이 시큐리티 그룹을 가진 리소스들 간의 통신을 허용한다’는 의미입니다. VPC 내부에서만 통신을 허용하는 경우 기본적으로 각 리소스에 이 시큐리티 그룹을 등록해주면 됩니다.

시큐리티 그룹은 기본적으로 특정 VPC에 종속되어 있으며, 같은 VPC의 시큐리티 그룹만을 참조할 수 있습니다. 하지만 피어링 연결을 사용하면 다른 VPC의 시큐리티 그룹을 참조하는 것이 가능해집니다. 라우트 테이블과 마찬가지로 뒤에서 다시 살펴보도록 하겠습니다.

같은 VPC 내에서의 통신

먼저 같은 VPC 내에서 리소스 간에 내부 네트워크를 통한 통신이 가능한지 확인해보겠습니다. 이를 위해 먼저 peering_test_1에 두 개의 인스터스를 생성합니다.

아마존 네트워크 외부에서 SSH 접속을 위한 시큐리티 그룹 생성

인스턴스를 생성하기에 앞서 먼저 외부에서 인스턴스에 SSH 접속을 허용하는 시큐리티 그룹을 만들어두겠습니다.

EC2 관리 콘솔 페이지로 이동합니다. 왼쪽 메뉴에서 시큐리티 그룹 목록Security Groups을 선택하고 시큐리티 그룹 생성Create Security Group 버튼을 클릭합니다.

ssh 접속을 위한 시큐리티 그룹 생성
ssh 접속을 위한 시큐리티 그룹 생성

인바운드Inbound 탭에 22번 포트(SSH), 0.0.0.0/0 규칙을 추가하고 생성Create합니다. 이 시큐리티 그룹을 인스턴스에 추가하고 퍼블릭 IP를 인스턴스에 할당하면 외부에서 SSH로 인스턴스에 접속하는 것이 가능해집니다.

인스턴스 생성

인스턴스를 생성하기 위해 EC2 관리 콘솔 페이지로 이동합니다. 관리 페이지에서 인스턴스 실행Launch Instances 버튼을 클릭합니다.

AWS의 ECS 대시보드
AWS의 ECS 대시보드

웹 콘솔에서 인스턴스를 생성하는 과정은 다음과 같이 총 7단계로 구성되어있습니다.

  1. AMI 선택Choose AMI
  2. 인스턴스 타입 선택Choose Instance Type
  3. 인스턴스 설정Configure Instance
  4. 스토리지 추가Add Storage
  5. 태그 추가Add Tags
  6. 시큐리티 그룹 설정Configure Security Group
  7. 리뷰Review

1단계에서 AMI는 Amazon Linux로 선택합니다. 2단계에서 인스턴스 타입은 t2.nano*를 선택합니다. 가장 중요한 부분은 3단계 인스턴스 설정입니다.

* 여기서는 가장 작은 인스턴스 타입인 t2.nano를 선택했지만, 프리 티어 기간 중에 무료로 사용할 수 있는 인스턴스 타입은 t2.micro입니다. 프리 티어를 이용하는 경우 t2.micro를 선택합니다.

인스턴스 생성 3단계: 인스턴스 상세 설정
인스턴스 생성 3단계: 인스턴스 상세 설정

인스턴스 개수Number of instances는 2로 설정합니다. 네트워크Network(VPC)와 서브넷Subnet을 앞서 만든 peering_test_1peering_test_1_public으로 설정합니다. 인스턴스에 아마존 외부에서 접속해야하므로 퍼블릭 IP 자동 할당Auto-assign Public IP활성Enable으로 설정합니다.

4단계와 5단계는 기본 설정을 사용합니다.

6단계: 시큐리티 그룹 설정
6단계: 시큐리티 그룹 설정

6단계에서는 시큐리티 그룹Security Group을 선택합니다. 이미 생성된 시큐리티 그룹 선택Select an existing security group을 체크하고, default 그룹과 public_access_by_ssh을 추가합니다

마지막으로 화면 아래의 리뷰 및 실행Review and Launch를 클릭합니다. 마지막으로 인스턴스에 접속할 SSH Key를 선택합니다.*

아직 SSH Key가 없다면 새로운 키 페어 생성*Create a new key pair를 선택해 웹 콘솔에서 키를 바로 생성하는 것도 가능합니다.

인스턴스 목록에서 추가된 인스턴스를 확인해봅니다.

새롭게 생성된 2개의 인스턴스를 목록에서 확인할 수 있습니다
새롭게 생성된 2개의 인스턴스를 목록에서 확인할 수 있습니다

EC2 인스턴스 2대가 실행중인 것을 알 수 있습니다. 각각의 인스턴스에 IPv4 퍼블릭 IPIPv4 Public IP프라이빗 IP 주소Private IP Address가 할당된 것을 확인할 수 있습니다. 인스턴스 초기화에는 몇 분 정도 시간이 걸릴 수 있습니다.

두 인스턴스의 퍼블릭 IP(DNS)와 프라이빗 IP(DNS)를 확인합니다. 각각의 인스턴스를 선택해서 확인할 수 있습니다. 아래는 예제이며, IP와 DNS 값은 생성 후 직접 확인해야합니다.

인스턴스 접속

SSH로 첫 번째 인스턴스에 접속해봅니다.*

* ssh 접속 시 -A 옵션을 사용합니다. 이 옵션은 ForwardAgent를 활성화해줍니다. 이 옵션을 통해 로컬 머신의 키를, SSH로 접속한 머신에서 다시 다른 머신에 접속할 때 인증키로 사용하는 게 가능해집니다. 정상적으로 작동하지 않는 경우 로컬 머신에서 인증에서 사용하는 키를 미리 ssh-add <KEY_PATH> 명령어로 등록하고 ssh-add -l 명령어로 등록되었는지 확인해봅니다.

$ ssh -A ec2-user@52.27.4.114

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
No packages needed for security; 3 packages available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-255-0-126 ~]$

이 안에서 두 번째 인스턴스에 각각 퍼블릭 IP와 프라이빗 IP로 ping을 해봅니다.

[ec2-user@ip-10-255-0-126 ~]$ ping 34.223.249.210
PING 34.223.249.210 (34.223.249.210) 56(84) bytes of data.
^C

[ec2-user@ip-10-255-0-126 ~]$ ping 10.255.0.96
PING 10.255.0.96 (10.255.0.96) 56(84) bytes of data.
64 bytes from 10.255.0.96: icmp_seq=1 ttl=255 time=0.591 ms
64 bytes from 10.255.0.96: icmp_seq=2 ttl=255 time=0.509 ms
64 bytes from 10.255.0.96: icmp_seq=3 ttl=255 time=0.489 ms
^C
--- 10.255.0.96 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.489/0.529/0.591/0.051 ms

퍼블릭 IP로 호출하는 경우 응답하지 않습니다. 이는 시큐리티 그룹에서 외부에 대해 SSH만 열어주고 핑 요청을 주고받는 ICMP를 열어주지 않았기 때문입니다. 반면에 프라이빗 IP로는 정상적으로 핑이 오는 것을 알 수 있습니다. 이는 default 시큐리티 그룹을 통해서 default 시큐리티 그룹을 가진 인스턴스 간에는 VPC 내에서 모든 통신이 허용되어있기 때문입니다.

첫 번째 인스턴스에서 두 번째 인스턴스로 SSH를 통해 접속해보겠습니다. (모든 IP에 대한) SSH 접근은 시큐리티 그룹에서 허용되어있기 때문에 퍼블릭 IP로 접속하는 것이 가능합니다.

[ec2-user@ip-10-255-0-126 ~]$ ssh ec2-user@34.223.249.210

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
No packages needed for security; 3 packages available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-255-0-96 ~]$

물론 프라이빗 IP로도 접속할 수 있습니다.

[ec2-user@ip-10-255-0-126 ~]$ ssh ec2-user@10.255.0.96
...
[ec2-user@ip-10-255-0-96 ~]$
노트
IP 대신 DNS를 사용하면 좋은 점

VPC 외부에서는 퍼블릭 IP를 통해서만 인스턴스에 접근할 수 있습니다. 하지만 VPC 내부에서는 프라이빗 IP로 접속하는 것이 유리합니다. IP를 사용하는 경우, 같은 인스턴스에 대한 접근을 할 때 퍼블릭 IP와 프라이빗 IP를 구분해서 사용해야합니다.

하지만 퍼블릭 DNS를 사용하면 VPC 외부와 내부에서 조회되는 IP가 자동적으로 달라집니다. 실제로 확인해보겠습니다. 두 번째 인스턴스의 퍼블릭 DNS를 VPC 외부와 내부에서 nslookup을 사용해 조회해보겠습니다.

## VPC 외부에서 두 번째 인스턴스의 퍼블릭 DNS 조회
$ nslookup ec2-34-223-249-210.us-west-2.compute.amazonaws.com
Server:         168.126.63.1
Address:        168.126.63.1#53

Non-authoritative answer:
Name:   ec2-34-223-249-210.us-west-2.compute.amazonaws.com
Address: 34.223.249.210

$ ssh ec2-user@52.27.4.114

## VPC 내부에서 두 번째 인스턴스의 퍼블릭 DNS 조회
[ec2-user@ip-10-255-0-126 ~]$ nslookup ec2-34-223-249-210.us-west-2.compute.amazonaws.com
Server:         10.255.0.2
Address:        10.255.0.2#53

Non-authoritative answer:
Name:   ec2-34-223-249-210.us-west-2.compute.amazonaws.com
Address: 10.255.0.96

VPC 외부에서는 퍼블릭 IP를, 내부에서는 프라이빗 IP를 반환하는 것을 확인할 수 있습니다.

여기까지 같은 VPC 안에 속한 인스턴스 간의 통신에 대해서 살펴보았습니다. 이를 위해 인스턴스를 2대 생성했지만, 다른 VPC의 인스턴스와 통신을 테스트하기 위해서는 인스턴스는 한 대로도 충분합니다. 이 시점에서 첫 번째 VPC에서 실행한 인스턴스 중 1대는 종료해도 무방합니다.

두 번째 VPC

이번에는 두 번째 VPC를 생성하고, 두 VPC에 속한 각각의 인스턴스가 통신 가능하도록 구성해보도록 하겠습니다.

VPC 피어링을 통한 두 VPC의 EC2인스턴스 간의 통신
VPC 피어링을 통한 두 VPC의 EC2인스턴스 간의 통신

VPC 마법사로 두 번째 VPC 생성

두 번째 VPC도 VPC 마법사를 사용해서 같은 방법으로 생성합니다. 생성 과정에서 입력해야하는 속성들은 다음과 같습니다.

두 번째 VPC가 생성된 것을 확인하고, 인스턴스 생성 단계로 넘어갑니다.

두 번째 VPC에 인스턴스 생성

첫 번째 VPC에서 인스턴스를 생성한 것과 마찬가지로 EC2 관리 콘솔 페이지로 이동해 인스턴스 실행Launch Instances 버튼을 클릭합니다.

1단계에서 AMI는 Amazon Linux, 2단계에서 인스턴스 타입은 t2.nano를 선택합니다. 3단계는 다음과 같이 설정합니다.

인스턴스 생성 3단계
인스턴스 생성 3단계

인스턴스 개수Number of instances는 1로 설정합니다. 네트워크Network(VPC)와 서브넷Subnet을 앞서 만든 peering_test_2peering_test_2_public으로 설정합니다. 퍼블릭 IP 자동 할당Auto-assign Public IP비활성Disable으로 설정합니다. 이렇게 설정하면 이 인스턴스로 VPC 외부에서 직접 접근하는 것이 불가능해집니다. 직접 접속하는 대신 VPC 피어링을 만들고 첫 번째 VPC에서 생성한 인스턴스를 통해 접속해보겠습니다.

4단계와 5단계는 기본 설정을 사용합니다. 6단계에서는 생성된 시큐리티 그룹 선택Select an existing security group을 체크하고, default 그룹을 선택합니다. 최종적으로 첫 번째 VPC와 같은 키를 지정하고 인스턴스를 생성합니다.

인스턴스 목록에서 추가된 인스턴스를 확인해봅니다.

2번째 VPC에 생성된 인스턴스
2번째 VPC에 생성된 인스턴스

이 인스턴스는 두 번째 VPC에 생성되며 프라이빗 IP만을 가집니다. 따라서 외부에서 이 인스턴스로 직접 접속할 수 있는 방법은 없습니다.

다른 VPC 간의 통신

VPC 간의 통신을 테스트하기 위한 기본적인 준비를 마쳤습니다. 서로 통신이 불가능하다는 것은 첫 번째 VPC의 인스턴스 A에서 두 번째 VPC의 인스턴스 C에 직접 요청을 해봄으로써 확인할 수 있습니다. (직접 확인하지 않더라도 라우트 테이블이나 시큐리티 그룹의 규칙을 생각해보면 접속이 불가능하다는 것을 논리적으로 유추해볼 수 있습니다)

두 인스턴스 간에 통신이 가능하도록 만들기 위해서는 피어링 연결을 생성해주어야합니다. 하지만 이것만으로는 부족합니다. 이 피어링 연결에 대한 규칙을 각 서브넷의 라우트 테이블에 추가해주어야합니다. 또한 시큐리티 그룹을 통해서 다른 VPC의 IP 대역에 대한 접근을 허용해주어야합니다. 한 단계 씩 진행해보도록 하겠습니다.

피어링 연결(Peering Connection)

피어링 연결을 생성하기 위해서는 두 개의 VPC가 필요합니다. 이 때 연결을 요청하는 VPC를 요청자Requester라고 하며, 연결을 요청 받는 VPC를 수락자Accepter라고 합니다. 요청자 VPC는 자신의 계정에서 현재 리전의 VPC 중 하나를 선택할 수 있습니다. 반면에 수락자 VPC는 현재 자신의 계정에 속한 현재 리전의 VPC 뿐만 아니라 다른 리전의 VPC나 다른 계정의 VPC를 선택하는 것도 가능합니다.

1 요청자 VPC에서 수락자 VPC로 요청을 하면, 2 요청을 받은 수락자 VPC에서 연결을 수락해야만 실제로 연결이 이루어집니다. 같은 계정, 같은 리전의 VPC 간에 연결을 생성할 때는 요청자/수락자 순서가 크게 중요하진 않습니다. 하지만 이 경우에도 요청을 받은 VPC에서 요청을 수락해야만 연결이 이루어집니다.

그럼 실제로 피어링 연결을 생성해보겠습니다. VPC 콘솔로 이동합니다. 사이드 메뉴에서 피어링 연결Peering Connections를 선택하고, 피어링 연결 생성Create Peering Connection 버튼을 클릭합니다.

VPC 피어링 연결 목록
VPC 피어링 연결 목록

피어링 연결을 생성하는 단계로 넘어갑니다. 다음과 같이 설정합니다.

VPC 피어링 생성 1단계
VPC 피어링 생성 1단계

여기서는 이름으로 test1_to_test2으로 붙여주었습니다. 다음으로 연결하고자 하는 두 개의 VPC를 선택해야합니다. 요청자에는 peering_test_1, VPC 수락자에는 현재 계정My account, 현재 리전This region을 선택하고 peering_test_2 VPC를 지정합니다. 앞서 설명했듯이 같은 계정, 같은 리전의 VPC 끼리 피어링 연결을 만들 때는 요청자, 수락자 순서가 바뀌어도 무방합니다.

1단계: VPC 피어링 요청자와 수락자와 지정
1단계: VPC 피어링 요청자와 수락자와 지정

아래에 있는 피어링 연결 생성create peering connection을 클릭해서 피어링 연결을 생성합니다.

VPC 피어링 생성 완료
VPC 피어링 생성 완료

피어링 연결이 정상적으로 생성된 것을 확인할 수 있습니다. 하지만 수락자 VPC에서 이 연결을 수락하기 전까지는 이를 사용할 수 없습니다. 피어링 연결 목록에서 수락 대기Pending Acceptance 상태를 확인할 수 있습니다.

수락 대기중인 VPC 피어링
수락 대기중인 VPC 피어링

피어링 연결을 선택한 상태에서 목록 위 쪽에 있는 액션Actions를 클릭합니다. 요청 수락Accept Request을 선택해 연결 요청을 수락합니다.

수락 대기중인 VPC 피어링의 요청을 수락합니다
수락 대기중인 VPC 피어링의 요청을 수락합니다

피어링 연결 요청을 수락하면 곧바로 활성Active 상태로 바뀌는 것을 확인할 수 있습니다.*

* VPC 피어링의 모든 상태에 대해서는 VPC 피어링 연결 수명 주기를 참고하시기 바랍니다.

활성화된 VPC 피어링
활성화된 VPC 피어링

피어링 연결 ID pcx-8f212ee6를 기억해둡니다. 다음 단계에서는 라우트 테이블을 수정해 이 피어링 연결을 사용해보겠습니다.

피어링 연결을 라우트 테이블에 추가하기

두 VPC를 연결하는 피어링 연결 리소스를 만들었지만, 이것만으로 두 VPC 간에 통신이 가능한 것은 아닙니다. 각각의 서브넷에 연결된 라우트 테이블에, 상대 VPC에 접근할 수 있도록 라우트 규칙을 추가해주어야만 합니다. 상대 VPC(혹은 서브넷)의 CIDR에 대한 타겟에 앞서 생성한 피어링 연결로 지정해주면 됩니다.

서브넷 목록Subnets에서 각각의 서브넷에 연결된 라우트 테이블Route Table을 확인할 수 있습니다.

서브넷 목록
서브넷 목록

먼저 rtb-64b5d11c부터 수정합니다. 라우트 테이블 목록Route Tables에서 rtb-64b5d11c를 선택합니다. 라우트 규칙Routes 탭에서 현재 정의되어있는 규칙들을 확인할 수 있습니다.

첫 번째 VPC의 라우트 테이블을 수정합니다
첫 번째 VPC의 라우트 테이블을 수정합니다

수정Edit을 클릭하면 규칙을 편집할 수 있는 상태가 됩니다.

첫 번째 VPC에서 두 번째 VPC에 연결하기 위한 규칙을 추가합니다
첫 번째 VPC에서 두 번째 VPC에 연결하기 위한 규칙을 추가합니다

새로운 규칙 추가Add another Route를 클릭합니다. 다음과 같이 새로운 규칙을 추가합니다.

저장Save을 클릭합니다. rtb-8181e5f9에도 같은 방법으로 새로운 라우트 규칙을 추가해줍니다.

이 규칙들을 통해서 peering_test_1_public 서브넷의 리소스와 peering_test_2_public 서브넷의 리소스가 통신하는 것이 가능해집니다.

시큐리티 그룹에서 상대 VPC의 접근을 허용

VPC 피어링과 라우트 테이블을 설정했지만, 아직 두 VPC의 리소스 간에 통신을 하려면 할 일이 하나 남아있습니다. 바로 시큐리티 그룹에서 상대 VPC의 접근을 허용해주는 일입니다. 네트워크가 연결되어있어도 시큐리티 그룹에서 통신을 허용해주지 않으면 리소스에 접근하는 것은 불가능합니다.

먼저 VPC 콘솔의 시큐리티 그룹 목록Security Groups에서 두 VPC의 default 시큐리티 그룹을 확인합니다. peering_test_1default 시큐리티 그룹 ID는 sg-9fdbd9e0이고, peering_test_2sg-ea848695입니다.

첫 번째 VPC의 기본 시큐리티 그룹
첫 번째 VPC의 기본 시큐리티 그룹

이미 앞서 디폴트 시큐리티 그룹의 인바운드 룰에서 살펴보았습니다. 이 규칙의 의미는 peering_test_1 VPC 내에서 default 시큐리티 그룹을 가진 자원 간의 통신을 허용한다는 의미입니다. peering_test_2도 마찬가지입니다.

원칙적으로 인바운드 룰의 소스Source에는 같은 VPC에 속한 시큐리티 그룹만 등록할 수 있습니다. 하지만 피어링 연결을 생성하고 나면 상대 VPC의 시큐리티 그룹을 등록하는 것이 가능해집니다. * 예를 들어 peering_test_1default 시큐리티 그룹(sg-9fdbd9e0)에서 peering_test_2default 시큐리티 그룹(sg-ea848695)의 모든 트래픽을 허용하는 것이 가능합니다.

VPC 연결이 생성되지 않았을 때, 다른 VPC의 시큐리티 그룹을 소스로 강제로 추가하려고 하면 다음과 같은 에러 메시지를 볼 수 있습니다: You have specified two resources that belong to different networks.*

하지만 피어링 연결이 생성된 상대 VPC의 시큐리티 그룹을 지정하면 더 이상 이 에러가 발생하지 않습니다.

이러한 규칙을 가진 별도의 시큐리티 그룹을 만드는 것도 가능하지만 여기서는 편의상 default에 직접 해당하는 규칙들을 추가합니다. 먼저 peering_test_1default 시큐리티 그룹의 인바운드 룰을 다음과 같이 수정합니다.

두 번째 VPC의 기본 시큐리티 그룹을 허용하는 규칙을 추가합니다
두 번째 VPC의 기본 시큐리티 그룹을 허용하는 규칙을 추가합니다

peering_test_2default 그룹에도 인바운드 룰에 peering_test_1default 그룹에 대해서 모든 트래픽을 허용하는 규칙을 추가합니다.

이걸로 VPC 피어링을 통해 두 네트워크 간에 통신을 하기 위한 준비가 모두 끝났습니다. 이제 인스턴스에서 직접 연결이 가능한지 확인해보도록 하죠.

피어링 연결을 통한 두 VPC 간의 통신

앞서 생성한 두 VPC의 인스턴스들입니다.* i-0cc716f67bb42e0d2peering_test_1 VPC에 생성되어 있는 인스턴스로 Public IP를 가지고 있습니다. i-0cc716f67bb42e0d2peering_test_2 VPC에 생성되어있는 인스턴스로 Private IP만을 가지고 있습니다.

* 튜토리얼 작성중에 인스턴스를 재생성해서 초반부에 peering_test_1에 생성했던 인스턴스의 ID와 IP가 다릅니다. 직접 생성한 인스턴스의 ID나 IP와도 다르므로 항상 직접 생성한 리소스의 값을 기준으로 진행하시기 바랍니다.

첫 번째 VPC에 생성된 인스턴스(퍼블릭 IP 할당)와 두 번째 VPC에 생성된 인스턴스
첫 번째 VPC에 생성된 인스턴스(퍼블릭 IP 할당)와 두 번째 VPC에 생성된 인스턴스

여기서는 먼저 SSH로 i-0cc716f67bb42e0d2의 Public IP에 접속한 다음, 이 인스턴스에서 다시 SSH로 i-0cc716f67bb42e0d2의 Private IP에 접속해보겠습니다.

먼저 SSH로 i-0cc716f67bb42e0d2의 Pubilc IP 54.201.130.60에 접속합니다.

# 인터넷을 통해 peering_test_1 VPC의 인스턴스에 ssh 접속
$ ssh -A ec2-user@54.201.130.60

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
2 package(s) needed for security, out of 5 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-255-0-38 ~]

정상적으로 접속에 성공한 것을 확인할 수 있습니다. 여기서 다시 i-0cc716f67bb42e0d2의 Private IP 10.255.1.37에 접속해보겠습니다.

# peering_test_1 VPC의 인스턴스에서 peering_test_2 VPC에 ssh 접속
[ec2-user@ip-10-255-0-38 ~]$ ssh 10.255.1.37

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
[ec2-user@ip-10-255-1-37 ~]$

다른 VPC의 인스턴스에 정상적으로 접근 가능한 것을 확인할 수 있습니다. traceroute 명령어로 다른 경로를 거치지 않고, 상대 인스턴스에 곧바로 연결되는 것을 확인할 수 있습니다.

# test_peering_1 -> test_peering_2
[ec2-user@ip-10-255-0-38 ~]$ traceroute 10.255.1.37
traceroute to 10.255.1.37 (10.255.1.37), 30 hops max, 60 byte packets
 1  ip-10-255-1-37.us-west-2.compute.internal (10.255.1.37)  1.243 ms  1.235 ms  1.212 ms

# test_peering_2 -> test_peering_1
[ec2-user@ip-10-255-1-37 ~]$ traceroute 10.255.0.38
traceroute to 10.255.0.38 (10.255.0.38), 30 hops max, 60 byte packets
 1  ip-10-255-0-38.us-west-2.compute.internal (10.255.0.38)  1.081 ms  1.051 ms  1.062 ms

두 VPC 간의 통신이 정상적으로 이루어지는 것을 확인해보았습니다. 사용하지 않는 리소스들은 삭제하여 추가적인 요금이 발생하지 않도록 합니다.

마치며

여기까지 VPC 피어링을 생성하고 설정하는 방법을 알아보았습니다. VPC를 사용하면 격리된 네트워크 환경을 만들 수 있고, VPC 피어링을 사용하면 격리된 네트워크 간의 연결 통로를 생성할 수 있습니다. VPC 피어링은 같은 계정의 VPC뿐만 아니라 다른 계정의 VPC에 대한 연결도 가능하게 해줍니다. 2018년 2월에는 AWS 백본을 기본으로 통신하는 멀티 리전 간 VPC 피어링 지원을 발표하기도 했습니다. VPC 연결을 지원하지 않는 경우에는 VPN 연결을 사용할 수 있습니다.

하지만 이러한 네트워크를 연결하는 기능이 만능은 아닙니다. IPv4의 경우 VPC 간에 CIDR이 겹치는 경우 피어링을 생성할 수 없습니다. 또한 VPC의 기본적인 기능인 네트워크를 격리하는 데 있다는 걸 생각해보면, 무분별한 피어링 생성은 VPC 본래의 의미를 퇴색시킬 수 있습니다. 따라서 가능하면 일찍부터 VPC 설계에 대해서 고민하는 것이 좋고 VPC 피어링을 사용하는 경우 정확히 필요한 범위만을 열어줄 필요가 있습니다.

더 읽을거리