들어가며

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

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

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

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

첫 번째 VPC

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

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

VPC 마법사로 VPC 생성

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

• VPC: peering_test_1, 10.255.0.0/24
  • Public Subnet: peering_test_1_public, 10.255.0.0/25

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

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

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

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

• IPv4 CIDR block: 10.255.0.0/24
• VPC Name: peering_test_1
• Public subnet’s IPv4 CIDR: 10.255.0.0/25
• Subnet name: peering_test_1_public

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

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

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

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

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

• 10.255.0.0/24 -> local
• 0.0.0.0/0 -> igw-94d344f2*

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

두 번째 규칙은 VPC 내부의 CIDR 접근 이외의 모든 IP에 적용되는 규칙으로, 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가 생성될 때 함께 생성됩니다.

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

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

같은 VPC 내에서의 통신

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

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

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

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

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

인스턴스 생성

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

웹 콘솔에서 인스턴스를 생성하는 과정은 다음과 같이 총 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단계 인스턴스 설정입니다.

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

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

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

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

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

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

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

• 인스턴스 A
  • 퍼블릭 IP: 52.27.4.114(ec2-52-27-4-114.us-west-2.compute.amazonaws.com)
  • 프라이빗 IP: 10.255.0.126(ip-10-255-0-126.us-west-2.compute.internal)
• 인스턴스 B
  • 퍼블릭 IP: 34.223.249.210(ec2-34-223-249-210.us-west-2.compute.amazonaws.com)
  • 프라이빗 IP: 10.255.0.96(ip-10-255-0-96.us-west-2.compute.internal)

인스턴스 접속

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

$ 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 ~]$

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

두 번째 VPC

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

VPC 마법사로 두 번째 VPC 생성

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

• IPv4 CIDR block: 10.255.1.0/24
• VPC Name: peering_test_2
• Public subnet’s IPv4 CIDR: 10.255.1.0/25
• Subnet name: peering_test_2_public

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

두 번째 VPC에 인스턴스 생성

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

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

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

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

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

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

• 인스턴스 C
  • 프라이빗 IP: 10.255.1.37(ip-10-255-1-37.us-west-2.compute.internal)

다른 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} 버튼을 클릭합니다.

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

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

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

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

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

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

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

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

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

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

• peering_test_1(10.255.0.0/24)의 서브넷 peering_test_1_public(10.255.0.0/25)
  • 라우트 테이블: rtb-64b5d11c
• peering_test_2(10.255.1.0/24)의 서브넷 peering_test_2_public(10.255.1.0/25)
  • 라우트 테이블: rtb-8181e5f9

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

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

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

• rtb-64b5d11c(peering_test_1_public의 라우트 테이블)
  • 목적지^Destination: 10.255.1.0/24(peering_test_2의 CIDR)
  • 타겟^Target: pcx-8f212ee6(peering_test_1과 peering_test_2의 피어링 연결)

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

• rtb-8181e5f9(peering_test_2_public의 라우트 테이블)
  • 목적지^Destination: 10.255.0.0/24(peering_test_1의 CIDR)
  • 타겟^Target: pcx-8f212ee6(peering_test_1과 peering_test_2의 피어링 연결)

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

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

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

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

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

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

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

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

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

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

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

여기서는 먼저 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 피어링을 사용하는 경우 정확히 필요한 범위만을 열어줄 필요가 있습니다.

더 읽을거리

• AWS VPC basic – asbubam’s blog
• VPC 피어링이란? - Amazon Virtual Private Cloud