Trong bức tranh hạ tầng số toàn cầu hiện nay, ba trụ cột của điện toán đám mây mà theo quan điểm của tôi là Amazon Web Services (AWS), Microsoft Azure và Google Cloud Platform (GCP) gần như nắm giữ nền tảng vận hành của thế giới Internet hiện đại. Từ các dịch vụ phát trực tuyến, thương mại điện tử, ngân hàng số cho đến trí tuệ nhân tạo, phần lớn đều đứng trên chiếc kiềng ba chân này.
Điều gì vừa xảy ra tại điểm nóng US‑EAST‑1?
Đây là vùng hạ tầng trọng yếu nhất của AWS, nơi tập trung khối lượng dịch vụ nền tảng khổng lồ. Chỉ một trục trặc nhỏ cũng đủ kéo theo hàng loạt dịch vụ cốt lõi của AWS như EC2 (máy chủ ảo) và DynamoDB (cơ sở dữ liệu NoSQL) bị tê liệt, dẫn đến hiệu ứng domino trên toàn hệ sinh thái.
Hậu quả là hàng triệu người dùng không thể truy cập vào các ứng dụng phổ biến gồm: Snapchat, Fortnite, Duolingo, Canva, Wordle, Slack, monday.com, Zoom cùng nhiều ngân hàng và dịch vụ công như Lloyds, Barclays, Bank of Scotland, HMRC, Vodafone…
Theo thông báo trên trang trạng thái dịch vụ của AWS, hệ thống đang gặp sự cố về DNS ảnh hưởng đến DynamoDB – dịch vụ cơ sở dữ liệu đóng vai trò nền tảng cho nhiều ứng dụng khác trong hệ sinh thái AWS.
DNS (Domain Name System) là hệ thống chịu trách nhiệm chuyển đổi tên miền thành địa chỉ IP, cho phép trình duyệt và các ứng dụng kết nối đến đúng máy chủ để tải và xử lý dữ liệu. Khi lớp phân giải DNS này gặp trục trặc, các ứng dụng không thể xác định vị trí của dịch vụ DynamoDB dẫn đến lỗi kết nối, gián đoạn truy xuất dữ liệu và từ đó kích hoạt hiệu ứng lan truyền sang hàng loạt dịch vụ phụ thuộc khác trong chuỗi hạ tầng AWS.
Giải phẫu nguyên nhân kỹ thuật
Dưới đây là tôi tổng hợp lại theo mô hình nguyên nhân – hệ quả, ưu tiên các khả năng có bằng chứng gián tiếp rõ ràng.
Lưu ý: AWS hiện chưa công bố báo cáo điều tra chi tiết ngoài trạng thái thông báo của hãng, vì vậy các phân tích này dựa trên dấu hiệu kỹ thuật quan sát được và các tiền lệ đã từng xảy ra. Nếu có bản điều tra rõ ràng thì mọi nguyên nhân dưới đây là giả thuyết mà tôi suy đoán.
1. Lỗi tại tầng điều khiển mạng hoặc DNS (Control Plane/Route 53)
Tất nhiên rồi, giả thuyết có khả năng cao nhất là sự cố trong quá trình phân giải tên miền (DNS) đến các điểm cuối của DynamoDB.
Khi DNS gặp trục trặc, các dịch vụ phụ thuộc không thể tìm “địa chỉ” chính xác để truy cập dữ liệu khiến hàng loạt ứng dụng gặp lỗi.
Trong kiến trúc vi dịch vụ (microservices), chỉ một lỗi ở Route 53 hoặc lớp điều phối mạng nội bộ (network control plane) cũng có thể lan nhanh sang các thành phần như Load Balancer (ELB) hay API Gateway dẫn tới tỷ lệ lỗi 5xx tăng đột biến, người dùng không đăng nhập được và các tác vụ khởi tạo tài nguyên (EC2, ECS) bị nghẽn.
→ Xác suất ước tính: 70 – 80%
2. Lỗi trong quá trình triển khai cấu hình tự động
AWS vận hành hạ tầng theo mô hình “infrastructure as code” (IaC), nghĩa là các thay đổi về mạng, bảo mật hay điều phối đều được cập nhật tự động qua các pipeline.
Nếu một bản cấu hình sai (ví dụ: quy tắc định tuyến VPC, IAM policy hay cài đặt mạng) được triển khai rộng, nó có thể gây “lệch pha” giữa tầng điều khiển và tầng dữ liệu khiến dịch vụ đứt quãng hàng loạt.
→ Xác suất ước tính: 15 – 20%
3. Bất ổn trong quá trình nhân bản dữ liệu
Dù không phải nguyên nhân gốc, sự bất nhất tạm thời giữa các bản sao dữ liệu có thể làm hậu quả thêm nghiêm trọng. Khi truy cập đến các endpoint không ổn định, hệ thống sinh ra lỗi time-out, mất phiên đăng nhập hoặc ngắt luồng xác thực khiến người dùng thấy ứng dụng “đơ” ngay từ bước khởi động.
→ Xác suất ước tính: 5 – 10%
4. Ảnh hưởng gián tiếp từ lưu lượng bất thường hoặc đối tác hạ tầng
Mặc dù AWS và các cơ quan an ninh mạng đều phủ nhận khả năng tấn công mạng quy mô lớn, không thể loại trừ hoàn toàn khả năng một nguồn lưu lượng bất thường (CDN, API hoặc nhà cung cấp DNS thứ ba) gây hiệu ứng dồn tải, kích hoạt lỗi sẵn có trong hệ thống.
Kịch bản này hiếm gặp hơn nhưng vẫn có thể góp phần khuếch đại sự cố, đặc biệt khi kết hợp với lỗi DNS ban đầu.
→ Xác suất ước tính: <5%
Thiệt hại không thể đo đạc bằng con số
Với vai trò là nhà cung cấp hạ tầng đám mây cho hơn 90% các công ty Fortune 100, AWS được xem như xương sống của công nghệ doanh nghiệp toàn cầu. Vì thế, thiệt hại từ sự cố lần này vượt xa mức khó chịu tạm thời của người dùng, nó phơi bày mức độ phụ thuộc khổng lồ của thế giới số vào một nền tảng duy nhất kèm cái giá có thể lên đến hàng tỷ USD trên toàn cầu, dù không ai có thể xác định chính xác con số đó.
Theo các ước tính trong ngành, những gián đoạn Internet quy mô lớn gây ra tổn thất hàng tỷ đô la mỗi năm, bao gồm mất doanh thu, sụt giảm năng suất và thiệt hại uy tín dài hạn. Một khảo sát năm 2024 dẫn trên trang DataCentre Magazine cho thấy:
- 76% doanh nghiệp toàn cầu đang vận hành ứng dụng trên nền tảng AWS
- 48% lập trình viên tích hợp AWS vào quy trình phát triển phần mềm
Trong bối cảnh đó, câu hỏi không còn là “Liệu AWS có thể sập hay không?” mà là “Mức độ tàn phá sẽ lớn đến đâu khi điều đó xảy ra?”.
Từ lăng kính an ninh mạng của tôi, sự cố AWS ngày 20/10/2025 là minh họa cho khái niệm Single Point of Failure (SPOF) – một điểm lỗi có thể kéo sập cả hệ thống.
Trong trường hợp này, DNS gặp trục trặc tại một nút hạ tầng trọng yếu, khiến hàng loạt dịch vụ tê liệt dù dữ liệu thực tế vẫn còn nguyên vẹn. Việc tập trung hạ tầng vào các “siêu vùng” như US-EAST-1 càng khuếch đại rủi ro, mức độ liên thông dày đặc của điện toán đám mây khiến phạm vi ảnh hưởng rộng và sâu hơn nhiều.
Sự cố này cũng không phải cá biệt. Trong nhiều năm, các đợt gián đoạn lớn của AWS đều xoay quanh vùng US-EAST-1 và chỉ mới năm 2024, thế giới từng sốc với sự vụ CrowdStrike Incident ngày 19/7/2024. Cả hai vụ việc đều cho thấy chuỗi cung ứng số toàn cầu đang phụ thuộc nguy hiểm vào số ít nhà cung cấp lõi, kéo theo rủi ro lan truyền mà nhiều tổ chức vẫn chưa lường trước được.
Gợi ý của tôi và biết đâu đấy được thế hệ chuyên gia trẻ “giải phẫu” tường tận hơn nữa, rằng khi chúng ta đang phụ thuộc sâu vào tam trụ đám mây như AWS, Microsoft, Google, trách nhiệm của kỹ sư công nghệ, chuyên gia vận hành và người lãnh đạo nên chủ động hướng đến phân tán rủi ro, thay vì đợi đến sự cố kế tiếp để giật mình nhìn lại.
