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

# AMS 中模式和帳戶的類型
<a name="ams-modes-types"></a>

AWS Managed Services (AMS) 模式可以定義為在每種模式的特定控管架構下與 AMS 服務互動的方式。會記下登陸區域差異、多帳戶登陸區域或 MALZ 和單一帳戶登陸區域或 SALZ。

**注意**  
如需應用程式部署和選擇正確 AMS 模式的詳細資訊，請參閱 [AMS 模式和應用程式或工作負載](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-and-apps-ug.html)。  
如需不同模式的實際使用案例，請參閱 [AMS 模式的實際使用案例](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-use-cases.html)

下表提供每個 AMS 服務模式的說明。


<table>
<thead>
  <tr><th>AMS 功能</th><th>RFC 模式 （先前為標準 CM 模式）/OOD\*</th><th>直接變更模式</th><th>AWS Service Catalog</th><th>自助式佈建/開發人員模式</th><th>客戶受管</th></tr>
</thead>
<tbody>
  <tr><td>登陸區域組態</td><td>MALZ 和 SALZ</td><td>MALZ 和 SALZ</td><td colspan="3">MALZ 和 SALZ</td></tr>
  <tr><td>變更管理</td><td>變更排程、檢閱手動變更和變更記錄</td><td>與 RFC 模式相同，適用於高風險變更，例如 IAM 或安全群組</td><td colspan="3">無</td></tr>
  <tr><td>記錄、監控、護欄和事件管理</td><td colspan="3">是 （支援的資源）</td><td colspan="2">否</td></tr>
  <tr><td>持續性管理</td><td colspan="3">是 （支援的資源）</td><td>不適用/否</td><td>否</td></tr>
  <tr><td>安全管理</td><td colspan="3">執行個體層級安全控制和帳戶層級控制</td><td>帳戶層級控制</td><td>AWS Org 層級控制</td></tr>
  <tr><td>修補管理</td><td colspan="3">是</td><td>不適用/否</td><td>否</td></tr>
  <tr><td>事件和問題管理</td><td colspan="3">AMS 支援資源的回應和解析 SLA</td><td>所產生資源的回應 SLA</td><td>否</td></tr>
  <tr><td>報告</td><td colspan="3">是</td><td colspan="2">否</td></tr>
  <tr><td>服務請求管理</td><td colspan="3">是</td><td>僅支援 請求</td><td>否</td></tr>
</tbody>
</table>


**\***隨需操作 (OOD) 提供客戶使用 RFC 模式，透過專用資源管理其變更。如需詳細資訊，請參閱 [ 方案的隨需操作目錄](https://docs.aws.amazon.com/managedservices/latest/userguide/ood-catalog.html)，並與您的雲端服務交付管理員 (CSDM) 交談。

**注意**  
[AMS 中的自助式佈建模式](self-service-provisioning-section.md) 和 [AMS 進階開發人員模式](developer-mode-section.md)似乎都適合根植於原生 AWS Services 的複雜架構的應用程式。架構工作負載時，您會根據您的業務環境，在卓越營運和敏捷性之間做出取捨。這是考慮為您的應用程式選取 SSP 模式或開發人員模式的好方法。選項也可能根據應用程式的 SDLC 階段而變更。例如：當應用程式為生產就緒時，SSP 模式可能會因為在此模式中的 AMS 護欄更嚴格，而成為更適當的選項。護欄是以預防性控制的形式強制執行，例如應用程式 OU 層級的 IAM 更新和 SCPs RFC 型變更控制。這些業務決策可以讓您了解工程設計的優先順序。您可以最佳化 ，以增加應用程式擁有者在「生產前」階段的彈性，而犧牲控管和營運支援。

## MALZ 架構和相關聯的 AMS 模式
<a name="ams-modes-and-malz"></a>

AMS 多帳戶登陸區域 (MALZ) 可讓您選擇在預設組織單位 (OU)：客戶受管 OU、受管 OU 或開發 OU 下自動佈建應用程式帳戶 （或資源帳戶）。在每個這些 OUs 下建立的應用程式帳戶中佈建的基礎設施，受限於這些基礎 OUs 提供的特定 AMS 模式。在同一個應用程式帳戶中尋找兩種或多種模式的混合是很常見的。例如：RFC 模式和 SSP 模式可以共存於託管由 API Gateway 和 Lambda 組成的管道架構的 AMS 受管帳戶中，用於觸發函數，以及用於擷取和協同運作的 EC2、S3 和 SQS。在此情況下，SSP 模式會套用至 Lambda 和 API Gateway。

圖 1 顯示如何在 AMS 中透過基礎 OUs 提供不同的模式。在 AMS 中請求新的應用程式帳戶時，您必須選取帳戶的 OU。

MALZ 架構和相關聯的 AMS 模式

![組織結構顯示管理帳戶的頂部、四個帳戶的中間類型，以及具有客戶堆疊的應用程式帳戶底部。](http://docs.aws.amazon.com/zh_tw/managedservices/latest/userguide/images/MALZ-high-level-(Mar2021).png)


AMS 利用以 AWS 最佳實務為基礎的基礎 OUs，做為使用服務控制政策 (SCPs) 邏輯管理帳戶的方法。這可做為對每個 AMS 模式強制執行控管架構的方法。套用至基礎 OUs 的任何控管和安全護欄 （以 SCPs 的形式） 也會自動套用至自訂/子 OUs。您可以為子 OUs 請求其他 SCPs。請務必了解應用程式帳戶與 模式不同。模式會套用至帳戶內佈建的基礎設施，並定義 AMS 與客戶之間的操作責任。

圖 1：MALZ 架構和相關聯的 AMS 模式

![表格顯示具有預防性和偵測性控制以及客戶控管支援的 AMS 模式。](http://docs.aws.amazon.com/zh_tw/managedservices/latest/userguide/images/ams-modes-guardrails-dcm.png)


**注意**  
「限制性」表示您可以為這些 OUs 請求自訂政策，這些政策由 AMS case-by-case核准，以確保它們不會干擾 AMS 提供卓越營運的能力。如需 AMS 護欄的詳細清單，請參閱《 使用者指南》中的 [AMS 護欄](https://docs.aws.amazon.com/managedservices/latest/userguide/security-mgmt.html#detective-rules)。