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

AMS 账户限额

AMS 多账户着陆区内有三种不同类型的限制需要考虑：AMS API 限制、AMS 资源限制和 AWS 限制。

AMS 单账户着陆区内有两种不同类型的限制需要考虑：AMS API 限制和 AWS 限制。

AMS 账户 API 限制

本节介绍账户级别限制，超过该限制后 AWS Managed Services (AMS) 会限制 AMS SKMS API 服务。这意味着，如果您在一秒钟内拨打列出的电话 APIs 超过 10 次，则其中一个呼叫被 “限制”（您会收到）。ThrottleException在极少数情况下，外部或下游依赖关系可能会限制 AMS API，然后 AMS 可能会以可能更低的速率限制您的 API 调用。

对于列出的每个 AMS SKMS API，该操作在 10 TPS（每秒交易量）后会受到限制：

AMS 多账户 landing zone 账户资源限制

账户资源限制与 AMS 多账户 landing zone 应用程序账户 VPCs 和子网有关。

应用程序账户资源限制

每个组织有 50 个应用程序帐户的软限制。如果您有超过 50 个应用程序帐户的用例，请联系您的云服务交付经理 (CSDM)，转达您的需求。

VPCs 和子网资源限制

在为该组织预定义的 AWS 区域内， VPCs 每个应用程序账户的软限制为 10 个。

每个 VPC 可能有 1 到 10 个私有子网层，跨越 2 到 3 个可用区。此外，每个 VPC 可能有 0 到 5 个公有子网层，跨越 2 到 3 个可用区。如果您的要求超出这些限制，请通知您的 CSDM 或云架构师查看您的用例。

AMS 多账户 landing zone 申请与账户比例

AMS 多账户着陆区支持每个应用程序一个账户；但是，每个应用程序账户的费用很小，您需要为每小时与 Transit Gateway 的连接次数以及流经 AWS Transit Gateway的流量收费。因此，账户中隔离的应用程序越多 VPCs，或者成本就越高。

为了降低成本并同时确保适当的职责分工，AMS 建议您 1) 按业务流程紧密耦合的团队对应用程序进行分组，以及 2) 不要混合处于不同阶段（生产与非生产）或由不同团队管理的应用程序。这样，您将拥有更少的帐户，访问管理和职责分工将更加容易，并且可以降低流量成本。

例如：一家企业在生产中有一个交易应用程序和一个投资组合管理应用程序，这两个应用程序都由投资IT团队管理，并且相互交换大量流量。在这种情况下，公司可以从将两个应用程序分组到同一个账户和同一个 VPC 中受益，因为投资 IT 团队不必请求访问多个应用程序账户，而且公司将节省流量成本。在这种情况下，公司应为处于开发阶段的相同应用程序创建另一个帐户，并向开发团队提供访问权限。

在另一种情况下，企业在生产中有一个薪资应用程序和一个会计应用程序，分别由人力资源 IT 和会计 IT 团队管理。尽管工资单应用程序必须与会计应用程序交换信息，但我们建议将两个应用程序分成不同的帐户，每个团队一个，并 VPCs 使用网络帐户在两个应用程序之间建立连接。通过这种方式，公司将防止人力资源IT团队请求更改影响会计应用程序基础架构，而他们对此一无所知。

有关如何将帐户分组为组织单位的提示（OUs）。OU 是一种逻辑分组机制，使您能够对帐户进行分类（分组），并根据这些组对帐户应用策略和配置。建议的创建方法 OUs 是将它们建立在需要应用于特定账户组的策略的基础上，而不是基于报告结构中团队的内部层次结构。OU 不等同于 Active Directory 的 OU，因此不鼓励尝试在中复制 AD OU 结构， AWS Organizations 这会导致 and/or 操作结构难以维护。

AWS 账户限制

AWS 账户限制适用于您的 AWS Managed Services (AMS) 账户。确定 AWS 服务默认和当前限制的最简单方法是利用 S AWS ervice Quotas。AMS 建议将单个服务限制调整到适当的大小，以便在账户中运行服务。限额就像护栏一样，可以保护您的账户安全并降低逃跑成本。如果您想提高具体限额，请向 AMS 提交服务申请，AMS Operations 将代表您提高限额。例如，RDS 实例的默认限制（或配额）为 40；如果您的工作负载需要 50 个 RDS 实例，请向 AMS Operations 提出服务请求，将限制提高到所需的值。