Nhiều dịch vụ của AWS gặp sự cố tại khu vực us-east-1

• Sự cố đã xảy ra trên nhiều dịch vụ trong khu vực us-east-1 của AWS
• Sự cố này khiến các doanh nghiệp sử dụng hạ tầng đám mây trải qua gián đoạn dịch vụ
• Báo cáo tình trạng sẵn sàng gặp vấn đề của các dịch vụ quan trọng như API Gateway, Lambda
• Các kỹ sụ đã làm rõ nhu cầu chuẩn bị đường đi dự phòng và xem xét kế hoạch ứng phó khẩn cấp
• AWS Health Dashboard cung cấp thông tin và cập nhật sự cố theo thời gian thực

---

Tổng quan sự cố khu vực AWS us-east-1

• Vào ngày 21 tháng 10 năm 2025, AWS Health Dashboard ghi nhận sự cố trên nhiều dịch vụ thuộc khu vực us-east-1
• Đặc biệt, các dịch vụ quan trọng như API Gateway, Lambda, S3 bị ảnh hưởng, khiến nhiều khách hàng trải qua gián đoạn dịch vụ
• Ngay từ lúc phát hiện, AWS đã bắt đầu ngay việc phân tích nguyên nhân và phục hồi
• Các công ty SaaS, startup và doanh nghiệp công nghệ phụ thuộc vào khu vực này đã báo cáo độ trễ dịch vụ và thời gian downtime
• Kỹ sư và quản trị viên IT nhấn mạnh nhu cầu xây dựng đường đi dự phòng khẩn cấp và chiến lược đa vùng cho các dịch vụ quan trọng

Tác động và ứng phó

• Khu vực us-east-1 là một trong những khu vực có lưu lượng truy cập cao nhất trong hạ tầng đám mây toàn cầu, do đó tác động lan tỏa khi xảy ra sự cố là rất lớn
• Trên thực tế, nhiều khách hàng ghi nhận đồng thời các vấn đề như dịch vụ ngừng cung cấp, độ trễ phản hồi API, sự cố xử lý dữ liệu
• AWS cung cấp tình hình theo thời gian thực, tài liệu hỗ trợ và bản cập nhật thông qua AWS Health Dashboard
• Các nhóm IT của khách hàng đã nỗ lực giảm thiểu thiệt hại bằng giám sát tình hình sự cố, chuyển hướng tạm thời và thông báo cho người dùng

Hàm ý cho kỹ sư

• Sự cố nhấn mạnh lại việc cần thiết phải tái xác nhận tầm quan trọng của hệ thống giám sát và cơ chế cảnh báo sự cố
• Giá trị của việc thiết kế kiến trúc có tính chịu lỗi cao như triển khai đa vùng, thao tác tự động khi sự cố và chiến lược sao lưu được làm nổi bật
• AWS Health Dashboard được xem như công cụ hỗ trợ ra quyết định và truy cập thông tin nhanh trong tình huống sự cố

Kết luận

• Các nhà cung cấp dịch vụ đám mây quy mô lớn cần thiết lập kế hoạch dự phòng cho khả năng gián đoạn dịch vụ
• Trong trường hợp sự cố, tầm quan trọng của quá trình khôi phục nhanh chóng, truyền thông minh bạch và năng lực ứng phó sự cố hạ tầng hiệu quả được nhấn mạnh một lần nữa

[GN⁺]

Ý kiến trên Hacker News

• Hôm nay thực sự là một ngày rất thú vị. Mình có mặt ở cầu nối ứng phó sự cố từ 3 giờ sáng. Hệ thống hầu hết đã được khôi phục, nhưng vẫn còn một bộ phận back office đang vật lộn vì thiếu tài nguyên. Sai lầm lớn nhất của chúng tôi là, dù đã thiết kế để có thể hoạt động đa region rồi, nhưng vẫn không thể thực thi được quy trình failover. Lý do là đội bảo mật đã chuyển chúng tôi sang Identity Center nhưng đặt nó duy nhất tại us-east-1, khiến toàn bộ công ty bị khóa hẳn vào control plane của AWS. Khi phải lấy thông tin đăng nhập root từ vault ra thì hệ thống đã gần như hồi phục rồi. Vụ này lại nhắc nhớ một lần nữa rằng mắt xích yếu nhất mới quyết định độ bền của toàn hệ thống.
  • Trước đây nhớ hồi vài năm trước, khi data center của Google ở Paris bị ngập rồi bùng cháy. Chúng tôi không đặt trực tiếp tài nguyên compute ở đó, nhưng service AWS của chúng tôi chạy trên data center EU và DNS resolver cho dịch vụ Google được host tại Paris, nên đường truy cập đã ưu tiên route về Paris. Hóa ra giải pháp tạm thời khá thú vị. Lúc đó lần đầu tiên tôi mới biết có thể chỉnh sửa file /etc/hosts được deploy toàn cục trong Kubernetes, và đã cần đến mức phải làm vậy ngay lập tức. Bình thường tôi không dùng /etc/hosts cho mục đích này, nhưng để vá tạm thì mức trừu tượng đó đúng là vừa đủ.
  • Nhớ lại một trường hợp tương tự khi Facebook làm lỗi cập nhật BGP khiến vault trở nên hoàn toàn không thể truy cập. Nếu luồng xác thực có cấu trúc tuần hoàn, chỉ cần DNS hỏng một lần là không thể làm gì thêm.
  • Cuối cùng sẽ đến lúc phải có ai đó cầm token phần cứng, bay tới một data center khác để reset thiết bị then chốt khiến hệ thống toàn cầu chạy lại.
  • Có nhắc đến việc đặt Identity Center chỉ ở us-east-1, tôi tò mò nó có thể đặt ở nhiều region không. Lần cuối tôi kiểm tra thì nó chỉ hoạt động ở một region và muốn chuyển đi thì phải xóa trước.
  • Rào cản bảo mật quá mức lại khiến mọi thứ không thể di chuyển. Không biết đội bảo mật có chịu trách nhiệm cho sự cố này hay không. Có vẻ mọi dự án sắp tới của chúng ta sẽ chậm lại. Họ đã đi quá nhanh quá lâu rồi. Câu hỏi là ai sẽ giám sát người giám sát?
• Có vẻ như vẫn còn sự cố lớn, và tệ hơn so với 4 giờ trước. Mình là data engineer và thấy Redshift, Airflow (dịch vụ managed của AWS) đang rối tung.
  • Sự cố kéo dài khá lâu, không biết đã mất bao nhiêu “con 9”. 365 ngày * 24 giờ * 0.0001 là khoảng 8 giờ, nghĩa là đã mất ngay mức 99,99% availability.
  • Không hiểu sao nhiều công ty vẫn bám chặt us-east-1. Nếu xét theo tần suất lỗi thì đây là nơi tệ nhất. Công ty tôi từng quyết định tránh us-east-1 và chỉ dùng các region khác. Tất nhiên, khi một dịch vụ được gọi là “global”, thực tế thường có nghĩa là us-east-1, nên có lúc vẫn không giúp được.
  • Các thao tác control plane của Lambda create-function vẫn còn fail với InternalError. Các dịch vụ khác (Lambda, SNS, SQS, EFS, EBS, CloudFront) đã hồi phục. Tôi đang làm nghiên cứu thạc sĩ CS về tính khả dụng cloud, nên đã thử nghiệm trên nhiều tài khoản AWS test, rồi tổng hợp timeline và tác động để đăng lại. Bài phân tích
  • Down Detector cho thấy sự cố AWS vẫn nghiêm trọng. Amazon nói là “đang khôi phục”, nhưng thực tế trên Amazon.com ngay lúc này việc tìm sản phẩm cũng không chạy. AWS Health page
  • Theo Down Detector, 12:52 AM PT (3:53 AM ET) có 5.755 báo cáo sự cố AWS, đến 4:22 AM PT (7:22 AM ET) giảm còn 1.190, rồi 9:32 AM PT (12:32 PM ET) lại tăng vọt lên 9.230. Khi West US dậy lại có thể góp phần tăng lượng báo cáo, nhưng dường như AWS vẫn chưa kiểm soát được tình hình.
• Sự cố này ảnh hưởng trực tiếp tới sinh hoạt hằng ngày của tôi. Tới Hudson Yards Whole Foods ở New York để mua thanh sôcôla nhưng không áp dụng được chiết khấu Prime nên đã không mua; giờ kho dự trữ sôcôla của tôi rất thấp.
  • Sáng nay câu lệnh “alexa mở máy pha cà phê” cũng không chạy. Cảm giác choáng váng.
  • Lúc trưa lấy đồ tại Hotbar và thử tự thanh toán, tôi loay hoay khá lâu không hiểu sao barcode của Whole Foods lại không hoạt động. Sau hơn 20 giây mới nhận ra là do sự cố.
  • Chia sẻ case này rất hay. Nhưng sự cố này khiến tôi tò mò không biết lúc AWS outage, mọi người đang ở Amazon Go ra sao.
• Hôm nay tôi có cuộc họp với account manager AWS. Sẽ trình bày định hướng thoát khỏi “All in on AWS” và phân tán workload. Lý do chính là tốc độ đổi mới của các core service chậm đi, lại thêm dịch vụ AI bị tụt xa hơn so với đối thủ. Team AWS vẫn luôn cho rằng đừng phân tán vì kể cả chuyện ổn định cực cao của AWS. Hôm nay tôi mong chờ cuộc họp.
  • Với AWS, Cloudflare, Google Cloud hay Akismet, ai rồi cũng gặp outage. Mỗi lần như vậy lại khiến người ta nghĩ tới in-house hosting. Cuối cùng thì lại là chuyện nhận refund rồi quay lại vận hành thôi. Kết quả vẫn tương tự nên không cần phải làm quá sức.
  • Lúc Amazon công bố kết quả gần đây, Andy Jassy bị chỉ trích vì AWS bị cho là chậm đổi mới, và anh ta đưa ra lập luận về stability, reliability, durability. Nhưng nhìn vào tình hình hiện tại thì lời giải thích đó không thuyết phục.
  • Tránh trừ us-east-1 thì các region khác đang vận hành khá ổn định. Công ty tôi cũng đặt hầu hết lên eu-west-1 và hiện tại chạy bình thường.
  • AWS đang đi vào giai đoạn suy thoái. Hiện tại trông như đang chỉ duy trì các dịch vụ đã có. Những kỹ sư giỏi dường như bị nhấn chìm bởi nội bộ quan liêu và áp lực KPI, nên cả mảng AI cũng tụt hậu.
  • Lập luận về độ ổn định nổi tiếng của AWS vốn đã không đúng từ đầu. Trước đây, khi tôi thiết lập giám sát đa cloud và dedicated server, có thể thấy rất rõ thứ gì thường lỗi trước. Kết quả khi đó cho thấy AWS không hẳn luôn số 1. Số liệu gần khớp với netcraft.com.
• Hôm nay giải đấu Premier League cũng sẽ chỉ vận hành hạn chế hệ thống VAR và tự động phán xét offside do outage của AWS. Thật là thời đại kỳ quái. Liên kết BBC
  • Có lẽ đây là một điểm cộng nhỏ của cloud (và cả các outage).
• Khi chọn us-east-1 là region chính, khi có sự cố thì không ai chịu riêng lẻ vì mọi thứ cùng ngừng; các region khác của Mỹ không có đặc quyền như vậy.
  • Một lợi ích bất ngờ khi chuyển từ data center cũ sang AWS là khi cả region down thì khách hàng sẽ dễ thông cảm hơn. Khi ai cũng cùng lúc khó chịu, mọi người dễ bỏ qua hơn.
  • Đôi khi ai cũng cần trải qua downtime kỹ thuật một lần.
  • Ừ, chúng ta hãy đưa hạ tầng lên US-East-1.
  • Trong môi trường doanh nghiệp, phải mất thời gian mới thấy ra điều thực sự quan trọng. Thực ra, cấu trúc đổ lỗi quan trọng hơn availability. 5 phút down do lỗi con người thì là lỗi của CTO; 5 giờ down do AWS thì ai cũng bực nên bị xem là “bất khả kháng”. AWS, Crowdstrike... cuối cùng thì không phải chuyện hệ thống vững chắc, TCO hay risk management, mà là ai cũng cùng chịu khó chịu. Nó khó chịu nhưng đó là thực tế. Với người thích công nghệ chạy ổn, thật bực mình.
  • Region Tokyo hiện đang chạy tốt! Chỉ vẫn còn lỗi ở một vài tính năng như đăng nhập console.
• Có thông báo: “Kết quả điều tra cho thấy có vẻ liên quan đến vấn đề giải quyết DNS của endpoint DynamoDB API tại us-east-1. Chúng tôi đang xử lý song song để đẩy nhanh khôi phục.” Lại là DNS như thường lệ.
  • Tôi tự hỏi đây có phải thực sự là vấn đề DNS resolution của DynamoDB API hay là cấu hình nội bộ/cơ sở dữ liệu của DNS server? Có vẻ nghiêng về khả năng thứ hai.
  • Bản thông báo sau đó cho rằng nguyên nhân là failure của network load balancer. DNS là triệu chứng của vấn đề gốc. DNS có thể làm hỏng health check, nhưng theo tôi nguyên nhân chính vẫn ở mạng.
  • BGP có thể là DNS giả dạng.
  • Nguyên nhân luôn là us-east-1.
  • Dù không phải DNS thì vẫn vẫn là DNS.
• Thiết kế hướng resilience đã hoạt động đúng như dự kiến. Chúng tôi đã đặt static site origin đa region với CloudFront nên lần outage này không bị ảnh hưởng. Control plane cũng là kiến trúc multi-region native, mặc dù phụ thuộc nhiều dịch vụ nhưng vẫn giữ được availability. Mỗi region hoạt động độc lập; replicate dữ liệu nhưng ngay cả khi không replicate về us-east-1 vẫn không bị ảnh hưởng. Bản thân dịch vụ là multi-region và xử lý failover nhiều lớp (DNS, routing, destination selection). Kiến trúc này chưa hoàn hảo và có nhiều điểm lỗi, nhưng lần này chạy trơn tru nên tôi thấy rất an tâm. Công việc của tôi không phải rocket engineering hay tốn kém, nhưng đây là cách làm hơi khác người ta làm. Nếu có gì cần thảo luận, đừng ngại hỏi.
  • Việc tận dụng CloudFront cho static origin đa region để tránh sự cố đáng lẽ đã phải là mặc định năm 2025, vậy mà giờ vẫn đáng khen.
  • Đây có phải active/active và stack dữ liệu của bạn thế nào? Tôi nghĩ đây là phần khó nhất.
  • Tôi muốn biết cách bạn triển khai redundancy cho key và chứng chỉ như thế nào.
• Một vấn đề lớn là hệ thống IAM/auth overload hoặc down đã tạo nên chuỗi lỗi tiếp theo. Có người nói nguồn gốc là DynamoDB; tôi tò mò IAM có phụ thuộc nội bộ vào Dynamo không. Trong các hệ thống quy mô lớn, phụ thuộc chằng chịt rất phức tạp; Auth/IAM có nguy cơ thành single global touchpoint nên muốn giảm dependency tối đa. Nhưng mở rộng, consistency, v.v... cũng buộc phải dùng DB đã kiểm chứng. Khi hệ thống down, có lẽ phải qua bootstrap phức tạp mới hồi phục. Tôi tò mò AWS xử lý như thế nào.
  • Khoảng 2017 từng có outage lớn của DynamoDB. EC2 lưu danh sách server trên DynamoDB, nên khi DynamoDB down, EC2 cũng down. DynamoDB chạy trên EC2 nên không thể khởi chạy lại instance EC2 để khôi phục. Đành vài ngày phải bật EC2 thủ công để hồi phục. Từ đó tôi cố gắng tách phụ thuộc giữa các hệ thống 1st-tier như S3, DynamoDB, EC2 càng nhiều càng tốt. Dù vậy khó đạt hoàn hảo.
  • Nhiều khách hàng AWS có retry policy sai, khi một hệ thống lỗi lại vô tình gây overload cho hệ thống khác. Outage DynamoDB đã kéo theo overload đến IAM.
  • Bên trong AWS có một nền tảng Dynamo KV-store tách riêng, khác với DynamoDB. Nên lỗi có thể đến DNS routing hoặc node deployment. Đây là điểm lặp đi lặp lại trong postmortem các outage lớn.
  • Khi còn làm ở AWS, IAM không phụ thuộc Dynamo. Không biết bây giờ đã thay đổi chưa, nhưng tôi nghiêng về khả năng do issue mạng diện rộng. Auth/IAM không nên là single global touchpoint, nên kiến trúc luôn nhằm giảm dependency. IAM có read-only cache riêng theo region, và AWS SigV4 cũng được thiết kế để chạy theo region. (Tài liệu tham khảo)
  • Gần đây nguyên nhân outage của GCP cũng thú vị ở điểm tương tự.
• AWS thông báo lúc 3:03 AM PT rằng đang trong quá trình khôi phục. Nhưng tình hình lại xấu đi. 9:13 AM PT lại nói tiếp tục điều tra nguyên nhân. AWS dường như không chắc chắn root cause, nên khiến tôi lo lắng.
  • Hình như tuần này là dịp Diwali (lễ lớn nhất Ấn Độ), các kỹ sư Ấn Độ đang nghỉ nên cũng làm trầm trọng thêm. Rất bất hạnh.