本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
單一多帳戶登陸區域與多個多帳戶登陸區域FAQs
選擇設定單一多帳戶登陸區域或多個多帳戶登陸區域時的一些常見問題：
Q1：如果遇到任何帳戶限制或業務限制，是否可以從單一多帳戶登陸區域開始，並移至多個多帳戶登陸區域？
答：是。您可以選擇在任何指定時間設定另一個多帳戶登陸區域：
需要設定新的帳單付款人帳戶 （目前，AWS 不支援單一 AWS 組織中的多付款人帳戶）。
一旦填寫多帳戶登陸區域問卷，多帳戶登陸區域基礎建置最多需要 2 週的前置時間。
每個多帳戶登陸區域代表增加 ~3，000 USD/每月執行成本。
需要 N/W、AD、DNS 和 SSO 整合才能建立新的 MALZ。
任何預留執行個體 (RIs)、成本節省計劃將需要為新的多帳戶登陸區域設定 (RIs不可轉移）。
AMS 多帳戶登陸區域不支援跨多帳戶登陸區域帳戶遷移帳戶，例如跨 AWS Orgs。不過，若要將應用程式從一個帳戶移至另一個帳戶，可以使用標準遷移方法。
Q2：什麼是對基礎/共用基礎設施進行 MALZ 更新/變更，並量化客戶風險的 AMS 方法？ 提供在程序中包裝哪些保證的詳細資訊。客戶如何放心 MALZ 更新/變更不會影響客戶？ 客戶是否需要採取任何措施來防止中斷？
答：AMS 使用內部工具遵循嚴格的變更方法，讓我們能夠定義、檢閱、排程和執行客戶環境的變更。
發佈更新的程序會強制執行程式碼檢閱、整合測試、在 Gamma 和 Beta 環境中部署，以及在 Beta 和 Gamma 環境中額外的製作時間和測試，然後再發佈給客戶環境。所有版本都包含轉返程序，並由版本團隊和建立和請求變更的團隊密切監控。發行版本的範圍僅限於 AMS 擁有和佈建的堆疊。平均而言，我們每週至少執行一個版本。
除此之外：
AMS SLA 適用。根據 AMS 服務描述，任何事件引發的共用基礎設施維護活動都會遵循具備解決權的 SLA 或點數。
客戶不需要採取特殊的預防措施，以防止對常見基礎設施的干擾。客戶在 AWS Org 或 Core OU 帳戶中具有唯讀許可，因此客戶無法對 MALZ 核心環境進行任何破壞性變更。所有客戶對 核心基礎設施的請求都需要 AMS 檢閱和核准。
在 App OU 層級傳播變更之前，客戶可以在個別非產品帳戶層級測試特定組織層級變更，例如 SCPs/角色。它正在 AMS 藍圖上，以允許多個 APP OUs(2020 年第 2 季），這將進一步緩解進行某些 ORG 層級變更的風險。MALZ 團隊已針對「建置模式」帳戶發行個別的 OU，以確保客戶所有權和個別控制項的明確區隔。
其中大多數都是允許 AMS 以有效和有效率的方式操作工作負載的變更，不一定會影響客戶的工作負載。當 AMS 認為共用的基礎設施變更可能會影響客戶的工作負載，然後與客戶的變更時段保持一致。
高階建議，如果符合下列條件，請從多個多帳戶登陸區域開始：
如果它可協助您達成任何特定的合規。
如果您需要使用多區域。
如果您有不同的現場部署 ADs和網路，用於生產/材料與非生產/非材料工作負載，請明確隔離 b/w 工作負載。
