AWS 비용 최적화 실무 정리

1. 정리 배경

AWS를 운영하다 보면 어느 순간 이런 질문에 도달한다.

• 리소스를 줄여도 괜찮은가?
• 비용을 줄이면서도 안정성은 유지할 수 있는가?
• 트래픽이 크지 않은 서비스에서 Blue-Green 배포는 과한가?

이 글은
ECS Fargate + ALB 기반 서비스 운영 경험을 바탕으로,
실제 사용률을 근거로 비용 최적화를 고민한 과정과 판단 기준을 정리한 기록이다.

특정 고객사나 서비스의 내부 정보가 아니라,
일반화된 운영 시나리오와 사고 흐름에 초점을 맞췄다.

---

2. 관찰된 운영 환경 (일반화)

• ECS 서비스 다수 운영
• 모든 서비스에서
  • CPU 사용률: 지속적으로 낮은 수준
  • 메모리 사용률: 여유 있음
• 트래픽 급증 거의 없음
• 무중단 배포 필요성은 있으나,
  대규모 트래픽을 전제한 구조는 아님

즉,

“항상 2개 이상의 Fargate 태스크를 유지해야 할 만큼의 부하는 아니다”

라는 판단이 가능한 환경이었다.

---

3. 핵심 질문

❓ 정말 항상 Fargate 2개가 필요할까?

일반적으로 ECS + ALB 환경에서는:

• 안정성 확보를 위해
• 무중단 배포를 위해

Fargate 태스크 2개 이상을 상시 유지하는 경우가 많다.

하지만 이 방식에는 단점도 분명하다.

• 실제 사용률 대비 비용 낭비
• 트래픽이 거의 없는 시간에도 동일 비용 발생

그래서 다음과 같은 대안을 검토했다.

“평상시에는 1개, 배포 시에만 2개로 늘릴 수 없을까?”

---

4. Fargate 1개 + Blue-Green 배포 시 고려사항

4.1 Fargate 1개일 때의 구조적 한계

Blue-Green 배포는 본질적으로:

• 기존 버전(Blue)
• 신규 버전(Green)

이 동시에 떠 있어야 하는 전략이다.

따라서 Fargate가 1개일 경우:

• 두 버전을 동시에 유지할 수 없음
• 배포 중 일시적인 서비스 중단 가능성 존재
• CPU / 메모리 경합 가능성 증가

➡️ 엄밀한 의미의 무중단 배포는 불가능

---

4.2 그럼에도 선택 가능한 이유

다음 조건을 만족한다면,
Fargate 1개 운영도 충분히 현실적인 선택지가 된다.

• 트래픽이 낮고 급증하지 않음
• 배포 빈도가 낮음
• 배포 중 일시적인 리소스 확장이 가능함
• ALB 헬스체크가 안정적으로 동작함

---

5. 현실적인 운영 전략:

“1 → 2 → 1” 패턴

전략 요약

• 평상시
  • Fargate 태스크 1개
• 배포 시
  • 태스크 수를 2개로 일시 확장
• 배포 완료 후
  • 다시 1개로 축소

이 방식은:

• 비용 절감
• 배포 안정성 확보

를 동시에 만족시킬 수 있다.

---

6. 태스크 수 조절 방법

6.1 수동 방식 (CLI 기반)

배포 시작 전:

 

aws ecs update-service \ --cluster <cluster-name> \ --service <service-name> \ --desired-count 2

배포 완료 후:

 

aws ecs update-service \ --cluster <cluster-name> \ --service <service-name> \ --desired-count 1

• 단순하지만 명확
• 배포 절차에 포함시키기 쉬움

---

6.2 자동 방식 (Auto Scaling)

• CPU 또는 메모리 사용률 기준
• Target Tracking Scaling Policy 사용

예:

• CPU 70% 이상 → 태스크 증가
• CPU 50% 이하 → 태스크 감소

➡️ 배포 트래픽이 짧고 명확하다면
수동 방식이 오히려 예측 가능성이 높음

---

7. ALB + 태스크 축소 시 주의점

❗ 가장 중요한 리스크

태스크가 줄어드는 순간,
ALB가 종료된 태스크로 트래픽을 보내지 않을까?

이 문제는 설정에 따라 실제로 발생할 수 있다.

---

7.1 Health Check 설정

• Health Check 간격을 과도하게 길게 잡으면 안 됨
• 태스크 종료 시 빠르게 비정상으로 인식해야 함

권장 방향:

• 짧은 interval
• 낮은 unhealthy threshold

---

7.2 Deregistration Delay

태스크가 종료될 때:

• 기존 요청은 정상적으로 처리
• 새로운 요청은 더 이상 받지 않도록 해야 함

이를 위해 Deregistration Delay 설정이 필수

일반적으로:

• 60 ~ 300초 권장

---

7.3 축소 타이밍

• 트래픽이 거의 없는 시간대에 축소
• 배포 직후 일정 시간 모니터링 후 축소

---

8. Blue-Green 배포는 누가 제어하는가?

자주 생기는 오해 중 하나는 이것이다.

“Blue-Green 배포는 개발자가 코드로 구현하는 건가?”

정리하면:

• ALB가 자동으로 트래픽을 분산/전환하는 것이 아님
• CodeDeploy 같은 배포 도구가 전략을 제어
• ALB는 단지 “지정된 타겟 그룹”으로 트래픽을 전달할 뿐

즉,

• Blue-Green 전략은 설정과 배포 도구의 역할
• Fargate 태스크 수 조절은 별도의 운영 전략

이다.

---

9. 최종 판단 기준

이 구조가 적합한 경우:

• 트래픽이 크지 않음
• 비용 민감도가 높음
• 배포 중 약간의 운영 개입이 가능함
• 장애 영향 범위가 제한적임

적합하지 않은 경우:

• 대규모 트래픽
• SLA가 매우 엄격함
• 배포 자동화 수준이 매우 높음

---

10. 마무리

AWS 비용 최적화는
**“무조건 줄이는 것”이 아니라
“현재 서비스 성격에 맞는 구조를 선택하는 것”**이다.

• 상시 2개 태스크가 반드시 필요한가?
• 배포 시에만 리소스를 더 쓰는 게 더 합리적이지 않은가?

이 질문에 데이터와 구조로 답할 수 있다면,
그 자체로 이미 운영 관점의 사고를 하고 있는 것이다.

---

 

※ 본 글은 실제 운영 경험을 일반화하여 재구성한 사례이며, 특정 고객사, 서비스, 인프라 구성과는 무관합니다.