Thứ Ba, 21 tháng 10, 2025

Sự cố Amazon Web Services (AWS) ngày 20/10/2025

1. Thông tin sự cố

  • Tên sự cố: “AWS Global Outage – US-EAST-1 Region”

  • Đơn vị chịu trách nhiệm: AWS Cloud Infrastructure (Region US-EAST-1)

  • Mã sự cố nội bộ: chưa công bố cụ thể từ AWS trên báo chí

  • Loại sự cố: Hạ tầng đám mây (Cloud Infrastructure Incident) ảnh hưởng toàn cầu

  • Mô tả thêm: Ngày 20/10/2025 (giờ Việt Nam), hàng loạt dịch vụ của Amazon Web Services (AWS) gặp sự cố tại vùng US-EAST-1 (Bắc Virginia) trung tâm vận hành của rất nhiều workload doanh nghiệp trên toàn cầu.

    Sự cố bắt nguồn từ lỗi phân giải DNS liên quan đến endpoint của Amazon DynamoDB, khiến nhiều hệ thống phụ thuộc như EC2, Lambda, CloudWatch, ECS, và SQS đồng loạt lỗi theo chuỗi. Đây là vùng cloud phổ biến nhất thế giới, nên sự cố đã tạo hiệu ứng lan truyền mạnh trên Internet, dù phạm vi chỉ giới hạn trong một region duy nhất.

2. Thời gian sự cố: Bắt đầu - Kết thúc

  • Bắt đầu: Khoảng 07:11 UTC (~ 14:11 giờ Việt Nam) ngày 20/10/2025. Al Jazeera+2Reuters+2

  • Kết thúc: AWS thông báo vấn đề chính đã được “fully mitigated” vào chiều muộn hoặc tối cùng ngày. Al Jazeera+2ABC+2

  • Lưu ý: Một số dịch vụ vẫn còn hiệu ứng phụ backlog/đang phục hồi sau đó. Reuters+1

3. Mức độ / Phạm vi ảnh hưởng sự cố

  • Mức độ: Cao (Critical) — ảnh hưởng tới hàng nghìn ứng dụng, dịch vụ toàn cầu, nền tảng lớn.

  • Phạm vi ảnh hưởng:

    • Vùng chính bị ảnh hưởng: US‑EAST‑1 (Northern Virginia) – khu vực chính của AWS bị lỗi mạng nội bộ. Reuters+1

    • Dịch vụ bị ảnh hưởng: hàng loạt ứng dụng, nền tảng & dịch vụ phụ thuộc AWS như Snapchat, Fortnite, Duolingo, Canva, Ring, Alexa, các ngân hàng, chính phủ qua dịch vụ AWS. WTOP News+2ABC+2

  • Ảnh hưởng tới doanh nghiệp và người dùng cuối: Các ứng dụng không phản hồi, thanh toán/trading/truy cập bị gián đoạn, dịch vụ lưu trữ và API bị lỗi hoặc chậm.

4. Diễn biến sự cố

Vào đêm 19/10 theo giờ Mỹ (sáng 20/10 theo giờ Việt Nam), AWS bắt đầu ghi nhận các tăng bất thường về lỗi API và độ trễ phản hồi.

Đội ngũ kỹ sư nhanh chóng phát hiện lỗi DNS resolution trong DynamoDB regional endpoint, dẫn đến các dịch vụ nội bộ của AWS không thể truy cập metadata và state cần thiết để vận hành bình thường.

Vì DynamoDB là thành phần nền tảng cho nhiều hệ thống quản lý trạng thái (stateful subsystem), lỗi này kéo theo sự cố thứ cấp ở EC2, Network Load Balancer (NLB), Lambda, và EventBridge.

Sự cố lan rộng ra toàn bộ tầng hạ tầng, ảnh hưởng tới 142 dịch vụ AWS, từ EC2, Lambda đến CloudFormation và CloudTrail.

Timeline chi tiết (giờ địa phương PDT / giờ Việt Nam GMT+7)

Thời điểmDiễn biến chi tiết
19/10 – 11:49 PM PDT (20/10 – 13:49 VN)AWS bắt đầu ghi nhận tăng lỗi API và độ trễ cao tại nhiều dịch vụ trong vùng US-EAST-1.
20/10 – 12:11 AM PDT (14:11 VN)AWS xác nhận sự cố ảnh hưởng nhiều dịch vụ, bao gồm DynamoDB, Lambda, EC2 và IAM. Kích hoạt quy trình SEV (Service Event) khẩn cấp.
12:51–1:26 AM PDT (14:51–15:26 VN)Xác nhận lỗi tập trung tại DynamoDB, gây ảnh hưởng đến các dịch vụ phụ thuộc. Nhiều API timeout hoặc không thể truy cập.
2:01 AM PDT (16:01 VN)AWS xác định nguyên nhân gốc là DNS resolution error trong endpoint của DynamoDB. Triển khai nhiều luồng khắc phục song song (DNS routing, cache flushing).
2:24 AM PDT (16:24 VN)Khôi phục thành công DNS DynamoDB, lưu lượng truy cập bắt đầu ổn định. Tuy nhiên, các dịch vụ như EC2, Lambda và SQS vẫn có backlog lớn.
3:35 AM PDT (17:35 VN)Hầu hết các API đã hoạt động trở lại. AWS khuyến nghị khách hàng flush DNS cache nếu vẫn gặp lỗi kết nối DynamoDB.
4:08–5:10 AM PDT (18:08–19:10 VN)Phát hiện lỗi thứ cấp trong EC2 launch subsystem (do phụ thuộc vào DynamoDB). AWS tạm giảm tốc độ khởi tạo EC2 để tránh bão tải.
5:48 AM PDT (19:48 VN)Một số Availability Zone đã có thể khởi tạo EC2 thành công trở lại. Các dịch vụ phụ thuộc như ECS, Glue, RDS bắt đầu phục hồi.
7:14–8:04 AM PDT (21:14–22:04 VN)AWS phát hiện vấn đề mới trong hệ thống health check của Network Load Balancer (NLB) khiến một số kết nối nội bộ bị gián đoạn.
8:43 AM PDT (22:43 VN)AWS triển khai biện pháp giảm tải, tạm throttle yêu cầu khởi tạo EC2, và bắt đầu phục hồi kết nối mạng nội bộ.
9:38 AM PDT (23:38 VN)Khôi phục hoàn toàn hệ thống kiểm tra tình trạng NLB, các dịch vụ Lambda, CloudWatch và DynamoDB hoạt động ổn định trở lại.
10:03–1:52 PM PDT (22:03–04:52 VN 21/10)AWS giảm dần throttle, xử lý backlog SQS, EventBridge, CloudTrail, và Lambda invocations.
3:01 PM PDT (05:01 VN 21/10)AWS xác nhận toàn bộ dịch vụ US-EAST-1 đã khôi phục hoàn toàn, chỉ còn backlog nhỏ của Redshift, Config, Connect đang xử lý nốt.

Tổng thời gian khắc phục: ~15 giờ, không có mất dữ liệu khách hàng.

5. Nguyên nhân sơ bộ, nguyên nhân gốc

  • Nguyên nhân sơ bộ: Lỗi mạng nội bộ giữa các nút của AWS, dẫn tới tình trạng DNS/định tuyến không chính xác và hàng loạt API/ dịch vụ bị lỗi. Al Jazeera+1

  • Nguyên nhân gốc: AWS công bố rằng nguyên nhân bắt nguồn từ “an underlying internal subsystem responsible for monitoring the health of our network load balancers …” trong mạng nội bộ EC2 tại US-EAST-1. Tom's Guide+1

    • Cụ thể hơn: Hệ thống cân bằng tải (network load balancers) bị ảnh hưởng, dẫn đến việc các API dịch vụ (như Amazon DynamoDB) không thể truy cập đúng. Reuters+1

  • Không có dấu hiệu tấn công mạng (cyber-attack) như AWS và giới phân tích khẳng định. Al Jazeera+1

6. Thủ tục khắc phục

  • Phát hiện và phản ứng nhanh: Chỉ sau 37 phút từ lúc phát hiện, AWS xác định đúng tầng lỗi (DNS) và cô lập phạm vi ảnh hưởng.
  • Tự động hóa phục hồi theo lớp: AWS kích hoạt hệ thống multi-layer mitigation, xử lý từ tầng DNS → EC2 → Network Load Balancer → Lambda → backlog.
  • Giảm tải có kiểm soát (graceful degradation): AWS chủ động throttle tạm thời các tiến trình tạo tải cao như EC2 launch và Lambda SQS polling để duy trì khả năng phản hồi trong giai đoạn chưa ổn định.
  • Khôi phục có trình tự: Thay vì reset toàn vùng, AWS ưu tiên khôi phục các subsystem cốt lõi như DNS, NLB health, và EC2 orchestration trước khi dỡ throttle.
  • Theo dõi và minh bạch: Mỗi 30–45 phút, AWS đều cập nhật chi tiết tiến độ phục hồi trên trang trạng thái, thông báo rõ từng lớp dịch vụ đang được xử lý, toàn bộ quá trình tại https://health.aws.amazon.com/health/status.

7. Thủ tục xử lý triệt để

  • AWS cam kết sẽ thực hiện “Post-Event Summary” công khai (PES) — cung cấp chi tiết nguyên nhân, ảnh hưởng và biện pháp. Amazon Web Services, Inc.+1

  • Rà soát lại các hệ thống cân bằng tải, mạng nội bộ, vùng dữ liệu lớn (US-EAST-1) và các dependency vượt chéo giữa vùng (region) để tránh phụ thuộc quá tập trung.

  • Đánh giá lại thiết kế kiến trúc khách hàng (end-users) sử dụng AWS: khuyến nghị đa vùng (multi-region), đa nhà cung cấp (multi-cloud) để giảm rủi ro tập trung vào một vùng bị sự cố.

  • Cập nhật quy trình vận hành & khôi phục (disaster recovery / fail-over) cho các hệ thống phụ thuộc AWS.

8. Bài học kinh nghiệm

  • Sự cố cho thấy phụ thuộc mạnh vào một vùng dịch vụ lớn (US-EAST-1) là rủi ro: khi vùng đó bị sự cố, ảnh hưởng lan rất rộng.

  • Các hệ thống nội bộ hạ tầng (như cân bằng tải, mạng nội bộ) khi gặp lỗi sẽ gây hiệu ứng dây chuyền lên nhiều dịch vụ phụ thuộc rất đa dạng.

  • Cần thiết lập cảnh báo & giám sát ở mức rất cao cho những thành phần “chủ chốt” trong hạ tầng (như mạng nội bộ, load balancer, DNS) mà không chỉ dịch vụ ứng dụng.

  • Thiết kế kiến trúc ứng dụng không nên chỉ dựa vào một nhà cung cấp, một vùng duy nhất, mà cần đa vùng, đa nhà cung cấp.

  • Trong vận hành sự cố, phản ứng nhanh và thông tin minh bạch giúp giảm thiểu ảnh hưởng tới khách hàng & uy tín.

9. Biện pháp phòng ngừa từ sớm, từ xa để đảm bảo an toàn hệ thống, kiểm soát tốt/chặt chẽ rủi ro

  • Áp dụng kiến trúc Multi-Region: khách hàng nên thiết kế ứng dụng tại ít nhất 2 vùng AWS khác nhau, hoặc sử dụng nhà cung cấp cloud phụ trợ.

  • Thiết lập Multi-Cloud hoặc Hybrid-Cloud để tránh rủi ro phụ thuộc vào một nhà cung cấp duy nhất.

  • Giám sát hệ thống mạng nội bộ, load balancer, DNS bên trong cloud provider và bên ngoài: đặt cảnh báo sớm cho các thông số như error rate, latency, drop/mis-route.

  • Thực hiện định kỳ kiểm thử “failover test” và “chaos engineering” (simulate failure) để đánh giá khả năng phục hồi khi một vùng hoặc component chủ chốt gặp sự cố.

  • Xây dựng kế hoạch liên tục kinh doanh và phục hồi thảm họa (Business Continuity & Disaster Recovery – BCDR) rõ ràng, có kịch bản cho tình huống nhà cung cấp cloud lớn gặp sự cố.

  • Đánh giá & quản lý rủi ro theo ITSM/ITIL: xác định các cấu phần hạ tầng có rủi ro cao (single-point-of-failure) và đưa vào danh sách ưu tiên cho đầu tư, kiểm soát, backup.

  • Giao tiếp rõ ràng với khách hàng/đối tác khi có sự cố: cung cấp cập nhật thực tế, thời gian ước tính khôi phục, và ảnh hưởng (impact) để giảm lo ngại về uy tín.

  • Trong hợp đồng với nhà cung cấp cloud: xem xét điều khoản SLA, đền bù khi xảy ra sự cố, và đảm bảo có phương án khắc phục/thay thế nhanh.

Kết luận: Sự cố này một lần nữa nhấn mạnh tầm quan trọng của việc thiết kế hệ thống phân tán, có khả năng chịu lỗi (resilience). Đối với các kỹ sư DevOps, bài học lớn nhất là "Luôn có kế hoạch cho thất bại (Always have a plan for failure)", ngay cả khi bạn đang sử dụng hạ tầng cloud hàng đầu thế giới.

Tham khảo thêm:

=============================
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội

=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
By lúc
Labels: , ,

ĐỌC NHIỀU
Trần Văn Bình - Oracle Database Master