甲骨文与AWS握手：死敌变"友敌"的云上交易

拉里·埃里森和安迪·贾西，两个在公开场合互相嘲讽了十多年的男人，突然决定让他们的云基础设施"握手"了。

这不是什么慈善行为。两家公司在4月16日宣布建立私有高速连接，让Oracle云和AWS云之间的数据传输延迟大幅降低。对于正在运行"拆分栈"AI应用的企业来说，这个消息可能直接决定他们下个月的技术选型。

从互相拆台到共享管道

甲骨文和AWS的恩怨可以追溯到云计算早期。埃里森曾多次公开质疑AWS的技术架构，贾西则回敬以市场份额数据——AWS长期占据全球云市场约三分之一的份额，而OCI（Oracle云基础设施）直到近年才勉强挤进前五。

但企业客户的实际需求正在改写剧本。

现代AI工作负载的架构越来越复杂：一个典型场景是，企业在Oracle OCI上运行高性能数据库，同时用AWS的SageMaker（机器学习平台）进行模型训练和推理。这种"拆分栈"部署不是设计出来的，是长出来的——业务部门各自选型，技术债务日积月累。

问题是，没有专用连接时，这些数据得绕道公网。延迟高、成本高、安全合规还麻烦。结果就是所谓的"数据重力"困境：数据一旦落在某个云上，就再也搬不动了。

甲骨文这次的动作很具体：把自家的Oracle Interconnect原生互联服务，对接上AWS的Interconnect-multicloud标准。两家声称这将创建一个"完全托管、企业级"的管道，让客户感觉像是在一个统一环境里操作。

「这是原生集成的托管服务，」甲骨文的声明强调了这个措辞。翻译一下：客户不用自己拉专线，不用配置复杂的网络策略，账单由一家出。

多云不是选择题，是生存题

这个合作的时机耐人寻味。

2024年以来，AI基础设施的军备竞赛进入白热化阶段。英伟达GPU一卡难求，云厂商的算力配额成为谈判筹码。企业发现，把所有鸡蛋放在一个云篮子里，风险正在上升——要么拿不到资源，要么被锁定在溢价合约里。

多云战略从"最好有"变成了"必须有"。但真正的多云从来不是简单的"这边开几台虚拟机，那边存点对象存储"。

过去企业的做法很狼狈：自建连接，或者采购第三方网络服务商的拼凑方案。这需要手动配置，需要维护物理基础设施，需要处理两家云的安全策略冲突。迁移一次数据的工程周期常以月计，成本则难以预测。

甲骨文和AWS现在提供的，本质上是一个"特权通道"。数据不走公网，延迟可控，安全合规的审计链条也更清晰。对于金融、医疗这些监管严格的行业，这直接降低了多云架构的准入门槛。

更值得玩味的是定价策略。两家公司都没有公布具体费率，但"托管服务"的潜台词是：这可能是按量计费的运营支出，而非一次性资本支出。对于CFO来说，这改变了多云连接的ROI计算方式。

谁在这次交易中更主动？

表面看是双赢，但细看条款能发现不对称。

甲骨文是主动适配AWS的Interconnect-multicloud标准，而非相反。这个细节很重要——AWS的互联规范正在成为事实上的行业标准，就像它的S3 API曾定义对象存储的接口形态。

对于OCI来说，这是一次务实的妥协。甲骨文的云业务增长近年有所提速，2024财年OCI收入增速超过50%，但基数仍然远小于AWS、Azure和谷歌云。接入AWS的互联生态，相当于获得了通往最大企业客户群的快速通道。

AWS的动机则更微妙。它不需要甲骨文的客户来填充算力——事实上，AWS的AI服务（Bedrock、SageMaker）正在与Oracle的数据库产品形成直接竞争。但AWS无法忽视一个现实：Oracle数据库在全球企业中的渗透率。与其让客户因为数据迁移困难而暂缓上云，不如提供一个"顺滑"的共存方案，再徐徐图之。

这种"友敌"关系在科技业并不新鲜。苹果和三星在法庭上互诉专利侵权，同时三星为iPhone供应屏幕；微软和Linux社区曾经势不两立，现在Azure却是开源工作负载的重要运行平台。

云计算正在进入这样一个阶段：基础设施的差异化越来越难做，互联互通成为新的竞争维度。谁能让自己成为多云架构的"默认枢纽"，谁就能在客户的技术栈里占据更有利的位置。

对企业的实际影响

这个合作真正值得关注的，是它解决的具体技术场景。

第一类是"拆分栈"AI应用。想象一个制造业客户：生产数据存在Oracle的自治数据库里（利用其高性能事务处理能力），同时用AWS的机器学习服务做预测性维护。过去这两个系统之间的数据同步可能是批处理的，延迟以小时计；现在理论上可以做到近实时，故障预警的响应速度直接提升。

第二类是渐进式云迁移。很多企业想从Oracle的本地部署转向AWS，但一次性迁移风险太高。有了专用连接，可以分阶段迁移——先迁应用层，数据层保持双写，验证稳定后再切换。这种"绞杀者模式"的迁移，技术风险和时间成本都更可控。

第三类是灾备和合规场景。某些行业要求数据在特定地理边界内存储，但应用需要跨地域部署。利用两家云的互联，可以构建更灵活的灾备架构，而不必在单个云内部复制全套环境。

不过，技术实现上仍有待观察的细节。比如：连接的高可用性如何保证？跨云的身份认证和访问控制如何统一？网络层面的故障排查由谁负责？这些运营层面的问题，往往比连接本身更能决定实际体验。

行业格局的连锁反应

甲骨文和AWS的握手，对其他云厂商构成了压力测试。

微软Azure和谷歌云是最直接的参照系。它们与Oracle的关系如何演变？特别是微软——SQL Server和Oracle数据库在企业市场长期竞争，但Azure也在积极拥抱开源和多云。如果客户开始要求"Azure-Oracle"专用连接，微软很难拒绝。

更深层的影响在于云互联的标准化。AWS的Interconnect-multicloud规范如果成为主流，可能重演S3 API的故事：其他云厂商被迫兼容，最终在接口层面被"收编"。这对于正在建设自主技术栈的中国云厂商，也是一个需要关注的信号。

独立软件厂商（ISV）的生态位也在变化。过去有一些公司专门做多云网络优化，比如Aviatrix、Prosimo等。云厂商原生提供类似能力，会挤压这些第三方工具的市场空间。但另一方面，多云管理的复杂度从未真正降低——跨云成本优化、统一监控、安全策略编排，这些需求可能从"连接层"向上迁移到"治理层"。

对于企业IT决策者，这个合作提供了一个重新评估供应商关系的契机。过去选云是"站队"逻辑，现在越来越像"组合"逻辑——哪个服务在特定场景下最能打，就用哪个。但这也意味着，技术团队需要建立真正的多云治理能力，而不是简单的"多账号管理"。

一个值得跟踪的指标

判断这个合作成败，有一个简单指标：半年后，有多少新发布的AI应用架构图里，会同时出现OCI和AWS的图标。

如果"Oracle数据库+AWS AI服务"成为常见配置，说明这次互联确实降低了架构复杂度，让拆分栈从"无奈之选"变成"合理之选"。

更深层的信号是定价。如果互联流量费用显著低于公网传输，甚至纳入双方的预留实例折扣体系，那将真正改变多云的成本结构。反之，如果定价高昂，这个"特权通道"可能只服务于最不价格敏感的高端客户，影响力有限。

云计算的竞争正在从"我的云比你的云更好"，转向"我的云能更好地与你的云共存"。这不是技术理想的胜利，是企业客户用脚投票的结果。当AI工作负载的复杂性超出任何单一云厂商的覆盖能力时，互联互通就从差异化卖点变成了准入门槛。

对于正在规划AI基础设施的技术负责人，现在可以重新打开那张被搁置的多云架构图了。检查哪些数据流正在绕道公网，估算延迟对模型推理的影响，然后给Oracle和AWS的账户团队发一封询价邮件——这可能是本季度最值得花时间的几件事之一。