Облако удобно тем, что ресурсы включаются по клику. Этим же оно и коварно: незаметно накапливается счёт за то, что работает вхолостую или взято с запасом «на всякий случай». Хорошая новость — большинство переплат лечится несколькими понятными приёмами. Многое опирается на то, где вы запускаете сервис и как храните данные.
Модели оплаты
Базовая модель — оплата по мере использования (pay-as-you-go): платите за то, что работает, по факту. У неё есть более дешёвые варианты:
- Зарезервированные экземпляры (reserved instances) — скидка за то, что вы бронируете ресурс на 1–3 года. Разумно для стабильной постоянной нагрузки, которую точно будете держать.
- Savings plans — скидка за обязательство тратить определённую сумму в час на вычисления, гибче резервирования конкретной машины.
- Spot-машины — сильно дешевле обычных, но Azure может их в любой момент забрать. Идеальны для нагрузок, которые не жалко прервать: пакетная обработка, тесты, фоновые расчёты. Для боевого сервиса, который должен быть доступен всегда, — нет.
Правило: spot — под то, что не жалко потерять; резервирование и savings plans — под стабильную базу; pay-as-you-go — под всё остальное и эксперименты.
Right-sizing: не брать с запасом
Самая частая переплата новичка — взять машину «помощнее, чтобы наверняка», и оставить её загруженной на 5%. Right-sizing — подгонка размера под реальное потребление: посмотреть в Azure Monitor, сколько процессора и памяти действительно используется, и уменьшить машину. Azure Advisor подсказывает такие возможности автоматически.
Сюда же — гасить то, что не работает: тестовые и dev-окружения ночью и в выходные никому не нужны, их останавливают по расписанию (auto-shutdown). Остановленная машина не тарифицируется за вычисления.
Serverless под нерегулярную нагрузку
Если нагрузка неравномерная — то густо, то пусто, — постоянно включённая машина простаивает и всё равно тарифицируется. Здесь дешевле serverless: Azure Functions и Container Apps масштабируются до нуля и берут плату строго за вызовы. Для редких обработчиков и API с нерегулярным трафиком это экономит заметную часть счёта.
Уровни хранения и трафик
Два коварных места в счёте связаны с данными.
Уровни хранения. В Blob Storage холодные данные (старые логи, бэкапы, архивы) не должны лежать в дорогом уровне Hot. Lifecycle-правила сами переносят их в Cool и Archive — это копейки за хранение вместо полной цены.
Исходящий трафик. За данные, уходящие из облака наружу, берут плату. На раздаче популярной статики это растёт незаметно. Помогает CDN перед хранилищем и внимание к архитектуре, которая гоняет данные между зонами и регионами без нужды.
Контроль расходов
Оптимизация начинается с видимости. Cost Management показывает, какой сервис и какая группа ресурсов сколько потратили, — поэтому среды и команды разносят по разным группам ресурсов и подпискам, чтобы затраты были прозрачны. Там же настраивают бюджеты и уведомления: «если расходы за месяц превысили столько-то — прислать оповещение», чтобы счёт не стал сюрпризом.
Где это применяется
Оптимизация затрат — не разовая акция, а привычка: раз в период смотреть, что работает вхолостую, что взято с запасом, что можно перенести в холодный уровень или на serverless. Разнесение по группам ресурсов и бюджеты с уведомлениями делают расходы видимыми, а видимое — управляемым.
Типичные ошибки новичков:
- берут машины с запасом и оставляют их почти пустыми;
- держат dev-окружения включёнными круглосуточно;
- не настраивают уровни хранения — платят за Hot даже за архив;
- не разносят затраты и не ставят бюджеты — счёт становится сюрпризом;
- ставят spot-машины под боевой сервис — и он падает, когда их забирают.
Что учить дальше: где смотреть потребление — в наблюдаемости; дешёвые уровни хранения — в Blob Storage; serverless под нерегулярную нагрузку — в serverless. Тот же набор приёмов в AWS — оптимизация затрат в AWS.