Microsoft’s Sovereign Cloud Strategy: is it really “Disconnected”?

Image Credit: Microsoft

Microsoft have just announced the General Availability of Disconnected Operations for Azure Local, M365 Local and Foundry Local.

Reading between the lines of the announcement seems to be aimed less at about “offline cloud” and more about Microsoft defining a clearer Sovereign Cloud architecture. While the headline is Azure Local disconnected operations + Microsoft 365 Local + Foundry Local, the bigger story is this:

Microsoft is trying to give customers a sovereign stack that spans infrastructure, productivity, and AI — and lets them choose where on the connectivity spectrum each workload sits.

Lets dig a bit deeper into this.

This is a Sovereign Private Cloud story

The Microsoft Learn page for Sovereign Private Cloud also makes the architecture intent more explicit, and positions that front and center as supporting locally hosted, hybrid, and fully disconnected environments. :

  • Azure Local for infrastructure
  • Microsoft 365 Local for productivity
  • Unified control and lifecycle management
  • Workload mobility between Azure and on-premises
  • Support for hybrid and disconnected deployment models

Announcing Azure Local, M365 Local, and Foundry Local together isn’t just about a bundling of product releases, it’s a shift to a full-stack sovereign operating model:

  • Infrastructure stays local,
  • Productivity stays local,
  • AI inferencing can stay local,
  • Control Plane can be cloud-hosted or on-premises depending on mode.

Azure Local is the foundation — but M365 Local and Foundry Local are the interesting parts

Most people immediately focus on Azure Local (understandably). We now get a local control plane (which is managed by the management appliance) that provides a Azure portal and ARM experience similar to the Azure Portal.

Flipping to disconnected mode means you do lose Azure Virtual Desktop (understandably), but still get options such as VMs, Kubernetes, Container Registry, Key Vault and Azure Policy.

Image Credit: Microsoft/Douglas Phillips

But the more important signal is that Microsoft is extending the same sovereign/disconnected pattern up the stack:

  • Microsoft 365 Local = productivity continuity inside the sovereign boundary
  • Foundry Local = AI inferencing/model capability inside the sovereign boundary

That matters because “sovereign” projects usually fail at one of these layers:

  • Infra is fine, but productivity still leaks to cloud services
  • Infra and productivity are local, but AI requires cloud inference
  • Everything is local, but operations become unmanageable

Microsoft is clearly trying to close those gaps. But are they?

Microsoft 365 Local: what it is, and what cloud use cases it’s trying to replace

What Microsoft 365 Local actually is

Image Credit: Microsoft

The Microsoft Learn page is direct in the positioning of M365 Local:

Microsoft 365 Local runs Exchange Server, SharePoint Server, and Skype for Business Server on customer-owned Azure Local infrastructure with Azure-consistent management, and it supports hybrid and fully disconnected deployments.

It also emphasizes:

  • customer-owned and customer-managed environment
  • data residency / access / compliance control
  • validated reference architecture and hardened baseline
  • certified hardware / partner-led deployment paths

What cloud use cases it’s potentially replacing

Microsoft 365 Local is not a like-for-like replacement for the entire modern Microsoft 365 cloud suite. The cloud use cases it appears to target (email, document collaboration, unified comms) are the ones where organizations would otherwise be pushed toward:

  • Exchange Online (email/calendar)
  • SharePoint Online (document collaboration/intranet)
  • Teams Online (cloud-first collaboration and video/audio conferencing)

Microsoft 365 Local does this using their stack of traditional on-premises server products:

  • Exchange Server
  • SharePoint Server
  • Skype of Business Server

Foundry Local: what it is, and what cloud AI use cases it’s trying to replace

In the sovereign announcement, Microsoft says Foundry Local now supports bringing large multimodal models into fully disconnected sovereign environments, using partner infrastructure (for example NVIDIA-based platforms) so customers can run local AI inferencing within their own boundaries.

What cloud use cases Foundry Local is trying to replace

Microsoft Foundry (cloud) is positioned as the place to design and operate AI apps/agents at scale, with:

  • a large model catalog
  • managed compute deployments
  • serverless API deployments
  • prompt flow orchestration
  • Azure-hosted endpoints/APIs

That means Foundry Local is potentially replacing cloud-hosted AI patterns like:

  • Serverless model APIs hosted by Microsoft
  • Managed compute model hosting in Azure
  • cloud-based prompt/app development pipelines for the inference/runtime side when data cannot leave the operational boundary

Foundry Local is effectively Microsoft’s answer for customers who need:

“Foundry-style AI capabilities, but the model runtime and data path must stay on-prem / inside the sovereign boundary.”

That’s a big gap in the market, and Microsoft is trying to close it.

What this stack is replacing, architecturally

If you zoom out, the trio maps cleanly to three cloud categories:

1) Azure Local disconnected

Potentially replacing: cloud-managed hybrid infrastructure patterns where WAN dependency is still too high
With: local control plane + Azure-consistent management for infra and some Arc-enabled services.

2) Microsoft 365 Local

Potentially replacing: reliance on Microsoft 365 SaaS for core productivity in environments that can’t support that connectivity/risk model
With: on-prem productivity server workloads on Azure Local under customer control.

3) Foundry Local

Potentially replacing: Azure-hosted model inference/serverless AI endpoints for sensitive AI use cases
With: local inferencing and APIs inside the same sovereign boundary.

That’s why this announcement matters: it’s not just infra resilience. It’s a stack-level sovereignty story.

The hard question: what if you need truly fully disconnected?

Microsoft’s wording now includes “fully disconnected” for Sovereign Private Cloud, and the Azure Local disconnected docs are a genuine step forward. But many organizations still need to define “fully disconnected” much more strictly than a marketing phrase ever can.

In practice, “fully disconnected” usually means:

  • no internet path
  • no cloud control plane dependency
  • no cloud identity dependency
  • no cloud telemetry path
  • updates and artifacts moved through approved transfer processes

If that’s your requirement, you need to compare options honestly and look at some alternatives that already fit that narrative.

Fully disconnected alternative 1: Azure Stack Hub

If you want the most explicit Microsoft-native air-gapped model, Azure Stack Hub is still the reference point.

Diagram showing Azure Stack Hub job roles
Image Credit: Microsoft

Microsoft’s Azure Stack Hub docs are very clear:

  • you can deploy and use it without internet connectivity
  • disconnected mode requires AD FS
  • multitenancy is not supported in disconnected mode because it would require Microsoft Entra ID
  • Microsoft describes this as a scenario for use in “factory floors, cruise ships, and mine shafts”

If you were to look at this really closely, that is about as explicit as Microsoft gets to stating that something is “fully disconnected”.

Why it’s still relevant

Azure Stack Hub is often the better fit when the requirement is:

  • pure private cloud
  • internal-only identity
  • no usage data sent to Azure
  • no hybrid dependency as a baseline design

The trade-off

Microsoft also documents the operational compromises in disconnected mode:

  • impaired marketplace flow (manual syndication)
  • no telemetry
  • some extension/tooling limitations
  • constraints around service principals/identity workflows, etc.

That’s the normal cost of real isolation.

Fully disconnected alternative 2: Red Hat OpenShift

If the center of gravity is containers/Kubernetes, OpenShift is one of the strongest mature options for disconnected environments.

Image Credit: Red Hat

Red Hat’s docs are excellent here because they define terms clearly:

  • Disconnected environment = no full internet access
  • Air-gapped network = completely isolated external network
  • Restricted network = limited connectivity (proxies/firewalls, etc.)

That taxonomy is exactly what more cloud vendors should be using.

Red Hat also documents:

  • extra setup is required because OpenShift automates many internet-dependent functions by default
  • preferred disconnected practices (image mirroring, local update service, etc.)
  • a wide range of disconnected install patterns, including on-prem and vSphere-based deployments

What OpenShift is replacing

OpenShift disconnected is often replacing:

  • managed Kubernetes services in public cloud
  • cloud-native CI/CD and image delivery assumptions
  • internet-dependent operator/update workflows

It’s a great fit if your target state is platform engineering and Kubernetes-first operations — but it absolutely requires discipline around mirroring, registries, and update lifecycle.

So where do M365 Local and Foundry Local fit versus these alternatives?

This is the key architecture question that can be answered in a number of ways.

If you want a Microsoft-centric sovereign stack (infra + productivity + AI)

Azure Local + M365 Local + Foundry Local is very compelling, because Microsoft is finally addressing all three layers together:

  • infra continuity
  • productivity continuity
  • AI continuity
    inside one sovereign/private-cloud framing.

That’s the strongest part of the announcement.

If you need “hard air gap” with minimal cloud relationship

Azure Stack Hub is still the clearer Microsoft answer, because the disconnected mode assumptions are explicitly documented (AD FS, no multitenancy, no Azure dependency during operation).

If you need broad private-cloud or Kubernetes-first flexibility

Red Hat OpenShift is a serious alternative, especially when:

  • you already run those stacks
  • your ops teams are built around them
  • your security model is based on internal depots, mirrors, and transfer controls rather than cloud-integrated management

Conclusion

Microsoft is not just shipping “offline features.”, they’re building a Sovereign Private Cloud narrative where:

  • Azure Local covers infrastructure,
  • Microsoft 365 Local covers productivity,
  • Foundry Local covers AI,
  • and customers can choose connected, hybrid, or fully disconnected modes based on mission and risk.

But “fully disconnected” still needs precise architecture definitions in every real project. Because in practice, the right question is never:

“Can this run disconnected?”

It’s:

“Which layer is disconnected, which layer isn’t, and who owns the operational overhead?”

Hope you found this post useful – see you next time

AKS Networking – Which model should you choose?

In the previous post, we broke down AKS Architecture Fundamentals — control plane vs data plane, node pools, availability zones, and early production guardrails.

Now we move into one of the most consequential design areas in any AKS deployment:

Networking.

If node pools define where workloads run, networking defines how they communicate — internally, externally, and across environments.

Unlike VM sizes or replica counts, networking decisions are difficult to change later. They shape IP planning, security boundaries, hybrid connectivity, and how your platform evolves over time.

This post takes a look at AKS networking by exploring:

  • The modern networking options available in AKS
  • Trade-offs between Azure CNI Overlay and Azure CNI Node Subnet
  • How networking decisions influence node pool sizing and scaling
  • How the control plane communicates with the data plane

Why Networking in AKS Is Different

With traditional Iaas and PaaS services in Azure, networking is straightforward: a VM or resource gets an IP address in a subnet.

With Kubernetes, things become layered:

  • Nodes have IP addresses
  • Pods have IP addresses
  • Services abstract pod endpoints
  • Ingress controls external access

AKS integrates all of this into an Azure Virtual Network. That means Kubernetes networking decisions directly impact:

  • IP address planning
  • Subnet sizing
  • Security boundaries
  • Peering and hybrid connectivity

In production, networking is not just connectivity — it’s architecture.

The Modern AKS Networking Choices

Although there are some legacy models still available for use, if you try to deploy an AKS cluster in the Portal you will see that AKS offers two main networking approaches:

  • Azure CNI Node Subnet (flat network model)
  • Azure CNI Overlay (pod overlay networking)

As their names suggest, both use Azure CNI. The difference lies in how pod IP addresses are assigned and routed. Understanding this distinction is essential before you size node pools or define scaling limits.

Azure CNI Node Subnet

This is the traditional Azure CNI model.

Pods receive IP addresses directly from the Azure subnet. From the network’s perspective, pods appear as first-class citizens inside your VNet.

How It Works

Each node consumes IP addresses from the subnet. Each pod scheduled onto that node also consumes an IP from the same subnet. Pods are directly routable across VNets, peered networks, and hybrid connections.

This creates a flat, highly transparent network model.

Why teams choose it

This model aligns naturally with enterprise networking expectations. Security appliances, firewalls, and monitoring tools can see pod IPs directly. Routing is predictable, and hybrid connectivity is straightforward.

If your environment already relies on network inspection, segmentation, or private connectivity, this model integrates cleanly.

Pros

  • Native VNet integration
  • Simple routing and peering
  • Easier integration with existing network appliances
  • Straightforward hybrid connectivity scenarios
  • Cleaner alignment with enterprise security tooling

Cons

  • High IP consumption
  • Requires careful subnet sizing
  • Can exhaust address space quickly in large clusters

Trade-offs to consider

The trade-off is IP consumption. Every pod consumes a VNet IP. In large clusters, address space can be exhausted faster than expected. Subnet sizing must account for:

  • node count
  • maximum pods per node
  • autoscaling limits
  • upgrade surge capacity

This model rewards careful planning and penalises underestimation.

Impact on node pool sizing

With Node Subnet networking, node pool scaling directly consumes IP space.

If a user node pool scales out aggressively and each node supports 30 pods, IP usage grows rapidly. A cluster designed for 100 nodes may require thousands of available IP addresses.

System node pools remain smaller, but they still require headroom for upgrades and system pod scheduling.

Azure CNI Overlay

Azure CNI Overlay is designed to address IP exhaustion challenges while retaining Azure CNI integration.

Pods receive IP addresses from an internal Kubernetes-managed range, not directly from the Azure subnet. Only nodes consume Azure VNet IP addresses.

How It Works

Nodes are addressable within the VNet. Pods use an internal overlay CIDR range. Traffic is routed between nodes, with encapsulation handling pod communication.

From the VNet’s perspective, only nodes consume IP addresses.

Why teams choose it

Overlay networking dramatically reduces pressure on Azure subnet address space. This makes it especially attractive in environments where:

  • IP ranges are constrained
  • multiple clusters share network space
  • growth projections are uncertain

It allows clusters to scale without re-architecting network address ranges.

Pros

  • Significantly lower Azure IP consumption
  • Simpler subnet sizing
  • Useful in environments with constrained IP ranges

Cons

  • More complex routing
  • Less transparent network visibility
  • Additional configuration required for advanced scenarios
  • Not ideal for large-scale enterprise integration

Trade-offs to consider

Overlay networking introduces an additional routing layer. While largely transparent, it can add complexity when integrating with deep packet inspection, advanced network appliances, or highly customised routing scenarios.

For most modern workloads, however, this complexity is manageable and increasingly common.

Impact on node pool sizing

Because pods no longer consume VNet IP addresses, node pool scaling pressure shifts away from subnet size. This provides greater flexibility when designing large user node pools or burst scaling scenarios.

However, node count, autoscaler limits, and upgrade surge requirements still influence subnet sizing.

Choosing Between Overlay and Node Subnet

Here are the “TLDR” considerations when you need to make the choice of which networking model to use:

  • If deep network visibility, firewall inspection, and hybrid routing transparency are primary drivers, Node Subnet networking remains compelling.
  • If address space constraints, growth flexibility, and cluster density are primary concerns, Overlay networking provides significant advantages.
  • Most organisations adopting AKS at scale are moving toward overlay networking unless specific networking requirements dictate otherwise.

How Networking Impacts Node Pool Design

Let’s connect this back to the last post, where we said that Node pools are not just compute boundaries — they are networking consumption boundaries.

System Node Pools

System node pools:

  • Host core Kubernetes components
  • Require stability more than scale

From a networking perspective:

  • They should be small
  • They should be predictable in IP consumption
  • They must allow for upgrade surge capacity

If using Azure CNI, ensure sufficient IP headroom for control plane-driven scaling operations.

User Node Pools

User node pools are where networking pressure increases. Consider:

  • Maximum pods per node
  • Horizontal Pod Autoscaler behaviour
  • Node autoscaling limits

In Azure CNI Node Subnet environments, every one of those pods consumes an IP. If you design for 100 nodes with 30 pods each, that is 3,000 pod IPs — plus node IPs. Subnet planning must reflect worst-case scale, not average load.

In Azure CNI Overlay environments, the pressure shifts away from Azure subnets — but routing complexity increases.

Either way, node pool design and networking are a single architectural decision, not two separate ones.

Control Plane Networking and Security

One area that is often misunderstood is how the control plane communicates with the data plane, and how administrators securely interact with the cluster.

The Kubernetes API server is the central control surface. Every action — whether from kubectl, CI/CD pipelines, GitOps tooling, or the Azure Portal — ultimately flows through this endpoint.

In AKS, the control plane is managed by Azure and exposed through a secure endpoint. How that endpoint is exposed defines the cluster’s security posture.

Public Cluster Architecture

By default, AKS clusters expose a public API endpoint secured with authentication, TLS, and RBAC.

This does not mean the cluster is open to the internet. Access can be restricted using authorized IP ranges and Azure AD authentication.

Image: Microsoft/Houssem Dellai

Key characteristics:

  • API endpoint is internet-accessible but secured
  • Access can be restricted via authorized IP ranges
  • Nodes communicate outbound to the control plane
  • No inbound connectivity to nodes is required

This model is common in smaller environments or where operational simplicity is preferred.

Private Cluster Architecture

In a private AKS cluster, the API server is exposed via a private endpoint inside your VNet.

Image: Microsoft/Houssem Dellai

Administrative access requires private connectivity such as:

  • VPN
  • ExpressRoute
  • Azure Bastion or jump hosts

Key characteristics:

  • API server is not exposed to the public internet
  • Access is restricted to private networks
  • Reduced attack surface
  • Preferred for regulated or enterprise environments

Control Plane to Data Plane Communication

Regardless of public or private mode, communication between the control plane and the nodes follows the same secure pattern.

The kubelet running on each node establishes an outbound, mutually authenticated connection to the API server.

This design has important security implications:

  • Nodes do not require inbound internet exposure
  • Firewall rules can enforce outbound-only communication
  • Control plane connectivity remains encrypted and authenticated

This outbound-only model is a key reason AKS clusters can operate securely inside tightly controlled network environments.

Common Networking Pitfalls in AKS

Networking issues rarely appear during initial deployment. They surface later when scaling, integrating, or securing the platform. Typical pitfalls include:

  • subnets sized for today rather than future growth
  • no IP headroom for node surge during upgrades
  • lack of outbound traffic control
  • exposing the API server publicly without restrictions

Networking issues rarely appear on day one. They appear six months later — when scaling becomes necessary.

Aligning Networking with the Azure Well-Architected Framework

  • Operational Excellence improves when networking is designed for observability, integration, and predictable growth.
  • Reliability depends on zone-aware node pools, resilient ingress, and stable outbound connectivity.
  • Security is strengthened through private clusters, controlled egress, and network policy enforcement.
  • Cost Optimisation emerges from correct IP planning, right-sized ingress capacity, and avoiding rework caused by subnet exhaustion.

Making the right (or wrong) networking decisions in the design phase has an effect across each of these pillars.

What Comes Next

At this point in the series, we now understand:

  • Why Kubernetes exists
  • How AKS architecture is structured
  • How networking choices shape production readiness

In the next post, we’ll stay on the networking theme and take a look at Ingress and Egress traffic flows. See you then!

AKS Architecture Fundamentals

In the previous post From Containers to Kubernetes Architecture, we walked through the evolution from client/server to containers, and from Docker to Kubernetes. We looked at how orchestration became necessary once we stopped deploying single applications to single servers.

Now it’s time to move from history to design, and in this post we’re going to dive into the practical by focusing on:

How Azure Kubernetes Service (AKS) is actually structured — and what architectural decisions matter from day one.

Control Plane vs Data Plane – The First Architectural Boundary

In line with the core design of a vanilla Kubernetes cluster, every AKS cluster is split into two logical areas:

  • The control plane (managed by Azure)
  • The data plane (managed by you)
Image Credit – Microsoft

We looked at this in the last post, but lets remind ourselves of the components that make up each area.

The Control Plane (Azure Managed)

When you create an AKS cluster, you do not deploy your own API server or etcd database. Microsoft runs the Kubernetes control plane for you.

That includes:

  • The Kubernetes API server
  • etcd (the cluster state store)
  • The scheduler
  • The controller manager
  • Control plane patching and upgrades

This is not just convenience — it is risk reduction. Operating a highly available Kubernetes control plane is non‑trivial. It requires careful configuration, backup strategies, certificate management, and upgrade sequencing.

In AKS, that responsibility shifts to Azure. You interact with the cluster via the Kubernetes API (through kubectl, CI/CD pipelines, GitOps tools, or the Azure Portal), but you are not responsible for keeping the brain of the cluster alive.

That abstraction directly supports:

  • Operational Excellence
  • Reduced blast radius
  • Consistent lifecycle management

It also empowers Operations to enable Development teams to start their cycles earlier in the project as opposed to waiting for the control plane to be stood up and functionally ready.

The Data Plane (Customer Managed)

The data plane is where your workloads run. This consists of:

  • Virtual machine nodes
  • Node pools
  • Pods and workloads
  • Networking configuration

You choose:

  • VM SKU
  • Scaling behaviour
  • Availability zones
  • OS configuration (within supported boundaries)

This is intentional. Azure abstracts complexity where it makes sense, but retains control and flexibility where architecture matters.

Node Pools – Designing for Isolation and Scale

One of the most important AKS concepts is the node pool. A node pool is a group of VMs with the same configuration. At first glance, it may look like a scaling convenience feature. In production, it is an isolation and governance boundary.

There are 2 different types of node pool – System and User.

System Node Pool

Every AKS cluster requires at least one system node pool, which is a specialized group of nodes dedicated to hosting critical cluster components. While you can run application pods on them, their primary role is ensuring the stability of core services.

This pool runs:

  • Core Kubernetes components
  • Critical system pods

In production, this pool should be:

  • Small but resilient
  • Dedicated to system workloads
  • Not used for business application pods

In our first post, we took the default “Node Pool” option – however you do have the option to add a dedicated system node pool:

It is recommended that you create a dedicated system node pool to isolate critical system pods from your application pods to prevent misconfigured or rogue application pods from accidentally deleting system pods.

You don’t need the system node pool SKU size to be the same as your user node Pool SKU size – however its recommended that you make both highly available.

User Node Pools

User node pools are where your applications and workloads run. You can create multiple pools for different purposes within the same AKS cluster:

  • Compute‑intensive workloads
  • GPU workloads
  • Batch jobs
  • Isolated environments

Looking at the list, traditionally these workloads would have lived on their own dedicated hardware or processing areas. The advantage of AKS is that this enables:

  • Better scheduling control – the scheduler can control the assignment of resources to workloads in node pools.
  • Resource isolation – resources are isolated in their own node pools.
  • Cost optimisation – all of this runs on the same set of cluster VMs, so cost is predictive and stable.

In production, multiple node pools are not optional — they are architectural guardrails.

Regional Design and Availability Zones

Like all Azure resources, when you create an AKS cluster you choose a region. That decision impacts latency, compliance, resilience, and cost.

But production architecture requires a deeper question:

How does this cluster handle failure?

Azure supports availability zones in many regions. A production AKS cluster should at a bare minimum:

  • Use zone‑aware node pools
  • Distribute nodes across multiple availability zones

This ensures that a single data centre failure does not bring down your workloads. It’s important to understand that:

  • The control plane is managed by Azure for high availability
  • You are responsible for ensuring node pool zone distribution

Availability is shared responsibility.

Networking Considerations (At a High Level)

AKS integrates into an Azure Virtual Network. That means your cluster:

  • Has IP address planning implications
  • Participates in your broader network topology
  • Must align with security boundaries

Production mistakes often start here:

  • Overlapping address spaces
  • Under‑sized subnets
  • No separation between environments

Networking is not a post‑deployment tweak – its a day‑one design decision that you make with your wider cloud and architecture teams. We’ll go deep into networking in the next post, but even at the architecture stage, you need to make conscious choices.

Upgrade Strategy – Often Ignored, Always Critical

Kubernetes evolves quickly. AKS supports multiple Kubernetes versions, but older versions are eventually deprecated. The full list of supported AKS versions can be found at the AKS Release Status page

A production architecture must consider:

  • Version lifecycle
  • Upgrade cadence
  • Node image updates

In AKS, control plane upgrades are managed by Azure — but you control when upgrades occur and how node pools are rolled. When you create your cluster, you can specify the upgrade option you wish to use:

Its important to pay attention to this as it may affect your workloads. For example, starting in Kubernetes v1.35, Ubuntu 24.04 because the default OS SKU. What this means if you are upgrading from a lower version of Kubernetes, your node OS will be auto upgraded from Ubuntu 22.04 to 24.04.

Ignoring upgrade planning is one of the fastest ways to create technical debt in a cluster. This is why testing in lower environments to see how your workloads react to these upgrades is vital.

Mapping This to the Azure Well‑Architected Framework

Let’s anchor this back to the bigger picture and see how AKS maps to the Azure Well-Architected Framework.

Operational Excellence

  • AKS’s managed control plane reduces operational complexity.
  • Node pools introduce structured isolation.
  • Availability zones improve resilience.

Designing with these in mind from the start prevents reactive firefighting later.

Reliability

Zone distribution, multiple node pools, and scaling configuration directly influence workload uptime. Reliability is not added later — it is designed at cluster creation.

Cost Optimisation

Right‑sizing node pools and separating workload types prevents over‑provisioning. Production clusters that mix everything into one large node pool almost always overspend.

Production Guardrails – Early Principles

Before we move into deeper topics in the next posts, let’s establish a few foundational guardrails:

  • Separate system and user node pools
  • Use availability zones where supported
  • Plan IP addressing before deployment (again, we’ll dive into networking and how it affects workloads in more detail in the next post)
  • Treat upgrades as part of operations, not emergencies
  • Avoid “single giant node pool” design

These are not advanced optimisations. They are baseline expectations for production AKS.

What Comes Next

Now that we understand AKS architecture fundamentals, the next logical step is networking.

In the next post, we’ll go deep into:

  • Azure CNI and networking models
  • Ingress and traffic flow
  • Internal vs external exposure
  • Designing secure network boundaries

Because once architecture is clear, networking is what determines whether your cluster is merely functional or truly production ready.

See you on the next post!

From Containers to Kubernetes Architecture

In the previous post, What Is Azure Kubernetes Service (AKS) and Why Should You Care?, we got an intro to AKS, compared it to Azure PaaS services in terms of asking when is the right choice, and finally spun up an AKS cluster to demonstrate what exactly Microsoft exposes to you in terms of responsibilities.

In this post, we’ll take a step back to first principles and understand why containers and microservices emerged, how Docker changed application delivery, and how those pressures ultimately led to Kubernetes.

Only then does Kubernetes and by extension AKS architecture fully make sense.

From Monoliths to Microservices

If you rewind to the 1990s and early 2000s, most enterprise systems followed a fairly predictable pattern: client/server.

You either had thick desktop clients connecting to a central database server, or you had early web applications running on a handful of physical servers in a data centre. Access was often via terminal services, remote desktop, or tightly controlled internal networks.

Applications were typically deployed as monoliths. One codebase. One deployment artifact. One server—or maybe two, if you were lucky enough to have a test environment.

Infrastructure and application were deeply intertwined. If you needed more capacity, you bought another server. If you needed to update the application, you scheduled downtime. And this wasn’t like the downtime we know today – this could run into days, normally public holiday weekends where you had an extra day. Think you’re going to be having Christmas dinner or opening Easter eggs? Nope – thtere’s an upgrade on those weekends!

This model worked in a world where:

  • Release cycles were measured in months
  • Scale was predictable
  • Users were primarily internal or regionally constrained

But as the web matured in the mid-2000s, and SaaS became mainstream, expectations changed.

Virtualisation and Early Cloud

Virtual machines were the first major shift.

Instead of deploying directly to physical hardware, we began deploying to hypervisors. Infrastructure became more flexible. Provisioning times dropped from weeks to hours, and rollback of changes became easier too which de-risked the deployment process.

Then around 2008–2012, public cloud platforms began gaining serious enterprise traction. Infrastructure became API-driven. You could provision compute with a script instead of a purchase order.

Despite these changes, the application model was largely the same. We were still deploying monoliths—just onto virtual machines instead of physical servers.

The client/server model had evolved into a browser/server model, but the deployment unit was still large, tightly coupled, and difficult to scale independently.

The Shift to Microservices

Around the early 2010s, as organisations like Netflix, Amazon, and Google shared their scaling stories, the industry began embracing microservices more seriously.

Instead of a single large deployment, applications were broken into smaller services. Each service had:

  • A well-defined API boundary
  • Its own lifecycle
  • Independent scaling characteristics

This made sense in a world of global users and continuous delivery.

However, it introduced new complexity. You were no longer deploying one application to one server. You might be deploying 50 services across 20 machines. Suddenly, your infrastructure wasn’t just hosting an app—it was hosting an ecosystem.

And this is where the packaging problem became painfully obvious.

Docker and the Rise of Containers

Docker answered the packaging problem.

Containers weren’t new. Linux containers had existed in various forms for years. But Docker made them usable, portable, and developer-friendly.

Instead of saying “it works on my machine,” developers could now package:

  • Their application code
  • The runtime
  • All dependencies
  • Configuration

Into a single container image. That image could run on a laptop, in a data centre, or in the cloud—consistently. This was a major shift in the developer-to-operations contract.

The old model:

  • Developers handed over code
  • Operations teams configured servers
  • Problems emerged somewhere in between

The container model:

  • Developers handed over a runnable artifact
  • Operations teams provided a runtime environment

But Docker alone wasn’t enough.

Running a handful of containers on a single VM was manageable. Running hundreds across dozens of machines? That required coordination.

We had solved packaging. We had not solved orchestration. As container adoption increased, a new challenge emerged:

Containers are easy. Running containers at scale is not.

Why Kubernetes Emerged

Kubernetes emerged to solve the orchestration problem.

Instead of manually deciding where containers should run, Kubernetes introduced a declarative model. You define the desired state of your system—how many replicas, what resources, what networking—and Kubernetes continuously works to make reality match that description.

This was a profound architectural shift.

It moved us from:

  • Logging into servers via SSH
  • Manually restarting services
  • Writing custom scaling scripts

To:

  • Describing infrastructure and workloads declaratively
  • Letting control loops reconcile state
  • Treating servers as replaceable capacity

The access model changed as well. Instead of remote desktop or SSH being the primary control mechanism, the Kubernetes API became the centre of gravity. Everything talks to the API server.

This shift—from imperative scripts to declarative configuration—is one of the most important architectural changes Kubernetes introduced.

Core Kubernetes Architecture

To understand AKS, you first need to understand core Kubernetes components.

At its heart, Kubernetes is split into two logical areas: the control plane and the worker nodes.

The Control Plane – The Brain of the Cluster

The control plane is the brain of the cluster. It makes decisions, enforces state, and exposes the Kubernetes API.

Key components include:

API Server

The API server is the front door. Whether you use kubectl, a CI/CD pipeline, or a GitOps tool, every request flows through the API server. It validates requests and persists changes.

  • Entry point for all Kubernetes operations
  • Validates and processes requests
  • Exposes the Kubernetes API

Everything—kubectl, CI/CD pipelines, controllers—talks to the API server.

etcd

Behind the scenes sits etcd, a distributed key-value store that acts as the source of truth. It stores the desired and current state of the cluster. If etcd becomes unavailable, the cluster effectively loses its memory.

  • Distributed key-value store
  • Holds the desired and current state of the cluster
  • Source of truth for Kubernetes

If etcd is unhealthy, the cluster cannot function correctly.

Scheduler

The scheduler is responsible for deciding where workloads run. When you create a pod, the scheduler evaluates resource availability and constraints before assigning it to a node.

  • Decides which node a pod should run on
  • Considers resource availability, constraints, and policies

Controller Manager

The controller manager runs continuous reconciliation loops. It constantly compares the desired state (for example, “I want three replicas”) with the current state. If a pod crashes, the controller ensures another is created.

  • Runs control loops
  • Continuously checks actual state vs desired state
  • Takes action to reconcile differences

This combination is what makes Kubernetes self-healing and declarative.

Worker Nodes – Where Work Actually Happens

Worker nodes are where your workloads actually run.

Each node contains:

kubelet

Each node runs a kubelet, which acts as the local agent communicating with the control plane. It ensures that the containers defined in pod specifications are actually running.

  • Agent running on each node
  • Ensures containers described in pod specs are running
  • Reports node and pod status back to the control plane

Container Runtime

Underneath that sits the container runtime—most commonly containerd today. This is what actually starts and stops containers.

  • Responsible for running containers
  • Historically Docker, now containerd in most environments

kube-proxy

Networking between services is handled through Kubernetes networking constructs and components such as kube-proxy, which manages traffic rules.

  • Handles networking rules
  • Enables service-to-service communication n

Pods, Services, and Deployments

Above this infrastructure layer, Kubernetes introduces abstractions like pods, deployments, and services. These abstractions allow you to reason about applications instead of machines.

Pods

  • Smallest deployable unit in Kubernetes
  • One or more containers sharing networking and storage

Deployments

  • Define how pods are created and updated
  • Enable rolling updates and rollback
  • Maintain desired replica counts

Services

  • Provide stable networking endpoints
  • Abstract away individual pod lifecycles

You don’t deploy to a server. You declare a deployment. You don’t track IP addresses. You define a service.

How This Maps to Azure Kubernetes Service (AKS)

AKS does not change Kubernetes—it operationalises it. The Kubernetes architecture remains the same, but the responsibility model changes.

In a self-managed cluster, you are responsible for the control plane. You deploy and maintain the API server. You protect and back up etcd. You manage upgrades.

In AKS, Azure operates the control plane for you.

Microsoft manages the API server, etcd, and control plane upgrades. You still interact with Kubernetes in exactly the same way—through the API—but you are no longer responsible for maintaining its most fragile components.

You retain responsibility for worker nodes, node pools, scaling, and workload configuration. That boundary is deliberate.

It aligns directly with the Azure Well-Architected Framework:

  • Operational Excellence through managed control plane abstraction
  • Reduced operational risk and complexity
  • Clear separation between platform and workload responsibility

AKS is Kubernetes—operationalised.

Why This Matters for Production AKS

Every production AKS decision maps back to Kubernetes architecture:

  • Networking choices affect kube-proxy and service routing
  • Node pool design affects scheduling and isolation
  • Scaling decisions interact with controllers and the scheduler

Without understanding the underlying architecture, AKS can feel opaque.

With that understanding, it becomes predictable.

What Comes Next

Now that we understand:

  • Why containers emerged
  • Why Kubernetes exists
  • How Kubernetes is architected
  • How AKS maps to that architecture

We’re ready to start making design decisions.

In the next post, we’ll move into AKS architecture fundamentals, including:

  • Control plane and data plane separation
  • System vs user node pools
  • Regional design and availability considerations

See you on the next post

What Is Azure Kubernetes Service (AKS) and Why Should You Care?

In every cloud native architecture discussion you have had over the last few years or are going to have in the coming years, you can be guaranteed that someone has or will introduce Kubernetes as a hosting option on which your solution will run.

There’s also different options when Kubernetes enters the conversation – you can choose to run:

Kubernetes promises portability, scalability, and resilience. In reality, operating Kubernetes yourself is anything but simple.

Have you’ve ever wondered whether Kubernetes is worth the complexity—or how to move from experimentation to something you can confidently run in production?

Me too – so let’s try and answer that question. For anyone who knows me or has followed me for a few years knows, I like to get down to the basics and “start at the start”.

This is the first post is of a blog series where we’ll focus on Azure Kubernetes Service (AKS), while also referencing the core Kubernetes offerings as a reference. The goal of this series is:

By the end (whenever that is – there is no set time or number of posts), we will have designed and built a production‑ready AKS cluster, aligned with the Azure Well‑Architected Framework, and suitable for real‑world enterprise workloads.

With the goal clearly defined, let’s start at the beginning—not by deploying workloads or tuning YAML, but by understanding:

  • Why AKS exists
  • What problems it solves
  • When it’s the right abstraction.

What Is Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) is a managed Kubernetes platform provided by Microsoft Azure. It delivers a fully supported Kubernetes control plane while abstracting away much of the operational complexity traditionally associated with running Kubernetes yourself.

At a high level:

  • Azure manages the Kubernetes control plane (API server, scheduler, etcd)
  • You manage the worker nodes (VM size, scaling rules, node pools)
  • Kubernetes manages your containers and workloads

This division of responsibility is deliberate. It allows teams to focus on applications and platforms rather than infrastructure mechanics.

You still get:

  • Native Kubernetes APIs
  • Open‑source tooling (kubectl, Helm, GitOps)
  • Portability across environments

But without needing to design, secure, patch, and operate Kubernetes from scratch.

Why Should You Care About AKS?

The short answer:

AKS enables teams to build scalable platforms without becoming Kubernetes operators.

The longer answer depends on the problems you’re solving.

AKS becomes compelling when:

  • You’re building microservices‑based or distributed applications
  • You need horizontal scaling driven by demand
  • You want rolling updates and self‑healing workloads
  • You’re standardising on containers across teams
  • You need deep integration with Azure networking, identity, and security

Compared to running containers directly on virtual machines, AKS introduces:

  • Declarative configuration
  • Built‑in orchestration
  • Fine‑grained resource management
  • A mature ecosystem of tools and patterns

However, this series is not about adopting AKS blindly. Understanding why AKS exists—and when it’s appropriate—is essential before we design anything production‑ready.

AKS vs Azure PaaS Services: Choosing the Right Abstraction

Another common—and more nuanced—question is:

“Why use AKS at all when Azure already has PaaS services like App Service or Azure Container Apps?”

This is an important decision point, and one that shows up frequently in the Azure Architecture Center.

Azure PaaS Services

Azure PaaS offerings such as App Service, Azure Functions, and Azure Container Apps work well when:

  • You want minimal infrastructure management responsibility
  • Your application fits well within opinionated hosting models
  • Scaling and availability can be largely abstracted away
  • You’re optimising for developer velocity over platform control

They provide:

  • Very low operational overhead – the service is an “out of the box” offering where developers can get started immediately.
  • Built-in scaling and availability – scaling comes as part of the service based on demand, and can be configured based on predicted loads.
  • Tight integration with Azure services – integration with tools such as Azure Monitor and Application Insights for monitoring, Defender for Security monitoring and alerting, and Entra for Identity.

For many workloads, this is exactly the right choice.

AKS

AKS becomes the right abstraction when:

  • You need deep control over networking, runtime, and scheduling
  • You’re running complex, multi-service architectures
  • You require custom security, compliance, or isolation models
  • You’re building a shared internal platform rather than a single application

AKS sits between IaaS and fully managed PaaS:

Azure PaaS abstracts the platform for you. AKS lets you build the platform yourself—safely.

This balance of control and abstraction is what makes AKS suitable for production platforms at scale.

Exploring AKS in the Azure Portal

Before designing anything that could be considered “production‑ready”, it’s important to understand what Azure exposes out of the box – so lets spin up an AKS instance using the Azure Portal.

Step 1: Create an AKS Cluster

  • Sign in to the Azure Portal
  • In the search bar at the top, Search for Kubernetes Service
  • When you get to the “Kubernetes center page”, click on “Clusters” on the left menu (it should bring you here automatically). Select Create, and select “Kubernetes cluster”. Note that there are also options for “Automatic Kubernetes cluster” and “Deploy application” – we’ll address those in a later post.
  • Choose your Subscription and Resource Group
  • Enter a Cluster preset configuration, Cluster name and select a Region. You can choose from four different preset configurations which have clear explanations based on your requirements
  • I’ve gone for Dev/Test for the purposes of spinning up this demo cluster.
  • Leave all other options as default for now and click “Next” – we’ll revisit these in detail in later posts.

Step 2: Configure the Node Pool

  • Under Node pools, there is an agentpool automatically added for us. You can change this if needed to select a different VM size, and set a low min/max node count

    This is your first exposure to separating capacity management from application deployment.

    Step 3: Networking

    Under Networking, you will see options for Private/Public Access, and also for Container Networking. This is an important chopice as there are 2 clear options:

    • Azure CNI Overlay – Pods get IPs from a private CIDR address space that is separate from the node VNet.
    • Azure CNI Node Subnet – Pods get IPs directly from the same VNet subnet as the nodes.

    You also have the option to integrate this into your own VNet which you can specify during the cluster creation process.

    Again, we’ll talk more about these options in a later post, but its important to understand the distinction between the two.

    Step 4: Review and Create

    Select Review + Create – note at this point I have not selected any monitoring, security or integration with an Azure Container Registry and am just taking the defaults. Again (you’re probably bored of reading this….), we’ll deal with these in a later post dedicated to each topic.

    Once deployed, explore:

    • Node pools
    • Workloads
    • Services and ingresses
    • Cluster configuration

    Notice how much complexity is hidden – if you scroll back up to the “Azure-managed v Customer-managed” diagram, you have responsibility for managing:

    • Cluster nodes
    • Networking
    • Workloads
    • Storage

    Even though Azure abstracts away responsibility for things like key-value store, scheduler, controller and management of the cluster API, a large amount of responsibility still remains.

    What Comes Next in the Series

    This post sets the foundation for what AKS is and how it looks out of the box using a standard deployment with the “defaults”.

    Over the course of the series, we’ll move through the various concepts which will help to inform us as we move towards making design decisions for production workloads:

    • Kubernetes Architecture Fundamentals (control plane, node pools, and cluster design), and how they look in AKS
    • Networking for Production AKS (VNets, CNI, ingress, and traffic flow)
    • Identity, Security, and Access Control
    • Scaling, Reliability, and Resilience
    • Cost Optimisation and Governance
    • Monitoring, Alerting and Visualizations
    • Alignment with the Azure Well Architected Framework
    • And lots more ……

    See you on the next post!

    You’re Already a Public Speaker (You Just Don’t Know It Yet)

    2025 was a great year for me from a community speaking perspective. I had the opportunity to speak in-person at conferences like South Coast Summit, Nordic Integration Summit, and Global Azure and AI Community Day, and virtually at community events like Azure Back to School, India Cloud Security Summit and Festive Tech Calendar.

    The one question that people keep asking me is: How do you get started as a public speaker?”. The answer usually surprises people.

    You probably already are one.

    Public Speaking Isn’t Where You Think It Starts

    When people hear “public speaker,” they often picture a conference stage, a headset microphone, and a perfectly polished slide deck and demo.

    But that’s not where public speaking actually begins. If you’ve ever:

    • Presented a solution to a client
    • Walked an internal team through an architecture decision
    • Explained why a particular design choice mattered
    • Defended a proposal in front of stakeholders

    Then congratulations—you’re already doing the hardest part.

    You’re communicating ideas, adapting to your audience, answering questions, and telling a story with a beginning, middle, and end. The only real difference between that and a community talk is the room you’re in.

    From Meetings to Community Stages

    The journey from a meeting room to a community stage isn’t about learning a completely new skill. It’s about refining the one you already have. At its core:

    • A client meeting is storytelling under pressure
    • A community talk is storytelling with support

    Community audiences want you to succeed. They’re there because they care about the topic, not because they’re trying to approve a budget or poke holes in a proposal. The tech community doesn’t require or want perfection – we thrive on real-world experiences and shared honestly. The community doesn’t show up to your talk to learn what to do. We want to hear your story, and learn what actually happened when you tried it.

    So where do I start?

    The first thing to do is to actually attend a conference as an attendee. Get yourself out there and introduce yourself to people in the community. We don’t bite – we’re all real people as well. Go to the sessions at that conference on topics that you are interested in. Watch the presenters and how their sessions flow and work. And go introduce yourself to the presenters afterwards – give some feedback and ask some questions.

    Once you have that first experience, start somewhere safe.

    • An internal lunch and learn
    • A team brown-bag session

    These environments are supportive by design. People expect experimentation, not perfection. Don’t send the essay-style email when you have found and solved a problem – gather your team for 15 minutes over lunch and explain what you found, how you solved it, the lessons you learned and how you can apply these lessons next time.

    You have your first talk – what happens now

    Now that you have a talk, the next step is to turn it into a session. The basic premise is when you encountered a problem or had to explain a solution to someone:

    • What problem were they trying to solve?
    • What options did you consider?
    • What trade-offs did you make?
    • What would you do differently next time?

    That conversation is already the outline of a community session. Add slides and/or a demo, structure it with a problem, solution and outcome, and suddenly you have a talk that’s grounded in reality—because it came from real work.

    For most conferences, your talk is going to be either a 15-20 minute lightning talk, or else a 35-50 minute session. A hack that I’ve used to time my sessions is having a script per slide and a script for your demo. Your slides should be bullet points along with graphics or diagrams, and you then need to talk through the demo as well. Having this scripted out means you can practice and time yourself on how long the session will take to deliver.

    Once you have the session done, you need to prepare your session abstract which is normally done by setting up a profile on Sessionize or Run.Events. Writing the abstract is important, and my friend and fellow MVP Zoe Wilson has written a great post on how to write a great session abstrat, which you can find at this link.

    Where do I find events to submit to?

    So now that you have your session, you need to submit it somewhere. And there’s a few options here:

    • Virtual Events – these are a great starting point, as they are normally events which require you to submit either blog posts or pre-recorded content. There’s also normally no “entry criteria” as all sessions are automatically approved. These events are great starting points to grow your presence in the community, and run at the same times every year. As well as the ones I’ve mentioned above, check out Azure Spring Clean, Cyber Back to School and WeDoAI (these are just some examples).
    • User Groups – remember that speaker that you went and gave feedback to above? There’s a good chance they are involved or know someone who is part of a User Group. User Groups like Welsh Azure (run by John Lunn aka Jonny Chipz) and Microsoft Azure Community (Run by Kevin Greene and Nicholas Chang) are run virtually, whereas Glasgow Azure (run by Sarah Lean and Gregor Suttie) is run in-person, so there’s a good balance depending on where you are located. Again, attend as an attendee – these are good fun and some have quizzes, spot prizes and refreshments for the in-person ones!
    • Conferences – if you’ve spoken or submitted to the first 2, then the live in-person conference is the next step. As I said above, these are welcoming environments where everyone is supported.

    You can find all of these in a few ways. I mentioned Sessionize and run.events, and you can also find an extensive list of upcoming conferences for both attendees and speakers at https://www.communitydays.org/. Also, start following or connecting with folks from the community on socials – we normally share user groups and CFS links for events and conferences.

    You will get rejected, but keep going!!

    My Sessionize profile has quite a lot of red in it:

    But thats OK – I don’t expect to be selected for every single session I submit to every conference or User Group. The difference between people who “can’t speak” and those who do regularly isn’t talent, it’s persistence. Keep submitting your sessions – the rejections can sting at the start but just keep going.

    The best advice here is to reach out and ask for advice – the conference organisers have hundreds of sessions to choose from and can’t give feedback on every single rejected session. If thats happening, reach out to someone in the community for help – again, we are all humans and have all gone through this. Sometimes its something as simple as the wording, the title, or a little tweak that needed.

    Final Thoughts

    Community speaking isn’t a performance, it’s a conversation, just at a slightly larger scale. You’re not there to prove how much you know, you’re there to share what you’ve learned so far. If you’ve ever explained a technical decision to another human being, you already have what it takes to be a community speaker.

    Azure Lab Services Is Retiring: What to Use Instead (and How to Plan Your Migration)

    Microsoft has announced that Azure Lab Services will be retired on June 28, 2027. New customer sign-ups have already been disabled as of July 2025, which means the clock is officially ticking for anyone using the service today.

    You can read the official announcement on Microsoft Learn here: https://learn.microsoft.com/en-us/azure/lab-services/retirement-guide

    While 2027 may feel a long way off, now is the time to take action!

    For those of you who have never heard of Azure Lab Services, lets take a look at what it was and how you would have interacted with it (even if you didn’t know you were!).

    What is/was Azure Lab Services?

    Image: Microsoft Learn

    Azure Lab Services allowed you to create labs with infrastructure managed by Azure. The service handles all the infrastructure management, from spinning up virtual machines (VMs) to handling errors and scaling the infrastructure.

    If you’ve ever been on a Microsoft course, participated in a Virtual Training Days course, or attended a course run by a Microsoft MCT, Azure Lab Services is what the trainer would have used to facilitate:

    • Classrooms and training environments
    • Hands-on labs for workshops or certifications
    • Short-lived dev/test environments

    Azure Lab Services was popular because it abstracted away a lot of complexity around building lab or classroom environments. Its retirement doesn’t mean Microsoft is stepping away from virtual labs—it means the responsibility shifts back to architecture choices based on the requirements you have.

    If you or your company is using Azure Lab Services, the transition to a new service is one of those changes where early planning pays off—especially if your labs are tied to academic calendars, training programmes, or fixed budgets.

    So what are the alternatives?

    Microsoft has outlined several supported paths forward. None are a 1:1 replacement, so the “right” option depends on who your users are and how they work. While these solutions aren’t necessarily education-specific, they support a wide range of education and training scenarios.

    Azure Virtual Desktop (AVD)

    Image: Microsoft Learn

    🔗 https://learn.microsoft.com/azure/virtual-desktop/

    AVD is the most flexible option and the closest match for large-scale, shared lab environments. AVD is ideal for providing full desktop and app delivery scenarios and provides the following benefits:

    • Multi-session Windows 10/11, which either Full Desktop or Single App Delivery options
    • Full control over networking, identity, and images. One of the great new features of AVD (still in preview mode) is that you can now use Guest Identities in your AVD environments, which can be really useful for training environments and takes the overhead of user management away.
    • Ideal for training labs with many concurrent users
    • Supports scaling plans to reduce costs outside working hours (check out my blog post on using Scaling Plans in your AVD Environments)

    I also wrote a set of blog posts about setting up your AVD environments from scratch which you can find here and here.

    Windows 365

    🔗 https://learn.microsoft.com/windows-365/

    Windows 365 offers a Cloud PC per user, abstracting away most infrastructure concerns. Cloud PC virtual machines are Microsoft Entra ID joined and support centralized end-to-end management using Microsoft Intune. You assign Cloud PC’s by assigning a license to that user in the same way as you would assign Microsoft 365 licences. The benefits of Windows 365 are:

    • Simple to deploy and manage
    • Predictable per-user pricing
    • Well-suited to classrooms or longer-lived learning environments

    The trade-off is that there is less flexibility and typically higher cost per user than shared AVD environments, as the Cloud PC’s are dedicated to the users and cannot be shared.

    Azure DevTest Labs

    Image: Microsoft Learn

    🔗 https://learn.microsoft.com/azure/devtest-labs/

    A strong option for developer-focused labs, Azure DevTest labs are targeted at enterprise customers. It also has a key difference to the other alternative solutions, its the only one that offers access to Linux VMs as well as Windows VMs.

    • Supports Windows and Linux
    • Built-in auto-shutdown and cost controls
    • Works well for dev/test and experimentation scenarios

    Microsoft Dev Box

    🔗 https://learn.microsoft.com/dev-box/

    Dev Box is aimed squarely at professional developers. It’s ideal for facilitating hands-on learning where training leaders can use Dev Box supported images to create identical virtual machines for trainees. Dev Box virtual machines are Microsoft Entra ID joined and support centralized end-to-end management with Microsoft Intune.

    • High-performance, secure workstations
    • Integrated with developer tools and workflows
    • Excellent for enterprise engineering teams

    However, its important to note that as of November 2025, DevBox is being integrated into Windows365. The service is built on top of Windows365, so Micrsoft has decided to unify the offerings. You can read more about this announcement here but as of November 2025, Microsoft are no longer accepting new DevBox customers – https://learn.microsoft.com/en-us/azure/dev-box/dev-box-windows-365-announcement?wt.mc_id=AZ-MVP-5005255

    When First-Party Options Aren’t Enough

    If you relied heavily on the lab orchestration features of Azure Lab Services (user lifecycle, lab resets, guided experiences), you may want to evaluate partner platforms that build on Azure:

    These solutions provide:

    • Purpose-built virtual lab platforms
    • User management and lab automation
    • Training and certification-oriented workflows

    They add cost, but also significantly reduce operational complexity.

    Comparison: Azure Lab Services Alternatives

    Lets take a look at a comparison of each service showing cost, use cases and strengths:

    ServiceTypical Cost ModelBest Use CasesKey StrengthWhen 3rd Party Tools Are Needed
    Azure Virtual DesktopPay-per-use (compute + storage + licensing)Large classrooms, shared labs, training environmentsMaximum flexibility and scalabilityFor lab orchestration, user lifecycle, guided labs
    Windows 365Per-user, per-monthClassrooms, longer-lived learning PCsSimplicity and predictabilityRarely needed
    Azure DevTest LabsPay-per-use with cost controlsDev/test, experimentation, mixed OS labsCost governanceFor classroom-style delivery
    Microsoft Dev BoxPer-user, per-monthEnterprise developersPerformance and securityNot typical
    Partner PlatformsSubscription + Azure consumptionTraining providers, certification labsTurnkey lab experiencesCore dependency

    Don’t Forget Hybrid Scenarios

    If some labs or dependencies must remain on-premises, you can still modernise your management approach by deploying Azure Virtual Desktop locally and manage using Azure Arc, which will allow you to

    • Apply Azure governance and policies
    • Centralise monitoring and management
    • Transition gradually toward cloud-native designs

    Start Planning Now

    With several budget cycles between now and June 2027, the smartest move is to:

    1. Inventory existing labs and usage patterns
    2. Map them to the closest-fit replacement
    3. Pilot early with a small group of users

    Azure Lab Services isn’t disappearing tomorrow—but waiting until the last minute will almost certainly increase cost, risk, and disruption.

    If you treat this as an architectural evolution rather than a forced migration, you’ll end up with a platform that’s more scalable, more secure, and better aligned with how people actually learn and work today.

    Azure Container Hosting – which service should you use?

    Its Christmas time, and that means its time for another month of the always fantastic Festive Tech Calendar. This was one of the first events that I participated in when I was trying to break into blogging and public speaking and I’m delighted to be involved again this year.

    This year, the team are raising funds for Beatson Cancer Charity who raise funds to transform the way cancer care is funded and delivered by funding specialists, research and education to invest in a better future for cancer patients. You can make donations via the Just Giving page.

    In this post, I’ll walk through the extensive list of Container hosting options that are available on Azure. I’ll take a look at the Azure-native offerings, include some third-party platforms that run on Azure, and then compare them on performance, scalability, costs, and service limits.

    What counts as “Container Hosting” on Azure?

    For this post I’m treating a “container hosting option” as:

    A service where you can run your own Docker images as workloads, with Azure (or a partner) running the infrastructure.

    There are an extensive list of options (and I will exclude a few off the list below, but the main “go-to” options that I’ve seen in architecture discussions are:

    • Azure Container Apps
    • Azure Kubernetes Service (AKS)
    • Azure Container Instances (ACI)
    • Azure App Service (Web Apps for Containers)
    • Azure Service Fabric (with containers)
    • Azure Red Hat OpenShift (ARO) – OpenShift on Azure
    • Kubernetes platforms on Azure VMs or Azure VMware Solution (VMware Tanzu, Rancher, etc.)

    But what about the humble reliable Virtual Machine?

    OK yes, its still out there as an option – the Virtual Machine with Docker installed to run containers. And its the place where most of us have started on this journey (you can check out a blog series I wrote a few years ago here on the subject of getting started with running Docker on VM’s).

    There are still some situations where you will see a need for Virtual Machines to run containers, but as we’ll see in the options below, this has been superseded by the range of offerings available on Azure who can run containers from single instances right up to enterprise level offerings.

    Azure Container Instances (ACI)

    Lets start with the smallest available form of hosting which is Azure Container Instances. ACI is the “run a container right now without VMs or an orchestrator” service – there are no virtual machines or orchestrators to manage, and containers start within seconds on Azure’s infrastructure. ACI provides a single container or small group of containers (called a container group) on-demand. This simplicity makes it essentially “containers-as-a-service”.

    You can run a container by issuing a single Azure CLI command. It’s completely managed by Azure: patching, underlying host OS, and other maintenance are invisible to the user. ACI also supports both Linux and Windows containers.

    Its great for short-lived tasks and simple container groups, good examples of this would be Cron-style jobs, build workers, data processing pipelines, and dev/test experiments where you just want a container to run for a bit and then disappear.

    Azure App Service (Web Apps for Containers)

    Azure App Service (Web App for Containers) is a Platform-as-a-Service offering that lets you deploy web applications or APIs packaged as Docker containers, without managing the underlying servers.

    This uses all of the features that you would normally see with App Service – you get deployment slots, auto-scaling, traffic routing, and integrated monitoring with Azure Monitor. The benefit of this is that it abstracts away the container management and focuses on developer productivity for web applications.

    The use case of using App Service is the familiarity with the product. Its gives you predictable, reserved capacity and can be used to host HTTP APIs or websites where you don’t want to have the overhead of using Kubernetes, but want to utilise features like deployment slots, built-in auth, easy custom domains, built-in backup & integration.

    Azure Container Apps

    Azure Container Apps is a fully managed container execution environment, designed specifically for microservices, APIs, and event-driven processing.

    It abstracts away the Kubernetes infrastructure and provides a serverless experience for running containers – meaning you can run many containers that automatically scale in response to demand and even scale down to zero when idle.

    Container Apps sits on top of Kubernetes (it runs on Azure’s internal K8s with open technologies like KEDA, Dapr, and Envoy) but as a developer you do not directly interact with Kubernetes objects. Instead, you define Container Apps and Azure handles placement, scaling, and routing.

    Container Apps is an ideal place for running Microservices, APIs and event-driven jobs where you don’t want to manage Kubernetes, and want to scale-to-zero and only pay when there’s traffic. Its a nice “middle ground” between App Service and full AKS.

    Azure Kubernetes Service (AKS)

    We’re finally getting to the good stuff!!

    Image Source – Microsoft

    Azure Kubernetes Service (AKS) is Azure’s flagship container orchestration service, offering a fully managed Kubernetes cluster.

    With AKS, you get the standard open-source Kubernetes experience (API, kubectl, and all) without having to run your own Kubernetes control plane – Azure manages the K8s master nodes (API servers, etc.) as a service.

    You do manage the worker nodes (agent nodes) in terms of deciding their VM sizes, how many, and when to scale (though Azure can automate scaling).

    In terms of ease-of-use, AKS has a steep learning curve if you’re new to containers, because Kubernetes itself is a complex system. Provisioning a cluster is quite easy (via Azure CLI or portal), but operating an AKS cluster effectively requires knowledge of Kubernetes concepts (pods, services, deployments, ingress controllers, config maps, etc.).

    It’s less turn-key than the earlier services – you are stepping into the world of container orchestration with maximum flexibility. One of the main benefits of AKS is that it’s not an opinionated PaaS – it’s Kubernetes, so you can run any containerized workload with any configuration that Kubernetes allows.

    Another reason for choosing AKS is that you can run it locally in your environment on an Azure Local cluster managed by Azure Arc.

    The main reason for choosing AKS is running enterprise or large-scale workloads that need:

    • Full Kubernetes API control
    • Custom controllers, CRDs, service meshes, operators
    • Multi-tenant clusters or complex networking

    If you’re already familiar with Kubernetes, this is usually the default choice.

    Azure Red Hat OpenShift (ARO)

    Azure Red Hat OpenShift (ARO) is a jointly managed offering by Microsoft and Red Hat that provides a fully managed OpenShift cluster on Azure.

    OpenShift is Red Hat’s enterprise Kubernetes distribution that comes with additional tools and an opinionated setup (built on Kubernetes but including components for developers and operations). With ARO, Azure handles provisioning the OpenShift cluster (masters and workers) and critical management tasks, while Red Hat’s tooling is layered on top.

    It’s a first-class Azure service, but under the covers, it’s Red Hat OpenShift Container Platform. In terms of ease-of-use: for teams already familiar with OpenShift, this is much easier than running OpenShift manually on Azure VMs. The service is managed, so tasks like patching the underlying OS, upgrading OpenShift versions, etc., are handled in coordination with Red Hat.

    The use case for ARO comes down to whether you’re an OpenShift customer already, or need OpenShift’s enterprise features (built-in pipelines, operators, advanced multi-tenancy).

    Azure Service Fabric

    Service Fabric predates AKS and was Azure’s first container orchestrator. I’ve not seen this ever out in the wild but it deserves a mention here as its still available as a container hosting platform on Azure.

    Its a mature distributed systems platform from Microsoft, used internally for many Azure services (e.g., SQL DB, Event Hubs). It can orchestrate containers as well as traditional processes (called “guest executables”) and also supports a unique microservices programming model with stateful services and actors where high-throughput is required.

    I’m not going to dive too deep into this topic, but the use case for this really is if you already have significant investment in Service Fabric APIs.

    Third-party Kubernetes & container platforms on Azure

    Beyond the native services above, you can also run a variety of third-party platforms on Azure:

    • Kubernetes distributions on Azure VMs: VMware Tanzu Kubernetes Grid, Rancher, Canonical Kubernetes, etc., deployed directly onto Azure VMs.
    • Azure VMware Solution + Tanzu: run vSphere with Tanzu or Tanzu Kubernetes Grid on Azure VMware Solution (AVS) and integrate with Azure native services.

    There are a number of reasons for ignoring the native Azure services and going for a “self-managed” model:

    • If you need a feature that AKS/ARO doesn’t provide (e.g., custom Kubernetes version or different orchestrator, or multi-cloud control plane).
    • If you want to avoid cloud vendor lock-in at the orchestration layer (some companies choose BYO Kubernetes to not depend on AKS specifics).
    • If your organization already invested in those tools (e.g., they use Rancher to manage clusters across AWS, on-prem and also want to include Azure).
    • If you have an on-prem extension scenario: e.g., using VMware Tanzu in private cloud and replicating environment in Azure via AVS to have consistency and easy migration of workloads.
    • Or if you require extreme custom control: e.g., specialized network plugins or kernel settings that AKS might not allow.

    Comparison Summary

    Lets take a quick comparison summary where you can see at a glance the ease of use, hosting, cost model and use cases of each service:

    OptionEase of UseHosting ModelCost ModelBest For
    Azure Container InstancesVery High Serverless Pay per second of CPU/Memory, no idle cost.Quick tasks, burst workloads, dev/test, simple APIs.
    Azure App Service High PaaSFixed cost per VM instance (scaled-out). Always-on cost (one or more instances).Web apps & APIs needing zero cluster mgmt, CI/CD integration, and auto-scaling.
    Azure Container AppsModerate ServerlessPay for resources per execution (consumption model) + optional reserved capacity. Idle = zero cost.Microservice architectures, event-driven processing, varying workloads where automatic scale and cost-efficiency are key.
    Azure Kubernetes Service (AKS)Low (for beginners).  Moderate (for K8s proficient teams).Managed Kubernetes (IaaS+PaaS mix)Pay for VMs (nodes) only. Control plane free (standard tier) Complex, large, or custom container deployments
    Azure Red Hat OpenShift (ARO)Moderate/Low – easy for OpenShift experts, but more complex than AKS for pure K8s users. Managed OpenShift (enterprise K8s)Pay for VMs + Red Hat surcharge. Higher baseline cost than AKS.Organizations requiring OpenShift’s features (built-in CI, catalog, stricter multi-tenancy) or who have OpenShift on-prem and want cloud parity.
    Azure Service FabricLow – steep learning curve IaaS (user-managed VMs) with PaaS runtimePay for VMs No automatic scaling – you manage cluster size.Stateful, low-latency microservices, or mixed workloads (containers + processes). Teams already leveraging SF’s unique capabilities.

    Conclusion

    As we can see above, Azure offers a rich spectrum of container hosting options.
    Serverless and PaaS options cover most workloads with minimal ops overhead, while managed Kubernetes and third-party platforms unlock maximum flexibility at higher complexity.

    In my own opinion, the best way to go is to make the decision based on business needs and the core knowledge that exists within your team. Use managed and/or serverless options by default; move to Kubernetes only when needed.

    You can use the decision tree shown below as an easy reference to make the decision based on the workload you wish to run.

    Image Source – Microsoft

    I hope this blog post was useful! For a deeper dive, you can find the official Microsoft guide for choosing a Container hosting service at this link.

    Maximizing Cloud Efficiency and Cost Savings with Azure FinOps

    Its Christmas time, and that means its time for another month of the always fantastic Festive Tech Calendar. This was one of the first events that I participated in when I was trying to break into blogging and public speaking and I’m delighted to be involved again this year.

    This year, the team are raising funds for Beatson Cancer Charity, and you can make donations via the Just Giving page.

    In this post, we’ll dive into Azure FinOps, explore tools and practices available to help you manage costs, look at real-world savings examples, and discuss how to integrate alerts into Service Management solutions for proactive monitoring.

    But before we dive in, lets set the scene with a real world example!

    The problem with wanting more …..

    We live in a world and a time in society where we all want more. We want it bigger and better. Bigger houses, bigger SUV’s, the highest performing laptop, the newest model phone.

    And of course because its Christmas, the biggest turkey you can find ….

    This is “Irish Mammy” syndrome, where we over cater to make sure there is enough for everyone at Christmas (and for my American readers, the same rules apply at Thanksgiving).

    And its not just Turkey – making sure there are lots of different vegetables as a supplement including multiple types of potatoes (roast, mashed, boiled with both skin on and off, chipped, gratin, croquette….). And don’t forget the Nut Roasts! You then get into Selection Boxes, Mince Pies, Puddings….. The list goes on.

    So aside from making you hungry, what has this got to do with Azure?

    Yes yes, I know I’ve been rambling on but I was getting to to the point.

    All of that food costs money and inevitably there is going to be some (or a lot of) wastage there. We can use the term “over-provisioning” to describe it.

    The same principle applies to Azure or any cloud provider when migrating new workloads into the cloud. No matter how much you try to “right-size”, there is a temptation to over-provision to make sure you have enough wiggle room due to increased demand.

    In my session for last years Festive Tech Calendar, I spoke about Azure Load Testing and how that can be used to not only “right-size” your environments, but also to test based on different patterns and unpredicatable spikes in demand that may happen.

    May happen …. or may not happen. You can only go so far in the science of predicting what might happen because there is always going to be a use case or usage pattern that you either didn’t consider.

    Regardless of all that you need to deploy your resources, but now comes the challenge – how do you monitor costs to ensure that there isn’t overspend? This is not just about Cost Management or Scaling, this is where the power of the entire suite of Azure FinOps can help.

    What is Azure FinOps?

    FinOps combines financial management practices with operations to ensure that cloud spending is transparent, accountable, and optimized. In the Azure ecosystem, FinOps helps businesses manage their cloud resources by giving visibility into spending patterns, offering optimization recommendations, and enabling financial governance.

    The FinOps lifecycle consists of three main phases:

    1. Inform: Understand and track cloud costs to ensure transparency.
    2. Optimize: Use insights to reduce unnecessary costs and improve efficiency.
    3. Operate: Continuously manage cloud costs to ensure ongoing financial efficiency.

    Azure provides a set of native tools designed to support FinOps practices and help organizations maximize cloud efficiency. Let’s look at each of these tools in detail:

    1. Azure Cost Management

    Azure Cost Management is the cornerstone of FinOps on Azure. It provides deep insights into cloud costs, allowing you to track, allocate, and analyze spend across your Azure resources.

    • Cost Analysis: Allows you to visualize and analyze costs over time by service, resource group, subscription, or department. This helps identify cost trends and usage patterns.
    • Budgets and Alerts: Set budgets for specific subscriptions or resources, and receive alerts if you’re approaching or exceeding budget limits.

    To give you a real world scenario, you can use Azure Cost Management to identify unnecessary resources running during off-peak hours, resulting in a significant cost reduction. By analyzing spending patterns, you can schedule workloads to scale down or shut down entirely during low-use periods.

    2. Azure Advisor

    Azure Advisor provides personalized recommendations to help optimize your Azure resources based on best practices. The Cost category of Azure Advisor focuses specifically on identifying opportunities to reduce spend by suggesting actions like right-sizing VMs, using Reserved Instances, and removing idle resources.

    In a real world scenario, you can use Advisor’s recommendations to optimize virtual machines , such as resizing underutilized VMs or applying Reserved Instances to resources that are in constant use, which can save thousands in annual costs.

    3. Azure Reservations

    Speaking of Azure Reservations, committing to reservations can provide significant cost savings by committing to a one or three-year terms for certain Azure resources, such as VMs, SQL Databases, and Cosmos DB.

    Reservations allow you to prepay for resources at a discounted rate, which is especially beneficial for predictable, long-term workloads. Depending on the Azure service, you can save up to 72% on reserved VMs and other services.

    4. Azure Spot Instances

    Azure Spot Instances allow you to purchase unused Azure compute capacity at a discount of up to 90%. These instances are ideal for workloads that are not time-sensitive and can tolerate interruptions, such as batch processing, development, and testing.

    An example would be running non-critical data processing workloads on Spot Instances during low-traffic hours, which drastically reduces operational expenses without impacting service.

    5. Azure Policy for Cost Management

    Azure Policy enforces rules and standards to keep resources compliant, including cost-related policies. You can set policies to control which resources can be deployed, prevent the use of expensive SKUs, and enforce resource tagging for accurate cost tracking.

    Using Alerts for Proactive Monitoring

    Setting up cost-related alerts is essential for proactive cost management. These alerts can notify relevant teams when spending thresholds are reached, helping prevent unexpected overspend. Here’s some examples and use cases for how you can configure alerts in Azure and integrate them into your Service Management solutions.

    1. Setting Budgets and Alerts

    With Azure Budgets, you can easily define the budgets in line with your predicted cloud spend based on amount, time period, and reset schedule to keep everything aligned.

    Once your budget is in place. Azure Budgets sends alerts the moment you hit a predefined threshold. Alerts can be customized to be sent via email or push notifications, ensuring you’re always in control of your cloud costs and never caught off guard.

    To create a budget:

    • In Azure Cost Management + Billing, navigate to Budgets, select your subscription, and create a new budget.
    • Set Thresholds: Define a monthly or quarterly budget and set alert thresholds (e.g., 50%, 75%, and 100% of the budget).
    • Configure Notifications: Specify recipients (e.g., Finance and Operations teams) for notifications via email or SMS.

    2. Integrating Alerts into Service Management Solutions

    For comprehensive monitoring, you can integrate Azure alerts with Service Management platforms like ServiceNow or Microsoft Teams.

    Azure Monitor allows you to create alerts based on various metrics, including cost. When this is integrated with Logic Apps, you can automate workflows to forward these alerts to a Service Management solution.

    An example would be generating an alert when spending hits 75% of the monthly budget. A Logic App workflow is triggered, creating a ServiceNow ticket for review and notifying the relevant team in Microsoft Teams.

    3. Real-Time Cost Alerts with Azure Monitor

    Azure Monitor’s integration with Azure Cost Management lets you create real-time alerts when costs increase unexpectedly. You can set up alerts based on specific metrics or thresholds for VM utilization, storage usage, and other cost-driving metrics.

    An example would be to use Azure Monitor to track VM utilization and generates alerts when the utilization exceeds a set threshold. The alert triggers a workflow to reduce resource allocation, leading to cost savings during non-peak hours.

    Real-World Savings with Azure FinOps

    Lets do a quick recap of some real-world examples where you can leverage Azure FinOps best practices to drive cost savings:

    1. Optimizing VM Costs
      • Challenge: High costs due to underutilized VMs during non-business hours.
      • Solution: Use Azure Advisor to right-size VMs and Azure Automation to shut down non-critical VMs during off-peak hours.
      • Result: In majority of cases, achieve between 20-30% reduction in monthly VM costs.
    2. Using Reserved Instances for Savings
      • Challenge: High costs from on-demand compute resources.
      • Solution: Purchase Azure Reserved Instances to lock in lower rates for long-term workloads.
      • Result: Depending on company size and size of cloud footprint, potential to save tens of thousands on your annual Azure bill by taking advantage of commitment-based discounts.
    3. Enhanced Governance with Azure Policy
      • Challenge: High operational costs and lack of visibility into resource usage.
      • Solution: Implement Azure Policy to enforce tagging and restrict expensive resources.
      • Result: Improved accountability and achieve savings on cloud spend by ensuring only necessary and approved resources were deployed.

    Best Practices

    Lets recap on the best practices for implementing Azure FinOps in your organization:

    1. Enforce Tagging: Use tags to categorize resources by cost center, department, or project, making it easier to track and allocate costs.
    2. Review Usage Regularly: Analyze reports from Azure Cost Management regularly to identify trends and patterns.
    3. Use Automation: Implement automation to shut down or scale down resources during low-usage periods.
    4. Educate Teams: Ensure that Finance, Operations, and Engineering teams understand FinOps principles and tools for more collaborative cost management.

    Conclusion

    Azure FinOps provides powerful tools and practices to optimize cloud spending, maximize efficiency, and achieve financial accountability across departments. Companies can not only achieve significant cost savings but also ensure their cloud environments are scalable, sustainable, and financially efficient.

    By combining Azure Cost Management, Azure Advisor, Reserved Instances, Spot Instances, and Azure Policy, you can effectively control and reduce your company’s Azure expenses. Integrating cost alerts into Service Management solutions allows for proactive cost management, ensuring that cloud spending remains transparent and aligned with organizational budgets.

    Top Highlights from Microsoft Ignite 2024: Key Azure Announcements

    This year, Microsoft Ignite was held in Chigaco for in-person attendees as well as virtually with key sessions live streamed. As usual, the Book of News was released to show the key announcements and you can find that at this link.

    From a personal standpoint, the Book of News was disappointing as at first glance there seemed to be very few key annoucements and enhancements being provided for core Azure Infrastructure and Networking.

    However, there were some really great reveals that were announced at various sessions throughout Ignite, and I’ve picked out some of the ones that impressed me.

    Azure Local

    Azure Stack HCI is no more ….. this is now being renamed to Azure Local. Which makes a lot more sense as Azure managed appliances deployed locally but still managed from Azure via Arc.

    So, its just a rename right? Wrong! The previous iteration was tied to specific hardware that had high costs. Azure Local now brings low spec and low cost options to the table. You can also use Azure Local in disconnected mode.

    More info can be found in this blog post and in this YouTube video.

    Azure Migrate Enhancements

    Azure Migrate is product that has badly needed some improvements and enhancements given the capabilities that some of its competitors in the market offer.

    The arrival of a Business case option enables customers to create a detailed comparison of the Total Cost of Ownership (TCO) for their on-premises estate versus the TCO on Azure, along with a year-on-year cash flow analysis as they transition their workloads to Azure. More details on that here.

    There was also an announcement during the Ignite Session around a tool called “Azure Migrate Explore” which looked like it provides you with a ready-made Business case PPT template generator that can be used to present cases to C-level. Haven’t seen this released yet, but one to look out for.

    Finally, one that may hae been missed a few months ago – given the current need for customers to migrate from VMware on-premises deployments to Azure VMware Solution (which is already built in to Azure Migrate via either Appliance or RVTools import), its good to see that there is a preview feature around a direct path from VMware to Azure Stack HCI (or Azure Local – see above). This is a step forward for customers who need to keep their workloads on-premises for things like Data Residency requirements, while also getting the power of Azure Management. More details on that one here.

    Azure Network Security Perimeter

    I must admit, this one confused me a little bit at first glance but makes sense now.

    Network Security Perimeter allows organizations to define a logical network isolation boundary for PaaS resources (for example, Azure Storage acoount and SQL Database server) that are deployed outside your organization’s virtual networks.

    So, we’re talking about services that are either deployed outside of a VNET (for whatever reason) or are using SKU’s that do not support VNET integration.

    More info can be found here.

    Azure Bastion Premium

    This has been in preview for a while but is now GA – Azure Bastion Premium offers enhanced security features such as private connectivity and graphical recordings of virtual machines connected through Bastion.

    Bastion offers enhanced security features that ensure customer virtual machines are connected securely and to monitor VMs for any anomalies that may arise.

    More info can be found here.

    Security Copilot integration with Azure Firewall

    The intelligence of Security Copilot is being integrated with Azure Firewall, which will help analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions. These capabilities were launched on the Security Copilot portal and now are being integrated even more closely with Azure Firewall.

    The following capabilities can now be queried via the Copilot in Azure experience directly on the Azure portal where customers regularly interact with their Azure Firewalls: 

    • Generate recommendations to secure your environment using Azure Firewall’s IDPS feature
    • Retrieve the top IDPS signature hits for an Azure Firewall 
    • Enrich the threat profile of an IDPS signature beyond log information 
    • Look for a given IDPS signature across your tenant, subscription, or resource group 

    More details on these features can be found here.

    DNSSEC for Azure DNS

    I was surprised by this annoucement – maybe I had assumed it was there as it had been available as an AD DNS feature for quite some time. Good to see that its made it up to Azure.

    Key benefits are:

    • Enhanced Security: DNSSEC helps prevent attackers from manipulating or poisoning DNS responses, ensuring that users are directed to the correct websites. 
    • Data Integrity: By signing DNS data, DNSSEC ensures that the information received from a DNS query has not been altered in transit. 
    • Trust and Authenticity: DNSSEC provides a chain of trust from the root DNS servers down to your domain, verifying the authenticity of DNS data. 

    More info on DNSSEC for Azure DNS can be found here.

    Azure Confidential Clean Rooms

    Some fella called Mark Russinovich was talking about this. And when that man talks, you listen.

    Designed for secure multi-party data collaboration, with Confidential Clean Rooms, you can share privacy sensitive data such as personally identifiable information (PII), protected health information (PHI) and cryptographic secrets confidently, thanks to robust trust guarantees that safeguard your data throughout its lifecycle from other collaborators and from Azure operators.

    This secure data sharing is powered by confidential computing, which protects data in-use by performing computations in hardware-based, attested Trusted Execution Environments (TEEs). These TEEs help prevent unauthorized access or modification of application code and data during use. 

    More info can be found here.

    Azure Extended Zones

    Its good to see this feature going into GA and hopefully will provide a pathway for future AEZ’s in other locations.

    Azure Extended Zones are small-footprint extensions of Azure placed in metros, industry centers, or a specific jurisdiction to serve low latency and data residency workloads. They support virtual machines (VMs), containers, storage, and a selected set of Azure services and can run latency-sensitive and throughput-intensive applications close to end users and within approved data residency boundaries. More details here.

    .NET 9

    Final one and slightly cheating here as this was announced at KubeCon the week before – .NET9 has been announced. Note that this is a STS release with an expiry of May 2026. .NET 8 is the current LTS version with an end-of-support date of November 2026 (details on lifecycles for .NET versions here).

    Link to the full release announcement for .NET 9 (including a link to the KubeCon keynote) can be found here.

    Conclusion

    Its good to see that in the firehose of annoucements around AI and Copilot, there there are still some really good enhancements and improvements coming out for Azure services.