There Is no Layer-2 in Public Cloud

The amount of layer-2 tricks we use to make enterprise networking work never ceases to amaze me - from shared IP addresses used by various clustering solutions (because it’s too hard to read the manuals and configure DNS) to shared MAC addresses used by first-hop router redundancy protocols (because it would be really hard to send a Gratuitous ARP message on failover) and all sorts of shenanigans we’re forced to engage in to enable running servers to be moved willy-nilly around the Earth.

The only way to get rid of that complexity is to say “NO, we won’t support that” or “NO, that is too risky” and I have rarely seen an enterprise networking architect who would be able to stick to that decision for a long time. Public cloud providers are different - they are big enough that an individual customer doesn’t matter (much), so it was pretty easy for them to say NO, you can’t use any of the layer-2 tricks, or run your own routing protocols, or ask us to implement IP Multicast. We don’t care, you are free to walk away to our competitor… who made the same decision.”

It seems someone managed to pay enough to get IP multicast into AWS, and AWS started down the slippery slope of implementing half-baked kludges. More about that in another blog post.

Migrating to a public cloud is thus an excellent opportunity to get your house in order. After all, if the same developers and server administrators who continuously ask for layer-2 extensions in enterprise data centers manage to implement their application stacks in a public cloud, they clearly demonstrated that there is no technology limitation to cleaning up your enterprise network.

While public clouds seem like a layer-3 nirvana, they present unique challenges. How do you implement shared IP addresses? How do you bring your own network appliances into a public cloud? How do you do service insertion (pushing traffic through your network appliances)? We’ll cover all these aspects of public cloud networking, including examples from AWS and Azure, in our Networking in Public Cloud Deployments course. All you have to do is register.


  1. You implement service insertion through Ingress Routing. ;)

    BTW I suspect multicast has made its appearance in conjunction with Local Zones and Outposts, rather than on its own.
    1. And we both know that works only for traffic received from outside of VPC ;)
  2. That (Outposts as possible source of multicast support enablement reason) is probably correct. We relied on multicast, when having decided to acquire Outposts.
Add comment