Building Azure Landing Zones with Pulumi

What I inherited

When I started the Azure landing-zone work, the subscriptions existed, along with a few resources created by an inherited Pulumi prototype. Those resources also needed recreation. The prototype appeared to have been generated from a generic infrastructure tutorial. It outlined some of the intended resources, but its structure was poor, it did not deploy reliably, and it did not fit the platform we needed.

I kept the intended resource list as input and rewrote the implementation. That decision let me rebuild the prototype’s partial resources without carrying its unsuitable code structure into the new foundation.

Rebuilding the foundation while development kept moving

Developers kept working through the landing-zone rebuild. Their day-to-day tasks did not stop while I replaced the infrastructure underneath them. I built the first usable development environment, then extended the same foundation to staging and production without making infrastructure changes a new project for the product teams.

It felt like changing the wheels on a moving vehicle: product work continued along the same road while I rebuilt the infrastructure carrying it. Developers kept their normal workflows and releases; they did not need to pause feature work for the foundation to change. I delivered the development environment first, then extended it to staging and production.

Building the foundation

I built the infrastructure across the existing subscriptions:

virtual networks, peering, VPN gateways, private connections, and DNS for shared and workload connectivity
identity, role assignments, Azure Policy governance, monitoring, and security controls
AKS clusters, PostgreSQL databases, Redis caches, and storage accounts for applications
Pulumi programs and stacks that separated foundational resources from later platform layers

These layers had to work together before developers could deploy: network connectivity and private DNS, access controls, AKS, and the data services their applications needed.

Development in 10 days; staging and production next

In 10 days, developers had a usable environment for their work and application deployments. I then built staging and production on the same foundation and continued hardening it.

This sequence made development available early while the larger Azure landing-zone build continued. Later, Azure became the network hub for the on-premises laboratory, GCP, and AWS.

What lasted

The Azure landing zones became the starting point for the later platform: Kubernetes clusters, shared services, developer tooling, and eventually additional cloud providers. As the footprint grew, each provider gained its own infrastructure code, while Azure remained the network hub.

Part of: Building Azure Landing Zones, Then Expanding Across Clouds

Related work: