Day 527. The only documentation you can find about supported log categories for the #Azure Application Gateway uses log table names which are for some reason different than the actual log category names. How do you find the names of these log categories to enable them using Terraform when there is no documentation? Easy, just look into the API requests the Azure Portal is doing when you enable them through the GUI.

Day 526. Following up on the shit from day 514 where the #Azure #Terraform provider tries to read registered Azure providers even though you tell it not to. #Microsoft's response: This is expected behavior and how about you disable enhanced provider validation for ALL of your Terraform providers by setting an environment variable?

Day 525. With 91 characters, the error "ThirdPartyPrivateLinkServiceProvidedDuringPrivateEndpointCreationDoesNotExistOrIsNotVisible" takes the record for the longest #Azure error name we have seen so far.

Day 524. Deleting this #Azure VM disk just failed with HTTP error code "undefined".

Day 523. Seemingly not even Storage accounts are exempt from the ongoing capacity shortages in many #Azure regions.

Day 522. The #Azure Portal reminds us to regularly rotate our App Configuration access keys. That's pretty funny since #Microsoft had not rotated their MSA identity keys in years which allowed attackers to use a signing key from 2016 (!) to issue forged identity tokens and to breach the email accounts of basically all Microsoft clients in the Exchange Online hack in 2023.

Day 521. When deploying an #Azure Database for MySQL flexible server with vnet integration, Azure validates whether the specified Private DNS zone for the database is actually linked to your database's vnet. This DNS zone link is completely pointless when configuring a custom DNS server located in a different vnet which could not resolve this linked Private DNS zone anyways.

Day 520. After years of daily gambling whether we can deploy our resources to #Azure West Europe and North Europe regions, capacity shortages have apparently spread to Azure France Central.

Day 519. When your #Azure Application Gateway can't connect to backends because it can't resolve their hostnames, the health probes have no idea what's wrong and only tell you that they can't reach the backend. But don't worry, Dr. Azure Advisor is here to help you. It somehow knows exactly what's wrong and tells you that your App Gateway can't resolve some service hostnames. Then why can't the probes tell us that?

Day 518. When you want to resolve the shit from day 517 and restart your #Azure Application Gateway, there is no way to do it through the Azure Portal. You have to do it via API or CLI (or PowerShell, but seriously, who voluntarily uses PowerShell?)

Restarting it took around 6 minutes for us, btw.

Day 517. When changing the DNS server of your #Azure vnet, you will need to restart your Application Gateway for it to adopt the new DNS server which will result in service downtime. This is the same behavior as we have seen for VMs (see day 508), but at least you can do rolling upgrades with VMs. How many productive Application Gateways do you have?

Day 516. The shit from day 515 completely breaks #Azure's own Private Link DNS resolution concept for hub and spoke topologies, where they tell you to link Private Link DNS zones to your central vnet which hosts your central DNS server (such as Private DNS resolver or Azure Firewall).

Day 515. An #Azure Application Gateway will always use the Azure default DNS server for resolution of so-called management FQDNs (for example domains ending in "windows.net" or "azure.net"). That also includes most Private Link domains. Because of that, regardless of your central DNS resolution setup, you will need to link all Private Link DNS zones to your gateway's vnet for it to be able to resolve Private Endpoint hostnames.

Day 514. When your #Azure principal you use for #Terraform does not have enough permission to register providers for the subscription, the docs tell you to set the resource provider registration flag to "none". However, Terraform will still look up registered providers and fail if your principal doesn't have permissions to do that.

Day 513. There are somehow two "Subscriptions" tiles in the #Azure Portal search bar.

Day 512. While the shit from day 511 somewhat makes sense (traffic from the #Azure VPN Gateway is forwarded traffic after all), the description in the Azure Portal is highly misleading and there is no documentation available for this behavior.
This will blow up in your face if you always only had Gateway Transit enabled on peerings and you decide to disable Gateway Transit. Now you're stuck troubleshooting why your indirectly peered VMs can no longer talk to each other.

Day 511. Even though the #Azure Portal says otherwise, when enabling Gateway Transit on a vnet peering, this implicitly also allows forwarded traffic from other indirectly peered vnets when routed through a central NVA such as Azure Firewall (which is completely indepent from the VPN Gateway). However, the peering itself will still tell you that forwarded traffic is disabled - which is wrong.

Day 510. To work around the shit from day 509 and to allow your P2S #Azure VPN Gateway clients to access machines in peered spokes, you need to enable Gateway Transit in the vnet peerings to allow response traffic to bypass any central NVA. This makes the networking architecture more complicated and means you cannot restrict P2S VPN traffic using an Azure Firewall.

Day 509. While the site-to-site VPN of the #Azure VPN Gateway supports user-defined routes, point-to-site (P2S) VPN does not. Which means there is no way to route traffic coming from VPN clients through a central NVA. Using P2S VPN makes the whole hub and spoke reference network topology provided by #Microsoft fall apart.

Day 508. We thought we already posted this since we have run into this so often already, but apparently we didn't. So here you go: When updating the custom DNS server configuration of your vnet, you will need to restart every single #Azure VM for them to adopt the new DNS configuration. They will never adopt the new DNS settings on their own.