K3s 기반 멀티 노드 클러스터 구축기 (4) - VPC Peering을 통한 Private 통신 연결

이번 글에서는 서로 다른 AWS 계정의 VPC 간에 Private IP를 이용해 통신하는 과정을 자세히 살펴본다. 실습은 "VPC Peering 생성 → 수락 → 라우팅 테이블 수정 → 통신 테스트" 순서로 진행되었으며, 이를 통해 Private 네트워크 상에서 계정이 다른 private 인스턴스끼리도 직접 통신할 수 있다는 점을 명확히 확인할 수 있었다.

1. 시작하면서

현재 인프라 구성은 다음과 같다. Control Plane은 Infra 계정에, Worker Node는 Dev 계정에 각각 배치되어 있으며, 두 계정의 VPC는 물리적으로 분리되어 있다.

기본적으로는 서로 다른 VPC이기 때문에 직접 통신이 불가능한 상황이었다. 그러나 퍼블릭 IP를 이용한 통신은 보안과 비용 측면에서 부담이 있었고, 가능하다면 Private IP 기반의 안전한 내부 통신 구조를 구축하고자 했다. 이런 배경에서 VPC Peering 연결을 통한 Private 통신을 시작하게 되었다.

• 서로 다른 AWS 계정 간 VPC Peering을 통해 Private IP로 통신할 수 있도록 구성한다.
• 퍼블릭 IP 없이도 계정 간 네트워크 연결이 가능한지 실습을 통해 검증한다.

2. VPC Peering 연결 과정

(1) Peering Connection 요청 생성

먼저 Infra 계정에서 VPC Peering Connection을 생성했다. 이때 중요한 것은 Peer AWS Account ID와 Peer VPC ID를 정확하게 입력하는 것이었다. Requester는 Infra VPC가 되었고, Accepter는 Dev VPC가 된다. 여기서 Accepter가 따로 수락을 해야 Peering이 활성화될 수 있다는 점을 주의해야 한다.

(2) Peering Connection 수락

Dev 계정으로 이동하여 Peering 요청을 수락했다.

 

수락이 완료되면 Peering Connection의 상태가 'Active'로 변경되며, 두 VPC 간 네트워크 레벨의 연결이 이루어진다. 하지만 이 단계만으로는 실제 통신이 이루어지지 않는다는 점을 알아야 한다.

 

(3) Routing Table 수정

Peering이 완료되었다 하더라도, 각 VPC의 Route Table을 수정해주지 않으면 트래픽이 제대로 전달되지 않는다. 따라서 각 VPC의 Route Table에 상대 VPC의 CIDR 대역을 등록하고, Target을 Peering Connection으로 설정해야 한다.

• Infra VPC Route Table: Destination = 10.10.0.0/16 → Target = Peering Connection
• Dev VPC Route Table: Destination = 10.30.0.0/16 → Target = Peering Connection

이 설정을 통해 양쪽 모두 상대방 VPC로 향하는 트래픽 경로를 명시적으로 열어주게 된다.

또한 보안 그룹(Security Group) 설정도 중요한데, 인바운드 규칙에 상대방 VPC 대역을 허용하지 않으면 통신이 차단될 수 있다.

3. Private IP 통신 테스트

라우팅 테이블 수정과 보안 그룹 설정이 끝난 후, 실제 통신이 이루어지는지 여러 방법으로 테스트했다.

(1) ping 테스트

Infra 계정의 Control Plane 인스턴스에서 Dev 계정의 Worker Node Private IP로 ping을 보냈다.

ping 10.10.1.100

ping 응답이 정상적으로 돌아오는 것을 확인할 수 있었다. 이는 기본적인 네트워크 연결이 성공했다는 의미였다.

(2) kubelet 포트 curl 테스트

쿠버네티스 노드가 사용하는 기본 포트(10250)로도 직접 연결을 시도했다.

curl -k https://10.10.1.100:10250

비록 응답은 404 Not Found였지만, 가장 중요한 점은 SSL 레벨의 연결이 성공했다는 것이다. 즉, 네트워크 경로상 문제 없이 통신이 가능함을 확인했다.