Tweet
Phân tích sự cố mất điện diện rộng của AWS và bài học về tính sẵn sàng cao
Chào mọi người,
Trong quá trình xây dựng các network lab project và ôn tập kiến thức thiết kế hệ thống an toàn cho chứng chỉ ISC2 CC, có một nguyên tắc luôn được nhắc đi nhắc lại là đảm bảo tính sẵn sàng cao và khả năng phục hồi sau thảm họa. Sự cố sập nguồn diện rộng vừa qua của AWS tại khu vực Trung Đông chính là một minh chứng thực tế và đắt giá nhất cho nguyên tắc này.
Dưới đây là tổng hợp chi tiết về nguyên nhân, diễn biến và bài học rút ra từ sự cố để chúng ta cùng thảo luận:
Nghiêm trọng hơn, sự cố mất điện đã gây lỗi dây chuyền đến các API mạng của hạ tầng EC2. Khách hàng liên tục gặp lỗi khi gọi các hàm quản lý mạng quan trọng như AllocateAddress, AssociateAddress, DescribeRouteTable và DescribeNetworkInterfaces. Khó khăn lớn nhất là khách hàng không thể gán lại các địa chỉ Elastic IP từ những tài nguyên đang bị kẹt trong trung tâm dữ liệu bị cháy sang các tài nguyên mới, làm gián đoạn nghiêm trọng quá trình phục hồi.
Từ góc độ thiết kế mạng và an toàn thông tin, mọi người có nghĩ rằng chúng ta nên luôn mặc định thiết kế Multi-AZ cho mọi dự án, hay chỉ áp dụng cho những hệ thống có mức độ rủi ro cao để cân đối chi phí hạ tầng? Hãy cùng chia sẻ quan điểm và kinh nghiệm vận hành nhé!
Trong quá trình xây dựng các network lab project và ôn tập kiến thức thiết kế hệ thống an toàn cho chứng chỉ ISC2 CC, có một nguyên tắc luôn được nhắc đi nhắc lại là đảm bảo tính sẵn sàng cao và khả năng phục hồi sau thảm họa. Sự cố sập nguồn diện rộng vừa qua của AWS tại khu vực Trung Đông chính là một minh chứng thực tế và đắt giá nhất cho nguyên tắc này.
Dưới đây là tổng hợp chi tiết về nguyên nhân, diễn biến và bài học rút ra từ sự cố để chúng ta cùng thảo luận:
- Nguyên nhân vật lý không ngờ tới Vào ngày 1 tháng 3 năm 2026, khu vực AWS me-central-1 đã gặp phải một sự cố vật lý cực kỳ hy hữu. Một vật thể bên ngoài đã va chạm mạnh vào trung tâm dữ liệu, gây ra tia lửa điện và dẫn đến hỏa hoạn. Để đảm bảo an toàn cho công tác chữa cháy, lực lượng cứu hỏa đã yêu cầu ngắt toàn bộ nguồn điện, kể cả hệ thống máy phát điện dự phòng. Hậu quả là toàn bộ Availability Zone mec1-az2 bị sập hoàn toàn.
- Tác động dây chuyền đến hạ tầng Cloud Việc mất điện đột ngột đã làm tê liệt hàng loạt dịch vụ cốt lõi tại vùng bị ảnh hưởng. Các máy chủ ảo EC2 Instances, các cụm lưu trữ Amazon Elastic Block Store cùng với hệ thống cơ sở dữ liệu Amazon Relational Database Service đều ngừng hoạt động, khiến dữ liệu không thể truy cập.
Nghiêm trọng hơn, sự cố mất điện đã gây lỗi dây chuyền đến các API mạng của hạ tầng EC2. Khách hàng liên tục gặp lỗi khi gọi các hàm quản lý mạng quan trọng như AllocateAddress, AssociateAddress, DescribeRouteTable và DescribeNetworkInterfaces. Khó khăn lớn nhất là khách hàng không thể gán lại các địa chỉ Elastic IP từ những tài nguyên đang bị kẹt trong trung tâm dữ liệu bị cháy sang các tài nguyên mới, làm gián đoạn nghiêm trọng quá trình phục hồi.
- Nỗ lực khắc phục của AWS Ngay khi sự cố xảy ra, AWS đã tiến hành cân bằng tải traffic, chuyển hướng các yêu cầu sang những Availability Zone đang hoạt động bình thường trong cùng khu vực. Đến chiều tối cùng ngày, đội ngũ kỹ thuật của AWS đã triển khai một bản cập nhật cấu hình quan trọng, cho phép người dùng buộc hủy liên kết các địa chỉ Elastic IP khỏi các tài nguyên đang bị sập. Nhờ đó, các tổ chức mới có thể gán lại IP cho máy chủ mới và khôi phục dịch vụ. Mặc dù vậy, việc cấp lại nguồn điện vật lý cho trung tâm dữ liệu vẫn phải chờ sự cho phép từ chính quyền địa phương để đảm bảo an toàn.
- Bài học sống còn về kiến trúc đa vùng Sự cố này một lần nữa khẳng định tầm quan trọng của thiết kế kiến trúc phân tán Multi-AZ. Theo báo cáo từ AWS, những khách hàng triển khai ứng dụng dự phòng chạy trên nhiều Availability Zone gần như không bị ảnh hưởng bởi đợt gián đoạn này. Đối với những hệ thống bị ảnh hưởng trực tiếp, cách nhanh nhất để phục hồi là triển khai tài nguyên thay thế ở các vùng khỏe mạnh và khôi phục dữ liệu từ các bản sao lưu hoặc EBS snapshots gần nhất.
Từ góc độ thiết kế mạng và an toàn thông tin, mọi người có nghĩ rằng chúng ta nên luôn mặc định thiết kế Multi-AZ cho mọi dự án, hay chỉ áp dụng cho những hệ thống có mức độ rủi ro cao để cân đối chi phí hạ tầng? Hãy cùng chia sẻ quan điểm và kinh nghiệm vận hành nhé!