예상치 못한 AWS 비용 청구 경험과 교훈

최근 지인들과 기획한 투두리스트 토이 프로젝트에서 배포를 처음으로 진행해보면서 AWS의 EC2, RDS, S3 서비스를 활용해봤습니다. 작은 프로젝트였고 사용량이 적어서 비용이 거의 발생하지 않을 거라고 생각했는데, 실제로는 예상보다 높은 요금이 청구되었습니다.

 

이번 글에서는 왜 작은 프로젝트에서도 요금이 많이 나왔는지 그 원인과 해결 방법, 그리고 AWS를 단순히 사용하는 것과 효율적으로 잘 활용하는 것의 차이에 대해 다뤄보려고 합니다.

 

문제 발견

프로젝트는 간단한 기능을 구현하는 토이 프로젝트였지만, 실제 청구서를 확인해보니 RDS 비용이 전체 과금의 큰 부분을 차지하고 있었습니다. “왜 이렇게 RDS 비용이 많이 나왔지?”라는 의문이 들었고, 여러 원인을 분석하게 되었습니다.

원인 분석

1. 인스턴스 유형 선택의 실수
   • 프리티어를 적용받을 수 있는 인스턴스는 주로 db.t3.micro나 db.t2.micro인데, 제가 사용한 인스턴스는 db.t4g.micro였습니다. t4g 계열은 ARM 기반 프로세서를 사용하지만, 프리티어 대상이 아니어서 비용이 청구된 것입니다.
2. 24시간 상시 가동
   • 사용 빈도가 낮았어도 인스턴스가 계속 켜져 있었기 때문에, 실제 사용 시간과 관계없이 비용이 누적되었습니다.
3. 자동 백업 및 스냅샷 비용
   • 자동 백업 기능과 스냅샷 설정도 비용에 영향을 미칠 수 있습니다. 필요 없는 백업이 계속 유지되어 있으면 추가 비용이 발생합니다.
4. 스토리지 및 데이터 전송 비용
   • 데이터 저장 용량이 예상보다 커지면 스토리지 비용이 늘어나고, 서비스 간 데이터 전송 역시 비용에 영향을 줄 수 있습니다. 특히, EC2와 RDS가 서로 다른 리전에 위치할 경우 추가 데이터 전송 요금이 발생할 가능성이 있습니다. (제 경우에는 해당 사항은 아니었지만 이런 상황에서는 비용이 더 늘어날 수 있습니다.)

 

해결 방안 및 교훈

• 인스턴스 유형 변경
  AWS 프리티어 대상 인스턴스로 변경(db.t3.micro 또는 db.t2.micro)하는 것이 비용 절감에 큰 도움이 됩니다.
• 불필요한 인스턴스 중지 또는 삭제
  사용하지 않는 경우 RDS 인스턴스를 중지하거나, 더 이상 필요 없다면 삭제하는 것도 효과적인 비용 절감 방법입니다.
• 자동 백업 및 스냅샷 관리
  필요 없는 백업은 주기적으로 삭제하고, 백업 정책을 재검토해야 합니다.
• 서비스 간 리전 일치
  데이터 전송 비용을 줄이기 위해 EC2, RDS, S3 등이 동일 리전에 위치하는지 확인할 필요가 있습니다.

 

결론

이번 프로젝트를 통해 그동안 AWS 배포를 직접 맡아본 적이 없어 몰랐던 여러 설정과 관리 요소들의 중요성을 깨닫게 되었습니다. 작은 프로젝트였음에도 불구하고 신경 써야 할 부분들이 생각보다 많았고, 이를 제대로 관리하지 않으면 예상치 못한 비용이 발생할 수 있다는 점을 몸소 체험했습니다.

 

또한 AWS는 단순히 서비스를 사용하기보다는 자원 관리, 자동화, 설계 최적화 등 다양한 측면에서 잘 활용해야 진정한 비용 절감과 안정적인 운영이 가능하다는 점을 다시 한 번 깨달았습니다.

 

이번 경험을 계기로 앞으로 배포 작업을 할 때는 더욱 철저히 준비해서 비용 최적화 및 안정적인 서비스 운영을 위한 다양한 전략들을 사전에 검토하고 체계적으로 배포를 진행해야겠습니다.