Облако удобно тем, что ресурсы включаются по клику. Этим же оно и коварно: незаметно накапливается счёт за то, что работает вхолостую или взято с запасом «на всякий случай». Хорошая новость — большинство переплат лечится несколькими понятными приёмами. Разберём, с чего начать. Многое опирается на то, где вы запускаете сервис и как храните данные.

Модели оплаты и прерываемые машины

Базовая модель — оплата по мере использования (pay-as-you-go): платите за то, что работает, по факту. Но у неё есть более дешёвые варианты для конкретных ситуаций:

  • Прерываемые (preemptible) виртуальные машины — сильно дешевле обычных, но облако может их в любой момент погасить, если ресурсы понадобятся. Идеальны для нагрузок, которые не жалко прервать и перезапустить: пакетная обработка, тесты, фоновые расчёты. Для боевого сервиса, который должен быть доступен всегда, — нет.
  • Обязательства (committed use) — скидка за то, что вы заранее резервируете объём ресурсов на длительный срок. Разумно для стабильной постоянной нагрузки, которую вы точно будете держать.

Правило: прерываемые — под то, что не жалко потерять; обязательства — под стабильную предсказуемую базу; pay-as-you-go — под всё остальное и под эксперименты.

Right-sizing: не брать с запасом

Самая частая переплата новичка — взять машину «помощнее, чтобы наверняка», и оставить её загруженной на 5%. Right-sizing — это подгонка размера ресурса под реальное потребление: посмотреть в Monitoring, сколько процессора и памяти действительно используется, и уменьшить машину до нужного.

Сюда же — гасить то, что не работает. Тестовые и dev-окружения ночью и в выходные никому не нужны — их можно останавливать по расписанию. Остановленная виртуальная машина не тарифицируется за вычисления (диск — отдельно).

Serverless под нерегулярную нагрузку

Если нагрузка неравномерная — то густо, то пусто, — постоянно включённая машина простаивает и всё равно тарифицируется. Здесь дешевле serverless: Cloud Functions и Serverless Containers масштабируются до нуля и берут плату строго за вызовы. Для редких обработчиков и API с нерегулярным трафиком это экономит заметную часть счёта.

Классы хранения и трафик

Два коварных места в счёте связаны с данными.

Классы хранения. В Object Storage холодные данные (старые логи, бэкапы, архивы) не должны лежать в дорогом стандартном классе. Lifecycle-правила сами переносят их в холодный и ледяной классы — это копейки за хранение вместо полной цены.

Исходящий трафик. За данные, уходящие из облака наружу, берут плату. На раздаче популярной статики или больших файлов это растёт незаметно. Помогает CDN перед хранилищем (кэширует ближе к пользователю) и внимание к архитектуре, которая гоняет данные между зонами и наружу без нужды.

Контроль расходов

Оптимизация начинается с видимости. В разделе биллинга видно, какой сервис и какой каталог сколько потратил, — поэтому среды и команды разносят по разным каталогам, чтобы затраты были прозрачны. Там же настраивают бюджеты и уведомления: «если расходы за месяц превысили столько-то — прислать оповещение», чтобы неприятный счёт не стал сюрпризом в конце месяца.

Где это применяется

Оптимизация затрат — не разовая акция, а привычка: раз в период смотреть, что работает вхолостую, что взято с запасом, что можно перенести в холодный класс или на serverless. Разнесение по каталогам и бюджеты с уведомлениями делают расходы видимыми, а видимое — управляемым.

Типичные ошибки новичков:

  • берут машины с запасом и оставляют их почти пустыми;
  • держат dev-окружения включёнными круглосуточно;
  • не настраивают классы хранения — платят за стандарт даже за архив;
  • не разносят затраты по каталогам и не ставят бюджеты — счёт становится сюрпризом;
  • ставят прерываемые машины под боевой сервис — и он падает, когда их гасят.

Что учить дальше: где смотреть потребление — в наблюдаемости; дешёвые классы хранения — в Object Storage; serverless под нерегулярную нагрузку — в serverless. Тот же набор приёмов в AWS — оптимизация затрат в AWS.