本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 单个多账户着陆区与多个多账户着陆区 FAQs
<a name="single-or-multi-malz-faq"></a>

选择设置单个多账户着陆区或多个多账户着陆区时的一些常见问题：

**问题 1**：如果遇到任何账户限制或业务限制，我能否从单个多账户着陆区开始，然后转移到多个多账户着陆区？

**答**：是的。您可以选择在任何给定时间设置另一个多账号着陆区：
+ 需要设置新的账单付款人账户（目前 AWS 不支持单个 AWS 组织中的多付款人账户）。
+ 填写多账户 landing zone 问卷后，多账户 Landing Zone 基础建设最多需要 2 周的交货时间。
+ 每个多账户 landing zone 意味着每月增加约 3K 美元的运营成本。
+ 新的 MALZ 需要集成 N/W、AD、DNS 和 SSO。
+ 需要为新的多账户 landing zone 设置任何预留实例 (RIs)、成本节省计划（RIs 不可转让）。
+ AMS 多账户着陆区不支持跨多账户着陆区账户迁移账户；例如，跨AWS Orgs。但是，使用标准迁移方法可以将应用程序从一个帐户转移到另一个帐户。

**问题 2**：AMS 对 MALZ updates/changes 的 underlying/shared 基础设施和量化客户风险的方法是什么？ 请详细说明流程中包含哪些保证。客户如何放心 MALZ updates/changes 不会影响客户？ 客户需要采取任何措施来防止中断吗？

**答**：AMS 采用严格的变更方法，使用内部工具，使我们能够定义、审查、安排和执行对客户环境的更改。

发布更新的过程强制执行代码审查、集成测试、在 gamma 和 beta 环境中部署，以及在 beta 和 gamma 环境中进行额外的烘焙时间和测试，然后再发布给客户环境。所有版本都包含回滚程序，并受到发布团队以及创建和请求变更的团队的密切监控。版本的范围仅限于 AMS 拥有和提供的堆栈。平均而言，我们每周至少执行一个版本。

此外：
+ AMS 服务等级协议适用。根据AMS服务描述，在共享基础设施维护活动后提出的任何事件都将遵守相应的服务等级协议，以获得解决方案或积分。
+ 客户无需采取特殊的预防措施来防止公共基础设施中断。客户对 AWS Org 或核心 OU 账户拥有只读权限，因此客户无法对 MALZ 核心环境进行任何破坏性更改。客户对核心基础设施的所有请求都需要 AMS 的审查和批准。
+  SCPs/Roles 在应用程序 OU 级别传播更改之前，客户可以测试某些组织级别的更改，例如在个人非生产账户级别进行更改。AMS路线图上允许使用多个应用程序 OUs （2020年第二季度），这将进一步降低进行某些ORG级别更改的风险。MALZ 团队已经为 “构建模式” 账户发布了单独的 OU，以确保明确区分客户所有权和单独的控制措施。
+ 其中大多数变更使AMS能够以有效和高效的方式操作工作负载，并且不一定会影响客户的工作量。如果 AMS 认为共享基础设施变更会对客户的工作负载产生影响，那么他们就会与客户的变更窗口保持一致。

**高级建议，如果出现**以下情况，则从多个多账户着陆区域开始：
+ 它是否可以帮助您实现任何特定的合规性。
+ 如果您需要使用多区域。
+ 如果您的本地 ADs 和网络 Prod/Material 与非工作负载不同Prod/Non-Material workloads, to clearly segregate b/w。