17 июля часть клиентов AWS открыла консоль и увидела оценки расходов на миллионы, миллиарды и даже триллионы долларов. Сбой AWS billing не затронул реальные инвойсы, но за сутки успел показать, насколько хрупкими могут быть системы, на которые компании опираются для контроля облачных затрат.
По данным InfoQ, инцидент начался 16 июля в 19:46 по PDT после изменения конфигурации в системе расчета биллинга AWS. В результате в конвейер оценочных начислений попала ошибка в unit pricing, то есть в логике сопоставления потребления и единицы тарификации. Один аккаунт с обычным расходом меньше 5 долларов в месяц увидел оценку в 1,7 млрд долларов. Пользователь Reddit опубликовал скриншот с суммой 225 579 210 164,83 доллара, а на другом дашборде фигурировало 7,1 трлн долларов за месяц. Для масштаба: это больше чем вдвое превышает рыночную капитализацию самой Amazon, на что отдельно обратили внимание в обсуждениях.
Самое неприятное здесь даже не абсурдные цифры, а порядок реакции. AWS признала, что внутренние алармы заметили аномалии, но не остановили генерацию оценочных счетов и не оповестили инженерные команды. Компания узнала о проблеме только после эскалаций от клиентов в 00:19 17 июля, то есть примерно через четыре с половиной часа после собственного срабатывания детекторов. Формально мониторинг отработал. Практически он не довел сигнал до людей и не заблокировал дальнейшее распространение мусорных данных. Для любой SRE- или FinOps-команды это почти учебник по тому, как не должен вести себя контур аварийной защиты.
Позже AWS попыталась откатить конфигурационное изменение, но это не помогло. В 08:24 по PDT компания поставила на паузу генерацию estimated bills, фактически заморозив на экранах уже раздутые суммы. Одновременно по всей платформе были отключены Budget alerts и Cost Anomaly Detection alerts. Ирония вышла почти слишком аккуратной: во время устранения инцидента AWS временно выключила два механизма, которые обычно рекомендует клиентам как страховку от неконтролируемых расходов. Для компаний, которые завязывают на эти сигналы автоматические действия, картина стала совсем неприятной. До паузы можно было получить ложные срабатывания и дернуть аварийные процедуры, от Slack-эскалаций до отключения ворклоадов. После паузы можно было, наоборот, остаться слепым к реальным отклонениям по затратам.
Почему такие ошибки вообще случаются
Техническое объяснение выглядит прозаично и потому особенно правдоподобно. В обсуждении на Hacker News один из инженеров, работавших с похожими сбоями внутри AWS, описал типичный механизм: сервисы отправляют данные о потреблении без цены, а стоимость потом определяется через pricing plan, где для каждой позиции задана единица измерения. Достаточно перепутать гигабайты и байты, чтобы тариф «5 центов за гигабайт» внезапно превратился в «5 центов за байт». На бумаге это мелкая ошибка в типе единицы. На выходе это счета в астрономических величинах уже через часы.
Другой участник обсуждения предложил еще более неприятное, но знакомое объяснение: подобные баги часто проходят тесты, если команды проверяют свои куски системы по отдельности, а полноценного end-to-end сценария между источником метрик и биллингом нет. Один набор тестов подтверждает, что сервис отдает billing entries в ожидаемом формате. Другой подтверждает, что сам биллинг умеет их считать. Но связку между ними никто не гоняет достаточно жестко, потому что она сложнее, дороже и чаще всего размазана по разным командам и управленческим линиям. Для крупных облачных платформ это не сенсация, а скорее старая болезнь распределенной ответственности.
На этом фоне особенно показательно, как рынок отреагировал на инцидент. Главный экономист The Duckbill Group Кори Куинн, который специализируется на облачных расходах, заметил в LinkedIn, что за свою практику переговоров по контрактам AWS на десятки миллиардов долларов он ни разу не доводил клиента до триллиона, а вот команда Cost Explorer смогла сделать это за ночь и сразу для тысяч аккаунтов. Шутка злая, но точная. FinOps-специалисту в такой момент нужно решить: перед ним баг платформы или новый, пока непонятный сценарий катастрофического перерасхода. Когда уведомление показывает что-то вроде «плюс 55 000 000 000% к базовой линии», здравый смысл советует не паниковать. Но если на кону продакшн и деньги компании, игнорировать такое уведомление тоже нельзя.
Что это значит для разработчиков и бизнеса
Для части пользователей история не осталась мемом про триллионные счета. Консультант по архитектуре ПО Пит ван Донген рассказал, что получил уведомление о превышении бюджета и увидел в Cost Explorer 369 188 086,24 доллара расходов на S3 в личном проекте. Он поверил этим цифрам достаточно надолго, чтобы открыть тикет в поддержку и удалить свои нагрузки. Руководитель инженерной команды Дэниел Блюменталь написал, что увидел оценку в 843 млрд долларов и первым делом решил, что его аккаунт взломали. Оба комментария бьют в одну точку: у AWS можно настроить предупреждения, но нельзя выставить жесткий потолок расходов на аккаунт, который физически не даст уйти дальше определенной суммы. И когда система оценок начинает вести себя странно, клиент остается между ложной тревогой и вполне реальным страхом финансовой аварии.
Сбой AWS billing здесь важен не только как курьез. Он напомнил о системной проблеме облачного FinOps: биллинговая телеметрия сама по себе является зависимостью со своими режимами отказа. Обычно про нее говорят в контексте задержек, когда данные о расходах приходят с лагом и автоматические budget actions реагируют постфактум. За несколько дней до этого InfoQ как раз писала о претензиях практиков к тому, что AWS billing может отставать от реального потребления примерно на сутки, а инциденты по перерасходу люди иногда обнаруживают раньше по банковской карте, чем по штатным уведомлениям. Теперь случилась зеркальная версия той же проблемы: данные оказались не медленными, а слишком быстрыми и неверными. Вывод от этого не меняется. Автоматизация затрат надежна ровно настолько, насколько надежен источник цифр, на котором она построена.
Для российских команд, которые продолжают работать с зарубежными облаками через дочерние структуры, партнеров или международные юрлица, здесь практический вывод без всякой романтики. Нельзя строить контроль расходов на одном канале сигналов, даже если этот канал официальный и очень большой. Уведомления AWS, budget actions и anomaly detection полезны, но они не заменяют независимую сверку: лимиты на уровне внутренних процессов, контроль по кредитным картам, вторичные дешборды, ручные пороги на критичных аккаунтах и сценарии, в которых финансовая аномалия не приводит к автоматическому отключению продакшна без дополнительной проверки. Абсурдные суммы хороши тем, что их видно сразу. Куда опаснее тихая ошибка на сотни или тысячи долларов, которую никто не отличит от обычного роста нагрузки.
AWS закрыла инцидент и подчеркнула, что реальные списания не пострадали. Но главный вопрос остался висеть в воздухе: если система, которая должна предупреждать всех остальных о ненормальных расходах, сама не может надежно предупредить о собственной поломке, то кто именно контролирует ее в момент сбоя. Для облачного рынка это уже не вопрос интерфейса Cost Explorer, а вопрос доверия к самой логике финансовой автоматики.