云厂商里的 MAC：AWS/Azure/GCP 各自怎么分配，以及查出来是厂商前缀意味着什么
本地虚拟化那条线很简单：VMware 用 00:50:56、Hyper-V 用 00:15:5D、Xen 用 00:16:3E，查出来什么前缀就知道它跑在哪个平台上，虚拟机的 MAC 地址 那篇讲的就是这套。云上的故事没这么直接。AWS、Azure、GCP 三家都自己注册了 OUI 前缀、在底层各自实现了一套 MAC 生成规则，而且因为云平台的物理约束，有些在本地虚拟化里理所当然的事情（比如"MAC 会跟着快照走"）到了云上就不是那么回事了。这篇把三家摊开讲。
云厂商为什么要自己注册 OUI
一个云平台可能同时跑着几十万到几百万台 VM，每台至少一个网卡。如果它还在用 VMware 或 Hyper-V 的 OUI，那等于在替这些平台消耗 MAC 空间。更重要的是，云厂商必须知道每台 ENI（Elastic Network Interface，弹性网卡）的 MAC，才能在物理网络里做正确的转发。
所以三家都注册了自己的前缀池：Amazon 一家就持有 203 个 OUI 前缀（见 ssid.ai 的 Amazon 目录），Microsoft 和 Google 各持几十个。在本站查询页输入一个查出来是 Amazon/Microsoft/Google 的 MAC，几乎可以直接断定：这是一台跑在该云上的 VM 或弹性网卡，而不是你的笔记本。
AWS：ENI 的 MAC 来自 Amazon 自己的前缀池
AWS 的 Nitro 架构（2017 年后几乎所有新实例类型都跑在 Nitro 上）里，每台 EC2 至少有一个默认 ENI，可以额外挂最多 15 个。每个 ENI 的 MAC 地址是 Amazon 从自己的 OUI 前缀池里分配的——不是 VMware 的 00:50:56，也不是 Hyper-V 的 00:15:5D，而是 Amazon 注册的那些。在 查询页 输入一个 10:AE:60:... 开头的地址，看到的是 Amazon Technologies Inc. 而不是 VMware，这就是云上虚拟化和本地虚拟化在 MAC 前缀上的直接区别。
关键行为。 MAC 一旦分配给 ENI，就和这个 ENI 永久绑定——不管这个 ENI 挂在哪台实例上、挂多少台，它都保持同一个 MAC。这和本地虚拟化里"一个 VM 绑定一块虚拟网卡，MAC 跟着 VM 走"的语义不同。AWS 的 VPC Flow Logs 记录的也是这个 ENI 的 MAC，不是底层宿主机的 MAC。
AWS 里能指定 MAC 吗？ 2026 年起 AWS 允许在部分实例类型上通过 AssignMacAddress 参数显式指定一个前缀在 Amazon 池里的地址（不能随便给一个 00:50:56 的），但这是稀有需求——绝大多数场景下 MAC 由 Amazon 自动分配。
云特有的陷阱之一：快照不等于 MAC。 在本地虚拟化里，你拍一个 VMware 模板快照，基于它克隆出的所有虚机都继承同一块虚拟网卡（可能后来会被 Hypervisor 自动换 MAC 避免冲突，但这是 Hypervisor 的行为）。在 AWS 上，快照只包含磁盘，不包含 ENI——从同一个 AMI 启动一百台实例，会拿到一百个全新的默认 ENI，每个 ENI 一个全新的 Amazon 前缀 MAC。想要稳定 MAC？得创建预定义 ENI 并手动挂载到每台实例上。
Azure：IMDS 里能查到 MAC，但有两层
Azure VM 的网络接口 MAC 存储在实例元数据服务（IMDS，169.254.169.254）里，通过请求 /metadata/instance/network/interface/?api-version=2025-04-01 可以拿到完整的 macAddress 字段。典型前缀是 00:0D:3A、00:15:5D（注意 Hyper-V 在本地也用 00:15:5D，所以这个前缀本身不能区分"跑在 Azure 上的 Hyper-V VM"还是"本地 Hyper-V VM"）。Azure VMM 的官方文档把 00:0D:3A 列为 Microsoft 保留、00:15:5D 列为 Hyper-V 默认池的一部分，这也解释了为什么两个前缀同时存在。
两层 MAC 的问题。 Azure 的公共 IP 通过 Azure 的平台 NAT/负载均衡器访问互联网时，外部流量看到的 MAC 是 Azure 平台出口的 MAC，不是 VM 内部看到的那个。所以"抓包拿到的 MAC"和"实例 ip link 看到的 MAC"可能不是同一个——这和本地虚拟化里"二层帧直通"的模型不同。排查 Azure VM 的出站流量时，不要假设包的源 MAC 就是你在 IMDS 里查到的那个。
Azure Sphere 和 IoT Hub 走的是另一套前缀（IoT 设备本身有 OUI，和 VM 的前缀不重叠），所以在 IoT 日志里查 MAC 看到的是硬件厂商前缀，不是 Microsoft 前缀。
GCP Compute Engine：VirtIO 和 gVNIC，MAC 也能指定
GCP 三代以前用 VirtIO 作为默认 vNIC 后端，三代以后改用 gVNIC（Google Virtual NIC）。实例的 MAC 可以在创建时通过实例元数据 API 或 gcloud compute instances create --network-interface mac-address=... 指定，同样前缀必须落在 Google 的注册池里。在 查询页 输入一个查出来是 Google LLC 的前缀，就能判定这是 GCP VM 的网卡。
GCP 的一个细节：IPv6 地址会根据 MAC 生成 EUI-64 接口标识，这和 EUI-64 与 IPv6 讲的是同一件事——把 MAC 的前 3 字节和后 3 字节中间插一个 FF:FE，反转第一字节的本地管理位得到。在 GCP VM 上看到 FF:FE，还原 MAC 的方法就是那篇讲的。
为什么云平台偏爱 ipvlan 而不是 macvlan
本地虚拟化和容器网络里，macvlan 给每个虚拟/容器接口分配自己的 MAC，直接接在二层网络上。到了云上，每个 ENI/网卡通常只允许一个 MAC 地址——云平台在物理 NIC 上开端口安全（port-security），阻止额外 MAC 进入。macvlan 在云上几乎必然被 block，因为它需要主机 NIC 处于混杂模式且接受多个 MAC。
这就是 ipvlan 在云原生部署里流行的原因：ipvlan 的 L2 模式让容器接口共享主机的物理 MAC，不产生新的二层地址。缺点是你无法区分"主机"和"容器"的源 MAC，但这正符合云平台只开放一个二层标识给租户的模型。在本站查询页看到一个云厂商前缀的 MAC 时，它几乎一定属于某个 ENI 的 ipvlan 主接口，而不是某个容器自己的 MAC。
和本地虚拟化的真正差别
把 虚拟机的 MAC 地址 那篇里的表格和云厂商放一起对比，有三个核心不同：
| 维度 | 本地虚拟化 | 云厂商 |
|---|---|---|
| MAC 前缀来源 | Hypervisor 平台自己的 OUI | 云平台注册的 OUI 池 |
| MAC 归属 | 跟着 VM 走 | 跟着 ENI 走，可挂载到任意实例 |
| 快照/模板 | 克隆出的 VM 可能继承或重生成 MAC | 快照不含 ENI，每次启动都是新 MAC |
本地虚拟化里查 00:50:56 意味着 VMware，查 00:15:5D 意味着 Hyper-V；云上查 Amazon 前缀意味着 AWS ENI，查 Microsoft 前缀可能是 Azure VM 或本地 Hyper-V，查 Google 前缀意味着 GCP。这张判断表是运维排查混合环境时最实用的一张——接到一个告警里的 MAC，先在 查询页 查出厂商，就能立刻判断出"这台设备在云上还是在本地"。
实务建议
对 SRE/DevOps。
- 别用 MAC 做云资产唯一键。 云快照、迁移、实例重建都会换 MAC。云原生资产盘点应改用实例 ID（AWS Instance ID、Azure VM ID、GCP Instance Name）或容器 ID，MAC 只作为辅助定位信息。
- 想固定 MAC 就要显式预创建 ENI。 AWS 的"默认 ENI"会在实例删除时跟着销毁；要长期稳定，创建时指定自定义 ENI 再挂载。GCP 同理用
--network-interface mac-address=。 - 云防火墙/安全组不是二层设备。 三者的安全组/NSG 都按 IP + 端口 + 协议过滤，不检查 MAC 地址。不要尝试用白名单 MAC 作为云安全层。
- ipvlan 容器的 MAC 就是宿主机的 MAC。 在云上抓包看到容器流量的源 MAC 是云厂商前缀时，它可能是某个容器的 ipvlan 接口，不一定是实例主接口本身。
- EUI-64 还原 MAC 在 GCP 上尤其有用。 云日志经常只记 IPv6，看到
FE80::开头的链路本地地址里有FF:FE，就能用本站查询页还原 MAC → 还原厂商。
对本站用户。 你在 查询页 输入一个 Amazon 或 Microsoft 前缀，不要假设那就是"硬件厂商"——它可能是云平台注册的 OUI，只标识"某台云上的 ENI"，不标识具体哪家硬件厂商。这种前缀查询不到更细粒度的设备型号，是正常的。查询到本地管理地址（02/06/AE 开头）则意味着它是某个容器、ipvlan 或随机化客户端，详细判断见 读懂 MAC 地址第一字节。
一句话总结
本地虚拟化里，MAC 前缀对应 Hypervisor 平台；云上，MAC 前缀对应云平台注册池，且跟着 ENI 走不跟着 VM 走。云平台的物理约束（每接口只允许一个 MAC）迫使 ipvlan 取代 macvlan，快照不带 ENI 意味着云原生部署里 MAC 永远不会稳定。查出来是 Amazon/Microsoft/Google → 云，查出来是 VMware/Xen/Hyper-V → 本地，这张对照表是排查混合环境最省时间的工具。
参考资料
- AWS EC2 describe-network-interfaces（返回 MacAddress 字段）：https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-interfaces.html
- Azure Instance Metadata Service（IMDS）：https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service
- Azure IP Ranges and Service Tags（2026-09-21）：https://www.microsoft.com/en-us/download/details.aspx?id=56519
- GCP Compute Engine VM 网络概览：https://docs.cloud.google.com/compute/docs/networking/network-overview
- GCP gVNIC 文档：https://docs.cloud.google.com/compute/docs/networking/using-gvnic
- AWS Nitro 架构说明：https://aws.amazon.com/nitro/
- ssid.ai Amazon 203 个 OUI 前缀目录：https://ssid.ai/directory/registrant/amazon-technologies-inc
- 本站 虚拟机的 MAC 地址分配规则
- 本站 EUI-64 与 IPv6 接口标识
- 本站 读懂 MAC 地址第一字节：U/L 位与 I/G 位