When you create a VNet in Azure or a VPC in AWS you have to allocate a CIDR range from which you subnets will be allocated. There are some nuances between the different service providers as you try to expand your networks which can lead to some challenges. Knowing the different rules from the start can help you plan your CIDR ranges appropriately. We'll start with what's the same across AWS and Azure and then look at the differences.
I will always be a network engineer and that means that 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 am 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 doing 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 were a bit confusing in the practice exams he has been taking. 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 do something to try to explain what the options are any 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.
One of the sneaky under the radar features that could to be a game changer in the near future is Azure Subnet Peering. This is a feature that is already there in the API but not really documented or productised.
I was chatting with a friend who is doing his AZ-700 and he had found this rather neat way of finding your IP 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 which 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.