💸 DynamoDB 비용 절감 여정

최근 AWS 비용을 점검하면서 DynamoDB의 청구 금액이 예상보다 높게 나오고 있다는 걸 확인했다. 특히 개발 환경(dev)과 운영 환경(prod) 모두에 동일한 방식으로 세팅되어 있어 불필요한 리소스 낭비가 있다고 문득 생각이듬. 이번 글에서는 제가 실제로 진행한 DynamoDB 비용 절감 여정을 공유하려고 합니다.

🧾 해결방안 탐색 및 해결

🪄 Step 1. Standard → Standard-IA 전환 (개발 환경)

먼저 개발 환경의 모든 테이블을 Standard → Standard-IA(Infrequent Access) 스토리지 클래스로 변경했습니다.

• Standard-IA 특징
  • 자주 접근하지 않는 데이터를 위해 설계
  • GB당 저장 비용은 저렴
  • 단 읽기/쓰기 요청이 많이 발생했을때 추가 비용 발생 가능성 높음

👉 dev 환경은 테스트 시에만 접근하므로 IA로 변경 시 읽기/쓰기 요청은 적지만 저장 데이터는 많기 때문에 확실히 유리했다.

🕒 Step 2. TTL + DynamoDB Streams + Firehose

다음은 오래된 데이터(Old Data) 정리 단계입니다. 데이터를 삭제하는 대신 추적 가능성을 유지하면서도 비용을 줄이는 방식을 택했습니다.

• TTL(Time To Live) 설정
• DynamoDB Streams 활성화
• Lambda → Firehose → S3 파이프라인 구축
  • Lambda : DynamoDB Stream [REMOVE] 이벤트 수신 후 Firehose로 JSON 전송
  • Firehose : JSON → Parquet 포맷 변환
  • S3(Data Lake) : 장기 보관용 저장소로 아카이빙 → Glue(Data Catalog) 구조화해서 Athena에서 SQL 조회도 가능

👉 삭제된 데이터도 로그 형태로 S3에 안전하게 보관

⚙️ Step 3. On-Demand → Provisioned 전환 (운영 환경)

운영 환경(prod)에서는 트래픽이 꾸준했기 때문에 온디맨드(On-Demand) 과금 방식이 오히려 비효율적이었습니다. 평균 RCU/WCU(읽기/쓰기 용량 단위)가 안정적으로 유지되는 상태라면 프로비저닝(Provisioned) 모드로 전환하는 것이 훨씬 저렴합니다.

• Before : On-demand (요청당 과금)
• After : Provisioned (고정 용량 + Auto Scaling)

👉 Auto Scaling도 같이 설정하여 트래픽 급증 시 자동으로 용량을 확장

💭 회고

솔직히 말하면 이번 프로젝트에서 DynamoDB에 대해 깊이 이해하지 못한 채 개발에만 집중해왔던 것 같다. 테이블 만들고 데이터 넣고 조회만 되면 “됐다”라고 생각했던것같다. 당시엔 “온디맨드(On-Demand) 방식이면 내가 쓴 만큼만 요금이 나오겠지” 라고 단순하게 생각했다. 하지만 청구서를 보고 많은걸 느꼈던것같다. 이번 비용 절감 작업을 하면서 느꼈던 건 운영 효율도 결국 개발의 일부고 단순히 코드만 잘 짜는게 아니라 서비스의 동작 원리와 과금 구조를 이해하는것이 진짜 백엔드 개발자의 완성이라는 걸 새삼 깨달았다.