снижать multi-cloud расходы с измеримыми инженерными guardrails
Оптимизация затрат в multi-cloud: практический playbook для AWS, GCP и Azure
10 минут
Неожиданные счета в облаке чаще всего связаны с пробелами в аллокации, простаивающими ресурсами и трафиком данных, а не с одной «лишней» VM. В материале — рычаги затрат для AWS, GCP и Azure: теги, коммитменты, guardrails и еженедельный цикл оптимизации без остановки delivery.
Почему облачные расходы растут быстрее, чем штат инженерии
Команды редко целенаправленно увеличивают cloud spend. Счёт всё равно ползёт вверх: провайдеры тарифицируют мелкие измерения — форму compute, класс storage, пути egress, API-вызовы и ресурсы, оставшиеся после экспериментов. Multi-cloud усиливает эффект: разные названия продуктов, разные выгрузки billing и разные рекомендации в консолях. Без единой модели аллокации финансы видят итог, а инженерия — сервисы. В итоге оптимизация становится реакцией после закрытия квартала, а не непрерывной работой, привязанной к архитектуре.
Шаг первый: каждый доллар должен быть атрибутирован
Нельзя оптимизировать то, что не видно по владельцу. Стандартизируйте обязательные теги или labels с первого дня: окружение, сервис или продукт, команда, cost center и при необходимости классификация данных. В AWS включите cost allocation tags и подайте CUR в Athena или FinOps-платформу. В GCP выгружайте billing в BigQuery и стыкуйте label keys в Looker или аналоге. В Azure закрепите теги политиками и разбирайте Cost Management и Advisor еженедельно. Цель — не идеальная таксономия сразу, а правило: в production не деплоится ресурс без тегов. Добавьте showback-дашборды по владельцам сервисов, чтобы лиды видели влияние autoscaling, retention и числа реплик.
provider "aws" {
region = var.region
default_tags {
tags = {
Environment = var.environment
Service = var.service_name
Team = var.team
CostCenter = var.cost_center
}
}
}
resource "aws_instance" "app" {
ami = var.ami_id
instance_type = var.instance_type
# Inherits default_tags on supported resources
}Сначала right-sizing, потом коммитменты
Reserved Instances, Savings Plans, Committed Use Discounts и Azure Reservations помогают только при честной базовой утилизации. Снимите две недели метрик: CPU, память, GPU и IOPS диска относительно выделенной ёмкости. Уберите явных «пожирателей» — остановленные, но не удалённые инстансы, раздутые БД и dev-кластеры с формой production. Затем накладывайте коммитменты на стабильный footprint. AWS Savings Plans и RI окупаются на предсказуемом compute; GCP CUD — на стабильных ядрах в проектах; Azure Reservations сочетают с Hybrid Benefit, где лицензии позволяют. Держите 20–30% on-demand буфера под всплески и новые сервисы, чтобы коммитменты не блокировали эксперименты.
Рычаги по провайдерам, которые реально двигают цифру
AWS: Graviton там, где поддерживают образы; переход gp2 → gp3; lifecycle для S3; аудит NAT Gateway и cross-AZ трафика. GCP: sustained use скидки, рекомендации Recommender, right-sizing пулов GKE, autopilot или auto-provisioning где уместно. Azure: Advisor, согласование SKU дисков, расписания shutdown для dev/test. На всех трёх проверяйте managed-сервисы с оплатой за запрос — API gateway, ingest observability, serverless и fan-out очередей часто доминируют после настройки compute.
aws ce get-cost-and-usage \
--time-period Start=2026-04-21,End=2026-05-21 \
--granularity MONTHLY \
--metrics UnblendedCost \
--group-by Type=DIMENSION,Key=SERVICE \
| jq '.ResultsByTime[0].Groups | sort_by(.Metrics.UnblendedCost.Amount | tonumber) | reverse | .[0:5]'Kubernetes и передача данных: скрытые множители
Платформы контейнеров маскируют стоимость абстракциями. Завышенные requests мешают bin-packing и раздувают число нод. Service типа LoadBalancer и межзонный трафик умножают egress. PVC без политик storage class остаются после удаления namespace. Выставляйте requests и limits по фактическому потреблению, используйте topology-aware маршрутизацию и по возможности внутренний ingress вместо публичных LB для east-west. Для данных рисуйте потоки явно: реплики БД между регионами, выгрузки в analytics, бэкапы и CDN. Один архитектурный shortcut — «на всякий случай» дублировать логи во второй регион — может стоить дороже compute.
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "768Mi"Автоматизируйте guardrails, а не политики в слайдах
Ручные напоминания не масштабируются. Внедрите бюджеты и anomaly detection по окружениям, блокируйте публичные ACL объектов, требуйте теги через policy-as-code и роняйте CI, если Terraform создаёт ресурсы без меток. AWS Budgets с SNS или Slack дают ранний сигнал; GCP budgets — Pub/Sub; Azure Cost Management — Action Groups. Добавьте технические ограничения: S3 public access block, очистку простаивающих IP и scale-down non-production по расписанию. Исключения документируйте с датой истечения, чтобы временные waiver не стали постоянным долгом.
resource "aws_budgets_budget" "monthly" {
name = "platform-monthly"
budget_type = "COST"
limit_amount = "12000"
limit_unit = "USD"
time_unit = "MONTHLY"
notification {
comparison_operator = "GREATER_THAN"
threshold = 85
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_email_addresses = [var.finops_email]
}
}Еженедельный цикл оптимизации, которому доверяют стейкхолдеры
Проводите 30-минутный FinOps-разбор: топ-5 сервисов по дельте, три кандидата на right-sizing, одно действие по коммитментам или скидкам и один архитектурный follow-up. Назначайте владельцев в Jira, Linear или GitHub issues с привязкой к тегам сервиса. Отмечайте удаления, не только снижения: снятые окружения и уменьшенные кластеры — это победы. Связывайте расходы observability с целями надёжности. Когда руководство просит «просто урезать на X%», отвечайте unit economics — стоимость на активного клиента, инференс или CI-run — чтобы решения оставались связаны с ростом продукта, а не с произвольными процентами.
Если нужен лёгкий культурный базис без просадки скорости продуктовых команд, начните с материала про контроль cloud-затрат без замедления инженерии.
Финансовые guardrails должны жить в той же цепочке поставки, что и инфраструктура — подключайте бюджеты рядом с проверками из статьи про тестирование Terraform и Kitchen-Terraform.