История сбоев Amazon Web Services

1. 4 октября 2026 г. в 16:14 UTCresolved

   Мы расследуем повышенную потерю пакетов в регионе ЕС-Юг-2.

2. 4 октября 2026 г. в 16:36 UTCresolved

   Мы испытываем повышенную потерю пакетов с одной зоной доступности (eus2-az1) в регионе ЕС-Юг-2. Эта проблема также приводит к увеличению задержки API и частоты ошибок для других рабочих процессов и сервисов AWS. Инженеры были автоматически привлечены и работают над выявлением первопричины и смягчением проблемы. Мы предоставим вам еще одно обновление к 10:15 утра или раньше по мере поступления новой информации.

3. 4 октября 2026 г. в 17:06 UTCresolved

   Наши усилия по смягчению повышенной потери пакетов с помощью единой зоны доступности (eus2-az1) в регионе ЕС-Юг-2 все еще продолжаются. Мы видим некоторые признаки улучшения в результате многочисленных параллельных усилий. Мы продолжаем работать над тем, чтобы подтвердить первопричину и полностью смягчить проблему. Хотя в настоящее время у нас нет оценки того, сколько времени займут наши действия, мы будем держать вас в курсе нашего прогресса и предоставим вам еще одно обновление к 11:00 утра или раньше по мере появления новой информации.

4. 4 октября 2026 г. в 17:56 UTCresolved

   Мы определили первопричину и в настоящее время сосредоточили наши усилия по смягчению последствий для полного восстановления. Хотя у нас нет точной оценки того, сколько времени займут наши текущие усилия, мы ожидаем постепенных улучшений по мере продолжения наших усилий. Мы предоставим вам еще одно обновление к 11:45 утра, или раньше, если новая информация станет доступной.

5. 4 октября 2026 г. в 18:45 UTCresolved

   Мы видим ранние признаки восстановления. Мы предоставим вам еще одно обновление к 12:00 PM PDT.

6. 4 октября 2026 г. в 18:56 UTCresolved

   Между 8:48 и 11:28 утра по местному времени мы столкнулись с повышенной потерей пакетов в пределах одной зоны доступности (eus2-az1) в регионе ЕС-Юг-2. Эта проблема привела к увеличению задержки API и частоты ошибок для нескольких рабочих процессов и сервисов AWS. Мы были автоматически предупреждены о проблеме в 8:54 утра и сразу же начали работу по выявлению первопричины, пройдя несколько параллельных путей, чтобы смягчить проблему. К 10:00 наши усилия по смягчению последствий привели к некоторым улучшениям. К 10:38 утра мы определили первопричину, связанную с изменением конфигурации сети, которое мы смогли вернуть к 11:28 утра. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 21 сентября 2026 г. в 23:26 UTCresolved

   Мы изучаем увеличение частоты ошибок API в регионе US-EAST-1.

2. 21 сентября 2026 г. в 23:44 UTCresolved

   Мы можем подтвердить увеличение частоты ошибок, влияющих на запуск новых экземпляров, включая повышенные скорости ошибок API для RunInstances, CreateFleet и связанных с ними рабочих процессов запуска EC2 в регионе US-EAST-1. Клиенты, пытающиеся запустить новые экземпляры EC2, могут испытывать сбои запуска или повышенную задержку отклика API. Наши инженеры активно занимаются и работают над восстановлением проблемы. Мы видим первые признаки восстановления. Существующие случаи остаются нетронутыми. Мы рекомендуем повторно использовать неудавшиеся вызовы RunInstances и CreateFleet API. Мы предоставим обновление к 5:30 вечера PDT или раньше.

3. 22 сентября 2026 г. в 00:24 UTCresolved

   Между 3:49 вечера и 5:06 вечера PDT мы столкнулись с увеличением частоты ошибок, влияющих на запуск новых экземпляров в регионе US-EAST-1. В течение этого времени клиенты могли испытывать повышенные показатели ошибок при попытке запустить новые экземпляры EC2 через RunInstances, CreateFleet и связанные с ними рабочие процессы запуска EC2. В этот период также были затронуты сервисы AWS, которые запускают экземпляры EC2 от имени клиентов, включая Amazon ECS, AWS Fargate, Amazon EMR и другие. Мы определили первопричину как недавнее развертывание в подсистеме службы EC2, ответственной за обработку запросов на запуск экземпляра. Мы инициировали откат проблемного развертывания и начали наблюдать начальные признаки восстановления в 4:44 вечера. Существующие случаи остаются нетронутыми. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 3 сентября 2026 г. в 21:49 UTCresolved

   Начиная с 2:12 PM PDT, мы начали испытывать повышенную частоту ошибок API для STS и Sign In при использовании SAML в регионе US-WEST-2. Наша инженерная команда была автоматически привлечена в 2:19 вечера, чтобы начать расследование первопричины. В это время нет работы вокруг. Мы предоставим еще одно обновление к 3:30 PM PDT.

2. 3 сентября 2026 г. в 22:26 UTCresolved

   Мы видим ранние признаки восстановления и продолжаем следить за полным восстановлением. Мы предоставим еще одно обновление в 4:15 вечера или раньше, если у нас будет дополнительная информация для обмена.

3. 3 сентября 2026 г. в 23:20 UTCresolved

   Мы продолжаем наблюдать устойчивое восстановление API STS AssumeRoleWithSAML и AssumeRoleWithWebIdentity в регионе US-WEST-2. Показатели ошибок теперь вернулись к уровням до событий, и мы продолжаем активный мониторинг, чтобы подтвердить полное восстановление. Мы предоставим еще одно обновление к 5:15 вечера или ранее.

4. 4 сентября 2026 г. в 00:07 UTCresolved

   Между 2:12 PM и 3:18 PM PDT мы столкнулись с увеличением частоты ошибок API, влияющих на STS AssumeRoleWithSAML и AssumeRoleWithWebIdentity API в регионе US-WEST-2. Основная причина была определена из-за проблемы с подсистемой STS, ответственной за связь с внешними поставщиками идентификационных данных. Также были затронуты другие сервисы AWS, которые полагаются на эти протоколы федерации идентификации. В 3:18 мы наблюдали признаки восстановления и продолжали следить за тем, чтобы обеспечить стабильность и полное восстановление. Проблема решена, и на данный момент сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 21 августа 2026 г. в 02:02 UTCresolved

   AP-NORTHEAST-1-ー-ン-ー-ա- -の- Мы наблюдаем увеличение частоты ошибок, влияющих на показатели в реальном времени в регионе AP-NORTHEAST-1. Клиенты могут испытывать недостающие или отсроченные метрические данные в режиме реального времени.

2. 21 августа 2026 г. в 02:40 UTCresolved

   8:58 AM 10:34 AM AP-NORTHEAST-1 ー の の の の の の の の の の の の の の の の の の の の )の ) 10:13 AM .の.の . 10:34 AM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | Между 4:58 вечера и 6:34 вечера PDT мы столкнулись с увеличением задержек, влияющих на показатели в реальном времени для Amazon Connect в регионе AP-NORTHEAST-1, что привело к отсутствию или застойным данным. В течение этого времени клиенты, возможно, испытывали недостающие данные в аналитических отчетах и могли наблюдать проблемы при доступе к показателям в режиме реального времени в контактных потоках, таких как проверка персонала агента. Мы определили первопричину проблемы с подсистемой, ответственной за доставку метрических событий. Мы начали применять смягчения в 6:13 вечера и смягчили проблему к 6:34 вечера. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 19 августа 2026 г. в 15:15 UTCresolved

   Мы расследуем вопрос, который влияет на запуск новых экземпляров EC2 и ресурсов в недавно запущенной зоне доступности (euw2-az4) в регионе ЕС-Запад-2. В течение этого времени пострадавшие клиенты могут испытывать проблемы при создании или изменении ресурсов в Регионе. Могут быть затронуты и другие сервисы AWS. Для немедленного восстановления мы рекомендуем клиентам использовать альтернативные зоны доступности (euw2-az1, euw2-az2 и euw2-az3), где это применимо. Существующие текущие случаи и ресурсы не затронуты. Мы предоставим еще одно обновление к 10:00 утра или раньше, если у нас будет дополнительная информация для обмена.

2. 19 августа 2026 г. в 17:03 UTCresolved

   18 августа мы запустили новую зону доступности (euw2-az4) в регионе ЕС-Запад-2. После запуска мы начали испытывать ошибки при запуске экземпляров EC2 в новой зоне доступности, когда подсеть по умолчанию отсутствует. Мы можем подтвердить, что существующие текущие экземпляры и ресурсы не затронуты. Рабочие процессы, которые автоматически получают список зон доступности в Регионе через API DescribeAvailabilityZones, а затем пытаются запустить новые экземпляры или создать ресурсы в новой зоне доступности, могут столкнуться с ошибками. В случае сбоев в запуске экземпляра EC2 мы предпринимаем смягчающие меры для автоматического создания подсетей по умолчанию, где их еще нет, когда запуск экземпляра EC2 нацелен на новую зону доступности. Для клиентов и рабочих процессов, требующих немедленного исправления <a href="https://docs.aws.amazon.com/vpc/latest/userguide/work-with-default-vpc.html#create-default-subnet">, вы можете создать подсеть по умолчанию</a> в новой зоне доступности. Это позволит успешно завершить запуск экземпляра EC2. Для других ресурсов, таких как функции Lambda, где новая зона доступности в настоящее время не поддерживается, мы рекомендуем клиентам обновить свои рабочие процессы, чтобы исключить недавно запущенную зону доступности и продолжить создание ресурсов с использованием других зон доступности в регионе. Хотя у нас нет точной оценки того, сколько времени займут наши усилия по смягчению последствий, мы будем держать вас в курсе нашего прогресса и предоставим вам еще одно обновление к 1:00 вечера по мере поступления новой информации.

3. 19 августа 2026 г. в 18:47 UTCresolved

   В период с 18 августа 5:00 вечера по 19 августа 11:00 утра PDT мы столкнулись с повышенными ошибками при запуске экземпляров EC2 в недавно запущенной зоне доступности (euw2-az4) в регионе ЕС-Запад-2. После запуска новой зоны доступности мы начали испытывать ошибки при использовании VPC по умолчанию. Мы обнаружили первопричину проблемы 19 августа в 9:00 утра и начали развертывание изменения для решения проблемы в 9:30 утра. Пока шли изменения, мы начали видеть постепенные улучшения в новых экземплярах, с полным восстановлением в 11:00 утра. Существующие действующие инстанции и ресурсы не пострадали. Некоторые региональные службы, такие как функции Lambda или базы данных Aurora, не были доступны при запуске новой Зоны доступности, и со временем будет добавлена доступность услуг. Клиенты, пытающиеся создать ресурсы до того, как услуги станут доступны, увидят сообщение о том, что оно не поддерживается в Зоне доступности. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 15 августа 2026 г. в 03:42 UTCresolved

   Мы расследуем увеличение потери пакетов, влияя на подключение AWS Direct Connect для некоторых клиентов в регионе ЕС-Централ-1.

2. 15 августа 2026 г. в 04:42 UTCresolved

   Мы можем подтвердить потерю пакетов, влияющую на соединения Direct Connect в регионе EU-CENTRAL-1. Инженеры были автоматически вовлечены и сразу же начали работу по выявлению первопричины и определению нескольких параллельных путей для смягчения проблемы. В настоящее время мы наблюдаем ранние признаки восстановления. Мы предоставим еще одно обновление через 60 минут или раньше, если у нас будет дополнительная информация для обмена.

3. 15 августа 2026 г. в 05:55 UTCresolved

   Начиная с 7:33 PM PDT, мы начали испытывать увеличение потерь пакетов, влияющих на подключение AWS Direct Connect для некоторых клиентов в регионе ЕС-Централ-1. В то время как мы добились прогресса, соединения со следующим местоположением Direct Connect все еще нарушены: Equinix FR5, Франкфурт, DEU. Клиенты, у которых есть многосайтовое резервирование, настроенное на их пути прямого подключения, не должны наблюдать влияние в это время. Клиенты, у которых есть связи только в Equinix FR5, Франкфурт, DEU, будут продолжать испытывать проблемы с подключением. Мы активно работаем над смягчением последствий и работаем над полным восстановлением, но ожидаем, что полное восстановление займет несколько часов. Мы предоставим обновление через 90 минут или раньше, если у нас будет дополнительная информация для обмена.

4. 15 августа 2026 г. в 07:24 UTCresolved

   Мы активно работаем над восстановлением связи через расположение Direct Connect: Equinix FR5, Франкфурт, DEU. Клиенты, у которых есть связи только в Equinix FR5, Франкфурт, DEU, будут продолжать испытывать проблемы с подключением. Для клиентов, которые имеют возможность отказа от VPN, рекомендуется сделать это для достижения восстановления. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit Gateway, см. шаги <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. На данный момент мы ожидаем, что восстановление займет несколько часов. Мы предоставим еще одно обновление через 90 минут или раньше, если у нас будет дополнительная информация для обмена.

5. 15 августа 2026 г. в 09:08 UTCresolved

   Мы продолжаем работать над восстановлением подключения к AWS Direct Connect в Equinix FR5, Франкфурт, DEU. Основная причина связана с проблемой инфраструктуры объекта в месте, которое влияет на сетевую инфраструктуру. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов или ухудшение подключения. Клиенты с многосайтовыми или избыточными конфигурациями в других местах не подвергаются воздействию. Для обхода, пострадавшим клиентам, у которых есть возможность перейти на VPN, рекомендуется сделать это. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. На данный момент мы ожидаем, что восстановление займет несколько часов. Мы предоставим еще одно обновление в течение 2 часов или как только у нас будет больше информации для обмена.

6. 15 августа 2026 г. в 11:10 UTCresolved

   Связь AWS Direct Connect остается нарушенной для клиентов, подключенных к Equinix FR5 во Франкфурте, DEU. Клиенты с многосайтовой или избыточной конфигурацией в других местах по-прежнему остаются незатронутыми. Инженеры активно работают над восстановлением связи, при этом усилия продолжаются в нескольких рабочих потоках для решения основной проблемы объекта и возвращения пострадавшего сетевого оборудования в эксплуатацию. Мы по-прежнему ожидаем, что восстановление займет несколько часов. Для обходного пути, пострадавшие клиенты, которые имеют возможность отказа от VPN, рекомендуется сделать это. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы предоставим еще одно обновление в течение 2 часов или как только у нас будет больше информации для обмена.

7. 15 августа 2026 г. в 13:17 UTCresolved

   Инженеры продолжают работу по восстановлению связи в офисе Equinix FR5 во Франкфурте. Наш партнер по совместному размещению работает над решением основной проблемы инфраструктуры объекта, и, хотя улучшения еще не видны клиентам, мы добиваемся положительного прогресса в направлении решения. Для клиентов, которым требуется немедленное восстановление, мы рекомендуем отказаться от VPN, как указано в наших предыдущих обновлениях. Мы предоставим еще одно обновление к 9:30 утра или раньше, если у нас будет дополнительная информация для обмена.

8. 15 августа 2026 г. в 16:27 UTCresolved

   Наш партнер по совместному размещению продолжает работать над решением проблемы базовой инфраструктуры объекта в месте расположения Equinix FR5 во Франкфурте, DEU. Доступ к пострадавшему району в настоящее время ограничен из-за проблем безопасности, что влияет на нашу способность оценивать физическое состояние сетевого оборудования и обеспечивать более точные сроки восстановления. Основываясь на текущей информации, полное восстановление не ожидается в ближайшей перспективе и может выйти за рамки сегодняшнего дня. Связи AWS Direct Connect в этом месте остаются неисправными. Клиенты с избыточными связями через другие места остаются незатронутыми. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы предоставим еще одно обновление к 3:30 вечера, или раньше, если у нас будет дополнительная информация для обмена.

9. 15 августа 2026 г. в 22:26 UTCresolved

   Наш партнер по совместному размещению продолжает работу по восстановлению безопасного доступа к пострадавшему району во Франкфурте, DEU. Как только будет обеспечен безопасный доступ, наши инженеры смогут оценить затронутые сетевые устройства. Мы продолжаем внимательно следить за прогрессом и поделимся обновлением к 9:30 вечера по мере поступления новой информации.

10. 16 августа 2026 г. в 04:37 UTCresolved

    Мы активно взаимодействуем с нашим партнером по совместному размещению, чтобы восстановить связь в Equinix FR5 во Франкфурте, DEU. С момента последнего обновления мы добились прогресса в восстановлении безопасного доступа к пострадавшему району во Франкфурте, DEU. Параллельно мы определили приоритетность порядка восстановления критических и высокоприоритетных стоек в рамках усилий по смягчению последствий. Основываясь на нашей текущей оценке, полное восстановление не ожидается в ближайшей перспективе и может выйти за рамки сегодняшнего дня. Связи AWS Direct Connect в этом месте остаются неисправными. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов. Клиенты с многосайтовыми или избыточными конфигурациями в других местах Direct Connect остаются незатронутыми. Для обхода, пострадавшим клиентам, у которых есть возможность перейти на VPN, рекомендуется сделать это. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы продолжаем внимательно следить за прогрессом и поделимся обновлениями к 16 августа 3:30 утра по мере поступления новой информации.

11. 16 августа 2026 г. в 10:25 UTCresolved

    Мы продолжаем работать с нашим партнером по совместному размещению, чтобы восстановить связь в месте расположения Equinix FR5 во Франкфурте, DEU. С момента последнего обновления мы добились значительного прогресса в восстановлении безопасного доступа к пострадавшему району. В настоящее время проводится процедура электрической изоляции, и наши команды находятся на месте в электрической комнате, выполняя деэнергизацию пострадавшей инфраструктуры. После того, как изоляция будет проверена и подтверждена в безопасности, инженеры начнут физический осмотр пострадавшего сетевого оборудования, чтобы определить объем требуемой замены. Основываясь на нашей текущей оценке, полное восстановление не ожидается в ближайшем будущем из-за масштабов потенциального воздействия на оборудование. Связи AWS Direct Connect в этом месте остаются неисправными. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов. Клиенты с многосайтовыми или избыточными конфигурациями в других местах Direct Connect остаются незатронутыми. Для обхода, пострадавшим клиентам, у которых есть возможность перейти на VPN, рекомендуется сделать это. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, мы рекомендуем создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы продолжаем внимательно следить за прогрессом и поделимся обновлениями к 16 августа 9:30 утра по мере поступления новой информации.

12. 16 августа 2026 г. в 16:30 UTCresolved

    Электрическая изоляция на Equinix FR5 во Франкфурте, DEU, завершена, и наши инженеры приступили к физическому осмотру пострадавшего сетевого оборудования. У нас пока нет графика полного разрешения, пока мы продолжаем оценивать степень воздействия на оборудование. Прямое соединение в этом месте остается нарушенным. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов. Клиенты с многосайтовыми или избыточными конфигурациями в других местах прямого подключения не затронуты. Мы рекомендуем, чтобы это повлияло на отказ клиентов от VPN, пока у нас не будет больше ясности в отношении следующих шагов и сроков восстановления. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, вы можете создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit Gateway, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы предоставим еще одно обновление к 16 августа 5:30 вечера PDT или раньше по мере поступления новой информации.

13. 16 августа 2026 г. в 22:51 UTCresolved

    Мы завершили оценку сетевого оборудования Equinix FR5 во Франкфурте и теперь имеем четкое представление о масштабах воздействия. Мы добиваемся прогресса в восстановлении связи и будем применять поэтапный подход к восстановлению. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов до тех пор, пока восстановление не будет завершено. Клиенты с многосайтовыми или избыточными конфигурациями в других местах прямого подключения не затронуты. Мы предоставим еще одно обновление к 16 августа 10:30 вечера PDT или раньше по мере поступления новой информации.

14. 17 августа 2026 г. в 05:38 UTCresolved

    Мы продолжаем добиваться прогресса в нашем поэтапном восстановлении в месте расположения Equinix FR5 во Франкфурте, DEU. С момента нашего последнего обновления была восстановлена некоторая зависимая сетевая инфраструктура. Продолжается восстановление оставшейся инфраструктуры, причем часть восстановления зависит от поставки сменного оборудования. Охлаждение полностью восстановлено, условия окружающей среды стабильны в пределах нормальных рабочих порогов. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов по мере восстановления. Клиенты с многосайтовыми или избыточными конфигурациями в других местах прямого подключения не затронуты. Ранее сообщенные руководящие указания и рекомендации по смягчению последствий остаются неизменными в настоящее время. Мы предоставим еще одно обновление к 17 августа 4:30 утра PDT или раньше по мере восстановления.

15. 17 августа 2026 г. в 11:22 UTCresolved

    Мы продолжаем добиваться прогресса в нашем поэтапном восстановлении в месте расположения Equinix FR5 во Франкфурте, DEU. Сетевая инфраструктура и зависимые системы продолжают улучшаться, поскольку мы возвращаем пострадавшее оборудование в Интернет. Некоторое оборудование для замены было доставлено, и установка продолжается по мере поступления компонентов на место. Параллельно мы меняем сетевой трафик, чтобы позволить восстановленным устройствам начать обслуживать клиентов по мере их выхода в Интернет. По мере того, как мы продвигаемся по пути восстановления, клиенты будут наблюдать восстановление в два этапа. На первом этапе сессии BGP будут восстановлены, но префиксы IP пока не будут рекламироваться, что указывает на то, что восстановление все еще продолжается, а базовая инфраструктура еще не готова к переносу трафика. На втором этапе будет возобновлена реклама префиксов IP, после чего инфраструктура будет полностью восстановлена. Хотя в настоящее время у нас нет ETA для полного восстановления, мы продолжаем работать как можно быстрее и безопасно, чтобы смягчить последствия для клиентов. Мы предоставим еще одно обновление к 17 августа 10:30 утра PDT или раньше по мере восстановления.

16. 17 августа 2026 г. в 16:25 UTCresolved

    Мы продолжаем работать над поэтапной реабилитацией в месте расположения Equinix FR5 во Франкфурте, DEU. Мы видим ранние признаки восстановления, в то время как мы продолжаем полностью устранять проблему. Мы активно работаем над тем, чтобы вернуть оставшееся затронутое оборудование в онлайн-режим, и мы предоставим еще одно обновление к 12:30 вечера PDT или раньше по мере восстановления.

17. 17 августа 2026 г. в 17:59 UTCresolved

    Мы видим широкие признаки восстановления в Equinix FR5 во Франкфурте, DEU. Мы восстановили связь для большинства затронутых устройств, и большинство соединений полностью восстановлены и стабильны. Есть небольшое количество клиентов, которые останутся затронутыми, пока оставшиеся устройства не будут полностью восстановлены. Мы предоставим еще одно обновление к 2:00 PM PDT или раньше по мере восстановления.

18. 17 августа 2026 г. в 21:00 UTCresolved

    Мы продолжаем работать над возвращением пострадавшего оборудования в Интернет. С момента последнего обновления мы добились прогресса, который не будет виден клиентам, но необходим для восстановления. Мы работаем параллельно, чтобы максимально безопасно вывести все устройства в интернет. Ожидается, что эта работа займет несколько часов для завершения и проверки. Для клиентов, которым требуются обходные пути, мы рекомендуем вам рассмотреть возможность отказа от VPN. Для клиентов, использующих шлюз Direct Connect и шлюз Transit Gateway, вы можете создать VPN-сервис AWS Site-to-Site и прикрепить его к вашему шлюзу Transit Gateway, обратитесь к шагам <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">здесь</a>. Для других клиентов мы рекомендуем установить AWS Site-to-Site VPN в качестве временного пути резервного копирования, обратитесь к шагам <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">здесь</a>. Мы предоставим еще одно обновление к 7:00 PM PDT или раньше по мере поступления новой информации.

19. 18 августа 2026 г. в 01:50 UTCresolved

    На этом этапе мы наблюдаем значительное восстановление большинства связей с клиентами. Несмотря на то, что мы еще не полностью восстановились, усилия по восстановлению продолжаются, как и ожидалось, в месте расположения Equinix FR5 во Франкфурте, DEU. Восстановление оставшейся инфраструктуры включает в себя завершение замены оборудования и проверку трафика, которые активно ведутся. Мы ожидаем дальнейшего оживления, поскольку оставшаяся инфраструктура возвращается в эксплуатацию. Клиенты, подключенные исключительно в этом месте, будут продолжать испытывать потерю пакетов до тех пор, пока восстановление не будет завершено. Ранее сообщенные руководящие указания и рекомендации по смягчению последствий остаются неизменными в настоящее время. Мы предоставим еще одно обновление до 17 августа 11:00 вечера PDT или раньше.

20. 18 августа 2026 г. в 04:01 UTCresolved

    Начиная с 14 августа 7:33 PM PDT, мы столкнулись с увеличением потери пакетов, влияющих на подключение AWS Direct Connect для клиентов с соединениями в месте Equinix FR5 во Франкфурте, DEU. Инженеры были автоматически привлечены к работе в 7:45 вечера 14 августа и немедленно начали расследование по смягчению последствий. К 8:30 мы определили, что сетевое оборудование на FR5 было повреждено из-за попадания воды в объект совместного размещения. В результате система охлаждения была нарушена, что привело к перегреву и выключению устройств. Вода также повлияла на системы распределения электроэнергии, которые отключили питание сетевых устройств. Первоначальные усилия по восстановлению были отложены, поскольку условия окружающей среды на объекте требовали стабилизации, прежде чем инженеры могли безопасно добраться до пострадавшего района. В течение 15 и 16 августа наши инженеры работали в координации с оператором объекта для восстановления поврежденных сетевых устройств. К 7:26 вечера 17 августа все поврежденное сетевое оборудование было успешно восстановлено, а подключение к месту было проверено как полностью работоспособное с устойчивым восстановлением. Мы не ожидаем, что этот вопрос повторится. Клиенты с избыточными соединениями в других местах Direct Connect поддерживали связь через альтернативные пути на протяжении всего мероприятия и не требовали никаких дальнейших действий. Клиенты, которые внедрили отказ VPN в качестве обходного пути, теперь могут безопасно вернуться к своим основным путям прямого подключения. Подключение было проверено как стабильное и полностью работоспособное. Клиенты, нуждающиеся в дополнительной помощи, могут обратиться в службу поддержки AWS через Консоль управления AWS или через Центр поддержки AWS <a href="https://console.aws.amazon.com/support".

Автоматический перевод официального обновления инцидента.

1. 31 июля 2026 г. в 17:33 UTCresolved

   Мы можем подтвердить повышенную потерю сетевых пакетов, что влияет на подключение AWS Direct Connect в регионе AP-SOUTH-1. Наша инженерная команда была автоматически привлечена к расследованию в 9:54 утра. В настоящее время нет доступных обходных путей. Мы предоставим еще одно обновление к 11:30 утра PDT.

2. 31 июля 2026 г. в 18:27 UTCresolved

   Мы определили первопричину, связанную с изменением системы конфигурации, ответственной за назначение маршрутов устройствам. Мы начали работу по сокращению потерь пакетов, которые влияют на AWS Direct Connect в регионе AP-SOUTH-1, и мы ожидаем, что восстановление будет происходить постепенно в течение следующих 30 минут. По мере того, как мы обретаем уверенность в этих усилиях, мы будем стремиться к параллелизации наших усилий по ускорению восстановления. Мы предоставим еще одно обновление к 12:00 PM PDT.

3. 31 июля 2026 г. в 18:54 UTCresolved

   В период с 9:42 до 11:44 утра PDT мы столкнулись с повышенной потерей сетевых пакетов, что повлияло на подключение AWS Direct Connect в регионе AP-SOUTH-1. Наша инженерная команда автоматически начала расследование в 9:46 утра. К 10:51 утра мы поняли первопричину изменения конфигурации системы, ответственной за назначение маршрутов устройствам. Когда мы обрели уверенность в наших мерах по смягчению последствий, мы распараллелили наши усилия по дальнейшему сокращению потерь пакетов. Проблема решена, и сервис работает нормально.

Автоматический перевод официального обновления инцидента.

1. 24 июля 2026 г. в 11:40 UTCresolved

   Мы изучаем проблемы коннективности, влияющие на несколько сервисов AWS в регионе США-Запад-2.

2. 24 июля 2026 г. в 11:56 UTCresolved

   Мы видим первые признаки восстановления и продолжаем работать над полным восстановлением.

3. 24 июля 2026 г. в 12:30 UTCresolved

   Мы по-прежнему видим значительные признаки восстановления в результате наших усилий по смягчению последствий проблем с подключением, влияющих на несколько сервисов AWS в регионе США-Запад-2. Мы определили первопричину проблемы с сетевым устройством, ответственным за маршрутизацию сети из Региона в метро Сиэтла. Инженеры завершили все работы по смягчению последствий. Поскольку маршруты продолжают восстанавливаться, клиенты должны видеть постоянное снижение количества ошибок и тайм-аутов при подключении к пострадавшим услугам. Мы внимательно следим за прогрессом в восстановлении и будем продолжать работать до тех пор, пока все маршруты не будут полностью восстановлены, а показатели обслуживания не вернутся на уровень, предшествующий событию. Мы предоставим еще одно обновление в ближайшие 30-45 минут.

4. 24 июля 2026 г. в 13:01 UTCresolved

   Между 3:55 и 4:15 утра мы столкнулись с проблемами подключения, которые повлияли на подключение к региону США-Запад-2. Это повлияло на несколько сервисов AWS в регионе. У некоторых клиентов могут возникнуть проблемы с доступом к консоли управления AWS, с перерывами в подключении и неотзывчивыми страницами. Связь внутри региона не пострадала. Наши инженеры автоматически занялись в 4:01 утра ПДТ, и тут же приступили к расследованию этого вопроса. Мы определили первопричину проблемы с сетевыми устройствами, ответственными за маршрутизацию сети из Региона в метро Сиэтла, и начали параллельно работать над несколькими путями для смягчения последствий. Мы приняли меры по смягчению последствий, которые привели к первоначальному восстановлению в 4:15 утра. По мере того, как сеть продолжала стабилизироваться после наших действий по смягчению последствий, произошло короткое событие реконвергенции между 4:47 и 4:59 утра PDT. В течение этого периода реконвергенции некоторые клиенты, возможно, испытывали периодические проблемы с подключением к Региону по мере восстановления сетевых маршрутов. К 4:59 утра PDT все маршруты были полностью восстановлены, а показатели обслуживания вернулись к уровням, предшествующим событию. Клиенты, использующие AWS Direct Connect через EqSe2, Westin Building Exchange, Сиэтл, испытали расширенное окно воздействия с 3:55 до 5:12 утра PDT. Эти клиенты испытывали проблемы с подключением, пока сетевые маршруты для этого конкретного пути не были полностью восстановлены в 5:12 утра по местному времени. Потребители, подключенные через другие места AWS Direct Connect, не пострадали от этого события. Проблема решена, и все сервисы AWS работают нормально.

Автоматический перевод официального обновления инцидента.

1. 17 июля 2026 г. в 08:33 UTCresolved

   Мы изучаем проблемы с Cost Explorer, отражающие неточные расчетные данные.

2. 17 июля 2026 г. в 09:07 UTCresolved

   Начиная с 16 июля 7:38 вечера PDT, мы начали отображать неверные расчетные данные в консоли для выставления счетов и управления расходами. Наши инженерные команды занимаются и исследуют первопричину. Мы предоставим еще одно обновление к 3:00 утра или раньше, если появится дополнительная информация.

3. 17 июля 2026 г. в 10:03 UTCresolved

   Мы продолжаем работать над решением проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления расходами. Мы определили первопричину проблемы с ценообразованием единиц в подсистеме расчетных расчетов, и мы работаем над смягчением последствий. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Как только проблема будет смягчена, мы ожидаем, что полное решение займет несколько часов, поскольку мы работаем над пересчетом расчетных данных. Мы предоставим еще одно обновление к 4:00 утра или раньше, если появится дополнительная информация.

4. 17 июля 2026 г. в 10:52 UTCresolved

   Мы продолжаем работать над решением проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления расходами. Как уже упоминалось ранее, мы определили первопричину проблемы с ценообразованием единиц в подсистеме расчетных расчетов. Чтобы предотвратить дальнейшее отображение неточных расчетных оценок, мы приостановили расчетные расчеты. Клиенты, которые в настоящее время видят нормальные оценки счетов, будут продолжать видеть эти оценки, а клиенты, которые видят завышенные оценки, не увидят их дальнейшего увеличения, пока мы работаем над разрешением. Показанные расчетные оценки не отражают фактическое использование и сборы. Мы продолжаем работать над полным смягчением проблемы. Как только проблема будет смягчена, мы ожидаем, что полное решение займет несколько часов, поскольку мы работаем над пересчетом расчетных данных. На данный момент никаких действий клиентов не требуется. Мы предоставим еще одно обновление к 5:00 утра или раньше, если появится дополнительная информация.

5. 17 июля 2026 г. в 11:58 UTCresolved

   Мы продолжаем работать над решением проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления расходами. Мы активно работаем над несколькими путями смягчения последствий параллельно. Первый путь включает в себя возвращение к последнему известному хорошему расчету счета. При таком подходе клиенты будут видеть данные о стоимости и использовании только до 15 июля, однако данные о завышенных затратах будут удалены. Второй путь включает в себя откат недавних изменений в подсистеме расчетов. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Как только проблема будет смягчена, мы ожидаем, что полное решение займет несколько часов, поскольку мы работаем над пересчетом расчетных данных. Мы предоставим еще одно обновление к 6:00 утра или раньше, если появится дополнительная информация.

6. 17 июля 2026 г. в 12:54 UTCresolved

   Мы продолжаем работать над несколькими путями смягчения последствий параллельно, чтобы решить проблему, затрагивающую предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления затратами, включая отчет о затратах и использовании. Мы оцениваем возобновление расчетных расчетов, поскольку наш внутренний мониторинг показывает, что подсистема расчетных расчетов в настоящее время производит точные оценки. Мы проводим дополнительную проверку, прежде чем идти по этому пути. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Мы предоставим еще одно обновление к 8:00 утра или раньше, если появится дополнительная информация.

7. 17 июля 2026 г. в 14:53 UTCresolved

   Мы продолжаем работать над решением проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления затратами, включая отчет о затратах и использовании. Откат недавних изменений не решил проблему, и мы продолжаем исследовать несколько путей смягчения последствий. Предполагаемые обновления законопроектов остаются приостановленными. Мы возвращаемся к последним точным оценочным данным. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Мы ожидаем, что это смягчение займет несколько часов, поскольку мы работаем над пересчетом расчетных данных. Мы предоставим еще одно обновление к 10:00 утра или раньше, если появится дополнительная информация.

8. 17 июля 2026 г. в 16:59 UTCresolved

   Мы определили первопричину и смягчили основную проблему, вызывающую неверную оценку стоимости и данных об использовании, которые будут отображаться в консоли учета и управления затратами, а также отчетах о затратах и использовании. Мы начали заполнение данных, чтобы исправить данные о стоимости для всех клиентов. Мы ожидаем, что некоторые клиенты начнут восстановление в течение следующих трех часов, а полное восстановление для всех клиентов к 18 июля 12:00 вечера. До тех пор, пока заполнение не будет завершено, некоторые клиенты могут по-прежнему видеть неверные данные о стоимости и использовании. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Мы предоставим еще одно обновление к 1:00 вечера или раньше, если информация станет доступной.

9. 17 июля 2026 г. в 19:56 UTCresolved

   Наши усилия по заполнению скорректированных сметных расходов и данных об использовании все еще продолжаются. Мы продвигаемся медленнее, чем ожидалось. Хотя мы видим, что некоторые учетные записи восстанавливаются с правильными данными о стоимости и использовании, мы ожидаем, что все затронутые учетные записи будут восстановлены к 19 июля 12:00 утра по местному времени. До тех пор, пока заполнение не будет завершено, некоторые клиенты могут по-прежнему видеть неверные данные о стоимости и использовании. Показанные расчетные оценки не отражают фактическое использование и сборы. На данный момент никаких действий клиентов не требуется. Мы предоставим еще одно обновление к 7:00 вечера или раньше, если информация станет доступной.

10. 18 июля 2026 г. в 01:38 UTCresolved

    Мы продолжаем добиваться устойчивого прогресса в решении проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления расходами. Наши усилия по заполнению исправленных данных продолжаются, и мы ожидаем, что все затронутые учетные записи будут полностью восстановлены к 19 июля 12:00 утра по местному времени. До тех пор, пока заполнение не будет завершено, некоторые клиенты могут по-прежнему видеть неверные данные о стоимости и использовании в отчетах о расходах и использовании. Эти оценки не отражают фактическое использование или сборы. Клиенты, которые настроили свой отчет о затратах и использовании с помощью опции «Перезапись», не требуют никаких действий — их отчет будет автоматически обновляться с исправленными данными после завершения обратного заполнения. Клиенты, которые настроили свой отчет о стоимости и использовании с опцией «Создать новые версии отчета», сохраняют все предыдущие поставки отчета в своем ведре S3. Версия отчета, представленная во время затронутого окна, может содержать неточные данные. Как только заполнение данных будет завершено, исправленная версия отчета будет доставлена в рамках новой сборки. Клиенты, использующие эту конфигурацию, должны обновлять любые нижестоящие процессы (таблицы Афины, трубопроводы Redshift, Amazon QuickSight или пользовательский ETL), чтобы ссылаться на последнюю сборку Id для затронутого периода выставления счетов, и могут удалять или архивировать затронутую версию отчета, чтобы предотвратить обработку устаревших данных. Чтобы определить последний отчет, клиенты могут следовать шагам в нашей документации <a href="https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html">. Мы предоставим еще одно обновление к 18 июля в 1:00 утра по местному времени или раньше, если дополнительная информация станет доступной.

11. 18 июля 2026 г. в 08:05 UTCresolved

    Мы продолжаем добиваться существенного прогресса в решении проблемы, затрагивающей предполагаемые затраты и данные об использовании, отображаемые в консоли учета и управления расходами. Наши усилия по смягчению последствий работают, как и ожидалось, и мы видим все большее число учетных записей, отражающих правильные данные о затратах и использовании. Мы ожидаем, что все затронутые учетные записи будут полностью восстановлены к 19 июля в 12:00 по местному времени. До тех пор, пока заполнение не будет завершено, некоторые клиенты могут по-прежнему видеть неверные данные о стоимости и использовании в отчетах о расходах и использовании. Эти оценки не отражают фактическое использование или сборы. Мы предоставим еще одно обновление к 18 июля, 7:00 утра PDT, или раньше, если появится дополнительная информация.

12. 18 июля 2026 г. в 13:57 UTCresolved

    С 16 июля в 7:38 вечера PDT и 18 июля в 6:00 утра PDT мы начали отображать неверные расчетные данные в консоли учета и управления расходами, включая отчет о стоимости и использовании. Клиенты, возможно, получили ошибочные предупреждения об обнаружении бюджетных и стоимостных аномалий и наблюдали завышенные расчетные данные о стоимости и использовании. 16 июля в 7:46 вечера PDT наши сигналы тревоги обнаружили аномалии в стоимости, но не смогли остановить процесс формирования расчетных счетов или предупредить наши инженерные команды. Мы были предупреждены об этом 17 июля в 12:19 по местному времени из-за эскалации и немедленно начали расследование. Мы впервые проинформировали клиентов через AWS Health 17 июля в 1:33 утра. В 8:24 утра мы приостановили дальнейшие обновления расчетных данных и отключили предупреждения о бюджетной аномалии в качестве меры предосторожности. Мы определили первопричину 17 июля в 12:00 PM PDT как изменение конфигурации в нашей системе расчетов счетов. Эта система опирается на данные о преобразовании единиц для расчета зарядов строки. Изменение конфигурации привело к сбою обновлений данных о преобразовании блока, что привело к завышенным расходам на линейные элементы, которые распространились на консоль Billing and Cost Management и вызвали предупреждения о бюджетных и стоимостных аномалиях. Мы смягчили проблему 17 июля в 12:30 вечера PDT, которая исправила конфигурацию конверсии блока и начала переработку данных о стоимости и использовании для всех учетных записей клиентов. Мы начали наблюдать восстановление в 4:19 вечера PDT, и большинство счетов были полностью восстановлены к 18 июля в 6:00 утра PDT. Существует небольшое количество учетных записей, которые все еще обрабатываются, и мы опубликуем обновления для этих учетных записей на панели управления личным здоровьем. Мы исправили наши тревоги, чтобы немедленно прекратить обработку и уведомить наши инженерные команды, когда происходят аномалии. Мы приносим извинения за тревогу, вызванную этим инцидентом, и проводим тщательную ретроспективу, чтобы предотвратить повторение подобных событий, а также улучшить нашу реакцию при возникновении инцидентов с выставлением счетов. Проблема решена, и все сервисы AWS работают в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 16 июля 2026 г. в 08:44 UTCresolved

   Мы расследуем увеличение числа ошибок 5xx для клиентов Cloudfront, использующих связь с VPC Origins.

2. 16 июля 2026 г. в 09:21 UTCresolved

   Начиная с PDT в 12:45 утра, мы испытываем повышенные ошибки 5xx для клиентов CloudFront, использующих связь с VPC Origins. Мы подтвердили, что клиенты, использующие другие типы происхождения, не затронуты этой проблемой. Наши инженеры активно работают над смягчением последствий. В качестве обходного пути клиенты, которым не требуется VPC Origins, могут изменить свой тип происхождения, чтобы устранить ошибки. Мы предоставим еще одно обновление к 3:15 утра PDT, или раньше, если появится дополнительная информация.

3. 16 июля 2026 г. в 10:18 UTCresolved

   Мы продолжаем работать над устранением ошибок 5xx для клиентов CloudFront, использующих подключение к VPC Origins. Клиенты, использующие другие типы происхождения, остаются незатронутыми этой проблемой. Основываясь на нашем исследовании, мы считаем, что первопричина связана с подсистемой обработки пакетов, ответственной за маршрутизацию запросов от краевых локаций CloudFront к ресурсам внутри клиентских VPC. Мы по-прежнему рекомендуем клиентам, которые могут сделать это, временно изменить свой тип происхождения, чтобы устранить ошибки. Мы предоставим еще одно обновление к 4:15 утра, или раньше, если дополнительная информация станет доступной.

4. 16 июля 2026 г. в 11:16 UTCresolved

   Мы продолжаем работать над устранением ошибок 5xx для клиентов CloudFront, использующих подключение к VPC Origins. Клиенты, использующие другие типы происхождения, остаются незатронутыми этой проблемой. Мы также рассмотрели проблему вплоть до емкости таблицы маршрутизации в подсистеме обработки пакетов, ответственной за запросы маршрутизации из краевых местоположений CloudFront к ресурсам в клиентских VPC. Мы определили и в настоящее время тестируем стратегию смягчения последствий для решения этой проблемы. Как только тестирование будет завершено, мы развернем смягчение в поэтапном подходе. Основываясь на результатах этих тестов, мы предоставим более четкое расчетное время для разрешения в нашем следующем обновлении. Мы по-прежнему рекомендуем клиентам, которые могут сделать это, временно изменить свой тип происхождения, чтобы устранить ошибки. Мы предоставим еще одно обновление к 5:15 утра, или раньше, если дополнительная информация станет доступной.

5. 16 июля 2026 г. в 11:27 UTCresolved

   Мы видим первые признаки восстановления и продолжаем работать над полным восстановлением.

6. 16 июля 2026 г. в 11:57 UTCresolved

   Мы по-прежнему видим значительные признаки восстановления в результате наших усилий по смягчению последствий, и полное восстановление ожидается в течение следующих 45 минут.

7. 16 июля 2026 г. в 12:21 UTCresolved

   Между 12:45 и 4:18 утра PDT мы столкнулись с увеличением ошибок 5xx для клиентов CloudFront, использующих связь с VPC Origins. Наши инженеры были автоматически привлечены и немедленно начали расследование первопричины. К 2:57 мы определили первопричину проблемы как внутреннее ограничение для флота, который управляет связями с частными источниками VPC. Когда это ограничение было достигнуто, система, отвечающая за распределение конфигурации маршрутизации для наших сетевых процессоров, не смогла правильно загрузить обновленные данные конфигурации, что повлияло на маршрутизацию соединений VPC Origin. В 3:52 утра PDT мы предприняли несколько действий по смягчению последствий, которые привели к полному восстановлению в 4:18 утра PDT. Теперь, когда проблема была смягчена, клиенты, которые временно изменили свой тип происхождения, могут безопасно вернуть эти изменения. Клиенты, использующие другие типы происхождения, не были затронуты этой проблемой. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 15 июля 2026 г. в 23:11 UTCresolved

   Мы изучаем повышенные проблемы с подключением к единой зоне Avalability (euc1-az2) в регионе ЕС-Централ-1.

2. 15 июля 2026 г. в 23:36 UTCresolved

   Мы видим ранние признаки восстановления и продолжаем работать над полным разрешением. Мы будем продолжать предоставлять обновления.

3. 16 июля 2026 г. в 01:24 UTCresolved

   Между 2:56 PM и 6:07 PM PDT мы столкнулись с проблемами подключения к подмножеству экземпляров EC2 в одной зоне доступности (euc1-az2) в регионе ЕС-Централ-1. В течение этого времени клиенты могут также испытывать повышенные частоты ошибок и задержки при запуске новых экземпляров в затронутой зоне, а также некоторые API AWS, которые используют затронутые экземпляры EC2. Некоторые службы AWS также столкнулись с проблемами подключения и увеличением частоты ошибок в зоне риска. Инженеры были автоматически привлечены и немедленно начали расследование. В рамках наших усилий по восстановлению мы переместили трафик из зоны доступности для пострадавших служб в 3:04 вечера. В 3:05 мы определили первопричину недавних изменений в сети. Инженеры немедленно начали возвращать это изменение, которое завершилось в 4:28 вечера. Это привело к восстановлению сетевого подключения к пострадавшей зоне в 4:30 вечера. Мы продолжали работать, пока полностью не восстановили удары в 6:07 вечера. Мы не ожидаем, что этот вопрос повторится. Проблема решена и сервис работает в штатном режиме.

Автоматический перевод официального обновления инцидента.

1. 6 июля 2026 г. в 12:45 UTCresolved

   We are investigating increased error rates when calling EC2 Launch Template APIs in US-EAST-1 Region. During this time, affected customers may experience errors when creating, modifying, or referencing launch templates. Other AWS services that rely on launch templates may also be impacted. We will provide another update by 6:30 AM PDT or sooner, if we have additional information to share.

2. 6 июля 2026 г. в 13:34 UTCresolved

   Starting at 2:56 AM PDT, we began experiencing increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. Our engineers have been engaged and are actively working to mitigate the impact. Additionally, Amazon Elastic Kubernetes (EKS) customers may experience errors when creating or updating clusters, or when launching and scaling nodes via Managed Node Groups, EKS Auto Mode, or Karpenter; this issue does not impact existing clusters and nodes. We have identified the root cause to be a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. We are pursuing multiple mitigation paths. We recommend that customers retry any failed requests during the impact window. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 7:15 AM PDT or sooner if we have additional information to share.

3. 6 июля 2026 г. в 14:12 UTCresolved

   We are seeing initial signs of recovery and continue to work toward full recovery.

4. 6 июля 2026 г. в 14:53 UTCresolved

   Between 2:56 AM and 6:54 AM PDT, we experienced increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. During this time, affected customers may have experienced errors when creating, modifying, or describing Launch Templates. Other AWS services that rely on Launch Templates were also impacted. Amazon EC2 instances and Amazon EKS workloads already running on provisioned nodes continued to operate normally. Cluster modification operations, and Managed Node Group creation were also impacted. For EKS Auto Mode, impact was limited to operations requiring new capacity or changes, including node provisioning and pod scheduling. Our engineers were automatically engaged and immediately began investigating the root cause. We identified the root cause as a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. At 3:26 AM PDT, we took mitigation actions by introducing throttling for the affected APIs and we saw some recovery which was communicated directly with a subset of customers via the 'Your Account view' of the AWS Health Dashboard. We took multiple additional mitigation paths, incrementally lifting these throttle limits, and by 6:54 AM PDT, the issue was fully mitigated. We recommend that customers retry any failed requests. The issue has been resolved and all AWS services are now operating normally.

1. 30 июня 2026 г. в 21:02 UTCresolved

   We are investigating increased launch errors and API errors in the EU-NORTH-1 Region. Existing instances are not affected by this issue.

2. 30 июня 2026 г. в 21:21 UTCresolved

   We can confirm increased error rates for the EC2 APIs, as well as errors launching new EC2 instances in the EU-NORTH-1 Region. Other AWS Services that launch new instances or call the EC2 APIs as part of their workflows may also be affected by this issue. During this time, customers may receive an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the issue. We are actively working on identifying the root cause. Existing instances are unaffected by this issue. We will provide an update by 3:15 PM, or sooner if we have additional information to share.

3. 30 июня 2026 г. в 21:29 UTCresolved

   We are seeing early signs of recovery and continue to work toward full recovery.

4. 30 июня 2026 г. в 21:53 UTCresolved

   Between 1:42 PM and 2:25 PM PDT we experienced increased error rates and latencies for EC2 APIs in the EU-NORTH-1 Region. This issue also affected new instance launches. Other AWS Services that launch new instances or call EC2 APIs as part of their workflows were also affected by this issue. Existing EC2 instances were unaffected by this issue. During this time, customers would have received an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the root cause. We identified the root cause as a planned configuration change. This change was reverted and we began observing recovery at 2:19 PM. By 2:25 PM, the issue was fully mitigated. We do not expect this issue to reoccur. Since the issue was mitigated at 2:25 PM, we have been processing a backlog for ELB workflows and expect this backlog to complete within the next 30 minutes. We recommend customers retry requests that failed during this time. The issue has been resolved and all services are operating normally.

1. 13 июня 2026 г. в 01:26 UTCresolved

   To support compliance with the US Government export control directive, Anthropic has asked us to revoke access to Claude Fable 5 and Claude Mythos 5 for all users in all regions. All other models, including Opus 4.8, are not affected and you can continue using them in full confidence. Please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a> for further details.

2. 15 июня 2026 г. в 18:13 UTCresolved

   Claude Fable 5 and Claude Mythos 5 models remain unavailable for all users in all regions. We are resolving this Health event. For further details please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a>.

1. 6 июня 2026 г. в 04:24 UTCresolved

   Between 5:50 PM and 7:15 PM PDT, we experienced connectivity issues that may have impacted Internet performance for some customers in the SA-EAST-1 Region. During this time, connectivity to instances and services within the Region was not affected. Our engineering team was automatically engaged at 5:51 PM PDT and immediately began investigating the issue. We identified the root cause and implemented a fix, which mitigated the issue at 7:15 PM PDT. The issue has been resolved and the service is operating normally.

1. 22 мая 2026 г. в 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 мая 2026 г. в 00:13 UTCresolved

   Between 4:00 PM and 4:46 PM, we experienced increased error rates for the Route53 APIs. This issue did not impact resolution of existing DNS records. Engineers were automatically engaged and immediately began investigating the issue. During this time, customers may have received 500s for Route53 APIs and the Route53 Management Console. We have identified the root cause and have mitigated this issue. Other AWS Services that call the Route53 APIs in their workflows may also have been impacted during this time. We recommend retrying any failed operations or stuck workflows. We do not expect this issue to reoccur. The issue has been resolved and the service is operating normally.

1. 8 мая 2026 г. в 00:25 UTCresolved

   We are investigating instance impairments in a single Availability Zone (use1-az4) in the US-EAST-1 Region. Other Availability Zones are not affected by the event and we are working to resolve the issue.

2. 8 мая 2026 г. в 00:53 UTCresolved

   We continue to investigate instance impairments to a single Availability Zone (use1-az4) in the US-EAST-1 Region. We have experienced an increase in temperatures within a single data center, which in some cases has caused impairments for instances in the Availability Zone. EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We will continue to provide updates as recovery continues.

3. 8 мая 2026 г. в 01:47 UTCresolved

   We continue to work towards mitigating the increased temperatures to its normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We have weighed away traffic for most services at this time. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region at this time, as existing instances in other AZ's remain unaffected by this issue. Customers may experience longer than usual provisioning times. We will provide an update by 7:45 PM PDT, or sooner if we have additional information to share.

4. 8 мая 2026 г. в 03:06 UTCresolved

   We are actively working to restore temperatures to normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, though progress is slower than originally anticipated. Since our last update we have made incremental progress to restore cooling systems within the affected AZ, which will not be visible to external customers but are required for the restoration of affected services. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region, as existing instances in other AZs remain unaffected by this issue. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. We will provide an update by 10:00 PM PDT, or sooner if we have additional information to share.

5. 8 мая 2026 г. в 05:11 UTCresolved

   We are observing early signs of recovery. We continue to work towards restoring temperatures to normal levels and bring impacted racks back online in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. We have been able to get additional cooling system capacity online, which has allowed us to recover some affected racks and are actively working to recover additional racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows until full recovery is achieved. We will provide an update by 11:30 PM PDT, or sooner if we have additional information to share.

6. 8 мая 2026 г. в 06:38 UTCresolved

   We continue to make progress in resolving the impaired EC2 instances in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, and are working towards full recovery. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows. Customers will continue to see some of their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. We will provide an update by May 8, 1:30 AM PDT, or sooner if we have additional information to share.

7. 8 мая 2026 г. в 08:32 UTCresolved

   Mitigation efforts remain underway to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. These EC2 instances and EBS volumes were impacted due to a loss of power during the thermal event. The work to bring additional cooling system capacity online, which will enable us to recover the remaining affected infrastructure in a controlled and safe manner, is taking longer than we had initially anticipated. Some services, such as IoT Core, ELB, NAT Gateway, and Redshift, have seen significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 3:30 AM PDT or sooner if additional information becomes available.

8. 8 мая 2026 г. в 10:54 UTCresolved

   We continue to make progress towards resolving the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. At this time, we wanted to provide some more details on the issue. Beginning on May 7 at 4:20 PM PDT, we began experiencing an increase in instance impairments within the affected zone due to the loss of power during a thermal event. Engineers were automatically engaged within minutes and immediately began investigating multiple mitigations. By 9:12 PM PDT, we restored power to a subset of the affected infrastructure and observed some signs of recovery, which have remained stable. We continue working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone in a controlled and safe manner. Some AWS services, such as IoT Core, ELB, NAT Gateway, and Redshift, continue to see significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. Based on our current mitigation efforts, we expect full recovery to take several hours. We are prioritizing this issue and will provide another update by 6:30 AM PDT or sooner if additional information becomes available.

9. 8 мая 2026 г. в 13:51 UTCresolved

   We continue working to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region caused by a thermal event. During such an event, servers automatically shut down when the temperatures exceeded the operating thresholds in order to protect the hardware. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. In parallel, we are investigating increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. During this time, affected customers may see errors for resume and restart workflows, as well as failover operations and availability issues. Our engineers are actively working to resolve this issue. Full recovery is still expected to take several hours. We are prioritizing this issue and will provide another update by 9:00 AM PDT or sooner if additional information becomes available.

10. 8 мая 2026 г. в 15:58 UTCresolved

    We continue our efforts to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are making progress towards the restoration of the cooling system capacity that is required to recover the affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until the affected racks are recovered. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. As part of our parallel investigation, we have identified the root cause of the increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. This has been confirmed to be related to impact from an upstream dependency. Affected customers may continue to see errors for resume and restart workflows, failover operations, and impact to general availability. We are actively working to resolve the issue. Our timeline for full recovery is still expected to take several hours and will be incremental as we bring racks online in phases. We will provide an additional update by 12:30 PM or sooner if we have new information to provide.

11. 8 мая 2026 г. в 16:30 UTCresolved

    We have observed complete recovery of increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. We were able to resolve the impact independently of the ongoing efforts to recover the affected hardware in the use1-az4 Availability Zone. The issue affecting Redshift has been resolved and the service is operating normally. We will provide an additional update regarding the efforts towards hardware restoration by 12:30 PM or sooner.

12. 8 мая 2026 г. в 18:12 UTCresolved

    We are experiencing an increase in timeouts to Amazon Managed Streaming for Apache Kafka partitions on a subset of clusters as a result of the ongoing issue in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are working in parallel to determine a path towards mitigation for affected clusters. We will provide an additional update by 12:30 PM or sooner.

13. 8 мая 2026 г. в 19:29 UTCresolved

    We continue to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region though efforts are slower than we had previously anticipated. We are taking measured steps to ensure that cooling capacity is brought online in a safe and controlled manner. As a result, EBS Volumes and EC2 instances affected by the issue will continue to experience impairments. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resourced by launching new replacement resources. Full recovery is still expected to take several hours. We will provide an additional update by 4:00 PM or sooner if we have new information to provide.

14. 8 мая 2026 г. в 23:00 UTCresolved

    We have begun to see improvements in the overall number of affected EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. The steps taken to supply additional cooling capacity have been showing steady signs of progress. Some EBS Volumes and EC2 instances affected by the issue will continue to experience impairments while we continue to drive these efforts. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources. In parallel, we have seen some improvements in Amazon Managed Streaming for Apache Kafka as a result of the parallel mitigation efforts being performed. We are still experiencing timeouts to partitions but are seeing continued progress. We do anticipate that recovery will still take several hours. We will provide an additional update by 7:30 PM or sooner if we have new information to provide.

15. 9 мая 2026 г. в 03:04 UTCresolved

    Starting May 7 4:20 PM PDT, we experienced increased impaired EC2 instances and degraded EBS volumes in a single facility (data center) within a single Availability Zone (use1-az4) in the US-EAST-1 Region. The issue was caused by a thermal event resulting in a loss of power. As part of our recovery effort, we shifted traffic away from the impacted Availability Zone for most services at May 7 5:06 PM. AWS services, like Elastic Load Balancing, Elastic Kubernetes Service, ElastiCache, Redshift, OpenSearch, Managed Streaming for Apache Kafka among others, that depend on the affected EC2 instances and EBS volumes in this Availability Zone, also experienced elevated error rates and latencies for some workflows and/or configurations. Our main effort during the event mitigation strategy was to bring back our cooling systems capacity. By May 8 1:50 PM, we were able to stabilize cooling system capacity to pre-event levels, which helped us to restore the majority of the impaired EC2 instances and EBS volumes. A small number of instances and EBS volumes remain impaired and we continue to work to recover all affected remaining resources. We will communicate with customers who are still impacted via the Your Account view of the AWS Health Dashboard. Customers that require further assistance with this event may contact AWS Support through the AWS Management Console or the AWS Support Center.

1. 27 апреля 2026 г. в 11:27 UTCresolved

   We are investigating instance connectivity issues in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region.

2. 27 апреля 2026 г. в 12:05 UTCresolved

   Between 3:58 AM and 4:40 AM PDT, we experienced increased error rates and increased launch failures for EC2 instances in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region. During this time, customers attempting to launch new EC2 instances in the affected Availability Zone would have experienced launch failures. Additionally, a subset of existing EC2 instances and EBS volumes in this Availability Zone were impacted and became unreachable. We have identified the root cause to be a loss of power to infrastructure within the affected Availability Zone. Engineers were engaged at 4:02 AM and immediately began working to restore power and assess the scope of impact. By 4:20 AM, power was successfully restored to the affected infrastructure. We then focused our efforts on recovering impacted EC2 instances and EBS volumes. By 4:40 AM, all impacted EC2 instances and EBS volumes had been fully recovered and were operating normally. No additional action is required for EC2 instances and EBS volumes that were impacted during the power loss event, as these have been fully recovered. While EC2 and EBS have recovered, some AWS services may take additional time to fully recover as they process backlogs and complete their own recovery procedures. The issue has been resolved and the service is operating normally.

1. 7 марта 2026 г. в 19:53 UTCresolved

   We are investigating increased error rates in the EU-CENTRAL-2 Region.

2. 7 марта 2026 г. в 20:17 UTCresolved

   We can confirm substantial error rates for PUT and GET requests to Amazon S3 in the EU-CENTRAL-2 Region. Engineers engaged immediately based on automated alarming. We have triangulated the issue to a subsystem responsible for assembling objects from bytes in storage. We have begun implementing mitigations, and are observing some improvement in error rates. We continue to work to identify the root cause, and are working on multiple parallel paths to fully mitigate the issue. Other AWS Services (such as EC2 launches) that rely on S3 are also affected by this issue. Existing EC2 instances are unaffected by this issue. We will provide another update by 12:45 PM PST, or sooner if we have additional information to share.

3. 7 марта 2026 г. в 20:28 UTCresolved

   We are seeing early signs of recovery and continue to monitor and work toward full recovery.

4. 7 марта 2026 г. в 21:04 UTCresolved

   Between 11:27 AM and 12:20 PM PST we experienced substantial error rates for S3 PUT/GET requests in EU-CENTRAL-2 Region. Engineers were engaged immediately based on automated alarming. We identified the root cause as an issue with a subsystem responsible for assembling objects bytes in storage. At 12:04 PM PST, we implemented mitigations and began observing early signs of recovery for S3. Error rates continued to improve, and other AWS Services continued to recover until 12:50 PM PST when we observed full recovery. We continue to work toward backfilling Cloudwatch logs, and expect that to continue over the next couple hours. We recommend customers retry any failed requests. The issue has been resolved and all services are operating normally.

1. 2 марта 2026 г. в 05:56 UTCresolved

   We are investigating increased API error rates in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region.

2. 2 марта 2026 г. в 07:09 UTCresolved

   We are investigating connectivity and power issues affecting APIs and instances in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region due to a localized power issue. Existing instances in this zone will also be affected. Other AWS Services may also be experiencing increased errors and latencies for their workflows, and we are working to route requests away from this affected Availability Zone. We recommend customers make use of other Availability Zones at this time. During this time, we are also experiencing delays in propagating DNS changes for Route53 to pops (Points of Presence) in ME-SOUTH-1.  Targeting new launches using RunInstances in the remaining AZs should succeed. Existing instances in the other AZs are not affected.

3. 2 марта 2026 г. в 09:03 UTCresolved

   We continue to work on a localized power issue affecting a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. In the impacted Availability Zone, EC2 Instances, DB Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the ME-SOUTH-1 Region, as existing instances in other AZs remain unaffected by this issue. We are actively working to restore power and connectivity, at which time we will begin recovering affected resources. Currently, we expect recovery to take many hours. We will provide an update by 2:30 AM PST, or sooner if we have additional information to share.

4. 2 марта 2026 г. в 10:41 UTCresolved

   We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. At this time, some AWS services have shifted traffic away from the affected Availability Zone and are seeing recovery for their affected operations and workflows. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline. Power has not yet been restored to the affected Availability Zone. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate Region. In parallel, we are actively working on reducing the error rates and latencies that some customers are experiencing with EC2 APIs. For now, we recommend continuing to retry any failed API requests. We will provide an update by 6:00 AM PST on March 2, or sooner if we have additional information to share.

5. 2 марта 2026 г. в 14:23 UTCresolved

   We continue to work toward restoring power in the impacted Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. Meanwhile, EC2 instance and networking APIs have been restored for the other Availability Zones. Additionally, we have made improvements to the availability of RDS multi-AZ databases while operating with the impaired Availability Zone. These improvements will help customers create database exports to preserve data, and we recommend customers with databases in the affected Availability Zone consider creating exports as a precautionary measure. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline, as power has not yet been restored. We are expecting recovery to take at least a day, as it requires repair of facilities, cooling and power systems, coordination with local authorities, and careful assessment to ensure the safety of our operators. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. We will provide an update by 11:00 AM PST on March 2, or sooner if we have additional information to share.

6. 2 марта 2026 г. в 18:52 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We currently expect our recovery efforts to take at least a day. Our current guidance regarding immediate recovery remains unchanged from our previous update. Customers are able to disassociate Elastic IP addresses from resources in the affected Availability Zone and associate those with resources in the unaffected Availability Zones. This can be done by specifying --allow-reassociation when attempting to associate the Elastic IP to the new resource. We will provide you with further updates by 2:00 PM PST or sooner if new information becomes available.

7. 2 марта 2026 г. в 22:29 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. We continue to advise customers to launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. At this time we recommend that customers that are capable of backing up data outside of the region consider doing so. You can view the current status of affected AWS services below. We will provide you with another update by 7:00 PM PST, or sooner if we have additional information to share.

8. 3 марта 2026 г. в 00:22 UTCresolved

   We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1) and the AWS Middle East (Bahrain) Region (ME-SOUTH-1). Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure as a result of drone strikes. In the UAE, two of our facilities were directly struck, while in Bahrain, a drone strike in close proximity to one of our facilities caused physical impacts to our infrastructure. These strikes have caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage. We are working closely with local authorities and prioritizing the safety of our personnel throughout our recovery efforts. In the ME-CENTRAL-1 (UAE) Region, two of our three Availability Zones (mec1-az2 and mec1-az3) remain significantly impaired. The third Availability Zone (mec1-az1) continues to operate normally, though some services have experienced indirect impact due to dependencies on the affected zones. In the ME-SOUTH-1 (Bahrain) Region, one facility has been impacted. Across both regions, customers are experiencing elevated error rates and degraded availability for services including Amazon EC2, Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon Kinesis, Amazon CloudWatch, Amazon RDS, and the AWS Management Console and CLI. We are working to restore full service availability as quickly as possible, though we expect recovery to be prolonged given the nature of the physical damage involved. In parallel with efforts to restore the physical infrastructure at the affected sites, we are pursuing multiple software-based recovery paths that do not depend on the underlying facilities being fully brought back online. For Amazon S3 and Amazon DynamoDB, we are actively working to restore data access and service availability through software mitigations, including deploying updates to enable S3 to operate within the current infrastructure constraints and remediating impaired DynamoDB tables to restore read and write availability for dependent services. Our focus on restoring these foundational services is deliberate, as recovery of Amazon S3 and Amazon DynamoDB will in turn enable a broad range of dependent AWS services to recover. For other affected service APIs, we are deploying targeted software updates to reduce error rates and restore functionality where possible, independent of the physical recovery timeline. We are also working to restore access to the AWS Management Console and CLI through network-level changes that route traffic away from the affected infrastructure. While these software-based mitigations can address many of the service-level impacts, some recovery actions are constrained by the physical state of the affected facilities — meaning that full restoration of certain services will require the underlying infrastructure to be repaired and brought back online. Across all services, our teams are working in parallel on both the physical restoration of the affected facilities and these software-based mitigations, with the goal of restoring as much customer access as possible as quickly as possible, even ahead of full infrastructure recovery. In addition, we are prioritizing the restoration of services and tools that enable customers to back up and migrate their data and applications out of the affected regions. Finally, even as we work to restore these facilities, the ongoing conflict in the region means that the broader operating environment in the Middle East remains unpredictable. We recommend that customers with workloads running in the Middle East consider taking action now to backup data and potentially migrate your workloads to alternate AWS Regions. We recommend customers exercise their disaster recovery plans, recover from remote backups stored in other regions, and update their applications to direct traffic away from the affected regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 9:00 PM PST on March 2, 2026, or sooner if new information becomes available.

9. 3 марта 2026 г. в 06:27 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. AWS infrastructure is designed to be highly resilient, but given the uncertainty of the current situation, we encourage our customers to replicate Amazon S3 and critical data from the ME-SOUTH-1 Region to another AWS Region. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will provide another update by March 3 at 3:00 AM PST, or sooner if new information becomes available. For more information on Cross-Region Replication, refer [1]. For more information on S3 Batch Replication, see [2]. For a simple script to quickly set up and start S3 Replication, see [3]. If you have questions or concerns, please contact AWS Support [4]. [1] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html</a> [2] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html</a> [3] <a href="https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py">https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py</a> [4] <a href="https://aws.amazon.com/support">https://aws.amazon.com/support</a>

10. 3 марта 2026 г. в 11:10 UTCresolved

    We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. The overall state of the region remains largely unchanged from our previous update. At this time, we have no updated guidance on expected timelines for fully restoring power and connectivity. We are taking all necessary steps to support the recovery process. While progress is being made, significant work remains before full restoration is complete. Given the ongoing uncertainty, we encourage customers to replicate their Amazon S3 data and other critical data from the ME-SOUTH-1 Region to another AWS Region, using the guidance provided in our previous update. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 6:00 AM PST on March 3, or sooner if new information becomes available.

11. 3 марта 2026 г. в 14:02 UTCresolved

    Recovery efforts in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region are ongoing, with the situation remaining consistent with our last update. We have no change to expected timelines for fully restoring power and connectivity. While progress is being made, significant work remains before full restoration is complete. We continue to recommend customers launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. Given the extended nature of this event, we continue to encourage customers to replicate Amazon S3 data and other critical workloads from ME-SOUTH-1 to another AWS Region using the guidance shared previously. We will provide our next update by 12:00 PM PST on March 3, or sooner if conditions change.

12. 3 марта 2026 г. в 16:40 UTCresolved

    We are providing an update on the ongoing service disruptions affecting the AWS Middle East (Bahrain) Region (ME-SOUTH-1). We continue to make progress on recovery efforts across multiple workstreams. With the immediate phase of this event now better understood, we are moving to a more targeted communication model. Going forward, updates will be delivered directly to affected customers through the AWS Personal Health Dashboard. Customers who require assistance with this event are encouraged to contact AWS Support through the AWS Management Console or the AWS Support Center. We continue to strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions. Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements.

13. 30 апреля 2026 г. в 07:07 UTCinvestigating

    We are providing an update on the ongoing service disruption. The Middle East (Bahrain) Region (ME-SOUTH-1) has suffered damage due to the conflict in the Middle East and is currently unavailable. Customers should recover their resources in other Regions from remote backups. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.

14. 15 сентября 2026 г. в 10:22 UTCinvestigating

    We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.