Облако удобно тем, что ресурсы включаются по клику. Этим же оно и коварно: незаметно накапливается счёт за то, что работает вхолостую или взято с запасом «на всякий случай». Хорошая новость — большинство переплат лечится несколькими понятными приёмами. Многое опирается на то, где вы запускаете сервис и как храните данные.
Три модели оплаты под три вида нагрузки. Обязательством покрывают только ровный минимум, который точно останется; нерегулярное отдают оплате по факту; прерываемые мощности берут для того, что переживёт отзыв за полминуты.
Модели оплаты
Базовая модель — оплата по мере использования (pay-as-you-go): платите за то, что работает, по факту. Для сервиса, который работает круглые сутки год напролёт, это самый дорогой способ: вы платите полную цену за ресурс, который и так никогда не выключите. Поэтому у неё есть более дешёвые варианты:
- Зарезервированные экземпляры (reserved instances) — скидка за то, что вы бронируете ресурс на 1–3 года. Разумно для стабильной постоянной нагрузки, которую точно будете держать. Цена ошибки при этом выше, чем кажется: бронь привязана к семейству машин и региону, и переезд на другое семейство или в другой регион скидку с собой не увозит. Обменять или вернуть резервирование можно, но с ограничениями.
- Savings plans — скидка за обязательство тратить определённую сумму в час на вычисления, гибче резервирования конкретной машины.
- Spot-машины — сильно дешевле обычных, но Azure может их в любой момент забрать. Забирает не молча: перед изъятием приходит предупреждение, но всего секунд за 30 — значит задача обязана за это время сохранить промежуточный результат и корректно закрыться, иначе работа пропадёт. При создании задают ещё две вещи: политику изъятия (машину освободить, чтобы позже запустить снова, или удалить совсем) и потолок цены — как только цена его перешагнёт, машину заберут. С такой оговоркой spot идеальны для нагрузок, которые не жалко прервать: пакетная обработка, тесты, фоновые расчёты. Для боевого сервиса, который должен быть доступен всегда, — нет.
Правило: spot — под то, что не жалко потерять; резервирование и savings plans — под стабильную базу; pay-as-you-go — под всё остальное и эксперименты.
С чего начинать: три строки отчёта
Практический первый шаг занимает пятнадцать минут и почти всегда даёт результат: открыть анализ расходов, сгруппировать по сервису за прошлый месяц и посмотреть три самые крупные строки.
Что обычно в них оказывается:
Вычисления — машины, узлы кластера, планы приложений. Главные находки здесь: машины, включённые круглосуточно ради работы восемь часов; узлы кластера, взятые с запасом «на всякий случай»; забытые стенды.
Базы данных — и чаще всего не самая нагруженная, а забытая: стенд с той же конфигурацией, что боевой контур, или база, оставшаяся после закрытого проекта. Вторая находка — избыточный резерв в другой зоне на стендах, который удваивает цену без всякой пользы.
Журналы и телеметрия — та строка, которая удивляет. Приём данных в рабочую область тарифицируется за гигабайт, и приложение с включённым отладочным уровнем в боевом контуре легко даёт десятки гигабайт в сутки. Для среднего сервиса эта строка часто оказывается в первой тройке, и уменьшается она двумя настройками: уровень журналирования и срок хранения.
Дальше по тем же трём строкам смотрят разбивку по тегам (env, service) — и вот здесь обычно и появляется главное открытие, что стенды стоят как половина боевого контура. Про теги и их настройку — в статье про основы.
Right-sizing: не брать с запасом
Самая частая переплата новичка — взять машину «помощнее, чтобы наверняка», и оставить её загруженной на 5%. Right-sizing — подгонка размера под реальное потребление: посмотреть в Azure Monitor, сколько процессора и памяти действительно используется, и уменьшить машину. Azure Advisor подсказывает такие возможности автоматически.
Сюда же — гасить то, что не работает: тестовые и dev-окружения ночью и в выходные никому не нужны, их останавливают по расписанию (auto-shutdown).
Здесь новичка ждёт самая дорогая ошибка в этой теме. «Остановить» в Azure бывает двух видов. Выключили машину изнутри операционной системы — она перейдёт в состояние «остановлена», но ресурсы останутся закреплены за ней, и счёт за вычисления продолжит капать, как будто она работает. Не тарифицируется только остановка с освобождением ресурсов (в портале это статус «Остановлена (освобождена)», в командах — deallocate); именно так гасят портал, CLI и расписание auto-shutdown. И даже у освобождённой машины остаются платными диски и зарезервированные за ней публичные адреса — совсем бесплатной она не становится.
Serverless под нерегулярную нагрузку
Если нагрузка неравномерная — то густо, то пусто, — постоянно включённая машина простаивает и всё равно тарифицируется. Здесь дешевле serverless: Azure Functions и Container Apps масштабируются до нуля и берут плату строго за вызовы. Для редких обработчиков и API с нерегулярным трафиком это экономит заметную часть счёта.
Уровни хранения и трафик
Два коварных места в счёте связаны с данными.
Уровни хранения. В Blob Storage холодные данные (старые логи, бэкапы, архивы) не должны лежать в дорогом уровне Hot. Lifecycle-правила сами переносят их в Cool и Archive — это копейки за хранение вместо полной цены.
Исходящий трафик. За данные, уходящие из облака наружу, берут плату — но не с первого гигабайта: примерно 100 ГБ в месяц отдаются бесплатно. Для маленького проекта это значит, что за трафик он начнёт платить не сразу; а вот на раздаче популярной статики счёт растёт незаметно. Помогает CDN перед хранилищем и внимание к архитектуре, которая гоняет данные между зонами и регионами без нужды.
Контроль расходов
Оптимизация начинается с видимости. Cost Management показывает, какой сервис и какая группа ресурсов сколько потратили, — поэтому среды и команды разносят по разным группам ресурсов и подпискам, чтобы затраты были прозрачны. Когда несколько команд живут в одной подписке, групп ресурсов уже мало: тогда ресурсы размечают тегами (team, env, project) и включают нужные теги как теги распределения затрат. После этого счёт в Cost Management раскладывается по командам и средам, а не остаётся списком безымянных виртуальных машин. Там же настраивают бюджеты и уведомления: «если расходы за месяц превысили столько-то — прислать оповещение», чтобы счёт не стал сюрпризом.
Дешевле не всегда правильно
Отдельный разговор, без которого статья про экономию вредна: часть способов сэкономить увеличивает риск, и это надо различать.
Честная экономия — та, которая убирает то, за что вы платите без пользы: выключенные по ночам стенды, правильный размер вместо запаса, дешёвый уровень хранения для старых данных, обязательство на предсказуемую нагрузку, перенос лицензий. Здесь риск не растёт вообще.
Экономия ценой риска — и с ней надо обращаться осознанно:
- Прерываемые мощности под боевую нагрузку. Дешевле в разы, и экземпляр могут забрать с коротким предупреждением. Годится для фоновых задач, обработки очередей, части узлов кластера, где потеря экземпляра переживается. Не годится для базы, для узлов с состоянием и для сервиса, у которого нет запаса.
- Отказ от второй зоны. Экономит половину стоимости резерва и меняет обещанную доступность на порядок. Решение принимает не инженер, а тот, кто отвечает за простой; и записывается оно словами, а не молча.
- Отказ от резервных копий в другом регионе или сокращение срока хранения копий: экономия копеечная, а последствия — потеря данных в плохом сценарии.
- Один экземпляр вместо двух. Половина цены и полное отсутствие запаса на обслуживание: любое обновление становится простоем.
Как отличать одно от другого на практике: задать вопрос «что случится, если это откажет». Если ответ «ничего, задача повторится» — это честная экономия. Если «сервис ляжет» или «потеряем данные» — это ставка, и её надо либо не делать, либо сделать с ведома тех, кто отвечает за результат, и записать в решениях.
Где это применяется
Оптимизация затрат — не разовая акция, а привычка: раз в период смотреть, что работает вхолостую, что взято с запасом, что можно перенести в холодный уровень или на serverless. Разнесение по группам ресурсов и бюджеты с уведомлениями делают расходы видимыми, а видимое — управляемым.
Типичные ошибки новичков:
- берут машины с запасом и оставляют их почти пустыми;
- держат dev-окружения включёнными круглосуточно;
- не настраивают уровни хранения — платят за Hot даже за архив;
- не разносят затраты и не ставят бюджеты — счёт становится сюрпризом;
- ставят spot-машины под боевой сервис — и он падает, когда их забирают.
Глубже: порядки цен и размер скидокрасширенное
Разговор про экономию без чисел остаётся общими словами. Ниже ориентиры (европейские регионы, значения меняются — точные смотрят в калькуляторе):
| Что | Порядок цены |
|---|---|
| Небольшая машина (2 ядра, 8 ГБ), круглосуточно | 70–90 долларов в месяц |
| Та же машина с обязательством на год | скидка порядка 30–40 % |
| Та же машина с обязательством на три года | скидка порядка 50–60 % |
| Та же машина на прерываемых мощностях | скидка до 80–90 %, с риском отзыва |
| Управляемый PostgreSQL небольшого размера | 60–120 долларов в месяц, вдвое дороже с резервом в другой зоне |
| Хранение объектов, горячий уровень | около 2 центов за гигабайт в месяц |
| Тот же объём на холодном уровне | примерно втрое дешевле, но платите за чтение |
| Архивный уровень | на порядок дешевле хранения, восстановление часами и платно |
| Исходящий трафик в интернет | порядка 8–9 центов за гигабайт |
| Приём данных в рабочую область журналов | порядка 2–3 долларов за гигабайт |
Три вывода, которые стоит держать в голове. Скидка за обязательство — самый крупный и самый безопасный рычаг для ровной нагрузки. Уровни хранения различаются кратно, и перекладывание старых данных даёт заметную экономию при нулевом риске. И журналы стоят дорого в расчёте на гигабайт — дороже, чем хранение тех же данных в объектном хранилище в сотню раз, о чём ниже.
Глубже: журналы как статья расходарасширенное
Раз журналы попадают в первую тройку, им стоит отдельный абзац: они дорожают тремя способами и удешевляются четырьмя.
Почему дорого. Платят за приём данных (за гигабайт) и за хранение сверх бесплатного срока. Отладочный уровень в боевом контуре, логирование тел запросов, метрики с большим числом измерений, трассировка всех запросов подряд — каждый из этих пунктов легко удваивает объём.
Что делают:
- Уровень журналирования. В боевом контуре — предупреждения и ошибки плюс по строке на обращение; отладочный включают точечно и на время.
- Срок хранения. Значение по умолчанию сокращают до нужного (30–90 дней вместо года), а что нужно хранить долго — выгружают в объектное хранилище, где гигабайт стоит в сотню раз дешевле.
- Частичная выборка трассировок. Хранить 100 % трасс не нужно: 5–10 % плюс все ошибки дают ту же картину за десятую часть цены. Это одна настройка в библиотеке телеметрии.
- Отдельный уровень для дешёвых данных. У рабочей области есть режим для журналов, к которым обращаются редко (дешевле приём, дороже запрос) — туда отправляют то, что нужно «на всякий случай»: подробные журналы платформы, трафик, аудит.
Глубже: перенос своих лицензийрасширенное
Рычаг, который применим не ко всем, и для тех, к кому применим, — самый крупный из существующих: перенос собственных лицензий (Azure Hybrid Benefit).
Смысл в том, что цена машины с Windows или с коммерческой базой складывается из двух частей: вычислительные ресурсы и лицензия. Если лицензия у вас уже есть (куплена с правом переноса в облако), платить за неё второй раз не нужно — вы включаете соответствующий признак у ресурса и платите только за вычисления.
Экономия заметная: для машины с Windows это порядка 40 % от цены, для управляемой базы на коммерческом движке — сопоставимо или больше.
Что нужно, чтобы этим пользоваться: подходящие лицензии с активной подпиской на обновления, включённый признак у ресурса (его можно включить и после создания) и учёт того, что вы задействовали. Это административная работа, а не техническая, и обычно её ведёт та же служба, что и закупки.
Почему это стоит проверить даже тем, кто «на Linux»: лицензии часто есть у компании исторически, а команда, которая поднимает инфраструктуру, про них не знает. Один вопрос закупщикам — и половина счёта за машины с Windows исчезает.
Глубже: чем именно гасить стенды по расписаниюрасширенное
«Гасить окружения разработки по ночам» — правильный совет, у которого для разных ресурсов разные инструменты.
Виртуальные машины — встроенное автоматическое выключение (настройка у самой машины: время и часовой пояс, с предупреждением на почту). Запуск утром делают расписанием в автоматизации или конвейером. Выключенная машина не тарифицируется по вычислениям, а вот диск платится всегда — это остаток, который не убрать.
Наборы машин и кластеры — расписание масштабирования: ночью нулевое или минимальное число экземпляров. У кластера Kubernetes есть и более радикальный вариант — остановка кластера целиком, при которой не платятся узлы.
Планы приложений и Container Apps — масштабирование в ноль там, где оно поддерживается; иначе уменьшение плана на ночь (это допустимо, но требует автоматизации).
А вот базы данных так гасить нельзя без потерь. Управляемый PostgreSQL умеет останавливаться, и это экономит вычисления, но с двумя оговорками: остановка ограничена по времени (через неделю сервер поднимается сам) и во время остановки не работают ни резервные копии по расписанию, ни обслуживание. Для стенда это приемлемо, для чего-то важного — нет. Кэш и очереди обычно тоже не гасят: потеря содержимого кэша безобидна, а вот сообщений в очереди — нет.
Практическая схема, которая приносит больше всего: стенды выключены с вечера до утра и все выходные (это две трети времени), боевой контур не трогают, а вместо гашения баз на стендах берут минимальный размер. И проверка, что расписание работает: график затрат по стендам должен иметь провалы по ночам — если он ровный, автоматика не сработала.
Коротко
- Оплата по факту самая дорогая для круглосуточной нагрузки: резервирование и savings plans под стабильную базу, spot с предупреждением за полминуты под то, что не жалко потерять.
- Обязательство на год даёт 30–40 %, на три 50–60 %, spot до 80–90 %; управляемая база с резервом в другой зоне вдвое дороже, а приём логов стоит доллары за гигабайт.
- Первый шаг занимает пятнадцать минут: три самые крупные строки отчёта по сервисам, обычно вычисления, базы и журналы, потом разбивка по тегам env и service.
- Журналы дорожают от отладочного уровня, тел запросов и метрик с большим числом измерений; дешевеют от уровня, срока хранения, выборки трасс и дешёвого уровня рабочей области.
- Right-sizing по реальному потреблению и гашение стендов по расписанию; «остановить» изнутри ОС оставляет ресурсы оплаченными, освобождает только deallocate.
- Нерегулярная нагрузка дешевле на serverless; холодные данные переносят правила жизненного цикла, а исходящий трафик платный после примерно 100 ГБ в месяц.
- Cost Management с разнесением по группам ресурсов и подпискам, бюджеты с оповещением; перенос своих лицензий Windows и коммерческих баз даёт порядка 40 %.
- Честная экономия убирает то, за что платят без пользы; экономия ценой риска (spot под бой, одна зона, отказ от копий, один экземпляр) решается вопросом «что случится, если это откажет».
- Стенды гасят с вечера до утра и на выходные: машины автоматическим выключением, наборы и кластеры расписанием, базы не гасят, а берут минимальный размер.
Что почитать дальше
- Безопасность и наблюдаемость — где смотреть потребление и почему журналы дорожают.
- Blob Storage — уровни хранения и минимальные сроки.
- Serverless в Azure — оплата по факту под нерегулярную нагрузку.
- Деньги в облаке — модель оплаты и ловушки, общие для всех провайдеров.