Right-sizing EC2 з AWS Compute Optimizer: економія до 60% у 2026

Оновлено: 15 червня 2026

AWS Compute Optimizer, це безкоштовний сервіс машинного навчання, який аналізує метрики CloudWatch ваших EC2-інстансів і видає рекомендації щодо right-sizing з оцінкою економії до 60% на місяць. У 2026 році сервіс охоплює EC2, EBS, Lambda, Auto Scaling Groups, ECS на Fargate, RDS (MySQL/PostgreSQL), а також виявляє idle-ресурси. У цьому посібнику я покажу, як ввімкнув Compute Optimizer для організації з 14 акаунтів, як інтерпретую його рекомендації та автоматизую міграцію на Graviton-інстанси через CI/CD.

• AWS Compute Optimizer безкоштовний; для рекомендацій потрібно мінімум 14 днів метрик CloudWatch (можна знизити до 30 хвилин з опцією external metrics ingestion).
• Memory utilization не збирається за замовчуванням, тож треба встановити CloudWatch Agent або підключити Datadog чи Dynatrace через external metrics provider.
• Рекомендації типу «migrate to Graviton» дають до 40% кращу ціна/продуктивність на m7g, c7g, r7g сімействах порівняно з x86-аналогами.
• Idle Resource Detection (GA з 2024) знаходить EC2 з CPU <1% та мережею <10 KB/s протягом 14 днів. Типова економія коливається в межах $50–200 на інстанс.
• Auto Scaling Groups recommendations враховують політики масштабування та target tracking метрики, на відміну від базового right-sizing окремих інстансів.
• Інтеграція з Cost Explorer показує оцінку економії з урахуванням ваших активних Compute Savings Plans та Reserved Instances.

Що таке AWS Compute Optimizer і як він працює?

AWS Compute Optimizer, це регіональний сервіс, який споживає історичні метрики CloudWatch (CPU, мережа, диск, пам'ять) ваших обчислювальних ресурсів, проганяє їх через моделі машинного навчання та повертає рекомендації одного з типів: UNDER_PROVISIONED, OVER_PROVISIONED, OPTIMIZED або NOT_OPTIMIZED. На відміну від простих порогових алертів CloudWatch, Compute Optimizer враховує пікові патерни навантаження, добові цикли та burstable credits для T-сімейств.

Скажу чесно: за моєю практикою, типова EC2-фліт після першого скану Compute Optimizer містить 30–45% over-provisioned інстансів. Сервіс розглядає до 140 типів EC2 (включно з m7i, c7g, r7a, m7a сімействами) та підбирає три варіанти заміни з ризиком міграції LOW, MEDIUM або HIGH. Ризик визначається тим, наскільки сильно нова конфігурація відрізняється від поточної за vCPU, RAM та network bandwidth.

Усі рекомендації EC2 за замовчуванням базуються лише на CPU та network метриках. Пам'ять не входить у стандартний набір CloudWatch, тому без додаткової конфігурації Compute Optimizer припускає, що пам'ять не є обмежувальним фактором. Це призводить до помилкових рекомендацій типу «downsize to t3.medium» для Java-додатків з 6 ГБ heap. Я особисто бачив, як саме на цьому втратили день розслідувань. Тому крок з CloudWatch Agent (нижче) обов'язковий, якщо ви хочете довіряти рекомендаціям.

Активація Compute Optimizer для AWS Organizations

Для multi-account середовища активація через payer-акаунт економить тижні на ручному включенні по кожному акаунту окремо. Я керую 14-акаунтною організацією і ввімкнув сервіс через AWS CLI з management-акаунта таким чином:

# Спочатку реєструємо Compute Optimizer як trusted service в Organizations
aws organizations enable-aws-service-access \
  --service-principal compute-optimizer.amazonaws.com

# Делегуємо адміністрування dedicated security/finops акаунту (опціонально, але рекомендовано)
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal compute-optimizer.amazonaws.com

# Вмикаємо Compute Optimizer для всієї організації
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Перевіряємо статус по всіх акаунтах
aws compute-optimizer get-enrollment-statuses-for-organization \
  --query 'accountEnrollmentStatuses[?status!=`Active`]'

Після активації перші рекомендації з'являться через 14 днів. Щоб не чекати, я рекомендую увімкнути external metrics ingestion для пам'яті, якщо у вас уже є Datadog або Dynatrace. Це скоротить час до перших коректних рекомендацій з тижнів до годин.

Для контролю IAM-доступу до рекомендацій по дочірніх акаунтах призначте роль ComputeOptimizerReadOnlyAccess вашій FinOps-команді. Я також інтегрую Compute Optimizer з нашою стратегією тегування. Детальніше про це у моїй статті про cost allocation tags для multi-account, що дозволяє атрибутувати потенційну економію по командах та продуктах.

Збір memory metrics через CloudWatch Agent

Без memory метрик Compute Optimizer працює наосліп для 40% реальних навантажень (Java, .NET, Python з ML моделями). Я використовую такий мінімальний конфіг CloudWatch Agent, розгорнутий через SSM Distributor:

{
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
    },
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    }
  }
}

Конфіг зберігається в SSM Parameter Store як /cloudwatch-agent/config/compute-optimizer-minimal і застосовується через SSM Run Command до всіх EC2 з тегом cost-optimization=enabled:

aws ssm send-command \
  --document-name "AmazonCloudWatch-ManageAgent" \
  --targets "Key=tag:cost-optimization,Values=enabled" \
  --parameters action=configure,mode=ec2,\
optionalConfigurationSource=ssm,\
optionalConfigurationLocation=/cloudwatch-agent/config/compute-optimizer-minimal,\
optionalRestart=yes

Як інтерпретувати рекомендації right-sizing

Після збору метрик відкрийте Compute Optimizer Console → EC2 Instances. Кожен рядок містить поточний тип, рекомендований тип, оцінку економії, та ризик. Ось як я фільтрую «безпечні» зміни через CLI:

aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=Finding,values=Overprovisioned \
  --query 'instanceRecommendations[?
    recommendationOptions[0].performanceRisk <= `1.0` &&
    recommendationOptions[0].estimatedMonthlySavings.value > `20`
  ].[
    instanceArn,
    currentInstanceType,
    recommendationOptions[0].instanceType,
    recommendationOptions[0].estimatedMonthlySavings.value
  ]' \
  --output table

Performance risk варіює від 0 до 4. Я застосовую тільки рекомендації з performanceRisk <= 1.0 автоматично. Усе вище 1.0 переглядаю вручну з командою, що володіє сервісом. Для stateless воркерів за ALB поріг можна підняти до 2.0 без значного ризику, бо health-чеки відкинуть проблемний інстанс під час rolling update.

Розшифровка типів рекомендацій

• OVER_PROVISIONED: типова економія 20–40%, але перевірте chargeable storage. Перехід з m5.4xlarge на m5.2xlarge не змінить вартості EBS volumes.
• UNDER_PROVISIONED: Compute Optimizer бачить throttling або high CPU. Зазвичай це сигнал про bottleneck, який ви могли не помічати в Datadog через усереднення.
• OPTIMIZED: поточна конфігурація адекватна, але можливі альтернативи з кращою ціна/продуктивність (наприклад, перехід з c5 на c7g).
• NOT_OPTIMIZED: поточний тип не запропоновано б оптимізатором з нуля, але різниця незначна.

Міграція на AWS Graviton через рекомендації

Compute Optimizer з 2022 року активно пропонує Graviton-альтернативи. За моїми спостереженнями, 70% workloads, що працюють на m5/m6i, отримують рекомендацію перейти на m7g або m6g з оцінкою економії 15–25% при тій самій продуктивності. Згідно з офіційними бенчмарками AWS, Graviton4 (R8g, M8g) дає до 30% кращу продуктивність на ядро порівняно з Graviton3.

Перед автоматичним прийняттям Graviton-рекомендацій перевірте сумісність бінарників. ARM64-сумісні: Node.js, Python, Go, Java (OpenJDK 11+), .NET 6+, Ruby. Проблемні: старі x86-only бібліотеки (деякі ML-моделі з x86-специфічним AVX-512 кодом), legacy комерційні драйвери, Oracle Database з prebuilt x86 packages.

Я використовую такий чекліст для кожного сервісу перед Graviton-міграцією:

1. Перебудувати Docker-образ через docker buildx build --platform linux/arm64.
2. Прогнати інтеграційні тести на m7g.large staging-інстансі.
3. Перевірити, що всі native dependencies (numpy, lxml, psycopg2) мають ARM64 wheels на PyPI.
4. Перевірити Java-додатки на наявність com.sun.jna.Native з x86-only нативками.
5. Запустити load test з k6 або wrk2. Graviton зазвичай показує нижчий p99 latency для I/O-bound навантажень.

Якщо ви вже використовуєте Compute Savings Plans, перехід на Graviton не «ламає» їх: Savings Plans покривають усі сімейства EC2 включно з g-варіантами. Більше про вибір між SP та RI у моєму матеріалі про Savings Plans проти Reserved Instances.

Idle Resource Detection та видалення мертвих інстансів

Idle Resource Detection — це функція, що стала GA у 2024 році. Вона визначає EC2-інстанси з CPU < 1% та network traffic < 10 KB/s протягом 14 днів. У моїй практиці кожен другий «забутий» dev/test акаунт містить 5–20 таких інстансів, які залишилися після давніх експериментів.

# Отримуємо список idle EC2 з оцінкою щомісячної економії
aws compute-optimizer get-idle-recommendations \
  --filters name=ResourceType,values=EC2Instance \
  --query 'idleRecommendations[].[
    resourceArn,
    finding,
    savingsOpportunity.estimatedMonthlySavings.value
  ]' \
  --output table

Перед видаленням я завжди створюю AMI-снепшот і призначаю тег scheduled-for-deletion=YYYY-MM-DD з grace-періодом 7 днів. EventBridge правило вмикає алерт, якщо хтось логіниться на інстанс протягом цього періоду. Цей нюанс врятував мене двічі від видалення «забутого» jumpbox, який раз на квартал використовував один інженер.

EBS Volume recommendations

Окрім EC2, Compute Optimizer аналізує EBS-volumes і виявляє overprovisioned gp2-диски, які можна мігрувати на gp3 з економією до 20%. Команда aws compute-optimizer get-ebs-volume-recommendations повертає список з рекомендованими IOPS та throughput. Для більшості загальних навантажень gp3 з 3000 IOPS та 125 MB/s baseline дешевший за gp2 такого ж розміру вже від 20 ГБ.

Автоматизація right-sizing через Lambda та EventBridge

Ручний перегляд рекомендацій раз на місяць, це антипатерн. Я автоматизував процес через EventBridge Scheduler, який щотижня викликає Lambda. Функція забирає рекомендації, фільтрує за порогом performance risk, створює GitHub PR з оновленням Terraform-файлів через GitHub API:

import boto3
import json
from github import Github

co = boto3.client('compute-optimizer')
ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    paginator = co.get_paginator('get_ec2_instance_recommendations')
    pr_candidates = []

    for page in paginator.paginate(
        filters=[{'name': 'Finding', 'values': ['Overprovisioned']}]
    ):
        for rec in page['instanceRecommendations']:
            top_option = rec['recommendationOptions'][0]
            savings = float(top_option['estimatedMonthlySavings']['value'])
            risk = top_option['performanceRisk']

            # Безпечні зміни: low risk + значна економія
            if risk <= 1.0 and savings > 25:
                instance_id = rec['instanceArn'].split('/')[-1]
                tags = ec2.describe_instances(
                    InstanceIds=[instance_id]
                )['Reservations'][0]['Instances'][0].get('Tags', [])
                tf_module = next(
                    (t['Value'] for t in tags if t['Key'] == 'terraform-module'),
                    None
                )
                if tf_module:
                    pr_candidates.append({
                        'instance_id': instance_id,
                        'current_type': rec['currentInstanceType'],
                        'recommended_type': top_option['instanceType'],
                        'monthly_savings': savings,
                        'terraform_module': tf_module
                    })

    if pr_candidates:
        create_github_pr(pr_candidates)

    return {'statusCode': 200, 'recommendations': len(pr_candidates)}

Цей паттерн «Compute Optimizer → GitOps PR» дозволяє зберегти human-in-the-loop підтвердження через code review, але прибирає рутину збору даних. У моїй організації середній час від рекомендації до prod-деплою скоротився з 6 тижнів до 4 днів. Якщо вам цікаво поглибити автономність процесу, дивіться FinOps та AI: автономна оптимізація, де я описую використання Bedrock-агентів для генерації commit messages з business-обґрунтуванням економії.

Compute Optimizer проти Trusted Advisor: коли що використовувати

Це питання я чую щотижня. AWS має два сервіси з частково перекривним функціоналом: Trusted Advisor (Cost Optimization category) і Compute Optimizer. Ось практичне порівняння:

Критерій	Compute Optimizer	Trusted Advisor (Cost)
Вартість	Безкоштовно для базових рекомендацій	Базові безкоштовно; повний доступ потребує Business/Enterprise Support
Глибина EC2-аналізу	ML-моделі, 140+ типів інстансів, Graviton рекомендації	Базові пороги CPU/network, без Graviton
EBS	gp2 → gp3 з recommended IOPS	Underutilized volumes (просто пороговий чек)
Lambda	Memory size optimization	Не охоплює
RDS	Так (MySQL/PostgreSQL з 2024)	Idle DB instances (базово)
Idle resources	EC2, Auto Scaling, EBS, ECS Fargate	Idle Load Balancers, idle DB
API/CLI	Повний API для автоматизації	Support API (потребує Business+)

Мій workflow: Compute Optimizer для compute right-sizing (де він безперечно сильніший), Trusted Advisor для специфічних чеків типу idle ELB, public S3 buckets, RDS без Multi-AZ у prod. Сервіси доповнюють один одного, а не конкурують.

RDS recommendations: оптимізація баз даних

З середини 2024 року Compute Optimizer підтримує RDS для MySQL та PostgreSQL engines. Це довгоочікувана фіча, бо RDS традиційно становить 25–40% AWS-білу для більшості SaaS-стартапів. Сервіс рекомендує:

• Перехід на graviton-варіанти (db.m7g, db.r7g): типово 10–18% економії при тій самій продуктивності.
• Перехід з General Purpose на Memory Optimized (або навпаки) на основі buffer pool hit rate.
• Перехід з gp2 на gp3 storage (RDS теж підтримує gp3 з 2023 року).
• Видалення idle DB instances з нульовою активністю DB connections.

Перш ніж застосовувати рекомендації для prod RDS, обов'язково тестуйте на read replica або snapshot-clone. На відміну від EC2, зміна типу RDS-інстансу викликає downtime до 5 хвилин (або failover для Multi-AZ ~60 секунд). Поточну документацію та changelog по RDS recommendations знайдете у офіційному довіднику AWS RDS Recommendations.

Часті питання

Скільки коштує AWS Compute Optimizer?

Сам сервіс безкоштовний для всіх облікових записів. Платні лише супутні витрати: власні CloudWatch метрики (наприклад, memory через CloudWatch Agent, $0.30 за метрику на місяць) та external metrics ingestion, якщо ви підключаєте Datadog. Enhanced infrastructure metrics з 3-місячною історією коштують $0.0003472 за ресурс на годину.

Чи безпечно автоматично змінювати тип EC2-інстансу за рекомендацією?

Безпечно лише для рекомендацій з performance risk ≤ 1.0 та для stateless workloads за load balancer з health checks. Для stateful сервісів (бази даних, queue workers зі state), брокерів повідомлень завжди передбачте maintenance window та rollback-план. Я особисто автоматизую тільки Auto Scaling Group launch template updates з rolling refresh.

Чому Compute Optimizer не показує memory utilization у моїх рекомендаціях?

За замовчуванням CloudWatch не збирає memory метрики з EC2. Потрібно встановити CloudWatch Agent (через SSM Distributor) з конфігом, що публікує mem_used_percent. Альтернативно увімкніть external metrics ingestion з Datadog/Dynatrace через консоль Compute Optimizer. Без memory метрик рекомендації для Java/Python/.NET додатків будуть неточними.

Як часто Compute Optimizer оновлює рекомендації?

Рекомендації перераховуються щодня. Для нових ресурсів перший аналіз відбувається після 14 днів накопичення метрик. З опцією enhanced metrics analysis сервіс використовує до 93 днів історії, що покращує точність для робочих навантажень з тижневою або місячною сезонністю (наприклад, payroll-системи).

Чи варто переходити на AWS Graviton за рекомендаціями Compute Optimizer?

У 90% випадків так, якщо ваші бінарники ARM64-сумісні. Graviton3 та Graviton4 дають 20–40% кращу ціна/продуктивність порівняно з x86-аналогами. Перевірте Docker-образи через docker buildx, прогнати інтеграційні тести на m7g-стейджингу та поступово розкочуйте через canary deployment. Compute Savings Plans продовжують покривати Graviton-інстанси без переоформлення.