1. 오류발생 상황
EC2 에서 RDS로 접근하는 것은 가능했지만
inteliJ database tool에서 rds에 연결이 실패했습니다.
aws rds를 사용하려는 이유가 ec2에 웹 프로젝트(스프링부트 기반)를 포함하여 배포하는 것이기 때문에,
외부 접근을 할 수 있어야 했습니다.
port 번호를 수정 후, 외부에선 접근이 가능했지만, EC2 -RDS 접근이 불가능하다면 명령어를 확인해주세요.
ERROR 2003 (HY000): Can't connect to MySQL server on 'post-rds.엔드포인트' (110)mysql -u rds관리자명 -P 포트번호 -h rds엔드포인트 -p-P를 통해 port를 명시하지 않으면, mysql 명령어의 default는 3306입니다.
2. 오류 확인
AWS에 RDS 생성하고 기존에 생성한 EC2 인스턴스와 연결을 했습니다.
ssh를 통해 EC2로 접근을 했고
(EC2 접근 명령어: ssh service -> 따로 설정을 해주었기 때문에 축약하여 사용할 수 있었습니다)
명령어를 통해 EC2-RDS로 접근하는 것까지 확인할 수 있었습니다.
(RDS 접근 명령어: mysql -u rds관리자명 -P 3306 -h rds엔드포인트 -p)
그러나 IntelliJ 와 같은 외부환경(Spring, Dbeaver 등)에서 RDS로 접근할 때 시간초과, 액세스 거부 오류가 발생했습니다.
게시글에서 사용된 탄력적 IP, RDS, EC2는 릴리스되었습니다.
인텔리제이 오류: Connect timed out
스프링부트 오류: Caused by: java.sql.SQLInvalidAuthorizationSpecException: (conn=12) Access denied for user 'admin'@'프라이빗ip' (using password: YES)
3. 해결책 - 테스트 (반복)
1. RDS 연결&보안 > 보안 > 퍼블릭 액세스 가능 여부 확인
외부 접근이 불가능할 때, 보안 그룹과 함께 가장 먼저 확인해야 할 항목으로 '아니오' 로 설정했다면 외부 접근이 불가합니다.
그러나 외부 접근이 가능하게 설정이 되어 있음을 확인할 수 있었습니다.
2. RDS(EC2) 보안 그룹 설정 점검
AWS는 보안 그룹(SG, security group)을 통해 (인스턴스 수준에서) 트래픽 송수신 제어를 합니다. 일종의 방화벽이라고 할 수 있습니다.
액세스 거부 원인이 될 수 있기 때문에 내부 규칙을 점검했습니다.
RDS 인바운드 규칙을 살펴보았을 때, 문제가 될 부분은 없어보였습니다. 오히려 더 넓은 범위를 지정한 것으로 확인할 수 있었습니다.
혹시 모르기 때문에 모든 트래픽을 허용하기로 했지만, 결과는 같았습니다.
※ 보안 그룹은 기본적으로 stateful 하기 때문에 아웃바운드 규칙의 경우 모든 트래픽 허용으로 해두었습니다.
3. 네트워크 ACL 의 보안 그룹 점검
AWS는 네트워크 ACL(NACL)를 통해 (서브넷 수준에서) 트래픽 송수신을 제어합니다.
NACL 또한 액세스 거부의 원인이 될 수 있기 때문에 내부 보안 그룹을 점검합니다.
ACL은 인스턴스 수준의 보안그룹과 달리 stateless 하기 때문에 인바운드의 연결이 추적되지 않습니다. 따라서 아웃바운드 규칙도 확인할 필요가 있습니다.
ACL SG는 위에 있는 규칙이 적용되므로
위처럼 설정이 되어 있다면(따로 설정을 하지 않았다면)
모든 트래픽을 허용하는 것입니다.
4. Region, VPC, AZ, Subnet 그룹 동일 여부 확인
동일한 Region에 속해있는가
동일한 VPC 내에 속해있는가
동일한 AZ에 있는가
동일한 서브넷 그룹을 공유하고 있는가
위 사항들을 점검해봅니다. 동일한 영역에서 동작하고 있다면 다음 항목으로 넘어가세요.
5. db tool설정을 포함한 오타 점검
RDS를 설정할 때 db 이름을 설정하지 않으면 db가 만들어지지 않습니다.
db_name은 외부 tool로 접근한 이후에도 생성할 수 있기 때문에
오류원인과 연관성은 낮다고 판단했지만 RDS 생성하면서 오타가 발생했을 수도 있기에
db_name과 관리자 정보를 포함하여 오타가 날 수 있는 요소들을 점검하여 RDS를 재생성합니다.
정보를 입력할 때는 복사-붙여넣기를 활용합니다.
또한, 인텔리제이의 DB driver 설치 및 버전 확인을 진행합니다.
6. port 번호 점검
MariaDB와 MySQL의 포트 번호는 3306으로 동일합니다.
동일한 포트 번호를 사용하기 때문에 종종 호환성 문제가 발생하기도 합니다.
따라서 RDS를 재생성 하면서 다른 port 번호(3308)를 사용할 수도 있습니다.
다만 다른 port 번호를 사용한다면 EC2에서 rds 로 접근할 시, 명령어에 -P 3308 을 추가해줍니다
(RDS 접근 명령어: mysql -u rds관리자명 -P 3306 -h rds엔드포인트 -p)
동시에 보안 그룹의 보안 규칙들도 확인해줍니다.
7. 서브넷 퍼블릭 IPv4 주소 자동 할당
AWS는 퍼블릭 IPv4 주소를 할당함으로써 인스턴스가 인터넷에 직접 액세스할 수 있도록 합니다.
따라서 이 항목을 점검합니다.
이 항목을 점검했지만, 인스턴스에 탄력적 IP를 사용하는 경우 자동 할당을 아니오로 설정해도 무방합니다.
탄력적 IP가 인터넷 액세스 권한을 가지고 있기 때문입니다.
8. 서브넷 (프라이빗 / 퍼블릭) 점검
데이터베이스에 외부 액세스를 하려면 RDS 서브넷 그룹의 모든 서브넷이 퍼블릭이어야 합니다.
그러나, 서브넷이 프라이빗일지라도 라우팅 테이블에 인터넷 게이트웨이가 있다면 외부 액세스가 가능합니다.
VPC > 라우팅 테이블 > 서브넷 연결 > 명시적 서브넷 연결에 서브넷이 있는지 확인하세요.
명시적 서브넷에 서브넷이 있다면, 그 서브넷은 프라이빗 서브넷입니다.
9. 라우팅 테이블(인터넷 게이트웨이 활성) 점검
라우팅 테이블은 VPC내의 네트워크 트래픽 흐름을 제어합니다.
VPC의 서브넷은 라우팅 테이블과 연결되어 있으며,
서브넷은 라우팅 테이블에 정의된 경로를 사용하여 트래픽을 보낼 위치를 결정합니다.
라우팅 테이블에 인터넷 게이트가 없는 경우,
해당 VPC 내의 인스턴스는 퍼블릭 인터넷에 트래픽을 보낼 경로를 찾을 수 없으므로직접 액세스할 수 없습니다.
4. 문제 해결 - 결과
저는 인스턴스가 공유하는 서브넷의 라우팅 테이블에 인터넷 게이트웨이가 없었음을 확인하였고,라우팅 테이블에 인터넷 게이트웨이를 활성화했습니다.
외부(인텔리제이)에서 AWS RDS로 접근 성공을 확인할 수 있었습니다.
5. 느낀점
이전에 AWS을 사용하면서 어떻게 설정하는지 과정을 기록했지만,
일단 경험해보는 것이 중요하니까, 왜 이렇게 설정하는지에 대한 생각을 품기보다는 일단 넘어갔습니다.
그래서 이번에는 이것저것하면서 개념을 정립하고 기록을 병행하기로 했습니다.
이것저것 해보다가 EC2 컴퓨팅 리소스 연결 전용(외부 접근 불허)으로 만든 서브넷 그룹을 다른 RDS의 서브넷으로 사용해서 이 오류를 맞닥뜨렸지만,
마침 보안 그룹과 서브넷에 대한 공식 문서를 읽고 있었기 때문에 문제 해결에 도움이 되었던 것 같습니다.
시스템이 어떻게 작동하는지 알아야 유연하게 대처할 수 있기 때문에
앞으로도 공식문서를 보며 각 리소스의 역할과 특징, 흐름을 파악하는 데 힘써야겠다고 느꼈습니다.
6. 문제 해결에 대한 참고자료
출처: (AWS공식문서) https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html