Banking · Azure · Landing zone
A governed Azure foundation a bank could build on
We designed and built an Azure landing zone for a bank: governance, hub-and-spoke networking, security policy and Terraform-delivered infrastructure.
Client context
Who this was for
The client is a bank moving workloads to Microsoft Azure, with an adoption programme that was running ahead of the governance meant to support it. The brief was a tailored Azure environment aligned with the organisation's needs and with established practice: a secure, compliant and efficient foundation for diverse workloads, and a framework for deploying, managing and governing resources consistently across the enterprise.
Banking estates are audited estates, and that changes what a foundation has to be. Working infrastructure is not enough. Its structure, controls and change history have to be explainable to people whose job is to find the gaps, and every later workload has to inherit those answers rather than reinvent them project by project.
Engagement scope
What the engagement covered
- A tailored Azure cloud environment aligned with organisational needs and established industry practice
- A secure, compliant and efficient infrastructure to support diverse workloads and applications
- A framework for consistent resource deployment, management and governance across the enterprise
Challenge
The decision they faced
Without a landing pattern, every workload negotiates its own networking, identity, policy and tagging. Each team's choices are defensible on their own and, taken together, very hard to govern: address spaces overlap, firewall rules drift, and cost cannot be traced back to an owner. In a regulated bank, each of those becomes an audit finding rather than an inconvenience.
The harder problem was evidence. Answering which subscriptions enforce a given control had become an investigation rather than a query. The decision the client faced was whether to keep paying that cost on every project, or to define the foundation once, in code, and make every subsequent workload inherit it by default.
Solution architecture
How the platform fits together
The foundation follows the Microsoft Cloud Adoption Framework enterprise-scale reference architecture: platform management groups for management, identity and connectivity, landing zone management groups for corporate and online workloads, and separate areas for decommissioned and sandbox subscriptions. Policy assignments and role entitlements are applied at the management group level, so a new subscription inherits its controls the moment it is placed, not when someone remembers to configure it.
Shared network services sit in a connectivity subscription. Its hub virtual network in Region 1 holds Azure Firewall, the ExpressRoute and VPN gateways for on-premises connectivity, Azure DDoS Protection, Azure DNS and the Azure DNS Private Resolver. Centralising these means inspection, name resolution and hybrid routing are owned in one place, and a workload team never has to operate a firewall to get a secure path out.
Each landing zone subscription connects to the hub through virtual network peering. Its virtual network carries DNS settings, user-defined routes (UDRs) that send traffic through Azure Firewall, and network and application security groups (NSGs and ASGs). Resource groups hold the application tier: a load balancer in front of virtual machines and a database, with Azure Key Vault, a file share and recovery. Applications, Azure portal dashboards, Recovery Services vaults and shared services complete the subscription.
Both subscriptions carry the same baseline of role entitlement, policy assignment, Network Watcher and Microsoft Defender for Cloud, so monitoring and posture management do not depend on the workload. Virtual machines are built from compliant templates that fix the VM SKUs, access credentials, in-guest policies and Desired State Configuration (DSC), backup policy, extensions and tagging, which makes the compliant configuration the default one.
Figure 1 — Hub-and-spoke interconnection between the connectivity subscription and an application landing zone, including the compliant VM template baseline every workload inherits.
Open full-size image: Figure 1 — Hub-and-spoke interconnection between the connectivity subscription and an application landing zone, including the compliant VM template baseline every workload inherits.
Approach
What we did
01
Governance model and resource organisation
We defined the organisational structure and governance model first, because every later decision depends on who owns what. We designed resource organisation across management groups and subscriptions, following the Cloud Adoption Framework hierarchy, and set naming and tagging conventions so that ownership and cost are attributable by construction. Cost management and budgeting were planned against the same hierarchy, so budgets follow the management groups rather than a spreadsheet.
02
Network topology and connectivity
We designed a hub-and-spoke topology with shared services in a connectivity subscription and workloads in peered landing zone networks. Each spoke received user-defined routes that force traffic through Azure Firewall, and security groups at the subnet boundary. ExpressRoute and VPN gateways in the hub give every workload one documented route to on-premises systems, instead of a connectivity arrangement negotiated project by project.
03
Security controls and policies
We designed the security controls and policies while the architecture was still open, which is when a control is a design decision rather than a migration. Policy assignments and role entitlements sit on the management group hierarchy, Microsoft Defender for Cloud and Network Watcher are enabled in every subscription, secrets live in Azure Key Vault, and Azure DDoS Protection covers the hub network.
04
Continuity and compliant workloads
We designed disaster recovery and business continuity into the topology rather than appending them as procedure. Recovery Services vaults and backup policy are part of the landing zone itself, and the compliant VM templates carry backup, extensions, in-guest policies and tagging, so a new virtual machine arrives recoverable and governed without a separate onboarding step for each application team.
05
Infrastructure as code and implementation
We prepared the infrastructure-as-code templates in Terraform, stored them in Azure Repos and set up the DevOps process that deploys them through Azure DevOps Pipelines. The landing zone was then implemented from those templates, so the platform that audit reviews is the platform the code describes, and a change to a control goes through the same pipeline rather than a manual edit in the portal.
Outcome
What changed
We delivered a scalable, secure and efficient Azure landing zone that accelerated the bank's cloud adoption. Application teams deploy into subscriptions that already carry networking, policy, monitoring and backup, which enabled rapid application deployment without a separate foundation project for each new workload.
Because controls are defined once in code and inherited through the management group hierarchy, the foundation supported the bank’s regulatory compliance with a structure that can be explained and evidenced. It also gave the organisation a platform for future growth: new workloads extend the landing zone pattern rather than starting another one.
Technology stack
What it was built with
- Cloud
- Microsoft Azure
- Networking
- Azure FirewallExpressRouteAzure DNS Private ResolverAzure DDoS Protection
- Security and operations
- Microsoft Defender for CloudAzure Key VaultNetwork WatcherRecovery Services vaults
- Infrastructure as code
- Terraform
- CI/CD
- Azure DevOps Pipelines
- Source control
- Azure Repos
Architecture gallery
Supporting diagrams
Figure 2 — Microsoft Cloud Adoption Framework enterprise-scale reference architecture that the implementation followed. “Contoso” is Microsoft’s sample organisation name, not the client.
Source: Microsoft Cloud Adoption Framework (opens in a new tab)
Open full-size image: Figure 2 — Microsoft Cloud Adoption Framework enterprise-scale reference architecture that the implementation followed. “Contoso” is Microsoft’s sample organisation name, not the client.
Figure 3 — Microsoft Cloud Adoption Framework network reference architecture that the implementation followed. “Adventure Works” is Microsoft’s sample organisation name, not the client.
Source: Microsoft Cloud Adoption Framework (opens in a new tab)
Open full-size image: Figure 3 — Microsoft Cloud Adoption Framework network reference architecture that the implementation followed. “Adventure Works” is Microsoft’s sample organisation name, not the client.
Lessons learned
What we would carry forward
- Placing policy assignments at the management group level decides most governance arguments in advance. A new subscription inherits its controls, including Microsoft Defender for Cloud, the moment it is placed in the hierarchy, so a request for an exception becomes a question about where that subscription belongs, which is far easier to settle and to audit.
- Centralising Azure Firewall and the ExpressRoute gateway in the hub makes user-defined routes the most important artefact in each spoke. We treat route tables as part of the landing zone template rather than per-workload configuration, because one missing route silently bypasses inspection.
- Keeping the Terraform templates as the only way to change the platform matters more than any individual control. When Azure DevOps Pipelines is the sole path to production, drift between the documented design and the running estate stops being something to discover and becomes something the pipeline prevents.
More case studies
Other programmes
Omnichannel banking on Microsoft Azure, private by default
An omnichannel banking platform on Azure: one controlled edge for every channel, workloads on AKS, and data services reached only through private endpoints.
We delivered a scalable, secure and efficient application architecture on Microsoft Azure. Every channel enters through one controlled edge and every data service is reachable only through a private endpoint,…
- Azure
- AKS
- Front Door
- Keycloak
Security gates inside every pipeline, not after them
A DevSecOps delivery platform with GitLab, Jenkins and Argo CD on GKE, where every quality and security check is a pipeline gate owned by a named team.
The platform is designed to let teams release more often without letting security and quality review fall behind. Because checks run inside the pipeline and every failure reaches its owner…
- Jenkins
- Argo CD
- GKE
- GitLab
Next step
Start from the platform you have today
Tell us what you run, what is holding back the next release or workload, and who owns it. An engineer replies with questions and a proposed first step.