Трильйонний збій AWS: причина, хронологія та уроки для хмарного білінгу

Астрономічні суми з’являлися навіть у малоактивних або фактично неактивних акаунтах, які зазвичай коштували своїм власникам лише кілька центів . Водночас це були саме помилкові прогнози на екрані, а не реальні нарахування.

AWS повідомила про проблему приблизно о 01:30 17 липня за PDT і протягом дня публікувала оновлення щодо перебігу розслідування .

Причина: помилка в одиницях тарифікації

AWS підтвердила, що причиною стала помилка в одиницях тарифікації в підсистемі розрахунку прогнозованого білінгу . Алгоритм, який оцінює майбутню вартість використаних ресурсів, застосував неправильні — радикально завищені — тарифні одиниці.

Важливо, що проблема виникла саме в логіці розрахунку оцінки, а не у фактичних даних про використання ресурсів . Тобто система могла правильно фіксувати роботу сервісів, але неправильно перетворювала ці дані на прогнозовану суму.

Глобальний масштаб збою

• Постраждали клієнти по всьому світу — повідомлення надходили з різних регіонів AWS, від Бангалора до Болсовера .
• Некоректні оцінки бачили користувачі, які відкривали Cost Explorer або Billing Console у період інциденту .
• Фактичні рахунки не змінилися. AWS неодноразово наголошувала, що показані суми не відображали реальне використання чи кошти, які клієнти мають сплатити .

Деякі користувачі повідомляли навіть про суми у квадрильйонах доларів . В інших випадках на екрані з’являлися прогнози на мільярди або трильйони, хоча реальне споживання хмарних ресурсів не змінювалося.

Наслідки: паніка та шквал хибних сповіщень

Найпомітнішим наслідком став шок клієнтів. У соцмережах користувачі жартували, що після відкриття консолі в них «душа покинула тіло», побачивши трильйонні баланси . Для компаній, які щодня контролюють хмарні витрати, це також означало серйозний операційний збій.

Помилка зачепила не лише візуалізацію даних. AWS Budgets і Cost Anomaly Detection — інструменти для контролю бюджетів та пошуку аномальних витрат — почали масово генерувати сповіщення про надзвичайно високі суми .

Реальних фінансових втрат AWS не зафіксувала: неправильні оцінки не стали рахунками й не були списані з клієнтів . Проте інцидент вдарив по довірі до систем керування витратами та змусив команди витрачати час на перевірку очевидно абсурдних сигналів.

Хронологія відновлення

Для більшості клієнтів неправильне відображення тривало приблизно 16–18 годин, хоча повний повторний розрахунок даних зайняв більше часу.

Чого цей випадок навчив системи контролю витрат

1. Один збій може заразити весь ланцюжок сповіщень

AWS Budgets і Cost Anomaly Detection використовують дані з тієї самої оцінювальної інфраструктури, де виникла помилка. Якщо базовий розрахунок пошкоджений, усі залежні інструменти починають продукувати шум . Це показує: надійність сповіщення про витрати не може бути вищою за надійність системи, яка формує його основу.

2. Масові хибні тривоги спричиняють «втому від сповіщень»

Коли тисячі клієнтів одночасно отримують повідомлення про фантастичні витрати, команди можуть почати менш серйозно ставитися до таких сигналів. У майбутньому це здатне сповільнити реакцію на справжню аномалію або реальний стрибок витрат .

3. Потрібні незалежні перевірки здорового глузду

Хмарним системам білінгу потрібні додаткові запобіжники — своєрідний «автоматичний вимикач», який не дозволяє показувати оцінку, що у сотні чи тисячі разів перевищує історичний рівень. Незалежний розрахунковий контур міг би перевіряти такі значення до їх появи в консолі.

4. Консолі мають уміти приховувати явно хибні дані

Інцидент показав комунікаційний недолік: у клієнтів не було очевидного механізму, який би в реальному часі позначив цифри як недійсні або тимчасово приховав їх. Багато хто дізнавався про проблему лише зі сторінки статусу AWS чи соціальних мереж .

5. Безпечніша архітектура має краще перевіряти межі

Якщо прогноз раптом перевищує фактичні витрати попереднього періоду в заздалегідь визначену кількість разів, система не повинна одразу показувати його користувачу. Безпечнішим варіантом було б повідомлення на кшталт «дані ще обробляються» до завершення перевірки.

Висновок

Липневий збій AWS не став фінансовою катастрофою: клієнтам не виставили трильйонні рахунки. Але він став серйозним випробуванням для довіри та архітектури хмарного білінгу. Одна помилка в одиницях тарифікації виявилася здатною одночасно спотворити прогнози, запустити масові хибні сповіщення й створити глобальну паніку.

Головний урок для постачальників хмарних сервісів — відокремлювати розрахунок оцінок від їх відображення, запроваджувати незалежні перевірки та не показувати користувачам значення, які очевидно виходять за межі реальності.