Hacker News Digest

20 октября 2025 года AWS пережил один из крупнейших за десятилетие инцидентов в регионе us-east-1, когда проблемы с DNS для DynamoDB вывели из строя весь регион. Пострадали Disney+, Lyft, McDonald's, New York Times и Reddit. Несмотря на то что Authress вынужден размещать часть инфраструктуры в us-east-1 (где находятся клиенты), сервис остался работоспособным. Это стало возможным благодаря архитектуре, не зависящей от单一 региона, и продуманной стратегии отказоустойчивости.

Authress, предоставляющий аутентификацию и авторизацию с генерацией JWT, стремится достичь SLA в "пять девяток" (99.999% uptime), что допускает простои не более 5 минут 15 секунд в год. Даже косвенные зависимости от AWS-сервисов вроде CloudFront и IAM в проблемном регионе не повлияли на работу платформы. Авторы подчеркивают, что надежность достигается не за счет избегания критических регионов, а через продуманную архитектуру, гарантирующую постоянную доступность для клиентов.

• Критика формулы повторных попыток за игнорирование корреляций сбоев, что неверно при массовых сбоях.
• Обсуждение рисков автоматизации и IaC как новых потенциальных точек отказа.
• Скепсис по поводу абсолютной недопустимости простоев и переоценка критичности сервисов инженерами.
• Вопросы измерения простоев (по времени vs по запросам) и специфика использования Route 53 для health checks.
• Важность бизнес-контекста и SLA для оценки допустимости простоев, особенно для критичных сервисов вроде аутентификации.

В течение 19 и 20 октября 2025 года сервис Amazon DynamoDB в регионе Северной Вирджинии (us-east-1) столкнулся с серией сбоев, повлиявших на клиентов. Проблема началась 19 октября в 23:48 по тихоокеанскому времени и завершилась 20 октября в 14:20. Событие развивалось в три этапа. Сначала, до 2:40 утра 20 октября, клиенты испытывали повышенное количество ошибок API при обращении к DynamoDB. Во-вторых, с 5:30 утра до 14:09 20 октября, Network Load Balancer (NLB) испытывал повышенные ошибки подключения для некоторых балансировщиков. В-третьих, с 2:25 до 10:36 утра 20 октября, запуски новых экземпляров EC2 терпели неудачу, а те, что запустились, имели проблемы с подключением до 13:50.

Причиной инцидента стала редкая race condition в системе управления DNS DynamoDB. Эта система, ключевая для масштабируемости и отказоустойчивости DynamoDB, состоит из двух частей. DNS Planner создает планы обновления DNS на основе состояния пула серверов. DNS Enactor применяет эти планы, обновляя Route53 (систему DNS AWS). Обычно это работает надежно, но в данном случае два экземпляра DNS Enactor одновременно попытались обновить одну и ту же запись DNS, что привело к ее очистке. В результате, адрес dynamodb.us-east-1.amazonaws.com стал указывать в пустоту, и клиенты не могли установить соединение. Проблема была обнаружена и исправлена к 2:40 утра 20 октября, но вторичные эффекты привели к последующим инцидентам.

С 5:30 утра до 14:09 20 октября, Network Load Balancer (NLB) испытывал повышенные ошибки соединения для некоторых балансировщиков. Это было вызвано тем, что вторичный эффект инцидента DynamoDB привел к тому, что часть трафика NLB перенаправлялась на экземпляры, которые сами зависели от DynamoDB и стали недоступны. Это создавало каскадный эффект: пока DynamoDB был недоступен, часть трафика NLB терялась, что привело к ошибкам.

С 2:25 до 10:36 утра 20 октября, запуски новых экземпляров EC2 терпели неудачу. Это произошло потому, что сервис управления EC2 использует DynamoDB для хранения состояния, и когда DynamoDB был недоступен, он не мог создавать новые экземпляры. В 10:37 запуски возобновились, но до 13:50 некоторые экземпляры имели проблемы с сетью, так как они были созданы без полной конфигурации сети из-за race condition с NLB.

• AWS постмортем выглядит как маркетинговый документ, а не как техдок, что вызывает скепсис в честности их расследования.
• Сложность системы и отсутствие единого источника правды делает невозможным понять, действительно ли это была гонка условий или просто человеческая ошибка.
• Система, которая не может гарантировать согласованность DNS-записей, может быть сама по себе причиной сбоя.
• Похоже, что AWS не имеет четкого плана восстановления после сбоя, и их инструменты для этого зависят от самой системы, которую они пытаются восстановить.
• Постоянные сбои внутри AWS указывают на то, что их собственная инфраструктура неустойчива к сбоям, что вызывает вопросы о том, как они могли бы справиться с более серьезным инцидентом.

• AWS-инцидент 20 октября затронул DynamoDB, IAM, CloudWatch и ряд других сервисов, что вызвало каскадный сбой в десятках зависящих сервисов, включая Netflix, Robinhood, Reddit и другие.
• Пользователи отметили, что даже крупные компании, которые, казалось бы, должны были бы быть готовы к таким ситуациям, оказались неготовыми.
• Некоторые отметили, что AWS не предоставляет достаточной информации о статусе сервисов и что это не первый случай, когда такие сбои происходят.
• Некоторые отметили, что AWS не предоставляет достаточной информации о статусе сервисов и что это не первый случай, когда такие сбои происходят.

• AWS-инцидент затронул DynamoDB в регионе us-east-1, что каскадом вывел из строя десятки зависимых сервисов — от Amazon-магазина до Zoom и Coinbase.
• Пользователи вспомнили, что AWS-облако не единственный провайдер, и обсуждают, как минимизировать риски, включая мульти-регион и мульти-клауд.
• Некоторые комментаторы подчеркивают, что большинство сервисов, которые «упали» в этот день, на самом деле зависят от AWS, и что это не первый раз, когда такое случается.