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

# AMS 模式和應用程式或工作負載
<a name="ams-modes-and-apps-ug"></a>

選擇正確的模式時，請考慮應用程式的操作和管理需求，方法是請求新的應用程式帳戶，或在現有的應用程式帳戶中託管應用程式。為每個應用程式或工作負載選擇適當的 AMS 模式取決於下列因素：
+ 環境將提供的 SDLC 生命週期函數類型 （例如，具有未修改變更的沙盒、具有一些頻繁變更的 UAT、具有最少變更且受到高度管制的生產）
+ 所需的控管政策 （在 OU 層級透過 SCPs 強制執行）
+ 營運模式 （如果您想要承擔營運責任，或想要將其委外至 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>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td><td rowspan="8">客戶負責</td></tr>
  <tr><td>持續性管理</td><td colspan="3">AMS 負責執行客戶選取的備份計劃</td><td>負責自助服務佈建服務 (SSP) 的客戶</td><td>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td></tr>
  <tr><td>執行個體層級存取管理</td><td colspan="3">使用內部部署網域透過單向 AD 信任管理的 AMS。需要受管基礎設施才能加入 AMS 網域</td><td>不適用</td><td>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td></tr>
  <tr><td>安全管理和帳戶層級存取管理</td><td colspan="3">所有受管帳戶的 AMS 責任</td><td>負責所有受管帳戶的 AMS</td><td>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td></tr>
  <tr><td>修補管理</td><td colspan="3">所有受管帳戶的 AMS 責任</td><td>負責自助服務佈建服務 (SSP) 的客戶</td><td>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td></tr>
  <tr><td>變更管理</td><td colspan="3">所有受管帳戶的 AMS 責任</td><td>負責自助服務佈建服務 (SSP) 的客戶</td><td>客戶負責在 AMS CM 系統外使用開發人員 IAM 角色佈建的資源</td></tr>
  <tr><td>佈建管理</td><td>AMS 中提供的佈建選項的規範和標準化</td><td>依照 AMS 規範標準直接使用 AWS Service Catalog 的 AWS 服務 API 的彈性</td><td>依照 AMS 規範標準直接使用 AWS 服務 API 的彈性</td><td>為 SSP 服務直接使用 AWS 服務 APIs彈性</td><td>直接使用 AWS 服務 API 進行佈建的彈性</td></tr>
  <tr><td>事件管理和稽核</td><td colspan="4">所有受管帳戶的 AMS 回應</td><td>客戶負責在 AMS 變更管理系統外使用開發人員 IAM 角色佈建的資源</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 等的 Data Lake 應用程式上反覆/最佳化</td><td>分散式帳戶/應用程式，例如沙盒、第三方受管應用程式</td></tr>
</tbody>
</table>


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

**注意**  
SSP 模式和開發人員模式之間的價格比較假設已佈建相同的 AWS 服務。

比較 AMS 模式與業務和 IT 目標

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


如所示，如果您要為應用程式尋找高度受控和標準化的控管模型，則 AMS 受管的標準變更、AWS Service Catalog 或直接變更模式是最適合的。如果您需要專注於應用程式創新的自訂控管模型，而不需要操作準備，請選取客戶受管模式。使用客戶受管模式，當您負責建立人員、程序和工具以支援操作功能時，可能需要更長的時間來操作應用程式，例如事件管理、組態管理、佈建管理、安全管理、修補程式管理等。