Azure World Newsletter – Issue 5.01

January 17, 2024

Welcome to the first edition of the Azure World Newsletter in 2024.

I hope you had a wonderful, restful holiday season. It was nice to take a break from writing the newsletter, but rest time is over, and it’s time to get back to work. 🙂

Let’s see what has been happening with Azure since we last looked.

The unsubscribe link is at the bottom if you want to stop receiving these emails.

ONE.

One of the benefits of running your computing jobs in the cloud is that there are many other useful services that tie into compute services that make the job of an administrator a lot easier.

One of these easier administration tasks is backup and recovery. As easily as you can set up a new Virtual Machine or App Service, you can configure a backup job for that service. And you can also easily restore to an old backup without much difficulty.

So, in late November, Azure announced that Azure Backup service now supports AKS.

Now, of course, AKS nodes are created using images, and it’s always been easy to deploy a new node based on that image or destroy that node when the node is no longer required. So, the need for scaling has required that all storage be external to the app, and the app itself be easily replicatable.

But Azure Backup for AKS apps can be quite complex, with many nodes and pods, and many apps running in an interconnected fashion. Some AKS apps have databases running inside the container. So, being able to back up the entire app is more than just being able to replicate a single image.

Azure Backup now supports AKS, making it easier to have automated backups and simple restores for the entire AKS cluster, including monitoring, from a single location in the portal.

TWO.

The way virtual machines access the public Internet is changing in the next two years, and you need to know about it if you work with VMs and subnets.

Right now, when you create a virtual network with one or more subnets, outbound access to the Internet is determined mainly by a network security group policy. Of course, you could also install a firewall on that subnet and use a routing table to force traffic through that firewall for finer-grained control of network traffic.

The current “default” access control for a subnet is to enable outbound access to the internet. So, any devices installed on that subnet – even those without their own public IP address – have full access to the Internet unless you take active steps to block that access. These devices also access the internet using one of Azure’s public IP addresses, which can change and are not controlled by the customer.

Microsoft has deprecated this type of setup, and default outbound access for virtual machines will be retired in September 2025.

Additionally, Microsoft has announced a new private subnet feature if you want to accelerate your move to this new world of explicit outbound Internet access.

The new private subnet feature currently in public preview has more of a “secure by default” mindset. This subnet type has outbound access blocked by default, and you will need to set up a method to get devices access to the Internet more explicitly.

More details of the deprecation of outbound access can be found here:
https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/

And more information on the private subnets can be found here:
https://azure.microsoft.com/en-us/updates/public-preview-private-subnet/