Год назад я открыл счёт за AWS и почувствовал, как у меня дёрнулся глаз: двенадцать тысяч долларов вместо ожидаемых семи. Проект жил спокойно, выручка росла не так бодро, как расходы, и на планерке мне прямо сказали, что пора разобраться, куда уходят деньги. Я не облачный архитектор и не финансовый гений, я обычный тимлид, который любит, когда в системе есть порядок. Тот разбор счёта стал для меня отдельным проектом на три месяца, и сейчас я расскажу, что реально помогло. Кстати, ни одного магического инструмента не понадобилось, только терпение и привычка задавать неудобные вопросы.
Первое открытие меня даже разозлило. Оказалось, у нас висело больше тридцати инстансов, которые никто не выключал по ночам и выходным. Люди поднимали машины под эксперименты, тесты, демо для клиента, а потом забывали про них, потому что это было легко и никого не били за перерасход. Только за счёт расписаний и автостопа в dev и стейджинге мы вернули около семи процентов бюджета. Совет простой: включите автоматическое выключение всего, что не prod, и не давайте никому права поднимать ресурсы без тега с владельцем.
Второй жирный пласт — хранилище. Мы хранили логи, снапшоты и бэкапы с таким энтузиазмом, будто данные закончатся. Когда я посчитал, сколько места занимают логи, которые не открывали ни разу за год, мне стало смешно и грустно одновременно. Помогли политики жизненного цикла: перевод в более холодные классы хранения, удаление по возрасту, отказ от хранения версий там, где версии нам не нужны. Это не самая заметная статья расходов, но она тихо капает каждый день, и именно такие капли в сумме дают неприятный счёт.
Народная мудрость
Отдельно хочу предупредить про сетевой трафик. Я долго не мог понять, откуда берётся ощутимая сумма за передачу данных, пока не нарисовал на доске схему нашего общения между зонами доступности. Мы гоняли тяжелые запросы через несколько зон, платили за NAT и даже не задумывались, что часть трафика можно завернуть иначе. После пересборки логики общения сервисов и осознанного размещения ресурсов рядом друг с другом счёт за сеть упал заметно. Проверьте свои маршруты, это часто слепая зона даже у опытных команд.
Третья история про то, что мы просто взяли слишком большие машины. Классика: восемь ядер и тридцать два гигабайта там, где нагрузка не поднималась выше десяти процентов. Мы прошлись по метрикам, уменьшили конфигурации, а часть сервисов перевели на процессоры с другой архитектурой, собрав образы заново. Плюс взяли долгосрочные обязательства по использованию на стабильную часть нагрузки, но только после того, как посчитали базовый уровень потребления за месяцы, а не на глаз. Здесь важно не переусердствовать: экономия не должна превращаться в ночные дежурства из-за нехватки ресурсов.
Инструменты сами по себе скучные, но без них никуда: просмотр расходов по сервисам, бюджеты с оповещениями, обязательная маркировка ресурсов и уведомления про аномалии. У нас появилось правило: если ресурс без тегов, деплой не проходит. Сначала все ворчали, потом привыкли, а через месяц я уже мог за минуту сказать, кто и сколько тратит. И самое важное — мы завели ежемесячный ритуал на полчаса, где просто смотрим на графики и задаём друг другу вопрос, всё ли ещё нужно. Никаких больших реформ, только регулярность.
Итог: за квартал мы срезали примерно сорок процентов счёта, и качество сервиса не упало. Если хотите повторить, начните не с покупки обязательств, а с порядка: теги, расписания, разбор хранилища, ревизия сетевых маршрутов и пересмотр размеров машин. Только потом имеет смысл говорить о долгосрочных скидках. И обязательно договоритесь с командой, что экономия — это общая задача, а не наказание для разработчиков. У нас именно смена отношения сработала лучше любых скриптов.
А теперь интересно послушать вас: какая самая неожиданная статья расходов в облаке вас когда-либо удивила, и что помогло навести порядок в вашей команде?
Первое открытие меня даже разозлило. Оказалось, у нас висело больше тридцати инстансов, которые никто не выключал по ночам и выходным. Люди поднимали машины под эксперименты, тесты, демо для клиента, а потом забывали про них, потому что это было легко и никого не били за перерасход. Только за счёт расписаний и автостопа в dev и стейджинге мы вернули около семи процентов бюджета. Совет простой: включите автоматическое выключение всего, что не prod, и не давайте никому права поднимать ресурсы без тега с владельцем.
Второй жирный пласт — хранилище. Мы хранили логи, снапшоты и бэкапы с таким энтузиазмом, будто данные закончатся. Когда я посчитал, сколько места занимают логи, которые не открывали ни разу за год, мне стало смешно и грустно одновременно. Помогли политики жизненного цикла: перевод в более холодные классы хранения, удаление по возрасту, отказ от хранения версий там, где версии нам не нужны. Это не самая заметная статья расходов, но она тихо капает каждый день, и именно такие капли в сумме дают неприятный счёт.
Народная мудрость
Отдельно хочу предупредить про сетевой трафик. Я долго не мог понять, откуда берётся ощутимая сумма за передачу данных, пока не нарисовал на доске схему нашего общения между зонами доступности. Мы гоняли тяжелые запросы через несколько зон, платили за NAT и даже не задумывались, что часть трафика можно завернуть иначе. После пересборки логики общения сервисов и осознанного размещения ресурсов рядом друг с другом счёт за сеть упал заметно. Проверьте свои маршруты, это часто слепая зона даже у опытных команд.
Третья история про то, что мы просто взяли слишком большие машины. Классика: восемь ядер и тридцать два гигабайта там, где нагрузка не поднималась выше десяти процентов. Мы прошлись по метрикам, уменьшили конфигурации, а часть сервисов перевели на процессоры с другой архитектурой, собрав образы заново. Плюс взяли долгосрочные обязательства по использованию на стабильную часть нагрузки, но только после того, как посчитали базовый уровень потребления за месяцы, а не на глаз. Здесь важно не переусердствовать: экономия не должна превращаться в ночные дежурства из-за нехватки ресурсов.
Инструменты сами по себе скучные, но без них никуда: просмотр расходов по сервисам, бюджеты с оповещениями, обязательная маркировка ресурсов и уведомления про аномалии. У нас появилось правило: если ресурс без тегов, деплой не проходит. Сначала все ворчали, потом привыкли, а через месяц я уже мог за минуту сказать, кто и сколько тратит. И самое важное — мы завели ежемесячный ритуал на полчаса, где просто смотрим на графики и задаём друг другу вопрос, всё ли ещё нужно. Никаких больших реформ, только регулярность.
Итог: за квартал мы срезали примерно сорок процентов счёта, и качество сервиса не упало. Если хотите повторить, начните не с покупки обязательств, а с порядка: теги, расписания, разбор хранилища, ревизия сетевых маршрутов и пересмотр размеров машин. Только потом имеет смысл говорить о долгосрочных скидках. И обязательно договоритесь с командой, что экономия — это общая задача, а не наказание для разработчиков. У нас именно смена отношения сработала лучше любых скриптов.
А теперь интересно послушать вас: какая самая неожиданная статья расходов в облаке вас когда-либо удивила, и что помогло навести порядок в вашей команде?