Vào ngày 21 tháng 8 năm 2025, mô hình lưu lượng truy cập bất thường của một khách hàng đã làm gián đoạn kết nối giữa Cloudflare và khu vực us-east-1 của Amazon Web Services trong gần bốn giờ. Sự cố này đã gây ra cuộc thảo luận sôi nổi trong cộng đồng công nghệ về việc lập kế hoạch dung lượng mạng, cách ly khách hàng và tính dễ vỡ của cơ sở hạ tầng internet.
Sự cố bắt đầu khi một khách hàng bắt đầu thực hiện các yêu cầu lớn đối với nội dung được lưu trong bộ nhớ đệm từ AWS us-east-1, tạo ra lưu lượng phản hồi làm bão hòa hoàn toàn tất cả các kết nối trực tiếp giữa hai gã khổng lồ công nghệ này. Điều làm cho sự cố này đặc biệt nghiêm trọng là luồng lưu lượng đi từ Cloudflare đến AWS , có nghĩa là Cloudflare về cơ bản đang làm tràn ngập các liên kết mạng của chính mình với các phản hồi đối với các yêu cầu hợp lệ.
Dòng thời gian sự cố
- 16:27 UTC: Lưu lượng truy cập tăng đột biến, tăng gấp đôi tổng lưu lượng từ Cloudflare đến AWS
- 16:57 UTC: AWS bắt đầu rút các tiền tố BGP trên các đường truyền bị tắc nghẽn
- 17:22 UTC: Việc rút BGP tăng lưu lượng bị mất và tác động
- 19:05 UTC: Giới hạn tốc độ của khách hàng có vấn đề làm giảm tắc nghẽn
- 19:27 UTC: Các hành động kỹ thuật lưu lượng giải quyết tắc nghẽn
- 20:07 UTC: AWS hoàn tất khôi phục tiền tố BGP
- Tổng thời gian: ~3 giờ 40 phút
 |
|---|
| Bài đăng blog này nêu ra sự cố nghiêm trọng khi các mẫu lưu lượng truy cập bất thường dẫn đến các vấn đề kết nối giữa Cloudflare và AWS , gây ra các cuộc thảo luận về độ tin cậy của hạ tầng |
Thách thức triển khai kỹ thuật
Cộng đồng đã tích cực thảo luận về cách Cloudflare có thể ngăn chặn các sự cố tương tự trong tương lai. Giải pháp được đề xuất về ngân sách lưu lượng cho từng khách hàng nghe có vẻ đơn giản, nhưng việc triển khai lại phức tạp. Việc xử lý các gói tin để xác định chúng thuộc về khách hàng nào trước khi loại bỏ chúng thực tế có thể chậm hơn so với việc chỉ chuyển tiếp chúng, đặc biệt là khi hàng đợi của bộ định tuyến biên đã đầy.
Tuy nhiên, trường hợp cụ thể này cung cấp một con đường rõ ràng hơn để tiến lên phía trước. Vì vấn đề là các phản hồi của Cloudflare chứ không phải các yêu cầu đến, công ty có thể đơn giản ngừng gửi phản hồi hoặc trả về mã HTTP 429 (giới hạn tốc độ) khi khách hàng vượt quá phân bổ của họ. Các hệ thống Linux hiện đại cũng có thể sử dụng chương trình BPF-XDP để loại bỏ lưu lượng ở cấp độ trình điều khiển trước khi có bất kỳ xử lý đáng kể nào xảy ra.
Các Biện Pháp Giảm Thiểu Đã Lên Kế Hoạch
- Ngắn hạn: Giảm ưu tiên lưu lượng có chọn lọc đối với các khách hàng gây tắc nghẽn
- Trung hạn: Nâng cấp nhanh dung lượng Data Center Interconnect ( DCI )
- Dài hạn: Hệ thống quản lý lưu lượng nâng cao với ngân sách tài nguyên cho từng khách hàng
- Phối hợp: Cải thiện phối hợp kỹ thuật lưu lượng BGP với AWS
Kiểm tra thực tế cơ sở hạ tầng
Sự cố đã làm nổi bật việc dung lượng backbone internet có thể bị hạn chế một cách đáng ngạc nhiên, ngay cả giữa các nhà cung cấp lớn. Trong khi các ISP nhỏ hơn có thể hoạt động chỉ với kết nối 10 Gbps đến các đối tác peering, liên kết Cloudflare - AWS về mặt lý thuyết nên có dung lượng cao hơn nhiều. Tuy nhiên, cộng đồng lưu ý rằng ngay cả với nhiều kết nối 100 Gbps, một khách hàng quyết tâm có quyền truy cập vào tài nguyên tính toán khổng lồ của AWS có khả năng tạo ra đủ lưu lượng để gây tắc nghẽn.
Thật điên rồ khi lưu lượng cache-hit của một tenant có thể làm đổ dung lượng kết nối của Cloudflare
Tình hình trở nên tồi tệ hơn do một loạt vấn đề: một liên kết peering trực tiếp đã hoạt động ở một nửa dung lượng do lỗi có từ trước, và khi AWS tự động rút một số tuyến mạng để giảm tắc nghẽn, lưu lượng được chuyển hướng đến các kết nối dự phòng không thể xử lý được tải.
 |
|---|
| Sơ đồ kỹ thuật cho thấy luồng dữ liệu giữa các trung tâm dữ liệu của Cloudflare và AWS , mô tả trực quan các tương tác đã góp phần vào sự cố kết nối ngày 21 tháng 8 năm 2025 |
Mô hình lỗi Swiss Cheese
Sự cố này minh họa cho những gì các kỹ sư gọi là lỗi Swiss Cheese - nhiều vấn đề nhỏ kết hợp với nhau để tạo ra một sự cố lớn. Cloudflare đã quen với việc các kết nối peering lớn của họ hoạt động đáng tin cậy, có khả năng dẫn đến sự tự mãn về việc duy trì các hệ thống dự phòng và giải quyết kịp thời các liên kết thứ cấp bị suy giảm.
Cuộc thảo luận của cộng đồng tiết lộ rằng việc rút tuyến của AWS có khả năng được tự động hóa, được thiết kế để phát hiện tắc nghẽn và tự động giảm lưu lượng. Mặc dù điều này thường hoạt động tốt, nhưng nó phản tác dụng khi các tuyến dự phòng có dung lượng không đủ, biến một vấn đề có thể quản lý thành một sự cố lan rộng.
Các Yếu Tố Kỹ Thuật Góp Phần Gây Ra Sự Cố
- Lưu lượng truy cập đột biến từ một khách hàng duy nhất từ AWS us-east-1 đến Cloudflare
- Một đường kết nối peering trực tiếp chỉ hoạt động ở 50% công suất do lỗi từ trước
- Dung lượng Data Center Interconnect ( DCI ) không đủ cho lưu lượng được chuyển hướng
- Hệ thống tự động rút các tuyến đường BGP của AWS đã chuyển hướng lưu lượng đến các đường dự phòng bị quá tải
- Cần can thiệp thủ công để giới hạn tốc độ và điều chỉnh lưu lượng
Nhìn về phía trước
Cloudflare đã phác thảo cả giải pháp ngắn hạn và dài hạn, bao gồm phát triển các cơ chế để giảm ưu tiên có chọn lọc lưu lượng có vấn đề và xây dựng các hệ thống quản lý lưu lượng nâng cao với phân bổ tài nguyên cho từng khách hàng. Công ty cũng đang làm việc với AWS để đảm bảo các hệ thống kỹ thuật lưu lượng tự động của họ không xung đột với nhau trong các sự cố tương lai.
Bài học rộng lớn hơn cho cộng đồng cơ sở hạ tầng internet là rõ ràng: khi điện toán đám mây cho phép khách hàng tạo ra lượng lưu lượng chưa từng có theo yêu cầu, các nhà cung cấp phải xây dựng các hệ thống cách ly và giới hạn tốc độ tinh vi hơn. Những ngày chỉ đơn giản cung cấp các đường ống lớn và hy vọng điều tốt nhất có thể sắp kết thúc.
Tham khảo: Sự cố Cloudflare vào ngày 21 tháng 8 năm 2025
 |
|---|
| Kính lúp tượng trưng cho cam kết của Cloudflare trong việc xem xét kỹ lưỡng và cải thiện các hệ thống quản lý lưu lượng truy cập để ngăn chặn các sự cố mất kết nối trong tương lai và tăng cường khả năng phục hồi của cơ sở hạ tầng |