Now that you know all about regions and availability zones (AZ) and the ways AWS and Azure implement subnets, let’s get to the crux of the original question Daniel Dib sent me:

As I understand it, subnets in Azure span availability zones. Do you see any drawback to this? You mentioned that it’s difficult to create application swimlanes that way. But does subnet matter if your VMs are in different AZs?

It’s time I explain the concepts of application swimlanes and how they apply to availability zones in public clouds.

Now that we know what regions and availability zones are, let’s go back to Daniel Dib’s question:

As I understand it, subnets in Azure span availability zones. Do you see any drawback to this? Does subnet matter if your VMs are in different AZs?

Wait, what? A subnet is stretched across multiple failure domains? Didn’t Ivan claim that’s ridiculous?

TL&DR: What I claimed was that a single layer-2 network is a single failure domain. Things are a bit more complex in public clouds. Keep reading and you’ll find out why.

My friend Daniel Dib sent me this interesting question:

As I understand it, subnets in Azure span availability zones. Do you see any drawback to this? Does subnet matter if your VMs are in different AZs?

I’m positive I don’t have to tell you what networks, subnets, and VRFs are, but you might not have worked with public cloud availability zones before. Before going into the details of Daniel’s question (and it will take us three blog posts to get to the end), let’s introduce regions and availability zones (you’ll find more details in AWS Networking and Azure Networking webinars).

Miha Markočič created sample automation scripts (mostly Terraform configuration files + AWS CLI commands where needed) deploying these features described in AWS Networking webinar:

• IP multicast deployment (video)
• Web Application Firewall deployment (video)
• Network Load Balancer deployment (video)
• Inter-region VPC Peering deployment (video)

To recreate them, clone the GitHub repository and follow the instructions.

Anyone who spent some time reading cloud providers' documentation instead of watching slide decks or vendor keynotes knows that setting up infrastructure in a public cloud is not much simpler than doing it on-premises. You will outsource hardware management (installations, upgrades, replacements…) and might deal with an orchestration system provisioning services instead of configuring individual devices, but you still have to make the same decisions, and take the same set of responsibilities.

Obviously that doesn’t look good in a vendor slide deck, so don’t expect them to tell you the gory details (and when they start talking about the power of declarative API you know you have a winner)… but every now and then someone decides to point out the state of emperor’s clothes, this time Gerben Wierda in his The many lies about reducing complexity part 2: Cloud.

For public cloud networking details, check out our cloud webinars and online course.

In December 2020 Ed Horley invited me to a chat about IPv6 in the public cloud. While I usually don’t want to think about a protocol that’s old enough to buy its own beer in US, we nonetheless had interesting discussions (including the need for frequent RA messages in AWS VPC).

A while ago (eons before AWS introduced Gateway Load Balancer) I discussed the intricacies of AWS and Azure networking with a very smart engineer working for a security appliance vendor, and he said something along the lines of “it shows these things were designed by software developers – they have no idea how networks should work.”

In reality, at least some aspects of public cloud networking come closer to the original ideas of how IP and data-link layers should fit together than today’s flat earth theories, so he probably wanted to say “they make it so hard for me to insert my virtual appliance into their network.”

Got this question from one of the networking engineers “blessed” with rampant clueless-rush-to-the-cloud.

I plan to peer multiple VNet from different regions. The problem is that there is not any consistent deployment in regards to the private IP subnets used on each VNet to the point I found several of them using public IP blocks as private IP ranges. As far as I recall, in Azure we can’t re-ip the VNets as the resource will be deleted so I don’t see any other option than use NAT from offending VNet subnets to use my internal RFC1918 IPv4 range. Do you have a better idea?

The way I understand Azure, while you COULD have any address range configured as VNet CIDR block, you MUST have non-overlapping address ranges for VNet peering.

Jon Kadis spent most of his life working on enterprise networks, and sadly found out that even changing jobs and moving into a public cloud environment can’t save you from people trying to lift-and-shift enterprise IT kludges into a greenfield environment.

Here’s what he sent me:

A long while ago I wrote a blog post along the lines of “it’s ridiculous to allow developers to deploy directly to a public cloud while burdening them with all sorts of crazy barriers when deploying to an on-premises infrastructure,” effectively arguing for self-service approach to on-premises deployments.

Not surprisingly, the reality is grimmer than I expected (I’m appalled at how optimistic my predictions are even though I always come across as a die-hard grumpy pessimist), as explained in The Shared Irresponsibility Model in the Cloud by Dan Hubbard.

For more technical details, watch cloud-focused ipSpace.net webinars, in particular the Cloud Security one.

In mid-September Ethan Banks invited me to chat about multi-cloud networking in the Day Two Cloud podcast. It was just a few weeks after Corey Quinn published a fantastic Multi-Cloud is the Worst Practice rant, which perfectly matched my observations, so I came well prepared ;)

This blog post was initially sent to the subscribers of our SDN and Network Automation mailing list. Subscribe here.

Most automation projects are gradual improvements of existing manual processes, but every now and then the stars align and you get a perfect storm, like what Adrian Giacommetti encountered during one of his automation projects.

The customer had well-defined security policies implemented in Cisco ACI environment with tenants, endpoint groups, and contracts. They wanted to recreate those tenants in a public cloud, but it took way too long as the only migration tool they had was an engineer chasing GUI screens on both platforms.

In last week’s update session we covered the new features AWS introduced since the creation of AWS Networking webinar in 2019:

• AWS Local Zones, Wavelengths, and Outposts
• VPC Sharing
• Bring Your Own Addresses
• IP Multicast support
• Managed Prefix Lists in security groups and route tables
• VPC Traffic Mirroring
• Web Application Firewall
• AWS Shield
• VPC Ingress Routing
• Inter-region VPC peering with Transit Gateways

The videos are already online; you need Standard or Expert ipSpace.net subscription to watch them.

One of my readers sent me this question (probably after stumbling upon a remark I made in the AWS Networking webinar):

You had mentioned that AWS is probably not using EVPN for their overlay control-plane because it doesn’t work for their scale. Can you elaborate please? I’m going through an EVPN PoC and curious to learn more.

It’s safe to assume AWS uses some sort of overlay virtual networking (like every other sane large-scale cloud provider). We don’t know any details; AWS never felt the need to use conferences as recruitment drives, and what little they told us at re:Invent described the system mostly from the customer perspective.

When planning to move your workloads to a public cloud you might want to consider the minor detail of public IPv4 connectivity (I know of at least one public cloud venture that couldn’t get their business off the ground because they couldn’t get enough public IPv4 addresses).

Here’s a question along these lines that one of the attendees of our public cloud networking course sent me: