Claude를 활용한 AWS 인프라 비용 최적화

스타트업에서 인프라 비용은 늘 민감한 주제입니다. 특히 B2B SaaS를 운영하다 보면, 트래픽 패턴이 B2C와는 확연히 다르다는 걸 체감하게 됩니다. 이 글에서는 Claude를 활용해 사내 인프라 리소스 사용량을 분석하고, 트래픽 패턴에 맞게 비용을 최적화한 경험을 공유합니다.

 

---

우리 서비스의 트래픽 특성

우선 저희는 B2B로 서비스를 운영하고 있고 고객사 대부분이 국내 기업이고, 몇가지 트래픽 특성을 갖고있습니다.

• 고객사의 80%가 9to6 근무 패턴을 따릅니다.
• 해외 접속은 전체의 약 10%에 불과합니다.
• 새벽 시간대와 주말의 트래픽은 주간 피크 대비 극히 낮습니다.

이 사실은 이미 사내 모든 서버 개발자가 알고 있었지만, 실제로 인프라 리소스가 얼마나 낭비되고 있는지는 데이터를 들여다보기 전까지 체감하지 못했습니다. 

이 정도의 인프라 변경을 하려면 주간 회의 때 분석과 근거를 통한 설득이 필요한데, 개발만으로도 너무 바쁜 상황이었기 때문에 우선순위가 낮았던 거 같다..

---

Claude로 리소스 사용량 분석하기

Datadog Fargate Agent 메트릭과 ECS CloudWatch 메트릭 데이터를 Claude에 넘겨 분석을 요청했습니다. 단순히 "CPU 사용률이 낮다"는 평균값이 아니라, 시간대별 트래픽 분포와 개별 태스크의 피크 사용량까지 함께 분석할 수 있었습니다.

Claude로 AWS 인프라를 어떻게 분석하지? 라는 궁금증이 있으실 수 도 있는데 로컬에 AWS CLI만 설치되어 있다면 프롬포팅에 해당되는 AWS_PROFILE을 사용해서 분석해달라고 프롬포팅하시면 됩니다.

 

분석 결과 새벽과 주말에도 주간과 동일한 리소스를 유지하는 것은 명백한 낭비 라는 결론을 얻을 수 있었습니다. 

 

동시에 한 가지 우려도 있었습니다. "혹시 야간에 갑자기 트래픽이 몰리면?" — 하지만 ECS Fargate의 오토스케일링이 있기 때문에, 기본 태스크 수를 줄이더라도 트래픽 급증 시 스케일아웃으로 충분히 대응할 수 있다고 판단했습니다. 기본값을 낮추되, 안전망은 그대로 유지하는 전략입니다.

---

분석 결과

평일 업무시간 vs 새벽 vs 주말 CPU 사용률

•  요일별: 월/화가 가장 높고(10.9%), 일요일이 가장 낮음(1.95%)
• 주말은 평일의 79% 수준 — 동일한 20대 태스크를 유지할 이유 없음
• 새벽(00-06)은 피크의 절반 수준 — 04~05시가 가장 낮아 2.34%
• 메모리는 평일 41.71% / 주말 30.91%로 큰 차이 없음

수치가 왤케 낮지?

실제로는 일부 태스크가 요청을 집중적으로 처리하고 있지만, 나머지 유휴 태스크까지 포함해서 평균낸 값이라 수치가 낮아보입니다.
오히려 태스크 수가 과잉이라는 근거로 판단했습니다. 개별 태스크 피크가 100%+ 찍히는 건 앞서 분석에서도 확인됐고 태스크 수가 많다고 판단했습니다.

---

최적화 1: server-prod  상시 태스크 축소 (XX → XX)

Before
clap-server-prod가 최소 20대로 운영되고 있었습니다. "혹시 모를 트래픽"에 대비한 설정이었지만, 실제 메트릭을 분석해보니 20대까지는 필요하지 않았습니다.

After
기본 태스크 수를 15대로 축소하고, 피크 시에는 오토스케일링으로 대응하도록 변경했습니다.

 

비용 절감

태스크 스펙	2 vCPU / 8 GB / ARM64
태스크당 시간 비용	(2 × 0.03238)+(8×0.00356) = $0.0932/hr
절감량	5태스크 × 24hr × 0.0932=11.19/일
연간 절감	$4,084

 

5대를 줄였을 뿐인데, 연간 약 $4,000 이상의 절감 효과가 생겼습니다. 인프라 비용은 이렇게 "당연하다고 생각한 설정"에서 새어나가는 경우가 많습니다.

물론 저희는 AWS에서 제공하는 Savings Plans을 사용해서 연간 결제를 하고 있기때문에 해당 비용이 직접적이진 않습니다.

---

최적화 2: server-prod 야간 스케일링 (15 → 5)

태스크 수를 줄인 것에서 한 발 더 나아가, 시간대별 스케일링을 도입했습니다.

왜 야간 스케일링인가?
B2B 서비스의 트래픽 패턴은 예측 가능합니다. 고객사의 90%가 9to6 근무를 하고, 해외 접속이 10%에 불과하다면 — KST 22시 이후에 15대를 유지할 이유가 없습니다.

 

스케일링 스케줄

ECS Scheduled Auto Scaling을 활용해 단계적으로 축소하도록 설정했습니다.

06:00 ~ 20:00	15대	주간 운영 (피크 시 오토스케일링)
20:00 ~ 22:00	15 → 5 점진적 감소	전환 구간
22:00 ~ 06:00	5대	야간 최소 운영

 

전환 구간을 두어 급격한 태스크 감소로 인한 요청 드롭을 방지했습니다. 그리고 야간에도 5대를 유지하는 이유는, 해외 접속(10%)과 배치 작업 등 최소한의 트래픽을 안정적으로 처리하기 위해서입니다.

 

비용 절감

야간 축소 태스크	10대 (15 → 5)
야간 시간	8시간/일
절감량	10태스크 × 8hr × 0.0932=7.46/일
연간 절감	$2,723

 

나머지 부분도 비슷한 영역에서 절감을 해서 생략하도록 하겠습니다. 

 

Right-sizing에 대한 주의사항

태스크 "수"를 줄이는 것과 태스크 "스펙"을 줄이는 것은 다른 문제입니다.
처음에는 태스크 스펙(vCPU/Memory)도 축소할 수 있을 거라 의심했습니다. CloudWatch 기준 평균 CPU가 1~5%였기 때문입니다. 하지만 Datadog에서 개별 태스크의 피크를 확인해보니, CPU가 95~100%까지 치솟는 순간이 있었습니다.

20대 태스크의 평균 CPU는 낮아 보이지만, 특정 태스크에 요청이 몰리는 순간에는 리소스를 최대로 사용합니다. 거기에 사이드카(Datadog Agent, Fluent Bit)가 태스크당 약 300MB의 메모리 오버헤드를 차지하고 있어 메모리도 여유가 있다고 판단하긴 힘들었습니다.
실제로 트래픽 급증 시 스펙 부족으로 장애가 발생한 이력이 있었기에, 이 부분은 현 스펙을 유지하기로 결정했습니다.

 

추가로 데이터독에서 Exclusion Filter 를 사용한 비용절감 내용도 이후에 추가하도록 하겠습니다.