agents24 多云服务选型对照指南AWS、Azure、GCP、OCI 计算 / 存储 / 数据服务对比与应用【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南围绕 multi-cloud-architecture 技能中承担完整对照表职责的 service-comparison.md 展开系统梳理 AWS、Azure、GCP、OCI 四大公有云在计算、存储与数据服务三个维度的一对一服务映射并给出平台选型与多活/主备/去供应商锁定等落地建议。读完本文你将能够在一张表内完成跨厂商服务的语义对齐并据此做出可迁移、可审计的多云架构决策。这份对照表在项目里扮演什么角色在 agents 仓库的 cloud-infrastructure 插件族中multi-cloud-architecture是一个面向 Claude Code、Codex、Cursor、OpenCode、Copilot、Antigravity 等多工具链的架构决策技能。其 SKILL.md 的 Front Matter 声明Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, GCP, and OCI.SKILL.md 内嵌了三张精简对比表Compute / Storage / Database并在文末明确标注Reference:Seereferences/service-comparison.mdfor complete comparison也就是说SKILL.md 是渐进式披露progressive disclosure的导航层而 references/service-comparison.md 才是承载完整服务映射的深度引用层。当 Agent 面临某个工作负载在四朵云上分别对应什么托管服务这类问题时主文档只给摘要完整对照需要读取本引用文件——这与仓库 docs/agent-skills.md、docs/authoring.md 中描述的 skills 分层披露机制一致。计算服务对照四朵云的每一种跑法service-comparison.md 的 Compute 对照按使用场景Use Case而非厂商罗列来组织天然面向选型问答Use CaseAWSAzureGCPOCIGeneral-purpose VMsEC2Virtual MachinesCompute EngineComputeManaged KubernetesEKSAKSGKEOKEServerless functionsLambdaFunctionsCloud FunctionsFunctionsContainers without cluster managementECS/FargateContainer Apps / Container InstancesCloud RunContainer Instances使用这张表的三个关键认知按场景横读而不是按厂商竖读。例如托管 Kubernetes行直接给出 EKS → AKS → GKE → OKE 的等价关系这也是 SKILL.md 中Cloud-Agnostic Architecture建议用 KubernetesEKS/AKS/GKE/OKE统一计算层的事实基础。行内并非全等替代。Containers without cluster management一行里ECS/Fargate 与 Container Apps / Container Instances、Cloud Run 在伸缩模型、冷启动、计费粒度上差异明显表格给出的是同语义能力映射迁移前仍需核对各自的服务配额与网络模型。与主文档表格互为补充。SKILL.md 的 Compute 表把 Containers 与 Managed containers 拆成两行并加入 Fargate而引用文件用四行四个场景做了更干净的归纳二者并不冲突引用文件信息密度更高。存储服务对照对象、块、文件、归档四类介质Storage 部分的对照是日常架构里被引用最频繁的一段Use CaseAWSAzureGCPOCIObject storageS3Blob StorageCloud StorageObject StorageBlock storageEBSManaged DisksPersistent DiskBlock VolumesFile storageEFSAzure FilesFilestoreFile StorageArchive storageGlacier / Deep ArchiveArchive StorageArchive StorageArchive Storage使用要点Object storage 一行是去锁定的关键抓手。S3、Blob Storage、Cloud Storage、OCI Object Storage 均提供 S3 兼容 API 或等效对象语义。项目中的 Cloud-Agnostic Abstraction 模式 明确建议以 S3-compatible API 作为存储抽象边界本地或跨云可用 MinIO 等自建对象存储兜底。Block storage 与虚拟机关联生命周期EBS、Managed Disks、Persistent Disk、Block Volumes 都承载虚拟机根卷与数据卷迁移时须连同磁盘类型通用型 / 吞吐型 / IO 型的效能差异一起评估不可只看容量单价。Archive 行暴露了命名的巧合陷阱GCP 的 Archive Storage 与 OCI 的 Archive Storage 同名但分属两朵云AWS 用 Glacier 系列含 Deep Archive表达同一层级。跨团队沟通时建议先写厂商前缀避免歧义。数据服务对照关系型、分布式 SQL、NoSQL 与流处理Data Services 部分是选型分歧最大的区域对照如下Use CaseAWSAzureGCPOCIManaged relational databaseRDSSQL DatabaseCloud SQLMySQL HeatWaveDistributed / globally resilient SQLAurora Global DatabaseCosmos DB for PostgreSQL / SQL patternsCloud SpannerAutonomous DatabaseNoSQLDynamoDBCosmos DBFirestoreNoSQL DatabaseStreamingKinesis / MSKEvent HubsPub/Sub / ConfluentStreaming需要特别注意的细节Managed relational database一行对应的是经典托管 SQLRDS可跑 MySQL/PostgreSQL 等、Azure SQL Database、Cloud SQL、OCI MySQL HeatWave。真正追求跨云可移植时应选 PostgreSQL/MySQL 语义——SKILL.md 的云中立替代清单正是建议 PostgreSQL/MySQL (RDS/SQL Database/Cloud SQL/MySQL HeatWave)并在 Portable Platform Baseline 模式中把 PostgreSQL 列为标准化底座。Distributed / globally resilient SQL是横向最不齐的一行Aurora Global Database 与 Cloud Spanner 是全球多区域强一致方案Cosmos DB for PostgreSQL 提供多主写能力而 OCI Autonomous Database 是自治运维型数据库各自的全局一致性模型与 RPO/RTO 承诺差异显著。引用文件用Distributed / globally resilient SQL这类语义标签而非产品等价来归纳提示读者此行为能力域而非替代关系。NoSQL 与流处理行的组合式写法AWS 行出现 Kinesis / MSKGCP 行出现 Pub/Sub / Confluent说明流式场景往往同时涉及数据接入Kinesis/Pub/Sub与 Kafka 生态MSK/Confluent映射时应区分消息总线与流处理平台两类诉求。平台选型 Notes什么时候用、怎么权衡service-comparison.md 末尾的四条选型准则浓缩了全套多云的决策逻辑团队熟练度与锁定容忍度高时优先厂商原生托管服务。这是用最好的托管省运维的路径代价是切换成本高。可移植性优先时选 Kubernetes、PostgreSQL、Redis 与开源可观测栈。对应 multi-cloud-patterns.md 的 Portable Platform Baseline以 Kubernetes Terraform/OpenTofu PostgreSQL Redis OpenTelemetry 为底座把云差异收进模块、黄金路径与服务目录仅对 IAM、网络、托管数据库等厂商特有行为单独记录例外。Oracle 数据库亲和、网络可预期性或受监管工作负载隔离是首要驱动时选择 OCI。结合 Best-of-Breed 模式OCI 往往承担Oracle 生态与受监管交易系统的角色而非通用算力池。跨厂商拆分负载前先对比出口流量费、托管服务溢价与支持计划。这一条提醒架构师Egress 定价、托管服务隐含加价和不同层级支持 SLA 会显著改变成本模型属于 SKILL.md Cost Comparison 部分列出的对比维度AWS On-demand/Reserved/Spot/Savings Plans、GCP Preemptible、OCI burstable/flexible shapes 等。四条 Notes 与 SKILL.md 的四种模式形成闭环条件 1 单云深度使用 → Single Provider with DR / Best-of-Breed 中做主力承载条件 2 → Cloud-Agnostic Abstraction 与 Portable Platform Baseline条件 3 → Best-of-Breed 中 OCI 的定位条件 4 → 分布式拆分前的成本护栏直接服务 Active-Active Regional Split 等跨云拓扑。如何把对照表用进真实架构决策结合本仓库的组织方式推荐的使用流程先查 SKILL.md 摘要再落引用文件。当你在做 cloud-infrastructure 插件族的架构任务如选型、迁移、多活时SKILL.md 的快速表足够支撑摘要级问答一旦涉及跨厂商精确映射例如把 RDS 的某个能力对标到其余三朵云就读取 references/service-comparison.md 的完整表格。对照行内语义逐项验证能力与配额。表中每个单元格是能力域映射具体可用性、区域列表、SLA、一致性与计费粒度需以各厂商当前文档为准——本文只负责告诉你四朵云上它叫什么不代替你核对产品页。用选型 Notes 做二次校验。每选中一行用第 30–35 行的四条准则自检这条选择是否违背可移植性目标是否低估了出口流量与托管溢价是否需要为受监管负载单独隔离配合模式文档落地。选型结果最终要落到 multi-cloud-patterns.md 描述的四种形态之一Active-Active Regional Split、Best-of-Breed Service Mix、Primary/DR Pairing、Portable Platform Baseline并通过 terraform-module-library 的 IaC 抽象、cost-optimization 的成本治理与 hybrid-cloud-networking 的跨云连通落地为可运行架构。仓库中 cloud-architect.md、hybrid-cloud-architect.md 等 Agent 角色文件正是围绕这类决策场景被调用。小结service-comparison.md 以场景 → 四厂商的矩阵格式给出了计算、存储、数据服务三大类下最常用托管服务的等价映射并配套四条平台选型准则。它既是 multi-cloud-architecture 技能的完整对照引用层也可独立作为跨云沟通与迁移评估的速查卡使用。使用时牢记一个原则表格保证语义对得上准则是保证方向不跑偏而真正落库上云之前请回到各厂商的现网文档验证区域可用性与具体配额。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考