本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

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

既然您已经对单云、混合云和多云有基本的了解，那么本节将提供有关选择模式的详细建议。
+ [选择主要战略云提供商](primary-provider.md)
+ [建立一个 CCo E](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 Steps for Planning a Cloud Strategy](https://www.gartner.com/smarterwithgartner/6-steps-for-planning-a-cloud-strategy) 中分享了这一见解，其中步骤 2 是“Prioritize a primary provider in multicloud architectures”。

每家云提供商都引入了不同的运营和支持模式、身份和访问管理、网络、运营、合规性功能等。**最好一次掌握一家云提供商的运营模式。**然后，您可以在合理化的情况下，以迭代和增量方式整合其他云服务。许多因素都可能会影响您采用主要云提供商的决定，但请使用以下关键问题来指导您的选择。
+ **提供商所提供服务的广度和深度如何？**

  不同的云提供商提供不同的服务。至少确保主要提供商具备支持您所有功能需求以及安全、治理和自动化等跨领域运营需求必要的能力。选择能够提供这些能力、在创新和卓越运营方面拥有实绩的提供商。不仅要考虑您的应用程序，还要考虑您的数据。考虑未来的数据集成和传输模式，以限制在提供商之间移动大量数据带来的成本、延迟和复杂性。选择服务广度和深度尽可能大的提供商，既能满足您当前的应用程序和数据需求，又能解锁新使用案例以适应随时间变化的机构需求。 
+ **提供商是否能支持您的所有安全与合规需求？**

  在教育领域，安全与合规对任何技术部署都至关重要。选择能够满足您所有安全与合规需求的云提供商。通过提供按需访问安全与合规报告的中心资源，[AWS Artifact](https://aws.amazon.com/artifact/) 等工具可以帮助您评估提供商。不仅要考虑云提供商自身基础设施和服务的安全与合规，还要考虑使用这些服务构建安全、合规解决方案的难易程度。优先选择提供预构建解决方案、快速入门和规范指引的某种组合的提供商，以加快云的安全采用。
+ **提供商是否拥有强大的合作伙伴网络？**

  任何组织都无法独自完成云转型。为了加快采用速度，您应该利用云提供商及其合作伙伴网络的服务和专业知识。该网络包括技术合作伙伴（提供在云运行、与云技术集成或支持云技术的软件），以及咨询合作伙伴（可以帮助您在云设计、构建、运行和管理自己的应用程序）。您会发现，许多已经与您合作的教育技术提供商、独立软件供应商 (ISVs)、顾问和经销商都是云提供商合作伙伴网络的成员。优先选择拥有最强大的合作伙伴网络且其合作伙伴具备经过验证能力的云提供商。拥有具备成熟行业和技术专业知识的合作伙伴至关重要。
+ **提供商提供哪些支持和赋能？**

  要成功采用任何新技术，您需要请求培训和帮助的机制，包括最佳实践建议、配置指导和故障修复解决方案。选择能够提供强大支持和培训方案的云提供商，为您的成功奠定基础。探索提供商的官方支持模式和资源，以及任何可用的第三方或基于社区的资源，例如博客、论坛、视频和操作指南。不仅要考虑提供商的技术支持计划，还要考虑侧重于业务和文化转型的计划。例如，[AWS 云采用框架 (AWS CAF)](https://aws.amazon.com/cloud-adoption-framework/) 通过关注包括业务流程和人员在内的视角，而不仅仅是技术，来帮助组织实现数字化转型。优先选择能够提供广泛培训选项以及成熟、可靠支持模式和社区的云提供商。

# 建立一个 CCo E
<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 开发并宣传了一种在整个组织中大规模实施云技术的方法。要成功采用云技术，请设计您的 CCo E，使其包括可以代表相关团队和部门发言的代表。从小处着手，逐步发展 CCo E 以满足您在转型之旅中的需求。您的主要云提供商代表（例如您的 AWS 客户经理和解决方案架构师）可以提供资源来指导您完成创建 CCo E。 CCoE 可以提高您建立主题专业知识、获得认同、赢得整个组织的信任以及制定满足任务要求的有效指导方针的能力。不存在适用于每个机构的单一组织结构，但是以下问题将帮助您设计自己的 CCo E.
+ **你应该在你的 CCo E中加入谁？**

  一开始， CCoE 可能只包括少数早期采用者和云端拥护者。 CCoE 可能仍然很小，但它应该演变为包括能够代表受云采用影响的业务职能和技术职能的拥护者。业务职能包括变更管理、利益相关者要求、治理、培训、采购和沟通。这些职能通常由您所在机构的行政和教学团队成员代表。技术职能包括基础设施、自动化、运营工具、安全、性能和可用性。这些职能通常由您所在机构的 IT 团队成员代表。如有必要， CCoE还应设法让供应商和合作伙伴参与进来，以提供主题方面的专业知识。 CCoE 是一个活生生的组织。其成员资格、形式和职能可能会随着时间的推移而发生变化，甚至可能在未来某个成熟阶段解散。
+ **欧盟如何与 CCo其利益相关者互动？**

   CCoE 为其他团队服务，仅用于告知和实现云的成功采用。看看将 CCo E 的某些部分嵌入到各个部门、学校和职能中。这样便可实现对更广泛资源的访问以及更快速的内部反馈。重点在于尽早在利益相关者之间建立合作关系和开放的沟通渠道，以在机构内部建立信任并打破组织壁垒。 CCoE 应明确与利益相关者沟通、收集反馈和培训用户的机制。 CCoE的成功指标应反映这种合作和沟通。如果仅以构建技术来衡量一个团队，那么将会构建更多的技术，但其使用和成果却会被忽略。相反，你的指标应该衡量一些因素，例如通过 CCo E 的工作实现自给自足的团队数量、 CCo E 走上关键举措道路的次数、举办的培训活动数量或 CCo E 产出的采用广度。精心构建、值得信赖 CCo的企业可以成为建立在信任基础上的更大规模组织转型的垫脚石。
+ **你应该如何建立 CCo E？**

  大多数组织会从具体、有针对性的试点项目开始其云采用之旅。在这些项目中建立 CCo E。良好的开端对于整个旅程的成败至关重要。
  + **从业务问题入手。**为了技术而技术是一种糟糕的策略。如果您正在尝试云技术，请确定一个有说服力的业务使用案例，无论它看起来多么微不足道。然后，根据该使用案例进行反向推导，设定技术如何提供帮助的明确目标。不要在孤立环境中实施解决方案。在项目实施之前和期间，不断听取业务利益相关者的意见。所有成功的云项目都依赖于与将使用该技术的机构部门的密切合作。
  + **从小处着手。**选择一个提供“双向门”的低风险项目。这意味着该项目是可逆的，并且可以快速纠正任何错误。试点项目旨在进行实验。避免大规模、高风险的项目可以让您更好地控制实施和结果。它有助于针对具体的、可定义的问题，而不是设定宽泛的目标。例如，如果最终目标是自动化，那么就应该着眼于自动化特定任务，而不是整个工作。
  + **定义并衡量成果。**设定明确的指标以评测每个项目的进度和表现。提前明确定义所需的最终状态，以避免利益相关者的期望不匹配。与业务利益相关者和组织内的其他领导者密切合作，以确定期望和可衡量的收益。将结果转化为非技术语言也至关重要。从机构目标的角度进行阐述，例如项目如何提高客户留存率和降低客户流失率，如何降低成本和加快交付速度等。
  + **从舒适区开始。**在机构熟悉的领域中选择一个项目。通过这种方式，您可以确保该项目具备有意义、易理解且具有实际影响的目标。这样的项目将建立信心，为您的组织带来更好的长期结果。例如，如果您已经具备数据分析方面的专业知识，则可以从分析项目入手，在利用现有技能集的同时，开启您的云之旅。每个机构都有不同的专长，需要找到自身独特的组成要素，才能制定成功的数字化转型战略。

# 区分 SaaS 应用程序和基础云服务
<a name="saas-apps"></a>

大多数教育机构已经采用软件即服务（SaaS）应用程序。SaaS 为您的机构提供由服务提供商运行和管理的完整解决方案。常见的 SaaS 应用程序包括文字处理和电子邮件等生产力应用程序，但许多任务关键型工作负载中也存在 SaaS 选项，例如企业资源规划（ERP）、学生信息系统（SIS）和学习管理系统（LMS）。当您的机构采用 SaaS 产品时，您的 IT 团队不必考虑如何维护服务或如何管理基础设施，您的用户只需使用该服务即可。这种交付模式减轻了 IT 员工的管理负担。许多机构选择在其 IT 策略中采用“SaaS 优先”方法，特别是其 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 云端硬盘或 Microsoft 来存储基于云 OneDrive 的学生文件。要向学生提供虚拟桌面和应用程序流，您可能会认为 [Amazon Appl WorkSpaces ic](https://aws.amazon.com/appstream2/) ations最适合您的要求。尽管这些服务在不同的环境中运行，但 WorkSpaces 应用程序已与 Google 云端硬盘和 Microsoft 进行了原生集成 OneDrive，因此您的学生可以继续使用其现有存储空间。
+ **SaaS 应用程序是否支持集中式身份管理？**

  为防止您的 IT 团队不得不管理分散的身份存储和避免用户必须记住多组凭证，请确保您的 SaaS 解决方案支持与您现有的身份管理或单点登录解决方案集成。分散的身份管理会降低工作效率，并可能导致权限蔓延和弱密码等不良安全实践。如果所需的 SaaS 解决方案不支持单点登录或您现有的身份存储，请评估采用该解决方案的业务价值是否超过给用户和员工增加的负担。
+ **如何保护与 SaaS 应用程序的网络通信？**

  在某些情况下，您可能需要自托管应用程序才能与 SaS 应用程序通信。通常，这种通信将通过 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/)，采用云服务的机构可以通过将基础设施安全的部分责任分载给云服务提供商来减轻管理负担。此外，您可以受益于专门构建的云原生安全服务，这些服务提供的功能在本地部署中通常不可用、难以管理或成本高昂。示例包括 Web 应用程序保护、分布式拒绝服务防护和[AWS Shield](https://aws.amazon.com/shield/) GuardDuty用于威胁检测的 [Amazon](https://aws.amazon.com/guardduty/) 等服务。[AWS WAF](https://aws.amazon.com/waf/)DDo成功的云安全和治理策略使 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_cn/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、微软 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，但您也可以在使用 [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) 时通过网络文件系统（NFS）、服务器消息块（SMB）和互联网小型计算机系统接口（iSCSI）等标准存储协议与其交互。您仍应专注于选择最符合自身需求的云原生托管服务，同时最大限度地降低运营开销，但您可能更愿意使用或提供通用行业标准和协议的服务。

# 在现有本地投资激励继续使用时，实施混合架构
<a name="hybrid-architecture"></a>

大多数教育机构都投资了不同规模的本地数据中心，以托管企业应用程序、数据存储解决方案、终端用户计算（EUC）环境和共享计算资源。这些数据中心中的所有资源都要遵循不同的刷新周期，在此期间，您必须考虑未来的增长，并预调配足够的容量以容纳峰值规模，而这种规模每年可能只需要几次。因此，资源经常处于闲置状态，直到下一个刷新周期。规划、预算、采购和部署新硬件可能需要数周、甚至数月或更长时间。这种漫长的过程扼杀了创新，并可能延误学习和研究。

云计算解决了其中许多挑战。云提供按需 pay-as-you-go的 IT 资源，因此您可以更紧密地将当前容量与实际需求相匹配，而无需进行大量的前期规划和投资。但是，如果您已经对本地硬件和资源进行了大量投资，则应寻求高效利用这些资源，并根据需要在混合模式下使用云技术对其进行扩充。

成功的混合云策略可以利用现有投资，同时提供比仅靠这些投资能够支持的更高的敏捷性、可扩展性和可靠性。以下考虑因素可帮助您开始使用。
+ **当您必须托管新的工作负载时，是否会先考虑云？**

  如何同时使用公有和私有云基础设施，定义了您的混合云策略。云优先方法并不意味着云是所有工作负载的更好选择。但是，在规划新工作负载时，应将云作为第一选择进行评估，特别是对于需要新技术或超出本地可用存储和计算容量的工作负载。具有瞬态、不一致使用模式、需要快速结果、易于移植或需要最新硬件的工作负载是实现云可扩展性和弹性的理想选择。此外，还要考虑工作负载是否可从任何本地不可用的云原生托管服务受益，即使您确实有可用容量。
+ **您是否了解本地环境的 TCO，并在进行新投资时与 CFO 合作？**

  我们建议您了解维护自己本地数据中心的真实总拥有成本（TCO）。在本地拥有和运营基础设施有许多隐性成本，不仅包括硬件、软件和支持，还包括设施、公用事业、保险和员工工时。这些成本会对员工的工作效率、运营韧性和业务灵活性产生负面影响。同时评估您当前的许可结构及其续订和维护期限。与您的首席财务官（CFO）合作，可以帮助您在计划进行新投资时明确所有隐性成本。有些许可证可能在云提供自带许可（BYOL）选项，或者其可能或多或少有利于云服务。了解当前基础设施的真实 TCO 有助于您优先将组织总 TCO 影响最大的工作负载采用云。您的 AWS 客户团队拥有随时可用的工具，可帮助您更好地了解本地总拥有成本。
+ **您需要哪些基础设施来支持混合部署？**

  要成功采用混合模式，您将需要基础网络、安全和基础设施工具。确保能够与云提供商保持足够的网络连接。这可以通过将现有的互联网连接、虚拟专用网络 (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 等标准协议访问云存储层。同样，可以考虑分载所有不常用或使用率较低的计算任务。如果您有专用于此类任务的本地服务器，则可以改用可扩展的云计算服务，即按需预调配资源并只需为实际用量付费。这些低成本、长期存储和低使用率的计算选项也使云成为备份和灾难恢复的理想选择。您可以在云使用安全、耐用、可扩展的存储和计算来保护您的数据，并在发生灾难时快速恢复，而无需自行维护必要的存储和计算基础设施。
+ **您是否有足够的本地容量进行实验和创新？**

  在固定规模的本地环境中，缺乏弹性和敏捷性可能会限制用户可用的服务和技术。如果您有严格的刷新周期，则新工作负载可能需要等到下一个周期才能实施。这种运营模式可能会限制实验并减缓创新。当您需要测试新的或创新的工作负载时，可以考虑使用可扩展的弹性云服务。云资源可以按需预调配和取消预调配，您只需为实际使用的资源付费，因此您可以快速实验和实施*快速失效机制*，同时最大限度地降低组织风险。
+ **是否有独特的合规或性能要求，迫使您将数据保存在本地？**

  具有严格数据驻留或延迟要求的工作负载可能会要求您将数据保留在本地或尽可能靠近用户的地方。对于这些使用案例，您可以优先使用现有的本地资源。但是，请考虑云提供商是否提供在本地使用基于云技术的边缘服务或机制。边缘服务在离您自己的端点更近的地方提供数据处理、分析和存储，并使您能够在标准云提供商数据中心之外部署工具。例如，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 时，请一并考虑这些因素。