AWS VPC Peering

Contents

AWS 상에서 서비스를 구성하다보면, 여러 개의 VPC로 나뉘는 경우가 있다. 그러다 보면 같은 계정의 같은 리전에 있는 다른 VPC 혹은 다른 리전에 있는 VPC와 통신해야 하는 경우가 생긴다. 아예 다른 계정의 VPC와 통신을 해야 할 수도 있다. IGW(인터넷게이트웨이)를 통해서 통신을 할 수 있겠으나 인터넷에 자원이 노출된다는 단점이 있다.

통신해야 할 자원이 프라이빗 서브넷(Private subnet)에 있다면, 통신하기가 더 힘들어진다. VPN을 사용하는 방법도 있기는 하지만 번거로울 뿐더러 추가적인 비용이 들어간다.

AWS VPC Peering를 이용하면 퍼블릭네트워크나 VPN을 이용하지 않고 VPC끼리 직접 트래픽을 라우팅 할 수 있다. 예컨데 아래와 같은 구성이 가능하다.

데이터베이스를 이용하는 인터넷 애플리케이션이다. 데이터베이스의 경우 프라이빗 서브넷에 구성을 해야 할테고, 하나의 VPC에 데이터베이스만을 위한 프라이빗 서브넷을 구성할 수 있을 것이다.

반면, 데이터베이스를 전개할 VPC를 아예 분리해버리는 방법도 있다. 요즘에 내가 사용하는 방법이다. 이렇게 하면 데이터베이스를 위한 독립된 (보안을 포함한)인프라 정책을 수립할 수 있다.

다른 조직에서 데이터베이스에 접근해야 할 경우 아래와 같이 구성 할 수도 있다.

MySQL 데이터베이스를 위한 별도의 DB VPC를 구성했다. DB VPC는 프라이빗 서브넷으로만 구성해서, 인터넷으로 부터 완전히 격리된다. 애플리케이션과는 vpc peering으로 연결해서 사용하게 한다.

그리고 데이터분석 팀에서 BI(Business Intelligence) 솔류션 개발을 위해서 MySQL 데이터베이스에 접근해야 겠다는 요구사항이 전달된다. 데이터분석팀은 자신들을 위한 별도의 VPC를 이미가지고 있다. vpc peering으로 두개를 연결하면, 네트워크 구성변경없이 라우팅 설정만하는 것으로 MySQL에 접근 할 수 있다.

• 리소스에 대한 모든 권한을 제공하기 위한 두 개 이상의 VPC 피어링
• 중앙 집중식 리소스에 대한 액세스
• ClassicLink와의 피어링

ClassicLink를 사용해서 VPC에 연결된 EC2-Classic 인스턴스가 있다고 가정해보자. VPC 피어링을 이용해서 이 VPC에 연결해서 EC2-Classic 인스턴스에 접근 할 수 있다. 이렇게 하면, ClassicLink의 Private IP를 이용해서 EC2-Classic 인스턴스와 통신 할 수 있다.

지금 10.20.0.0/16, 10.1.0.0/16 두 개의 VPC를 가지고 있다. 각 VPC에는 EC2 인스턴스가 있다. 이들 인스턴스를 VPC Peering를 통해서 연결하려 한다. 테스트 환경은 아래와 같다.

동일한 계정의 같은 리전에 있는 VPC 끼리 테스트를 진행한다.

• VPC-A : 10.1.0.0/16
• VPC-B : 10.2.0.0/16

2개의 VPC를 만들고 EC2 인스턴스를 실행했다. EC2 인스턴스의 정보는 아래와 같다.

• VPC-A에 위치한 인스턴스 : 10.1.1.12
• VPC-B에 위치한 인스턴스 : 10.2.1.234

VPC의 라우팅 테이블은 아래와 같다.

VPC-A의 Subnet

Destination	Target
10.1.0.0/16	local
0.0.0.0/0	igw-xxxxx

VPC-B의 Subnet

Destination	Target
10.2.0.0/16	local
0.0.0.0/0	igw-xxxxx

VPC Peering는 요청자(Requester)와 수락자(Accepter)가 참여한다.

• 요청자 : VPC 연결을 요청하는 측이다.
• 수락자 : VPC 자원을 제공하는 측이다.

요청자가 수락자에게 VPC 요청을 보내고, 수락자가 허가하면 연결이 마무리된다. 연결요청과 수락에 사용하는 키는 VPC ARN이다.

연결의 요청에서 부터 연결삭제까지의 수명주기는 아래와 같다.

• Initiating-request: VPC peering 요청이 시작된다. 실패하지 않을 경우 pending-acceptance 즉, 수락자가 요청을 수락 하기를 기다린다.
• Failed : Peering 연결 요청이 실패한다. 실패한 peering 연결요청은 2시간 동안 요청자에게 보이는(visible)상태로 남아 있으며, 이 시간동안에는 peering 요청의 수락, 거부, 삭제를 할 수 없게 된다.
• Pending-acceptance : VPC peering 수락자에게 요청이 보인다. 수락자가 연결을 허락(accept)하기 전까지 이 상태로 남는다. 최대 7일까지 이 상태로 남을 수 있으며, 7일이 지나면 요청이 만료된다.
• Expired : Peering 요청이 만료됐다. 만료된 요청은 2일 동안 요청자와 수락자 모두에게 보이는 상태로 남는다.
• Rejected : 수락자가 pending-acceptance 상태의 요청을 거부했다. 거부된 요청은 2시간동안 표시된다.
• Provisioning : VPC peering 요청이 수락됐다. 수락하면 몇 분의 시간이 지난 후 active 상태가 된다.
• Active : VPC peering이 활성화 됐으며, 통신을 할 수 있다.
• Deleting : VPC peering의 한쪽 소유자가 VPC peering 삭제 요청을 전달 했다. 요청을 전달 한 상태로 아직 삭제된건 아니다. 같은 계정에서는 deleting 없이 바로 deleted 되는 것으로 확인했다.(같은 계정에서 테스트로 즉시 Deleted 상태가 되는 건 확인했으나, 다른 계정에서는 테스트를 아직 못해봐서 Deleting 상태가 되는건지는 확인하지 못했다.)
• Deleted : VPC peering 연결이 삭제된다. 이 상태에서는 VPC 피어링 연결을 수락하거나 거부 할 수 없다. 삭제된 peering은 2시간 동안 연결을 삭제한 쪽에서 볼 수 있고, 다른 쪽에서는 2일 동안 보이는 상태로 남는다.

AWS 웹 콘솔에서 VPC Peering 요청을 보낼 수 있다. VPC-A(10.1.0.0/16)에서 VPC-B(10.2.0.0/16)으로 VPC peering 연결 요청을 전송하기로 했다.

VPC Dashboard > Peering Connections 에서 Create Peering Connection를 선택한다.

• peering connection name tag : Peering 연결 이름
• Select a local VPC to peer with : 요청자의 VPC 정보를 입력한다. VPC-A 를 선택했다.
• Select another VPC to peer with : 수락자의 VPC 정보를 입력한다. VPC-B를 선택했다.

위 내용을 기입하고 Create Peering Connection을 클릭하면 Peering 연결 요청이 만들어진다.

Pending Acceptance인 것을 확인 할 수 있다. aws cli 툴로 자세히 살표보자

Accept Request를 수행하면, VPC peering 연결이 만들어진다.

Vpc peering 연결이 만들어졌다. 이제 라우팅 테이블을 수정해서, Vpc peering connection(pcx-01bfaf57ab86dad52)으로 트래픽이 흐르도록 해야 한다.

VPC-A의 라우팅 테이블을 아래와 같이 수정한다.

Destination	Target
10.1.0.0/16	local
0.0.0.0/0	igw-xxxxx
10.2.0.0/16	pcx-01bfaf57ab86dad52

VPC-B(10.2.0.0/16)로 향하는 패킷은 vpc peering 연결로 흐르도록한다.

VPC-B의 라우팅 테이블을 아래와 같이 수정한다.

Destination	Target
10.2.0.0/16	local
0.0.0.0/0	igw-xxxxx
10.1.0.0/16	pcx-01bfaf57ab86dad52

VPC-A(10.1.0.0/16)로 향하는 패킷은 vpc peering 연결로 흐르도록한다.

VPC-A와 VPC-B에 있는 EC2 인스턴스에서 연결 테스트를 했다.

사설 IP로 연결되는게 확인되면 성공이다. 만약 연결이 안된다면 security group을 확인해보자.

일치하거나 중첩되는 IPv4 CIDR 블록에 대해서는 VPC peering 연결을 만들 수 없다.

VPC에 여러 개의 IPv4 CIDR 블럭이 있는 경우, 중첩되는 CIDR 블록이 있으면 VPC peering를 만들 수 없다.

IPv6를 통한 리전간 VPC peering는 지원하지 않는다.

전이적 피어링은 지원하지 않는다.

• 다른 리전의 VPC에 대해서도 VPC peering 연결을 할 수 있다. 다만 중국리전은 제외다.
• 다른 AWS 계정의 VPC에 VPC peering 연결을 할 수 있다.
• VPC peering 연결에는 인터넷게이트웨이가 필요하지 않다.
• VPC 대역폭은 동일한 VPC 내 인스턴스간 대역폭과 같다.
• 리전간 트래픽의 경우 AEAD 알고리즘을 사용하여 암호화된다.
• 리전간 IPv6 VPC peering은 지원하지 않는다.
• Network Load Balancer, AWS PrivateLink, EBS 등은 VPC 피어링에서 사용 할 수 없다.

• AWS PrivateLink를 이용한 SaaS 개발
• AWS Transit Gateway