本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 全球擴展的規劃
**調查**
我們希望聽到您的意見。請進行[簡短的問卷](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2)，以提供對 AWS PRA 的意見回饋。
[AWS Security Assurance Services](https://aws.amazon.com/professional-services/security-assurance-services/) 經常收到有關在全球擴展 AWS 時 的隱私權架構的問題。問題涉及維持對唯一隱私權要求的合規性，例如資料主權義務或客戶合約，同時避免額外的成本和營運開銷。設計考量因素通常包括資料落地、操作員存取限制、彈性和存活能力，以及整體獨立性。如需詳細資訊，請參閱 [上的滿足數位主權要求 AWS](https://d1.awsstatic.com/events/Summits/reinvent2022/SEC205_Meeting-digital-sovereignty-requirements-on-AWS.pdf)(AWS re：Invent 2022 簡報）。
下列問題很常見，只有您可以針對使用案例回答這些問題：
+ 我客戶的個人資料需要存放在何處？
+ 我的客戶資料存放在哪裡？
+ 個人資料可以跨越邊界的方式和位置？
+ 跨區域存取資料的人工或服務是否構成傳輸？
+ 如何確定沒有外國政府存取我客戶的個人資料？
+ 在哪裡可以存放備份和熱或冷網站？
+ 為了將資料保留在本機，我應該在提供服務的每個區域中維護 AWS 登陸區域嗎？ 或者，我可以使用現有的 AWS Control Tower 登陸區域嗎？
對於資料駐留需求，不同的架構部署可能更適合不同的組織。有些組織可能要求其客戶的個人資料保留在特定區域內。如果是這樣，您可能會擔心如何在維護這些義務的同時，通常遵守法規。無論情況如何，選擇多帳戶部署策略時有多個考量。
若要定義關鍵架構設計元件，請與您的合規和合約團隊緊密合作，以確認個人資料可以跨越 的位置、時間和方式的需求 AWS 區域。判斷哪些內容符合資料傳輸的資格，例如移動、複製或檢視。此外，了解是否有必須實作的特定彈性和資料保護控制。備份和災難復原策略是否需要跨區域容錯移轉？ 若是如此，請判斷您可以使用哪些區域來存放備份資料。判斷資料加密是否有任何需求，例如特定加密演算法或用於產生金鑰的專用硬體安全模組。與這些主題的合規利益相關者保持一致之後，開始考慮多帳戶環境的設計方法。
**Topics**
+ [具有受管區域的中央登陸區域](#global-expansion-central)
+ [區域登陸區域](#global-expansion-regional)
+ [AWS 歐洲主權雲端](#global-expansion-eea)
也請務必記住，隱私權合規可能不會只停止資料主權。檢閱本指南的其餘部分，以了解許多其他挑戰的可能解決方案，例如同意管理、資料主體的請求、資料控管和 AI 偏差。
## 具有受管區域的中央登陸區域
如果您想要全域擴展，但已在其中建立多帳戶架構 AWS，則通常會想要使用相同的多帳戶登陸區域 (MALZ) 來管理其他 AWS 區域。在此組態中，您會繼續在建立基礎設施的區域中，從現有的 AWS Control Tower 登陸區域操作基礎設施服務，例如記錄、帳戶工廠和一般管理。
對於生產工作負載，您可以透過將 AWS Control Tower 登陸區域擴展到新的區域來操作區域部署。透過這樣做，您可以將控管擴展 AWS Control Tower 到新的區域。如此一來，您就可以將個人資料存放區保留在特定受管區域中，資料仍然位於受益於基礎設施服務和 AWS Control Tower 控管的帳戶。在 中 AWS Organizations，包含個人資料的帳戶仍會在專用個人資料 OU 下彙總，其中 AWS Control Tower 會實作 中的所有資料主權護欄。此外，區域特定的工作負載包含在專用帳戶中，而不是在多個區域中建立可能包含相同工作負載的生產帳戶。
此部署可以最具成本效益，但需要考慮控制跨 AWS 帳戶 和區域邊界的個人資料流程。考慮下列各項：
+ 日誌可能包含個人資料，因此可能需要一些額外的組態來包含或修改敏感欄位，以防止在彙總期間進行跨區域傳輸。如需控制跨區域日誌彙總的詳細資訊和建議實務，請參閱本指南[集中式日誌儲存](log-archive-account.md#centralized-log-storage)中的 。
+ 考慮在 AWS Transit Gateway 設計中隔離 VPCs 和適當的雙向網路流量流程。您可以限制允許和核准的 Transit Gateway 附件，也可以限制可變更 VPC 路由表的人員或內容。
+ 您可能需要防止雲端營運團隊的成員存取個人資料。例如，包含客戶交易資料的應用程式日誌可能會被視為比其他日誌來源更敏感。可能需要其他核准和技術護欄，例如角色型存取控制和[屬性型存取控制](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。此外，資料在存取時可能受到駐留限制。例如，一個區域 A 中的資料只能從該區域內存取。
下圖顯示具有區域部署的集中式登陸區域。
![\[具有區域部署的集中式登陸區域。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/privacy-reference-architecture/images/global-expansion-central.png)
## 區域登陸區域
與非材料工作負載相比，具有多個 MALZ 可以完全隔離處理個人資料的工作負載，從而協助您實現更嚴格的合規要求。根據預設，可以設定 AWS Control Tower 集中記錄彙總，從而簡化。透過此方法，您不需要使用需要修訂的個別日誌串流來維護記錄的例外狀況。您甚至可以擁有每個 MALZ 的本機和專用雲端操作團隊，這會限制操作員存取本機駐留。
許多組織都有個別的美國和歐洲登陸區域部署。每個區域登陸區域都有單一的空白安全狀態，以及區域中帳戶的相關控管。例如，在一個 MALZ 中的工作負載中可能不需要使用專用 HSMs 來加密個人資料，但在另一個 MALZ 中可能需要。
雖然此策略可以擴展以滿足許多目前和未來的需求，但請務必了解與維護多個 MALZs 相關的額外成本和營運開銷。如需詳細資訊，請參閱 [AWS Control Tower 定價](https://aws.amazon.com/controltower/pricing/)。
下圖顯示兩個區域中的個別登陸區域。
![\[在兩個區域中分隔登陸區域。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/privacy-reference-architecture/images/global-expansion-regional.png)
## AWS 歐洲主權雲端
有些組織需要徹底分離其在歐洲經濟區 (EEA) 中操作的工作負載，以及在其他地方操作的工作負載。在這種情況下，請考慮[AWS 歐洲主權雲端](https://aws.eu/)。 AWS 歐洲主權雲端是歐洲的全新獨立雲端，旨在協助客戶滿足區域不斷發展的主權需求，包括嚴格的資料駐留權、營運自主權和彈性需求。
AWS 歐洲主權雲端在實體上和邏輯上與現有的 分開 AWS 區域，同時提供相同的安全性、可用性和效能。只有位於歐洲 AWS 的員工才能控制 AWS 歐洲主權雲端的操作和支援。如果您有嚴格的資料駐留需求， AWS 歐洲主權雲端會保留您在歐洲建立的所有中繼資料 （例如其用來執行的角色、許可、資源標籤和組態 AWS)。 AWS 歐洲主權雲端也具有自己的帳單和用量計量系統。
對於此方法，您會使用與上一節[區域登陸區域](#global-expansion-regional)類似的模式。不過，對於您提供給歐洲客戶的服務，您可以在 AWS 歐洲主權雲端中部署專用的 MALZ。