서버 인프라/Aws

VPC Peering 사용하기

트리맨스 2023. 9. 23. 17:44
반응형

 

이번에 서버를 글로벌 확장을 하게 되면서 각 VPC간에 연결을 해야 할 상황이 왔다. 그래서 Peering을 하면서 간단히 정리해 보려고 한다.

 

개요


처음에는 각 국가의 서버 정보가 달라야 하기 때문에 아키텍쳐 전체를 복사하려고 했으나, 모니터링 및 기타 중앙에서 관리해야 하는 앱이 있고, 해당 앱에 대해서는 처음부터  구축하기에는 공수가 많이 들었다. 그래서 서비스되는 애플리케이션은 Terraform을 사용해서 복사하고, BI 또는 모니터링 애플리케이션에 대해서는 AWS의 내부 네트워크를 사용해서 타 리전의 애플리케이션에 접속하여 외부 네트워크를 거치지 않고 안전하게 데이터에 접근할 수 있게 할 계획이다.

 

먼저 VPC Peering과 비슷한 서비스인 Transit Gateway에 대해서 조사해 보았다.

VPC Peering Transit Gateway
VPC간 1대1 연결 허브&스포크 방식으로 연결
최대 125개의 VPC 연결 최대 5000개의 VPC연결
연결 비용 없음 시간단 0.07$
리전간 데이터 이동 표준 요금 리전간 데이터 이동 표준 요금

 

VPC Peering은 1대1 연결이기 때문에 A, B, C, D 총 4개의 VPC를 모두 연결하기 위해서는 6개의 connection이 필요하다. 하지만 Transit Gateway는 허브가 있기 때문에 4개의 Connection만 필요하다. 하지만 연결마다 비용이 따로 든다. 나의 경우에는 VPC가 많은 편도 아니고, 모두 연결하는 것이 아닌 메인VPC에만 모두 연결만 하면 되는 VPC Peering을 선택했다. 비용도 비교적 저렴하다.

 

테스트


간단히 테스트할려는 계획은 다음과 같다.

VPC1의 EC2는 퍼블릭으로 열려 있어서, 외부에서 접속이 가능하다. 하지만 VPC2의 EC2는 외부에서 접속을 못하게 프라이빗 서브넷에 두었다. 여기 접속하기 위해서는 VPC1의 EC2에 접속한 다음, VPC Peering을 통해 VPC2의 EC2에 접속해야 한다. 이 구성을 테스트 해 볼 것이다.

 

먼저 VPC2개를 만들어 둔다. 그리고 VPC1의 퍼블릭 서브넷에 인스턴스까지 하나 만들어 둔다. 그리고 VPC2에는 프라이빗 서브넷 내에 EC2를 만들어 둔다. 이제 외부에서 해당 EC2에는 접속할 방법이 없다. 여기서 주의할 점은, 각 VPC의 내부IP가 중복되지 않게 CIDR을 설정해야 한다.

 

VPC1에서 피어링 연결을 요청한다.

요청자 VPC ID에 VPC1 아이디를 입력하고, 수락자 VPC ID에 VPC2의 아이디를 입력한다. 아후 VPC2에서 수락하면 일단은 연결이 된 것이다.

 

 다음으로는 라우팅 테이블에서 타 VPC에 접속할 때 라우터를 잘 탈수 있도록 라우터를 설정하는 것이다. 먼저 VPC1의 EC2가 있는 서브넷의 라우팅 테이블을에 라우팅 규칙을 추가하자.

 

172.31.0.0/16은 VPC2의 내부 IP주소이다. 해당 라우팅은 172.31.0.0/16으로 요청하는 네트워크에 대해서는 VPC Peering을 사용하도록 설정한 것이다. VPC Peering 대상에 특별한 설정이 없다면 pcx-xxxx...로 시작하는 이름이 있을 것이다. 이제 VPC2의 EC2가 있는 서브넷의 라우팅 테이블도 편집해 주자.

 

 

192.168.0.0/16은 VPC1의 내부 IP주소이다. 각 인스턴스의 보안 그룹은 22번 포트로 접속할 수 있게 한다. IP주소 대역 제한은 요청하는 호스트의 아이피 주소에 따라서 제한을 준다.

 

위에서 설정한 것과 마찬가지로 라우팅을 설정하면, 이제 EC2에서 ssh접속을 테스트 해볼 수 있다. scp명령어를 통해서 VPC1의 EC2에 VPC2의 EC2 키 파일을 넣어 두고, ssh 접속을 테스트해보자. 먼저 VPC1의 EC2에 접속한다.

 

아이피 주소를 보면 192.168.1.183인 것을 보아 192.168.0.0/16 안에 있는 것을 알 수 있다. VPC1의 EC2이다. 이제 VPC2의 EC2에 접속해보자.

 

아이피 주소가 172.31.64.162인 것을 보아 172.31.0.0/16안에 있는 것을 잘 알수 있다. VPC Peering이 정상적으로 잘 이루어진 것 같다.

 

현재 필요한 프로젝트에서는DB 접속과 S3 엔드포인트 접속을 위해 DNS 주소까지 사용할 것 같으므로, 나중에 DNS 설정까지 켜두면 좋을 것 같다. 주고받는 데이터는 오직 관리자를 위한 데이터이므로, 사용자 수준에서 데이터의 전송은 없다고 봐도 무방할 것 같다.

 

반응형