EC2 인스턴스에서 RDS 연결 문제 해결하기

EC2에서 실행 중인 애플리케이션이 RDS에 연결할 수 없을 때, 먼저 실패 유형을 파악하세요. 타임아웃은 일반적으로 경로 어딘가에서 트래픽이 차단되고 있음을 의미합니다. 빠른 connection refused는 호스트에 도달했지만 포트가 연결을 수락하지 않았음을 의미합니다. 인증 오류는 네트워크 경로가 작동 중이며 문제가 데이터베이스 사용자, 비밀번호, SSL, IAM 인증 또는 권한으로 이동했음을 의미합니다.

이러한 구분은 시간을 절약해 줍니다. 네트워크 타임아웃에 대해 비밀번호를 재설정하지 말고, 잘못된 비밀번호에 대해 보안 그룹을 열지 마세요. EC2 인스턴스에서 바깥쪽으로 작업하세요: DNS, 포트 연결 가능성, 보안 그룹, 서브넷 라우팅, NACL, RDS 상태, 그다음 데이터베이스 인증 순서입니다.

성공적인 연결을 위한 전제 조건

문제 해결에 들어가기 전에 다음 기본 요소가 올바르게 구성되었는지 확인하세요:

VPC 정렬: 가장 간단한 구성을 위해 EC2 인스턴스와 RDS 인스턴스는 이상적으로 동일한 VPC 내에 있어야 하지만, VPC 피어링을 통해 교차 VPC 연결도 가능합니다.
가용 영역(AZ): 필요한 경우 애플리케이션 인프라(EC2)가 데이터베이스 인프라(RDS)에 AZ를 넘어 도달할 수 있는지 확인하세요. 라우팅은 일반적으로 VPC 내에서 이를 처리합니다.
네트워크 연결 가능성: EC2 인스턴스가 실행 중이고 활성 네트워크 연결(예: 인터넷 또는 다른 내부 서비스에 도달 가능)이 있는지 확인하세요.

1단계: 보안 그룹 구성 확인 (가장 흔한 원인)

보안 그룹은 EC2 인스턴스와 RDS 인스턴스 모두에 대한 가상 방화벽 역할을 합니다. 여기서의 잘못된 구성은 대부분의 연결 실패 원인입니다.

A. EC2 보안 그룹 확인

EC2 인스턴스에는 데이터베이스 포트로 트래픽이 나갈 수 있도록 하는 아웃바운드 규칙이 필요합니다. 기본적으로 대부분의 보안 그룹은 모든 아웃바운드 트래픽(0.0.0.0/0 모든 프로토콜/포트)을 허용하지만, 이를 확인하는 것이 좋습니다.

B. RDS 보안 그룹 인바운드 규칙 확인

이것이 중요한 단계입니다. RDS 보안 그룹은 EC2 인스턴스의 인바운드 트래픽을 명시적으로 허용해야 합니다.

실행 가능한 확인:

RDS 콘솔로 이동하여 데이터베이스 인스턴스를 선택하세요.
연결 및 보안 탭으로 이동하여 연결된 보안 그룹을 찾으세요.
인바운드 규칙을 편집하세요.
특정 데이터베이스 포트(예: MySQL의 경우 3306, PostgreSQL의 경우 5432)에서 트래픽을 허용하는 규칙이 있는지 확인하세요.
이 규칙의 소스는 EC2 인스턴스의 보안 그룹 ID이거나, 보안 그룹 참조를 사용하지 않는 경우 EC2 인스턴스의 특정 프라이빗 IP 범위여야 합니다.

모범 사례: 소스 필드에 특정 IP 주소를 사용하는 대신 소스 리소스(EC2)의 보안 그룹 ID를 항상 참조하세요. 이렇게 하면 EC2 인스턴스의 프라이빗 IP가 변경되더라도(예: 스케일링 또는 재부팅 중) 연결이 유지됩니다.

예시 인바운드 규칙 (PostgreSQL):

유형	프로토콜	포트 범위	소스
PostgreSQL	TCP	5432	sg-012345abcdef67890 (EC2 보안 그룹 ID)

2단계: RDS 퍼블릭 액세스 가능성 및 엔드포인트 확인

EC2 인스턴스가 프라이빗 서브넷에 없거나 퍼블릭 인터넷을 통한 연결이 필요한 경우(일반적으로 프로덕션에서는 권장되지 않음), RDS 퍼블릭 액세스 가능성을 확인해야 합니다.

A. 퍼블릭 액세스 가능성 설정

RDS 콘솔에서 RDS 인스턴스의 연결 및 보안 탭을 확인하세요.
퍼블릭 액세스 가능이 아니요로 설정된 경우, 데이터베이스는 동일한 VPC의 리소스 또는 라우팅 및 보안 규칙이 허용하는 경우 피어링, Transit Gateway, VPN 또는 Direct Connect를 통해 연결된 네트워크와 같은 프라이빗 네트워크 경로를 통해서만 연결할 수 있습니다.
퍼블릭 액세스 가능이 예로 설정된 경우, 이를 프로덕션 액세스의 지름길로 취급하지 마세요. 클라이언트에 유효한 퍼블릭 경로가 있는지 확인하고, RDS 보안 그룹을 가능한 가장 작은 실용적인 소스 범위로 제한하세요. 동일한 VPC의 EC2 인스턴스는 일반적으로 프라이빗 경로를 사용해야 합니다.

B. 엔드포인트 확인

EC2 인스턴스의 애플리케이션이 올바른 RDS 엔드포인트(DNS 이름)와 올바른 포트를 사용하고 있는지 확인하세요. 여기서 불일치가 발생하면 타임아웃 또는 연결 거부가 발생합니다.

EC2 인스턴스에서 telnet 또는 nc(netcat) 유틸리티를 사용하여 RDS 엔드포인트 및 포트에 대한 기본 TCP 연결 가능성을 테스트하세요:

# MySQL 포트 3306의 경우
telnet your-rds-endpoint.rds.amazonaws.com 3306

# PostgreSQL 포트 5432의 경우
nc -zv your-rds-endpoint.rds.amazonaws.com 5432

성공적인 연결은 빈 화면이나 즉각적인 연결 메시지로 이어집니다. 실패(타임아웃 또는 거부)는 일반적으로 보안 그룹 또는 서브넷 라우팅과 같은 네트워크 차단을 나타냅니다.

3단계: 서브넷 및 라우팅 구성 분석

보안 그룹이 올바른 것 같으면 문제는 서브넷 간 통신 방식에 있을 수 있습니다.

A. 네트워크 ACL(NACL)

네트워크 ACL은 서브넷 수준에서 작동하는 상태 비저장 방화벽입니다. 사용자 지정 NACL을 구현한 경우 연결을 완료하는 데 필요한 반환 트래픽을 차단할 수 있습니다.

EC2 서브넷과 RDS 서브넷 모두에 대한 NACL을 확인하세요.
인바운드 및 아웃바운드 규칙이 데이터베이스 포트와 반환 트래픽을 위한 임시 포트 범위(1024-65535)에서 트래픽을 허용하는지 확인하세요.

B. 교차 VPC 또는 하이브리드 라우팅

RDS 데이터베이스 연결은 일반적으로 S3 스타일 게이트웨이 엔드포인트가 아닌 일반 VPC 라우팅을 사용합니다. EC2와 RDS가 다른 VPC에 있거나 온프레미스 네트워크에서 연결된 경우, 양방향의 전체 프라이빗 경로를 확인하세요. VPC 피어링, Transit Gateway, VPN 및 Direct Connect는 모두 라우팅 테이블 항목과 호환 가능한 보안 그룹 및 NACL 규칙이 필요합니다.

4단계: 데이터베이스 인스턴스 구성 확인

네트워크 연결이 확인된 경우(2단계 성공), 문제는 데이터베이스 엔진 자체에 있습니다.

A. 데이터베이스 자격 증명 및 권한 부여

EC2 인스턴스에서 연결하는 애플리케이션이 사용하는 사용자 이름, 비밀번호 및 데이터베이스 이름을 확인하세요. MySQL 및 PostgreSQL과 같은 RDS 서비스는 엄격한 사용자 인증을 적용합니다.

B. 파라미터 그룹 및 데이터베이스 상태

데이터베이스 상태: RDS 인스턴스 상태가 사용 가능인지 확인하세요. 수정 중, 백업 중 또는 재부팅 중이면 연결이 실패합니다.
파라미터 그룹: RDS 인스턴스에 적용된 사용자 지정 파라미터 그룹을 확인하세요. 특정 설정(예: 일부 MySQL 구성에서 skip-networking은 관리형 RDS에서는 덜 일반적이지만)이 연결을 방해할 수 있습니다.

C. IAM 데이터베이스 인증(사용하는 경우)

비밀번호 대신 IAM을 데이터베이스 인증에 사용하는 경우, EC2 인스턴스에 연결된 IAM 역할(또는 애플리케이션을 실행하는 사용자 프로필)에 올바른 권한(rds-db:connect)이 있고 연결 문자열에 필요한 인증 토큰이 올바르게 포함되어 있는지 확인하세요.

문제 해결 흐름

이 우선 순위 체크리스트를 사용하여 문제를 신속하게 해결하세요:

포트 확인: EC2가 telnet 또는 nc를 사용하여 RDS 포트에 도달할 수 있나요? ICMP 핑에 의존하지 마세요. RDS는 그런 방식으로 문제를 해결할 수 있는 일반 서버가 아닙니다.
RDS 보안 그룹: 인바운드 규칙이 EC2 보안 그룹 에서 RDS 포트 로 트래픽을 허용하나요?
NACL: 필요한 포트(데이터베이스 포트 + 임시 포트)에 대해 인바운드 및 아웃바운드 규칙이 모두 열려 있나요?
엔드포인트/자격 증명: 연결 문자열이 올바르고 자격 증명이 유효한가요?
DB 상태: RDS 인스턴스가 사용 가능인가요?

포트 테스트가 실패하면 성공할 때까지 네트워크 계층에 머무르세요. 포트 테스트는 성공했지만 데이터베이스 클라이언트가 실패하면 VPC 규칙 변경을 중단하고 데이터베이스 오류를 자세히 읽어보세요. 네트워크 연결 가능성과 데이터베이스 인증을 별개의 문제로 취급하면 대부분의 EC2-to-RDS 문제가 훨씬 쉬워집니다.