[AWS] 서로 다른 VPC에 있는 EC2에서 RDS로 연결하기 (VPC 피어링)

 

EC2에서 RDS로 접속하려는데, 둘이 서로 다른 VPC에 있어 McpError('Connection closed') 같은 연결 오류가 나는 상황. 이럴 때 VPC 피어링으로 어떻게 연결하는지 정리한다.

 

AWS 네트워크 관련 개념은 예전 글에서 한 번 정리했는데, 이번 작업을 이해하는 데 필요한 만큼만 다시 짚고 넘어가자.

 

VPC

• VPC(Virtual Private Cloud) 는 AWS 에서 논리적으로 격리된 네트워크 공간이며, 기본적으로 서로 다른 VPC 에 있는 리소스끼리는 통신이 불가능하다. 
  VPC 는 하나의 리전 안에만 속하며, 여러 리전에 걸칠 수 없다. 

 

서브넷

• 서브넷은 VPC 네트워크 공간을 잘게 나눈 하위 공간이다. 
• EC2 나 RDS 같은 리소스는 VPC 에 직접 놓이는게 아니라, 반드시 어떤 서브넷 안에 배치된다. 
• 각 서브넷은 하나의 가용 영역(AZ)에 연결되며, 여러 AZ 에 걸칠 수 없다. 
• 즉 서브넷 하나 = 하나의 AZ 이다. 
  
  

라우팅 테이블

• 라우팅 테이블은 네트워크 트래픽이 어디로 가야 하는지 알려주는 규칙 목록이다. 
• 라우팅 테이블은 '서브넷 단위' 로 붙는다. VPC 전체에 일괄 적용되는 게 아니라, 각 서브넷에 하나씩 연결된다. 따라서 어떤 서브넷이 너떤 라우팅 테이블을 쓰는지는 중요한 포인트이다. 
• 서브넷에 별도 테이블을 명시하지 않으면 VPC 기본 테이블을 쓰지만, 명시적으로 다른 테이블을 연결해두면 기본 테이블에 아무리 라우트를 추가해도 그 서브넷에는 적용되지 않는다. 

 

상황

EC2와 RDS가 서로 다른 VPC에 놓여 있는 구성이다.

리소스	VPC	IP
agent-ec2	vpc-001 (vpc-dev)	10.0.x.x
RDS rds-production	vpc-002 (vpc-prod)	10.1.x.x

 

agent-ec2에서 rds-production에 접속하려고 하는데, 둘은 서로 다른 VPC에 위치해 있다.
이 경우 기본 상태로는 통신이 되지 않는다.

 

VPC 피어링 연결을 통해 서로 다른 VPC에 걸쳐 통신 할 수 있다.

 

VPC 피어링

VPC 피어링은 서로 다른 두 VPC를 직접 연결하는 전용 통로다.

인터넷을 거치지 않고 프라이빗 IP로 통신할 수 있게 해주는 AWS 기능이다.

 

VPC 피어링이 실제로 동작하려면 아래 3가지가 모두 갖춰져야 한다. 

이때 하나라도 빠지면 연결되지 않는다.

 

• VPC 피어링 연결 : 두 VPC 사이에 통로가 뚫려 있는가
• 라우팅 테이블   : EC2/RDS 서브넷이 실제로 쓰는 테이블에 피어링 라우트가 있는가
• RDS 보안 그룹   : RDS 인바운드가 EC2의 접근을 허용하는가

 

▶ Step 1. VPC 피어링 연결 생성 — 통로 뚫기

• VPC → 피어링 연결 → 피어링 연결 생성

 

 

• 요청자 VPC : vpc-001 (vpc-dev)
• 수락자 VPC : vpc-002 (vpc-prod)

 

요청자, 수락자 구분은 통신 방향과 아무 상관이 없다. 
VPC 피어링은 두 VPC 를 연결할 때 한쪽이 "연결하자"고 요청을 보내고, 다른 쪽이 수락하는 handshake 절차를 거친다. 
따라서 이것은 그냥 역할일 뿐이며, 요청자라고 해서 트래픽을 보내기만 하는 것도 아니고, 수락자라고 해서 받기만 하는 것도 아니다. 

 

그럼 요청자, 수락자를 반대로 입력해도 되나 ? >> 된다
두개 역할을 반대로 입력해도 결과는 완전히 동일하다. 요청자, 수락자가 실제로 의미를 갖는 것은, 다른 AWS 계정의 VPC 와 피어링을 할때 이다. 그때는 상대 계정 소유자가 수락 버튼을 눌러줘야 하기 때문이다. 

 

통신이 어느 방향으로 흐를지를 결정하는 것은 요청자 / 수락자가 아니라, 글 뒤쪽에 나오는 라우팅 테이블과 보안그룹이다. 

 

• 라우팅 테이블 : 어느 VPC 에서 어느 대역으로 가는 길을 열지
• 보안 그룹 : 어느 IP 의 인바운드를 허용할지

 

VPC 피어링 연결을 생성한 후 작업 → 요청 수락을 통해 활성화 한다. 

 

이제 통로 뚫기가 완료되었다. 

 

▶ step 2. 라우팅 테이블 설정

 

피어링 통로를 만들었어도, 각 VPC가 "저쪽으로 가려면 피어링을 타라"는 규칙을 모르면
통신이 되지 않는다. 그 규칙을 적어주는 게 라우팅 테이블이다.

 

앞에서 짚었듯, VPC를 만들면 메인 라우팅 테이블이 하나 자동 생성되고, 아무것도 지정하지 않은 서브넷은 전부 이 메인 테이블을 따라간다. 그러다 특정 서브넷에 다른 라우팅 테이블을 명시적으로 연결하면, 그 서브넷만 메인에서 떨어져 나와 지정한 테이블을 따른다.

그리고 EC2 인스턴스는 항상 하나의 서브넷에 할당된다. 인스턴스를 시작할 때 서브넷을 지정해야 하고, 한 번 정해지면 그 인스턴스의 기본 네트워크 위치가 된다. 따라서 라우트를 추가할 때는 "VPC의 기본 테이블"이 아니라 그 인스턴스의 서브넷이 실제로 쓰는 테이블을 찾아야 한다.

 

▷ 2-1. EC2 서브넷의 라우팅 테이블에 추가

 

• EC2 → 인스턴스 → 네트워킹 → 서브넷ID → 라우팅 테이블 → 라우팅 테이블 연결 편집

여기서 step 1 에서 생성한 VPC 피어링 연결 ID 를 선택해서 추가한다. 

 

▷ 2-2. RDS 서브넷의 라우팅 테이블에도 추가

 

라우팅은 EC2 쪽만 하면 안 되고, RDS가 위치한 서브넷의 라우팅 테이블에도 추가해야 한다.

 

이유는 라우팅이 방향마다 따로 필요하기 때문이다. EC2가 RDS로 패킷을 보낼 때(가는 길)와, RDS가 그 응답을 EC2로 돌려보낼 때(오는 길)는 각각 출발하는 쪽의 라우팅 테이블을 참조한다. EC2 쪽만 설정하면 패킷이 RDS까지 가긴 하지만, RDS가 답을 돌려보낼 길을 몰라 통신이 반쪽만 되고 끊긴다.

 

RDS(특히 Aurora)는 여러 서브넷에 걸쳐 배치될 수 있으므로, 먼저 RDS가 어느 서브넷을 쓰는지부터 확인한다.

 

• Aurora and RDS → 데이터베이스 → 인스턴스 → VPC ID 확인
• Aurora and RDS → 서브넷 그룹 → 위에서 확인한 VPC 내의 서브넷 그룹 → 서브넷 ID → 라우팅 테이블 연결 편집

여기서 동일하게 step 1 에서 생성한 VPC 피어링 연결 ID 를 선택하여 추가한다. 

 

위와 같이 EC2 와 Aurora RDS 이 위치한 서브넷이 어떤 라우팅 테이블을 실제로 사용하는지 먼저 확인한 뒤, 그 테이블에 라우트를 추가해야한다. 

 

 

▶ step 3. RDS 보안 그룹 생성 및 연결

 

step 1 에서 길을 뚫어주고, step 2 에서 이 길로 가면 된다고 안내판을 세워줬다. 
step 3 는 출입 허가증을 발급하는 절차라고 보면 되겠다.

 

보안 그룹은 RDS 앞에 선 방화벽이다. 허용 규칙만 설정할 수 있고, 기본적으로 모든 인바운드가 차단돼 있다. 그래서 라우팅을 통해 패킷이 RDS 문 앞까지 도착해도, 보안 그룹 인바운드에 그 출처가 등록돼 있지 않으면 문턱에서 막힌다.

 

참고: 보안 그룹은 RDS 쪽만 열면 된다.
(단, EC2 아웃바운드를 일부러 제한해둔 경우라면 RDS 포트로 나가는 것이 허용돼 있는지만 확인한다.)

 

▷ 3-1. EC2의 프라이빗 IP 확인

 

먼저 RDS 인바운드에 등록할 EC2의 프라이빗 IP를 확인한다.

 

• EC2 → 인스턴스 → 해당 인스턴스 → [네트워킹] 탭 → 프라이빗 IPv4 주소
• 여기 표시되는 값(예: 10.0.17.105)이 RDS 인바운드 소스로 넣을 IP다.

 

▷ 3-2. RDS 보안 그룹 인바운드 규칙 수정

 

• RDS → 데이터베이스 → 해당 인스턴스 → [연결 및 보안] 탭
             → 연결된 보안 그룹 클릭 → [인바운드 규칙] 탭 → [인바운드 규칙 편집]
             → [규칙 추가]

 

RDS에 보안 그룹이 여러 개 연결돼 있을 수 있다. 규칙은 합집합으로 적용되므로, EC2 접근용으로 목적이 분명한 보안 그룹(예: rds-prd-access처럼 dev 대역 IP가 이미 들어 있는 것) 하나를 골라 거기에 추가하면 된다. 내부 통신용 보안 그룹에 섞지 않는 편이 나중에 관리하기 깔끔하다.

 

소스에 IP /32 대신 EC2의 보안 그룹 ID를 넣을 수도 있다. 그러면 EC2가 재시작돼 IP가 바뀌어도 규칙을 고칠 필요가 없다. 단, 이 방식은 두 리소스가 같은 VPC이거나 VPC 피어링으로 연결된 경우에만 동작한다.

 

 

---

정리

서로 다른 VPC에 있는 EC2와 RDS를 연결하려면 VPC 피어링을 사용할 수 있다. 다만 단순히
피어링 연결만 생성한다고 통신이 되는 것은 아니며, 다음 3가지가 모두 갖춰져야 한다.

 

1.   피어링 연결 생성 - 두 VPC 사이의 전용 통로
2.  라우팅 테이블 설정 - EC2와 RDS가 실제로 사용하는 서브넷의 테이블 양쪽에 추가 (기본 테이블 != 실제 사용 테이블일 수 있음)
3.  보안 그룹 설정 - RDS 인바운드에 EC2 IP를 명시적으로 허용

 

위 세 가지를 갖추면 VPC 피어링을 통해 서로 다른 VPC에 위치한 리소스끼리도 프라이빗 IP로 통신할 수 있다.