GCP Billing неожиданный счёт за Cloud Storage как разобраться и оптимизировать расходы

[Austkin]

Пришёл счёт от GCP за прошлый месяц — 340 долларов за Cloud Storage, хотя храним там логи и бэкапы, думали будет максимум 20-30 долларов. Данных всего 500 ГБ в Standard storage. Залез в Billing reports — большая часть расходов в строке 'Network Egress'. Похоже что-то постоянно читает из бакетов. Как найти что именно и как это оптимизировать?

[svelte88]

Классическая ловушка — inter-region или internet egress. Если читаешь данные из GCS в Европе, а твои инстансы или Lambda-аналоги в другом регионе, платишь за исходящий трафик. Включи Data Access audit logs в Cloud Logging на уровне бакета (Storage > Audit logs) и посмотри кто и откуда читает данные. Ещё проверь, нет ли публичного доступа к бакетам — иногда индексируют боты.

[hogan20]

У меня была похожая история. Оказалось, что приложение при каждом запросе загружало конфиг-файл из GCS вместо того, чтобы кешировать его локально. 10 000 запросов в день * 1 МБ файл = 10 ГБ исходящего трафика в день. Посмотри в Cloud Monitoring метрику storage.googleapis.com/api/request_count разбитую по method — если там миллионы GetObject, это твоя проблема.

[ralfalfa]

Для логов и бэкапов совершенно точно не нужен Standard storage. Переведи всё что старше 30 дней в Nearline, старше 90 дней — в Coldline. Object Lifecycle Management настраивается через JSON-политику прямо на бакете, это бесплатно и делается за 10 минут. Standard стоит $0.02/ГБ/мес, Coldline — $0.004/ГБ/мес, экономия в 5 раз на хранении.

[Tcraw62981]

Помимо lifecycle policies, включи Object Versioning только если реально нужно — если включено, каждое удаление создаёт noncurrent версию, которая тоже хранится и тарифицируется. Проверь командой gsutil versioning get gs://your-bucket. Если версионирование не нужно — выключи и удали старые версии: gsutil -m rm gs://your-bucket/**#<version>.

[fabs2002x]

По поводу egress: если твои GCE/GKE находятся в том же регионе что и бакет — трафик внутри региона бесплатный. Но если бакет в us-central1, а читаешь из europe-west1 — платишь как за интернет. Быстрая проверка: gsutil ls -L gs://your-bucket | grep Location и сравни с регионом своих инстансов. Перенос бакета в тот же регион решит проблему egress полностью.

[asyncmonk]

Самый быстрый способ найти виновника — включить экспорт биллинга в BigQuery и сгруппировать по SKU: там сразу видно, какой именно egress (inter-region, internet, межконтинентальный) и по какому проекту. Стандартные Billing reports показывают агрегаты, а с экспортом за пару SQL-запросов находится конкретный бакет и день, когда трафик попёр. И сразу поставь budget alert долларов на 50 — чтобы следующий сюрприз прилетел уведомлением на второй день, а не счётом через месяц.

[markcack]

@ralfalfa, с Nearline/Coldline есть подвох, который стоит проговорить: минимальный срок хранения (30 и 90 дней) и плата за чтение — $0.01/ГБ у Nearline, $0.02/ГБ у Coldline. Для бэкапов мёртвым грузом — идеально, но у автора что-то активно читает из бакета. Если перевести горячие логи в Coldline до того, как найден источник чтений, retrieval-плата сожрёт всю экономию и сделает только хуже. Сначала убить лишние GetObject, потом lifecycle.

[svelteops]

@fabs2002x, дополню: перенести бакет одной кнопкой нельзя, Location фиксируется при создании. Реально это новый бакет в нужном регионе плюс gsutil -m cp или Storage Transfer Service, и за саму перекачку между регионами один раз заплатишь тот же межрегиональный трафик. На 500 ГБ терпимо, но делать это лучше после зачистки лишних чтений. И заодно прикинуть dual-region, если читают из двух мест постоянно.