AWS Study Group

Khôi phục toàn diện từ các sự cố AZ trong Amazon EKS bằng EKS Zonal shift và Istio

Tác giả: Moe Wahidi và Hemal Gadhiya
Ngày phát hành: 20 JAN 2026
Chuyên mục: Amazon Elastic Kubernetes Service, Containers

Điều gì sẽ xảy ra khi một trong các Availability Zones (AZs) của bạn bắt đầu hoạt động không ổn định, nhưng không hoàn toàn bị lỗi? Hãy hình dung thế này: cụm Amazon Elastic Kubernetes Service (Amazon EKS) của bạn đang hoạt động trơn tru trên ba Availability Zones thì đột nhiên, một Availability Zone bắt đầu gặp phải tình trạng suy giảm hiệu suất tinh vi—không phải là một sự cố ngừng hoạt động hoàn toàn, nhưng đủ để khiến khách hàng của bạn thất vọng với thời gian phản hồi chậm hơn và các lỗi không liên tục. Kịch bản này đại diện cho một trong những vấn đề thách thức nhất trong kiến trúc đám mây hiện đại: lỗi xám (gray failures). Không giống như các lỗi nhị phân, nơi các dịch vụ rõ ràng là hoạt động hoặc ngừng hoạt động, lỗi xám tạo ra một vùng trung gian mờ mịt nơi một Availability Zone có vẻ khỏe mạnh đối với hệ thống giám sát của bạn nhưng lại mang lại trải nghiệm khách hàng bị suy giảm. Các kiểm tra sức khỏe của Kubernetes của bạn vẫn vượt qua, các pod của bạn vẫn chạy, nhưng người dùng của bạn đang âm thầm chịu đựng.

Giải pháp là gì? Khôi phục toàn diện từ các sự cố Availability Zone nhằm chuyển đổi lưu lượng truy cập một cách thích hợp trên cả ba chiều của các mô hình giao tiếp ứng dụng của bạn. Bạn cần chuyển đổi lưu lượng truy cập Bắc-Nam (north-south) rõ ràng đi vào cụm của bạn và giao tiếp dịch vụ-đến-dịch vụ Đông-Tây (east-west) trong cụm của bạn. Hơn nữa, bạn cần chuyển đổi lưu lượng truy cập đi thường bị bỏ qua đến các phụ thuộc bên ngoài như Amazon Relational Database Service (Amazon RDS).

Đây là nơi điều kỳ diệu xảy ra: Amazon Application Recovery Controller (ARC) zonal shift cho Network Load Balancer (NLB) cung cấp một cơ chế để chuyển hướng các yêu cầu bên ngoài ra khỏi các Availability Zones bị ảnh hưởng. Việc bật Zonal shift trong các cụm EKS xử lý lưu lượng truy cập Kubernetes Đông-Tây nội bộ của bạn, trong khi lưới dịch vụ Istio mở rộng khả năng quản lý lưu lượng truy cập của bạn đến các dịch vụ bên ngoài thông qua các tài nguyên ServiceEntry. Cùng nhau, chúng tạo ra một mạng lưới an toàn toàn diện có thể chuyển đổi lưu lượng truy cập một cách duyên dáng ra khỏi toàn bộ Availability Zone khi mọi thứ trở nên tồi tệ—trước khi khách hàng kịp nhận ra.

Giám sát hiệu quả là rất quan trọng để phát hiện khi một Availability Zone đang gặp phải tình trạng suy giảm, đặc biệt đối với các lỗi xám không kích hoạt các kiểm tra sức khỏe tiêu chuẩn. Các tổ chức có thể giám sát các chỉ số quan trọng đối với doanh nghiệp và thiết lập các kỳ vọng hiệu suất cơ bản để xác định các suy giảm tinh vi và khởi tạo các quy trình để chuyển đổi lưu lượng truy cập ra khỏi các AZ bị ảnh hưởng trước khi tác động đến khách hàng trở nên nghiêm trọng. Mặc dù giám sát là yếu tố cần thiết cho quá trình này, bài đăng này tập trung cụ thể vào chiến lược chuyển đổi lưu lượng truy cập hơn là việc triển khai giám sát. Để có hướng dẫn toàn diện về việc xây dựng một giải pháp giám sát mạnh mẽ để phát hiện các AZ không khỏe mạnh hoặc bị ảnh hưởng, hãy tham khảo bài đăng đi kèm của chúng tôi: Giám sát và tự động hóa khôi phục từ các sự cố AZ trong Amazon EKS với Istio và ARC Zonal Shift

Trong bài đăng này, chúng tôi sẽ hướng dẫn bạn xây dựng hệ thống khôi phục toàn diện này, chỉ cho bạn chính xác cách cấu hình chuyển đổi lưu lượng truy cập để bảo vệ ứng dụng của bạn khỏi các sự cố Availability Zone trong khi vẫn duy trì tính sẵn sàng cao mà doanh nghiệp của bạn yêu cầu.

Tổng quan giải pháp

Trong bài đăng này, chúng tôi sẽ hướng dẫn bạn một sổ tay vận hành toàn diện sử dụng lưới dịch vụ Istio và ARC zonal shift cho NLB và Amazon EKS để cung cấp hoạt động không bị gián đoạn khi một Availability Zone đang gặp sự cố. Cách tiếp cận của chúng tôi giải quyết cả ba mô hình lưu lượng truy cập quan trọng: lưu lượng truy cập vào Bắc-Nam, giao tiếp dịch vụ-đến-dịch vụ Đông-Tây và lưu lượng truy cập đi đến các phụ thuộc bên ngoài. Điều này tạo ra một khuôn khổ hoàn chỉnh để duy trì hiệu suất và độ tin cậy của ứng dụng trong các gián đoạn Availability Zone. Để minh họa, chúng tôi đã tạo một ứng dụng được triển khai trên ba Availability Zones, thể hiện cả ba mô hình lưu lượng truy cập mà chúng tôi cần quản lý trong quá trình sự cố Availability Zone. Điều này được thể hiện trong kiến trúc được mô tả trong hình sau.

Môi trường minh họa bao gồm những điều sau:

  1. Hai microservice được triển khai trên ba AZ trong Amazon EKS:
    • Dịch vụ Frontend: Một dịch vụ frontend được tiếp xúc với internet thông qua NLB
    • Dịch vụ DB-info: Một dịch vụ backend kết nối với cơ sở dữ liệu Amazon Aurora MySQL-Compatible Edition
    • Lưới dịch vụ Istio chạy ở chế độ sidecar: Mỗi pod có một container Istio sidecar (proxy Envoy). Điều này kiểm soát và quản lý giao tiếp dịch vụ-đến-dịch vụ và kiểm soát lưu lượng truy cập đi đến các phụ thuộc bên ngoài. Chế độ Ambient cũng có thể được sử dụng với các hỗ trợ gần đây cho DestinationRule và ServiceEntries.
  2. Cụm Amazon Aurora MySQL với ba bản sao đọc:
    • Một bản sao đọc được triển khai trong mỗi Availability Zone
    • Một điểm cuối cụm cho các hoạt động ghi
    • Các điểm cuối đọc cho các hoạt động đọc


Hình 1: Kiến trúc khôi phục sự cố AZ từ đầu đến cuối

Điều kiện tiên quyết

Các điều kiện tiên quyết sau đây là cần thiết để hoàn thành giải pháp này:

Hướng dẫn chi tiết

Các bước sau đây sẽ hướng dẫn bạn qua giải pháp và cách triển khai.

Tạo cụm Aurora với ba điểm cuối đọc, mỗi điểm trong một Availability Zone khác nhau

Tham khảo tài liệu Tạo và kết nối với cụm DB Aurora MySQL. Để tạo bản sao đọc, tham khảo tài liệu Tạo bản sao đọc cho Aurora MySQL.

Tạo cụm EKS ba node trong ba Availability Zone khác nhau

Bạn có thể sử dụng Amazon EKS Blueprints for Terraform để triển khai cụm EKS. Tham khảo mô hình Istio sidecar để biết mã Terraform. Điều này triển khai bộ điều khiển Istio và Istio ingress được hỗ trợ bởi NLB.

Triển khai Istio Gateway, VirtualService và ứng dụng mẫu

Clone kho lưu trữ sample-eks-az-traffic-shift và thực hiện các bước từ 1 đến 5 trong phần quick start của readme.md.

git clone https://github.com/aws-samples/sample-eks-az-traffic-shift.git
cd sample-eks-az-traffic-shift

Khi chúng ta truy cập dịch vụ frontend thông qua NLB, nó thực hiện các hoạt động sau:

  • Trả về thông tin về Availability Zone mà nó hiện đang chạy
  • Thực hiện 10 cuộc gọi đến Dịch vụ DB-Info
  • Đối với mỗi cuộc gọi, nó hiển thị Availability Zone mà Dịch vụ DB-Info đã phản hồi
  • Nó hiển thị thông tin kết nối cơ sở dữ liệu, bao gồm bản sao cơ sở dữ liệu Availability Zone nào đã được sử dụng

Sơ đồ sau đây cho thấy luồng yêu cầu trong kịch bản bình thường. Yêu cầu đầu tiên được nhận trong Availability Zone us-east-1a bởi dịch vụ frontend, và nó thực hiện 10 cuộc gọi đến Dịch vụ DB-Info. Nếu bạn nhìn vào cuộc gọi đầu tiên, thì nó được nhận trong Availability Zone us-east-1c bởi Dịch vụ DB-Info. Sau đó, Dịch vụ DB-Info kết nối với điểm cuối Aurora, là reader-1 trong Availability Zone us-east-1a.


Hình 2: Luồng yêu cầu bình thường qua các Availability Zone

Sổ tay vận hành chuyển đổi lưu lượng theo vùng

Bạn sẽ thực hiện bước 6 trong phần quick start của readme.md.

Trong điều kiện tiêu chuẩn, lưu lượng truy cập chảy đến các pod kết nối với các điểm cuối đọc cơ sở dữ liệu của cụm. Nếu không có bất kỳ quy tắc chuyển đổi lưu lượng truy cập nào, lưu lượng truy cập tự nhiên phân phối trên các pod và các điểm cuối đọc cơ sở dữ liệu trong tất cả các Availability Zones có sẵn. Trong trường hợp một Availability Zone bị ảnh hưởng hoặc hiệu suất suy giảm, chúng ta muốn chuyển đổi lưu lượng truy cập ra khỏi Availability Zone đó. Cách tiếp cận toàn diện này tạo ra một mô hình cách ly lưu lượng truy cập hoàn chỉnh, để cả các pod và các điểm cuối cơ sở dữ liệu trong Availability Zone bị ảnh hưởng đều không nhận được bất kỳ lưu lượng truy cập nào trong sự cố. Trong các phần sau, chúng ta sẽ đi sâu vào chi tiết về cách chúng ta có thể đạt được điều đó.

1. Zonal shift

Bạn có thể sử dụng zonal shift để tạm thời chuyển đổi lưu lượng truy cập ra khỏi một Availability Zone bị ảnh hưởng. Tính năng này rất quan trọng để xử lý cả lưu lượng truy cập vào Bắc-Nam và giao tiếp dịch vụ-đến-dịch vụ Đông-Tây trong cụm EKS của bạn.

Đối với NLB (lưu lượng Bắc-Nam): Trong ứng dụng minh họa của chúng tôi, điểm vào cho người dùng bên ngoài là một NLB phân phối lưu lượng truy cập đến dịch vụ frontend của chúng tôi trên ba Availability Zones. Khi bạn khởi tạo zonal shift cho NLB của mình trong một Availability Zone cụ thể, ARC sẽ đánh dấu node NLB trong Availability Zone đó là không khỏe mạnh, và nó sẽ bị xóa khỏi DNS của bộ cân bằng tải. NLB ngừng định tuyến lưu lượng truy cập đến các đích trong Availability Zone bị ảnh hưởng. Điều này đảm bảo rằng người dùng bên ngoài truy cập ứng dụng của bạn thông qua NLB không được chuyển hướng đến vùng bị suy giảm.

Sơ đồ sau đây cho thấy các chỉ số byte đã xử lý cho NLB trong mỗi Availability Zone trước và sau khi bắt đầu zonal shift. Chúng tôi đã bắt đầu zonal shift trong Availability Zone us-east-1a, và có thể thấy rằng các byte đã xử lý trong Availability Zone us-east-1a sau đó đã giảm xuống 0.


Hình 3: Các chỉ số byte đã xử lý của NLB trong quá trình zonal shift

Đối với Amazon EKS (lưu lượng Đông-Tây): Trong ứng dụng minh họa của chúng tôi, dịch vụ frontend giao tiếp với Dịch vụ DB-Info thông qua khám phá dịch vụ Kubernetes tiêu chuẩn. Nhiều pod Dịch vụ DB-Info được triển khai trên các Availability Zones và được tiếp xúc thông qua một dịch vụ Kubernetes ClusterIP.

Trong các hoạt động bình thường, Kubernetes sử dụng EndpointSlices để duy trì danh sách động các địa chỉ IP của pod cho mỗi dịch vụ. Bộ điều khiển EndpointSlice liên tục cập nhật các danh sách này khi các pod được tạo, sửa đổi hoặc chấm dứt. Khi một yêu cầu dịch vụ được thực hiện, kube-proxy trên mỗi node sử dụng thông tin này để định tuyến lưu lượng truy cập đến một trong các điểm cuối pod có sẵn.

Khi bạn khởi tạo Amazon EKS zonal shift cho cụm EKS của mình, bạn chỉ định cả cụm và Availability Zone mà bạn muốn chuyển đổi lưu lượng truy cập ra khỏi. Điều này kích hoạt một tập hợp các hành động phối hợp được thiết kế để chuyển hướng lưu lượng truy cập một cách duyên dáng ra khỏi vùng bị ảnh hưởng. Cơ chế chuyển hướng lưu lượng truy cập hoạt động thông qua hệ thống EndpointSlice, nơi bộ điều khiển EndpointSlice xác định một cách có hệ thống tất cả các pod nằm trong Availability Zone bị ảnh hưởng và xóa các điểm cuối pod này khỏi các EndpointSlices tương ứng của chúng. Do đó, lưu lượng dịch vụ tự động được chuyển hướng đến các pod chỉ chạy trong các Availability Zones khỏe mạnh, trong khi kube-proxy cập nhật các bảng định tuyến của nó để phản ánh cấu hình điểm cuối mới. Là một phần của quy trình quản lý node, tất cả các node trong Availability Zone mục tiêu ngay lập tức được cordoned để ngăn chặn việc lập lịch pod mới. Đối với các nhóm node được quản lý, việc cân bằng lại Availability Zone bị tạm dừng để duy trì phân phối dung lượng thích hợp, và Auto Scaling Groups được cập nhật để xác minh rằng các node mới chỉ khởi chạy trong các Availability Zones khỏe mạnh. Các node và pod trong Availability Zone mà bạn đang chuyển đổi ra khỏi không bị xóa. Điều này đảm bảo rằng khi zonal shift hết hạn hoặc bị hủy, lưu lượng truy cập của bạn có thể an toàn quay trở lại Availability Zone có đầy đủ dung lượng. Cách tiếp cận được phối hợp này xác minh rằng giao tiếp dịch vụ-đến-dịch vụ nội bộ tránh được Availability Zone bị ảnh hưởng một cách liền mạch trong khi vẫn duy trì tính sẵn sàng và hiệu suất của ứng dụng. Bản chất dần dần của quá trình này ngăn chặn sự gián đoạn dịch vụ trong khi cách ly hiệu quả Availability Zone bị suy giảm khỏi luồng lưu lượng truy cập ứng dụng của bạn. Sơ đồ sau đây cho thấy yêu cầu được thực hiện bởi dịch vụ frontend đến Dịch vụ DB-Info sau khi zonal shift cho Amazon EKS được khởi tạo trong Availability Zone us-east-1a. Không có yêu cầu nào được gửi đến Availability Zone us-east-1a từ dịch vụ frontend.

EKS zonal shift traffic redirection
Hình 4: Chuyển hướng lưu lượng truy cập EKS zonal shift

Sơ đồ sau đây cho thấy EndpointSlices cho Dịch vụ DB-Info trước và sau khi zonal shift được khởi tạo. Trước khi zonal shift, có ba điểm cuối, mỗi điểm trong một Availability Zone. Sau khi khởi tạo zonal shift, điểm cuối trong Availability Zone us-east-1a đã bị xóa khỏi EndpointSlice.


Hình 5: EndpointSlices trước và sau khi zonal shift

Sự kết hợp của NLB và Amazon EKS zonal shifts đảm bảo rằng cả lưu lượng truy cập vào cụm EKS và giao tiếp dịch vụ nội bộ của cụm đều tránh vùng bị ảnh hưởng. Điều này tạo ra một rào cản toàn diện chống lại hiệu suất suy giảm.

Lưu lượng truy cập bên ngoài rời khỏi cụm EKS đến các điểm cuối đọc vẫn đang được gửi đến ba Availability Zones. Đây là nơi lưới dịch vụ Istio phát huy tác dụng.

2. Istio service mesh để quản lý lưu lượng truy cập đi

Mặc dù zonal shift xử lý lưu lượng truy cập vào và Đông-Tây một cách hiệu quả, nhưng nó không kiểm soát các kết nối đi từ các dịch vụ Amazon EKS của bạn đến các phụ thuộc bên ngoài như Amazon RDS hoặc các dịch vụ được truy cập thông qua AWS PrivateLink. Đây là lý do tại sao lưới dịch vụ Istio trở nên thiết yếu đối với chiến lược chuyển đổi lưu lượng truy cập theo vùng của chúng tôi.

Trong bài đăng này, chúng tôi đang minh họa việc sử dụng cơ sở dữ liệu Aurora, vì vậy lưới dịch vụ Istio đảm bảo rằng lưu lượng truy cập không được định tuyến đến bất kỳ phiên bản đọc nào trong Availability Zone không khỏe mạnh mà chúng tôi đang chuyển đổi lưu lượng truy cập ra khỏi. Istio cung cấp hai tính năng chính cho phép quản lý lưu lượng truy cập đi nhận biết Availability Zone.

ServiceEntry cho các phụ thuộc bên ngoài: Bạn có thể sử dụng tài nguyên ServiceEntry của Istio để đưa các dịch vụ bên ngoài vào quyền kiểm soát quản lý lưu lượng truy cập của Istio bằng cách định nghĩa chúng là một phần của registry lưới dịch vụ. Khả năng này đặc biệt có giá trị đối với bất kỳ dịch vụ bên ngoài nào tiếp xúc các điểm cuối cụ thể theo Availability Zone, chẳng hạn như các bản sao đọc Amazon RDS, hoặc các ứng dụng tùy chỉnh được triển khai với các điểm cuối riêng tư cụ thể theo vùng. Đối với minh họa cơ sở dữ liệu Aurora của chúng tôi, chúng tôi cấu hình ServiceEntry để đại diện cho mỗi điểm cuối đọc cụ thể theo Availability Zone như một đích riêng biệt với thông tin vị trí.

DestinationRule với các ưu tiên vị trí: Bạn có thể sử dụng các quy tắc này để định nghĩa các chính sách lưu lượng truy cập áp dụng cho lưu lượng truy cập dành cho một dịch vụ. Thông qua các chính sách này, bạn có thể bật localityLbSetting, ưu tiên định tuyến lưu lượng truy cập dựa trên sự gần gũi về địa lý: đầu tiên trong cùng một khu vực, sau đó trong cùng một vùng. Trong Kubernetes, nhãn topology.kubernetes.io/zone xác định vùng của một node và nhãn topology.kubernetes.io/region xác định khu vực. Bạn có thể sử dụng các nhãn vị trí này để đảm bảo rằng các kết nối cơ sở dữ liệu từ các pod ưu tiên kết nối với các bản sao trong cùng một Availability Zone. Hơn nữa, trong quá trình chuyển đổi lưu lượng truy cập, điều này có nghĩa là hoàn toàn tránh vùng bị ảnh hưởng.


Hình 6: Cấu hình Istio ServiceEntry và DestinationRule

Chúng tôi kết hợp ServiceEntry và DestinationRule lại với nhau để tạo ra một hệ thống quản lý lưu lượng truy cập đi toàn diện, đưa các phụ thuộc bên ngoài cho các điểm cuối đọc Aurora vào quyền kiểm soát của Istio. Hơn nữa, nó áp dụng các chính sách định tuyến thông minh dựa trên vị trí, cung cấp phạm vi chuyển đổi lưu lượng truy cập theo vùng hoàn chỉnh. Sơ đồ sau đây minh họa cách cấu hình Istio ServiceEntry và DestinationRule cho phép định tuyến nhận biết vị trí, nơi các yêu cầu từ Dịch vụ DB-Info được chuyển hướng đến các điểm cuối đọc Aurora trong cùng một Availability Zone.

Locality-aware routing with Istio
Hình 7: Định tuyến nhận biết vị trí với Istio

3. Điểm cuối ghi của Aurora

Đối với phiên bản ghi của Aurora, và nếu nó nằm trong Availability Zone không tốt, sổ tay vận hành phải chuyển đổi dự phòng nó để một bản sao Aurora (reader) có sẵn trong Availability Zone khỏe mạnh khác được thăng cấp thành phiên bản DB chính mới. Để biết thêm thông tin, hãy tham khảo Chuyển đổi dự phòng cụm DB Amazon Aurora.

Khôi phục hoạt động bình thường sau khi sự cố Availability Zone được giải quyết

Quá trình này sẽ chỉ được khởi tạo sau khi xác nhận rằng Availability Zone bị ảnh hưởng trước đó đã trở lại trạng thái khỏe mạnh. Quy trình giả định rằng lưu lượng mạng tiếp tục các mô hình định tuyến bình thường khớp với những gì đã có trước khi quy trình chuyển đổi lưu lượng truy cập theo vùng được chạy. Trước khi tiếp tục, hãy xác minh những điều sau:

  • Availability Zone bị ảnh hưởng trước đó hiển thị các chỉ số sức khỏe bình thường
  • AWS đã xác nhận giải quyết mọi vấn đề cơ sở hạ tầng cơ bản
  • Hệ thống giám sát của bạn cho thấy các điều kiện ổn định trong Availability Zone bị ảnh hưởng

Khi điều này được xác nhận, bạn có thể đảo ngược các biện pháp chuyển đổi lưu lượng truy cập theo vùng bằng cách chạy những điều sau:

  • Xóa Istio DestinationRule và ServiceEntry. Tham khảo bước đầu tiên trong phần Cleaning up.
  • Hủy NLB và Amazon EKS zonal shift.

Dọn dẹp tài nguyên

Khi bạn đã hoàn tất việc kiểm tra giải pháp, hãy làm theo các bước sau để dọn dẹp tài nguyên và tránh phát sinh các khoản phí AWS không cần thiết:

  1. Xóa cụm Amazon Aurora
  2. Xóa tài nguyên ứng dụng
  3. Xóa cụm EKS

Kết luận

Xây dựng các ứng dụng linh hoạt trên đám mây đòi hỏi một cách tiếp cận toàn diện để giải quyết mọi khía cạnh của luồng lưu lượng truy cập trong quá trình gián đoạn cơ sở hạ tầng. Thông qua minh họa này, chúng tôi đã chỉ ra cách kết hợp các khả năng Amazon Application Recovery Controller (ARC) zonal shift với lưới dịch vụ Istio tạo ra một chiến lược chuyển đổi lưu lượng truy cập theo vùng hoàn chỉnh, xử lý liền mạch cả ba mô hình lưu lượng truy cập quan trọng. Kết hợp Amazon Application Recovery Controller zonal shift với lưới dịch vụ Istio tạo ra khả năng khôi phục sự cố AZ toàn diện. Giải pháp tích hợp này chuyển hướng lưu lượng truy cập Bắc-Nam, Đông-Tây và lưu lượng truy cập đi ra khỏi các vùng bị suy giảm, biến phản ứng khủng hoảng thủ công thành khả năng phục hồi tự động.

Sẵn sàng triển khai giải pháp này? Bắt đầu với các tài nguyên thiết yếu sau:

Về tác giả


Moe Wahidi là Quản lý Tài khoản Kỹ thuật Cấp cao tại Amazon Web Services, có trụ sở tại California. Anh chuyên về container, mạng và các hệ thống phân tán. Với hơn 20 năm kinh nghiệm trong phát triển phần mềm, kỹ thuật mạng, kỹ thuật hệ thống và DevOps, Moe mang đến chuyên môn sâu rộng về các hệ thống và cơ sở hạ tầng doanh nghiệp. Anh thích hướng dẫn các đồng nghiệp trong các lĩnh vực chuyên môn của mình, đặc biệt là công nghệ container.


Hemal Gadhiya là Kiến trúc sư Giải pháp Cấp cao thuộc Nhóm Kỹ thuật Đám mây và Tạo mẫu trong AWS Global Financial Services (GFS), nơi anh làm việc dựa trên nhu cầu của khách hàng để xây dựng các giải pháp đám mây sáng tạo. Anh chuyên về kiến trúc linh hoạt, các mô hình khôi phục sau thảm họa và đảm bảo tính liên tục trong kinh doanh cho các tổ chức tài chính trên AWS.

←
→

Leave a comment