When you create a VNet in Azure or a VPC in AWS, you need to allocate a CIDR range for your subnets. There are key differences between these cloud providers when expanding networks, which can create challenges. Knowing these rules from the start helps you plan your CIDR ranges better. I'll start with what's similar across AWS and Azure, then look at the differences.
I will always be a network engineer, and that means some words have very specific meanings that have taken root in my soul. The terminology within ExpressRoute has bothered me for ages, and when speaking to a few people, I found that I'm not the only one who finds it unintuitive. To me, a circuit is a single link, but to Microsoft, a circuit is the pair of links and the associated peerings! Two thumbs up to that, Microsoft, or rather in your own language 'one ExpressRoute thumb'.
Anyone who has accidentally advertised too many prefixes and watched their ISP BGP peerings collapse (I'm looking at you, BT) knows that prefix limits are a common safeguard in networking. While exploring anycast configurations in Azure, I carefully noted the official Route Server prefix limit of 1,000 routes. However, I recently discovered something far more interesting in the fine print about how Azure actually calculates this limit.
A good friend of mine is taking his AZ-700 next week and asked me a few questions about Azure Traffic Manager, Azure Front Door and the WAF capabilities in Azure. Some of the questions in his practice exams were a bit confusing. As he's not only a good friend but also the kind chap who proof reads a lot of these blog posts, I thought I'd try to explain what the options are and when you'd use them. On a side note, if you fancy talking to a top tier network guy and all-round nice fella, I thoroughly recommend you look up Zain Khan.
I've recently been exploring one of the sneaky under-the-radar features that could be a game changer in the near future: Azure Subnet Peering. This is a feature that's already there in the API but not really documented or productised yet.
I was chatting with a friend who's studying for his AZ-700 exam, and he showed me this rather neat way of finding your IP address using Google DNS.
The reason I fell down the rabbit hole with regard to finding my public IP was because of a section in an old Azure networking book my friend was reading. It said:
To allow Azure internal communication between resources in Virtual Networks and Azure services, Azure assigns public IP addresses to VMs, which identifies them internally. Let's call these public IP addresses AzPIP (this is an unofficial abbreviation). You can check the Azure internal Public IP address bound to the VM with the command dig TXT short o-o.myaddr.google.com.