It’s time for the Azure Spring Clean. The annual event is organised by Joe Carlyle and Thomas Thornton to encourage you to look at your Azure subscriptions and see how you could manage it better. In my contribution for this year, we will look at how you can leverage Azure Copilot to manage your Azure Tenants better. What Is Azure Copilot Azure Copilot is Microsoft’s AI assistant, but it is tuned to work with Azure.

Deployment scripts are a feature of Bicep (and ARM templates) that allow you run either Azure PowerShell or Azure CLI scripts as part of your infrastructure as code deployment. This provides a means to do things in your deployment that Bicep can’t do natively. You’ll often hear this referred to as an “escape hatch”. If you can write it in Azure PowerShell or CLI (or any other PowerShell module if you download it), then you can do it in your deployment script.

As of the 29th of February 2024, classic application insights will be deprecated. This means you need to switch any classic instances over to Workspace-based instances, which will use a Log Analytics workspace to store the data rather than within App Insights itself. If you use Application Insights, check which mode your workspaces are using. There is a migration process to switch your workspace over, and it is pretty straightforward:

Versioning of runtime and packages in Azure Automation has been a pain for a long time. All of your scripts in the same automation account will use the same version of PowerShell and have access to the same versions of any packages you install. If you update some package versions for one script, you risk breaking things for other scripts. If you want to use specific packages that can’t be used alongside other packages (such as AzureRM vs Az modules), then you can’t be sure you aren’t breaking other scripts that might rely on the other packages.

Azure Copilot is here, a new AI assistant for Azure that can help you with your Azure resources, but what can it do, and is it any good?

Azure Verified Modules are a new initiative to create a library of verified, well-designed and supported infrastructure as code modules for Azure. Let’s take a look at what they are and why you might want to use them.

This week, I encountered an annoying issue when deleting some resources, specifically Azure Backup Vaults (and recovery service vaults). I was deleting a resource group that contained several resources, including a backup vault. The delete started fine, and all the other resources got deleted, but the vault and the resource group did nothing for a long time before the deletion timed out with no further information. The issue is that when you attempt to delete a resource group, it attempts to delete all the resources inside it, including the backup vault.

AI is everywhere at the minute, and everyone is trying to develop a way to implement AI in their products or workflows. Azure’s open AI services are a great way to do this, but because they’re so easy to deploy and use, you can end up with a proliferation of AI services. The default security settings for these resources are often set up for convenience and ease of use, rather than locking down your precious data and IP.

This week, I was working with Azure functions and had a very frustrating issue that I spent multiple days trying to get to the bottom of. This ended up being a reasonably straightforward issue with name collisions. Still, it wasn’t obvious and took a lot of digging to get to the bottom of, so I wanted to provide some details here in case anyone else hits the same problem. The Problem I was working with an Azure function that had been running for some time, but I needed to make some changes to the code.

A couple of weeks ago we talked about how Microsoft is deprecating default internet access for VMs](https://samcogan.com/retiring-default-internet-access-for-vms/) in September 2025. This change is being done because it doesn’t meet Microsoft’s “secure by design” approach. However, you don’t need to wait till 2025 if you want to get ahead of the game and secure your outbound traffic due to the introduction of private subnets. By declaring your subnet as private you disable default outbound access and out of the box any VMs in that subnet will not have access to the internet.