Чого нас навчили AWS та Microsoft в жовтні 2025 року.

Жовтневі збої у хмарних гігантів AWS та MS Azure показали просту істину: «висока доступність» не дорівнює справжній стійкості. Протягом кількох годин недоступними ставали застосунки, сайти й навіть корпоративні панелі — і не лише в межах одного провайдера. Збої у шарі DNS, маршрутизації чи керувальній площині каскадно «глушили» сервіси, що взагалі не планувалися як пов’язані. Це не кінець довіри до хмари, а чіткий сигнал будувати архітектури під неминучу відмову.

Якщо коротко: вранці 20 жовтня 2025 року стався масштабний технологічний колапс в інфраструктурі Amazon Web Services (AWS), який миттєво викликав збої в роботі багатьох глобальних онлайн-платформ. Постраждали такі гіганти, як Snapchat, Duolingo, Roblox, Fortnite, Clash Royale, Playstation, Zoom, Viber, Clash of Clans, Facebook, Signal та інші сервіси, що використовують хмарні рішення AWS.

За Amazon Web Services поспішив «впасти» Microsoft: з 15:45 UTC 29 жовтня до 00:05 UTC 30 жовтня 2025 року клієнти та сервіси Microsoft, що використовують Azure Front Door (AFD), могли спостерігати значні затримки (latency), тайм-аути та помилки. Azure Front Door — це, по суті, глобальний фасад і балансувальник трафіку Microsoft. Через нього ходить трафік до купи сервісів. Якщо лягає він — лягає все, що за ним стоїть (App Service, Azure Active Directory B2C, Azure Portal, Azure SQL Database, Azure Virtual Desktop, Microsoft Entra ID і так далі).

Що це означає для бізнесу в Україні

Більшість компаній досі спираються на один регіон або одного постачальника. Це зручно, але крихко: відмова в одному вузлі або помилка конфігурації здатні зупинити платежі, CRM, логістику і підтримку клієнтів одночасно. Правильна відповідь — диверсифікація інфраструктури та операцій: не лише копії даних, а й альтернативні шляхи трафіку, незалежні механізми автентифікації, автономні конвеєри розгортання і регулярні «вправи з хаосу».

Практичний висновок для бізнесу

Щоб наступний інцидент став для вас інженерною подією, а не кризою репутації, варто зробити чотири кроки.

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

Автоматизація має значення: компанії, які мали автоматизовані перевірки працездатності, сценарії аварійного перемикання, налаштування TTL (Time-to-Live) на Route 53 або Azure DNS, відновилися швидше. Ручне втручання просто не могло встигнути.

Тестуйте своє аварійне відновлення (а не просто документуйте його): “У нас був план аварійного відновлення” — цього недостатньо. Питання в тому: Чи тестували ви його цього кварталу? Хаос-інженерія та симуляції відмов — це не розкіш, а тренування з виживання.

Залежності — це тихі вбивці: від сторонніх API до шарів CDN, кожен зовнішній сервіс додає вектор відмови. Якщо Azure Front Door виходить з ладу, ваш “незалежний” застосунок може виявитися не таким уже й незалежним.

UCLOUD допомагає пройти всі етапи: аудит архітектури і залежностей, проєктування плану стійкості, розгортання мульти-регіональних/мульти-провайдерних шаблонів, налаштування бекапів та DR, а також супровід регулярних тестів.

Підсумок простий: хмара не панацея від аварій сама по собі. Вона вимагає дорослого дизайну та відповідального відношення до побудови архітектури. Побудуйте інфраструктуру так, ніби відмова неминуча, і наступний збій стане керованою подією, а не бізнес-ризиком. З UCLOUD це — не теорія, а операційна практика, яку можна виміряти в хвилинах простою, що не відбулися.