Right-sizing облачных VM: гид 2026

Q: Как часто нужно проводить right-sizing?

Для быстро меняющихся сред раз в квартал. Для стабильных production-нагрузок раз в полгода. Плюс всегда после крупных релизов, миграции БД, изменения кэш-стратегии или подключения новых крупных клиентов. Между ручными циклами держите автоматический еженедельный отчёт по кандидатам.

Q: Сколько реально можно сэкономить на right-sizing?

По моим проектам, 30–60% от compute-бюджета в первый цикл. Наибольший результат дают unused non-prod (до 90% экономии на idle) и переход на Graviton/Ampere/Axion в веб- и API-слоях (25–40%). Если ваш overprovisioning ниже 15%, вы уже в хорошей форме; больше 40% значит базовая гигиена ещё не проведена.

Q: В чём разница между right-sizing и autoscaling?

Autoscaling меняет количество инстансов в группе под нагрузку; right-sizing выбирает правильный тип и размер одного инстанса. Работают вместе: сначала right-sizing подбирает базовый тип и параметры min/max/desired, потом autoscaling двигает количество внутри этих границ. Autoscaling без right-sizing умножает overprovisioning.

Q: Стоит ли покупать Reserved Instances до right-sizing?

Категорически нет. RI и Savings Plans фиксируют вас на 1–3 года. Если вы купите обязательства под overprovisioned парк, right-sizing превратится в убыток: инстанс уменьшили, а зарезервированный тип остался неиспользованным. Правильный порядок: сначала месяц right-sizing, потом commit на новую baseline.

Q: Работают ли Graviton, Cobalt и Axion со всеми приложениями?

ARM64 сегодня совместим с 80–90% современных workload'ов: .NET 6+, Java 11+, Node.js 16+, Python, Go, все managed БД, Nginx, Envoy, PostgreSQL, Redis. Проблемы бывают у legacy-приложений с нативными x86-only зависимостями (некоторые Oracle-компоненты, старые проприетарные драйверы). Всегда запускайте пилот 2–4 недели перед массовым переходом.

Обновлено: 16 июля 2026

Right-sizing облачных инстансов, если коротко, это подбор минимально достаточного типа и размера виртуальной машины под фактический профиль нагрузки, с опорой на реальные метрики CPU, памяти, сети и I/O за окно 14–30 дней. По моему опыту работы с корпоративными счетами AWS, Azure и GCP right-sizing в одиночку даёт сокращение расходов на compute на 30–60% ещё до того, как вы подпишете единый Savings Plan или запустите первый Spot-пул. В этом руководстве я покажу, как делаю это на практике: какие метрики смотрю, какие пороги использую и какие скрипты запускаю каждую неделю.

Средняя утилизация CPU по EC2 в западных клиентах, которых я аудировал в 2026 году, держится на уровне 7–12%. Целевой коридор при right-sizing: 40–60% на пиках.
AWS Compute Optimizer, Azure Advisor и GCP Recommender бесплатны, но их рекомендации нужно фильтровать по окну и метрикам памяти, иначе получите ложноотрицательные.
Переход с x86 (m5/m6i) на Graviton (m7g/m8g) даёт дополнительно 15–40% экономии сверх right-sizing без изменения архитектуры для 80% рабочих нагрузок.
Наибольшая ROI достигается на «унаследованных» стейджинг- и pre-prod-средах: там инстансы месяцами держатся на 2% CPU при полной оплате.
Right-sizing должен предшествовать покупке Savings Plans / Reserved Instances / CUD, иначе вы зафиксируете overprovisioning на 1–3 года.
Автоматизируйте цикл (сбор метрик, рекомендация, изменение, откат при регрессе), иначе конфигурация уплывёт обратно за 60–90 дней.

Что такое right-sizing в облаке

Right-sizing, честно говоря, это не «уменьшить инстанс на один размер». Это дисциплина, которая отвечает на четыре вопроса: какая семья инстансов подходит под профиль нагрузки (compute-optimized, memory-optimized, general purpose), какое поколение (m5 vs m7i vs m8g), какой размер (large, xlarge, 2xlarge) и какая архитектура процессора (x86 vs ARM/Graviton/Ampere/Axion). Ошибка в любом из этих измерений оборачивается либо переплатой, либо деградацией производительности.

Я разделяю right-sizing на три категории. Downsizing, то есть снижение размера при устойчиво низкой утилизации. Family switch, смена семейства, когда профиль не совпадает (например, m5.xlarge с 3% CPU и 85% RAM должен стать r6i.large). Modernization, переход на новое поколение или архитектуру: Graviton3/4 в AWS, Ampere Altra в Azure Dpsv6, Axion в GCP. Каждая категория даёт свою экономию: downsizing (20–50%), family switch (15–35%), modernization ещё 15–40% сверху.

Важно понимать: right-sizing это не разовое упражнение. Профиль нагрузки меняется вслед за релизами, кэшами, миграциями схем. Если вы не запускаете цикл раз в квартал, за год вы вернётесь в исходную точку. Именно поэтому я строю не «отчёт», а pipeline.

Почему right-sizing критичен в 2026 году

Три вещи изменились за последние 18 месяцев. Во-первых, счета за облако выросли: по данным Flexera State of the Cloud, средний респондент теряет 27–32% облачного бюджета на overprovisioning и idle-ресурсы. В абсолютных цифрах для компании со счётом $10M/год это $2.7–3.2M ежегодно.

Во-вторых, разброс между поколениями инстансов стал огромным. AWS Graviton4 (m8g/c8g/r8g) в 2026 году даёт до 40% лучшее соотношение цена/производительность против m6i для веб- и API-нагрузок. Azure Dpsv6 (Cobalt 100 ARM) в EU-регионах на 32% дешевле Dv5 за сопоставимую производительность. GCP Axion (C4A) на 30% быстрее аналогичных x86 C4 при более низкой цене. Клиент, застрявший на m5, платит наценку за архитектуру, которая перестала быть оптимальной.

В-третьих, поставщики облака резко улучшили встроенные рекомендатели. AWS Compute Optimizer с 2025 года учитывает метрики памяти через CloudWatch Agent и умеет рекомендовать Graviton-эквиваленты. Azure Advisor интегрирован с Azure Monitor Workbooks. GCP Recommender выделяет отдельные рекомендации для машин с несбалансированным CPU/RAM. Всё это бесплатно, но требует правильной настройки метрик, иначе рекомендации будут ошибочными.

Какие метрики и пороги использовать

Я использую окно 14 дней для быстрых итераций и 30 дней для production. Метрики, которые нельзя игнорировать: p95 CPU, p95 memory, network throughput, disk IOPS. Ошибка №1 в наивном right-sizing, это смотреть только на average CPU. Средний CPU в 8% может скрывать регулярные пики до 90% во время ночных ETL. Уменьшите инстанс, и ETL встанет. Я на этом обжигался в 2023-м, когда «оптимизировал» кластер аналитики без взгляда на p95.

Мои рабочие пороги

Кандидат на downsizing: p95 CPU < 40% И p95 memory < 50% за 14 дней, при отсутствии scheduled peaks в календаре.
Кандидат на upsize: p95 CPU > 80% или p95 memory > 85% чаще, чем 2 часа в сутки.
Family switch на memory-optimized: memory/CPU > 2.5x усреднённо за окно.
Family switch на compute-optimized: CPU/memory > 3x усреднённо.
Кандидат на shutdown: p95 CPU < 3% И network < 1KB/s за 7+ дней.

AWS: Compute Optimizer + автоматизация

Compute Optimizer это базовый инструмент для EC2, Auto Scaling Groups, EBS и Lambda. Он бесплатен, но по умолчанию отключён в новых аккаунтах. Включается одной командой, но полезен только после 14 дней сбора метрик.

# Включаем Compute Optimizer на уровне организации
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Включаем расширенные метрики (память через CloudWatch Agent)
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --enhanced-infrastructure-metrics Active \
  --look-back-period-preference DAYS_32

# Получаем все рекомендации с потенциалом экономии > $50/мес
aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=Finding,values=Overprovisioned \
  --query 'instanceRecommendations[?recommendationOptions[0].estimatedMonthlySavings.value > `50`].[instanceArn, currentInstanceType, recommendationOptions[0].instanceType, recommendationOptions[0].estimatedMonthlySavings.value]' \
  --output table

Дальше я обычно экспортирую рекомендации в S3, обогащаю тегами через систему тегирования ресурсов для аллокации затрат, и раскидываю задачи по командам-владельцам через Jira/Linear. Ручное применение работает до 200–300 инстансов; выше уже нужен pipeline.

Автоматизация через AWS Systems Manager

# Пример: остановка кандидатов на downsizing в non-prod, замена типа, перезапуск
import boto3, json

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

recs = co.get_ec2_instance_recommendations(
    filters=[{'name': 'Finding', 'values': ['Overprovisioned']}]
)['instanceRecommendations']

for r in recs:
    savings = r['recommendationOptions'][0]['estimatedMonthlySavings']['value']
    new_type = r['recommendationOptions'][0]['instanceType']
    instance_id = r['instanceArn'].split('/')[-1]

    # Проверяем тег Environment (прод трогаем только вручную)
    tags = ec2.describe_tags(Filters=[
        {'Name': 'resource-id', 'Values': [instance_id]},
        {'Name': 'key', 'Values': ['Environment']}
    ])['Tags']
    env = tags[0]['Value'] if tags else 'unknown'
    if env == 'production' or savings < 50:
        continue

    print(f'Resize {instance_id}: -> {new_type} (save ${savings}/mo)')
    ec2.stop_instances(InstanceIds=[instance_id])
    ec2.get_waiter('instance_stopped').wait(InstanceIds=[instance_id])
    ec2.modify_instance_attribute(InstanceId=instance_id,
                                  InstanceType={'Value': new_type})
    ec2.start_instances(InstanceIds=[instance_id])

Azure: Advisor и Azure Resource Graph

Azure Advisor работает по похожему принципу: собирает метрики VM через Azure Monitor, ищет overprovisioning и предлагает shutdown или downsize. Ключевая настройка, это Advisor Configuration, где нужно задать средний CPU-порог (по умолчанию 5%, я обычно поднимаю до 15% для non-prod, чтобы получать больше кандидатов).

# Настраиваем более агрессивный порог для non-prod подписки
az advisor configuration create \
  --resource-group finops-rg \
  --low-cpu-threshold 15 \
  --exclude false

# Получаем все cost-рекомендации в JSON
az advisor recommendation list \
  --category Cost \
  --query '[?impactedField==`Microsoft.Compute/virtualMachines`].{VM:impactedValue, Action:shortDescription.solution, Save:extendedProperties.savingsAmount}' \
  --output table

Для больших ландшафтов лучший инструмент это Azure Resource Graph в связке с Log Analytics. Один KQL-запрос даёт срез по всем подпискам сразу:

// KQL: VM с CPU < 20% за 14 дней и стоимостью > $100/мес
Perf
| where TimeGenerated > ago(14d)
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| summarize p95_cpu = percentile(CounterValue, 95) by Computer
| where p95_cpu < 20
| join kind=inner (
    Resources
    | where type == "microsoft.compute/virtualmachines"
    | project Computer=name, sku=properties.hardwareProfile.vmSize, id
) on Computer
| project Computer, sku, p95_cpu, id
| order by p95_cpu asc

Далее я рекомендую посмотреть Azure Dpsv6/Dpldsv6 (Cobalt 100 ARM) как замену Dv5. Экономия 25–30% для .NET 8/9, Java 21 и Node.js без изменения кода. Для Windows Server VM проверьте, что образ поддерживает ARM (доступно с Windows Server 2022 в preview).

GCP: Recommender API

GCP Recommender даёт несколько специализированных «recommender'ов»: google.compute.instance.MachineTypeRecommender для VM, google.compute.instanceGroupManager.MachineTypeRecommender для MIG и google.compute.instance.IdleResourceRecommender для полностью idle ресурсов. Я использую все три параллельно.

# Экспортируем рекомендации по всем проектам в BigQuery для анализа
gcloud beta billing accounts list --format="value(name)"

# Настраиваем BigQuery-экспорт recommendations
gcloud recommender recommendations list \
  --project=my-project \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(name.basename(), content.overview.currentMachineType, content.overview.recommendedMachineType, primaryImpact.costProjection.cost.units)"

С 2025 года GCP Axion (C4A) доступен в большинстве регионов, и Recommender сам предлагает переход с C3/N2 на C4A там, где нагрузка совместима. По моим тестам, C4A даёт 25–35% лучшее соотношение цена/производительность на Nginx, Envoy, PostgreSQL и типовых Java-нагрузках.

Сравнение встроенных и сторонних инструментов right-sizing

Встроенные рекомендатели бесплатны, но у них есть слепые зоны: они не видят кросс-облачный контекст, не учитывают бизнес-теги (например, «эта VM обслуживает регулятора») и слабо оптимизируют Kubernetes-workload. Сторонние платформы закрывают эти пробелы. Ниже сравнение того, что я использовал в 2025–2026 годах.

Инструмент	AWS/Azure/GCP покрытие	Метрики памяти	Kubernetes	Цена	Когда выбирать
AWS Compute Optimizer	Только AWS	Требует CloudWatch Agent	Через EKS-integration	Бесплатно	AWS-only, до 2000 VM
Azure Advisor	Только Azure	Только с Azure Monitor Agent	Ограничено	Бесплатно	Azure-only
GCP Recommender	Только GCP	Через Ops Agent	Через GKE Cost Insights	Бесплатно	GCP-only
Kubecost / IBM Turbonomic	Все три + on-prem	Да, из cAdvisor/Prometheus	Отличное	От $5K/мес	Kubernetes-heavy
Densify	Все три	Через агенты	Да	По количеству VM	Enterprise, multi-cloud
CloudHealth (VMware)	Все три	Ограничено	Средне	% от spend	Крупные MSP

Мой обычный совет такой. До $5M годового spend хватит встроенных инструментов плюс собственных скриптов. Выше уже есть смысл смотреть на Densify или Turbonomic ради ROI, но только после того, как вы уже провели ручной цикл right-sizing и понимаете свои теги.

Методология right-sizing за 30 дней

Ниже процесс, который я запускаю для новых клиентов. Он рассчитан на команду 1–2 человека и приносит первую экономию к концу второй недели.

Неделя 1: инвентаризация и метрики

Установить CloudWatch Agent / Azure Monitor Agent / Ops Agent на все VM. Без метрик памяти right-sizing слепой.
Включить Compute Optimizer / Advisor / Recommender во всех аккаунтах и подписках.
Экспортировать текущий inventory: тип VM, регион, тег Environment, тег Owner, тег CostCenter. Дыры в тегах, это отдельный тикет.

Неделя 2: quick wins в non-prod

Собрать все idle-ресурсы (CPU < 3%, network < 1KB/s, uptime > 7 дней) и остановить с 3-дневным окном на возражения.
Применить downsizing к non-prod, где p95 CPU < 40% за 14 дней.
Померить экономию по AWS Cost Explorer / Azure Cost Management / GCP Billing и опубликовать результат в общем канале. Это создаёт политический капитал для этапов 3 и 4.

Неделя 3: production и family switches

Согласовать окна изменений с владельцами сервисов; изменение типа требует reboot.
Применить downsizing к prod-инстансам, где recommender подтверждает overprovisioning c 90%+ confidence.
Для memory-heavy нагрузок сделать переезд general-purpose на memory-optimized (m6i на r6i, D8s на E8s, n2-standard на n2-highmem).

Неделя 4: modernization и автоматизация

Пилот на Graviton/Cobalt/Axion в тестовой среде: собрать бенчмарки, проверить совместимость нативных зависимостей.
Настроить weekly cron, который отправляет свежие рекомендации в Slack/Teams владельцам.
Зафиксировать baseline экономии и настроить Savings Plans или Reserved Instances под уже правильно подобранные типы.

Типичные ошибки, за которые платят дважды

За семь лет консультаций я вижу одни и те же грабли. Первая: покупка Savings Plans до right-sizing. Клиент фиксирует Compute Savings Plan на $50K/мес под текущий overprovisioned парк, а через два месяца хочет уменьшить инстансы, но SP уже привязан к baseline, и downsize уводит coverage к нулю. Правильно: сначала месяц right-sizing, потом покупка SP на новый, оптимизированный baseline.

Вторая ошибка: игнорирование памяти. Compute Optimizer без CloudWatch Agent видит только CPU. Инстанс m5.xlarge с 4% CPU и 78% RAM он предложит уменьшить до m5.large, у которой памяти в 2 раза меньше, и приложение начнёт OOM'ить. Я именно на этом баге потерял ночь, когда «оптимизировал» инстанс с Elasticsearch.

Третья: right-sizing автоскейлинг-групп по средним значениям. ASG/VMSS/MIG должны сайзиться под минимум группы (пример: min=2 c8g.large), а не под текущее среднее. Отдельная задача, это оптимизация Kubernetes-кластеров, где right-sizing идёт на уровне pods (requests/limits), а не только нод.

Четвёртая: отсутствие отката. Изменили тип, всё «работает», но latency-p99 вырос на 40 мс, и через сутки жалуется клиент. Всегда сохраняйте старый instance type в теге PreviousType и мониторьте SLO 72 часа после изменения.

Right-sizing и облачные обязательства

Right-sizing и обязательства (RI/Savings Plans/CUD) это не альтернативы, а последовательность. Порядок такой: terminate idle, потом downsize/family switch, потом modernize, и только потом commit. Каждый шаг сокращает базу, на которую вы будете покупать обязательства. Пропуск любого шага удорожает следующий.

Для baseline-нагрузки (24/7, стабильная) после right-sizing я покупаю 1-year Compute Savings Plan с покрытием 60–70% от стабильного пика. Это даёт скидку 20–27% сверх уже сэкономленного. Для пиковой части использую Spot-инстансы для отказоустойчивых нагрузок. Итоговая формула экономии на compute: right-sizing (35%) × Graviton switch (25%) × Savings Plan (25%). На бумаге это около 63% суммарной экономии против исходного on-demand x86 сценария.

Часто задаваемые вопросы

Как часто нужно проводить right-sizing?