قطعی سراسری AWS، نگرانی‌های ریسک تمرکز در SaaS را برانگیخت

ماجرا چه بود؟

در ۱۴ فوریه ۲۰۲۶، AWS تجربه‌ی یکی از بزرگ‌ترین قطعی‌های خدمات خود طی پنج سال اخیر را داشت. این قطعی از منطقه‌ی us-east-1 (شمال ویرجینیا) شروع شد و طی ۲۰ دقیقه به همه‌ی سرویس‌های global شامل IAM، CloudFront، Route 53، و Lambda سرایت کرد.

مدت کل قطعی: حدود ۴ ساعت برای core services، تا ۹ ساعت برای recovery کامل سرویس‌های وابسته. در طی این مدت، صدها SaaS مهم زمین‌گیر شدند — از Slack و Zoom گرفته تا GitHub، Dropbox، Coinbase، و خدمات استریم Netflix.

جزئیات فنی

طبق post-mortem رسمی AWS، علت اصلی یک تغییر پیکربندی در DynamoDB در us-east-1 بود که به یک حلقه‌ی feedback در سیستم routing داخلی منجر شد. این حلقه ظرفیت کنترل پلین (control plane) را پر کرد و منجر به throttling گسترده‌ی API ها شد.

سرویس‌هایی که از endpoint های global IAM یا کلیدهای KMS وابسته به us-east-1 استفاده می‌کردند، حتی اگر در region دیگر اجرا می‌شدند، دچار خطا شدند. این موضوع نشان داد که «multi-region» بسیاری از سازمان‌ها در عمل، تنها multi-region در data plane است، نه control plane.

تأثیر و واکنش

تخمین زیان مستقیم برای کسب‌وکارهای متأثر: حدود ۱.۲ میلیارد دلار. شرکت‌های فنی متعدد در روزهای بعد، blog post هایی منتشر کردند که بازنگری معماری آن‌ها در مواجهه با وابستگی به us-east-1 را شرح می‌داد.

این حادثه بحث قدیمی درباره‌ی «cloud concentration risk» را دوباره فعال کرد: تمرکز بیش از حد بازار ابر در دست سه ارائه‌دهنده‌ی اصلی و حتی در درون AWS، تمرکز در یک region.

توصیه‌های امنیتی

• inventory وابستگی‌های سازمان به us-east-1 را تهیه کنید — حتی اگر workload در region دیگر اجرا می‌شود، ممکن است IAM یا KMS وابسته باشد.
• multi-region failover برای سرویس‌های بحرانی را به‌جای multi-AZ تنها، ارزیابی کنید.
• چاپ کلیدهای KMS را به region اصلی workload محدود کنید.
• runbook ای آماده داشته باشید برای زمانی که AWS console در دسترس نیست (API هم throttle می‌شود).
• در طولانی‌مدت، multi-cloud یا hybrid را برای سرویس‌های mission-critical در نظر بگیرید.

منابع

• TechCrunch