MAC Addresses in the Cloud: AWS, Azure and GCP Assignment Rules and What the OUI Prefix Tells You

On premises, the story is straightforward: VMware uses 00:50:56, Hyper-V 00:15:5D, Xen 00:16:3E, and a lookup on the query page tells you straight away which platform a VM sits on — that is the subject of MAC addresses of virtual machines. On the cloud it is less direct. AWS, Azure and GCP each registered their own OUI pools, each implemented their own MAC-generation rules at the hypervisor layer, and some things that are natural on premises (MAC travels with the VM even through snapshots) simply do not work that way in a cloud environment. This article breaks all three down.

Why do cloud providers register their own OUIs

A cloud platform may run hundreds of thousands of VMs simultaneously, each with at least one interface. If it still consumed VMware or Hyper-V OUIs it would be exhausting their address space. More importantly, the platform must know every ENI's MAC so the physical network can forward correctly.

All three therefore registered their own prefix pools. Amazon alone holds 203 OUI prefixes (see ssid.ai's Amazon directory); Microsoft and Google hold dozens each. Entering a MAC on the lookup page that resolves to "Amazon Technologies Inc." or "Microsoft Corporation" or "Google LLC" is almost always a conclusive sign that you are looking at a cloud ENI, not a laptop.

AWS: the ENI's MAC comes from Amazon's own OUI pool

On Nitro (the architecture that powers every recent EC2 instance type since 2017), each instance has at least one default ENI and up to 15 extra ones. Every ENI's MAC is allocated from Amazon's own OUI pool — not VMware's 00:50:56, not Hyper-V's 00:15:5D, but one of the 203 Amazon-registered prefixes. A MAC starting with 10:AE:60 resolves to Amazon Technologies Inc., not VMware, and that difference is exactly where cloud virtualisation diverges from on-prem virtualisation.

Key behaviour. The MAC, once assigned to an ENI, is bound to that ENI for life — no matter which instance you attach it to, or how many instances you move it across, it keeps the same MAC. That is different from on-prem where a MAC typically travels with one VM. VPC Flow Logs record this ENI MAC, not the underlying host MAC.

Can you specify the MAC on AWS? As of 2026, a subset of instance types accepts an AssignMacAddress parameter that lets you pick a prefix inside Amazon's pool (you cannot feed it an arbitrary 00:50:56). That is a rare need; almost all workloads rely on auto-allocation.

A cloud-specific trap: snapshots do not carry MACs. On premises, cloning a VMware template produces children that share the template's virtual NIC (the hypervisor may regenerate MACs to avoid collisions, but that is the hypervisor's choice). On AWS, a snapshot contains only the disk — it does not contain the ENI. Launch a hundred instances from the same AMI and you will get a hundred brand-new default ENIs, each with a brand-new Amazon-prefix MAC. For a stable MAC you must pre-create a custom ENI and attach it to each instance.

Azure: IMDS gives you the MAC, but there are two layers

An Azure VM's interface MAC lives in the Instance Metadata Service (IMDS at 169.254.169.254). Request /metadata/instance/network/interface/?api-version=2025-04-01 and you get the full macAddress field. Typical prefixes are 00:0D:3A and 00:15:5D — note that Hyper-V on premises also uses 00:15:5D, so that prefix alone cannot distinguish "an Azure VM" from "a local Hyper-V VM". Microsoft's own VMM documentation lists 00:0D:3A as a Microsoft-reserved range and 00:15:5D as Hyper-V's default pool, which explains why both coexist.

The two-layers problem. When an Azure VM reaches the internet through Azure's platform NAT or load balancer, packets leave with Azure's platform egress MAC, not the MAC you see inside the VM from ip link. So the MAC you see in a capture and the one you get from IMDS may not match — unlike on premises where layer-2 frames pass straight through. Troubleshooting Azure outbound traffic? Don't assume the source MAC in the capture is what IMDS told you.

Azure Sphere and IoT Hub devices use their own hardware-vendor OUIs, not Microsoft's pool, so an IoT device log lookup will surface the hardware maker rather than Microsoft.

GCP Compute Engine: VirtIO, gVNIC, and the MAC is specifiable

Before generation 3, GCP used VirtIO as the default vNIC backend; generation 3 and later default to gVNIC (Google Virtual NIC). You can specify a MAC at instance creation time through the instance metadata API or via gcloud compute instances create --network-interface mac-address=..., again bound to Google's registered pool. A lookup page hit of "Google LLC" confirms a GCP interface.

A GCP detail worth noting: IPv6 addresses derive their interface identifier via EUI-64 from the MAC — exactly the mechanism described in EUI-64 and IPv6. Spotting FF:FE in a link-local address on a GCP instance? You can recover the MAC from that pattern and feed it into the lookup page.

Why cloud platforms prefer ipvlan over macvlan

On premises, macvlan gives each virtual or container interface its own MAC on the L2 segment. On the cloud, each ENI usually allows only one MAC address. The cloud platform enforces port security on the physical NIC and drops extras. macvlan almost always breaks on the cloud because it needs promiscuous mode and multiple MACs per physical port.

That is why ipvlan is ubiquitous in cloud-native deployments. ipvlan L2 mode makes a container interface share the host's physical MAC rather than introducing a new L2 address. You cannot tell host from container by MAC anymore, but that is exactly the one-L2-identifier model the cloud exposes to tenants. When you look up a cloud-prefix MAC on the query page, it is almost certainly an ipvlan primary interface of an ENI, not a container's own MAC.

The real difference from on-prem virtualisation

Putting the table from MAC addresses of virtual machines next to the cloud vendors, three structural differences stand out:

On premises a 00:50:56 means VMware, a 00:15:5D means Hyper-V. On the cloud, an Amazon prefix means an AWS ENI, a Microsoft prefix could be Azure or local Hyper-V, a Google prefix means GCP. That mapping is the single fastest sanity check during incident response: given a MAC from an alert, a lookup page hit tells you instantly whether the device sits on the cloud or on premises.

Practical guidance

For SRE / DevOps.

1. Do not use MAC as the cloud asset's unique key. Snapshots, migrations and instance rebuilds all change MACs. Cloud-native asset inventory should pivot to instance IDs (AWS Instance ID, Azure VM ID, GCP instance name) or container IDs, with MAC as a secondary hint.
2. Want a stable MAC? Pre-create a custom ENI. An AWS default ENI is destroyed together with its instance. For long-term stability you create it separately and mount it to instances. GCP uses --network-interface mac-address= the same way.
3. Cloud security groups do not operate at layer 2. All three providers filter by IP + port + protocol — MAC addresses are not inspected. Don't try using MAC whitelisting as the cloud security layer.
4. An ipvlan container's MAC is the host's MAC. When you see cloud-prefix MACs in a capture originating from container traffic, it may be the ENI's ipvlan primary interface rather than the host interface itself.
5. EUI-64 recovery is especially useful on GCP. Cloud logs often record only IPv6; spotting FF:FE inside a link-local address lets you reconstruct the MAC and run it through the lookup page to recover the vendor.

For readers of this site. If a lookup on the query page returns Amazon or Microsoft, do not think "hardware vendor" — it is the cloud provider's OUI and only identifies "some cloud ENI", not a specific hardware maker. A failed lookup that starts with a locally-administered bit (02/06/AE) means a container, an ipvlan interface or a randomised client; the full rules are in reading the first byte of a MAC address.

In one sentence

On premises the MAC prefix tells you the hypervisor. On the cloud it tells you the cloud provider's own pool, and travels with the ENI rather than the VM. The physical constraint of "one MAC per cloud interface" pushed ipvlan over macvlan, and the fact that snapshots carry no ENI means MACs never stabilise in cloud-native deployments. Amazon/Microsoft/Google prefix → cloud; VMware/Xen/Hyper-V → on-prem — that table saves more troubleshooting time than any other single step.

References

• AWS EC2 describe-network-interfaces (returns MacAddress): https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-interfaces.html
• Azure Instance Metadata Service: 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 networking overview: https://docs.cloud.google.com/compute/docs/networking/network-overview
• GCP gVNIC docs: https://docs.cloud.google.com/compute/docs/networking/using-gvnic
• AWS Nitro architecture: https://aws.amazon.com/nitro/
• ssid.ai directory of Amazon's 203 OUI prefixes: https://ssid.ai/directory/registrant/amazon-technologies-inc
• This site: MAC addresses of virtual machines
• This site: EUI-64 and IPv6 interface identifiers
• This site: Reading the first byte of a MAC address: U/L and I/G bits