AWS Compute Optimizer, Azure Advisor, GCP Recommender 세 도구로 EC2·VM 인스턴스를 실제 사용량 기준으로 자동 라이트사이징하는 실전 워크플로우. 코드 예제, 함정 회피 전략, ARM 전환 팁까지 한 번에 정리한 2026년 최신 FinOps 가이드.
업데이트: 2026년 7월 25일
클라우드 인스턴스 라이트사이징(rightsizing)은 실제 CPU·메모리·네트워크·디스크 사용량 데이터를 근거로 EC2·VM·Compute Engine의 인스턴스 타입과 크기를 최적화하여, 성능 저하 없이 컴퓨트 비용을 20~50% 절감하는 FinOps 실무의 핵심 기법입니다. AWS Compute Optimizer, Azure Advisor, GCP Recommender 세 도구는 각 클라우드의 사용량 텔레메트리를 ML로 분석해 다운사이징·업그레이드·인스턴스 패밀리 변경 권고를 자동 생성하므로, 별도 스크립트 없이도 실행할 수 있죠. 이 글에서는 세 도구를 실전에서 어떻게 결합하는지, 무엇을 그대로 믿고 무엇을 반드시 검증해야 하는지 정리해봅니다.
라이트사이징은 워크로드가 실제로 소비하는 vCPU·RAM·네트워크·IOPS를 기준으로 인스턴스 스펙을 조정해 과잉 프로비저닝(overprovisioning)을 제거하는 프로세스입니다. FinOps Foundation의 2026년 State of FinOps 보고서에 따르면 응답 조직의 71%가 라이트사이징을 "가장 즉시 실행 가능한 절감 조치"로 꼽았고, 유휴 리소스 정리(zombie cleanup) 다음으로 ROI가 빠른 활동으로 나타났습니다.
솔직히 처음 FinOps 팀에 합류했을 때 저도 "한 단계 작은 인스턴스로 바꾸면 되겠지" 정도로 생각했습니다. 그런데 실무에서는 다음 네 가지 축을 동시에 검토해야 하더군요.
라이트사이징의 반대 개념인 업사이징도 존재합니다. 도구가 "under-provisioned"로 표시하면 성능 SLO를 위반할 위험이 있어 오히려 인스턴스를 키우는 편이 옳죠. 특히 AWS 스팟 인스턴스와 EC2 Auto Scaling을 함께 쓰는 환경에서는 헤드룸이 부족하면 스팟 중단 시 폴백이 실패하니, 업사이징 권고도 같이 챙겨봐야 합니다.
세 대형 클라우드는 각기 다른 라이트사이징 서비스를 제공하지만, 데이터 소스와 지원 리소스, 라이선스 모델에서 차이가 큽니다. 아래 표는 2026년 7월 기준 실무자가 도구를 선택할 때 확인해야 할 핵심 축을 정리한 것입니다.
| 항목 | AWS Compute Optimizer | Azure Advisor | GCP Recommender |
|---|---|---|---|
| 지원 리소스 | EC2, ASG, EBS, Lambda, Fargate, RDS, Idle 감지 | VM, VMSS, App Service, SQL, Cosmos DB | Compute Engine, GKE, Cloud SQL, IAM, BigQuery |
| 기본 히스토리 윈도우 | 14일 (유료 확장 시 최대 93일) | 최대 30일 (Cost Optimization 워크북) | 8일 (CPU/RAM), 30일 (idle) |
| 메모리 지표 | CloudWatch Agent 필요 | Azure Monitor Agent 필요 | Ops Agent 필요 |
| 가격 | 기본 무료, 확장 옵션 $0.0003432/시간·리소스 | 무료 | 기본 무료 (Active Assist 포함) |
| API/IaC 지원 | SDK, CloudFormation, EventBridge | Azure REST, Bicep, Event Grid | Recommender API, gcloud, Terraform |
| 다중 계정 지원 | Organizations 위임 관리자 필수 | Management Group 스코프 | Folder/Organization 스코프 |
| Savings 시각화 | 월 예상 절감액 표시 | 월 예상 절감액 표시 | 월 예상 절감액 (USD) 표시 |
세 도구 모두 "권고" 수준이며, 실제 변경은 사용자가 별도 워크플로우로 실행해야 합니다. Compute Optimizer만이 EBS 볼륨(gp2 → gp3 다운그레이드 등)까지 커버하는 점, Azure Advisor는 공식 문서에 따르면 예약 인스턴스 구매 권고까지 통합한다는 점, GCP Recommender는 CUD(Committed Use Discount) 시뮬레이션까지 하나의 API로 노출한다는 점이 특기할 만합니다.
AWS Compute Optimizer는 2019년 GA된 이후 지원 리소스가 계속 확장돼, 2026년 현재 EC2·Auto Scaling Group·EBS·Lambda·ECS on Fargate·RDS·Idle 자원까지 아우릅니다. Organizations의 위임 관리자 계정에서 활성화하면 모든 멤버 계정 데이터를 단일 뷰로 볼 수 있죠.
먼저 조직 전체에서 활성화합니다.
# 관리 계정에서 Compute Optimizer 위임 관리자 지정
aws organizations register-delegated-administrator \
--account-id 123456789012 \
--service-principal compute-optimizer.amazonaws.com
# 위임 관리자 계정에서 옵트인
aws compute-optimizer update-enrollment-status \
--status Active \
--include-member-accounts
# 확장 히스토리(최대 93일 + 추가 메트릭) 활성화 - 리소스당 유료
aws compute-optimizer put-recommendation-preferences \
--resource-type Ec2Instance \
--enhanced-infrastructure-metrics Active권고를 CSV로 뽑아 CI/CD 파이프라인에서 처리하려면 export API를 사용합니다. 아래는 조직 전체 EC2 권고를 S3로 익스포트하는 예시입니다.
aws compute-optimizer export-ec2-instance-recommendations \
--account-ids $(aws organizations list-accounts --query 'Accounts[?Status==`ACTIVE`].Id' --output text | tr '\t' ' ') \
--include-member-accounts \
--s3-destination-config bucket=finops-recommendations,keyPrefix=ec2/$(date +%Y-%m-%d)/ \
--file-format Csv \
--fields-to-export AccountId InstanceArn CurrentInstanceType RecommendationOptions_1_InstanceType \
RecommendationOptions_1_EstimatedMonthlySavings_Value UtilizationMetrics_CPU_MAXIMUM \
UtilizationMetrics_MEMORY_MAXIMUM Finding CurrentPerformanceRisk권고 등급은 OVER_PROVISIONED, UNDER_PROVISIONED, OPTIMIZED, NOT_OPTIMIZED로 나뉩니다. 저희 팀은 OVER_PROVISIONED이면서 CurrentPerformanceRisk = Very Low인 리소스만 자동 적용 대상으로 삼고, 나머지는 검토 큐로 보냅니다. Compute Optimizer는 P95 CPU가 40% 미만이고 메모리가 60% 미만일 때 다운사이징을 권고하는데, 이 임계값은 워크로드 특성(예: 야간 배치 잡)에 따라 오탐을 유발할 수 있어서 반드시 사용 패턴과 함께 봅니다.
Azure Advisor의 Cost 카테고리는 라이트사이징 관련 두 가지 대표 권고를 제공합니다. 하나는 Right-size or shutdown underutilized virtual machines이고, 다른 하나는 Buy reserved instances to save money over pay-as-you-go죠. 두 권고 모두 지난 7일간 CPU/네트워크 사용률을 기준으로 산출되며, 2026년부터는 30일 확장 옵션이 GA됐습니다.
Azure CLI로 조직 스코프에서 권고를 뽑는 예시입니다.
# Cost 카테고리의 활성 권고 조회 (구독 전체)
az advisor recommendation list \
--category Cost \
--query "[?impactedField=='Microsoft.Compute/virtualMachines'].{
VM:impactedValue,
Action:shortDescription.solution,
MonthlySavings:extendedProperties.savingsAmount,
Currency:extendedProperties.savingsCurrency,
RecommendedSize:extendedProperties.targetSku
}" \
--output table
# Management Group 전체로 확장하려면 각 구독에 대해 반복
for sub in $(az account list --query "[?state=='Enabled'].id" -o tsv); do
az account set --subscription "$sub"
az advisor recommendation list --category Cost > "advisor-$sub.json"
doneAdvisor는 임계값을 사용자 지정할 수 있는 몇 안 되는 도구 중 하나입니다. 기본 CPU 임계값은 5%(idle)와 20%(low usage)인데, HPC나 배치 워크로드에서는 이 값이 지나치게 보수적일 수 있어요. az advisor configuration create로 구독별 커스텀 임계값을 지정해봅시다.
az advisor configuration create \
--subscription $SUBSCRIPTION_ID \
--low-cpu-threshold 15 # 15% 미만이면 idle로 간주Azure Advisor의 강점은 실제 대상 SKU를 문자열이 아닌 구조화된 값으로 반환한다는 점입니다. 덕분에 Bicep/Terraform 파이프라인에서 targetSku를 그대로 vmSize 파라미터로 밀어넣어 IaC 변경 PR을 자동 생성할 수 있죠. 자세한 예약 인스턴스 대안은 AWS·Azure·GCP 약정 할인 완벽 비교 문서를 참고하세요.
Google Cloud는 라이트사이징을 Active Assist 브랜드 아래 여러 Recommender로 세분화해 제공합니다. 컴퓨트 관련 핵심 Recommender는 google.compute.instance.MachineTypeRecommender(머신 타입 추천)와 google.compute.instance.IdleResourceRecommender(유휴 인스턴스 탐지) 두 가지입니다. GKE 노드풀·Cloud SQL·BigQuery까지 별도 Recommender로 각각 존재하죠.
gcloud로 프로젝트 전체 머신 타입 권고를 조회해볼까요.
# 프로젝트의 모든 리전에서 머신 타입 권고 수집
for zone in $(gcloud compute zones list --format="value(name)"); do
gcloud recommender recommendations list \
--project=$PROJECT_ID \
--location=$zone \
--recommender=google.compute.instance.MachineTypeRecommender \
--format="table(
name.basename():label=RECOMMENDATION_ID,
description,
primaryImpact.costProjection.cost.units:label=MONTHLY_SAVINGS_USD,
content.operationGroups[0].operations[0].resource.basename():label=INSTANCE
)"
done
# 유휴 리소스(30일간 CPU < 3%, 네트워크 이그레스 없음)만 필터
gcloud recommender recommendations list \
--project=$PROJECT_ID \
--location=us-central1-a \
--recommender=google.compute.instance.IdleResourceRecommenderRecommender API의 재밌는 특징은 각 권고에 etag가 있어 낙관적 잠금(optimistic locking)이 가능하다는 점입니다. 자동화 파이프라인에서 권고를 "적용됨"으로 마킹하려면 gcloud recommender recommendations mark-succeeded를 --etag와 함께 호출합니다. 이렇게 하면 팀이 이미 처리한 권고를 중복 트리거하지 않게 됩니다.
GCP만의 차별점은 커스텀 머신 타입 권고입니다. n2-custom-4-16384처럼 4 vCPU / 16GB로 커스텀 조합이 가능해서, 표준 SKU에 억지로 맞추느라 발생하는 낭비가 적죠. Recommender는 워크로드가 표준 SKU보다 커스텀 타입이 저렴하다고 판단하면 그 조합을 제안합니다.
세 클라우드 모두 하이퍼바이저 레이어에서 CPU·네트워크·디스크는 자동 수집하지만, 메모리와 디스크 사용률은 게스트 OS 정보라서 에이전트를 설치하지 않으면 노출되지 않습니다. 이게 라이트사이징에서 가장 흔한 함정이에요. 메모리 지표가 없으면 도구는 "CPU가 낮으니 다운사이징하라"라고 자신 있게 권고하지만, 실제로는 메모리 90%를 쓰고 있어서 축소 시 OOM(Out Of Memory)이 발생하는 거죠. 저도 예전 프로젝트에서 이 함정에 딱 한 번 걸린 뒤로는 라이트사이징 프로젝트 시작 첫날에 에이전트 커버리지부터 확인합니다.
AWS는 CloudWatch Agent를 systemd 서비스로 배포합니다.
# Amazon Linux 2023 기준
sudo dnf install -y amazon-cloudwatch-agent
# SSM Parameter Store에 config 저장 (한 번만)
cat <<'EOF' | aws ssm put-parameter --name /cw-agent/rightsizing --type String --value file:///dev/stdin --overwrite
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": { "InstanceId": "${aws:InstanceId}" },
"metrics_collected": {
"mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 },
"disk": { "measurement": ["used_percent"], "resources": ["/"], "metrics_collection_interval": 60 }
}
}
}
EOF
# 인스턴스에서 config 로드
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c ssm:/cw-agent/rightsizingAzure는 Azure Monitor Agent(AMA)와 Data Collection Rule(DCR)을 사용하고, GCP는 Ops Agent가 메모리·디스크·프로세스 지표를 기본으로 수집합니다. 세 경우 모두 공식 설치 가이드를 따르되, 에이전트가 없는 인스턴스를 자동으로 태깅해 감사(audit) 리포트에 노출시키는 워크플로우를 만들어두는 것이 실무 팁입니다.
수백 개 인스턴스가 있는 환경에서 권고를 수동으로 처리하는 건 현실적이지 않습니다. 저희는 다음과 같은 5단계 파이프라인을 만들어 매주 반복 실행합니다.
instance_type 파라미터를 수정하는 Pull Request 자동 생성.다음은 3단계(필터링) 로직을 Python으로 구현한 예입니다. Compute Optimizer의 익스포트 CSV를 읽어 안전한 다운사이징만 골라냅니다.
import pandas as pd
df = pd.read_csv("s3://finops-recommendations/ec2/2026-07-25/recommendations.csv")
# 자동 적용 안전 조건:
# 1) 과다 프로비저닝 상태
# 2) 성능 위험 매우 낮음
# 3) 월 20 USD 이상 절감 예상 (미만은 PR 노이즈)
# 4) 팀 소유 태그 존재 (오너십 불명은 사람이 검토)
auto_apply = df[
(df["Finding"] == "OVER_PROVISIONED")
& (df["CurrentPerformanceRisk"] == "Very Low")
& (df["RecommendationOptions_1_EstimatedMonthlySavings_Value"] >= 20)
& (df["Tags_owner"].notna())
]
manual_review = df[df["Finding"].isin(["OVER_PROVISIONED", "UNDER_PROVISIONED"])] \
.loc[lambda x: ~x.index.isin(auto_apply.index)]
print(f"자동 적용: {len(auto_apply)}건, 예상 월 절감 ${auto_apply['RecommendationOptions_1_EstimatedMonthlySavings_Value'].sum():,.0f}")
print(f"수동 검토: {len(manual_review)}건")
# Terraform 변수 파일로 출력
auto_apply.to_json("tf-rightsizing-vars.json", orient="records")이 파이프라인은 클라우드 비용 자동화 거버넌스 가이드에서 다룬 Policy as Code 프레임워크와 결합하면 훨씬 강력해집니다. OPA/Rego 규칙으로 "프로덕션 태그가 있는 인스턴스는 카나리 승인 없이 다운사이징 금지" 같은 가드레일을 걸 수 있으니까요.
도구가 자동화됐다고 해서 결과가 항상 옳은 건 아닙니다. 컨설팅 현장에서 반복적으로 마주치는 다섯 가지 실수를 정리했습니다.
매일 03:00~04:00에만 CPU 90%를 치는 야간 배치 잡은 24시간 평균이 15%로 낮게 나타납니다. Compute Optimizer는 이 패턴을 감지하도록 개선됐지만, 여전히 P100 인식이 완벽하진 않아요. 크론 잡의 실행 창구를 태그로 명시하고, 그 시간대는 라이트사이징 제외 필터에 넣는 편이 안전합니다.
SQL Server, Oracle, RHEL은 vCPU 기반 라이선스를 부과합니다. m5.4xlarge → m5.2xlarge 다운사이징이 인스턴스 요금은 반값이지만 라이선스는 그대로면 총 비용이 오히려 오를 수 있죠. 특히 BYOL(Bring Your Own License)이 아닌 마켓플레이스 라이선스 인스턴스가 함정입니다.
t3.large를 t3.medium으로 축소하면 CPU 크레딧 축적률과 최대 잔고가 절반이 됩니다. 크레딧 소진 후 baseline(20%) 이상 사용하면 Unlimited 모드에서 초과 요금이 붙어 오히려 비싸질 수 있어요.
인스턴스 크기가 작아지면 EBS 대역폭과 네트워크 처리량 상한도 함께 줄어듭니다. 데이터베이스나 데이터 파이프라인 노드는 CPU에 여유가 많아도 IO 병목 때문에 다운사이징이 성능 참사를 낳는 경우가 있어요.
Graviton, Ampere, Tau T2A 같은 ARM 인스턴스는 시간당 요금이 20~40% 저렴합니다. 다만 네이티브 확장 모듈이 있는 Python(예: numpy, TensorFlow), Node.js 네이티브 애드온, 특정 JVM 벤더는 재컴파일이 필요하죠. 컨테이너 이미지는 반드시 멀티 아키텍처(docker buildx --platform linux/amd64,linux/arm64)로 빌드하고, ARM 노드에서 통합 테스트를 통과한 뒤 프로덕션에 배포하세요.
기본 기능(14일 CloudWatch 지표 기반 EC2·EBS·Lambda·Fargate·ASG 권고)은 완전 무료입니다. 다만 최대 93일 히스토리와 추가 지표(외부 메모리·디스크 IO 등)를 활용하려면 Enhanced Infrastructure Metrics 옵션을 리소스당 시간 단위(2026년 7월 기준 약 $0.0003432/시간)로 결제해야 합니다. Enterprise 규모에서는 이 유료 옵션이 만들어내는 추가 절감이 요금을 크게 상회하는 경우가 대부분이에요.
FinOps Foundation의 2026 벤치마크에 따르면 미최적화 상태 조직 기준 컴퓨트 예산의 20~50%, 평균 32%를 절감합니다. 여기에 세대 업그레이드(예: m5 → m7i)와 ARM 전환을 결합하면 60% 이상 절감도 가능해요. 반대로 이미 예약 인스턴스나 Savings Plans가 촘촘히 걸린 성숙한 조직은 5~15% 정도가 현실적입니다.
Trusted Advisor의 저활용 EC2 체크는 CPU와 네트워크만 보는 룰 기반 검사(4일 CPU 10% 미만 등)인 반면, Compute Optimizer는 최대 93일치 데이터를 ML 모델로 분석해 구체적인 대체 인스턴스 타입까지 제시합니다. 2026년 현재 AWS는 라이트사이징 목적으로는 Compute Optimizer를, 광범위한 보안·서비스 한도·내결함성 검사에는 Trusted Advisor를 사용하도록 권장하고 있습니다.
기술적으로는 가능하지만 프로덕션 환경에서는 권장하지 않습니다. Recommender는 리소스 재시작이 필요한 변경을 제안하는 경우가 많고(머신 타입 변경은 인스턴스 stop/start 필요), CUDs가 걸려 있으면 예상 절감액이 실제와 달라질 수 있어요. 개발/스테이징 환경만 자동 적용하고, 프로덕션은 PR 리뷰, 카나리, 전체 롤아웃 단계를 순차적으로 거치세요.
반드시 라이트사이징을 먼저 하세요. 잘못된 크기의 VM에 3년짜리 예약을 걸면 나중에 인스턴스를 축소할 때 예약이 매칭되지 않아 노는 예약을 그대로 결제하게 됩니다. 이상적인 순서는 (1) 유휴 리소스 정리, (2) 라이트사이징, (3) 워크로드 안정화 2주 관찰, (4) 예약 인스턴스 또는 Savings Plans 구매입니다.
AWS CloudWatch, Azure Monitor, GCP Cloud Logging의 관측성 비용을 60% 이상 절감하는 실전 가이드. Infrequent Access 로그 클래스, Basic Logs 이관, 제외 필터, OpenTelemetry 테일 샘플링까지 30일 체크리스트로 정리했습니다.
클라우드 비용 할당 태그로 쇼백·차지백 리포트를 자동화하세요. AWS, Azure, GCP의 태그 설정, FOCUS 1.2 표준, 미태그 리소스 자동 교정, 부서별 차지백 SQL까지 실전 가이드.
AWS 스팟 인스턴스로 온디맨드 대비 최대 90% EC2 비용을 절감하는 2026년 최신 전략 가이드. EC2 Auto Scaling 혼합 인스턴스 정책, price-capacity-optimized 할당 전략, EventBridge 중단 자동화, Graviton 스팟 조합까지 실전 예제 코드와 함께 설명합니다.