AWS 프리티어인데 돈이나간다(RDS, Public IPv4)

dev_Hyun·2024년 2월 13일

😨 0.41 달러가 주는 불안감

약 4일 전, 새로운 사이드 프로젝트의 인프라 구축을 담당하게 되어 AWS 신규가입을 했고, 1년간 프리티어 혜택을 활용할(뽕뽑을) 계획으로 서비스를 이용하기 시작했습니다.

우선 반드시 사용할 EC2와 RDS를 생성했고, EC2에 탄력적 IP를 발급받아 할당했습니다. 과거(21년도)의 경험을 바탕으로 해당 작업 까지는 프리티어 계정에서 1년간 비용이 발생했던 점이 전혀 없었기에 안심하고 있었습니다만,,,

0.41달러 과금 정보

이럴 수가.. 고환율 시대(1,333원)에 0.41 달러의 비용이 누적된 것을 발견했습니다. 💸

다른 개발자분들의 AWS 프리티어 수 백 만원대 비용이 과금되었다는 눈물없이 못듣는 썰 만큼 제 사례가 치명적인 것은 당연히 아니지만, 비용이 발생한 사건에 '펀하고 쿨하게'(끄덕) 돈을 내고 넘어갈 일은 아니라고 판단했습니다.

먼저, 비용이 발생한 원인을 파악하고 제가 목표로하는 클라우드 아키텍처를 구성하기 위한 대처까지 정리해보겠습니다.

🤔 왜 비용이 발생했는가

AWS서비스별요금

즉시, 결제 및 비용 관리 페이지의 청구 및 결제 - 청구서 탭을 클릭해 스크롤을 조금 내려 서비스별 요금 영역을 확인해보았습니다.

이곳에서 요금이 발생한 서비스가 VPC 그 중에서도 In-use public IPv4 임을 파악했습니다.

한국어로 번역해보자면, 사용중인 퍼블릭(공용) IPv4 주소 때문에 비용이 발생했습니다.

Elastic IP (탄력적 IP) 때문일까?

이상했습니다. 제가 직접 IP 관련해서 주소를 할당 받은 것은 탄력적 IP 주소 1개 뿐이며, 프리티어 계정에서 요금이 발생하지 않도록 다음 규칙을 따르고 있었는데 말이죠.

인스턴스와 연결되지 않은 Elastic IP는 시간당 $0.005 (약 5원)이 과금되기 때문에 Elastic IP(탄력적 IP)를 실행중인 프리티어 인스턴스인 EC2와 연결 한다.
인스턴스를 중지하거나 삭제해 탄력적 IP가 연결되어 있지 않으면 비용이 발생한다.

😥 원인은 AWS Public IPv4 요금 변경

AWS Public IPv4 키워드로 검색해보니, AWS 한국 블로그(링크)와 AWS 공지사항(링크)에서 친절하게 원인을 알려주고 있었습니다.

아무튼돈이나간다는뜻

주요내용은

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

왜 이런 요금 정책 변경이 발생했는지도 설명되어 있습니다.

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

조금 더 제 상황에 맞게 해석하자면, Free-Tier 사양에 해당되는 EC2를 생성하고, 인스턴스에 탄력적 IP를 월 750시간 이내로 사용하는 것은 비용이 청구되지 않는다는 의미입니다.

그럼 저는 어느 서비스의 Public IPv4가 비용을 발생시켰던 것일까요?

💡 이제 Public RDS는 비용이 발생해요

조금 더 구글링을 하다보니, 커뮤니티 댓글에서 단서를 찾을 수 있었습니다. 프리티어 계정에서, RDS 의 접근 방식을 Public 하게 설정하여 생성했었고, Public IPv4가 자동으로 할당된 것이 문제의 원인인 것 같다는 가능성을 확인했습니다.

okky커뮤니티에나같은상황이 (출처 : https://okky.kr/questions/1488081)

🔍 IPAM 기능으로 Public IPv4 확인하기

AWS 공식 블로그(링크)을 다시 살펴보면 AWS의 요금 정책 변경과 더불어, 어느 서비스가 Public IPv4를 가지고 있는지 퍼블릭 IPv4 주소 사용을 보다 쉽게 모니터링, 분석 및 감사할 수 있도록 무료(중요하죠) 기능을 지원한다는 내용을 발견할 수 있습니다.

23년 8월에 출시된 Amazon VPC IP Address Manager의 새로운 기능인 Public IP Insights 입니다. 이 기능을 통해 현재 사용중인 퍼블릭 IP 유형과 EIP 사용량에 대해 파악할 수 있습니다.

Public IP Insights 기능을 사용하기 위해서는 서비스를 생성해야 합니다. 콘솔 검색창에 IPAM을 검색해 Amazon VPC IP Address Manager을 클릭하고, Create IPAM 을 클릭합니다. (해당 기능에 대해 더 자세히 알고 싶을 경우 해당 공식 링크를 참고하세요!)

IPAM생성 (이미지출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/ipam/tutorials-get-started-console.html)

Name tag : 선택 옵션 입니다. 공란으로 두어도 무방합니다.
Description : 선택 옵션 입니다. 역시 공란으로 두어도 무방합니다.
Operating Regions : 어느 리전에 대해 IP들을 탐색할지 선택할 수 있습니다. 저의 경우 Asia Seoul 리전에서만 EC2와 RDS 등의 서비스를 생성했으니 Seoul 리전만 선택합니다.

생성이 완료되고, Public IPv4들이 탐색되기까지 약 5분 정도의 시간이 소요됩니다. 탐색이 완료된 결과 화면은 아래와 같습니다.

특히 저와 같이 EC2 생성, EIP(탄력IP) 연결, Public 접근 허용 RDS를 생성한 상황이라면 동일한 인사이트 화면을 마주하게 되실 겁니다. 위 화면처럼 총 퍼블릭 IP의 개수는 2개(Amazon 소유의 EIP 1개, 서비스 관리형 IP 1개) 그리고 연결되지 않은 EIP는 0개임을 확인할 수 있습니다.

(이미지 출처 : AWS)

조금 더 아래로 스크롤을 하면, AWS에서 제공한 참고이미지(위)와 같은 화면처럼, 각 IP 별로 어떤 유형에 해당되는지도 분석할 수 있습니다.

제가 마주한 Public IP addresses 목록은 총 2개로 RDS가 사용중인 서비스 관리형 IP 1개 그리고 EIP(탄력적IP)가 나타났습니다. 이로써 IPAM 기능을 통해 확실하게 RDS의 Public IPv4가 비용을 발생했음을 알 수 있었습니다.

그저 검색엔진에 AWS Free Tier RDS 생성 방법을 검색해서 참고자료들을 따라하며 RDS를 생성했었는데, 퍼블릭 액세스를 허용했던 것이 문제였습니다. 퍼블릭 액세스를 허용할 경우 Public IP주소를 데이터베이스에 할당하기 때문입니다.

퍼블릭액세스허용

🤗 해결 방안 - Private RDS 사용

프로젝트 개발 단계 이전에 해당 문제를 발견한게 정말 다행이란 생각이 들었습니다. 과감하게 문제가 되는 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/
- https://blog.nuricloud.com/aws-alternatives-to-public-ipv4-charges/

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

🚧 Private RDS 생성

생성할 때 유의할 점은 퍼블릭 액세스를 아니요으로 선택해야 Public IP 주소가 할당되지 않습니다.
EC2 컴퓨팅 리소스에 연결을 선택하면 RDS가 필요한 서브넷 그룹과 VPC 보안그룹을 자동으로 추가합니다.
이 외 설정은 프리티어 한도 내에서 과금이 발생되지 않도록 적절히 선택 후 생성을 누르면 완료됩니다.

생성된 데이터베이스의 연결된 컴퓨팅 리소스에서는 EC2와 연결된 것을, 보안그룹 규칙에서는 인바운드, 아웃바운드 규칙이 적용되어 있는 것을 확인할 수 있습니다. 참고한 링크 : EC2 터널링으로 private subnet RDS 접속하기

🔗 RDS와 DB tool SSH 터널링 연동

DB Tool 에서 Private 접근이 허용된 RDS에 접근하기 위해 SSH 터널링 방법을 사용했습니다.
DBeaver, MySql Workbench, DataGrip, 인텔리제이 내장 Database Tool 등 많은 도구들이 DB 연결 시에 SSH 터널링을 지원하기 때문에 어떤걸 사용해도 무방합니다. 저는 DataGrip을 사용했습니다. 설정 순서는 아래 이미지와 같습니다.

🌉 SSH Tunneling

ssh 터널링이란, “출발지에서 목적지로 한 번에 이동할 수 없을 때, 목적지로 이동 가능한 지점을 거쳐서 이동하는 우회 접근 방법” 입니다. 로컬 서버에서 DB 서버에 접근하고 싶지만, RDS가 private subnet에 구축되어 있을때 외부에서는 RDS에 접속할 수 없습니다. 그렇기 때문에 DB 서버에 접근 가능한 EC2 서버를 우회해서 접근합니다. (즉, 로컬 서버 → EC2 서버 → DB 서버의 형태로 접근)

참고 링크 :

🔗 RDS와 Local 실행 환경 연동

그렇다면 Datagrip과 같은 DB Tool에서 RDS에 접근하는 것이 아니라, IDE를 통해 로컬에서 서버를 실행했을 때 RDS와 연결하려면 어떻게 해야할까요? 이전 처럼 SpringBoot 프로젝트에서 Public 접근이 가능한 RDS의 경우 application 설정파일을 아래와 같이 작성했었습니다.

application.yml

그러나, 이제는 EC2를 통해서만 RDS에 접근 가능한 Private RDS를 생성했기 때문에 아래의 명령어를 통해 터미널에서 SSH 터널링 세션을 생성해야 합니다.

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

해당 명령어는 로컬에서 SSH 프로토콜을 사용해 시스템간 연결을 생성합니다. localhost(127.0.0.1)의 3307 포트로 요청을 하면, EC2 를 거쳐 RDS로 요청이 전달됩니다

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

위 명령어는 Linux나 OSX기반의 터미널이 있는 OS를 대상으로 하기 때문에 Window 환경인 저는 Git Bash 터미널을 이용했습니다. PuTTY를 사용해도 무방합니다.

(이미지출처:https://steady-coding.tistory.com/626)

여기서 조심해야 할 점은 로컬에 설치된 DB와 동일한 Port를 사용할 경우 포트 충돌이 일어나 Permission denied가 발생할 수 있습니다.

(이미지출처: https://velog.io/@kjyeon1101/Spring-수숙관-프로젝트-실행하기Spring-Boot-IntelliJ-MySQL-ssh)

따라서, 사용중이지 않는 PID를 찾아서 사용해야 합니다. 저의 경우 로컬에 설치된 MySQL이 3306, 33060 포트를 사용하기 때문에 3307 로컬 포트를 사용했습니다.

만약 SSH Tunneling 명령어를 입력했을 때, 아래와 같이 등록된적 없는 host 경고 메시지가 발생하면 yes 입력합니다.

(이미지 출처 : https://info-lab.tistory.com/254)

참고 링크

🔍 IPAM 다시 확인해보기

문제가 된 Public 접근 허용된 RDS를 제거하고, Private 접근만 허용된 RDS를 생성하고 난 뒤, 다시 IPAM에 진입해 Public IPv4 목록을 확인하면 위와 같이 저에게 할당된 Public IPv4는 탄력적 IP 1개만 존재하도록 변경된 것을 확인할 수 있습니다.

(번외)😧 Public RDS를 삭제했는데도 청구서 금액이 올랐어요

분명 퍼블릭 액세스를 허용한 RDS를 삭제하고, Private 접근만 허용한 RDS를 생성했으며, Public IPv4 1개도 EC2에만 연결되어 있는 것을 검토했음에도 불구하고 청구서 금액이 올라서 놀라셨나요?

네,, 저는 놀랐습니다 하하.. 문제가 되었던 RDS를 삭제했으니 이제 금액이 더이상 오르지 않겠지 생각했으나, 시간당 0.005 USD가 청구되는 Public IPv4의 사용량과 그에 따른 금액이 0.41 USD → 0.46 USD으로 오르는 것을 목격했습니다.

청구서금액이올랐다

금액이 오른 이슈를 포함해 프리티어와 관련된 여러 궁금증을 해소하기 위해 AWS 지원센터에 문의글을 남겼고, 매크로 같은 형식적인 답변을 받았습니다만, 덕분에 그 안에서 이유를 파악할 수 있었습니다.

AWS 프리 티어를 사용하는 동안 실수로 요금이 발생했습니다. 요금이 다시 청구되지 않도록 하려면 어떻게 해야 하나요?

과금 및 비용 관리 콘솔에서 활성 리소스의 사용량 및 요금 정보 업데이트에는 약 24시간이 걸립니다. (출처 : 답변에 포함된 AWS 지식센터 링크)

청구서는 실시간으로 책정된 금액이 표시되지 않는다는 것을 알게되었습니다. 실제로 EC2 생성일자, RDS 생성일자, RDS 삭제일자를 개인적으로 기록해둔 것과 비교대조 해보니 92.231 시간이 최종적으로 Public 접근을 허용한 RDS가 활성화 되어 있던 시간이었으며, 이 이후로는 더이상 금액이 증가하지 않음을 확인했습니다.

❗ 느낀 점

적은 비용이더라도 금액이 청구되는 것과 청구되지 않는 것 사이에는 커다란 심리적 차이가 존재했습니다.
인프라 구축 과정을 프로젝트 개발 단계 이전에 시작한 것이, 늦지 않게 이슈를 해결할 수 있었던 것에 도움을 주었다고 생각합니다.
공지사항, 블로그, 매크로 답변 무엇이든 공식 참고 자료는 시간이 걸리더라도 천천히 읽어보는 것이 좋다는 것을 또 한번 깨닫게 되었습니다. 문제 파악 방법, 원인, 해결 방법 모두 공식 참고 자료 내에 포함되어 있었습니다.