Некоторые клиенты AWS утром 17 июля увидели в консоли и письмах оценки расходов, от которых обычно зовут не FinOps, а кардиолога: от сотен тысяч долларов до триллионов. Ошибка биллинга AWS затронула именно расчетные суммы, а не реальные списания, но для команд, которые живут по алертам и бюджетным порогам, этого хватило, чтобы на несколько часов превратить обычную пятницу в учения по антикризисному реагированию.
О проблеме сообщает The Register: Amazon Web Services признала, что в Cost Explorer отображались некорректные оценочные данные по расходам. Инцидент появился на AWS Health Dashboard в пятницу, 17 июля, в 1:33 по тихоокеанскому времени. Компания довольно быстро локализовала источник сбоя и описала его предельно сухо: проблема возникла в подсистеме расчета estimated billing, а точнее в логике unit pricing. Для внешнего мира это выглядело проще: сервис, который должен помогать считать деньги, на время потерял чувство меры.
Масштаб визуального абсурда оказался по-настоящему облачным. По скриншотам, опубликованным пользователями на Reddit, один из клиентов, заплативший в прошлом месяце всего 19 центов, получил оценку почти в $2,5 млрд. В том же обсуждении фигурировали суммы около $126 тысяч, сотен миллионов и даже $2,5 трлн. На Hacker News картина была такой же: у людей всплывали уведомления о якобы гигантских превышениях порога расходов. AWS отдельно подчеркнула, что эти цифры не отражают фактическое потребление и реальные начисления. Но в момент, когда почта сообщает, что вы внезапно должны бюджету небольшой страны, формулировка про inaccurate estimated billing звучит не так уж успокаивающе.
Дальше Amazon сделала то, что в такой ситуации выглядит самым рациональным шагом: остановила обновление оценок. Это означает, что завышенные числа могли продолжать висеть в интерфейсе, но хотя бы не росли дальше с каждым обновлением. Компания также попросила клиентов ничего не предпринимать. Перевод на язык эксплуатации простой: не надо срочно открывать десятки тикетов, останавливать прод, удалять ресурсы и устраивать внутренний разбор с поиском виноватого среди платформенной команды. После устранения причины AWS предупредила, что на полную пересборку корректных данных уйдет несколько часов, потому что цифры в Cost Management Console нужно пересчитать заново. Уже после публикации заметки Amazon обновила статус и сообщила, что первопричина устранена, а корректные суммы должны появиться у всех клиентов к полудню 18 июля по тихоокеанскому времени.
С технической точки зрения это довольно показательный сбой. Ошибка биллинга AWS случилась не в execution plane и не в сети, а в слое, который многие компании считают почти бухгалтерским фоном. На практике именно этот слой завязан на массу автоматизаций: budget alerts, лимиты подразделений, отчеты для CFO, внутренние chargeback-механики, FinOps-дашборды, оповещения в Slack и даже скрипты, которые при аномалии расходов создают инцидент или начинают срезать неключевые нагрузки. Когда оценочный биллинг внезапно показывает миллиарды, ломается не только интерфейс, но и доверие к обвязке вокруг него. Для российских и русскоязычных команд, которые работают с зарубежными облаками через дочерние структуры, партнеров или международные юрлица, это особенно неприятный сценарий: сначала система кричит про катастрофу, потом человеку нужно объяснить бизнесу, что катастрофы, возможно, не было.
Почему это важно не только финансистам
У облачного биллинга давно двойная роль. С одной стороны, это бухгалтерия. С другой, это часть observability для бизнеса: по расходам часто раньше всего видно runaway-job, неверную конфигурацию хранения, внезапный всплеск egress или ошибку в автоскейлинге. Поэтому даже когда AWS говорит, что реальные списания не затронуты, инцидент все равно бьет по операционной дисциплине. Если канал оповещений уже однажды соврал на миллиарды, следующий алерт люди будут читать с заметно меньшим доверием. А это плохая новость для любой зрелой инженерной организации, где важна не просто автоматизация, а предсказуемость автоматизации.
Есть и более прикладной вывод. Многие компании строят процессы так, будто оценка расходов из облака всегда достаточно надежна для немедленных действий. История с AWS показывает обратное: между «аномалия в метрике» и «реакция системы» нужен здравый буфер. Если у вас budget alert автоматически эскалируется до руководства, а за ним запускается полуавтоматическое урезание ресурсов, стоит проверить, есть ли второй источник валидации. Например, сверка с фактическим usage, задержка перед применением жестких мер или хотя бы ручное подтверждение для слишком больших отклонений. Ошибка биллинга AWS в этом смысле полезна как стресс-тест архитектуры управленческих решений: она показывает, где у компании мониторинг расходов превращается в триггер паники.
Для Amazon этот эпизод тоже не выглядит пустяком, даже если деньги у клиентов фактически не списывались. AWS продает не только вычисления и storage, но и предсказуемость платформы. Когда проблема касается расчетов стоимости, затрагивается один из самых чувствительных слоев отношений с корпоративным клиентом. Небольшой баг в unit pricing внутри estimated billing computation subsystem быстро превращается в репутационную историю, потому что его видят не только инженеры, но и финансы, закупки, руководители и, возможно, совет директоров, если алерт пришел в особенно неудачный момент квартала.
Главный вопрос после таких сбоев не в том, насколько смешно выглядят скриншоты с триллионными счетами, а в том, сколько решений в компаниях уже завязано на «почти реальном времени» облачного биллинга. Чем глубже FinOps и платформа встроены в операционные процессы, тем дороже обходится даже ошибка в оценочных цифрах. Облака давно стали инфраструктурой, но инцидент 17 июля напомнил: инфраструктура доверия к цифрам там не менее важна, чем виртуальные машины и сети.