Everything You Need to Know About Azure Infrastructure – June 2020 Edition

Aidan Finn

Jul 2, 2020

June 2020 marks the end of Vibranium and the start of Manganese, the codenames for the ending and starting half-year semesters in the Azure development year, and with that a whole new half-year of Azure goodies for us to look forward to. But before we get caught up in the future, we’d better consider the recent past. I’ve highlighted some of the stories that, at first glance, might not seem all that important but they will be!

Azure Firewall Improvements

Microsoft’s platform-based Firewall has been installed in every one of my deployments since January of 2019. Customers, in my experience, prefer a platform-based option where there are no appliance maintenance tasks and the thing auto-scales according to demand. Throw in the fact that it’s deployed and configured entirely as an ARM template and enterprises can start to move towards a DevSecOps (Wait! Was that a link to RedHat?!) model where the firewall is configured and change-controlled through Git, GitHub, DevOps, and so on.
There were two announcements in June. The first announcement, Azure Firewall forced tunneling and SQL FQDN filtering now generally available, revealed two features had just gone GA:

Forced-tunneling: The ability to force all Internet-bound traffic through an IP address such as an on-premises firewall or a network virtual appliance (NVA) for additional filtering/inspection. This would not be a common request, but I can imagine some security crazed environments requiring multiple tiers of inspection/filtering. For those of you considering this feature and placing the firewall into minimally sized virtual networks (hubs) then be aware that a second Azure Firewall subnet is required. There are complications with this, such as the firewall becoming the source IP address (SNAT) instead of the true source device, or traffic to cloud services going via on-premises – but there are documented workarounds that should be considered. Note that forced-tunneling should be the exception, not the rule!
SQL FDN Filtering: One of the features I really like in Azure Firewall is the ability to create outbound rules based on FQDN for HTTP/S services. Now you have the ability to create similar rules VNets accessing SQL (SQL Server, Azure SQL, Azure SQL Data Warehouse, Azure SQL MI).
Public IP Address Limit: The maximum number if PIPs in a single firewall has increased from 100 to 250. That increases the number of inbound DNAT rules you can create, but more importantly, increases the outbound connections (outbound SNAT port exhaustion) through the hidden Azure load balancer (which also affects highly available firewall appliances). Tip – deploy the addresses using Public IP Prefix for a sequential block of addresses.

But Azure Firewall has not stopped there – New Azure Firewall features in Q2 CY2020:

Custom DNS (Preview): You can configure Azure Firewall to use your own DNS, even Azure Private DNS if it is connected to the virtual network.
DNS Proxy (Preview): This feature prevents DNS resolution mismatch when Custom DNS is used and enables FQDN filtering in network rules.
FQDN filtering in Network Rules (Preview): You can filter outbound traffic based on FQDNs for any TCP/UDP based protocol. It is recommended that you use DNS Proxy to ensure that the client and the firewall are resolving names to the same IP address (do an NSLOOKUP for azure.com).
IP Groups (GA): I’ve been waiting for this feature. You can document one or more commonly used IP addresses as a reusable resource; you can use this resource as a source or destination in Azure Firewall rules. It was stated at Ignite 2019 that the hope was to add support for IP Groups in Network Security Groups.

But that is not all that the Azure Firewall product group has been up to – watch this space!

Who Needs More Virtual Machine SKUs?

Are we getting to the point where Azure virtual machines should be branded like Apple iPads once were – let’s just call it the D-Series and leave it at that. But no; we need a _v4 with more variants: New general purpose and memory-optimized Azure Virtual Machines with Intel now available.
Azure added:

D_v4
Ds_v4
E_v4
Es_v4
Dd_v4
Dds_v4
Ed_v4
Eds_v4

Let’s boil all that down:

_v4: Indicates that this is the fourth version or generation of a virtual machine on a new hardware host. This time the host has 2nd generation Intel Xeon Platinum 8272CL (Cascade Lake) processor with Intel® Deep Learning Boost Technology, Intel® Advanced Vector Extensions 512 (Intel® AVX-512), Intel® Turbo Boost Technology 2.0, and Intel® Hyper-Threading Technology. We are told to expect approximately 20% improved CPU performance over the _v3 machines.
D-Series: This is one of the oldest families of general-purpose virtual machines in Azure, offering full processor performance and offering good disk performance for database (and RDS/WVD/other) services.
E-Series: I think of E as in “D-Series with extra RAM”. The workloads are similar but you just need more RAM per virtual processor.
The s specialization: This means that the virtual machine can handle Premium SSD and Ultra SSD in this case, as well as Standard HDD/SSD. Why anyone would limit themselves with a non-s variant, I have no idea. Other newer series have sensibly dispensed with the non-s variants.
The d specialization: They include larger (50%), faster SSD storage in the host for temporary storage, for example, disk-based caching.

In my experience, the Bs-Series and the Ds-Series have been, and continue to be, the most commonly used SKUs in Azure.

Other Announcements from Microsoft

Here are other Azure IaaS headlines from the past month:

And Now for Something Different

This time, it’s still Azure-related, but it’s from a source that most techies will normally ignore. The Microsoft Cloud Adoption Framework (CAF) is a set of guides to steer an organization through its adoption of Microsoft Azure. It’s a lot of heavy reading. Historically, it’s been a set of questions with a bunch of possible answers that needed interpretation, understanding, and decision-making.
Last month, a new section was added to CAF to document an “enterprise-scale landing zone architecture”. This is a “virtual data center” implementation:

Deployed using infrastructure-as-code (ARM templates in GitHub)
Governance and security are deployed first
Each stamp is deployed using Azure Policy by dropping a new subscription into a management group
Networking is deployed for secure delivery of services and storage of data (IaaS and PaaS)

This is an area I know well because I built such a “product” with my colleagues 18 months ago and have been delivering it to customers for over a year. I knew it was coming and was surprised to see the quiet launch – a page appeared, and a few Microsoft staff members tweeted about it. I guess the big launch will come at the virtual Inspire conference in July (a partner/business-focused event).
You can poke around and learn more about how the architecture is built and deployed. The main GitHub repo is https://github.com/Azure/Enterprise-Scale/. At the heart of the network, you will find the Secure Virtual Hub, a merger of Azure Virtual WAN, Azure Firewall, and Azure Firewall Manager for site-to-site networking, point-to-site networking, SD-WAN, region-to-region, networking, and spoke-to-spoke connectivity. While the tech is very interesting, I have to question the scalability of some design elements and the design choice to use tens of thousands of lines of code in a single JSON template – contrary to the modular approach that many now prefer. I would have tested it out, but deployments failed in my tenant because there appear to be dependencies on Microsoft-internals or private preview features (I got access denied errors even though I’m a global admin with elevated rights for management groups). I guess we’ll see how this product develops now that the public can contribute via GitHub.