Коли падає US-East-1: анатомія глобального збою AWS

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

1. Вступ: Анатомія системного колапсу

Рано-вранці в понеділок, 20 жовтня 2025 року, інтернет «зламався» для мільйонів користувачів. Звичні сервіси, від ігор до банківських додатків, раптово припинили працювати. Причиною стала не одна помилка, а серія каскадних збоїв у найстарішому та найважливішому регіоні AmazonWebServices — US—East—1 (Північна Вірджинія).

Офіційний звіт AWS підтверджує, що інцидент, який тривав понад 15 годин, був не просто збоєм DNS. Це була класична демонстрація «тісного зв’язку» (tight coupling) компонентів у складній системі. Відмова одного, здавалося б, базового сервісу, спричинила ланцюгову реакцію, яка паралізувала інші, нібито незалежні, системи.

У цій статті ми реконструюємо події, використовуючи офіційну хронологію AWS, щоб точно зрозуміти, як початкова проблема з DNS для DynamoDB призвела до відмови EC2, а та, у свою чергу, «поклала» NetworkLoadBalancer, спричинивши глобальні наслідки.

2. Хронологія та масштаби: Три акти катастрофи

Збій розвивався в кілька етапів, кожен з яких погіршував попередній.

Етап 1: Тригер — Збій DNS DynamoDB (23:49 PDT — 02:24 PDT)

• 23:49 PDT (19.10): AWS фіксує «підвищений рівень помилок та затримок» у US—East—1.
• 00:26 PDT (20.10): Інженери ідентифікують тригер: проблеми з розпізнаванням DNS-імен для регіональних ендпоінтів сервісу DynamoDB (популярної NoSQL бази даних).
• Наслідки: Мільйони додатків, що використовують DynamoDB для сесій, налаштувань та збереження станів, втрачають зв’язок із базою. Що ще гірше, глобальні сервіси AWS, які мають критичні залежності від US—East—1 (наприклад, IAM — управління доступом, та DynamoDBGlobalTables), також починають збоїти.
• 02:24 PDT: AWS усуває проблему з DNS. Сервіси починають відновлюватися. Здається, що найгірше позаду, але це був лише початок.

Це класика. DNS — це «телефонна книга» інтернету. І тут з’ясовується, що головна телефонна станція (US—East—1) не може знайти номер телефону для одного зі своїх найважливіших відділів (DynamoDB). Усі клієнти (SDK) починають шалено передзвонювати, створюючи лавину повторних запитів. Вони кажуть: «Агов, де база?», а у відповідь тиша.

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

Етап 2: Каскадний збій № 1 — Відмова підсистеми EC2 (з ~02:24 PDT)

• Відразу після 02:24 PDT: Проявляється друга, глибша проблема. Внутрішня підсистема EC2, яка відповідає за запуск нових віртуальних серверів (інстансів), сама виявилася залежною від DynamoDB.
• Наслідки: Попри вирішення проблеми з DNS, запуск нових інстансів EC2 в US—East—1 зупиняється або відбувається з величезною кількістю помилок. Це негайно б’є по всіх сервісах, що використовують автомасштабування або запускають EC2 за вимогою (наприклад, RDS — бази даних, ECS — контейнери, Glue — обробка даних).

Ось тут і починається справжній «жар». Це мій улюблений момент у будь-якому збої: виявлення прихованих залежностей. Виявляється, що сервіс, який видає вам нові сервери (EC2), сам потребує бази даних (DynamoDB), щоб працювати. Це якби майстер із ремонту ліфтів не міг потрапити до зламаного ліфта, бо сам застряг в іншому. Це демонструє фундаментальну проблему: ви не можете відновити систему, якщо ваші інструменти відновлення (EC2) залежать від того, що ви намагаєтеся полагодити (DynamoDB). Усі ваші плани автомасштабування в цей момент перетворилися на гарбуз.

Етап 3: Каскадний збій № 2 — Відмова NetworkLoadBalancer (до 09:38 PDT)

• ~08:43 PDT: На тлі проблем з EC2 інженери AWS виявляють, що перевірки працездатності (healthchecks) балансувальників навантаження (NetworkLoadBalancer, NLB) також порушені. Внутрішня підсистема NLB (ймовірно, також пов’язана з EC2) перестає коректно працювати.
• Наслідки: Це спричиняє масштабні проблеми з мережевою зв’язністю для безлічі сервісів. NLB перестають розуміти, які сервіси за ними «живі», і припиняють коректно маршрутизувати трафік. Це стає причиною відмови Lambda, CloudWatch і, за іронією долі, DynamoDB (вже на мережевому рівні).

Якщо EC2 — це м’язи, то NLB — це нервова система, яка каже їм, що робити. І вона теж зламалася. Балансувальник буквально почав питати: «Сервер, ти живий?», але через проблеми з мережею (спричинені, ймовірно, тим же збоєм EC2) не отримував відповіді. В результаті NLB вирішив, що всі сервери «мертві», і перестав надсилати їм трафік.

Етап 4: Стабілізація та відновлення (09:38 PDT — 15:01 PDT)

• 08:43 PDT — 14:48 PDT: Щоб стабілізувати систему, AWS вдається до примусового «троттлінгу» (штучного обмеження) операцій: насамперед, запуску нових EC2-інстансів, а також обробки черг SQS через Lambda.
• 09:38 PDT: AWS відновлює роботу перевірок NLB.
• 14:48 PDT: AWS знімає обмеження (троттлінг) з EC2.
• 15:01 PDT: Усі сервіси AWS повертаються до нормальної роботи. Залишається лише «беклоги» (накопичені повідомлення) в сервісах на кшталт Redshift і Connect, які були оброблені протягом наступних кількох годин.

AWS, каже: «Гаразд, усі, заспокойтеся! Не намагайтеся увімкнути все й одразу». Вони вручну прикрутили кран, щоб система не захлинулася від потоку відкладених запитів. Це називається «холодний старт» після колапсу. Системі потрібен час, щоб «прогріти кеші», відновити пули з’єднань. Тому відновлення ніколи не буває миттєвим. Це не рубильник «увімкнути/вимкнути».

3. Технічний аналіз: Ефект доміно в дії

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

1. Доміно 1: DNS та DynamoDB (Початковий удар) Першопричина — збій DNS — була відносно стандартною. SDK клієнтів не могли знайти IP-адреси DynamoDB, що призводило до масових тайм-аутів та повторних спроб, створюючи DoS-шторм.
2. Доміно 2: Прихована залежність EC2 (Ключова проблема) Це найважливіший і найбільш повчальний момент збою. Виявилося, що «площина управління» EC2 (Control Plane) — система, яка виділяє вам нові віртуальні сервери, — сама використовує DynamoDB для своєї роботи. Коли DynamoDB «впав», а потім «піднявся», ця внутрішня підсистема EC2 не змогла коректно відновитися. AWS полагодила DNS, але клієнти все одно не могли отримати нові обчислювальні потужності.
3. Доміно 3: Збій NLB (Друга хвиля) Третє доміно впало, коли проблеми з EC2 порушили роботу внутрішньої підсистеми NLB. Балансувальники критично важливі, оскільки їхні перевірки працездатності (healthchecks) вирішують, чи «живий» сервіс. Коли ці перевірки зламалися, NLB перестали коректно направляти трафік, що викликало другу хвилю проблем зі зв’язністю і відмову Lambda та CloudWatch.

4. Міф про відмовостійкість: Чому Multi-AZ не врятував?

Цей інцидент — хрестоматійний приклад того, чому Multi-AZ (розгортання в кількох Зонах Доступності) не рятує від збоїв на рівні регіону.

Архітектура Multi-AZ захищає від фізичної відмови одного дата-центру (наприклад, пожежі або відключення живлення).

Але під час цього інциденту відмовили регіональні сервіси (площини управління):

• Регіональне розпізнавання DNS.
• Регіональна підсистема запуску EC2.
• Регіональна підсистема NLB.

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

5. Ключові уроки та практичні висновки

Уроки, винесені з цього збою, тепер підтверджені офіційними даними AWS:

1. Моделюйте залежності як життєво важливі артерії. Збій EC2-через-DynamoDB — ідеальний приклад прихованої залежності. Ви повинні знати, від чого залежить не тільки ваш додаток, але й сервіси, які ви використовуєте.
2. Ставтеся до регіону як до змінної конфігурації. Єдиним порятунком була повноцінна мультирегіональна архітектура, здатна повністю «вимкнути» US—East—1 і перенаправити трафік, наприклад, в US—West—2.
3. Робіть клієнти (SDK) розумнішими. Клієнтський додаток повинен мати резервний шлях для отримання конфігурації (наприклад, з S3 в іншому регіоні), якщо основний API або DNS не відповідають.
4. Практикуйте збої (Chaos Engineering). Цей інцидент доводить, що стійкість, яку ви не тестували, — це фікція. «Вимкніть» US—East—1 у вашому тестовому середовищі та подивіться, що станеться.

6. Висновок: Крихкість монокультури та справжня стійкість

Офіційний звіт AWS лише підкреслює крихкість сучасної інтернет-монокультури. Збій — це не відмова одного компонента; це ланцюгова реакція, де тісно пов’язані залежності в одному регіоні призводять до глобального колапсу.

Для інженерів це нагадування, що відмовостійкість — це не функція, яку можна «купити» в AWS (обравши Multi-AZ). Це архітектурна дисципліна, що вимагає активного проектування з урахуванням відмови не тільки серверів, але й самих «хмарних» сервісів.