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

# 建議
<a name="recommendations"></a>

現在您已對單一雲端、混合雲端和多雲端有基本的了解，本節提供選擇模型的詳細建議。
+ [選取主要的策略性雲端供應商](primary-provider.md)
+ [建立 CCoE](establish-ccoe.md)
+ [區分 SaaS 應用程式和基礎雲端服務](saas-apps.md)
+ [為每個雲端服務供應商建立安全與控管要求](security-governance.md)
+ [盡可能且實際地採用雲端原生受管服務](managed-services.md)
+ [當現有的現場部署投資鼓勵持續使用時，實作混合架構](hybrid-architecture.md)
+ [僅針對無法透過單一雲端供應商滿足其技術或業務需求的工作負載保留多雲端](multicloud.md)

# 選取主要的策略性雲端供應商
<a name="primary-provider"></a>

雲端採用提供了對 IT 現代化、成本效益和創新至關重要的大量優勢。不過，採用超過有限 SaaS 應用程式的雲端技術可能會帶來教育機構必須仔細規劃的挑戰，以避免不必要的成本和複雜性。在雲端實作工作負載所涉及的技術和業務變更需要員工啟用和調整核心基礎設施，包括聯網、安全、管理和操作。

有效解決這些挑戰的最佳方法，特別是如果您的組織處於雲端之旅的早期階段，就是選擇主要的策略性雲端供應商來支援大多數工作負載。從專注於該供應商的採用開始，以便您可以簡化和加速實現雲端利益。選取主要雲端提供者並非不可復原的專屬決策。它可讓您的組織反覆發展您的雲端採用。首先，您可以專注於一些服務，然後視需要擴展到其他雲端服務，而不會延遲雲端的整體優勢。這種方法可最大限度地提高您組織利用供應商功能的能力，專注於並開發員工技能和第三方合作夥伴關係，並簡化廠商管理。

我們看到客戶嘗試同時採用多個雲端供應商，展開雲端之旅，但之後遺棄了該決策及其帶來的複雜性。在其文章中，Gartner 會分享此洞見：[規劃雲端策略的 6 個步驟](https://www.gartner.com/smarterwithgartner/6-steps-for-planning-a-cloud-strategy)，其中步驟 2 是「優先考慮多雲端架構中的主要供應商」。

每個雲端供應商都會推出不同的操作和支援模型、身分和存取管理、聯網、操作、合規功能等。**最好一次掌握一個雲端供應商的操作模型。 **然後，您可以在合理化的情況下反覆和遞增地整合其他雲端服務。許多因素可能會影響您採用主要雲端供應商的決定，但請使用下列關鍵問題來引導您的選擇。
+ **供應商提供的服務廣度和深度為何？**

  不同的雲端供應商提供不同的服務。至少，請確定您的主要供應商具備支援所有功能需求的必要功能，以及安全性、控管和自動化等交叉切割、營運需求。選擇提供這些功能的供應商，其創新和卓越營運記錄經過驗證。不僅考慮您的應用程式，也考慮您的資料。考慮未來的資料整合和傳輸模式，以限制供應商之間移動大量資料的成本、延遲和複雜性。選擇盡可能具有最大服務廣度和深度的提供者，以滿足您目前的應用程式和資料需求，並釋放新的使用案例，以滿足機構隨時間變化的需求。 
+ **供應商可以支援您的所有安全與合規需求嗎？**

  在教育中，安全和合規對於任何技術部署都至關重要。選擇能夠滿足您的所有安全和合規需求的雲端供應商。等工具[AWS Artifact](https://aws.amazon.com/artifact/)可以透過提供中央資源來隨需存取安全性和合規報告，協助您評估提供者。不僅要考慮雲端供應商自有基礎設施和服務的安全性和合規性，還要考慮使用這些服務架構安全、合規解決方案的難易度。偏好提供一些預先建置解決方案、快速入門和規範指引組合的提供者，以加速您安全採用雲端。
+ **供應商是否有強大的合作夥伴網路？**

  沒有組織單獨進行雲端轉型。為了加速採用，您應該使用雲端供應商及其合作夥伴網路的服務和專業知識。此網路包括提供在 上執行、整合或支援雲端技術之軟體的技術合作夥伴，以及可協助您在雲端設計、建置、執行和管理自有應用程式的諮詢合作夥伴。您會發現許多教育技術供應商、獨立軟體供應商 (ISVs)、顧問和已與之合作的經銷商都是雲端供應商合作夥伴網路的成員。偏好擁有最強大合作夥伴網路且具有經審核能力的雲端供應商。擁有經過驗證的產業和技術專業知識的合作夥伴至關重要。
+ **供應商提供哪些支援和啟用？**

  若要成功採用任何新技術，您需要要求訓練和協助的機制，包括最佳實務建議、組態指導和中斷修正問題解決方案。選擇提供強大支援和訓練選項的雲端供應商，將讓您為成功做好準備。探索供應商的官方支援模型和資源，以及任何可用的第三方或社群型資源，例如部落格、論壇、影片和操作指南。不僅考慮供應商的技術支援計劃，還考慮專注於業務和文化轉型的計劃。例如，[AWS 雲端採用架構 (AWS CAF)](https://aws.amazon.com/cloud-adoption-framework/) 透過專注於包括業務流程和人員的觀點，而不只是技術，協助組織進行數位轉型。偏好提供廣泛訓練選項的雲端供應商，以及經過驗證、可靠的支援模型和社群。

# 建立 CCoE
<a name="establish-ccoe"></a>

考慮透過轉型辦公室或雲端[卓越中心 (CCoE)](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html) 發展您的雲端領導職能。CCoE 開發並宣傳在整個組織中大規模實作雲端技術的方法。為了成功採用雲端，請設計您的 CCoE 以包含代表，他們可以為參與的團隊和部門發言。從小規模開始並逐步發展 CCoE，以因應您在轉型過程中的需求。您的主要雲端供應商代表，例如 AWS 您的帳戶管理員和解決方案架構師，可以提供資源來引導您建立 CCoE。CCoE 可加速您建立主題專業知識、達成接受、獲得整個組織的信任，以及建立符合任務需求的有效指導方針。沒有適用於每個機構的單一組織結構，但下列問題可協助您設計自己的 CCoE。
+ **您應該在 CCoE 中包含誰？**

  一開始，CCoE 可能只包含少數早期採用者和雲端擁護者。CCoE 可能仍然很小，但應該發展為包括可以同時代表業務職能和技術職能受到雲端採用影響的擁護者。業務職能包括變更管理、利益相關者需求、控管、訓練、採購和通訊。這些函數通常由您機構的管理和教學團隊的成員表示。技術功能包括基礎設施、自動化、操作工具、安全性、效能和可用性。這些函數通常由您機構的 IT 團隊的成員表示。CCoE 也應視需要尋求讓廠商和合作夥伴參與，以提供主題專業知識。CCoE 是活體組織。其成員資格、形式和函數可能會隨著時間而改變，甚至可能在未來的成熟期解散。
+ **CCoE 如何與其利益相關者互動？**

  CCoE 為其他團隊提供服務，且僅用於通知和啟用成功的雲端採用。查看各個部門、學校和函數中 CCoE 的內嵌部分。這可讓您存取更廣泛的資源和更快的內部意見回饋。專注於及早在利益相關者之間建立合作夥伴關係和開放溝通管道，以在機構內建立信任並打破組織孤島。CCoE 應該已定義與利益相關者通訊、收集意見回饋和訓練使用者的機制。CCoE 的成功指標應該反映這類協同合作和通訊。如果只根據建置技術來衡量團隊，將會建置更多技術，但其使用方式和結果將成為事後考量。您的指標應該改為測量物件，例如透過 CCoE 工作變得自給自足的團隊數量、CCoE 在計劃關鍵路徑上的次數、所持有的訓練事件數量，或採用 CCoE 輸出的廣度。建構良好、信任的 CCoE 可以是建立在信任之上的大型組織轉型的基石。
+ **您應該如何建立 CCoE？**

  大多數組織都使用特定的目標試驗專案開始採用雲端。在這些專案中建立 CCoE。良好的開始對於定義整個旅程的成功至關重要。
  + **從業務問題開始。**基於技術的技術是錯誤的策略。如果您正在試驗雲端技術，請識別令人信服的業務使用案例，無論它看起來有多小。然後，從該使用案例恢復工作，設定技術如何提供協助的明確目標。請勿在孤島中實作解決方案。在專案實作之前和期間，接受業務利益相關者的持續輸入。所有成功的雲端專案都依賴與將使用 技術的機構單位緊密合作。
  + **從小開始。**選擇提供雙向大門的低風險專案。這表示專案是可逆的，任何錯誤都可以快速修正。試行專案都與實驗有關。避免大規模的高風險專案可讓您更好地控制實作和結果。它有助於鎖定特定、可定義的問題，而不是廣泛的目標。例如，如果自動化是最終目標，則目標是自動化特定任務，而不是整個任務。
  + **定義和測量結果。**設定明確的指標，以評估每個專案的進度和效能。預先定義所需的結束狀態，以避免利益相關者之間不相符的期望。與企業利益相關者和組織內的其他領導者緊密合作，以定義期望和可衡量的收益。將結果翻譯為非技術語言也很重要。討論機構目標，例如專案如何改善保留率和減少流失率、如何降低成本並提高交付速度等。
  + **從舒適區域開始。**在貴機構熟悉的網域內選擇專案。如此一來，您就可以確保專案具有有意義的、可理解且實際影響的目標。這類專案將建立可信度，並為您的組織帶來更大的長期結果。例如，如果您已經具備資料分析的專業知識，則可以從 分析專案開始，同時利用您現有的技能來開始雲端之旅。每個機構都有不同的專業知識，需要尋找其獨特的元件來制定成功的數位轉型策略。

# 區分 SaaS 應用程式和基礎雲端服務
<a name="saas-apps"></a>

大多數教育機構已採用軟體即服務 (SaaS) 應用程式。SaaS 為您的機構提供由服務供應商執行和管理的完整解決方案。常見的 SaaS 應用程式包括文字處理和電子郵件等生產力應用程式，但 SaaS 選項也適用於許多關鍵任務工作負載，例如企業資源規劃 (ERP)、學生資訊系統 (SIS) 和學習管理系統 (LMS)。當您的機構採用 SaaS 產品時，您的 IT 團隊不必考慮如何維護服務或如何管理基礎設施，您的使用者只需要使用服務。此交付模型可減少 IT 人員的管理負擔。許多機構選擇在其 IT 策略中採用「SaaS first」方法，特別是如果他們的 IT 團隊缺乏足夠的時間、資源或技能集，以充分自我託管相同的應用程式時。即使您有自行託管的資源，採用 SaaS 解決方案並改為投資其他專案仍可能更具成本效益。

當您使用 SaaS 應用程式時，您的 IT 團隊不需要管理基礎基礎設施，因此廠商託管應用程式的位置 （內部部署資料中心、主要雲端提供者或替代雲端提供者） 會變得較不重要。在您選擇主要的策略性雲端提供者之後，您可以選擇使用託管在其他雲端提供者或內部部署的供應商資料中心的 SaaS 產品。相反地，即使您的 SaaS 應用程式託管在一個雲端提供者中，您也可以根據非 SaaS 工作負載的提供者強度選擇不同的主要、策略雲端提供者。對於 SaaS，託管環境之間的差異不如對自我託管應用程式重要。不過，在評估 SaaS 在 IT 策略中如何與雲端搭配時，您仍應考慮下列重要問題。
+ **SaaS 應用程式是否具有高可用性和可擴展性？**

  許多廠商已決定為其 SaaS 產品採用雲端。如此一來，廠商便能夠實現提高可用性和可擴展性的雲端優勢。此外，由於廠商可以採用雲端的共同責任模型，而不是管理和維護實體基礎設施，因此他們可以投入更多時間和資源來提供新功能。由於這些優點，您應該偏好以雲端為優先的提供者，並提供雲端託管解決方案。
+ **SaaS 應用程式能否滿足您的安全需求？**

  評估 SaaS 時，請務必了解應用程式存放哪些資料、如何使用該資料，以及採取哪些安全控制來保護該資料。雖然您可能無法像在自己的自我託管環境中一樣直接控制資料儲存，但您應該確保廠商具有適當的機制和控制，以適當處理您的資料。請注意 SaaS 解決方案內建了哪些安全功能，以及哪些功能需要額外的組態。雲端可讓 SaaS 供應商建置更多可用且可擴展的解決方案，而且由於[共同的責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)，也可以建置更安全的解決方案。您應該偏好在其解決方案中利用雲端安全工具和服務的供應商。
+ **誰擁有 SaaS 應用程式資料，以及如何存取它？**

  當您使用 SaaS 時，您會信任提供者正確處理您機構的資料。請務必檢閱 SaaS 應用程式的服務條款和服務層級協議，以了解資料擁有權、可用性和耐久性等因素。評估備份或匯出資料的機制；如果您決定切換供應商或供應商停止服務，這些機制尤其重要。
+ **無論您的環境為何，您的其他服務和自我託管應用程式是否可以與 SaaS 應用程式整合？**

  採用 SaaS 解決方案時，您可以輕鬆地假設共用相同託管環境 （即使用相同雲端提供者或相同廠商資料中心的應用程式） 的 服務和應用程式將具有更無縫的整合。不過，目前大多數 SaaS 解決方案都廣泛支援 API 和第三方整合，因此請勿將 自己侷限於在相同環境中託管的解決方案。如果存在必要的整合，則解決方案不需要共用相同的基礎環境。例如，假設您使用 SaaS 解決方案，例如 Google Drive 或 Microsoft OneDrive 進行雲端型學生檔案儲存。若要提供虛擬桌面和應用程式串流給您的學生，您可以判斷 [Amazon WorkSpaces 應用程式](https://aws.amazon.com/appstream2/)最適合您的需求。雖然這些服務在不同環境中執行，但 WorkSpaces 應用程式具有與 Google Drive 和 Microsoft OneDrive 的原生整合，因此您的學生可以繼續使用其現有的儲存體。
+ **SaaS 應用程式是否支援集中式身分管理？**

  為了避免您的 IT 團隊必須管理不同的身分存放區，而您的使用者必須記住多組登入資料，請確定您的 SaaS 解決方案支援與您現有的身分管理或單一登入解決方案整合。分段身分管理可降低生產力，並可能導致錯誤的安全實務，例如權限隱含和密碼脆弱。如果您所需的 SaaS 解決方案不支援單一登入或現有的身分存放區，請評估採用解決方案的商業價值是否超過使用者和員工增加的負擔。
+ **如何保護與 SaaS 應用程式的網路通訊？**

  在某些情況下， 您可能需要自我託管的應用程式才能與 SaaS 應用程式通訊。一般而言，此通訊將透過透過適當的身分驗證和授權機制保護APIs 進行。不過，根據兩個應用程式的託管環境，可能需要替代或其他機制來簡化或保護該通訊。例如，如果您與雲端提供者自行託管應用程式，且需要將其與同一雲端提供者託管的 SaaS 應用程式整合，廠商可能會提供數個連線選項。您可能可以使用雲端特定的互連連線、私有 APIs 或私有介面，例如 [AWS PrivateLink](https://aws.amazon.com/privatelink/) ，以防止該通訊周遊公有網際網路。同樣地，如果您的現場部署應用程式透過 等服務與雲端提供者建立專用網路連線[AWS Direct Connect](https://aws.amazon.com/directconnect/)，您可以使用相同的連線與在相同雲端提供者上託管的 SaaS 應用程式通訊。

# 為每個雲端服務供應商建立安全與控管要求
<a name="security-governance"></a>

教育機構必須達成各種合規、控管和網路安全目標。無法達成這些目標的風險可能包括機構評價損失、貨幣罰款、勒索軟體、敏感資料外洩、智慧財產權盜竊，以及任務關鍵職能降級或完全遺失。由於[共同的責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)，採用雲端服務的機構可以透過將一些基礎設施安全的責任卸載給雲端服務供應商來減輕管理負擔。此外，您可以受益於專門建置的雲端原生安全服務，這些服務在內部部署中提供通常不可用、難以管理或成本高昂的功能。範例包括[AWS WAF](https://aws.amazon.com/waf/)用於 Web 應用程式保護的服務，[AWS Shield](https://aws.amazon.com/shield/)用於分散式拒絕服務 (DDoS) 保護的服務，以及用於威脅偵測的 [Amazon GuardDuty](https://aws.amazon.com/guardduty/)。成功的雲端安全與控管策略可讓 IT 和安全團隊專注於建置設計上安全的系統、協助機構快速適應不斷發展的任務需求，並為講師和研究人員提供安全的學習和創新環境。若要評估您的安全與控管需求，請考慮下列重要問題。
+ **您的工作負載必須符合哪些合規架構？**

  教育機構必須遵守許多合規架構，因為他們支援許多利益相關者和工作負載。這些合規架構包括家庭教育權利與隱私權法案 (FERPA)、健康保險流通與責任法案 (HIPAA)、聯邦風險與授權管理計劃 (FedRAMP)、網路安全成熟度模型認證 (CMMC)、國際武器貿易法規 (ITAR)、刑事司法資訊服務 (CJIS) 和支付卡產業資料安全標準 (PCI DSS)。在某些情況下，例如使用 CMMC，在相關工作負載通過合規認證之前，不會發行研究授予資金。每個架構都是唯一的，可能僅適用於一部分的工作負載。請確定您知道哪些工作負載必須遵循哪些要求，而且能夠在每個工作負載環境中達成這些要求。在雲端環境中，請確定您了解與雲端供應商的責任相比的責任。您應該具備實現和維護合規所需的知識、資源和技能集。
+ **您有哪些機制可在多個雲端提供者之間強制執行合規性，而不會抑制創新？**

  如果您的學術機構是第一次使用雲端，我們建議您選擇一個主要策略雲端服務供應商，並專注於了解如何架構、設計和操作設計上安全的雲端環境。理想情況下，自動內嵌在自助式系統中的安全控制，可讓使用者快速部署安全雲端環境，並盡可能減少 IT 團隊介入。專注於單一供應商會限制您必須投入的資源量和時間，以確保安全性和合規性。最成功的機構會選擇可支援大多數合規要求的雲端服務供應商、擁有強大的合作夥伴網路、提供預先建置的合規解決方案，以及提供安全的自助式自動化。如果您必須確保跨多個雲端提供者的安全性和合規性，則需要額外的投資來建置技能集和資源，以管理每個環境的合規性。如果每個雲端提供者使用不同的基礎環境或登陸區域，您需要了解每個登陸區域可以支援的合規標準和要求，這可能會決定是否可以在該提供者上託管特定工作負載。您可以個別管理每個供應商的合規，或使用自訂建置的或合作夥伴解決方案來集中跨供應商的管理。 [AWS Marketplace](https://aws.amazon.com/marketplace)提供也可滿足您的合規需求的統包解決方案。
+ **如何評估和控制多個雲端供應商的成本和用量？**

  如果您的學術機構是初次使用雲端，我們建議您建立成本可見性和控制機制，以深入了解哪些雲端服務正在使用、哪些雲端資源所屬、這些雲端資源的用途，以及透過最佳化耗用量可節省哪些潛在成本。機構可以與其雲端服務供應商合作，遷移和現代化關鍵任務系統，從而實現顯著的投資回報，因為他們可以協商企業級協議、受益於大量定價，並利用雲端服務供應商的專業知識。如果您必須控制多個供應商的成本和用量，請考慮如何彙總和分析每個供應商的成本和用量，無論是使用內部程序和工具或使用合作夥伴解決方案。許多組織開始將雲端財務操作 (FinOps) 識別為關鍵功能，並分配資源來宣傳和實作雲端成本管理和最佳化的功能。
+ **您是否有可隨時間輕鬆管理使用者許可的機制？**

  我們建議學術機構在第一次接近雲端時了解核心利益相關者的需求。機構系統的使用者包括學生、教職員、研究人員、IT 人員、管理人員、安全人員、一般大眾和第三方合作者。您應該識別這些使用者的核心需求，並確保您擁有適當的機制來授予他們雲端服務的存取權。不同類型的使用者需要不同類型的雲端服務存取權。例如，學生、教職員和一般大眾需要存取應用程式；IT 人員、管理員和安全需要存取雲端基礎設施；研究人員及其第三方協作者需要存取安全的研究環境；教職員需要存取安全教學環境，甚至可能想要為學生提供雲端技術的實作存取。您應該備妥工具，以自動化方式[集中管理這些身分](identity-sso.md)，並使用已建立的程序來識別、授予和撤銷許可，因為角色和責任會隨著時間而變更。
+ **您是否有適當的機制來將新系統與身分管理解決方案整合？**

  我們建議學術機構輕鬆將新系統與其身分管理系統整合。這可讓利益相關者採購和建置可輕鬆整合至身分管理系統的系統，藉此為機構提供支援各種關鍵任務功能的彈性。透過簡化整合程序，利益相關者不太可能使用自己的存取控制措施，這可能不會強制執行安全最佳實務，例如單一登入、通行金鑰和多重驗證 (MFA)。請確定您的身分管理系統可以透過原生整合或業界標準通訊協定，與必要的系統相互操作。
+ **您是否有適當的機制來啟用有效的事件偵測和回應？**

  教育機構通常是網路攻擊和勒索軟體的目標。為了協助有效地偵測和回應這類事件，我們建議分叉的方法：
  + 將您的工作重點放在自動嵌入雲端環境中的安全控制形式的預防性措施上。
  + 實作偵測功能，協助網路事件回應者及時偵測、遏制和緩解安全漏洞。

與合規一樣，您必須確保您擁有可偵測、防止和回應每個環境中事件的資源、技能集和工具。透過專注於單一主要雲端提供者，您可以限制所需的資源。沒有成熟安全營運團隊的學術機構，應尋求獨立的軟體廠商、受管偵測和回應供應商，以及網路安全顧問協助這些領域。

# 盡可能且實際地採用雲端原生受管服務
<a name="managed-services"></a>

當您一開始考慮如何利用雲端服務時，使用您的團隊熟悉的基礎設施服務和開發工具，似乎是最佳的前進途徑。不過，選取雲端原生受管服務，特別是無伺服器選項，可以大幅降低成本、工作量和複雜性。

雲端原生的受管服務可消除許多未區分的 IT 任務，這些任務需要員工的時間和精力，而這些任務可能會更好地花費在以任務為中心的活動上。此外，隨著提供者改善其服務的功能，您的解決方案自然會繼承效率、安全性、彈性、效能和其他特性的增量改善。例如，全受管資料庫服務是功能豐富的關聯式資料庫管理系統，但您不需要佈建和管理資料庫執行所在的基礎伺服器和作業系統。這可消除當您在自己的資料中心或雲端佈建的自我管理虛擬伺服器上維護關聯式資料庫時，通常需要的管理任務。下圖說明此差異。

![\[比較自我管理和全受管資料庫服務的責任\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-education-hybrid-multicloud/images/db-services.png)


當您比較任何雲端原生受管服務與類似的自我管理方法時，消除基礎設施管理的好處很明顯。因此，每當您需要部署購買或自訂開發的應用程式將在其上執行的元件時，您應該使用雲端原生的受管服務來減少時間和精力。

當您的團隊負責在雲端中建置、部署或管理解決方案時，請使用雲端原生的受管服務，充分利用您雲端供應商的差異化功能和創新。此策略可讓您選擇、整合和部署雲端服務，以減少這些專案所需的時間和精力，同時提高其彈性和安全性。為了實現成功的雲端策略，請考慮在將自訂解決方案遷移至雲端、在雲端開發新解決方案，或在雲端部署授權軟體時採用這些雲端原生*建置區塊*。當您評估雲端原生受管服務的選項時，請考慮下列重要問題。
+ **您是否需要將更多員工的時間和精力集中在教育任務的核心功能上？**

  管理伺服器，即使是虛擬伺服器，都需要時間和注意，以確保它們與系統軟體升級和修補程式保持最新狀態。使用為您處理這些任務的 受管服務，可讓您將 IT 人員的時間導向更直接符合機構任務的活動。例如，如果您需要部署容器，請考慮無伺服器受管服務，例如，[AWS Fargate](https://aws.amazon.com/fargate/)這樣您就不必設定和維護伺服器。透過消除採購、佈建和管理基礎基礎設施的需求，您可以專注於提供新功能、最佳化效能並改善使用者體驗。當您針對自我管理選項評估受管服務時，請考慮此優點。
+ **您的團隊需要哪些努力才能採用雲端原生受管服務？**

  使用雲端原生的受管服務設計和實作解決方案可能有一種學習曲線，但這些工作將在解決方案生命週期內透過降低成本、時間和複雜性來償還。由於雲端運算的隨需pay-as-you-go特性，雲端原生服務可讓您以更靈活的方式快速迭代和實驗，同時避免前期投資。這會導致創新增加和專案時間表縮短。不過，為了有效地實現這些好處，請考慮採用和使用服務可能需要什麼，例如員工訓練最佳使用模式和程式碼重構，以適應服務特定的 APIs。即使服務使用業界標準或開放原始碼 APIs，您可能需要重構或設定應用程式來處理功能差異或版本不符。
+ **您目前如何部署和管理基礎設施？ 您需要維持該層級的控制嗎？**

  有多種方式可以託管和管理雲端中的基礎設施，包括使用裸機主機、虛擬機器、受管容器服務和無伺服器產品。即使您目前在內部部署環境中使用類似的基礎設施，例如虛擬機器或容器，請考慮替代方法是否適合某些工作負載。例如，不要在虛擬機器上執行所有應用程式，請考慮容器化您的應用程式，並利用 [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/) 等受管容器服務。這可能需要重構，但您可以使用 等工具[AWS App2Container](https://aws.amazon.com/app2container/)來簡化和協助容器化。進一步執行此操作，而不是為所有元件部署伺服器或容器，請考慮完全無伺服器選項。無伺服器技術具有自動擴展、內建高可用性和pay-for-use模式，可提高敏捷性和最佳化成本。同時，他們不需要管理伺服器和規劃容量。等無伺服器運算服務[AWS Lambda](https://aws.amazon.com/lambda/)是無伺服器架構的核心。Lambda 支援常見的程式設計語言，並允許開發人員專注於應用程式程式碼，而不是管理基礎設施。探索每個工作負載的這些選項，並考慮學習曲線、管理開銷、成本和授權等因素。
+ **您是否必須部署和管理任何授權軟體的基礎設施？**

  當您從獨立軟體廠商 (ISVs) 部署和管理授權軟體時，使用雲端基礎設施模擬內部部署似乎很合理。例如，您可能會考慮將內部部署虛擬機器取代為雲端託管的虛擬機器。雖然這是可行的選項，但請考慮您是否可以使用雲端原生受管服務取代架構的任何元件。例如，您可以使用全受管資料庫服務取代自我管理的資料庫伺服器，在執行相同的資料庫引擎時減輕管理負擔。許多 ISVs已經使用利用 受管服務的雲端架構，甚至可能提供預先建置的範本來簡化部署。如果可能，您應該偏好提供方案指引和支援雲端部署的 ISVs。將授權軟體部署至雲端之前，請務必諮詢 ISV，以了解雲端環境授權與內部部署授權有何不同。
+ **您是否擔心使用受管服務可能會導致廠商鎖定？**

  許多雲端原生的受管服務都是為了支援常見的產業標準和 APIs而建置。例如， [AWS Glue](https://aws.amazon.com/glue/)和 [Amazon EMR](https://aws.amazon.com/emr/) 等分析服務是以產業標準處理和儲存架構為基礎，例如 Apache Spark 和 Apache Parquet。 [AWS Lambda](https://aws.amazon.com/lambda/) 原生支援 Java、Go、Microsoft PowerShell、Node.js、C\$1、Python 和 Ruby 程式碼。[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 支援多個版本的常見資料庫引擎，包括 SQL Server、Oracle、PostgreSQL 和 MySQL。當 服務具有專屬 APIs 時，原生或合作夥伴解決方案可能可以使用通用、不區分雲端的通訊協定與 APIs 互動。例如，[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) 具有用於直接整合的服務特定 API，但您也可以在使用 時，使用網路檔案系統 (NFS)、伺服器訊息區塊 (SMB) 和網際網路小型電腦系統界面 (iSCSI) 等標準儲存通訊協定與其互動[AWS Storage Gateway](https://aws.amazon.com/storagegateway/)。您仍應專注於選擇最符合您需求的雲端原生受管服務，同時盡可能降低營運開銷，但您可能偏好使用或提供常見業界標準和通訊協定的服務。

# 當現有的現場部署投資鼓勵持續使用時，實作混合架構
<a name="hybrid-architecture"></a>

大多數教育機構已投資各種規模的內部部署資料中心，以託管企業應用程式、資料儲存解決方案、最終使用者運算 (EUC) 環境和共用運算資源。這些資料中心中的所有資源都受到不同的重新整理週期影響，您必須在其中考慮未來的成長和佈建足夠的容量以適應尖峰規模，這可能需要一年幾次。因此，資源通常會閒置，直到下一個重新整理週期。規劃、編列預算、採購和部署新硬體可能需要數週的時間，如果不是數月或更長時間。這個冗長的程序會阻礙創新，並可能延遲學習和研究。

雲端運算解決了許多這些挑戰。雲端提供隨需、pay-as-you-go 資源，因此您可以更緊密地比對目前容量與實際需求，而無需大型的前期規劃和投資。但是，如果您已經對內部部署硬體和資源進行了重大投資，您應該尋求有效地利用這些資源，並根據需要透過混合模型中的雲端技術增強這些資源。

成功的混合雲端策略會利用現有的投資，同時提供比單獨使用這些投資更高的敏捷性、可擴展性和可靠性。下列考量事項可協助您開始使用。
+ **當您必須託管新的工作負載時，是否先考慮雲端？**

  您同時使用公有和私有雲端基礎設施的方式會定義混合雲端策略。 雲端優先方法並不表示雲端是所有工作負載的更佳選擇。不過，當您規劃新的工作負載時，請評估雲端做為第一個選項，尤其是需要新技術或超過內部部署可用儲存和運算容量的工作負載。具有暫時性、不一致的使用模式、需要快速結果、易於攜帶或需要最新硬體的工作負載，是雲端可擴展性和彈性的理想候選項目。此外，考慮工作負載是否會受益於任何無法在內部部署使用的雲端原生受管服務，即使您有可用的容量。
+ **您是否了解現場部署環境的 TCO，並在進行新投資時與 CFO 合作？**

  我們建議您了解維護自己的內部部署資料中心的真實總擁有成本 (TCO)。擁有和操作內部部署基礎設施有許多隱藏成本，包括硬體、軟體和支援，以及設施、公用事業、保險和員工時數。這些成本可能會對員工生產力、營運彈性和業務敏捷性造成負面影響。評估您目前的授權結構及其續約和維護期間。當您計劃進行新的投資時，與您的財務長 (CFO) 合作可協助您識別所有隱藏成本。某些授權可能會在雲端中提供自攜授權 (BYOL) 選項，或者對雲端服務來說可能更有利或更不有利。了解目前基礎設施的真實 TCO，可協助您優先考慮對組織總 TCO 影響最大的工作負載採用雲端。您的 AWS 客戶團隊隨時提供工具，協助您更了解內部部署 TCO。
+ **您需要哪些基礎設施來支援混合部署？**

  若要成功採用混合模型，您需要基礎網路、安全和基礎設施工具。請確定您可以與雲端供應商保持足夠的網路連線。這可以透過現有網際網路連線、虛擬私有網路 (VPNs) Direct Connect、專用連線，例如第三方連線供應商，或 [Internet2](https://internet2.edu/) 和區域研究和教育網路的組合。請確定您在內部部署和雲端環境中擁有統一的身分和存取管理。建立工具和程序，以強制執行一致的安全性、成本和用量防護機制。
+ **您的 IT 人員是否已準備好操作混合部署？**

  雲端服務可能需要您的團隊可能沒有的特定技能集。若要限制提升 IT 人員技能以有效採用雲端所需的訓練和啟用，請考慮雲端提供者是否提供在內部部署和雲端之間重複使用和建置現有技能集的任何服務。例如，如果您使用 並熟悉 Kubernetes，您可以考慮使用 [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 或 [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/)。如果您使用 且熟悉 NetApp，您可以考慮使用 [Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/)。同樣地，也請考慮您使用的任何現有合作夥伴解決方案是否具有雲端環境的原生整合或支援。
+ **您可以將長期儲存或低用量運算從內部部署卸載到雲端嗎？**

  雲端儲存為長期資料儲存提供數種經濟實惠的選項。例如，[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) 提供各種針對不同使用案例最佳化的儲存層。如果您的機構需要長時間保留特定資料，請考慮冷儲存解決方案，例如 [Amazon Glacier](https://aws.amazon.com/s3/storage-classes/glacier/)。將此資料卸載至雲端儲存可以釋放寶貴的高效能內部部署儲存。這類服務[AWS Storage Gateway](https://aws.amazon.com/storagegateway/)可讓現場部署應用程式輕鬆透過標準通訊協定存取雲端儲存層，例如 SMB、NFS 和 iSCSI。同樣地，請考慮卸載不常或低用量的任何運算任務。如果您有專用於此類任務的內部部署伺服器，您可以改為使用可擴展的雲端運算服務，其中資源會隨需佈建，而且您只需為使用量付費。這些低成本、長期儲存和低用量運算選項也讓雲端成為備份和災難復原的理想選擇。您可以在雲端中使用安全、耐用、可擴展的儲存和運算來保護您的資料，並在發生災難時快速復原，而無需自行維護必要的儲存和運算基礎設施。
+ **現場部署是否有足夠的容量可以實驗和創新？**

  在固定大小的內部部署環境中缺乏彈性和敏捷性，可能會限制使用者可用的服務和技術。如果您有嚴格的重新整理週期，新的工作負載可能必須等到下一個週期才能實作。此操作模型可以限制實驗和緩慢創新。當您有新的或新的工作負載需要測試時，請考慮使用可擴展的彈性雲端服務。雲端資源可以隨需佈建和取消佈建，您只需為使用量付費，因此您可以*快速實驗和失敗*，同時將組織風險降至最低。
+ **您是否有獨特的合規或效能要求，迫使您將資料保留在內部部署？**

  具有嚴格資料駐留或延遲要求的工作負載可能會指示您將資料保留在內部部署或盡可能靠近使用者。對於這些使用案例，您可以優先使用現有的現場部署資源。不過，請考慮您的雲端提供者是否提供邊緣服務或機制，以在內部部署中使用雲端技術。Edge 服務可提供更接近您端點的資料處理、分析和儲存，並可讓您在標準雲端提供者資料中心之外部署工具。例如，AWS 提供 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) 和 等服務[AWS Wavelength](https://aws.amazon.com/wavelength/)，可在更接近最終使用者的特定位置部署應用程式。您也可以使用 [AWS Outposts](https://aws.amazon.com/outposts/)、[AWS Storage Gateway](https://aws.amazon.com/storagegateway/)、[Amazon ECS Anywhere](https://aws.amazon.com/ecs/anywhere/) 和 [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) 等服務，將雲端服務和功能帶入現有的資料中心。

# 僅針對無法透過單一雲端供應商滿足其技術或業務需求的工作負載保留多雲端
<a name="multicloud"></a>

*多雲端*是指使用來自多個 （兩個或更多） 雲端服務供應商的雲端服務。擁有多雲端策略可以提供某些好處，例如選擇解鎖多個雲端供應商的差異化功能，或能夠滿足單一雲端供應商可能無法滿足的資料主權要求。不過，針對您使用的每個提供者，請確定您擁有適當的人員、技能、訓練和工具集，以有效地使用該提供者。此外，如果您想要針對特定工作負載使用多雲端策略，則需要額外的資源來整合和交互操作每個雲端供應商的必要服務。**我們建議您只在效益超過增加的投資時，才考慮多雲端。**若要判斷您是否應該選擇多雲端策略，請考慮下列重要問題。
+ **您是否有資源和技能集來導覽不同雲端供應商提供的服務？**

  當多個雲端供應商提供各種產品和服務時，您的員工需要基本技能來導覽每個供應商的功能。視您使用的服務和功能而定，單獨使用一個雲端供應商的服務可能需要提升員工技能和進行訓練。如果您正在考慮多雲端策略，請評估現有的資源，以判斷有效使用來自多個雲端供應商的服務所需的額外技能集。您可能必須擴增員工，或投入額外的時間和金錢來提升技能和訓練，超越單一雲端供應商的需求。如果您已經有使用不同雲端供應商的個別團隊或使用者，請考慮將他們合併到主要雲端供應商的組織優勢，並依case-by-case而定。
+ **特定多雲端架構會帶來哪些額外的額外負荷？**

  多雲端的常見驅動因素是想要使用來自某個供應商的特定受管服務，該供應商具有可以與其他雲端供應商的服務區分的功能。例如，您可能想要針對基礎設施需求使用一個雲端提供者，並針對網域和目錄服務使用另一個提供者的受管服務。不過，即使該單一受管服務可減輕管理負擔並簡化該架構元件的管理，它可能會為其他工作負載帶來額外負荷，例如程式碼重構、私有連線需求或手動整合工作。預先識別此額外額外負荷，並確保它不會偏移或消除您的團隊從差異化服務獲得的好處。
+ **您將如何集中監控和管理跨雲端供應商？**

  當您開始使用來自不同雲端供應商的資源來部署應用程式和功能時，請考慮如何標記、監控和管理此類資源。每個供應商都有自己的工具，您可以延伸到其他環境。例如，您可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 監控關鍵指標和日誌、建立警示，以及在單一、混合和多雲端環境中視覺化您的應用程式和基礎設施。您也可以使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 來改善資源可見性和控制、快速診斷和修復操作問題，以及自動化程序，例如跨環境更新和修補虛擬機器。如果您有供應商工具無法支援的需求，您可以探索合作夥伴解決方案，但這些解決方案可能會增加額外的成本或整合工作。
+ **使用不同的雲端供應商時，如何透過自動化將基礎設施管理為程式碼？**

  當您在雲端執行資源時，自動佈建和管理資源可協助您有效率地 管理各種環境。APIs 和原生自動化工具因雲端供應商而異。如果可能，請考慮使用一組通用的協同運作和部署工具，以容納不同的雲端供應商資源。這可提供更大的彈性，並簡化跨多個雲端的操作。不過，個別使用每個供應商的原生自動化，並建立組織程序以確保適當的使用方式可能比較簡單。
+ **您是否有每個雲端供應商必須滿足的合規和法規要求？**

  您可能有規定儲存和處理資料方式的法規考量。專注於標準化政策 （例如網路流量、儲存和安全性），這些政策可自動套用到跨雲端供應商的每個雲端環境。考慮您的應用程式將如何與其資料通訊，並將其託管在相同的供應商上。如果您的應用程式及其資料分散在供應商之間，則很難確保您符合合規和法規要求。最好讓應用程式盡可能接近資料，以盡可能減少網路延遲、最大化資料輸送量，並限制資料輸出，同時簡化安全性和存取控制。
+ **當您跨雲端供應商部署應用程式時，是否能夠將 TCO 降至最低，並將定價折扣最大化？**

  在考慮多雲端時，請務必考慮總體擁有成本 (TCO)。跨多個雲端供應商執行應用程式可以提高營運成本和管理開銷，以維護和管理每個環境中的資源。此外，將用量分散到多個供應商，使得利用特定供應商的大量定價折扣或企業協議變得更加困難。當您判斷多雲端的優點是否需要增加 TCO 時，請將這些因素納入考量。