AWS 인프라 비용 절감하기: 월 50% 절감한 인프라 점검기

GPT 가 만들어 준 썸네일... 글자가 짤렸지만 썸네일이 맘에 들어서 그냥 사용함

개요

기존 서비스가 지속적인 개발 단계에서 완전한 유지보수 단계로 전환되면서, 새로운 기능이나 콘텐츠가 더 이상 추가되지 않아 MAU/DAU가 크게 감소했다. 반면, 기능 추가가 활발하던 시절에 확장한 서버와 DB 스펙은 그대로 유지되어 인프라 비용은 오히려 증가했다. 결과적으로 월 비용은 약 2천 달러에서 3천 달러로 40~50% 가까이 상승했다.

 

사용량은 줄었는데 비용은 오르는 상황이 반복되자, 실장님께서 회의 때마다 시간이 날 때 비용 구조를 한번 점검해보자고 언급하셨고, 마침 맡고 있던 MVP 개발이 마무리되면서 본격적으로 비용 절감 작업을 시작할 수 있었다. 우선 하이퍼빌링 계정을 전달받아 전체 AWS 리소스를 분석하기 시작했는데, 큰 문제는 두 가지였다. 첫째, 리소스에 태깅이 제대로 되어 있지 않아 용도 파악이 어려웠고, 둘째, 인수인계가 제대로 이뤄지지 않아 어떤 역할을 하는 리소스인지 알기 어려운 경우가 많았다는 점이다. 이로 인해 초기 분석에 꽤 많은 시간이 소요되었다.

 

이번 작업에서는 운영 서버를 중심으로 우선 정리를 진행했고, 그 외 리소스는 텍스트 기반으로 간단히 정리했다. 최대한 빠르게 절감할 수 있는 항목부터 우선 조치했고, 앞으로 추가로 할 수 있는 절감 방안과 해야 할 작업들도 함께 정리해봤다.

 

현재 상황 분석 

현재 이 서비스는 운영 서버, 개발 서버, 테스트 서버용으로 각각 별도의 AWS 계정을 사용 중이다.

운영 서버 비용 변화 추이

월별 비용 그래프를 보면, 2024년 6~7월부터 인프라 비용이 급격히 상승했다. 이는 당시 새롭게 추가된 기능이 고성능 EC2 인스턴스를 필요로 했기 때문이다. 개발 초기부터 비용 증가가 예상되었고, 이를 Lambda 기반으로 구축하자고 제안했지만, 팀 내에 Lambda에 익숙한 인원이 없어 결국 EC2로 구현하게 되었다.

 

또한, 진작 삭제되었어야 할 리소스들이 여전히 남아 있었다. 예전 테스트용 서비스, 이미 도메인이 삭제된 프로젝트, 관리되지 않던 RDS와 CloudWatch 로그, 이상하게 구성된 WAF 등이 여기에 해당된다. 이를 하나씩 확인하고 정리하는 작업을 진행했다.

개발 서버와 테스트 서버도 상황은 비슷했으며, 불필요한 리소스 정리 및 비용 최적화를 순차적으로 수행했다.

 

조치사항

1. AWS RDS 삭제 및 옵션 변경

AWS를 운영하면서 가장 많은 비용이 지출되는건 뭘까? 바로 데이터베이스, RDS다. 그냥 켜놓기만해도 비용이 줄줄 나가는 돈먹는 하마다. 분석 결과 두가지 문제가 발견됐다.

 

첫번째는 사용하지 않는 데이터베이스들이 남아 있었다. 총 네개의 인스턴스가 떠있었는데, 두개가 사실상 사용하지 않고 있어서 삭제를 진행했다. 그나마 다행? 인지 Serverless로 구축되어있어서 상대적으로 적은 금액을 소모 중이었지만, 그래도 이 데이터베이스들이 각각 $100/월 씩은 먹고 있었다...

 

두번째는 우리 서버의 사용량이 확 줄었는데 온디맨드로 꽤 큰 인스턴스를 사용 중이었다. 그래서 메인 DB를 Serverless로 변경했다. 왜냐면 상대적으로 너무 적은 CPU 사용률을 보여줬기 때문이었다. 

 

운영 서버는 갑자기 사용량이 튈 수 있으니 기본 ACU를 개발서버의 2배로 잡아줬다. 개발 서버도 동일하게 전부 Serverless로 변경했다.

2. 불필요한 프로젝트 삭제 및 이전

사용하지 않는 프로젝트와 앱들을 제거하면서 EKS 노드 수가 줄었고, EC2 인스턴스도 다운사이징이 가능해졌다. 또한, 운영 서버의 capacity_type을 on-demand에서 on-demand + spot으로 변경하고, 선택 가능한 인스턴스 타입을 다양하게 설정하여 spot 종료 시 자동으로 대체될 수 있도록 구성했다

"prod" = {
  "instance_category" = ["m", "r", "c"]
  "capacity_type"     = ["on-demand", "spot"]
  "instance_type"     = [
    "c5.large", "c5a.large", "c6i.large", "m5.large", 
    "m5a.large", "m6i.large", "c6i.2xlarge", 
    "r6i.large", 
    "m6a.xlarge", "r6g.xlarge", "c6a.2xlarge"
  ]

또한, 테스트용으로 사용했던 EC2 인스턴스가 계정별로 몇 개씩 방치되어 있었고, 이를 제거함으로써 계정당 $100~$200/월 수준의 비용을 절감할 수 있었다.

 

마지막으로, EC2 기반으로 운영 중이던 주요 기능 중 하나를 Lambda로 이전함으로써 큰 폭의 비용 절감 효과를 얻었다. 이 기능은 낮은 호출 빈도 대비 높은 컴퓨팅 자원을 요구하는 특성이 있었기 때문에, EC2 대비 Lambda가 확실히 효율적이었다.

 

3. 그외 

- Security Hub / AWS Config : 이번 비용절감 작업을 하면서 가장 큰 의문이 들었던 리소스다. 이 두 서비스에서 약 $150/월 정도의 비용이 발생하고 있었다. 일부 알림과 통합이 설정되어 있었지만, 어느 곳에서 사용 중이었는지를 알 수 있는 방법이 없었다. (인수인계 받은 내용 중에는 없었다.) 모니터링 용도로 사용되었을 가능성은 있지만, 실제로 활용되지 않았다면 굳이 유지할 필요는 없다고 판단해 전부 비활성화했다. 

 

- CloudWatch : 일부 로그 그룹의 보관 기간이 무제한으로 설정되어 있었고, 특히 ALB 로그가 약 150GB에 달해 $80/월의 비용을 유발하고 있었다. 보관 기간을 30~60일로 조정하고, 이후 로그는 S3로 아카이브하는 방식으로 변경했다.

 

- WAF : 삭제된 리소스에 여전히 WAF가 연결되어 있었고, 불필요한 룰들도 다수 설정되어 있었다. 예를 들어, SQL Injection 방어 룰은 대부분의 ORM에서 이미 방어되고 있었고, 화이트리스트 룰은 보안 그룹에서 충분히 제어되고 있어 중복 설정으로 판단했다. 이에 따라 WAF를 정리하고 룰도 최소화했다.

 

- ElasticCache : Redis에서 Valkey로 변경하면서 비용 절감 효과를 보았고, 인스턴스 타입도 t4g 계열로 낮춰 전체 비용을 약 40~50% 줄일 수 있었다.

 

4. 엔터프라이즈 AWS Support 비용

가장 황당했던 부분 중 하나였다. 전체 사용량이 $15,000에 미치지 않음에도 불구하고, Enterprise Support Plan을 사용 중이었고, 그로 인해 전체 비용의 10%가 Support 비용으로 지출되고 있었다.

 

문제는 내가 이직하고 2년, DevOps를 맡은 이후 지난 1년 동안 Support에 단 한 번도 문의한 적이 없다는 점이었다. 즉시 Support Plan을 낮춰 약 $200/월의 비용을 절감할 수 있었다.

 

이 외에도 몇 가지 리소스를 다운 스케일링을 진행하고, 불필요한 데이터들을 이전 혹은 삭제를 진행했다.

결과

위에서 언급한 조치들을 포함해 여러 최적화 작업을 진행한 결과, 운영 계정 기준으로 약 30~40% 수준의 비용 절감을 이끌어낼 수 있었다. 개발 및 테스트 계정을 포함하면 전체적으로는 약 50%에 가까운 비용 절감 효과를 달성했다.

 

개발 서버는 운영 서버와 동일한 방식으로 리소스 정리와 구조 최적화를 진행했고, 테스트 계정은 대부분 사용되지 않는 리소스들이 방치되어 있어 이를 중심으로 삭제 작업을 진행했다.

 

만약에 시간이 더 주어졌다면 개발 서버의 EKS 클러스터와 데이터베이스를 미사용 시 종료시키는 방식까지 고려해봤을 것 같다. 현재 개발 서버만 해도 월 약 $1,000 정도(비용 절감 후 $800)의 비용이 발생하고 있기 때문에 이 방법만으로도 상당한 비용을 줄일 수 있을 것이다.

 

다만, 일정상 이 작업까지는 진행하지 못했다. 추후에 추가적인 비용 절감 요청이 들어올 경우, 이 작업을 가장 먼저 작업할 것이다.

마치며

우리 팀에서는 AWS를 테스트나 개발, 학습 용도로 자유롭게 사용하는 분위기다. 사용 자체에 대해 크게 제한을 두지 않다 보니, 다양한 리소스를 만들어보고 실험해보는 일이 많았고, 그 과정에서 방치된 리소스들도 적지 않게 쌓이게 되었다.

결과적으로, 누적된 리소스들과 잘 알지 못한 채 설정된 서비스들이 인프라 비용 상승의 주요 원인이 되었던 것 같다.

 

이번 작업을 통해 비용 절감을 위해 어떤 조치를 취할 수 있는지 실제로 경험하면서 배울 수 있었고, 내가 미처 몰랐던 AWS 기능들도 하나하나 알아가는 계기가 되었다. 특히, 리소스에 태그를 꼼꼼히 설정하는 것이 얼마나 중요한지를 체감했다.

 

그래서 새로 시작한 프로젝트에서는 가능한 모든 리소스에 용도별 태깅을 철저히 적용하며, 이후에도 인프라를 명확하게 관리할 수 있도록 정리하고 있다.