If you’re running VMs in Azure, you will usually need to either RDP or SSH to the VM to resolve issues, install software or perform other administrative tasks. You can do this by opening the inbound port on your NSG and connecting directly to your VM. This will work, but leaving that port open invites brute-force attacks to compromise your VMs. Cloud services are an easy target for attackers looking for open ports, and it’s not uncommon to see attempts at brute force attacks within hours of a VM being deployed with an open port.
Most VM-based workloads in Azure are either running 24/7 or are scaled up and down dynamically as load changes. However, there are a class of workloads that fall in between these two scenarios, where you are running machines for reasonable periods, but there are periods where they are not in use and you would like to be able to turn them off during that period, but retaining state is a problem.
Ever since the release of ARM, and now Bicep, there has been a glaring omission from what we can create with this infrastructure as code languages - Entra ID (formally Azure AD) resources. There was an obvious reason for this, as Entra ID resources are created using the Graph API, which is a completely separate API from ARM. This has meant that we’ve had to resort to other methods for creating Entra ID resources as part of our deployments, things like deployment scripts or separate tasks in a pipeline.
When creating Infrastructure as Code, most IaC languages create dependencies between resources so that resources are created in the correct order, and we wait for a resource to complete creation before we start creating a resource that depends on it. A lot of the time this is handled automatically, but you can also add explicit dependencies as well. However, sometimes these dependencies don’t do the job.
Sometimes a resource will be complete, at least as far as the IaC is concerned, but it’s not actually ready in the cloud provider.
This week Microsoft announced the GA of the new “v2” SKUs for Azure API Manager, these offer updated versions of the basic and standard SKUs, with some new features. Let’s look at the difference between the v1 and v2 SKUs, and whether you would want to use them.
Improvements in the v2 SKU The v2 SKUs are mainly intended to improve on the v1 SKU and to bring in some features that previously had only been present in the Premium tier, which locked them behind an expensive monthly cost.
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.
