Enterprise-scale on Azure, with a second region that is real.
An enterprise-scale landing zone built for a stealth-mode cybersecurity startup: a management-group hierarchy with policy inherited by every subscription, hub-and-spoke networking with shared firewall and gateways, and a fully paired disaster-recovery region kept warm by continuous replication — with monitoring, SIEM and vaulted backup spanning both.
A landing zone is the shape everything later has to fit.
“Landing zone” sounds like paperwork and is actually the most consequential engineering decision an organisation makes on a cloud platform. It fixes how subscriptions are grouped, what policy they inherit, how networks connect and what a new workload has to do to be allowed to exist. Get it right and teams move quickly inside safe defaults; get it wrong and every subsequent workload negotiates its own exceptions until there is no estate, only a collection of accounts.
Built for a customer whose own product is security.
The bar is higher when the customer sells security. The estate is segmented by management group, governed by inherited policy, connected through an inspected hub, monitored into a SIEM, and replicated to a paired region that is continuously maintained rather than notionally available.
Five decisions, and the reasoning behind each.
Governance is the foundation, not a later project
A management-group hierarchy — platform, identity, management, connectivity and landing zones under a root — is put in first, so policy and cost attribution apply to every subscription created afterwards. Imposing that structure on an estate that already exists is an order of magnitude harder than starting with it.
Hub and spoke, so the network is a policy
Shared services — firewall, gateways and bastion — live in a hub VNet; workloads live in spokes that peer to it. Egress and inspection are therefore properties of the topology rather than of whatever each team configured, and adding a workload does not mean re-litigating the network.
Paired regions, with the second one real
A DR region is only a DR region if it exists before the disaster. West Europe runs active and North Europe is a warm standby with the same shape — hub, spokes, data and platform — kept current by continuous replication rather than assembled from templates during an incident.
Different tiers, different replication
Data and compute do not fail over the same way. Azure SQL uses failover groups, Cosmos DB is configured multi-region, storage is geo-redundant, and compute is replicated with Azure Site Recovery while the Kubernetes cluster is held as a warm standby. Each mechanism matches what it is protecting.
Security operations across both regions
Monitoring, log analytics and SIEM span the regions rather than following the active one, so the security picture does not go dark exactly when a failover has made it most interesting.
Before either region.
| Azure Front Door + WAF | Global entry with web application firewalling ahead of either region. |
|---|---|
| Traffic Manager | DNS-level failover between the paired regions. |
| ExpressRoute / VPN Gateway | Private connectivity into the estate, terminated in the hub of each region. |
The same three layers, in both regions.
West Europe runs as the active region and North Europe as its Azure-paired standby. Both carry an identical structure, which is the property that makes failover credible: recovering into a region that is shaped differently from production is not recovery, it is a migration performed under pressure.
| Layer | Components | Purpose |
|---|---|---|
| Hub VNet | Azure Firewall, VPN / ExpressRoute Gateway, Azure Bastion | Shared network services and controlled administrative access, identical in both regions. |
| Spoke VNet — workloads | Application Gateway + WAF, AKS cluster, VM Scale Set | The workload tier, fronted by a regional web application firewall. The DR region carries the same components with the cluster in warm standby. |
| Data & platform | Azure SQL, Cosmos DB, Storage (GRS), Key Vault | Relational, document, object and secret storage — each with its own cross-region replication mechanism. |
Shared services belong in one place.
Firewall, gateways and bastion sit once in the hub; workload spokes peer to it. Inspection and egress control are therefore structural rather than per-team, administrative access goes through bastion rather than through public addresses on virtual machines, and onboarding a new workload is a peering rather than a network design exercise.
Each tier fails over the way that tier should.
The common mistake in DR design is choosing one replication strategy and applying it to everything. A relational database, a globally distributed document store, object storage and a Kubernetes cluster have genuinely different recovery characteristics, and each is handled with the mechanism built for it.
| Tier | Mechanism |
|---|---|
| Azure SQL | Failover group — the primary replicates continuously to the secondary region, which can be promoted. |
| Cosmos DB | Configured multi-region, so the data is already present in both rather than being shipped at failover time. |
| Storage | Geo-redundant storage, with a replica maintained in the paired region. |
| Compute | Azure Site Recovery replication for virtual machines and scale sets. |
| Kubernetes | AKS maintained as a warm standby in the DR region rather than created on demand. |
| Backup | Azure Backup with vaulted recovery points, held separately from the primary data path. |
| Traffic | Traffic Manager DNS failover, with Front Door in front of both regions globally. |
No recovery-time or recovery-point figures are published for this engagement. Achievable objectives depend on the workload, the data volume, the failover procedure and how often it is rehearsed — a number quoted without those is marketing rather than engineering. What is described above is the set of mechanisms that determine them.
The standby region exists on an ordinary Tuesday.
The DR region is not a set of templates waiting to be applied. Its hub, spokes, data services and Kubernetes cluster are deployed and maintained, with the cluster held warm and the data continuously replicated. That costs more than a cold standby and is the entire reason the failover path is believable — what has never been built has never been tested.
Cross-region by design.
Governance and operations span both regions rather than following whichever is currently active. Policy is inherited down the management-group hierarchy so that compliance is a property of where a subscription sits, monitoring and log analytics aggregate across the estate, and the SIEM sees both regions at once.
| Management groups | Root over platform, identity, management, connectivity and landing-zone groups — the hierarchy that policy and cost attribution hang from. |
|---|---|
| Azure Policy + Blueprints | Guardrails applied by inheritance, so a new subscription is compliant by construction rather than by review. |
| Azure Monitor + Log Analytics | Telemetry and log aggregation spanning both regions. |
| Microsoft Sentinel | SIEM across the estate — a cybersecurity customer’s own platform has to be defensible. |
| Azure Site Recovery | Orchestrated replication and failover for the compute tier. |
| Azure Backup | Vaulted backup, retained independently of the running estate. |
The subscription that has not been created yet.
Policy and blueprints applied at the management-group level mean the next subscription inherits its guardrails on the day it is created, before anyone has deployed anything into it. This is the difference between a governed estate and a governance programme: one is enforced by the platform, the other by a review meeting that happens after the fact.
Delivered for a stealth-mode cybersecurity startup. The customer is not named and no detail beyond the architecture is published. This was a delivered engagement rather than a product.