Лишний сетевой прыжок в мульти-региональный AWS API стоил команде 75-100 мс на p90 уже в «хорошем» сценарии, около 315 мс в среднем и до 1 секунды в худшем. Проблему заметили не из-за борьбы за красивую метрику, а после серии региональных сбоев: оказалось, что глобальная архитектура формально была глобальной, а по факту клиенты все равно намертво привязывались к одному региону.
Об этом сообщает InfoQ в пересказе статьи инженера AWS Суреша Гурураджана. Он описал, как внутренняя служба пользовательских настроек в AWS годами жила с дополнительным pre-flight-вызовом, который был нужен только затем, чтобы понять, для какого региона подписывать следующий запрос. Когда сервис решили сделать действительно устойчивым к региональным авариям, именно этот шаг внезапно оказался главным архитектурным тормозом.
Речь идет о внутреннем сервисе, который хранит пользовательские настройки и отдает их другим командам AWS. Такие данные нужны быстро, часто прямо на старте приложения, поэтому изначальная схема выглядела вполне здраво: API Gateway в двух регионах, Route 53 с latency-based routing и идея, что инфраструктура сама выберет ближайшую точку. Но дальше в игру вступала IAM-аутентификация в API Gateway, а вместе с ней и AWS Signature Version 4, или SigV4. У этого механизма есть неприятная особенность: подпись запроса жестко включает регион. Если клиент подписал вызов под us-west-2, а трафик по дороге улетел в eu-west-1, запрос просто не пройдет проверку.
Из этого ограничения когда-то собрали рабочий компромисс. Перед первой «настоящей» операцией клиент делал отдельный неаутентифицированный вызов DiscoverRegion, получал имя региона, кэшировал его и уже потом подписывал все последующие запросы для этой точки через SigV4. Формально сервис оставался распределенным, но практическая логика маршрутизации жила уже не в Route 53, а в клиентской библиотеке. Для первого обращения выходило два запроса вместо одного, и система с этим спокойно прожила несколько лет.
Спокойствие закончилось после серии инцидентов в us-east-1. В статье перечислены как минимум три события, которые напрямую били по сервису: сетевые проблемы в декабре 2021 года, сбой Lambda в июне 2023-го и проблемы DynamoDB в октябре 2025-го. Поскольку сервис зависел от API Gateway, Lambda и DynamoDB, красиво «перелить» клиентов в другой регион не получалось. Если сессия уже прошла discovery и подписывала запросы под us-east-1, то криптографически она оставалась привязанной именно к нему. Перенаправить такой трафик в us-west-2 без повторного discovery было нельзя: подпись стала бы недействительной еще до обработки запроса. Для команды это было неприятное открытие: архитектура выглядела мульти-региональной, но в аварийном режиме вела себя как региональная с ручным сбросом состояния у клиентов.
Когда инженеры начали разбирать трассировки и пересматривать дизайн в четвертом квартале 2025 года, всплыл еще и ценник этой схемы в миллисекундах. Для новых клиентских сессий p90 у DiscoverEndpoint составлял 75-100 мс, если пользователь находился в том же регионе, что и найденный endpoint. В более типичном, но уже неидеальном сценарии, когда пользователь из us-west-2 получал endpoint в us-east-1, p90 доходил примерно до 315 мс. А в худшем кейсе, когда пользователь из us-west-2 попадал на ap-south-1 в Мумбаи, задержка на p90 подскакивала до 1 секунды. Для настроек, которые читаются на старте приложения, это уже не академическая потеря. Это то, что пользователь вполне может почувствовать как лишнюю задумчивость интерфейса.
Но задержка была только самой заметной частью счета. Кэш региона внутри клиента усложнял жизненный цикл сессии: если выбранный регион деградировал уже после discovery, клиенту нужно было не просто ретраить запрос, а понять, что проблема в региональной привязке, инвалидировать кэш, заново пройти discovery и только потом повторить исходную операцию. Для библиотеки, которую отдавали нескольким внутренним потребителям, это означало лишнюю ответственность за кэширование, политику ретраев и корректный credential scope. Иными словами, обходное решение перестало быть мелкой технической хитростью и выросло в заметный слой клиентской логики, который приходилось поддерживать отдельно от бизнес-функции сервиса.
Выходом стала AWS Signature Version 4A, или SigV4a, доступная еще с третьего квартала 2021 года. В отличие от обычной SigV4, она делает подпись валидной не для одного региона, а для набора регионов. Это меняет саму точку принятия решения: клиенту больше не нужно заранее угадывать, куда прилетит запрос. Маршрутизацию снова можно отдать инфраструктуре, а значит, мульти-региональный AWS API начинает вести себя так, как от него ожидают на схеме, а не только в презентации. По словам автора, сама замена SigV4 на SigV4a в коде оказалась небольшой. Гораздо тяжелее была координация зависимых вызовов и сам rollout: проблема оказалась не алгоритмической, а организационной.
Для разработчиков и архитекторов здесь полезен не только конкретный урок про AWS-подписи. История хорошо показывает, как временный workaround постепенно становится «естественной частью системы» и перестает обсуждаться, пока не случится серия отказов. Если в вашем облачном сервисе есть pre-flight-шаг, который существует только затем, чтобы узнать, как потом правильно аутентифицироваться, это уже повод насторожиться. Возможно, бизнес давно платит и миллисекундами, и сложностью отказоустойчивости за ограничение, которое когда-то было неизбежным, а теперь уже нет. Для российских команд, которые строят мульти-региональные или мульти-зональные API на публичных облаках, вывод довольно прямой: смотреть надо не только на p95 и цену трафика, но и на то, где именно в протоколе зашита привязка к конкретной площадке.
Такие истории обычно заканчиваются не выводом «надо срочно все переписать», а более неприятным вопросом: сколько еще клиентских библиотек в облачной инфраструктуре до сих пор тащат логику, оправданную реальностью трех- или пятилетней давности. История про мульти-региональный AWS API показывает, что следующая точка отказа может скрываться не в базе, не в DNS и не в балансировщике, а в одном старом «невинном» вызове, который все давно привыкли считать нормой.