企业多云战略：AWS、Azure 和 GCP

多云（同时使用多个提供商的云服务）已成为默认的企业云架构。 Gartner 报告称，当今 87% 的企业采用多云，尽管意图程度差异很大。一些组织在设计上是多云的，有意跨提供商构建工作负载，以优化成本、功能和风险。许多都是偶然的多云——不同团队选择不同提供商、整合不同云环境的并购活动或依赖底层云基础设施的 SaaS 采用的结果。

偶然的多云和战略性的多云之间的区别是巨大的。意外的多云会带来管理复杂性、成本低效、安全漏洞和集成挑战，而无法提供深思熟虑的多云策略可以提供的优势。战略性多云是一种深思熟虑的架构选择，它以复杂性换取特定优势：弹性、成本优化、最佳能力访问和谈判筹码。

本指南提供了制定深思熟虑的多云战略的框架——原因、时间、方式以及成本。

要点

87% 的企业采用多云，但大多数企业没有经过深思熟虑的策略 — 意外的多云会带来成本而不带来收益

三大云优势明显：AWS（广度、成熟度、生态系统）、Azure（企业集成、微软堆栈）、GCP（数据/AI/分析、Kubernetes）

多云的主要业务驱动因素：供应商独立性、同类最佳服务、合规性/数据主权、弹性

多云增加了复杂性、成本管理难度和安全范围 - 这些必须明确管理

云抽象层（Kubernetes、Terraform、与云无关的服务）支持可移植性，但增加了自身的复杂性

FinOps（云财务运营）是使多云经济上易于管理的学科

治理和安全性必须从一开始就针对多云进行设计——改造治理成本高昂

大多数组织在考虑 3 个或更多云之前应有目的地使用 2 个云

多云格局：组织为何选择这里

三大云：独特优势

亚马逊网络服务 (AWS)：最成熟的云平台，于 2006 年推出。最广泛的服务目录（200 多个服务）、最大的全球基础设施（30 多个区域）、最深入的第三方生态系统。全球市场份额领先（~32%）。最强之处：无服务器 (Lambda)、托管数据库多样性、容器服务（ECS、EKS、Fargate）以及最广泛的成熟、生产就绪的服务组合。 AWS 的生态系统——围绕 AWS 构建的 ISV、咨询合作伙伴和人才库——是无与伦比的。

Microsoft Azure：与 Microsoft 企业产品（Office 365、Dynamics 365、Active Directory、SQL Server、.NET）的深度集成使 Azure 成为以 Microsoft 为中心的企业的默认选择。强项：混合云（Azure Arc、Azure Stack）、企业身份（Azure AD/Entra ID）、AI/ML 服务（Azure OpenAI）和企业集成服务。全球市场份额约 22%；在微软投入大量资金的企业中更高。

Google Cloud Platform (GCP)：Google 的公共云，利用 Google 的基础设施、数据和 AI 功能。最强领域：数据分析（BigQuery、Dataflow）、机器学习（Vertex AI、TPU 访问、基础模型）、Kubernetes（GCP 发明了 K8s；GKE 被认为是 K8s 的参考实现）和全球网络。〜11％的市场份额。增长迅速，尤其是在数据密集型和人工智能工作负载方面。

其他提供商：Oracle 云基础设施 (OCI) — 非常适合 Oracle 数据库工作负载； IBM Cloud — 在金融服务监管环境中表现出色；阿里云——在中国市场占据主导地位；区域提供商（欧洲的 OVHcloud、韩国的 Naver Cloud）满足数据主权要求。

为什么企业要转向多云

特定于工作负载的功能：没有任何一个提供商能够在所有方面都表现出色。数据密集型组织可能会选择 GCP 的 BigQuery 进行分析、Azure 进行 Microsoft 集成，以及 AWS 的广泛应用程序托管功能。

降低供应商风险：避免单一提供商依赖可以减少谈判杠杆劣势，防止服务中断，并对冲服务中断风险。

合规性和数据主权：由于监管要求，某些工作负载必须保留在特定地理区域。所需区域的提供商可用性可能会推动多云发展。

并购整合：当组织收购具有不同云环境的公司时，集成到单一云的成本高昂且具有破坏性。多云通常是务实的结果。

谈判杠杆：拥有主要云提供商的可靠替代方案可以加强定价谈判。将 20% 的支出转移给二级提供商可以对剩余 80% 的支出产生影响力。

SaaS 供应商选择：企业 SaaS 应用程序在特定云提供商上运行。 Salesforce、Workday、ServiceNow 和其他主要 SaaS 平台具有与云无关的 API，但其底层基础设施可能更喜欢某些云互连以提高性能。

战略性多云架构模式

模式 1：主要 + 次要

最常见的故意多云架构：一个主云（60-80% 的工作负载）和一个辅助云（20-40%），选择用于特定功能或风险缓解。

示例：AWS 作为应用程序托管、容器工作负载和广泛的 AWS 服务组合的主要服务。 GCP 作为辅助，专门用于 BigQuery 分析、Vertex AI 和 ML 训练工作负载，其中 GCP 的数据服务优于 AWS 同类服务。

这种模式提供了有意义的供应商多样性和能力访问，而无需同等对待三个提供商的极端运营复杂性。

模式 2：按提供商实力分配工作负载

每种工作负载类型都放置在最适合它的提供程序上，无论哪个提供程序是“主要”。

示例：

AI/ML 训练和推理：GCP（Vertex AI、TPU）
Microsoft 应用程序堆栈（SharePoint、Dynamics、Power Platform）：Azure
一般应用程序托管、微服务：AWS
Oracle数据库：OCI

这种模式最大化了功能优化，但也最大化了运营复杂性——团队必须保持跨多个提供商的熟练程度，成本管理变得困难，并且安全治理跨越多个环境。

模式 3：地理分布

出于数据主权、延迟或提供商可用性的原因，不同的区域由不同的云提供商提供服务。

示例：

北美和欧洲：AWS（最广泛的全球业务）
亚太地区：GCP（亚太地区实力雄厚，特别是在新加坡、日本、台湾）
中国：阿里云（监管要求；AWS 和 Azure 在中国的业务有限）

模式 4：灾难恢复和业务连续性

主要工作负载位于一个提供商上，灾难恢复环境位于第二个提供商上。防止提供商级别的中断（尽管这种情况很少见），并为云便携式应用程序设计提供强制功能。

最常见的是第 1 层应用程序，其中提供商级中断（理论上）将是灾难性的。

多云复杂性的成本

多云策略提供了真正的好处，但必须权衡这些好处与复杂性增加的实际成本。

直接成本

数据出站：在云提供商之间移动数据会产生大量的出站费用。需要在 AWS 和 GCP 之间定期移动数据的多云架构可能会产生大量意外的出口成本。 AWS、Azure 和 GCP 都对离开其网络的数据收费 - 区域间和互联网出口为 0.08-0.09 美元/GB。

冗余工具：为多个云而不是一个云运行管理工具、安全工具和治理框架会成倍增加工具成本。

技能和培训：工程团队必须保持跨多个云平台的专业知识——比单云深度要高得多的知识栏。

间接成本

操作复杂性：多云环境需要更复杂的操作程序、监控和事件响应。多云环境中的事件更难以诊断和解决。

安全复杂性：跨多个云的安全治理需要更复杂的工具、更复杂的策略和更熟练的安全团队。

开发摩擦：开发人员必须跨多个云提供商 SDK、部署模型和服务 API 进行工作，从而产生上下文切换开销。

盈亏平衡分析

多云的好处——通过谈判杠杆节省成本、通过最佳服务选择提高能力、提高弹性——必须超过复杂性的成本。这种收支平衡很少经过严格计算，导致许多组织过度投资于多云复杂性，以获得不合理的收益。

FinOps：使多云经济地可管理

FinOps（云金融运营）是通过财务、工程和业务团队之间的协作来优化云经济的学科。这在成本可见性和优化更加复杂的多云环境中尤其重要。

多云成本可见性

第一个挑战：以统一的视图查看跨提供商的总云支出。每个提供商都有自己的成本管理工具（AWS Cost Explorer、Azure Cost Management、Google Cloud Billing）以及不同的成本分配模型。

多云 FinOps 平台：CloudHealth (VMware)、Apptio Cloudability、CloudCheckr (NetApp)、Spot by NetApp、Flexera Cloud Management。这些平台汇总来自多个提供商的计费数据，规范不同提供商模型之间的成本分配，并提供统一的报告。

跨云承诺折扣

每个云提供商都为承诺使用提供大幅折扣：

AWS：预留实例（1-3 年承诺）和节省计划（计算、EC2、SageMaker）
Azure：预留 VM 实例和 Azure Savings Plans
GCP：承诺使用折扣和持续使用折扣

管理跨多个云的承诺投资组合需要仔细的需求预测和利用率监控——未使用的承诺是浪费的支出；承诺不足意味着按需支付保费。

最佳承诺组合是一个持续优化问题——FinOps 团队每季度重新计算最佳覆盖范围。

标记和成本分配

多云环境中的成本分配需要在所有提供商之间进行一致的标记 - 将成本分配给特定的应用程序、团队、业务部门或项目。如果没有一致的标记，就不可能确定哪些业务部门正在推动云成本。

在所有提供商之间实施标记策略。使用可一致应用的与云无关的标记标准。在基础设施即代码管道中自动进行标签验证，以防止未标记的资源。

多云安全与治理

多云环境中的安全性比单云环境中的安全性更加复杂，需要进行深思熟虑的架构投资。

云安全态势管理 (CSPM)

CSPM 工具根据安全最佳实践不断评估云配置，在错误配置的资源被利用之前识别它们。多云 CSPM 平台提供跨提供商的统一可见性：

Wiz：快速增长的 CSPM 平台，具有强大的多云覆盖范围（AWS、Azure、GCP、OCI）。基于图形的分析可识别复杂云环境中的攻击路径。

Palo Alto Prisma Cloud：全面的 CNAPP（云原生应用程序保护平台），涵盖多云 CSPM、CWPP（工作负载保护）、DSPM（数据安全）和运行时安全。

CrowdStrike Falcon Cloud Security：强大的运行时保护和 CSPM，与 CrowdStrike 的端点安全平台深度集成。

Microsoft Defender for Cloud：强大的 Azure 原生；还涵盖 AWS 和 GCP。对于拥有大量 Microsoft 安全投资的组织而言，价格合理。

跨云身份和访问管理

跨多个云提供商一致地管理身份是一项重大的治理挑战。主要原则：

集中身份：使用单个身份提供商（Azure Active Directory、Okta）来跨所有云提供商提供人员身份，使用联合而不是在每个提供商的 IAM 中维护单独的身份。

机器身份管理：服务帐户、托管身份和实例配置文件需要跨提供商进行一致的管理。应使用云原生机密管理器（AWS Secrets Manager、Azure Key Vault、GCP Secret Manager），而不是硬编码凭证。

特权访问管理：跨云一致的 PAM 策略，以及管理操作的即时访问。

多云 CIEM（云基础设施权利管理）：专门用于管理跨提供商的云 IAM 配置的工具 - 识别过度许可的角色、未使用的权限和权限升级路径。

基础设施即代码：治理基金会

基础设施即代码 (IaC) — 在版本控制的代码中定义云基础设施，而不是通过手动控制台操作 — 是多云治理的基础。

Terraform (HashiCorp)：占主导地位的多云 IaC 工具，提供所有主要云平台的提供商。跨 AWS、Azure 和 GCP 实现一致的基础设施配置模式。 Terraform Cloud/Enterprise 提供协作、状态管理和治理功能。

Pulumi：使用通用编程语言（TypeScript、Python、Go）而不是 DSL 的 IaC。强大的类型检查和 IDE 支持。 Terraform 的不断增长的替代品。

云原生 IaC：AWS CloudFormation、Azure 资源管理器 (ARM)/Bicep 和 Google Cloud 部署管理器是特定于提供商的。非常适合致力于单一提供商的工作负载；不适合需要一致工具的多云。

Kubernetes：多云可移植层

Kubernetes 已成为多云应用程序可移植性的事实上的标准。在 Kubernetes 上运行的容器化应用程序理论上可以在任何托管 Kubernetes 服务（AWS EKS、Azure AKS、Google GKE）或自我管理的 Kubernetes 集群上运行。

托管 Kubernetes 比较

GKE（Google Kubernetes Engine）：参考实现； Google 发明了 Kubernetes 并运行着最大的 K8s 部署。优秀的操作工具、强大的自动驾驶模式、领先的工作负载身份集成。 Kubernetes 优先组织的最佳选择。

EKS（Amazon Elastic Kubernetes Service）：最强的 AWS 生态系统集成、最广泛的部署（由于 AWS 市场份额）、最佳的运营商人才可用性。对于某些操作来说，比 GKE 更强大，但更需要手动操作。

AKS（Azure Kubernetes 服务）：最佳 Microsoft Azure 集成，适用于 Windows 工作负载和 .NET 应用程序，与 Azure AD 集成以实现身份识别。大多数与 Azure DevOps 和 GitHub Actions 集成。

Kubernetes 可移植性实践

虽然 Kubernetes 提供了理论上的可移植性，但实际的可移植性受到以下因素的限制：

云原生服务：使用特定于提供商的服务（S3、Azure Blob、GCS；SQS 与服务总线与 Pub/Sub；Route 53 与 Azure DNS 与 Cloud DNS）的应用程序在没有抽象层或代码更改的情况下不可移植。

存储：云原生存储集成（EBS、Azure 磁盘、GCP 持久磁盘）在性能特征和配置方面有所不同。有状态应用程序需要存储抽象。

网络：云网络服务（VPC、子网、负载均衡器集成）因提供商而异。 Kubernetes 服务抽象（LoadBalancer 类型）使用特定于云的实现。

服务网格（Istio、Linkerd）和与云无关的网络抽象（Cilium）解决了一些可移植性挑战，但对于复杂应用程序来说，“在任何地方运行而无需更改”的目标仍然更加理想化，而不是实际。

常见问题

我们如何确定多云是否适合我们？

当至少满足以下条件之一时，多云是有必要的：您的工作负载具有任何单一提供商都无法满足的特定要求，监管要求要求特定提供商提供特定数据，您的云支出足够大，以至于谈判杠杆证明运营开销是合理的，或者您经历过或存在影响关键工作负载的提供商级服务中断的可信风险。在以下情况下，多云是没有保证的：主要驱动因素是模糊的“风险降低”，没有考虑到特定场景，操作复杂性会让您的云工程团队不堪重负，或者您的云总支出低于约 100 万美元/年（杠杆效益很少证明较低规模的成本是合理的）。

我们如何在多云环境中管理成本？

多云成本管理需要：集中可见性（使用多云 FinOps 平台汇总跨提供商的成本）、一致的标记（使用 IaC 策略在所有提供商之间强制执行成本分配标签）、定期承诺组合审查（跨提供商的预留实例/节省计划的季度评估）、共享成本分配模型（定义有利于多个团队的共享服务的规则）以及 FinOps 团队结构（负责所有提供商的云经济的专用 FinOps 功能或实践）。所有提供商的预算警报都会输入到统一的警报系统中。对业务部门的回馈/退款创建了财务责任，从而推动了资源的高效利用。

多云和混合云有什么区别？

多云使用多个公共云提供商（AWS + Azure + GCP）。混合云将公共云与本地私有云或数据中心基础设施相结合。许多企业同时采用多云和混合云。混合云的驱动因素是：防止某些数据离开本地的数据主权要求、无法经济地迁移的遗留系统，或者本地比云更有效地满足特定的性能要求。多云的驱动因素是：同类最佳的能力访问、供应商风险管理和谈判杠杆。混合云技术（Azure Arc、AWS Outposts、GCP 分布式云、VMware Tanzu）与主要实现多云可移植性的技术（Kubernetes、Terraform）不同。

当我们已经跨多个提供商提供工作负载时，我们如何进行云迁移？

迁移前的合理化通常是正确的方法：首先了解什么在哪里运行以及为什么运行，然后决定哪些工作负载应该移动、保留或淘汰。通用合理化标准：仅使用一个提供商的本地服务的工作负载应保留在该提供商上；在当前提供商上运行欠佳的工作负载（不适合服务、成本高、性能差）是迁移候选者；具有多个提供商本机依赖项的工作负载在迁移之前可能需要更改架构。迁移执行：使用 Terraform 或等效 IaC 使迁移可重现；使用提供商迁移工具（AWS MGN、Azure Migrate、Google Migrate for Compute）进行直接迁移；将迁移视为实现架构现代化的机会，而不是在新环境中复制遗留架构。

哪种治理结构最适合多云环境？

卓越云中心 (CCoE) 模型是一个专门团队，负责所有提供商的云战略、标准、工具和治理，是最有效的多云治理结构。 CCoE 拥有：提供商选择标准和标准、IaC 模板和护栏、安全基线要求、成本治理和 FinOps，以及为采用云服务的团队提供的技术支持。业务部门按照 CCoE 标准实施，并可以在批准的范围内自主选择服务。如果没有 CCoE，多云治理就会默认让每个团队解决自己的问题，从而导致工具激增、安全性不一致以及成本不受管理。

后续步骤

多云战略不是一项技术决策，而是一项具有重大运营、财务和风险影响的业务架构决策。从多云中受益的组织是那些刻意接近它的组织：定义明确的驱动因素，选择特定功能的提供商，投资于使多云易于管理的治理和工具，并不断优化产品组合。

ECOSIRE 的云原生技术实现旨在在多云环境中有效工作 - 具有基础设施即代码基础、与云无关的集成模式以及保留提供商可选性的架构选择。无论您使用的是 AWS、Azure、GCP 还是组合，我们的团队都可以根据您的特定要求设计和实施正确的架构。

探索我们的服务组合或联系我们的云架构团队讨论您的多云策略。

Multi-Cloud Strategy for Enterprise: AWS, Azure, and GCP