[ AWS ] VPC Peering

A VPC - EKS내의 서비스와 B VPC ECS상의 서비스가 통신하기 위한 방법에 대해 설명

VPC(Virtual Private Cloud)의 개념은 클라우드 서비스 제공 업체가 제공하는 가상화된 네트워크 환경으로, 이 환경을 이용하여 자체적으로 격리된 논리적 네트워크를 구성하고 이를 통해 안전하게 컴퓨팅 자원과 데이터를 관리할 수 있습니다.

즉, 일반적으로 서로 다른 VPC는 서로 격리된 네트워크로 통신을 할 수 없습니다.
하지만, 서비스 규모가 커지면서 하나의 서비스를 위해 여러 VPC 네트워크 간 통신이 필요한 경우가 발생할 수 있으며, 문제 상황 처럼 서로 다른 VPC에 존재하는 EKS내 서비스와 ECS상 서비스가 통신이 필요할 수 있습니다.

 

주어진 상황에 따라 일반적인 상황을 설명하자면, A VPC에 EKS가 Private Subnet에 존재하고(EKS내 A서비스), B VPC의 Private Subnet에 ECS가 존재(ECS내 B서비스)한다고 가정하겠습니다. 이 때 기본적으로 A서비스는 B서비스와 다른 격리된 네트워크에 있으므로 서로 인지할 수 없습니다. A는 B VPC에 존재하는 Load Balancer의 Pulic IP로 호출하게 되고, 이 호출은 A VPC의 Public Subnet에 존재하는 NAT를 거쳐, A와 B VPC의 Internet Gateway를 통해 B VPC의 Load Balancer로 전달되게 됩니다. 그 후 LB에 의해 B서버로 해당 호출이 전해지게 됩니다. 이러한 성능/보안적으로 취약한 방식 대신에 사용할 수 있는 방법으로는 VPC Peering, VPN설정, AWS Transit Gateway가 있습니다.

 

이 중 해당 문제에서는 AWS EKS, AWS ECS를 사용하고 있으므로 AWS VPC Peering을 통해 각 서비스가 통신하는 방법에 대해 설명해보도록 하겠습니다.

 

AWS VPC Peering은 비공개적으로 두 VPC간에 트래픽을 라우팅할 수 있도록 해주는 네트워킹 연결입니다. Peering된 VPC내에 존재하는 서비스들은 동일 네트워크에 존재하는 것 처럼 서로 통신할 수 있으며, 같은 AWS 계정뿐만 아니라 서로 다른 계정의 VPC 간 또는 서로 다른 Region의 VPC 간 Peering도 가능합니다. AWS VPC Peering은 게이트웨이나 VPN연결이 아니며, 별도의 물리적 하드웨어에 의존하지 않아, 통신/대역폭 병목에 대한 SPOF(Single Point of Failure)에 대한 문제가 발생하지 않습니다.

 

VPC Peering은 세부적으로 서브넷 간 연결으로 표현할 수 있을 것 같습니다. 더 자세히는 서로 다른 VPC내 서브넷에서 사용하고자 하는 VPC의 CIDR주소(전체 또는 이부)간의 연결이며, 각 라우팅 테이블에서 다른 VPC 서브넷 CIDR을 target address로 작성하고, target을 생성한 VPC Peering connection ID로 설정하면서 통신이 가능하게 됩니다.

 

 

우선, VPC Peering Connection을 생성하는 방법에 대해 설명하겠습니다. (AWS Console)

A VPC가 존재하는 계정으로 접속하여, VPC화면에서 Peering 연결을 생성합니다. 먼저 연결 요청하는 쪽이 VPC Peering 연결 요청자가 되고, VPC 연결 수락자에게 요청을 보내게 됩니다.

요청을 생성할 때, VPC Peering Connection이름을 지정할 수 있으며 아래 정보들을 선택/입력할 수 있습니다.

• VPC 요청자의 연결하고자 하는 VPC ID
• Peering할 다른 VPC 선택 - Account, Region, VPC ID

연결 요청이 생성되면, 수락자가 Peering 연결 탭에서 수락을 해야 Peering 연결 생성이 완료되며, Peering Connection ID가 생성되게 됩니다. 이 후, 요청자와 수락자의 VPC내에서 서로 통신하려는 서브넷의 라우팅 테이블에서 수작업으로 경로를 추가해 주어야 합니다.

A VPC에서 EKS가 존재하는 서브넷의 라우팅 테이블에 새로운 경로를 추가합니다.

해당 경로의 Target Address는 B VPC에서 ECS가 존재하는 서브넷의 CIDR전체 또는 일부이고, Target은 생성한 Peering Conneciton ID가 됩니다. 반대로 B VPC에서 ECS가 존재하는 서븐넷의 라우팅 테이블에는 A VPC에서 EKS가 존재하는 CIDR전체 또는 일부를 라우팅 테이블에 동일하게 추가해주어야 합니다.

 

이로써 각 서브넷에서 생성되는 트래픽은 변경된 라우팅 테이블을 통해 같은 네트워크에 존재하는 서비스 간 통신과 같이 원활한 통신이 가능하게 됩니다. 간략히 VPC Peering연결 단계를 요약해봤습니다.

 

1. VPC Peering 요청자가 VPC Peering 수락자에게 연결 요청
   (VPC Peering 이름 설정 + Peering할 VPC 선택)
2. VPC Peering   수락자가 피어링 연결 탭에서 수락
3. Peering하려는 각 VPC의 서브넷 라우팅 테이블 경로 설정 필요
   VPC Peering 요청자/수락자 모두 서로 서브넷의 라우팅 테이블에서 Peer VPC의 CIDR 주소, Peering ID설정
4. 연결하려는 AWS Resource의 보안 그룹 설정 필요

마지막 단계로, 필요한 경우 A VPC의 EKS와 B VPC의 ECS에 설정된 Security Group에서 Inbound/Outbound Rule로 각 VPC의 default Security Group을 추가해주거나, 각 Resource가 존재하는 서브넷의 CIDR을 추가해주어야 합니다.

이러한 과정을 통해 이루어지는 네트워크 통신은 외부를 통하지 않고 AWS 네트워크 상에서만 이루어지게 되며, 안전하고 고성능의 통신이 가능하게 됩니다.

 

하지만 이러한 VPC Peering에도 한계는 있습니다. 여러 한계점이 존재하지만 그 중 대표적으로 격리된 VPC상에는 같은 CIDR이 존재할 수 있스니다. 이러한 경우에는 VPC Peering 연결을 생성할 수 없으며 그 이슈는 다음 문제에서 설명하겠습니다. 또한 A VPC와 B VPC가 VPC Peering이 생성되어 있고, B VPC와 C VPC가 VPC Peering이 연결되어 있다고 해도 A VPC와 C VPC는 Peering이 되지 않고, 따로 설정을 해주어야 합니다. 이러한 이슈는 네트워크 구조가 복잡해지고 VPC개수가 증가하는 경우 간편하게 해결할 수 있는 방법이 필요할 것 같습니다.

 

 

 

 

 

서로 다른 계정에서 운영되는 각 VPC의 CIDR가 동일할 경우 통신을 위해 어떻게 구축할 것인지 설명

 

위에서 설명했 듯, 서로 다른 계정에서 운영되는 각 VPC간 통신은 AWS VPC Peering을 통해 해결할 수 있었습니다.

하지만, 이 경우에 연결하려는 VPC 내 서브넷의 CIDR이 동일하거나 겹치는 구간이 있는 경우에는 Local 통신인지 VPC Peering을 위한 트래픽인지 라우트 테이블이 판단할 수 없으므로 VPC Peering이 불가능하게 됩니다.

 

이 때, A VPC의 Peering 불가한 서브넷과 B VPC의 Peering이 불가한 서브넷이 통신하려면 각 VPC에 Peering이 가능한 서브넷이 존재해야 하며, NAT게이트웨이, ALB, Transit게이트웨이의 도움이 필요합니다.

아래 그림과 같이 각 VPC A와 B에 Peering불가능한 서브넷, 가능한 서브넷이 존재합니다. A VPC의 Peering불가능한 서브넷에 서비스 A가 VPC B의 Peering불가능한 서브넷의 B서비스로 트래픽이 가능하도록 구축해 보겠습니다.

 

A VPC의 Peering 불가한 서브넷의 라우팅 테이블에서 B VPC의  Peering 가능한 서브넷으로의 모든 트래픽을 A VPC내 NAT게이트웨이 주소로 지정하는 경로를 추가합니다. 그에 이어 A VPC의 Peering 가능한 서브넷에서 B VPC의 Peering 가능한 서브넷으로의 모든 트래픽을 Transit 게이트웨이로 전달하는 경로를 추가합니다.

이렇게 되면 A 서비스에서 B VPC의 Peering 가능한 서브넷으로의 ALB에 주소에 대한 트래픽이 NAT, Transit게이트웨이를 거쳐 VPC B의 Peering 가능한 서브넷의 ALB에 전달되게 되고 ALB는 B 서비스로 전달하게 되어 통신이 가능하게 됩니다.

 

이 때 서비스 B에서 ALB로 전달된 응답을 서비스 A로 전달하려면, VPC B의 Peering 가능한 서브넷의 라우팅 테이블에는 대상 주소가 VPC A의 Peering 가능한 서브넷으로 향하는 모든 트래픽을 Transit 게이트웨이로 향하게 설정합니다.

이 VPC Peering의 중간 역할을 해주는 Transit게이트웨이의 라우팅 테이블에는 VPC A의 Peering 가능한 서브넷의 CIDR전체 또는 일부를 VPC A에 전달하도록 하고, VPC B의 Peering 가능한 서브넷의 CIDR전체 또는 일부로 오는 트래픽은 VPC B로 전달되도록 설정해주면 됩니다.

 

 

위에서 설명한 것처럼 중복되는 CIDR을 가진 VPC간 VPC Peering문제를 NAT, Transit게이트웨이와 각 VPC의 라우팅 가능한 CIDR를 가진 서브넷의 추가로 해결할 수 있습니다. 또한, Transit Gateway를 통해 VPC Peering의 CIDR중복 문제 뿐만 아니라, 1:1연결이만 가능한 VPC Peering이 복잡하고 많은 수의 VPC가 통신해야 할 때의 문제를 해결해줄 수 있는 라우팅 Hub역할도 해줄 수 있습니다. 감사합니다.