[AWS] public IP 요금 부과 대응 방안 및 EC2를 통한 RDS 외부 연결 방법

RDS 프리티어 생성하기 글에서 RDS 설정 시 퍼블릭 엑세스를 허용하는 이유를 간단히 언급했지만, 왜 요금이 부과되는 이유를 잘 모르시는 분들을 위해 이 글에서는 자세히 설명하였습니다! 요금 부과를 방지하는 데 도움이 되고자 작성했습니다.

AWS Public IPv4 요금 변경

AWS에서 퍼블릭(Public) IPv4 주소에 대한 새로운 요금이 도입됩니다. 2024년 2월 1일부터 서비스 연결 여부에 관계없이 모든 퍼블릭 IPv4 주소에 대해 시간당 IP당 0.005 USD의 요금이 부과됩니다.

 

이러한 요금 정책 변경의 이유에 대해서도 설명이 포함되어 있습니다.

IPv4 주소는 점점 더 부족해지고 있으며 퍼블릭 IPv4 주소를 하나 취득하는 데 드는 비용은 지난 5년간 300% 이상 증가했습니다. 새로운 요금 변경 사항은 자사 유지 비용을 반영하며 퍼블릭 IPv4 주소 사용을 줄이고 현대화 및 보존 조치로 IPv6 채택을 가속화하는 것을 고려하도록 권장하기 위한 것입니다.

https://aws.amazon.com/ko/blogs/korea/new-aws-public-ipv4-address-charge-public-ip-insights/

공지 – AWS Public IPv4 주소 요금 변경 및 Public IP Insights 기능 출시 | Amazon Web Services

AWS Free Tier RDS 생성 방법을 검색하다 보면, 참고 자료들에서 RDS를 생성할 때 퍼블릭 액세스를 허용하는 것이 문제로 시작되는 경우가 많습니다. 퍼블릭 액세스를 허용하면 데이터베이스에 Public IP 주소가 할당되기 때문입니다.

예시

해결 방안 : Private RDS 사용

저는 Public 접근 대신 EC2 인스턴스를 통해서 접근하도록 즉, Private 연결만 가능하도록 새로운 RDS를 생성함으로써 문제를 해결했습니다.

다른 해결 방법

- 사용하지 않는 Public IPv4 삭제
- 서브넷의 퍼블릭 IPv4 자동 할당 비활성화
- IPv4 대신 IPv6 도입하기

 

다른 해결 방법 참고자료: https://dev.classmethod.jp/articles/rate-policy-for-aws-public-ipv4-addresses-will-change-kr/

24년 2월부터 AWS의 Public IPv4 주소의 요금 정책이 변경됩니다 | DevelopersIO

 

Private RDS를 생성하는 방법과 로컬 PC에서 Private RDS를 연결하는 방법에 대해 정리해보겠습니다.

 

Private RDS 연결

프라이빗 RDS 연결은 데이터베이스 인스턴스가 퍼블릭 인터넷에 노출되지 않고, VPC(가상 사설 클라우드) 내에서만 접근할 수 있도록 설정하는 방법입니다.

1. VPC 생성: 프라이빗 RDS 인스턴스를 생성하기 위해 VPC를 설정합니다.
2. 서브넷 구성: RDS 인스턴스를 배치할 서브넷을 설정합니다. 프라이빗 서브넷을 사용하는 것이 일반적입니다.
3. 보안 그룹 설정: 보안 그룹을 구성하여 특정 IP 주소나 다른 AWS 리소스에서 RDS 인스턴스로의 접근을 허용합니다.
4. RDS 인스턴스 생성: RDS 인스턴스를 생성할 때, 퍼블릭 액세스를 비활성화하고, 위에서 설정한 프라이빗 서브넷과 보안 그룹을 선택합니다.
5. 연결: EC2 인스턴스 같은 내부 리소스를 통해 RDS에 연결합니다. EC2 인스턴스가 RDS와 동일한 VPC 내에 있어야 합니다.

프라이빗 RDS에 연결하기 위해서는 EC2 인스턴스와 RDS 인스턴스가 반드시 동일한 VPC 내에 있어야 합니다. 이는 보안과 네트워크 접근성을 유지하기 위한 필수 조건입니다.

EC2 인스턴스를 통해 RDS에 연결하면, 생성된 데이터베이스에 연결된 컴퓨팅 리소스가 EC2와 연결된 것을 확인할 수 있습니다. 또한, 보안 그룹 규칙에서 인바운드 및 아웃바운드 규칙이 적용되어 있는 것을 확인할 수 있습니다. 이를 통해 데이터베이스와 EC2 간의 안전한 통신이 보장됩니다.

SSH Tunneling

SSH 터널링은 데이터 전송 시 보안을 강화하고, 제한된 네트워크에 접근하기 위해 중간 서버를 통해 연결하는 방법입니다. 예를 들어, 로컬 서버에서 RDS 데이터베이스에 접근하려고 할 때, RDS가 프라이빗 서브넷에 위치해 있어 외부에서 직접 연결할 수 없습니다. 이럴 때, 데이터베이스에 연결할 수 있는 EC2 인스턴스를 경유하여 접속합니다. 즉, 연결 경로는 로컬 서버 → EC2 서버 → RDS 데이터베이스의 형태로 진행됩니다. 이를 통해 안전하게 데이터베이스에 접근할 수 있습니다.

MySQL Workbench를 이용한 SSH 터널링

MySQL Workbench를 열고, "Database" 메뉴에서 "Manage Connections"를 선택합니다.

"New" 버튼을 클릭하여 새로운 연결을 만듭니다.

• Connection Name: 연결 이름을 입력합니다.
• Connection Method: "Standard TCP/IP over SSH"를 선택합니다.
• SSH Hostname: SSH를 통해 접근할 인스턴스의 퍼블릭 IP 주소를 입력합니다.
• SSH Username: SSH 사용자 이름을 입력합니다.
• SSH Key File: SSH 키 파일(.pem)을 선택합니다.
• MySQL Hostname: RDS 인스턴스의 엔드포인트를 입력합니다.
• MySQL Server Port: 기본 포트(3306)를 입력합니다.
• Username: RDS 데이터베이스 사용자 이름을 입력합니다.
• Password: 데이터베이스 비밀번호를 입력합니다.

이렇게 설정하면 SSH 터널링을 통해 RDS에 안전하게 연결할 수 있습니다!

 

RDS와 Local 실행 환경 연동

그렇다면, 프로젝트에서 RDS와 로컬 환경을 연동하는 간단한 방법은 다음과 같습니다.

아래의 명령어를 통해 터미널에서 SSH 터널링 세션을 생성해야 합니다.

ssh -i [키 페어 파일 경로].pem -N -L [로컬 포트]:[RDS 엔드포인트]:3306 [EC2 사용자 이름]@[EC2 인스턴스 주소]

 

해당 명령어는 로컬에서 SSH 프로토콜을 사용해 시스템 간 연결을 생성합니다.

• -i: 사용자가 EC2 서버에 로그인하는 데 사용하는 개인 키를 지정합니다.
• -N: 실제 셸 세션을 시작하지 않고 포워딩만 수행하도록 ssh에 지시합니다. RDS에 대한 접속 전용 터널을 생성/유지합니다.
• -F: 백그라운드로 ssh 터널을 등록합니다. 매번 다시 연결할 필요가 없지만, 예상치 못한 상황이 발생할 수 있어 사용하지 않았습니다.
• -L: 로컬포트:원격서버:원격서버포트 포맷으로 로컬 포워딩을 설정하기 위한 옵션입니다.

위 명령어는 Linux나 macOS 기반의 터미널에서 사용하도록 설계되어 있습니다. Windows 환경에서는 Git Bash 터미널을 사용할 수 있으며, PuTTY를 이용해서도 가능합니다!

 

여기서 주의할 점은 로컬에 설치된 데이터베이스와 동일한 포트를 사용할 경우 포트 충돌이 발생할 수 있다는 것입니다. 이로 인해 "Permission denied" 오류가 나타날 수 있습니다. 따라서, 로컬 포트 번호를 다른 값으로 설정해야 합니다. 예를 들어, 3307로 설정하면 충돌을 피할 수 있습니다.

따라서 SSH 터널링 명령어에서 로컬 포트를 3307로 지정하면 다음과 같이 입력하면 됩니다.

ssh -i [키 페어 파일 경로].pem -N -L 3307:[RDS 엔드포인트]:3306 [EC2 사용자 이름]@[EC2 인스턴스 주소]

 

 localhost(127.0.0.1)의 3307 포트로 요청을 하면, EC2를 거쳐 RDS로 요청이 전달됩니다.

// .env 파일 예시
DB_HOST=localhost          # 로컬호스트를 통해 접속
DB_PORT=3307               # SSH 터널링 포트 (3307)
DB_USER=remazitensi        # 데이터베이스 사용자
DB_PASSWORD=mypassword     # 데이터베이스 비밀번호
DB_NAME=mydatabase         # 데이터베이스 이름

(추가) 로컬 우분투 환경에서 SSH 키 파일 인식 문제 해결 방법

저는 로컬 환경에서 우분투를 사용하면서 SSH 키 파일이 제대로 인식되지 않는 문제가 발생했습니다.

 

WSL로 파일 복사: WSL에서는 파일 권한 설정이 제대로 적용되므로, SSH 키 파일을 WSL 파일 시스템으로 복사하여 사용합니다.

cp /mnt/c/Users/Username/Desktop/Path/to/key-file.pem ~/key-file.pem

키 파일 권한 수정: 복사한 키 파일의 권한을 적절히 설정합니다.

chmod 400 ~/key-file.pem

SSH 터널링 명령어 실행: 권한을 수정한 후, SSH 터널링을 설정합니다.

ssh -i ~/key-file.pem -N -L 3307:[RDS 엔드포인트]:3306 [EC2 사용자 이름]@[EC2 인스턴스 주소]

 

이러한 단계들을 따라 SSH 키 파일의 권한 문제를 해결하고 SSH 터널링을 성공적으로 설정할 수 있습니다!