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

стабильная база ровный минимум обязательство на 1–3 года скидка нерегулярная нагрузка то густо, то пусто Cloud Run или по факту платите за работу фоновые задачи переживут отзыв spot-машины в разы дешевле

Три модели оплаты под три вида нагрузки: обязательством покрывают только ровный минимум, нерегулярное отдают оплате по факту, а прерываемые машины берут для того, что переживёт отзыв. Остальное в счёте это правильный размер, погашенные стенды, классы хранения и трафик.

Обязательно

Модели оплаты и скидки

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

  • Скидки за длительное использование (sustained use discounts) — начисляются автоматически, если машина работает большую часть месяца: резервировать ничего не нужно, скидка приходит сама. Но приходит она не ко всем: работает на прежних сериях машин (N1, N2, N2D, C2, M1, M2), а на новых поколениях — C3, C4, N4 и дальше — её нет вовсе. Прежде чем закладывать эту экономию в расчёт, посмотрите, какая серия у вас выбрана.
  • Скидки за обязательство (committed use discounts, CUDs) — за то, что вы берёте обязательство на 1–3 года. Видов два, и выбирают между ними осознанно: обязательство по объёму ресурсов (столько-то процессоров и памяти в таком-то регионе) даёт скидку побольше, но жёстко привязывает вас к серии машин и региону; обязательство по сумме трат в час, гибкий CUD, скидку даёт поменьше, зато считает любые подходящие ресурсы. Для инфраструктуры, которая ещё меняется, обычно рабочий второй.
  • Spot-машины — сильно дешевле обычных, но GCP может их в любой момент забрать. Идеальны для нагрузок, которые не жалко прервать: пакетная обработка, тесты, фоновые расчёты. Для боевого сервиса, который должен быть доступен всегда, — нет. В документации и старых статьях рядом встречаются preemptible-машины: это предыдущее поколение той же идеи, и разница у них одна, зато существенная — preemptible живёт максимум 24 часа и гасится в любом случае, а у Spot потолка по времени нет. Цена одинаковая, так что для нового берут Spot.

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

Порядки скидок и цен

Числа, без которых разговор про экономию остаётся общим (ориентиры, точные значения — в калькуляторе):

ЧтоПорядок
Скидка за постоянное использование (даётся сама, без обязательств)до 20–30 % для машин, работающих месяц целиком
Обязательство на годоколо 35–40 %
Обязательство на три годаоколо 55 %
Прерываемые мощности (Spot)скидка 60–90 %, с отзывом по предупреждению
Небольшая машина (2 ядра, 8 ГБ), круглосуточно50–70 долларов в месяц
Управляемая база небольшого размера50–100 долларов в месяц, вдвое дороже в режиме высокой доступности
Плата за управление кластером Kubernetesоколо 0,10 доллара в час за кластер (порядка 70 долларов в месяц), сверх узлов
Исходящий трафик в интернетпорядка 8–12 центов за гигабайт
Трафик между зонами одного регионаоколо 1 цента за гигабайт
Приём журналов сверх бесплатного объёмаоколо 0,5 доллара за гигабайт

Что из этого чаще всего меняет решения. Скидка за постоянное использование приходит сама — то есть ровно работающая машина уже дешевле, чем кажется по часовой цене. Обязательство на год даёт сопоставимую скидку и не требует трёхлетнего горизонта. Прерываемые мощности — самый крупный рычаг для всего, что переживает остановку. И плата за управление кластером — та строка, которая делает три маленьких кластера заметно дороже одного: для стендов это повод жить в одном кластере с разными пространствами имён.

Где деньги утекают незаметно

Ученик после общего совета ищет большие машины, а в счёте обычно прячется другое. Список специфичных для GCP утечек, по частоте:

Неподключённые диски. Машину удалили, диск остался — и тарифицируется полностью. Это самая частая находка при первой уборке.

gcloud compute disks list --filter="-users:*" --format="table(name,zone,sizeGb)"

Зарезервированные и неиспользуемые внешние адреса. Адрес, не привязанный ни к чему, стоит дороже привязанного. Десяток забытых адресов — заметная строка.

gcloud compute addresses list --filter="status=RESERVED"

Правила переадресации балансировщика. Каждое правило тарифицируется почасово, независимо от трафика. Эксперименты с балансировщиками оставляют после себя правила, которые никто не считает ресурсом.

Узлы кластера без нагрузки. Кластер, поднятый под один сервис, продолжает держать три узла. Плюс плата за управление кластером сверху. Лечится автомасштабированием узлов, а для стендов — остановкой кластера или переносом в общий.

Снимки диска. Они инкрементальные и потому кажутся дешёвыми, но копятся: снимок каждую ночь без правила удаления через год даёт заметный объём.

Приём журналов. См. статью про наблюдаемость: отладочный уровень в боевом контуре легко стоит десятки долларов в месяц.

Забытые стенды целиком. Проект, поднятый под демонстрацию год назад, продолжает работать. Именно поэтому среды разносят по проектам: проект видно в счёте отдельной строкой, и его можно удалить одним движением.

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

Разбор счёта: экспорт в аналитическое хранилище

Консоль отвечает на вопрос «сколько», а на вопрос «почему именно столько» отвечает только подробный разбор. Для этого счёт выгружают в аналитическое хранилище — это включается один раз и дальше работает само.

live example

SELECT
  service.description AS service,
  sku.description AS sku,
  ROUND(SUM(cost), 2) AS cost
FROM `acme-billing.billing_export.gcp_billing_export_v1_XXXX`
WHERE DATE(usage_start_time) BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY service, sku
ORDER BY cost DESC
LIMIT 20
Run

Running examples is part of paid access. There the same code runs inside the article: editor, run and check next to the paragraph. Three free days →

Что это даёт, чего не даёт консоль: разбивку по позициям услуг (не «Compute Engine», а «межзонный трафик» и «диски типа такого-то»), группировку по своим ярлыкам и проектам, сравнение месяцев и построение своих отчётов. Тот самый вопрос «откуда в счёте трафик на сто долларов» решается одним запросом.

Три практических приёма: выгрузка включается до того, как счёт станет непонятным (данные появляются только с момента включения); запросы ограничивают периодом, потому что за сканирование платят; и полезно сразу завести два-три готовых запроса — топ позиций, динамика по месяцам, разбивка по ярлыкам.

Бюджет не останавливает расходы

Важная вещь, которую новичок понимает неверно: бюджет с оповещением — это уведомление, а не предохранитель. Достигли порога — вам напишут на почту. Ресурсы продолжат работать, счёт продолжит расти.

Если нужен именно предохранитель, его собирают сами: бюджет отправляет сообщение в очередь, а функция по этому сообщению выполняет действие — например, отключает платёжный аккаунт у проекта, что фактически останавливает почти все ресурсы.

gcloud billing budgets create --billing-account=XXXX \
  --display-name="dev-limit" --budget-amount=200USD \
  --threshold-rule=percent=0.5 --threshold-rule=percent=0.9 \
  --all-updates-rule-pubsub-topic=projects/acme-ops/topics/budget-alerts

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

Что ещё работает как ограничитель расходов, кроме бюджета: квоты (их можно уменьшать, а не только повышать — это законный способ поставить потолок), предельное число экземпляров у сервисов и максимум в группах масштабирования, и отдельный проект под эксперименты с небольшим бюджетом и жёсткими квотами.

Подгонка размера (right-sizing): не брать с запасом

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

Сюда же — гасить то, что не работает: тестовые и dev-окружения ночью и в выходные никому не нужны, их останавливают по расписанию. А serverless Cloud Run масштабируется до нуля сам, поэтому под нерегулярную нагрузку он дешевле постоянно включённой машины.

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

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

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

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

Какой трафик платный

Одна фраза про исходящий трафик — и половина неожиданных счетов растёт именно отсюда. Разложим.

Бесплатно: входящий трафик; обмен внутри одной зоны по внутренним адресам; обращения к сервисам Google (хранилище объектов, реестр образов, хранилище секретов) из того же региона.

Платно: обмен между зонами одного региона (около цента за гигабайт); обмен между регионами; выход в интернет (порядка 8–12 центов за гигабайт); трафик через преобразование адресов и через балансировщики (у них своя плата за обработку).

Почему из-за незнания этой разницы архитектура «начинает гонять данные по кругу». Типичные случаи:

  • Приложение в одной зоне, база в другой. Каждый запрос платится. Дублирование по зонам нужно для надёжности, но общаться компоненты должны внутри зоны — то есть реплика в другой зоне для отказа, а не для постоянного чтения.
  • Обработка файлов из хранилища другого региона. Данные в одном регионе, вычисления в другом — и каждый прочитанный гигабайт платный. Лечится тем, что вычисления ставят туда, где данные.
  • Отдача файлов пользователям напрямую из хранилища. Самый дорогой вид трафика. Сеть доставки содержимого перед хранилищем дешевле и быстрее.
  • Сбор журналов и метрик в другой регион или в другое облако — постоянный межрегиональный поток, который никто не замечает.

Практическая проверка: в подробной выгрузке счёта (см. ниже) трафик виден отдельными позициями с указанием направления. Если в первой тройке расходов оказался трафик — почти наверняка это одна из четырёх ситуаций выше.

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

Оптимизация начинается с видимости. В биллинге видно, какой сервис и какой проект сколько потратил, — поэтому среды и команды разносят по разным проектам, чтобы затраты были прозрачны.

Проект — не единственный разрез, и полагаться только на него неудобно: в одном проекте обычно живут несколько сервисов сразу. Поэтому ресурсы помечают метками (labels) — парами «ключ-значение» вроде team: billing или env: staging, — и в отчётах биллинга группируют расходы по ключу метки; для разбора поглубже включают выгрузку биллинга в BigQuery. Одна тонкость: метку носит сам ресурс, поэтому на том, что создано без меток, разрез задним числом не появится. Метки проставляют сразу при создании, обычно прямо в Terraform, а не когда счёт уже удивил.

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

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

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

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

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

Глубже: журнал стоит денег, а счёт разбирают запросомрасширенное

Две строки счёта, которые статья выше не называет, а они появляются у каждого: приём журналов и то, как вообще увидеть, откуда взялась сумма.

Cloud Logging платный. Первые 50 ГиБ в месяц на проект принимаются бесплатно, дальше около 50 центов за гибибайт, плюс хранение дольше 30 дней. Сервис с подробным журналом запросов на балансировщике и отладочным уровнем в приложении наливает гибибайты в сутки, и через месяц журнал стоит дороже машин, на которых он пишется. Смотрят по метрике объёма приёма в разрезе ресурсов; лечат исключениями (фильтр, который отбрасывает журнал проверок здоровья и отладочный уровень до приёма), уровнем журнала в приложении и приёмниками (sink), которые уводят объёмный журнал в Cloud Storage или BigQuery по цене хранения вместо цены приёма. То же самое у AWS и Azure с другими порогами: журнал везде тарифицируется на входе.

Экспорт биллинга в BigQuery. Консоль биллинга показывает суммы по сервисам и проектам, а на вопрос «какой именно бакет, какая машина, с какой меткой» отвечает подробный экспорт: включается один раз в настройках биллингового аккаунта, и с этого момента каждая строка расхода с метками, ресурсом и SKU лежит в таблице BigQuery. Дальше это обычный SQL: расход по метке team за месяц, десять самых дорогих ресурсов, рост сетевого трафика по дням. На эту таблицу ставят панель и сигнал тревоги на аномалию, и она же закрывает вопрос «почему счёт вырос вдвое» за десять минут вместо переписки с поддержкой. Стоит экспорт копейки за хранение, и включают его до первого крупного счёта, потому что задним числом он данные не восстановит.

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

Коротко

  • Скидки: за длительное использование автоматически, за обязательство на год или три под стабильную базу, spot под то, что не жалко прервать.
  • Подгонка размера по реальной загрузке и выключение стендов ночью экономят больше любых скидок.
  • Классы хранения через lifecycle-правила и Cloud CDN против исходящего трафика.
  • Проекты, метки и бюджеты с оповещением дают видимость расходов.
  • Журнал платный на входе сверх 50 ГиБ: исключения, уровень, приёмники в дешёвое хранилище; экспорт биллинга в BigQuery включают до первого крупного счёта и разбирают расход SQL.
  • Скидка за постоянное использование приходит сама, обязательство на год даёт около 35–40 %, прерываемые мощности — до 90 % с риском отзыва; плата за управление кластером делает три маленьких кластера дороже одного.
  • Незаметные утечки: неподключённые диски, зарезервированные адреса, правила балансировщика, узлы без нагрузки, снимки без правил удаления, приём журналов и забытые стенды.
  • Платный трафик — между зонами, между регионами и в интернет; обращения к сервисам Google в своём регионе обычно бесплатны, поэтому вычисления ставят туда, где данные.
  • Подробный разбор счёта делают выгрузкой в аналитическое хранилище: разбивка по позициям услуг и по ярлыкам, которой нет в консоли.
  • Бюджет с оповещением ничего не останавливает: предохранитель собирают сами через сообщение и функцию, а грубое отключение платёжного аккаунта применяют только к песочницам.

Что почитать дальше