Tác giả: Ivo Kammerath, Lars Reimann, Michael Hanisch, và Stephan Schiller
Ngày phát hành: 30 THÁNG 1 2026
Chuyên mục: AWS Identity and Access Management (IAM), AWS Organizations, Best Practices, Intermediate (200)

Các tổ chức hoạt động trên nhiều khu vực pháp lý cần xem xét tác động của các thay đổi quy định hoặc sự kiện địa chính trị đối với quyền truy cập vào cơ sở hạ tầng đám mây của họ. Bài viết này giải thích cách thiết kế kiến trúc chuyển đổi dự phòng (failover) trải rộng các phân vùng (partition) của AWS—bao gồm AWS European Sovereign Cloud, AWS GovCloud (US) và các AWS Region khác trong cơ sở hạ tầng toàn cầu — để các workload có thể tiếp tục hoạt động khi các yêu cầu về chủ quyền thay đổi.

Mặc dù AWS European Sovereign Cloud được thiết kế để giúp khách hàng đáp ứng các yêu cầu về quyền tự chủ vận hành và lưu trú dữ liệu, nhưng nó cũng có thể được sử dụng để giải quyết các rủi ro địa chính trị và chủ quyền rộng hơn. Bài viết này khám phá các mẫu kiến trúc, thách thức và thực tiễn tốt nhất để xây dựng chuyển đổi dự phòng đa phân vùng, bao gồm kết nối mạng, xác thực và quản trị. Bằng cách hiểu các ràng buộc này, bạn có thể thiết kế các ứng dụng gốc đám mây (cloud-native) linh hoạt, cân bằng giữa tuân thủ quy định và tính liên tục trong vận hành.

Hiểu về các rủi ro chủ quyền

Chủ quyền kỹ thuật số bao gồm việc quản lý các phụ thuộc kỹ thuật số — quyết định cách dữ liệu, công nghệ và cơ sở hạ tầng được sử dụng, đồng thời giảm thiểu rủi ro mất quyền truy cập, kiểm soát hoặc kết nối. Giống như bất kỳ chiến lược khôi phục sau thảm họa nào, có nhiều cách để cung cấp tính liên tục cho các hệ thống được thiết kế. Hầu hết chúng đều liên quan đến một dạng kiến trúc chuyển đổi dự phòng, tức là cung cấp một bộ cơ sở hạ tầng thứ hai để sử dụng khi thảm họa làm tê liệt cơ sở hạ tầng ban đầu. Điều khác biệt đối với khôi phục sau thảm họa có chủ quyền là cơ chế kiểm soát và cấu trúc của mục tiêu chuyển đổi dự phòng. Việc tích hợp AWS European Sovereign Cloud vào thiết kế workload của bạn sẽ bổ sung khả năng chuyển đổi dự phòng giúp bạn thiết lập lại hoặc duy trì chủ quyền nâng cao nếu môi trường chính không khả dụng.

Khi các yêu cầu quy định phát triển, các kiến trúc chuyển đổi dự phòng hiện đại phải tính đến các môi trường có chủ quyền như AWS European Sovereign Cloud, AWS GovCloud (US) và các triển khai đa nhà cung cấp. Bài viết này tập trung vào ba lĩnh vực cốt lõi để tích hợp các yêu cầu về chủ quyền vào thiết kế chuyển đổi dự phòng: chiến lược chuyển đổi dự phòng, kết nối mạng qua các phân vùng bị cô lập, và xác thực và ủy quyền trong các kiến trúc đa phân vùng. Các mẫu này áp dụng cho cả các sự cố gián đoạn khu vực ngắn hạn và các lỗi phân vùng dài hạn.

Hiểu về các phân vùng AWS

Là một nhà cung cấp đám mây toàn cầu, AWS vận hành nhiều phân vùng cơ sở hạ tầng được điều chỉnh để đáp ứng các yêu cầu vận hành và quy định cụ thể. Ngoài cơ sở hạ tầng toàn cầu của AWS, AWS còn cung cấp các phân vùng chuyên biệt như AWS GovCloud cho các cơ quan chính phủ Hoa Kỳ, các AWS China Region và AWS European Sovereign Cloud cho các khách hàng yêu cầu lưu trú dữ liệu và kiểm soát nghiêm ngặt trong EU.

Mỗi phân vùng là một nhóm AWS Region được cô lập về mặt logic với bộ tài nguyên riêng, bao gồm AWS Identity and Access Management (IAM). Do sự tách biệt này, các phân vùng hoạt động như các ranh giới cứng. Thông tin xác thực không được chuyển tiếp, và các dịch vụ như Amazon S3 và các tính năng như S3 Cross-Region Replication hoặc AWS Transit Gateway inter-region peering không thể hoạt động giữa các phân vùng. Những hạn chế này là có chủ ý, nhằm cung cấp sự cô lập trong vận hành. AWS GovCloud (US), ra mắt năm 2011, hỗ trợ các khách hàng khu vực công của Hoa Kỳ với các nhu cầu tuân thủ như FedRAMP và ITAR. Các AWS China Region được vận hành thông qua các đối tác địa phương để đáp ứng luật chủ quyền dữ liệu của Trung Quốc. Tương tự, AWS European Sovereign Cloud là một phân vùng được xây dựng hoàn toàn trong EU, ra mắt vào năm 2026.

Các phân vùng này cung cấp khả năng kiểm soát dữ liệu nâng cao và cô lập cơ sở hạ tầng vật lý, khiến chúng trở nên thiết yếu nếu bạn hoạt động trong các lĩnh vực nhạy cảm được quy định và cần đáp ứng các yêu cầu tuân thủ nghiêm ngặt.

Lợi ích chính của các phân vùng AWS

AWS đã giới thiệu các phân vùng vì một số lý do. Chúng là chìa khóa giúp khách hàng đáp ứng các yêu cầu tuân thủ và quy định cụ thể của từng quốc gia, cho dù là trong AWS GovCloud (US), AWS China hay AWS European Sovereign Cloud. Điều này được củng cố bởi nhiều biện pháp bảo vệ và kiểm soát, bao gồm sự tách biệt vật lý, logic và vận hành của cơ sở hạ tầng đám mây giữa các phân vùng. Điều này tương ứng trực tiếp với các khía cạnh bảo mật của các phân vùng. Các phân vùng cho phép AWS cung cấp sự cô lập hoàn toàn các tài nguyên, giúp quản lý bảo mật, đặc biệt đối với các kiến trúc chạy các workload nhạy cảm.

Một điểm quan trọng khác cần lưu ý khi nói về các phân vùng là tính khả dụng của dịch vụ. Không phải tất cả các dịch vụ AWS đều có sẵn trong mọi phân vùng. Để tìm hiểu thêm về các dịch vụ AWS có sẵn theo Region, hãy tham khảo AWS Capabilities by Region.

Kiến trúc đa phân vùng

Kiến trúc đa phân vùng cho phép chuyển đổi dự phòng phân vùng bằng cách triển khai tài nguyên và cơ sở hạ tầng trên nhiều phân vùng AWS bị cô lập. Bởi vì các phân vùng được tách biệt hoàn toàn bởi danh tính, mạng và ranh giới dịch vụ, việc chuyển đổi dự phòng không thể đơn giản chuyển đổi giữa chúng như trong một phân vùng hoặc Region duy nhất. Thay vào đó, các môi trường phải được cấp phát trước và giữ đồng bộ thông qua các công cụ nội bộ hoặc bên ngoài. Nếu không có kiến trúc như vậy, việc chuyển đổi dự phòng giữa các phân vùng là không thực tế. Các kiến trúc đa phân vùng giúp việc chuyển đổi dự phòng trở nên khả thi nhưng yêu cầu cơ sở hạ tầng trùng lặp, hệ thống danh tính riêng biệt và đồng bộ hóa dữ liệu tùy chỉnh.

Hình 1: Các lý do khác nhau cho việc chuyển đổi dự phòng và các vị trí khả thi của chúng

Khi thiết kế các chiến lược chuyển đổi dự phòng đa Region hoặc đa phân vùng, việc lựa chọn Region phụ thuộc vào loại thảm họa bạn muốn giảm thiểu:

• Thảm họa tự nhiên – chọn các Region ở các khu vực địa lý khác nhau hoặc có các đặc điểm địa lý riêng biệt.
• Thảm họa kỹ thuật – tách biệt các workload trên các phần độc lập của cơ sở hạ tầng kỹ thuật toàn cầu, chẳng hạn như lưới điện, mạng và các tài nguyên dùng chung khác.
• Thảm họa do con người gây ra – xem xét các yếu tố chính trị, kinh tế xã hội và pháp lý có thể ảnh hưởng đến hoạt động.

Hình 2: Kịch bản chuyển đổi dự phòng active-active bao gồm tùy chọn chuyển đổi dự phòng có chủ quyền

Chuyển đổi dự phòng phân vùng

Các workload đa phân vùng phát sinh từ nhu cầu của ngành để duy trì tính liên tục trên các miền có chủ quyền trong khi vẫn đáp ứng các quy định khu vực. Các ví dụ bao gồm quân đội và quốc phòng kết nối các đám mây chuyên biệt (chẳng hạn như AWS GovCloud (US)) với các môi trường thương mại, và các hệ thống ứng phó khẩn cấp yêu cầu cô lập phân vùng an toàn kết hợp với quản lý thống nhất (phương pháp tiếp cận một bảng điều khiển duy nhất). Các mặt phẳng điều khiển (control plane) quản lý các workload trên các phân vùng rất quan trọng để xử lý các cấu trúc đa người thuê (multi-tenant), cho phép tập trung các số liệu, tổng hợp nhật ký, giới thiệu, quản lý bảo mật và nhiều hơn nữa.

Tuy nhiên, các kết nối đa phân vùng làm tăng độ phức tạp trong vận hành, chi phí bảo mật và tuân thủ, chi phí và thách thức quản trị. Những yếu tố này khiến việc triển khai các kiến trúc như vậy chỉ khi chúng thực sự cần thiết là quan trọng. Các mô hình khả năng phục hồi đám mây tiêu chuẩn bao gồm từ sao lưu đơn giản đến thiết lập đa địa điểm, và có thể được triển khai trên nhiều Availability Zone cũng như nhiều Region. Khái niệm tương tự cũng áp dụng cho nhiều phân vùng. Chúng ta có thể di chuyển các bản sao lưu vào một phân vùng thứ hai để có thể khôi phục vào phân vùng đó. Tương tự, chúng ta có thể chạy một ứng dụng pilot light trong một phân vùng khác. Điều này giúp giảm đáng kể chi phí cơ sở hạ tầng cần thiết trong phân vùng thứ hai vì nó sẽ chỉ được xây dựng khi cần. Cuối cùng, các thiết lập warm standby hoặc multi-site active-active chủ yếu khác nhau ở nhu cầu đồng bộ hóa mạng phức tạp hơn giữa các phân vùng.

Hình 3: Các loại kịch bản khôi phục sau thảm họa khác nhau

Bạn cũng có thể xem xét tính độc lập của nhà cung cấp như một yêu cầu chủ quyền bổ sung khi lập kế hoạch chuyển đổi dự phòng. Một cách để đạt được tính độc lập của nhà cung cấp là sử dụng một nhà cung cấp đám mây khác. Tuy nhiên, việc chuyển đổi dự phòng sang một phân vùng AWS khác đơn giản hơn so với việc chuyển đổi nhà cung cấp đám mây vì bạn có thể tái sử dụng các mẫu cơ sở hạ tầng dưới dạng mã (infrastructure as code) của mình trên các phân vùng.

Lý do để kết nối các phân vùng

Mặc dù các phân vùng được thiết kế để cô lập, một số workload trong một phân vùng có thể cần giao tiếp với các workload trong các phân vùng ít được quy định hơn hoặc với các hệ thống bên ngoài có thể truy cập qua internet công cộng. Đối với những trường hợp như vậy, một số chiến lược kiến trúc và các quyết định kiến trúc tương ứng nên được xem xét. Có thể có các trường hợp sử dụng mà bạn cần các dịch vụ AWS giao tiếp giữa các phân vùng và điều phối các hành động trải rộng nhiều phân vùng, chẳng hạn như:

• Ứng dụng đa miền
• Tính năng tương đương và khả năng sẵn sàng của dịch vụ
• Tối ưu hóa chi phí trong khi đáp ứng các yêu cầu bảo mật
• Hợp nhất cơ sở hạ tầng
• Các mẫu mặt phẳng điều khiển (control plane)

Việc triển khai các trường hợp sử dụng này đòi hỏi phải xem xét sâu hơn các khía cạnh kỹ thuật của việc kết nối các phân vùng từ cả góc độ mạng và góc độ bảo mật.

Kết nối khu vực so với các phân vùng được kết nối

Các kết nối khu vực cho phép bạn liên kết các AWS Region trong cùng một phân vùng bằng cách sử dụng các tính năng như S3 Cross-Region Replication và Transit Gateway peering, tạo điều kiện thuận lợi cho việc phân phối workload và chuyển đổi dự phòng tương đối liền mạch trong cơ sở hạ tầng toàn cầu của phân vùng. Việc hiểu rõ sự khác biệt giữa các kết nối khu vực và các phân vùng được kết nối là rất quan trọng để thiết kế các kiến trúc linh hoạt, tuân thủ, đáp ứng cả yêu cầu vận hành và quy định.

Kết nối mạng phân vùng

Bạn có thể kết nối các phân vùng AWS theo ba cách: kết nối internet được bảo mật bằng TLS, IPsec Site-to-Site VPN qua internet, hoặc thông qua một gateway AWS Direct Connect đến các router tại chỗ hoặc sử dụng các kết nối đối tác Direct Connect point of presence (PoP) đến một Direct Connect PoP khác. Mỗi phương pháp đều có những đánh đổi khác nhau về độ phức tạp bảo mật và khả năng khôi phục. Để biết thêm thông tin về các mẫu kết nối giữa AWS GovCloud (US) và cơ sở hạ tầng AWS toàn cầu, hãy xem Connectivity patterns between AWS GovCloud (US) and AWS commercial partition. Ngoài giải pháp customer gateway đã được trình bày trước đó, các đối tác đặt tại các Direct Connect PoP có thể cung cấp các dịch vụ kết nối đa phân vùng. Các dịch vụ này có thể di chuyển lưu lượng truy cập từ một Direct Connect PoP này sang một Direct Connect PoP khác. Thiết lập như vậy cho phép các đường truyền chuyên dụng giữa các Direct Connect PoP của AWS European Sovereign Cloud và các vị trí Direct Connect trong các phân vùng khác.

Vì thông tin xác thực IAM không hoạt động trên các phân vùng, bạn cần tạo các vai trò riêng biệt hoặc sử dụng các nhà cung cấp danh tính bên ngoài. Các phương pháp tiếp cận phổ biến bao gồm sử dụng các IAM role với mối quan hệ tin cậy và ID bên ngoài, các endpoint khu vực của AWS Security Token Service (AWS STS), các chính sách dựa trên tài nguyên, hoặc các vai trò đa tài khoản được quản lý thông qua AWS Organizations. Một thực tiễn tốt nhất hiện đại là liên kết các danh tính từ một nhà cung cấp danh tính tập trung duy nhất đến nhiều phân vùng, tránh nhu cầu sử dụng IAM user bất cứ khi nào có thể. Nếu IAM user vẫn được sử dụng, thông tin xác thực có thể được lưu trữ trong AWS Secrets Manager, xoay vòng bằng Lambda, và một người dùng dự phòng có thể cải thiện tính khả dụng. Các mẫu này thường được kết hợp với các kiểm soát truy cập tiêu chuẩn, chẳng hạn như Amazon API Gateway với các authorizer, để bảo mật các tương tác đa phân vùng. Để tìm hiểu sâu hơn về xác thực và ủy quyền đa phân vùng với AWS IAM, hãy xem IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions.

Khi bảo mật giao tiếp giữa các phân vùng AWS, các phương pháp dựa trên chứng chỉ mang lại cả cơ hội và thách thức. Bởi vì các chứng chỉ AWS Certificate Manager (ACM) và AWS Private Certificate Authority (AWS Private CA) bị ràng buộc với từng phân vùng riêng lẻ, bạn thường phải triển khai và quản lý các cơ sở hạ tầng khóa công khai (PKI) riêng biệt trong mỗi môi trường, bao gồm các CA gốc chuyên dụng và xử lý thủ công việc chuyển khóa riêng. Để thiết lập giao tiếp đa phân vùng an toàn, một giải pháp nâng cao hơn liên quan đến việc sử dụng chứng chỉ được ký kép, trong đó các CA gốc trong mỗi phân vùng ký chéo chứng chỉ của nhau, tạo ra một chuỗi tin cậy hai chiều. Việc triển khai này yêu cầu thiết lập các CA gốc với AWS Certificate Manager Private CA, thiết lập các thỏa thuận ký chéo, quản lý các kho lưu trữ tin cậy trên các phân vùng và xử lý các kiểm tra xác thực và thu hồi chứng chỉ phức tạp. Bạn cũng phải tuân thủ các yêu cầu quy định khác nhau và duy trì các dấu vết kiểm toán chi tiết. Mặc dù phương pháp này làm tăng độ phức tạp trong vận hành, nhưng nó rất cần thiết để cho phép giao tiếp được xác thực, mã hóa trên các phân vùng bị cô lập, đặc biệt trong các môi trường được quy định nơi bảo mật và tuân thủ là tối quan trọng.

Quản lý AWS Organizations trên các phân vùng

Việc thiết lập các tài khoản AWS European Sovereign Cloud trong AWS Organization của bạn phải được thực hiện trong một tổ chức hoàn toàn riêng biệt. Trong phân vùng AWS GovCloud (US), các tài khoản có thể được ghép nối vào một tổ chức thương mại, như được mô tả trong Inviting Accounts into an Organization for AWS GovCloud. Với chủ quyền là mục tiêu chính, việc chuyển đổi dự phòng sang trạng thái chỉ có AWS European Sovereign Cloud sẽ đơn giản hơn nếu thiết lập AWS Organizations được tách biệt ngay từ đầu. Điều này không yêu cầu bắt đầu lại từ đầu. Thay vào đó, bạn có thể quản lý cùng các đơn vị tổ chức (OU) và chính sách cho AWS European Sovereign Cloud bằng cách tái sử dụng tự động hóa triển khai hiện có của mình.

Lý tưởng nhất, cấu trúc tài khoản AWS Organizations nên được tách biệt để dễ dàng sử dụng môi trường AWS trong AWS European Sovereign Cloud mà không phụ thuộc vào các phân vùng khác.

Hình 4: Kết nối và phân phối dịch vụ trên các phân vùng AWS như AWS European Sovereign Cloud

Các kiểm soát bảo mật nên được điều chỉnh cho từng phân vùng bằng cách sử dụng các Chính sách kiểm soát dịch vụ (SCP) riêng biệt, với AWS Control Tower quản lý phía thương mại. Mạng yêu cầu các Transit Gateway bị cô lập, các vùng DNS Amazon Route 53 riêng biệt và giao tiếp đa phân vùng an toàn bằng cách sử dụng AWS PrivateLink. Đối với giám sát, các bộ tổng hợp AWS Config và các phiên bản AWS Security Hub phải được cấu hình riêng trong mỗi phân vùng, trong khi thanh toán hợp nhất có thể được quản lý thông qua Organizations. Điều quan trọng là phải xem xét các hạn chế (ví dụ: AWS Control Tower không thể trực tiếp quản lý các tài khoản AWS GovCloud (US) hoặc AWS European Sovereign Cloud), và tính khả dụng hạn chế của một số tính năng AWS Organizations trong các phân vùng này. Nhìn chung, phương pháp này hỗ trợ quản trị, bảo mật và sự rõ ràng trong vận hành trên các phân vùng.

Kết luận

Việc điều hướng các kiến trúc đám mây dựa trên chủ quyền đòi hỏi một chiến lược giải quyết sự cô lập phân vùng, kết nối mạng và xác thực đa phân vùng an toàn. Ưu tiên chủ quyền trong thiết kế chuyển đổi dự phòng làm tăng độ phức tạp, nhưng nó có thể đáng giá nếu các workload của bạn cần được bảo vệ khỏi các rủi ro địa chính trị hoặc thay đổi quy định. Bắt đầu bằng cách xác định các kịch bản thảm họa quan trọng nhất đối với doanh nghiệp của bạn, sau đó chọn kiến trúc đơn giản nhất giải quyết các rủi ro đó. Bằng cách thiết kế chủ động cho các quy định đang phát triển, bạn có thể duy trì cả sự tuân thủ và khả năng phục hồi trong đám mây.

---

Về tác giả

Ivo Kammerath
Ivo Kammerath, Kiến trúc sư Giải pháp Trưởng về Khả năng phục hồi của AWS tại Đức, đã làm việc tại Amazon Web Services (AWS) từ năm 2017 và đã sử dụng AWS trong môi trường sản xuất từ năm 2012. Ông có kinh nghiệm trong phát triển phần mềm, độ tin cậy hệ thống và phân tích dữ liệu. Trong vai trò của mình, Ivo chịu trách nhiệm về khả năng phục hồi kiến trúc của khách hàng AWS tại Đức. Ivo cũng đã đóng góp cho các dự án mã nguồn mở như Hadoop HDFS, Netflix Chaos Monkey, Apache Tomcat và Flume.

Lars Reimann
Lars Reimann là Kiến trúc sư Giải pháp Cấp cao có trụ sở tại Münster, Đức. Với bằng Thạc sĩ Khoa học Máy tính Ứng dụng, ông gia nhập AWS vào tháng 4 năm 2020. Ông hỗ trợ khách hàng trong lĩnh vực Bán lẻ Doanh nghiệp với các thực tiễn tốt nhất trong hành trình đám mây của họ. Lars cũng đam mê về tính bền vững và cách công nghệ có thể được tận dụng để giải quyết các thách thức hiện tại vì một tương lai tốt đẹp hơn.

Michael Hanisch
Michael Hanisch là Trưởng phòng Công nghệ tại AWS EMEA cho thị trường Đức. Từng là một khách hàng AWS từ sớm, Michael quyết định đã đến lúc không nhìn lại CNTT truyền thống và gia nhập AWS vào năm 2011 với tư cách là Kiến trúc sư Giải pháp để chia sẻ kinh nghiệm và hỗ trợ các công ty khác trên hành trình lên đám mây của họ. Với nền tảng về kiến trúc phần mềm và lãnh đạo kỹ thuật, Michael đã làm việc trong các dự án trên nhiều khu vực địa lý và ngành công nghiệp, từ các công ty khởi nghiệp đến các tập đoàn lớn, trong hơn 20 năm qua trong ngành.

Stephan Schiller
Stephan là Kiến trúc sư Giải pháp tại AWS, nơi ông đã làm việc từ năm 2023. Ông mang đến chuyên môn sâu rộng từ các vai trò kỹ thuật trên nhiều hyperscaler và chuyên về phân tích dữ liệu và công nghệ streaming, với trọng tâm mạnh mẽ vào việc thiết kế và vận hành các kiến trúc hướng sự kiện (event-driven) có khả năng mở rộng. Trong suốt sự nghiệp của mình, Stephan đã làm việc trên nhiều dự án đám mây, hỗ trợ các doanh nghiệp lớn ở các giai đoạn khác nhau trong hành trình đám mây của họ.