На 20 октомври 2025 г. стотици уебсайтове, приложения и социални мрежи по света станаха недостъпни заради глобален срив на Amazon Web Services (AWS) – най-голямата платформа за облачна инфраструктура в света. В САЩ потребителите не можеха да достъпят Amazon, Alexa, Prime Video, Crunchyroll, Canva, Perplexity, Duolingo, както и социални мрежи като Snapchat и Goodreads, и популярни игри като Fortnite, Roblox и Clash Royale. В Европа някои услуги също изпитаха проблеми с достъпа.

„Причината е, че много от невидимите компоненти на интернет работят върху AWS,“ обяснява Херве Ламбер, глобален мениджър на потребителските операции в Panda Security. „Когато тази платформа се срине, не спира просто един сървър – падат цели услуги, включително сайтове, приложения и социални мрежи, които разчитат на нея.“

Как AWS-сривът влияе върху приложенията

Ламбер подчертава, че при срив на AWS „някои приложения не могат да обслужват страници, API-та или фийдове, защото изчислителният слой – EC2, EKS или Lambda – спира на нодовете или контролния план. Ако няма къде да се чете или съхранява информацията, сайтът не се зарежда; логините спират, защото системите за удостоверяване като Cognito, STS/AssumeRole или AWS SSO не издават токени; DNS не разрешава домейни, или CDN не може да достъпи данни от източника. Дори приложения, които не са хостнати на AWS, страдат, ако доставчиците им са.“

Освен това, при срив компаниите могат буквално да „оглупеят“, защото инструментите им за наблюдение и защита също се хостват в същата платформа. „CloudWatch, CloudTrail, GuardDuty, SIEM системи, табла, уведомления SNS/SES или SSO – ако са в същия регион, също спират, оставяйки сайтовете без метрики, логове или валидни идентификационни данни,“ предупреждава експертът.

Липсата на план Б увеличава рисковете

Много компании концентрират всичко в една област и един акаунт, включително резервни копия и ключове за криптиране (KMS). „Без multi-region failover, недостъпността е тотална. Под напрежение някои екипи отварят групи за сигурност, изключват WAF или разширяват IAM права, за да поддържат системите – често нарушавайки допълнително сигурността,“ отбелязва Ламбер.

Причината за липсата на планове за аварийно възстановяване е проста: „Компаниите не са мотивирани – изглежда скъпо и технически сложно. Много сайтове и приложения нямат план Б, защото приоритетите им са изкривени: бизнесът цени скоростта, а не устойчивостта; има фалшиво усещане за сигурност – хората смятат, че това няма да се случи на тях. Multi-region или multi-account конфигурации, репликация на данни, резервни идентичности, runbooks и учения звучат като удвоени разходи.“

Сигурността като част от дизайна

Ламбер подчертава, че интегрирането на киберсигурността още от ранните етапи на разработка е ключово. Реактивното прилагане на пачове след инциденти е по-малко ефективно и по-скъпо в дългосрочен план.

За да се прекъсне цикълът на уязвимост, експертът препоръчва:

• интегриране на устойчивостта в KPI-тата на екипите;

• разделяне на акаунти и региони;

• автоматизация на бекъпите и защитните механизми;

• редовни учения за failover.

„Това винаги е по-евтино, отколкото да обяснявате на хиляди потребители защо услугата ви е изчезнала,“ заключава Ламбер.