AWS ipv4 과금 정책에 따른 배포 수정(alb nginx로 대체, rds 퍼블릭 액세스 차단)

AWS에서 2024년 2월부터 public ipv4 정책이 변경되었다는 것을 다들 알고 계실지 모르겠다!

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

일단 난 몰랐다 🤣

 

다들 많이 쓰시는 ec2 + route53 + alb 조합으로 배포를 했다가 정책이 바뀌면서 요금이 계속 나와서 해결법을 고민하는 분들을 위해 나의 4개월간의 삽질 기록을 공유하고자 한다! 열심히 구글링을 해봐도 정보가 많이 없었기 때문에 ㅠㅠ

 

2024년 1월에 ec2 + route53 + alb 조합으로 Spring 서버를 배포하고 1달간 aws를 잘 확인하지 않았는데, 3월에 청구서를 받아보니 5만원 가량이 청구되어 있었다.

 

 

트래픽이 딱히 없는 서버라 깜짝 놀라서 어디서 나갔는지 확인해봤더니 RDS랑 VPC에서 청구된 금액이었다.

 

일단 RDS를 확인해보니 까먹고 삭제하지 못한 사용하지 않는 인스턴스가 하나 있었다. 이미 하나를 쓰는 중이었기 때문에 프리티어가 적용이 안되어서 사용하지 않아도 돈이 나가고 있던 것이다. 그래서 삭제해주었다.

 

그리고 중요한 VPC로 분류된 요금! 이때는 VPC에 대해 잘 모를 때라 갑자기 웬 VPC? 싶었는데 이것도 삭제해보고 저것도 삭제해보고 이래도 돈이 나가나? 좀 노가다식으로 ㅋㅋㅋ 알아본 결과 요금이 나오는 이유는 다음과 같다.

 

Amazon VPC IP Address Manager 의 퍼블릭 IP 인사이트를 보면, 

 

이런 식으로 현재 쓰이는 퍼블릭 ipv4 현황을 알려준다. 사실 저 주소 수만큼 돈이 나간다고 보면 된다. 

(*단, EC2 public IP 제외! 프리티어 적용돼서 무료이다)

나는 RDS에서 1개, ALB에서 2개, EC2에서 1개가 할당된 상태였고 EC2 주소를 제외한 저 3개의 주소에서 시간당 0.005달러씩 돈이 나가고 있었다. 이렇게 나가는 돈이 바로 청구서에서 VPC로 분류되어 표시되는 돈이었다. 그러면 저 퍼블릭 ipv4 주소들은 언제, 어디에서 할당된 것일까? 나는 명시적으로 ipv4 주소를 달라고 한 기억이 없는데 말이다!

 

1. RDS

RDS의 경우 mysql workbench나 인텔리제이 데이터베이스 이용해서 데이터 삽입하고 잘 돌아가나 보고~ 개발할 때 외부 접속이 필요해서 퍼블릭 액세스 가능으로 많이 사용하실 것 같은데, 저 퍼블릭 액세스를 가능하게 하는 순간 퍼블릭 ipv4 주소도 할당이 되기 때문에 과금이 된다.

 

이를 해결하기 위해서는 RDS의 퍼블릭 액세스를 아니요로 바꾸면 된다. ec2 인스턴스와 RDS를 같은 VPC에만 위치하게 하면 잘 작동하기 때문에 잘 돌아가는지 걱정하지 않아도 된다. 잘 돌아가는지 굳이 확인하고 싶다면 ec2에 ssh 접속한 후에 mysql install 해주고 명령어 써주면 db에 접근이 가능하다.

 

mysql -h 엔드포인트.rds.amazonaws.com -P 3306 -u 사용자 아이디 -p

 

 

 

2. ALB

나는 웬만하면 AWS 서비스를 쓰면서 해결하고 싶었어서 해결하는데 오랜 시간이 걸렸다. 여튼 ALB를 만들다 보면 무조건 2개 이상의 가용 영역을 선택해야 하는데, 저 가용영역&서브넷마다 하나씩 퍼블릭 ipv4가 할당이 된다. 근데 ALB를 생성하려면 최소한 2개 이상의 가용 영역을 선택해야되기 때문에 요금을 피하는 방법을 찾을 수 없었다.

 

그래서 다른 방법을 여러개 생각해 보았는데,

 

1) ipv4 대신 ipv6 할당

ec2 인스턴스, alb 등에 ipv4 대신 ipv6 사용해볼까 싶었는데 일단 vpc 서브넷부터 ipv6 허용되게 다 바꿔야 해서 여러모로 복잡하고 또 정확한 이유는 모르겠지만 ipv4를 제외하고 ipv6만 허용되게 하면 잘 돌아가지 않았다. 그리고 현재 ipv4만 쓰는 컴퓨터들도 많다고 해서 듀얼스택(ipv4+ipv6)이 아니라 ipv6만 쓰도록 구성하는 건 좋지 않은 듯해서 다른 방법을 찾기로 결정.

 

2) alb 대신 cloudfront로 ssl 적용

[AWS] 로드밸런서(ALB) IPv4 과금 제거 - 2

이 글을 보고 cloudfront를 사용해보자 싶어서 route53의 A에서 별칭 이용해서 cloundfront 연결해주고, cloudfront랑 ec2 도메인 연결하는 방식으로 배포해봤는데, https 배포까진 되는데 문제는 CORS 였다 ㅠㅠ 이미 spring 서버에서 CORS 설정을 다 해주었고, alb로 할 때는 프론트와의 통신 문제가 없었는데 아무래도 cloudfront 도메인을 경유해서 가는 것이다보니 CORS 오류가 자꾸 났다. cache policy 계속 수정하고 여러가지 시도를 해봤지만 보통 cloudfront의 s3랑 연동해서 쓰이고 서비스의 원래 목적이 ssl이 아니기 때문에 좋은 해결책은 아닌 것 같아서 안 쓰기로 했다.

 

3) nginx 사용

결국엔 이 방법이다 😅! ec2에 nginx 깔고~ 인증서 받고~ 밑의 링크에서 잘 정리해주셨기 때문에 자세한 건 해당 링크를 참고하면 될 것 같다. 참고로 나는 ec2 인스턴스에 nginx 인증서 받아서 ssl 적용한 뒤에 서버를 까는 걸 추천하는데, (본인은 docker-compose 사용) docker-compose 먼저 실행하고 nginx 사용하면 이유는 모르겠지만 과부하? 걸려서 인스턴스가 멈추거나 인증서가 발행 안되곤 했다.

 

[Nginx] SSL 적용하기

해당 글에서 약간의 오류와 자세하게 적혀있지 않은 부분을 추가하자면,

---

 

certbot 설치 부분에서 명령어 앞에 sudo 를 적어주어야 실행이 된다.

$ sudo add-apt-repository ppa:certbot/certbot

---

 

test.conf의 위치는 /etc/nginx/sites-available/test.conf 다음과 같고

    proxy_pass https//localhost:9001;

 

이 부분을 아래처럼 바꿔주어야 한다. 

    proxy_pass http://localhost:8080; # 스프링 서버는 8080포트에서 열린다

---

$ sudo nginx -t

위의 명령어 nginx 오류 찾기 좋다.

 

여튼 우여곡절끝에 배포를 완료하게 되어 매우 기쁘고! 이 글이 다른 분들께도 도움이 되었으면 하는 바람이다. 😇