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

# AMS 模式和应用程序或工作负载
<a name="ams-modes-and-apps-og"></a>

在选择正确的模式时，请考虑应用程序的运营和管理要求，方法是申请新的应用程序帐户或将应用程序托管在现有应用程序帐户中。为每个应用程序或工作负载选择适当的 AMS 模式取决于以下因素：
+ 环境将提供的 SDLC 生命周期功能类型（例如，包含未经审核更改的沙箱、具有一些频繁更改的 UAT、更改最少且受到严格监管的生产）
+ 所需的治理政策（通过 SCPs OU 级别强制执行）
+ 运营模式（如果您想承担运营责任或想将其外包给AMS）
+ 预期的业务成果，例如在云端运营的时间和运营成本。

**注意**  
有关每个 AMS 服务的模式类型的描述，请参阅 AMS [中的模式和账户类型](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-types.html)。  
有关不同模式的真实用例，请参阅 [AMS 模式的真实世界用例](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-and-use-cases.html)

下表概述了应用程序所有者在决定最合适的 AMS 模式时需要考虑的关键因素。应用程序所有者应在应用程序迁移之前加入评估阶段，以充分了解哪种模式适用于他们的特定应用程序。示例：对于基于云原生服务或无服务器架构的应用程序，最好的选择可能是在开发人员模式下开始构建和迭代，然后使用 AMS Managed — SSP 模式部署最终的基础设施即代码。在这种情况下，可能需要进行轻度重构，以确保为自动部署创建的任何 CloudFormation 模板都符合 AMS 制定的采集指南。此外，任何 IAM 权限都需要获得 AMS Security 的批准，以确保它们遵循最低权限模式。

为托管应用程序而选择的 AMS 模式可以帮助您朝着所需的云运营模式进行构建。

**注意**  
根据为托管应用程序而选择的不同 AMS 模式，单个 AMS 托管着陆区中可以存在多个云运营模式。


<table>
<thead>
  <tr><th>决策问题</th><th>标准 CM 模式/OOD \*</th><th>AWS Service Catalog</th><th>直接更改模式</th><th>自助配置</th><th>开发者模式</th><th>客户管理</th></tr>
</thead>
<tbody>
  <tr><td colspan="7">运营准备就绪</td></tr>
  <tr><td>记录、监控和事件管理</td><td colspan="3">AMS 负责所有托管基础架构</td><td>负责自助配置服务 (SSP) 的客户</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td><td rowspan="8">客户负责</td></tr>
  <tr><td>连续性管理</td><td colspan="3">AMS 负责执行客户选择的备份计划</td><td>负责自助配置服务 (SSP) 的客户</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td></tr>
  <tr><td>实例级访问管理</td><td colspan="3">AMS 通过本地域的单向 AD 信任进行管理。需要托管基础设施才能加入 AMS 域</td><td>不适用</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td></tr>
  <tr><td>安全管理和账户级别访问管理</td><td colspan="3">AMS 对所有托管账户负责</td><td>AMS 负责所有托管账户</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td></tr>
  <tr><td>补丁管理</td><td colspan="3">AMS 对所有托管账户负责</td><td>负责自助配置服务 (SSP) 的客户</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td></tr>
  <tr><td>变更管理</td><td colspan="3">AMS 对所有托管账户负责</td><td>负责自助配置服务 (SSP) 的客户</td><td>负责使用开发者 IAM 角色在 AMS CM 系统之外配置资源的客户</td></tr>
  <tr><td>资源调配管理</td><td>针对 AMS 中提供的配置选项进行了规范和标准化</td><td>按照 AMS 规范性标准，可以灵活地直接使用适用于 AWS Service Catalog 的 AWS 服务 API</td><td>按照 AMS 规范性标准灵活地直接使用 AWS 服务 API</td><td>可以灵活地直接使用 AWS 服务 APIs 提供 SSP 服务</td><td>可以灵活地直接使用 AWS 服务 API 进行配置</td></tr>
  <tr><td>事件管理和审计</td><td colspan="4">AMS 负责所有托管账户</td><td>负责使用开发者 IAM 角色在 AMS 变更管理系统之外配置资源的客户</td></tr>
  <tr><td>GuardRails 以及共享基础架构（网络）和安全框架</td><td colspan="5">利用 AMS 核心账户的规范性和标准化</td><td>灵活定制利用 AMS 核心账户</td></tr>
  <tr><td colspan="7">应用程序就绪</td></tr>
  <tr><td>应用程序重构</td><td colspan="4">需要轻量化重构</td><td>需要轻量级重构（如果使用 AMS 标准 CM 进行配置）</td><td>无需重构</td></tr>
  <tr><td>对 AWS 服务的支持</td><td colspan="5">仅限于 AMS 支持的内容</td><td>不限</td></tr>
  <tr><td colspan="7">业务注意事项</td></tr>
  <tr><td>是时候做好运营准备了</td><td colspan="3">三到六个月</td><td colspan="2">6 个月以上，具体取决于客户的应用程序操作能力</td><td>6-18 个月视客户基础架构和应用程序操作能力而定</td></tr>
  <tr><td>成本</td><td colspan="3">$$$$</td><td>$$$</td><td>$$</td><td>$</td></tr>
  <tr><td>应用示例</td><td colspan="3">具有 3 层堆栈的 Web 服务器、符合合规性和监管要求的应用程序</td><td>使用 API Gateway 的 Web 服务器、利用 ECS/EKS 的容器化应用程序</td><td>对使用 Lambda、Glue、Athena 等的数据湖应用程序进行迭代/优化</td><td> accounts/applications 像沙盒一样去中心化、第三方托管的应用程序</td></tr>
</tbody>
</table>


**\*** Operations On Demand (OOD) 为使用标准 CM 模式的客户提供了通过专用资源管理管理其变更的服务。有关更多详细信息，请参阅按[需运营产品目录](https://docs.aws.amazon.com/managedservices/latest/userguide/ood-catalog.html)，并咨询您的云服务交付经理 (CSDM)。

**注意**  
SSP 模式和开发者模式之间的价格比较假设预配置了相同的 AWS 服务。

将 AMS 模式与业务和 IT 目标进行比较

![](http://docs.aws.amazon.com/zh_cn/managedservices/latest/onboardingguide/images/ams-modes-choosing-dcm.png)


如图所示，如果您正在为应用程序寻找高度可控和标准化的监管模式，那么 AMS 管理的标准变更、AWS Service Catalog 或直接变更模式最为合适。如果您需要以应用程序创新为重点的定制治理模型，而无需做好运营准备，请选择客户管理模式。在 Customer Managed 模式下，您可能需要更长的时间才能运行应用程序，因为您有责任建立人员、流程和工具来支持操作功能，例如事件管理、配置管理、配置管理、安全管理、补丁管理等。