AMS 模式的真實使用案例

使用案例 1，透過時間敏感的資料中心退出來降低成本的必要業務：具有吸引人業務事件的企業，例如資料中心退出，有興趣在雲端上重新託管其內部部署應用程式。大多數現場部署庫存都由 Windows 和 Linux 伺服器組成，並混合作業系統版本。如此一來，客戶還希望利用遷移到雲端提供的成本節省，並改善其應用程式的技術和安全狀態。客戶想要快速移動，但尚未建置內部雲端操作專業知識。客戶必須找到重構的平衡，太多重構可能會對緊迫的時間軸造成風險。不過，透過一些重構，例如更新作業系統版本和最佳化資料庫，應用程式可以實現更高水準的效能。在此範例中，客戶可以選擇 AMS 受管 RFC 模式來重新託管大部分的應用程式。AMS 提供基礎設施操作，同時引導客戶操作團隊在雲端中安全操作的最佳實務。

AMS 受管 AWS Service Catalog 和 AMS 受管直接變更模式可為客戶提供額外的靈活性，同時實現相同的業務成果和目標。此外，客戶可以使用 AMS Operations On Demand (OOD) 產品，讓專用 AMS 操作工程師優先執行變更請求 (RFCs)。

將未差異化的基礎設施操作任務 （修補、備份、帳戶管理等） 卸載至 AMS 時，客戶可以繼續專注於最佳化其應用程式，並在雲端操作上提升其內部團隊。AMS 會每月向客戶提供節省成本的報告，並針對資源最佳化提出建議。在此使用案例中，如果在 Windows 2003 和 2008 等舊版作業系統上託管end-of-life應用程式，而客戶決定不重構，則這些應用程式也可以遷移到 AMS，並託管在利用客戶受管模式的帳戶中。

使用案例 2，在安全的 AMS 界限內使用 Lambda、Glue、Athena 建置資料湖：企業希望設定 Data Lake，以滿足 AMS 中多個應用程式的報告需求。客戶想要使用 S3 儲存貯體來儲存資料集，而 AWS Athena 會針對每個報告的資料集進行查詢。S3 和 AWS Athena 將部署在不同的 AMS 受管帳戶中。使用 S3 的帳戶也有其他服務，例如 Glue、Lambda 和 Step Functions，以建置資料擷取管道。在這種情況下，Glue、Lambda、Athena 和 Step Functions 被視為自助式佈建 (SSP) 服務。客戶也在帳戶中部署 EC2 執行個體，做為臨機操作工具/指令碼伺服器。客戶從請求 AMS 在其 AMS 受管帳戶中啟用 SSP 服務開始。AMS 會為客戶可擔任的每個服務佈建 IAM 角色，一旦該角色加入到客戶的聯合解決方案。為了方便管理，客戶也可以將個別 IAM 角色的政策合併為一個自訂角色，減輕在 AWS 服務之間工作時切換角色的需求。在帳戶中啟用角色後，客戶就可以根據其需求設定服務。不過，客戶必須使用 AMS 變更管理系統來請求其他許可，視其使用案例而定。

例如，若要存取 Glue 爬蟲程式，Glue 需要額外的許可。還需要其他許可才能建立 Lambda 的事件來源。客戶將使用 AMS 更新 IAM 角色，以允許 Athena 跨帳戶存取查詢 S3 儲存貯體。還需要透過 Lambda 的 AMS 變更管理更新服務角色或服務連結角色，以呼叫 Step Functions 服務，以及透過 Glue 讀取和寫入所有 S3 儲存貯體。AMS 與客戶合作，確保遵循最低權限的存取模型，並且請求的 IAM 變更不會過度寬鬆，並使環境面臨不必要的風險。客戶的資料湖團隊會花費時間規劃客戶架構特定服務所需的所有 IAM 許可，並請求 AMS 啟用這些許可。這是因為所有 IAM 變更都會手動處理，並經過 AMS 安全團隊的審核。應用程式部署排程中應考量處理這些請求的時間。

由於 SSP 服務在帳戶中運作，客戶可以透過 AMS 事件管理和服務請求請求支援和報告問題。不過，AMS 不會主動監控 Lambda 的效能和並行指標，或 Glue 的工作指標。客戶有責任確保為 SSP 服務啟用適當的記錄和監控。帳戶中的 EC2 執行個體和 S3 儲存貯體完全由 AMS 管理。

使用案例 3，在 AMS 中快速且靈活地設定 CICD 部署管道：客戶希望設定以 Jenkins 為基礎的 CICD 管道，將程式碼管道部署到 AMS 中的所有應用程式帳戶。客戶可能會發現它最適合在 AMS 受管直接變更模式 (DCM) 或 AMS 受管開發人員模式下託管此 CICD 管道，因為它可靈活地在 EC2 上設定具有所需自訂組態的 Jenkins 伺服器，並具有所需的 IAM 許可來存取 CloudFormation 和託管成品儲存庫的 S3 儲存貯體。雖然這也可以在 AMS 受管 RFC 模式中完成，但客戶團隊需要為 IAM 角色建立多個手動 RFCs，以針對 AMS 手動檢閱的最低許可集進行反覆運算。DCM 可讓客戶在 AWS 上實現其營運目標，同時避免在使用 AMS 受管 RFCs 模式時為 IAM 角色建立多個手動 RFC 的需求，以針對 AMS 手動檢閱的最低寬鬆許可集進行反覆運算。這需要時間和客戶方面的教育，才能提升 AMS 程序和工具。使用開發人員模式，客戶可以從「開發人員角色」開始，使用原生 AWS APIs 佈建基礎設施。設定此管道最快速且最靈活的方法是使用 AMS Managed-Developer 模式。開發人員模式提供最快速且最簡單的方式，同時犧牲操作整合，而 DCM 的靈活性較低，但確實提供與 RFC 模式相同的操作支援層級。

使用案例 4，AMS 基礎中的自訂操作模型：客戶正在查看截止日期驅動的資料中心退出，且其其中一個企業應用程式完全由第三方 MSP 管理，包括應用程式操作和基礎設施操作。假設客戶沒有時間重新考慮此應用程式，因此可以由 AMS 操作，則客戶受管模式是適合的選項。客戶可以利用 AMS 受管登陸區域的自動化和快速設定。他們可以利用集中式帳戶管理，透過集中式聯網帳戶控制帳戶販賣和連線。它還透過 AMS Payer 帳戶合併所有客戶受管帳戶的費用，以簡化其帳單。客戶可以靈活地設定其自訂存取管理模型，其 MSP 與用於 AMS 受管帳戶的標準存取管理不同。如此一來，使用客戶受管模式，他們可以設定 AMS 受管環境，同時滿足清空內部部署環境的業務需求。在此情況下，如果客戶也有要遷移至雲端的 Windows 應用程式，並選擇將他們移至客戶受管帳戶，則客戶必須負責建立雲端操作模型。視客戶轉換傳統 IT 程序及訓練人員的能力而定，這可能會複雜、昂貴且耗時。客戶可以透過將此類工作負載「抬高和轉移」到 AMS 受管帳戶，並將基礎設施操作卸載到 AMS 來節省時間和成本。