Azure

Dynamic Sessions for Azure Container Apps provides a way to run untrusted code in a secure, sandboxed environment with dynamic scaling.

Planned failover for Azure Storage is now in preview, but what is it and how does it differ from unplanned failover?

AKS now supports applying FQDN based network polcies to restrict traffic, however it’s part of the Advanced Container Networking Services product, which comes at an additional cost.

Allow rules in Azure WAF’s might not operate the way you think they do, and could mean you’re not processing all the rules you think you are.

Back at Build, Microsoft announced a new feature for running Kubernetes in Azure: AKS Automatic. This feature aims to simplify and make using Kubernetes in Azure less overwhelming. Let’s look at this service and see how it works and whether it will be useful for you. What is AKS Automatic AKS Automatic is an extension to the existing AKS service. When you deploy an AKS cluster, you get a control plane instance and then several worker nodes to run your pods.

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.