Đêm 19 rạng sáng 20/10/2025 giờ bờ Tây nước Mỹ, vùng us-east-1 của Amazon Web Services rơi vào gián đoạn kéo dài. Vùng này lâu đời nhất và đông khách nhất của hãng, đặt tại Bắc Virginia. Bản tường trình AWS công bố ba ngày sau đó chỉ ra điểm khởi phát ở một chỗ ít ai ngờ. Hệ thống tự động cập nhật bản ghi tên miền cho DynamoDB.
Hai tiến trình giẫm chân nhau
Hệ thống ấy chạy bằng hai phần tách rời. Một phần theo dõi sức khoẻ các bộ cân bằng tải rồi dựng ra bản kế hoạch DNS; phần kia đem kế hoạch đó ghi vào Route 53. Tài liệu của AWS gọi chúng là DNS Planner và DNS Enactor.
Đêm hôm đó một tiến trình ghi bị chậm bất thường. Trong lúc nó còn treo, bên dựng kế hoạch vẫn đẻ ra bản mới. Một tiến trình ghi thứ hai áp xong bản mới rồi chạy tác vụ dọn dẹp. Bản cũ về đích sau cùng và đè lên trên. Tác vụ dọn dẹp nhìn thấy một kế hoạch quá hạn nên xoá đi, xoá sạch mọi địa chỉ IP của điểm cuối vùng.
Còn lại một bản ghi rỗng. Ứng dụng nào hỏi tên miền DynamoDB tại us-east-1 cũng nhận về chỗ trống. Tệ hơn, trạng thái bất nhất ấy chặn luôn cơ chế cập nhật tự động. Máy không tự bò dậy được, kỹ sư phải vào tay chữa từng bản ghi.
Mười lăm giờ, ba lớp hỏng chồng lên nhau
Theo mốc thời gian AWS đưa ra, tỉ lệ lỗi gọi API của DynamoDB bắt đầu tăng lúc 23 giờ 48 phút ngày 19/10 giờ Thái Bình Dương. Gần một tiếng sau đội trực mới khoanh được nguyên nhân về phía DNS. Tới 2 giờ 25 sáng, DynamoDB trở lại.
Dịch vụ lõi sống lại vẫn chưa hết chuyện. Bộ phận điều phối máy chủ vật lý của EC2 dựa vào DynamoDB để gia hạn quyền quản lý từng máy. Mất kết nối mấy tiếng, nó tích một núi việc tồn rồi tự làm nghẽn chính mình. AWS phải can thiệp bằng tay, tới 5 giờ 28 sáng mới gỡ xong.
Lớp thứ ba nằm ở mạng. Hàng đợi cấu hình dồn lại khiến phép kiểm tra sức khoẻ của bộ cân bằng tải trả về kết quả sai. Máy còn tốt cũng bị gạt khỏi vòng phục vụ. Hơn 2 giờ chiều mọi thứ mới về mức bình thường. Cộng lại gần mười lăm tiếng, và trong khoảng đó hơn 140 dịch vụ của AWS chịu ảnh hưởng ở mức này hay mức khác.
Cái giá đo được và cái giá không đo được
Downdetector của Ookla đếm hơn mười bảy triệu lượt báo lỗi từ người dùng trong ngày hôm đó. Không sự cố nào khác của năm 2025 chạm tới con số ấy. Snapchat, Fortnite, Roblox, Coinbase, Venmo và cả chuông cửa Ring đều nằm trong danh sách nạn nhân.
CyberCube, hãng mô hình hoá rủi ro mạng, đặt tên sự việc là “Amazonk”. Họ ước tính tổn thất bảo hiểm nằm trong khoảng 38 đến 581 triệu đô la Mỹ, và nghiêng hẳn về đầu thấp, quanh 40 triệu. Lý do khá thực tế. AWS vốn bù bằng tín dụng dịch vụ theo cam kết, còn doanh nghiệp thì ít ai chịu mở hồ sơ đòi bảo hiểm cho vài giờ gián đoạn. Cũng theo ước tính của hãng này, hơn 2.000 tổ chức lớn và khoảng 70.000 tổ chức nói chung bị chạm tới.
Con số 581 triệu sau đó được nhiều nơi trích lại như thiệt hại thật. Đọc bản gốc thì nó chỉ là trần trên của một khoảng ước tính sơ bộ.
Vì sao một vùng lại kéo theo cả thế giới
us-east-1 mở trước tất cả các vùng khác. Vì lý do lịch sử, nhiều dịch vụ toàn cầu của AWS vẫn giữ mặt phẳng điều khiển ở đó. Bạn chạy hệ thống tại Singapore hay Tokyo, nhưng vài thao tác quản trị vẫn phải vòng qua Bắc Virginia. Nhiều đội kỹ thuật chỉ phát hiện ra chi tiết này giữa lúc đang chữa cháy.
Sâu hơn nữa là kiểu phụ thuộc mà dân vận hành gọi là phụ thuộc ẩn. DynamoDB nằm trên đường đi nội bộ của Lambda, của EC2, của lớp xác thực. Không sơ đồ kiến trúc nào vẽ ra mấy mũi tên đó, cho tới hôm chúng gãy.
Ở trong nước, phần lớn doanh nghiệp chẳng chạy gì trực tiếp tại Bắc Virginia. Rắc rối nằm ở lớp dịch vụ bên thứ ba. Công cụ gửi thư tự động, nền tảng đo hành vi người dùng, kho ảnh, cổng đăng nhập mạng xã hội — rất nhiều thứ trong đó đặt trên AWS. Khách hàng cuối không bao giờ hỏi tới. Hệ thống của bạn vẫn chạy, các mảnh ghép quanh nó thì không, và trải nghiệm vỡ ở đúng chỗ khó đoán nhất. Khi ngồi rà kiến trúc cùng đối tác, phần lâu nhất của RBE thường là dựng lại đúng cái danh sách phụ thuộc chưa ai viết ra.
Bài học rút ra không phải là rời bỏ đám mây công cộng. Bài học nằm ở chỗ biết rõ mình đang đứng trên cái gì, và cái đó còn tựa vào cái gì nữa.
