Tóm tắt sự cố gián đoạn dịch vụ Amazon DynamoDB tại khu vực Miền Đông Hoa Kỳ (Bắc Virginia, US-East-1)

• Trong hai ngày 19~20/10/2025, khu vực AWS N. Virginia (us-east-1) đã gặp sự cố kéo dài trên Amazon DynamoDB cùng nhiều dịch vụ cốt lõi khác
• Sự cố bắt đầu khi một race condition tiềm ẩn trong hệ thống quản lý DNS tự động của DynamoDB tạo ra nhầm một bản ghi DNS rỗng không hợp lệ
• Điều này dẫn đến chuỗi sự cố gồm không thể tạo EC2 instance, lỗi kết nối Network Load Balancer (NLB), cùng độ trễ và lỗi API trên nhiều dịch vụ như Lambda, ECS, Redshift
• AWS xác định nguyên nhân là xung đột cập nhật đồng thời bất thường giữa các DynamoDB DNS Enactor, và đã khôi phục hoàn toàn vào khoảng 2:20 chiều ngày 20/10 sau khi can thiệp thủ công
• Sự cố lần này cho thấy độ phức tạp trong sự phụ thuộc lẫn nhau giữa các hệ thống tự động hóa nội bộ của AWS, và báo hiệu các cải tiến cấu trúc sắp tới để tăng khả năng phục hồi cho DNS, EC2 và NLB

---

Tổng quan sự cố

• Sự cố bắt đầu lúc 11:48 tối (PDT) ngày 19/10/2025 và kết thúc lúc 2:20 chiều (PDT) ngày 20/10
  • Có ba giai đoạn ảnh hưởng chính:
    1. 11:48PM ngày 19/10 ~ 2:40AM ngày 20/10: tỷ lệ lỗi API của DynamoDB tăng vọt
    2. 5:30AM ~ 2:09PM ngày 20/10: lỗi kết nối NLB gia tăng
    3. 2:25AM ~ 10:36AM ngày 20/10: thất bại khi tạo EC2 instance mới và sự cố kết nối mạng
• Sự cố bắt đầu từ lỗi trong hệ thống quản lý DNS của DynamoDB rồi lan sang nhiều dịch vụ như EC2, NLB, Lambda, Redshift

Nguyên nhân và tác động của sự cố DynamoDB

• Hệ thống quản lý DNS tự động của DynamoDB đã kích hoạt một lỗi tiềm ẩn, khiến bản ghi DNS của dynamodb.us-east-1.amazonaws.com bị cập nhật sai thành trạng thái rỗng
  • Hệ thống được tách thành hai thành phần:
    • DNS Planner: giám sát trạng thái load balancer và tạo kế hoạch DNS mới
    • DNS Enactor: áp dụng thay đổi lên Route53
• Đã xảy ra race condition giữa các DNS Enactor được triển khai độc lập trên ba Availability Zone (AZ)
  • Enactor thứ nhất áp dụng một kế hoạch cũ trong trạng thái bị trễ
  • Enactor thứ hai áp dụng kế hoạch mới nhất rồi xóa kế hoạch cũ, khiến toàn bộ địa chỉ IP bị loại bỏ và hệ thống rơi vào trạng thái không nhất quán
  • Việc tự động khôi phục thất bại nên cần can thiệp thủ công
• Ngay sau khi sự cố bắt đầu lúc 11:48PM, tất cả dịch vụ và lưu lượng khách hàng phụ thuộc vào DynamoDB đều gặp lỗi kết nối
  • Khách hàng dùng global table vẫn có thể gửi yêu cầu tới bản sao ở khu vực khác, nhưng phát sinh replication lag
• Lúc 12:38AM, kỹ sư AWS xác nhận trạng thái DNS là nguyên nhân của sự cố
  • Lúc 1:15AM, một biện pháp khôi phục tạm thời đã giúp khôi phục kết nối cho một phần dịch vụ nội bộ
  • Lúc 2:25AM, thông tin DNS được khôi phục hoàn toàn, và đến 2:40AM thì mọi kết nối đã trở lại bình thường

Tác động tới Amazon EC2 và quá trình khôi phục

• Trong khoảng 11:48PM ngày 19/10 ~ 1:50PM ngày 20/10, đã xảy ra tăng tỷ lệ lỗi API EC2, thất bại khi tạo instance và tăng độ trễ
  • Các instance đang chạy sẵn không bị ảnh hưởng
• Việc quản lý EC2 instance sử dụng hai hệ thống con là DropletWorkflow Manager (DWFM) và Network Manager
  • DWFM quản lý trạng thái của các máy chủ vật lý (“droplet”) và thực hiện kiểm tra trạng thái định kỳ
  • Network Manager truyền bá cấu hình mạng của instance
• Do sự cố DynamoDB, việc kiểm tra trạng thái của DWFM thất bại khiến lease của các droplet hết hạn
  • Sau khi DynamoDB được khôi phục lúc 2:25AM, DWFM cố gắng kết nối lại nhưng do số lượng droplet quá lớn đã dẫn tới congestive collapse
  • Lúc 4:14AM, kỹ sư chọn lọc khởi động lại các host DWFM để dọn hàng đợi và tiếp tục khôi phục
  • Lúc 5:28AM, toàn bộ lease của droplet được phục hồi và việc tạo instance mới được nối lại
• Sau đó, khi Network Manager xử lý backlog lan truyền trạng thái mạng bị chậm, đã phát sinh độ trễ kết nối mạng
  • Lúc 10:36AM, thời gian lan truyền mạng trở lại bình thường
  • Lúc 11:23AM bắt đầu nới lỏng giới hạn yêu cầu (throttling), và đến 1:50PM thì EC2 được khôi phục hoàn toàn

Tác động tới Network Load Balancer (NLB)

• Từ 5:30AM ~ 2:09PM ngày 20/10, một số khách hàng gặp lỗi kết nối NLB gia tăng
  • NLB có kiến trúc multi-tenant và định tuyến lưu lượng tới các EC2 instance backend
• Nguyên nhân là thất bại health check do chậm lan truyền trạng thái mạng
  • Cấu hình mạng của các EC2 instance mới thêm chưa hoàn tất nên health check thất bại
  • Kết quả health check dao động lặp lại, khiến các node NLB bị gỡ khỏi DNS rồi lại quay trở lại
• Lúc 6:52AM, hệ thống giám sát phát hiện vấn đề và kỹ sư bắt đầu xử lý
  • Tải tăng trên hệ thống con health check đã kích hoạt cơ chế failover DNS AZ tự động
  • Lúc 9:36AM, việc vô hiệu hóa failover tự động đã đưa toàn bộ node bình thường trở lại
  • Lúc 2:09PM, sau khi EC2 khôi phục, failover tự động được bật lại

Tác động tới các dịch vụ AWS khác

• AWS Lambda:
  • Lỗi API và độ trễ từ 11:51PM ngày 19/10 ~ 2:15PM ngày 20/10
  • Do sự cố DynamoDB, việc tạo/cập nhật function thất bại và xử lý sự kiện SQS/Kinesis bị chậm
  • Lúc 7:04AM, thất bại health check của NLB khiến hệ thống nội bộ bị thu hẹp, làm hạn chế các lời gọi bất đồng bộ
  • Đến 2:15PM, mọi backlog đã được xử lý xong và hệ thống trở lại bình thường
• ECS, EKS, Fargate:
  • Thất bại khi chạy container và chậm mở rộng cluster trong khoảng 11:45PM ngày 19/10 ~ 2:20PM ngày 20/10
• Amazon Connect:
  • Lỗi trong xử lý cuộc gọi, chat và case từ 11:56PM ngày 19/10 ~ 1:20PM ngày 20/10
  • Sau khi DynamoDB khôi phục, phần lớn chức năng hoạt động lại bình thường, nhưng từ 7:04AM lại phát sinh lỗi do ảnh hưởng của NLB và Lambda
  • Khôi phục hoàn toàn lúc 1:20PM
• AWS STS:
  • Lỗi và độ trễ trên API xác thực từ 11:51PM ngày 19/10 ~ 9:59AM ngày 20/10
  • Tạm thời bình thường sau khi DynamoDB khôi phục, rồi lại phát sinh lỗi do vấn đề NLB
• Đăng nhập IAM và Identity Center:
  • Tăng lỗi xác thực từ 11:51PM ngày 19/10 ~ 1:25AM ngày 20/10
  • Trở lại bình thường sau khi DynamoDB được khôi phục
• Amazon Redshift:
  • Thất bại khi truy vấn và chỉnh sửa cluster từ 11:47PM ngày 19/10 ~ 2:21AM ngày 20/10
  • Sau khi DynamoDB khôi phục, một số cluster vẫn chưa bình thường do sự cố EC2
  • Khôi phục hoàn toàn lúc 4:05AM ngày 21/10
  • Do phụ thuộc vào IAM API, ngay cả các khu vực toàn cục cũng tạm thời gặp lỗi truy vấn
• Các dịch vụ khác:
  • Managed Workflows for Apache Airflow, Outposts, AWS Support Center cùng một số dịch vụ khác cũng bị ảnh hưởng

Biện pháp hậu sự cố và kế hoạch cải thiện

• Tự động hóa DNS Planner và Enactor của DynamoDB đã bị vô hiệu hóa hoàn toàn, và trước khi kích hoạt lại AWS sẽ sửa race condition cũng như bổ sung cơ chế bảo vệ
• NLB: triển khai cơ chế điều tiết tốc độ để giới hạn lượng công suất mà một NLB đơn lẻ có thể loại bỏ khi health check thất bại
• EC2:
  • Xây dựng bộ test mới bao gồm cả quy trình khôi phục DWFM
  • Cải thiện smart throttling trong hệ thống lan truyền dữ liệu để bổ sung khả năng giới hạn yêu cầu theo kích thước hàng đợi chờ
• AWS đang tiếp tục rà soát thêm sự phụ thuộc lẫn nhau giữa các dịch vụ để rút ngắn thời gian khôi phục và ngăn các sự cố tương tự

Kết luận và lời xin lỗi

• AWS đã chính thức xin lỗi về tác động mà sự cố lần này gây ra cho khách hàng
• Dù trước nay công ty đã duy trì tính sẵn sàng cao cho các dịch vụ, AWS thừa nhận sự cố này đã gây ảnh hưởng nghiêm trọng tới hoạt động kinh doanh của khách hàng
• AWS cam kết lấy sự cố này làm bài học để tăng cường khả năng phục hồi của các hệ thống tự động hóa và quy trình ứng phó sự cố

[shakespeares]

Nghe nói đây là dư chấn sau khi sa thải các nhân sự cấp cao... có đúng vậy không?

[GN⁺]

Ý kiến trên Hacker News

• Tôi là người lúc nào cũng lặp lại cùng một điều về chủ đề này. Nếu bạn դեռ chưa đọc bài viết của Richard Cook, tôi khuyên hãy dừng bản postmortem này lại và đọc How Complex Systems Fail trước. Đây là một trong những bài viết kỹ thuật hay nhất về thất bại của các hệ thống phức tạp. Cook bác bỏ chính khái niệm “nguyên nhân gốc rễ (root cause)”, và tôi nghĩ trong sự cố lần này ông ấy đã đúng

  • Bài của Cook ổn, nhưng thực ra nó tạo cảm giác giống như một danh sách các lập luận mang tính trực giác. Muốn hiểu sâu thật sự thì có lẽ phải đọc hết các tài liệu tham khảo. Trong môn học hệ thống 6.033 của MIT cũng cho đọc một bài báo năm 1962 và một bài báo kinh điển khác nói về những chủ đề tương tự. Tôi xem đây là trường hợp mà vấn đề cuối cùng đã đạt tới mức độ phức tạp kiểu ‘Wicked problem’
  • Điều gây ấn tượng với tôi trong bài của Cook là việc cố sửa hệ thống cho “an toàn hơn” sau tai nạn đôi khi lại có thể làm giảm độ an toàn. Cách giải thích rằng các biện pháp nhằm ngăn lỗi do con người lại làm tăng mức độ kết dính và độ phức tạp của hệ thống, từ đó làm tăng các điểm lỗi tiềm ẩn và khiến việc phát hiện/ngăn chặn khó hơn, đặc biệt khiến tôi thấy thấm
  • Một góc nhìn khác là lý thuyết ‘Normal Accidents’. Lập luận của nó là khi các thành phần được liên kết chặt, tương tác phức tạp và hậu quả của thất bại nghiêm trọng, thì hệ thống về bản chất sẽ nguy hiểm hơn. Xem wiki về Normal Accidents
  • Tôi chưa đọc trọn vẹn cả hai tài liệu, nhưng tôi không đồng ý với lập luận rằng chỉ vì hệ thống phức tạp nên không thể xác định nguyên nhân gốc rễ của thất bại. Trong thể thao cũng vậy, ghi điểm là kết quả của nhiều yếu tố, nhưng cuối cùng vẫn có ‘người ghi điểm’. Có cái nhìn rộng là tốt, nhưng chỉ ra nguyên nhân chính cũng rất thực tế
  • Tôi là một nhà thầu làm oncall. Hầu hết các công ty không coi oncall là chuyện nghiêm túc. Tài liệu hóa cũng thiếu, và cũng không cho thời gian để đọc code phức tạp của người khác. Tôi thật sự muốn một lần được trải nghiệm văn hóa coi oncall là một phần của học tập và trách nhiệm như ở AWS

• Internet đang dần biến thành một mạng đơn tập trung (mononet). Internet sinh ra như một mạng phân tán thời Chiến tranh Lạnh, giờ đây lại trở thành cấu trúc mà chỉ một lỗi triển khai cũng có thể khiến ngân hàng, mua sắm và du lịch trên toàn thế giới ngừng hoạt động. Ẩn dụ “đám mây” đã vượt quá giới hạn của nó từ lâu.
  Nó vẫn hữu ích cho startup hay R&D, nhưng các công ty đang ở giai đoạn tăng trưởng hoặc chính phủ thì nên có máy chủ riêng, cloud riêng, dịch vụ cốt lõi riêng. Công nghệ và nhân lực đều đã đủ

• Tôi ấn tượng với cách trực quan hóa timeline chính xác trong bản postmortem của AWS. Giống như bài nói chuyện huyền thoại ở GDC “I Shot You First”, cách thể hiện dòng thời gian bằng các mũi tên nghiêng và đặt câu hỏi “độ trễ phát sinh ở đâu” rất hữu ích.
  Nhưng điều làm tôi ngạc nhiên hơn là dịch vụ quản lý lease của node EC2 lại không có quy trình khôi phục (runbook). Với một dịch vụ cốt lõi của AWS, tôi đã nghĩ gần như mọi tình huống ngoại lệ đều phải được chuẩn bị sẵn

  • Không nên sợ những tình huống như vậy, mà nên nhìn nhận chúng như mẫu hình bản chất của hệ thống phức tạp. Các thất bại tiềm ẩn tồn tại như fractal, và không thể có runbook cho mọi trường hợp có thể xảy ra

• Cốt lõi của sự cố lần này có vẻ giống một biến thể của vấn đề vô hiệu hóa bộ nhớ đệm (cache invalidation) trong hệ thống DNS. Hai DNS Enactor áp dụng plan ở các thời điểm khác nhau nên phát sinh race condition, và plan cũ đã ghi đè lên plan mới

  • Đây chỉ là cách giải thích cho công chúng; bên trong thực tế, sau khi xử lý sự cố xong sẽ có đánh giá khả năng tái diễn và viết biện pháp giảm thiểu (runbook). Sau đó sẽ tiếp tục có học hỏi và chia sẻ ở cấp tổ chức
  • Tôi xem chính race condition này là nguyên nhân gốc rễ. Nếu không có bug đó thì đã không có sự cố
  • Tôi thắc mắc vì sao lại tách DNS Planner và Enactor ra. Nếu là một dịch vụ duy nhất thì trạng thái cạnh tranh kiểu này hẳn sẽ lộ rõ hơn. Có thể đây là kết quả của lạm dụng microservices làm tăng độ phức tạp
  • Tôi từng gặp vấn đề tương tự, nguyên nhân là độ trễ JVM GC và phần cứng bị lỗi. Lần này cũng có thể có khả năng như vậy
  • Nhưng AWS lại không nêu rõ biện pháp phòng ngừa khi loại độ trễ này xảy ra lần nữa

• Enactor lẽ ra phải thực hiện so sánh phiên bản của record hiện tại (CAS) trước khi áp dụng giá trị mới. Dù hiệu quả có giảm thì đây vẫn là chốt an toàn cơ bản. Có lẽ DynamoDB tự nó cũng đã có thể xử lý việc này

• Tôi ngạc nhiên khi thấy mô tả rằng DynamoDB quản lý hàng trăm nghìn DNS record theo từng khu vực. dynamodb.us-east-1.amazonaws.com mà có thể phân giải ra hàng trăm nghìn IP thì có vẻ vượt quá giới hạn của Route53. Có lẽ họ để TTL thấp và chỉ cập nhật một phần

  • Thực tế DNS của AWS hoạt động theo cách đó. Route53 vận hành theo đơn vị resource record set (RRSet), và trả về set phù hợp thông qua health check hoặc logic lựa chọn dựa trên độ trễ
  • CDN cũng hoạt động tương tự. Nó thu thập metric hệ thống để tính ra PoP tối ưu theo từng mạng. bunny.net SmartEdge là một ví dụ hay
  • Tôi cũng thử với S3, và chỉ trong vài giây đã nhận được hàng trăm IP khác nhau. Ngay cả trong một region duy nhất cũng có mức độ đa dạng như vậy

• Bug thì lúc nào cũng tồn tại. Formal verification rất khó, và những bug xác suất thấp đôi khi phải nhiều năm sau mới phát nổ.
  Vì vậy phải giả định rằng hệ thống chắc chắn sẽ thất bại, rồi thiết kế cấu trúc giới hạn thiệt hại. Kiến trúc dựa trên cell, rollout theo từng bước, và các zone cách ly là ví dụ.
  AWS cũng đang thử theo hướng cell-based, nhưng đặc biệt ở us-east-1 vẫn còn các phụ thuộc chéo mang tính legacy. Về dài hạn, region cần được thiết kế độc lập hoàn toàn.
  Công việc như vậy sẽ không thể tiến hành nếu không có sự hậu thuẫn của lãnh đạo cấp cao, nhưng ở góc độ cổ đông thì đây là khoản đầu tư cốt lõi để giảm rủi ro sống còn của công ty

• Tôi thấy lạ khi báo cáo dùng múi giờ PT thay vì UTC

  • Có người còn đùa là “epoch fail?”, nhưng vì phần lớn khách hàng ở Mỹ nên PT có thể trực quan hơn
  • Cũng có thể họ muốn nhấn mạnh độ khó của ứng phó ban đêm

• Tôi ngạc nhiên khi không có các mẫu như quản lý phiên bản per-endpoint hay 2PC, single writer lease. Dù vậy tôi vẫn đánh giá cao việc AWS công khai minh bạch như thế này

  • Thực tế API thay đổi DNS có thực hiện CAS, nhưng nhiều writer bất đồng bộ lại cạnh tranh mà không có thứ tự logic, nên mới phát sinh vấn đề. Lẽ ra họ phải tuần tự hóa thứ tự bằng zone serial hoặc sentinel record

• Tôi cho rằng nguyên nhân trực tiếp của sự cố lần này là race condition tiềm ẩn trong hệ thống quản lý DNS của DynamoDB. Plan cũ đã ghi đè plan mới nhất, khiến DNS record của endpoint khu vực bị trống

  • Nhưng vẫn cần thận trọng với khái niệm “nguyên nhân gốc rễ”. Lần này đây là một sự sụp đổ siêu ổn định (metastable collapse), và vấn đề trọng tâm là thiếu quy trình khôi phục (runbook).
    Tham khảo: How Complex Systems Fail