Пока облакосчитает деньги.

Спор о жёстком потолке расходов в облаке начал Саймон Уиллисон. 3 октября он написал, что у сервисов с оплатой за использование потолок должен стоять по умолчанию. Дошли до суммы — сервис отключается и отвечает ошибками. Хотите без потолка — снимите отдельной галочкой и возьмите ответственность на себя. Комментаторы на Hacker News разошлись на два лагеря и друг друга почти не слышат. Одним ошибка понятнее, чем утренний счёт на десять тысяч долларов. Бывший сотрудник поддержки сервиса с такими лимитами вспоминает другое: у клиентов выключалось рабочее, они теряли трафик и грозили судом.

А о каком лимите вообще речь? По-моему, обе стороны представляют одно и то же: сумму на весь аккаунт, после которой выключается всё. Тогда правы обе, и договориться им не о чем. Но сами облака лимит так уже не устраивают.

Что умеют лимиты расходов в AWS, Google Cloud и Yandex Cloud

Жёсткий лимит расходов сейчас есть у AWS и Google Cloud, и оба ставят его на проект или отдельный сервис. В Yandex Cloud бюджет только присылает уведомление, а остановку собирают сами.

AWS в сентябре дала новым клиентам лимит на проект: от 20 долларов, до десяти проектов на аккаунт. Когда сумма набрана, проект встаёт на паузу, все его ресурсы останавливаются, данные сохраняются. Если 90 дней ничего не делать, их удалят (документация AWS). Интереснее, что можно включить заранее. Примерно за семь дней до лимита по прогнозу AWS запрещает создавать новые ресурсы. За пять усыпляет простаивающие: например, сервер, который две недели почти не грузил процессор и сеть. За четыре останавливает самые дорогие из работающих. Про последний пункт AWS сама честно предупреждает, что он может нарушить работу.

Google Cloud в июле запустил потолки в тестовом режиме, и тоже узко: один проект, один сервис, один месяц. Сервисов четыре, в том числе Gemini API и Cloud Run. Остальное в проекте продолжает работать.

В Yandex Cloud встроенного потолка нет. Бюджет там умеет одно: прислать уведомление. Документация так и пишет: «достижение установленного порога не влияет на дальнейшее потребление ресурсов» (Yandex Cloud). Остановку можно собрать самому, для этого есть пошаговая инструкция: бюджет, триггер, функция, очередь сообщений, бот в Telegram и сервисный аккаунт с правами редактора. Какие машины останавливать, функция узнаёт по метке target-for-stop.

Если сложить три настройки рядом, в каждой сумма — самое простое поле. AWS спрашивает, какой проект и что гасить первым. Google — какой сервис. Yandex Cloud требует повесить метку на конкретную машину. Жёсткий лимит у всех троих начинается со списка того, что можно выключить.

А лимит на весь аккаунт сразу у нас тоже есть, и включён по умолчанию. Это долг. Если у компании в Yandex Cloud задолженность, ресурсы могут приостановить: виртуальные машины и кластеры баз данных останавливаются, доступа к данным нет, а через 60 дней их могут удалить. Ровно этого и боится второй лагерь в треде: выключилось всё, вместе с сайтом и базой, и никто не выбирал, что именно.

Почему предупреждение о бюджете приходит поздно

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

Как это выглядит, видно на истории с форума разработчиков Google за июнь. У семейного шиномонтажа в Бразилии был ключ, выпущенный в 2021 году для карты на сайте. Позже владелец включил в проекте Gemini API, и AI Studio не предупредила, что старый ключ тоже его откроет. 10 июня по ключу прошло около 593 тысяч запросов, 515 тысяч из них за первый час. Счёт вышел примерно на 14 тысяч долларов. Письмо о подозрительной активности, по словам владельца, пришло через два часа после атаки. А данные биллинга отставали примерно на 32 часа, и сотрудник поддержки поначалу вообще не видел этих списаний. Его вывод: бюджеты — это уведомления, а не лимиты.

Бывает и крупнее. В марте The Register рассказал о стартапе из трёх человек. Обычно он тратил около 180 долларов в месяц, а за двое суток получил по украденному ключу счёт на 82 314 долларов. Причём ночью тратит не только злоумышленник. Уиллисон пишет и о другом: с агентами для кода легко собрать то, что стоит денег, и проснуться к счёту за сервис, который всю ночь работал.

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

Что поставить под жёсткий лимит, а что нет

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

Утёкшие ключи — отдельный пункт. Ключ, который выпустили под карту или форму на сайте, должен открывать только карту и форму. Если он лежит в коде страницы, его видит любой посетитель, об этом есть раздел в справочнике по безопасности кода от ИИ. А чем короче ключ живёт, тем меньше у него шансов дожить до того дня, когда в проекте включат что-нибудь дорогое, про это отдельный текст.

Если бы я начинал в Yandex Cloud с нуля, я бы завёл отдельный каталог под всё, что не жалко: эксперименты, тестовые стенды, сервисы с ключами к нейросетям. Бюджет можно ограничить конкретными каталогами, и я бы поставил его только на этот, с низким порогом. К нему — функцию из инструкции, а метку target-for-stop на каждую машину в каталоге. Для рабочего каталога — отдельный бюджет повыше, с уведомлениями нескольким людям. И отдельно проверил бы ключи: к каким сервисам каждый из них пускает сегодня, а не в тот день, когда его выпустили.