本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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 多帳戶登陸區域帳戶資源限制

帳戶資源限制與 AMS 多帳戶登陸區域應用程式帳戶和 VPCs和子網路相關。

應用程式帳戶資源限制

每個組織有 50 個應用程式帳戶的軟性限制。如果您有超過 50 個應用程式帳戶的使用案例，請聯絡您的雲端服務交付管理員 (CSDM) 來轉送您的需求。

VPCs和子網路資源限制

在組織的預先定義 AWS 區域內，每個應用程式帳戶有 10 VPCs 的軟性限制。

每個 VPC 可能有 1 到 10 個私有子網路層，橫跨 2 到 3 個可用區域。此外，每個 VPC 可能有 0 到 5 個公有子網路層，橫跨 2 到 3 個可用區域。如果您有超出這些限制的要求，請通知您的 CSDM 或雲端架構師檢閱您的使用案例。

AMS 多帳戶登陸區域應用程式與帳戶比率

AMS 多帳戶登陸區域支援每個應用程式一個帳戶；不過，每個應用程式帳戶的成本都很低，而且您每小時需支付 Transit Gateway 的連線數，以及流經 AWS Transit Gateway 的流量。因此，隔離的應用程式越常進入帳戶或 VPCs，成本就越高。

為了降低成本並仍然確保適當的職責劃分，AMS 建議您 1) 依業務流程緊密耦合的團隊將應用程式分組，以及 2) 不混合處於不同階段 （產品與非產品） 或由不同團隊管理的應用程式。如此一來，您將擁有較少的帳戶、存取管理和職責分離會更輕鬆，並且可以降低流量成本。

例如：企業在生產中擁有交易應用程式和產品組合管理應用程式，這兩個應用程式都由投資 IT 團隊管理，並互相交換大量流量。在此案例中，公司可以從將相同帳戶和 VPC 中的兩個應用程式分組中受益，因為投資 IT 團隊不需要請求存取多個應用程式帳戶，而且公司將節省流量成本。在這種情況下，公司應該在開發階段為相同的應用程式建立另一個帳戶，並向開發團隊提供存取權。

在另一個案例中，企業在生產環境中有薪資應用程式和會計應用程式，分別由人力資源 IT 和會計 IT 團隊管理。雖然薪資應用程式必須與會計應用程式交換資訊，但我們建議您隔離不同帳戶中的兩個應用程式，每個團隊一個，並使用網路帳戶在兩個應用程式的 VPCs 之間建立連線。透過這種方式，公司將防止人力資源 IT 團隊請求變更影響會計應用程式基礎設施，而他們對此並不知情。

如何將帳戶分組為組織單位 (OUs秘訣。OU 是一種邏輯分組機制，可讓您分類 （群組） 帳戶，並根據這些群組將政策和組態套用至 。建立 OUs 的建議方法是以需要套用至特定帳戶群組的政策為基礎，而不是以報告結構內團隊的內部階層為基礎。OU 不等同於 Active Directory 的 OU，因此 AWS Organizations 不鼓勵在 中嘗試複寫 AD OU 結構，並導致難以維護和/或操作結構。

AWS 帳戶限制

AWS 帳戶限制適用於您的 AWS Managed Services (AMS) 帳戶。判斷 AWS 服務預設和目前限制的最簡單方法是利用 AWS Service Quotas。AMS 建議將個別服務限制的大小調整到適當的大小，以在帳戶中執行服務 （些）。限制就像護欄一樣，可保護您的帳戶的安全和成本失控。如果您想要提高特定限制，請向 AMS 提交服務請求，AMS Operations 會代表您提高限制。例如，RDS 執行個體的預設限制 （或配額） 為 40；如果您的工作負載需要 50 個 RDS 執行個體，請提出 AMS Operations 的服務請求，將限制提高到所需的值。