I believe I’m not alone on this feeling: It seems like every time we use the Azure Portal some new feature appear. The features reproduce themselves faster than rabbits. Did you had this feeling before? Share your thoughts in the comments.
This week, working with Azure, I found some new small features around and decided to share them with you. When does these features appeared? Where did they come from? No idea, but they are interesting. It’s even possible they were there for some time and I never reached them. Anyway, Tighten your seat belt and prepare for a ride.
Deletion features on virtual machines
When we provision a virtual machine, many additional objects are provisioned together it: Disk (or disks), Network Interface and Public IP, for example.
This usually creates problems when deleting a VM. If you have multiple VMs in the same resource group, you need to locate each object related to the VM and delete them.
Some features, such as Availability Sets and Site Recovery, requires us to provision multiple VMs in the same resource group. This requirement and the deletion problem annoys me a lot. Provisioning on this way creates problems when deleting the VM. It becomes difficult to select the correct objects. Sometimes Azure also has problems identifying the correct deletion order, according the objects dependencies.
The new feature: We have two deletion checkboxes included during the provision of a virtual machine. The first one, to delete the disks together the virtual machine itself, the other to delete the network interface together the virtual machine itself.
The deletion process, by the way, deserves a special mention: I spent an entire week working with Azure without getting a single deletion error – when azure mistakes the order to delete dependent objects. This is great!
Global load balancer
The Load Balancer, a layer 3 load balancer in Azure, got a new option for us to select: Regional or Global.
Regional load balancer is the load balancer we are familiar with, no difference. Global load balancer is a load balancer which only accepts other load balancers on the backend pool. Yes: A load balancer of load balancers.
It can load balance across different regions. This means we can create two set of VMs, each one on a different region and using a regional load balancer for them, then create a Global Load balancer to balance the load between them.
This feature can twist the reality but doesn’t change it: There are two local load balancers in Azure and two Global load balancers in Azure. Load Balancer and Application Gateway are local load balancers while Traffic Manager and Front Door are global load balancers.
A local load balancer requires the connection from the end user to reach it, on the region it’s deployed. A global load balancer, on the other end, intercepts the request anywhere in the world, on the border of the Azure network, and process the request, without being tied with a region.
One side note about this change is the mix of names: Now, “Global” for load balancers have two different meanings depending on the context.
Internal Load Balancer
The type selection for Public or Internal load balancer also seems new. The load balancer was public by default. The new internal load balancer option changes the front-end IP configuration and only allow us to set an internal IP as the front-end IP.
An internal Load Balancer can be used by internal applications, put behind another load balancer or exposed to the internet using NAT.
Gateway Load Balancer
This is a new SKU for the load balancer. This feature is in preview, but I could only notice this when checking the documentation.
A Gateway load balancer works as a load balancer/gateway for NVA’s. It redirects traffic to NVA’s, allowing them to work as firewalls, analyse the network traffic and many additional tasks.
Public load balancers have the option to redirect their traffic to the NVA’s, using the Gateway Load Balancer. According to the documentation, we also should be able to configure network interfaces to redirect their traffic to the gateway load balancer. However, I couldn’t find this option on network interfaces in the portal. Maybe it’s because it’s still in preview.
The possibility to configure the gateway load balancer in network interfaces avoid the need of custom routing tables for a NVA. I would still question what would be best: using a custom routing table set on the subnet or configuring each network interface.
New advanced backup option
This is a very interesting and simple improvement. When configuring backup for a VM to recovery services vault, we were limited to once a day backup. Anything beyond that required a custom backup server.
I don’t know exactly why this option appear like it was a total different kind of backup. It seems to me the improvement from once a day to hourly backup is the main new feature here.
There is an additional difference: The amount of backups to be retained on the source machine. Originally it was 5, while with the new backup it’s up to 30. It makes sense: if you are making a daily backup, you don’t need to retain many of them. On the other hand, if you are making hourly backups, you may need to retain 1 day or more.
The images below show the difference between the retention on the old and new backup method.
The hourly backup feature, however, is only available under request to join the preview. On the other hand, the change on the retention days is available.
Choice of what will be encrypted in a storage account
The possibility to encrypt a storage account using a customer managed key is very interesting. It’s not a new feature at all.
The new feature is the possibility to select the services affected by the customer managed key: Blob Storage, File Storage, Tables or Queues.
It escapes to me why someone would like to apply the encryption key to only some services.
Link to set the permissions for a VPN Gateway
This is, probably, the most hidden of the new features. When we configure a point to site VPN to use Azure Authentication, we need to give permission to Azure VPN App to access our Azure Active Directory.
This requires us to follow a detailed documentation from Microsoft website to build a complex URL and call it on the browser.
The new feature: Now we have a link on the configuration page. Clicking on the link we trigger the same URL, setting the permission to Azure VPN.
One complex URL less to build while configure Azure Authentication for a VPN. A few helpers more on the text boxes and we will not need to open the documentation anymore to complete this configuration.
DSC on a Virtual Machine
The Desired State Configuration made from a Virtual Machine blade instead of an Automation Account is already in preview for some time. The first time I tested it, the results were not much integrated with the automation account.
The news is that now the synchronization between automation account and the DSC on the VM is way better. After applying the DSC on the automation account, I was able to see the same configuration on the DSC blade of the virtual machine.
The button Manage Multiple Machines on a single virtual machine takes us to the automation account used to complete the DSC configuration. The synchronization is way better.
References
Gateway Load Balancer
https://docs.microsoft.com/en-us/azure/load-balancer/gateway-overview
Configure Azure Authentication on a VPN Gateway
https://docs.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-tenant
Create an Internal Load Balancer
Load comments