云服务商 L1-L7
「云服务商」这一组共 5 家厂商 / 机构，每一家都按 L1～L7 分层整理：那一层它卖什么、哪一层是它的主场。
Alicloud
主场：L3
L1 物理层
云把数据中心里需要采购的物理层内容基本全部接管了：布线、光模块、机柜、供电、散热、时钟设备用户既碰不到也不需要采购。所以这一层不是产品矩阵。但仍有两类真实内容值得当成物理层来理解：一是用户仍然要自己做的物理决策——地域与可用区的选址决定了物理距离、时延与故障域边界，专线接入要真实采购物理端口并协调运营商施工；二是实例的网络性能上限（带宽、每秒包量、连接数），它本质上是平台把物理网卡能力按规格切分后暴露给用户的结果，选错规格的后果与选错网卡一样。
L2 数据链路层
这一层的核心内容是「云上没有什么」，而这恰恰是 IDC 上云最容易踩坑的地方。VPC 是三层虚拟网络，传统二层能力大部分不存在：不支持广播与组播、不能把 VLAN 延伸进来、没有生成树与 MLAG、也没有用户可配置的交换机。带来的直接后果是一批依赖二层的方案在云上失效——依赖组播的 keepalived 默认配置、基于广播的服务发现与许可证服务器、以及「一个 VLAN 跨机房」的高可用假设。云上给出的替代品是三层化的：交换机（vSwitch）绑定单个可用区、弹性网卡承担二层寻址角色、高可用虚拟 IP 替代 VIP 漂移、负载均衡替代二层冗余。理解这套替换关系是迁移设计的必修内容。
L3 网络层
这是云网络的主体层，也是阿里云域内容最厚的一层。除了 VPC、路由与互联这些能力本身，有两条贯穿全域的约束必须在这一层讲清楚：一是计费模型——公网流量通常只计出方向、NAT 网关按能力单元加流量、跨地域互联要买带宽包、EIP 未绑定也有保有费，这些是账单意外最集中的地方；二是配额——路由条目数、安全组规则数、CEN 内 VPC 数都是硬上限，架构设计必须提前核对而不是撞上去再申请。另外网段规划是这一层最不可逆的决策：VPC 主网段创建后不可修改，与自有机房或未来互联对象网段冲突会导致根本无法互联。
L4 传输层
这一层与前面四个厂商域形成了一个明显对比：思科之外的三家都没有 ADC 产品线、四层分发要靠 ECMP 加第三方，而云上负载均衡是托管服务——按需开通、自动扩缩、免运维，这是云在这一层的实质优势。内容重心有三块：负载均衡产品族的选型（网络型做四层、应用型做七层、传统型兼有）、容量与计费模型（按能力单元计费，比按带宽计费复杂且容易低估），以及云上最经典的四层故障——NAT 网关的 SNAT 端口耗尽，症状是「带宽空闲但新连接建不上」，不了解机制会查很久。健康检查配置错误是第二高频问题，其中安全组挡住探测源导致后端全部异常是典型案例。
L5 会话层
云上的会话层与网络设备完全不是一回事：网络设备关心的是 TACACS+ 与设备登录，云上关心的是访问控制体系——所有对云资源的操作都是 API 调用，都要经过身份鉴权，所以 RAM（访问控制）是这一层的中枢。这里有一条必须放在最前面的实务：AccessKey 泄露是云上最高频、后果最严重的安全事故，代码仓库里硬编码的密钥被扫走后，轻则被拿去挖矿产生巨额账单，重则数据被删被勒索。根治办法不是「小心保管密钥」而是根本不用长期密钥——用实例 RAM 角色与临时凭证让应用免密访问。其余内容包括运维访问路径（堡垒机而非直接暴露端口）、VPN 会话，以及操作审计留痕。
L6 表示层
这一层是整个参考里的一个转折点：前面四个厂商域（思科、Arista、Juniper、Palo Alto）在这层给出的是同一个硬约束——没有 KMS 产品线、基本无国密适配、不在信创目录，涉及商密合规的项目它们都不在可选范围；而阿里云正好补上这块空白，有完整的密钥管理服务、国密算法支持与合规资质，这也是国内合规项目选择国内云的实际理由之一。内容分四块：KMS 密钥管理（含信封加密这个必须理解的机制）、国密与密评合规、证书服务与到期治理、以及传输与存储加密的落地。要提醒一条运维铁律：密钥一旦删除，用它加密的数据将永久不可读，这是云上少数不可逆且不可救的操作。
L7 应用层
这一层又形成了一次有意义的对照：WAF、CDN、DNS 安全这三类产品，恰好是 Arista、Juniper、Palo Alto 三家共同缺失的（它们的 L7 空白说明里都明确写了「必须由 Cloudflare、F5、Akamai 承担」），而云上这些都是原生的托管服务，开通即用、按量付费。内容分六块：WAF 应用防护、CDN 内容分发、DNS 解析与安全、API 网关、内容安全与合规，以及应用层可观测。要贯穿理解两条：一是防护类产品的价值取决于「源站是否可被绕过直连」——WAF 部署了但源站 IP 暴露在外，攻击者直接打源站等于防护失效，这是最常见的部署缺陷；二是国内特有的备案要求，CDN 与域名解析都受此约束，跨境业务必须提前规划。
跨层 · 管控与运营
云上跨层管控与硬件域有两处根本差异，这也是本层的重心。一是成本治理的分量完全不同：硬件是一次性采购加年维保，预算基本可预测；云是按量计费加自助开通，任何人有权限就能创建资源，所以成本会在无人察觉时持续增长——云上成本失控几乎都不是单价贵，而是没人管。二是多账号与资源目录这种组织方式是云特有的，它同时解决权限隔离、成本归属与故障隔离三个问题，是企业级云架构的基础，但很多团队直到规模变大才想起来做，那时迁移代价已经很高。此外还有资源编排、配置合规与可观测体系，以及最后的选型建议——包括与外商方案的定位差异和多云与锁定的权衡。
AWS
主场：L3
L1 物理层
与阿里云域一样，AWS 把数据中心里需要采购的物理层内容全部接管了，所以这层不是产品矩阵。仍然真实的内容有三块：Region 与可用区的选址（决定物理距离、时延与故障域），Direct Connect 的物理端口采购与运营商施工，以及实例规格对应的网络性能上限。但这个域要重点讲清与阿里云的差异，因为这些差异会直接改变架构与成本：AWS 对跨可用区流量按 GB 双向计费，而阿里云同地域内网流量通常不单独计费——这一条会让同一套「跨可用区多活」架构在两朵云上产生完全不同的账单，是跨云移植时最容易忽略的成本变量。另外 AWS 的可用区标识按账号随机映射，跨账号沟通「哪个可用区」时必须用 AZ ID 而非名称。
L2 数据链路层
与阿里云域一样，这一层的核心是「云上没有什么」。VPC 是三层虚拟网络：不支持广播与组播、不能延伸 VLAN、没有生成树与堆叠、也没有用户可配置的交换机。依赖二层的方案会失效——keepalived 的组播默认配置、广播式服务发现、PXE 网络启动。替代品同样是三层化的：子网绑定单个可用区、弹性网络接口承担二层寻址、负载均衡替代二层冗余。有两处与阿里云的差异值得注意：AWS 没有独立的「高可用虚拟 IP」产品，VIP 漂移的等价实现是弹性网络接口迁移或辅助 IP 重新绑定（配合 keepalived 单播），需要自己实现切换逻辑；以及 AWS 支持通过传输网关的组播能力有限地满足部分组播需求，这是阿里云没有的选项，但适用范围有限，迁移前需确认。
L3 网络层
这是 AWS 网络的主体层。概念与阿里云域大部分对应，所以这里重点讲会改变架构与成本的差异。三处最关键：一是安全组的连接跟踪机制——它是有状态的且每条连接占用跟踪表项，表项上限随实例规格变化，触顶时新连接失败而带宽空闲，这个机制阿里云域没有同等强调；二是Transit Gateway 的计费结构与 CEN 完全不同（按挂载数每小时加按 GB 处理费，而非带宽包），跨云成本模型不能直接换算；三是 NAT 网关是 AWS 上最经典的成本陷阱——除了按小时收费还按处理的每 GB 收费，且访问同 Region 的 AWS 服务如果走 NAT 而不走 VPC 端点，会产生完全可以避免的大额费用。网段规划的不可逆性与阿里云一致，但 AWS 支持添加辅助 CIDR 且限制略有不同。
L4 传输层
AWS 在这一层有一个阿里云没有的形态值得重点讲：网关负载均衡（GWLB）——它专门用于把第三方安全设备（防火墙、IDS、深度包检测）串接进流量路径，用 GENEVE 封装把流量透明地导给设备集群并做健康检查与横向扩展。这正好衔接了前面 Palo Alto 域讲的「串接部署与失效模式」：在 IDC 里要自己解决旁路、冗余与扩展，在 AWS 上 GWLB 把这些做成了托管能力。其余内容是三种负载均衡的分工（ALB 七层、NLB 四层、GWLB 串接安全设备）、LCU 计费模型（与阿里云能力单元同类但维度定义不同），以及两个 AWS 特有的成本与机制要点：跨可用区负载均衡开关直接影响跨区流量费，以及 NLB 保留源 IP 时的目标组配置差异。
L5 会话层
这一层是 AWS 域信息价值最高的部分，因为 IAM 的策略评估逻辑比阿里云 RAM 复杂得多，也是 AWS 上最常见的困惑源。同一次 API 调用可能同时受到身份策略、资源策略、权限边界、服务控制策略与会话策略五类策略的约束，它们的叠加规则不是简单的「有允许就通过」——任何一处显式拒绝都会否决全部允许，而权限边界与服务控制策略只能收窄不能放宽。理解这套评估顺序是回答「为什么我明明有权限却被拒绝」的前提。其余内容包括：访问密钥泄露这一最高频事故与实例角色的根治思路（与阿里云域结论一致）、无需开放端口的会话管理器（AWS 相对阿里云更成熟的运维通道）、以及操作审计。
L6 表示层
这一层与阿里云域形成反向对照：阿里云域的 L6 是全站的一个转折点（它补上了四家外商共同的国密与合规空白），而 AWS 在这一点上与四家外商一致——没有国密（SM2/SM3/SM4）支持、不在国内信创目录，所以涉及商密合规或国产化要求的国内项目，AWS 与思科、Arista、Juniper、Palo Alto 一样不在可选范围。这不是能力问题而是合规资质问题，且是硬约束。除此之外 AWS 的密钥与证书能力很完整：KMS 提供托管密钥与信封加密、证书管理服务提供免费的公有证书与自动续期、CloudHSM 提供专属硬件模块。要掌握的机制重点是信封加密（与阿里云一致）、密钥策略与 IAM 的双重授权关系，以及密钥删除的不可逆性。
L7 应用层
AWS 在这一层的产品与阿里云大致对应（WAF、CDN、DNS、API 网关），所以重点讲三处实际差异。一是成本结构的关键差异：从 CloudFront 传出到互联网的流量比从实例直接传出便宜，且回源流量免费——这让「把对外流量都走 CDN」在 AWS 上同时是性能优化和成本优化，比在阿里云上的收益更明显。二是 WAF 按规则数与请求数计费，与阿里云按实例规格计费不同，规则多的场景成本模型完全不一样。三是 AWS 没有内容审核这类产品——这是国内业务的强制合规需求，阿里云有原生服务而 AWS 完全不覆盖，涉及 UGC 的国内业务必须自行解决。此外 Route 53 的健康检查与故障转移策略比阿里云 DNS 更完整，是跨 Region 容灾的实际执行机制。
跨层 · 管控与运营
AWS 跨层与阿里云域的重心相同（成本治理与多账号组织），但有三处差异值得重点讲。一是 服务控制策略（SCP）与 L5 的策略评估直接呼应——它是「只能收窄不能放宽」那条规则的组织级体现，也是防止成员账号越界的唯一硬手段，比在每个账号里配策略可靠得多。二是 AWS 的多账号实践更成熟且更被推荐：Landing Zone 与账号工厂把「新业务开一个账号」变成标准动作，而这在阿里云上通常不是默认做法。三是 Well-Architected 框架——AWS 特有的架构评审方法论，阿里云没有同等分量的对应物，它的实际价值在于提供一套可重复的提问清单而非工具。成本治理的结论与阿里云一致：失控几乎从来不是单价贵而是没人管。
Azure
主场：L3 / L5
L1 物理层
跟 AWS 域、阿里云域一样，Azure 把数据中心里需要采购的物理层内容全部接管了，这层不是产品矩阵。仍然真实的内容有三块：区域与可用区的选址、ExpressRoute 的物理端口采购与运营商施工、以及虚拟机规格对应的网络性能上限。需要额外说明一个容易被忽略的国内特殊情况：Azure 的中国大陆区域不是由微软直接运营的，由于国内对外资电信/云基础设施的监管要求，中国大陆区域由世纪互联运营（对外称「Azure 由世纪互联运营」），是与全球版 Azure 相互独立的部署——门户、功能可用性与账单都是分开的，很多全球版功能在国内区域会有延迟或缺失，选型前必须单独核实。这不是 Azure 独有的安排，AWS 的中国区域同样由光环新网与西云数据独立运营，但读全球版文档时很容易忘记这一层区别。
L2 数据链路层
跟 AWS、阿里云域一样，核心是「云上没有什么」：VNet 是三层虚拟网络，不支持广播与组播、不能延伸 VLAN、没有生成树与堆叠。但 Azure 在这一层有一个跟 AWS/阿里云都不同的重要设计：Azure 的子网不绑定单个可用区——VNet 本身就跨越region 内的所有可用区，子网是纯粹的三层地址划分单元，可用区是在子网内创建具体资源（虚拟机、负载均衡器）时单独指定的属性，而不是子网本身的边界。这跟 AWS VPC 与阿里云 VPC「一个子网只能属于一个可用区」的设计不同——迁移架构图时容易按 AWS/阿里云的思维把子网当成可用区边界来画，这在 Azure 上是错误的。
L3 网络层
这是 Azure 网络的主体层，概念与 AWS、阿里云域大部分对应，重点讲三处实际差异。一是网络安全组的连接跟踪机制：跟安全组一样是有状态的，但可以同时绑定在子网与网络接口两级，两级规则叠加生效，规划不清晰时最终生效规则很难审计——这跟阿里云域「安全组只在实例级」的心智模型不同。二是 ExpressRoute Global Reach：可以把两条独立的 ExpressRoute 线路直接互联，让两个不同的本地机房通过微软骨干网互通，不需要额外建专线，这是 AWS Direct Connect 没有对应产品的能力（AWS 的等价方案是自建 Transit VPC 或用 Direct Connect Gateway 间接实现，机制不同）。
L4 传输层
Azure 在这一层的产品分工跟 AWS 有一个容易混淆的地方：Load Balancer（四层）与 Application Gateway（七层）是两个独立产品，不像 AWS 用 ALB/NLB 两个 SKU 覆盖同一个产品家族——选型时如果只需要四层负载均衡却买了 Application Gateway，会承担不必要的复杂度与成本；反之如果需要七层能力却只用了 Load Balancer，则完全不支持基于 URL 路径的路由。Load Balancer 本身分 Basic 与 Standard 两档 SKU，差异不只是功能（Standard 才支持跨可用区、健康探测更完整、有 SLA），Basic 档已逐步走向退役，新架构应默认选 Standard。
L5 会话层
这是这个域信息价值最高的一层，因为 Microsoft Entra ID（原 Azure Active Directory）的租户模型跟 AWS IAM 的账号模型是两种完全不同的身份体系，也是跨云迁移时最容易产生认知错位的地方。AWS 的身份边界是「账号」，一个账号下的 IAM 用户/角色默认只在这个账号内有意义；Azure 的身份边界是「租户」，一个租户可以对应组织里的一批用户与设备，多个订阅（相当于 AWS 账号）可以共享同一个租户身份系统——这意味着企业级 Azure 部署天然要考虑跟企业现有 Active Directory 的混合身份同步（通过 Microsoft Entra Connect 把本地 AD 账号同步到云端），而这套「本地目录服务延伸到云」的心智模型是 AWS IAM 体系里没…
L6 表示层
跟本站 AWS 域一样，这一层要跟本站国内厂商域形成反向对照：Azure 跟思科、Arista、Juniper、Palo Alto、AWS 一样，没有国密（SM2/SM3/SM4）支持、不在国内信创目录——涉及商密合规或国产化要求的国内项目，Azure 不在可选范围，这是合规资质问题而不是能力问题，是硬约束。除此之外 Azure 的密钥、密文与证书能力相对完整，但产品边界跟 AWS 不同：Key Vault 是一个合并型产品，同时覆盖了 AWS 上分成三个独立产品的能力——密钥管理（对应 AWS KMS）、密文/连接字符串管理（对应 AWS Secrets Manager）与证书管理（对应 AWS Certificate Manager）——选型时不需要像在 AWS 上一样为这三类需求各…
L7 应用层
Azure 在这一层最容易让人困惑的地方，是把 AWS Route 53 一个产品承担的能力拆成了三个独立产品：Azure DNS（纯粹的 DNS 区域托管）、Traffic Manager（基于 DNS 解析层面的流量路由，比如按地理位置或优先级返回不同的解析结果，但它自己不代理流量）、以及 Front Door（真正的边缘七层反向代理，流量实际经过它的边缘节点，可以做路径路由、WAF、TLS 终结与就近加速）——三者解决的问题层次完全不同，选错会导致「我明明配了流量管理却没有实现预期效果」。简单区分：只需要托管域名解析用 Azure DNS；需要基于地理位置或健康状态在多个源站之间做 DNS 级别的流量分配、且可以接受 DNS 解析带来的切换延迟，用 Traffic Manager；
跨层 · 管控与运营
Azure 跨层的重心跟 AWS、阿里云域一致（成本治理与多账号/多订阅组织），但有两处差异值得重点讲。一是资源组（Resource Group）这个 Azure 特有的组织单元——AWS 和阿里云都没有直接对应物：一个订阅下的资源必须归属某个资源组，资源组通常是生命周期管理的基本单元（可以整组创建、整组删除），这跟 AWS 用标签模拟分组、阿里云用资源目录分组的做法不同，资源组是一等公民而不是元数据。
GCP
主场：L2 / L7
L1 物理层
跟 AWS、阿里云、Azure 域一样，GCP 把数据中心里需要采购的物理层内容全部接管了，这层不是产品矩阵。仍然真实的内容有区域与可用区选址、Interconnect 的物理端口采购，以及虚拟机规格对应的网络性能上限。这个域在这一层有两个相对独特的点值得单独讲：一是虚拟机的透明热迁移——主机需要维护或预测到硬件即将故障时，GCP 会把运行中的虚拟机透明迁移到另一台主机，工作负载不中断、不需要重启，这跟 AWS/Azure 上很多维护事件要求用户自己停机重启的模式不同；
L2 数据链路层
这是这个域第一个星标层，也是 GCP 跟 AWS、阿里云、Azure 最根本的架构差异所在：GCP 的 VPC 是全球资源，不是区域资源。一个 VPC 网络可以在全球任意多个区域创建子网，不同区域的子网之间默认就能通过 Google 自己的全球私有骨干网互通，不需要像 AWS VPC 跨区域那样建对等连接或 Transit Gateway，也不需要像 Azure VNet 跨区域那样建 VNet 对等或 Virtual WAN——一个 VPC 天然就是全球的。这不是「更大的区域」，而是完全不同的抽象层级：AWS 与 Azure 的多区域组网需要用户显式搭建互联，GCP 的多区域组网从 VPC 创建的那一刻起就已经存在。
L3 网络层
这一层要讲清楚 GCP 特有的两套结构。一是共享 VPC（Shared VPC）：一个「宿主项目」持有 VPC 网络，多个「服务项目」的资源可以直接使用宿主项目的子网，网络管理与业务资源管理由此解耦到不同团队——这跟 AWS 的 VPC 共享（通过 RAM）、Azure 单订阅内网络的模式都不完全一样，GCP 的共享 VPC 是围绕多项目协作设计的原生机制。二是资源层级：组织 → 文件夹 → 项目——项目是计费与资源的基本容器（概念上接近 AWS 账号或 Azure 订阅），文件夹可以按部门或环境分组项目，IAM 权限与组织策略沿着这条层级链向下继承，这跟 AWS Organizations 的组织单元、Azure 管理组的定位类似，命名和具体机制略有差异。
L4 传输层
跟本站 Azure 域强调的产品分工类似，GCP 也把四层负载均衡（Passthrough Network Load Balancer）与七层负载均衡（在 L7 的全球负载均衡里）设计成不同产品，但侧重点不同：GCP 的四层直通负载均衡器本质是区域资源——真正的全球范围能力被留在了 L7（全球锚定 IP 的负载均衡），这跟 GCP 在 L2/L3 强调「网络本身是全球资源」形成一个值得注意的对比：并不是 GCP 的所有产品都做到了全球范围，四层负载均衡这一层选择的是区域内直通转发（数据包直接转发到后端，不终结连接、默认保留客户端源 IP），性能开销比七层代理更低，适合对时延和吞吐要求高、不需要七层内容感知的场景。
L5 会话层
这一层的核心是 Identity-Aware Proxy（IAP）——它是 Google 内部 BeyondCorp 零信任理念对外产品化的落地：BeyondCorp 是 Google 多年前就开始在公司内部实践的思路，核心主张是「不应该因为一个设备在公司内网就默认信任它，访问控制应该基于身份与设备状态，而不是网络位置」，Google 把这套内部实践对外发表过论文并逐步产品化，IAP 正是这个思路面向云资源访问的产品形态。IAP 同时覆盖两种场景：一是给 SSH/RDP 建立基于身份验证的隧道，虚拟机不需要公网 IP、也不需要开放管理端口，跟本站 AWS 域的会话管理器、Azure 域的 Bastion 定位类似；
L6 表示层
跟本站 AWS、Azure 域一样，这一层要跟本站国内厂商域形成反向对照：GCP 跟思科、Arista、Juniper、Palo Alto、AWS、Azure 一样，没有国密（SM2/SM3/SM4）支持、不在国内信创目录——涉及商密合规或国产化要求的国内项目，GCP 不在可选范围，这是合规资质问题而不是能力问题，是硬约束。产品结构上，GCP 跟 AWS 的做法更接近：Cloud KMS（密钥管理）、Secret Manager（密文管理）与 Certificate Manager（证书管理）是三个独立产品，不像 Azure Key Vault 把三者合并进同一个产品——这意味着选型时需要像在 AWS 上一样分别评估这三类需求，但也意味着权限可以天然按产品边界隔离，不容易出现「一个入口权…
L7 应用层
这是这个域的第二个星标层，也是全球 VPC 架构（见 L2）在应用层的自然延伸：全球外部应用负载均衡器（Global External Application Load Balancer）用单个全球锚定 IP 同时覆盖多个区域的后端——这个锚定 IP 会从全球各地的 Google 边缘节点以任播（Anycast）方式对外广播，客户端请求自动被路由到延迟最低的入口点，再经 Google 私有骨干网转发到最近健康的后端区域，故障切换与就近接入都内建在这一个产品里。
跨层 · 管控与运营
Azure 域用 Resource Group 作为一等公民组织单元、Management Group 加 Policy 做组织级治理，GCP 在这一层的对应结构在 L3 已经讲过资源层级本身（组织 → 文件夹 → 项目），跨层管控真正要展开的是 Organization Policy Service：跟 Azure Policy 类似，它既能做预防性拦截（比如禁止创建带公网 IP 的虚拟机），约束沿组织层级向下继承且只能收紧不能放宽，这跟 AWS SCP 与 Azure Policy 的核心规则一致；
OCI
主场：L1 / L3
L1 物理层
跟本站其他云域一样，OCI 把数据中心里需要采购的物理层内容全部接管了，这层不是产品矩阵。命名上有一处需要单独说明：OCI 用「可用性域（Availability Domain）」而不是「可用区」，部分区域内只有一个可用性域，此时故障隔离要靠可用性域内部再划分的「故障域（Fault Domain）」——选型时不能直接套用 AWS/Azure/GCP「每个区域至少三个可用区」的默认假设，需要先查目标区域的可用性域数量。
L2 数据链路层
这一层要讲清楚 OCI 一个容易被忽略的设计：它同时提供两套并行的防火墙机制——安全列表（Security List，绑定在子网上）与网络安全组（NSG，绑定在资源上）——两者可以同时生效，实际放行规则是两者的叠加。这跟本站 Azure 域强调的 NSG 两级绑定（子网级 + 网络接口级，同属一个产品）不同：OCI 是两个不同名称、不同管理界面的产品同时作用于同一份流量，规划不清晰时更容易出现「明明配置了 NSG 允许，却因为安全列表没放行而被拦」这类排查困难。
L3 网络层
这是这个域网络的主体层。VCN 是区域资源（跟 AWS VPC、Azure VNet 一样，不是 GCP 那种全球资源），跨区域互通需要通过动态路由网关（DRG）做远程 VCN 对等——DRG v2 可以同时作为多个 VCN、FastConnect 专线、site-to-site VPN 与跨区域对等的单一枢纽，定位跟 AWS Transit Gateway、Azure Virtual WAN 类似。
L4 传输层
跟 Azure 域强调的产品分工类似，OCI 也把七层负载均衡（Load Balancer）与四层直通负载均衡（Network Load Balancer）设计成不同产品，但计费模式上有一个真实的差异值得单独讲：Network Load Balancer 本身不收取实例小时费或数据处理费，只需要为后端资源正常付费——这跟 AWS NLB、Azure Load Balancer Standard、GCP Passthrough Network Load Balancer 都按流量或规则数计费不同，是选型时应该纳入成本对比的真实变量。
L5 会话层
这一层最值得单独展开的是 IAM 策略的语句化语法：OCI 的权限策略不是写成 JSON 文档，而是写成接近自然语言的句子，比如「Allow group Administrators to manage all-resources in tenancy」——这跟 AWS/Azure/GCP 都用结构化 JSON 或专用策略语言的做法不同，可读性明显更高，非专职安全工程师也能大致看懂一条策略在做什么，但表达复杂条件（比如多重否定或复杂的资源匹配）时不如 JSON 策略灵活，需要拆成多条语句组合。
L6 表示层
跟本站 AWS、Azure、GCP 域一样，这一层要跟本站国内厂商域形成反向对照：OCI 跟另外四家一样，没有国密（SM2/SM3/SM4）支持、不在国内信创目录——涉及商密合规或国产化要求的国内项目，OCI 不在可选范围。产品结构上，OCI 处在 Azure 的完全合并（Key Vault 一个产品覆盖三类数据）与 AWS/GCP 的完全拆分（三个独立产品）之间：Vault 把密钥管理与密文管理合并进同一个产品（跟 Azure 类似），但证书管理是独立的 Certificates 产品（跟 AWS/GCP 类似）——四家云厂商在这个产品边界问题上呈现出「全合并、全拆分、部分合并」三种不同答案，OCI 是「部分合并」这一类的代表。
L7 应用层
这一层先要如实说明一个跟本站 GCP 域形成的对比：GCP 的全球外部负载均衡器用单一全球锚定 IP 覆盖多区域后端（见 GCP 域 L7），而 OCI 的 Load Balancer（七层）跟 VCN 一样是区域资源，不具备跨区域的单一入口能力——如果业务需要跨区域的全局流量分配与故障切换，需要在 DNS 层面做流量路由，而不是假设负载均衡器本身能覆盖多区域。DNS 产品结构上 OCI 更接近 AWS：OCI DNS 把区域托管与基于健康检查/地理位置的流量控制策略（Traffic Management Steering Policy）做进了同一个产品，不像 Azure 域强调的「DNS 托管、流量路由、边缘代理三个独立产品」那种拆分——这是又一个「四家云厂商分成不同阵营」的例子。
跨层 · 管控与运营
这一层的核心是隔间（Compartment）：跟 AWS 账号、Azure 订阅、GCP 项目都不同，隔间是同一个租户内部的纯逻辑分区，不需要为不同的团队或环境创建独立的账号/租户就能获得清晰的资源隔离与权限边界——一个隔间可以嵌套子隔间，IAM 策略按隔间设置并向下继承，资源可以在隔间之间移动而不需要重新创建。这跟 AWS 需要多账号才能获得强隔离、Azure 用管理组分组多个订阅、GCP 用文件夹分组多个项目的做法都不一样：OCI 从一开始就假设大多数场景只需要一个租户，隔间承担了其他三家云厂商需要靠多账号/多订阅/多项目才能做到的隔离效果。
