Amazon ECS 오토스케일링 모니터링 2026, 20초 지표·CloudWatch 비용·운영 기준

Amazon ECS 오토스케일링 모니터링을 위한 CloudWatch 대시보드와 컨테이너 서비스 운영 점검 장면 — ECS 오토스케일링은 빠른 scale-out보다 지연, 배포 상태, 비용 알림을 함께 봐야 한다.

Amazon ECS 오토스케일링 모니터링은 CPU 평균값 하나에 task 수를 연결하는 작업이 아니다.

서비스가 늦게 늘어나는지, 너무 늦게 줄어드는지, 배포 중 scale-in이 멈추는지, CloudWatch 관측 비용이 커지는지를 같이 봐야 한다.

AWS News Blog는 Amazon ECS Service Auto Scaling이 20초 단위 high-resolution metrics와 metric publishing 최적화를 지원한다고 소개했다.

이 변화는 “무조건 빠르게 늘어난다”보다 “scale-out 판단 지연을 더 촘촘히 볼 수 있다”로 해석하는 편이 안전하다.

이 글은 해당 발표를 번역하지 않는다.

ECS를 운영하는 팀이 target tracking, step scaling, scheduled scaling, Container Insights, IAM 권한, CloudWatch 비용을 어떤 순서로 점검할지 정리한다.

결론부터 말하면 먼저 볼 숫자는 desired task가 아니다.

p95 지연, pending task 시간, scale-out trigger delay, running task gap, 로그 GiB를 함께 봐야 운영 판단이 흔들리지 않는다.

핵심 요약

Amazon ECS 오토스케일링 모니터링은 CPU·메모리·ALB 요청 수뿐 아니라 p95 latency, queue depth, PendingTaskCount, deployment 상태를 같이 봐야 한다.
20초 high-resolution metrics는 scale-out 반응성을 점검하는 근거가 될 수 있지만, CloudWatch 비용과 알람 피로를 같이 검토해야 한다.
target tracking은 기본 선택지로 좋고, step scaling은 명확한 임계치와 운영자가 있을 때만 좁게 쓰는 편이 안전하다.
발행 전 운영 기준은 min/max capacity owner, cooldown, 로그 보존, IAM 권한, 실패 scale-out 런북까지 통과해야 한다.

이 글이 필요한 사람

Amazon ECS Fargate 또는 EC2 launch type에서 서비스 task 수가 늦게 늘어나는 원인을 찾는 SRE
ALB request count, CPU utilization, queue depth 중 어떤 지표로 target tracking을 걸지 정해야 하는 DevOps 담당자
CloudWatch Container Insights를 켜야 하는지, 비용과 가시성을 같이 따져야 하는 플랫폼 리드
배포 중 scale-in과 scale-out이 어떻게 움직이는지 설명해야 하는 백엔드 팀장
EKS가 아니라 ECS를 쓰면서도 Kubernetes식 운영 지표와 비용 리뷰를 도입하려는 팀

1. ECS 오토스케일링은 task 수보다 반응 시간을 먼저 본다

ECS Service Auto Scaling은 Application Auto Scaling을 통해 서비스의 desired count를 늘리거나 줄인다.

AWS 문서 기준으로 target tracking, step scaling, scheduled scaling, predictive scaling 같은 선택지가 있다.

운영자가 실제로 겪는 문제는 “desired count가 늘었는가”보다 “사용자가 느끼기 전에 늘었는가”다.

그래서 Amazon ECS 오토스케일링 모니터링은 scale-out event와 사용자 지연을 같은 타임라인에 놓아야 한다.

관측 대상	볼 지표	좋은 신호	위험 신호
수요 증가	ALBRequestCountPerTarget, queue depth, lag	지표 상승 뒤 target tracking이 일관되게 반응한다	CPU는 낮은데 queue만 쌓여 scale-out이 늦다
task 공급	DesiredTaskCount, RunningTaskCount, PendingTaskCount	desired와 running의 차이가 짧게 닫힌다	pending task가 오래 남고 capacity provider가 못 따라온다
사용자 경험	p95 latency, 5xx error rate, timeout count	scale-out 전후 p95가 SLA 안으로 돌아온다	task는 늘었지만 p95와 오류율이 그대로다
배포 상태	DeploymentCount, rollout event, unhealthy task	배포 중에도 scale-out은 필요한 만큼 일어난다	새 task health check 실패가 scaling 문제처럼 보인다
비용	idle task minutes, log GiB, custom metric count	scale-in과 로그 보존이 비용을 제한한다	피크 이후 task와 로그가 계속 쌓인다

이 조건이면 오토스케일링 정책을 손볼 가치가 있다.

트래픽 피크가 명확하고, 지연이 task 부족과 함께 움직이며, 애플리케이션 내부 병목이 아니라 capacity 반응 문제가 확인될 때다.

반대로 p95가 높지만 CPU와 queue가 낮다면 task 수 문제가 아닐 수 있다.

DB connection pool, downstream API, lock contention, cold cache를 먼저 확인해야 scaling 정책을 건드려도 효과가 보인다.

2. 20초 지표는 빠른 scale-out의 근거지만 공짜 판단은 아니다

AWS 발표의 핵심은 ECS Service Auto Scaling이 high-resolution 20-second metrics와 metric publishing 최적화를 지원한다는 점이다.

기존 1분 단위 지표만 보던 팀이라면 짧은 피크를 더 빨리 감지할 여지가 생긴다.

하지만 20초 지표는 운영 설계 없이 켜는 장식이 아니다.

CloudWatch 고해상도 지표, custom metric, Container Insights, 로그 수집은 비용과 알람 피로를 만들 수 있다.

지표 주기	맞는 상황	주의할 비용	운영 판단
1분 기본 지표	일반 웹 API, 완만한 트래픽 증가	기본 ECS 지표 중심이면 비용 부담이 낮다	대부분의 서비스는 먼저 여기서 기준을 잡는다
20초 high-resolution	짧은 이벤트 피크, checkout, flash sale, queue burst	고해상도 지표와 알람 수 증가를 검토한다	scale-out 지연이 실제 매출이나 SLA에 영향을 줄 때만 쓴다
custom metric	queue depth, Kafka lag, job backlog처럼 CPU와 무관한 수요	metric cardinality와 API call 비용을 본다	CPU target보다 업무 지표가 더 정확할 때 필요하다
Container Insights	task/container 수준 원인 분석과 capacity planning	custom metric과 log ingestion 비용이 붙는다	장애 분석 가치가 비용보다 클 때 켠다

실무 시나리오 하나.

커머스 결제 API가 5분짜리 타임딜에서만 급증한다면 1분 지표는 늦을 수 있다.

이 경우 20초 지표와 scheduled scaling을 함께 검토해야 피크 시작 전에 최소 task를 올릴 수 있다.

실무 시나리오 둘.

사내 백오피스 API가 하루 종일 완만하게 움직인다면 20초 지표보다 target tracking 목표값, cooldown, 로그 보존 기간을 정리하는 쪽이 먼저다.

3. target tracking, step scaling, scheduled scaling을 같은 용도로 쓰지 않는다

AWS 문서는 target tracking이 선택한 metric을 목표값 근처로 유지하도록 CloudWatch alarms와 scaling adjustment를 관리한다고 설명한다.

CPU나 request count처럼 capacity가 늘면 지표가 내려가는 성격에는 기본 선택지로 맞다.

step scaling은 운영자가 CloudWatch alarm과 조정 폭을 직접 만든다.

임계치가 뚜렷하지 않거나 트래픽 패턴이 자주 바뀌는 서비스에서는 오히려 튜닝 부담이 커진다.

scheduled scaling은 예측 가능한 시간대 피크에 맞다.

월요일 오전 9시, 점심 주문 시간, 배치 시작 전처럼 반복되는 부하는 reactive scaling만 기다리지 않는 편이 낫다.

정책	맞는 지표	장점	보류 기준
Target tracking	CPU, memory, ALBRequestCountPerTarget, queue depth	목표값 중심으로 scale-out과 scale-in을 자동 조정한다	metric이 capacity와 비례하지 않으면 부정확하다
Step scaling	명확한 alarm breach, 긴급 queue spike	임계치별 조정 폭을 직접 정할 수 있다	알람 설계자가 없으면 과잉 증설과 진동이 생긴다
Scheduled scaling	예측 가능한 시간대와 캠페인 피크	피크 전에 min capacity를 올릴 수 있다	예외 피크와 장애성 트래픽에는 단독으로 부족하다
Predictive scaling	반복되는 장기 패턴이 충분한 서비스	과거 패턴 기반의 proactive scaling을 기대할 수 있다	신규 서비스나 이벤트성 트래픽에는 근거가 약하다

실무 판단은 이렇게 잡는다.

먼저 target tracking으로 기준을 만들고, 예측 피크는 scheduled scaling으로 보강하며, step scaling은 운영자가 설명할 수 있는 특정 alarm에만 붙인다.

정책을 늘리는 것보다 중요한 것은 timeline이다.

alarm breach, desired count 변경, running task 증가, target registration, p95 회복까지 한 화면에서 봐야 “정책이 효과가 있었는지” 말할 수 있다.

4. CloudWatch와 Container Insights는 원인 분석 비용까지 포함해 본다

Amazon ECS는 CloudWatch로 cluster와 service 지표를 보낸다.

Fargate 서비스는 CPU와 memory utilization 지표가 자동으로 있고, EC2 기반 task는 agent와 권한 조건을 확인해야 한다.

Container Insights with enhanced observability는 cluster, service, task, container 수준의 자세한 telemetry와 dashboard를 제공한다.

AWS 문서는 이 데이터가 performance log events로 수집되고 CloudWatch가 집계 metric을 만든다고 설명한다.

중요한 단서가 있다.

AWS 문서는 Container Insights metrics가 custom metrics로 과금된다고 명시한다.

장애 분석 가치는 크지만, 모든 cluster에 무조건 켜면 관측 비용이 운영 비용 설명을 어렵게 만들 수 있다.

관측 레이어	얻는 것	비용/권한 확인	추천 적용
ECS 기본 지표	CPU, memory, service utilization	기본 지표 범위와 agent 조건 확인	모든 production service의 최소 기준
ALB 지표	request count, target response time, 5xx	Load Balancer 비용과 로그 설정 확인	HTTP API scale 판단에 필수
Custom metric	queue depth, lag, business backlog	namespace와 dimension cardinality 제한	CPU와 무관한 worker service에 필요
Container Insights	task/container별 network, storage, restart, health	custom metric과 log ingestion 비용 확인	장애 원인 분석이 잦은 핵심 cluster부터
Application trace	사용자 요청과 scaling event 연결	sampling, PII redaction, retention 확인	p95와 5xx 원인 분리에 필요

이 조건이면 Container Insights를 켜는 편이 맞다.

task 재시작, pending, network, ephemeral storage, 배포 실패 원인을 자주 놓치고 있고, 장애 한 번의 비용이 custom metric 비용보다 큰 서비스다.

이 경우는 보류한다.

개발 cluster와 sandbox가 많고, owner가 없고, 로그 보존 기간이 기본값으로 방치되어 있다면 먼저 계정별 관측 정책부터 정리해야 한다.

5. 배포 중 오토스케일링 동작을 따로 검증한다

target tracking 문서는 ECS deployment가 진행되는 동안 scale-in은 꺼지고 scale-out은 계속될 수 있다고 설명한다.

이 동작은 배포 안정성을 위해 중요하지만, 비용과 용량 타임라인에는 흔적을 남긴다.

배포 중 p95가 오르면 운영자는 scaling 문제가 아닌데 scaling 정책부터 의심하기 쉽다.

새 task가 health check를 통과하지 못하거나 image pull이 늦거나 dependency가 느린 경우도 같은 증상으로 보인다.

배포 상황	확인할 이벤트	scaling과 구분할 신호	조치 기준
새 revision 배포	deployment started, task set change	old/new task 비율과 health check 실패	배포 이벤트를 scaling 그래프 위에 표시
scale-out 동시 발생	desired count 증가, running task 증가	target group 등록 지연과 pending 시간	capacity provider와 target health를 같이 확인
scale-in 지연	deployment in progress, scale-in suspended	피크 종료 뒤 task가 늦게 줄어든다	비용 알림과 cooldown 검토
roll back	unhealthy task, 5xx 증가	새 task만 오류가 높다	scaling 정책 수정 전에 revision 원인 분리

실무 시나리오 셋.

배포 직후 CPU가 오르고 target tracking이 task를 늘렸지만 p95가 개선되지 않는다.

이 경우 새 task가 downstream connection을 초기화하지 못하거나 target group health check가 늦는지 먼저 확인한다.

오토스케일링 모니터링 대시보드에는 deployment marker가 있어야 한다.

deployment marker가 없으면 scale-out 실패, health check 실패, 애플리케이션 지연을 같은 문제로 착각한다.

6. IAM과 운영 권한은 scaling 정책의 일부로 본다

ECS 운영에서 IAM은 보안팀 문서에만 들어가는 항목이 아니다.

누가 scaling policy를 수정하고, 누가 CloudWatch alarm을 만들고, 누가 production service에 execute-command로 들어갈 수 있는지가 운영 리스크를 만든다.

AWS IAM 문서는 ECS 리소스 접근을 인증과 권한으로 제어한다고 설명한다.

Service Auto Scaling 관련 권한도 별도로 확인해야 하며, CI role과 사람 계정의 권한을 섞으면 원인 추적이 어려워진다.

권한 대상	허용 기준	차단 기준	감사 포인트
Scaling policy 수정	platform/SRE 승인과 변경 기록	개발자 개인 계정의 직접 수정	Change ticket, CloudTrail event
CloudWatch alarm 수정	metric owner와 alert owner가 명확한 경우	알람 피로를 줄인다는 이유의 임의 disable	alarm history, suppression reason
Task role	애플리케이션 최소 권한	관측을 위해 과도한 AWS API 권한 부여	IAM Access Analyzer, policy review
Execution role	image pull, logs, secrets 접근 최소화	모든 secret에 접근 가능한 wildcard	secret ARN scope, rotation
ECS Exec	break-glass와 session logging 조건	상시 production shell 접근	접속 사유, session log, 승인자

비용 절감을 위해 task 수를 줄이는 실험도 권한이 있어야 한다.

그러나 권한이 넓으면 장애 중 누군가 alarm을 끄거나 max capacity를 과하게 올린 뒤 기록이 남지 않는 문제가 생긴다.

운영팀은 “수정 가능한 사람”과 “볼 수 있는 사람”을 분리해야 한다.

대시보드는 넓게 열고, scaling policy와 IAM role 수정은 좁게 두는 편이 안전하다.

7. 비용 절감은 scale-in, 로그 보존, custom metric 수에서 나온다

오토스케일링을 붙였다고 비용이 자동으로 줄지는 않는다.

scale-out은 빠른데 scale-in이 보수적이면 피크 이후에도 task가 남고, Container Insights와 로그가 과하게 쌓이면 관측 비용이 별도 청구서가 된다.

CloudWatch 가격 페이지는 가격 정보가 region과 사용 방식에 따라 달라질 수 있으므로 최신 가격 탭을 확인하라고 안내한다.

그래서 글 안에서 단가를 고정하지 말고, metric 수와 log GiB를 월간 리뷰 항목으로 남기는 편이 낫다.

비용 항목	측정 질문	줄이는 방법	주의할 점
유휴 task	피크 종료 후 running task가 얼마나 남는가	scale-in cooldown과 min capacity 재검토	너무 빠른 scale-in은 재피크에 취약하다
Fargate/EC2 capacity	desired count와 실제 처리량이 비례하는가	traffic class별 서비스 분리	DB 병목이면 task 증설 효과가 낮다
Custom metric	namespace와 dimension이 과하게 늘었는가	service/env/metric 중심으로 cardinality 제한	pod/task ID 같은 고카디널리티 차원 금지
Logs	request body와 debug 로그가 계속 쌓이는가	retention, sampling, redaction 적용	장애 분석에 필요한 key는 남긴다
Alarms	중복 알람이 많아 on-call을 지치게 하는가	symptom alarm과 cause dashboard 분리	조용한 알람은 없는 알람과 같다

이 조건이면 비용 최적화가 가능하다.

피크 이후 유휴 task가 반복되고, log GiB가 늘고, custom metric dimension이 서비스 수보다 빠르게 증가한다면 scaling과 관측 정책을 함께 손봐야 한다.

이 경우는 증설부터 한다.

p95와 5xx가 이미 SLA를 깨고 있고, pending task가 길며, capacity provider가 부족하다면 비용 절감보다 availability 회복이 먼저다.

8. Amazon ECS 오토스케일링 모니터링 런북 스켈레톤

아래 YAML은 실제 배포 파일이 아니라 운영 리뷰용 런북 예시다.

목표는 scaling policy와 관측 지표, 비용 차단선, IAM 조건을 한 문서에서 확인하게 만드는 것이다.

# ecs-autoscaling-runbook.yaml
# 목적: Amazon ECS 오토스케일링 모니터링을 CPU 평균값 하나가 아니라 지연, 큐, 배포 상태, 비용으로 함께 점검한다.
# 실제 cluster/service 이름, metric namespace, threshold는 운영 환경에서 다시 채운다.

service:
  cluster: prod-app-cluster
  service: checkout-api
  launch_type: fargate-or-ec2
  owner: platform-sre
  business_owner: commerce-platform

scaling_policy:
  primary: target-tracking
  target_metric: ALBRequestCountPerTarget-or-custom-queue-depth
  backup_policy: scheduled-scaling-for-known-peak
  step_scaling_allowed: only-for-clear-alarm-breach
  cooldown_review_required: true

metrics:
  must_watch:
    - CPUUtilization
    - MemoryUtilization
    - ALBRequestCountPerTarget
    - RunningTaskCount
    - PendingTaskCount
    - DeploymentCount
    - TaskRestartCount
    - p95_latency_ms
    - 5xx_error_rate
  high_resolution_watch:
    - scale_out_trigger_delay_seconds
    - pending_task_age_seconds
    - queue_depth_or_lag

cost_controls:
  hard_block_if:
    - no_min_max_capacity_owner
    - no_scale_in_review
    - no_budget_alarm_for_cloudwatch_custom_metrics
    - no_log_retention_policy
    - no_runbook_for_failed_scale_out
  weekly_review:
    - desired_vs_running_task_gap
    - scale_out_events
    - scale_in_events
    - idle_task_minutes
    - container_insights_custom_metric_count
    - log_ingestion_gib

security:
  task_role_least_privilege: required
  execution_role_secret_scope: minimal
  deployment_write_access: limited_to_ci_role
  cloudwatch_dashboard_write_access: platform_only
  production_exec_access: break_glass_only

월간 운영 리뷰에는 metric export나 수동 집계 CSV를 붙일 수 있다.

아래 스크립트는 desired task 급증, p95 지연, scale-in 부재, pending task, log GiB를 빠르게 표시하는 검사용 예시다.

#!/usr/bin/env python3
# ecs_autoscaling_guard.py
# CloudWatch metric export CSV나 운영 집계 CSV를 넣기 전, ECS 오토스케일링 위험 신호를 빠르게 확인하는 예시다.

import csv
from pathlib import Path

path = Path('ecs_autoscaling_daily.csv')
required = [
    'date', 'service', 'avg_running_tasks', 'max_desired_tasks', 'p95_latency_ms',
    'scale_out_events', 'scale_in_events', 'pending_task_minutes', 'log_gib'
]

if not path.exists():
    raise SystemExit('ecs_autoscaling_daily.csv 파일을 먼저 준비하세요')

with path.open(newline='', encoding='utf-8') as f:
    rows = list(csv.DictReader(f))

if not rows:
    raise SystemExit('CSV에 데이터가 없습니다')

missing = [column for column in required if column not in rows[0]]
if missing:
    raise SystemExit('필수 컬럼 누락: ' + ', '.join(missing))

for row in rows:
    running = float(row['avg_running_tasks'] or 0)
    desired = float(row['max_desired_tasks'] or 0)
    p95 = float(row['p95_latency_ms'] or 0)
    scale_out = float(row['scale_out_events'] or 0)
    scale_in = float(row['scale_in_events'] or 0)
    pending_minutes = float(row['pending_task_minutes'] or 0)
    log_gib = float(row['log_gib'] or 0)
    warnings = []

    if desired >= running * 2 and desired >= 4:
        warnings.append(f'desired task spike without matching average load: desired={desired:.0f}, running_avg={running:.1f}')
    if p95 > 1200:
        warnings.append(f'p95 latency above review threshold: {p95:.0f}ms')
    if scale_out > 20 and scale_in < 3:
        warnings.append(f'scale-out frequent but scale-in weak: out={scale_out:.0f}, in={scale_in:.0f}')
    if pending_minutes > 10:
        warnings.append(f'pending task minutes high: {pending_minutes:.1f}')
    if log_gib > 30:
        warnings.append(f'CloudWatch log ingestion high: {log_gib:.1f}GiB')

    if warnings:
        print(row['date'] + ' | ' + row['service'] + ' | ' + ' / '.join(warnings))

이 스켈레톤의 목적은 자동 튜닝이 아니다.

운영 회의를 “task를 몇 개로 할까”에서 “어떤 신호가 늦었고 어떤 비용이 남았나”로 바꾸는 것이다.

9. 발행 전 점검 순서와 중단 기준

Amazon ECS 오토스케일링 모니터링을 production에 붙이기 전에는 부하 테스트와 장애 시나리오를 먼저 통과해야 한다.

dashboard가 예쁘게 보여도 scaling event와 사용자 지연이 연결되지 않으면 운영 기준으로 부족하다.

서비스별 traffic class와 SLA를 정하고 p95 latency 기준을 문서화한다.
target tracking 후보 지표를 CPU, memory, ALB request count, queue depth 중에서 고른다.
짧은 피크가 매출이나 SLA에 영향을 주는 서비스만 20초 high-resolution metric을 검토한다.
scheduled scaling이 필요한 반복 피크와 reactive scaling이 필요한 예외 피크를 분리한다.
배포 중 scale-out, scale-in 지연, health check 실패를 staging에서 재현한다.
Container Insights와 custom metric 비용을 계정별 예산 알림에 연결한다.
scaling policy, CloudWatch alarm, IAM role 수정 권한을 CI와 platform role로 제한한다.
2주 파일럿 뒤 p95, 5xx, pending task, idle task, log GiB가 기준을 넘으면 증설보다 정책 재설계를 먼저 한다.

중단 기준도 필요하다.

high-resolution 지표를 켰는데 p95가 줄지 않거나, log GiB와 custom metric 비용만 늘거나, on-call 알람 피로가 커진다면 production 확대는 보류한다.

승인 기준은 더 구체적이어야 한다.

scale-out이 목표 시간 안에 일어나고, scale-in이 비용을 회수하며, 배포 marker와 scaling event가 연결되고, 권한 변경이 감사 로그로 남으면 다음 서비스로 확장할 수 있다.