Azure Architecture: Landing Zones, Resilience, and Recovery

Establish the Platform Boundary

Azure architecture translates workload requirements into decisions about governance, identity, networking, availability, data, operations, security, and cost.

Landing zones establish management groups, subscriptions, policies, identity, connectivity, and monitoring so application teams inherit a usable platform rather than inventing foundations repeatedly.

The Azure Well-Architected Framework provides review perspectives, but workload-specific recovery targets, failure tests, and trade-offs remain the real design evidence.

Decide how management groups, subscriptions, policies, identities, and shared services separate environments and responsibilities. Keep platform administration distinct from application deployment.

Use subscriptions to limit blast radius and clarify ownership.
Apply policy inheritance deliberately.
Define shared DNS, connectivity, logging, and security services.

Design for Failure

Record availability targets, recovery time, recovery point, regional requirements, and dependency limits. Select zones, redundancy, queues, replicas, and secondary Regions from those targets.

Test zone and dependency failures separately.
Avoid making every service multi-region without a justified requirement.
Plan how traffic and data fail over together.

Choose Network and Data Patterns

Hub-spoke, Virtual WAN, private endpoints, and centralized inspection solve different connectivity needs. Data architecture should follow access patterns, consistency, residency, and recovery needs.

Prevent address overlap before connecting networks.
Document DNS ownership for private endpoints and hybrid systems.
Treat replication and backup as different protections.

Operate and Revisit Decisions

Architecture includes deployment, observability, quotas, incident response, cost allocation, and decommissioning. Record major decisions and revisit them as traffic, team capability, and requirements change.

Load test scaling and quota assumptions.
Measure the operational value of managed services.
Review architecture after incidents and major releases.

Workload Requirements

Translate business goals into users, critical flows, peak and growth, latency, availability, consistency, RTO, RPO, data classification, residency, deployment frequency, team skill, and budget. Mark assumptions and tests. Without measurable requirements, architecture becomes a collection of preferred Azure services.

Azure Well-Architected uses five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. Review trade-offs across all five. A private multi-region design may improve resilience and security while increasing latency, operational burden, and cost.

Separate platform requirements from workload requirements. A landing zone supplies subscription, identity, Policy, network, monitoring, and automation guardrails; the application team still designs request flow, data, scaling, release, and recovery inside those boundaries.

Define critical flows and measurable objectives.
Record unknown assumptions and tests.
Review trade-offs across all five pillars.
Distinguish landing-zone controls from workload design.

Failure Domains and Landing Zones

Map tenant, management group, subscription, Region, Availability Zone, scale unit, subnet, cluster, partition, and external-provider failure domains. Zone-redundant compute does not make a workload resilient when DNS, egress, database, Key Vault, deployment, or identity remains one shared dependency.

Use subscriptions and deployment scope to contain administrative mistakes, zones for datacenter failure, and cells or stamps when one tenant or partition should not consume the whole service. Multi-region architecture adds routing, replicated data, consistency, key, deployment, and failback complexity and should follow a real regional-outage requirement.

Test zonal loss, regional dependency failure, quota exhaustion, and a broad Policy or role mistake. Controlled degradation may be more achievable than full active-active availability. Document what the user sees and what operations remain possible in each failure.

Find shared dependencies behind redundant icons.
Choose each isolation layer from a failure objective.
Limit tenant and deployment blast radius.
Test governance failure as well as resource failure.

Request and Event Boundaries

A synchronous path couples user latency and availability to every dependency it calls. Keep the critical path small, set deadlines from the outside inward, retry only transient idempotent work with jitter, and stop within a budget. Layered unbounded retries can turn one slow dependency into fleet exhaustion.

Service Bus, Event Grid, Event Hubs, Storage queues, and other messaging services have different delivery, ordering, partition, replay, and failure models. Define schema version, duplicate handling, maximum age, poison destination, ownership, and user status before selecting one. Event driven does not mean failure free.

Apply backpressure with queue limits, concurrency, rate limiting, circuit behavior, and load shedding. A growing queue is useful only if the backlog can be processed within the business objective. Test dependency slowdown and recovery, not only complete stop.

Keep synchronous dependency chains short.
Bound timeout, retry, and concurrency.
Select messaging from its delivery contract.
Design overload behavior before launch.

Data Authority and Recovery

Name the system of record and transaction boundary for each business fact. Replicas, caches, search indexes, and analytical copies need freshness, rebuild, and reconciliation rules. State which consistency a user observes after write and how conflict is resolved during multi-region operation.

Availability replication can copy logical deletion or corruption. Point-in-time restore, backup, soft delete, versioning, immutable retention, and isolated copies protect different failures. Map each dataset to RPO, RTO, key ownership, restore owner, and validation steps.

Exercise zone failover, regional routing change, encrypted restore, and failback. Verify identity, private DNS, network, schema, data integrity, and real application read/write. A recovered resource is not a recovered workload until the critical flow works.

Name one authoritative write path.
Document replica and cache freshness.
Match recovery controls to distinct failure modes.
Test restore through the user flow.

Performance and Cost Envelope

Model arrival rate, concurrency, payload, compute, memory, storage, connection, network, request-unit, and downstream demand for the busiest flow. Load-test representative distributions and failure. Average utilization can hide hot partitions, burst, tail latency, queue age, and per-instance limits.

Azure quotas, regional SKU capacity, subnet addresses, SNAT ports, database connections, Cosmos throughput, Key Vault operations, and external APIs can constrain scaling first. Monitor quota usage and request increases before launch. Autoscaling reacts after a signal and must include startup and warm-up time.

Compare managed service cost with the operations it removes and track cost per successful business unit. Preserve security and recovery headroom while eliminating unnecessary processing, retained data, transfer, and idle capacity. Performance tuning that increases failure risk is not efficient architecture.

Load-test tail behavior and dependency slowdown.
Treat quotas as architectural limits.
Include warm-up in scaling design.
Measure cost per useful outcome.

Architecture Evolution

Architecture includes Bicep, deployment, observability, support, security response, backup, cost allocation, and decommissioning. A component the team cannot release, diagnose, patch, or restore within the target is not ready merely because its diagram is elegant.

Capture consequential choices in architecture decision records with context, options, decision, consequences, owner, and review trigger. Revisit them when traffic, regulation, team skill, price, service support, or Azure capability changes. Avoid undocumented portal drift and avoid needless redesign without evidence.

Run Well-Architected reviews and game days against the highest risks. Trace one business operation, then remove a zone, slow the database, deny Key Vault access, exhaust a quota, and deploy incompatible code. Turn the most important findings into owned tests or controls and remove obsolete resources, routes, roles, data, flags, and compatibility paths.

Design operations with the data path.
Record decisions and review triggers.
Validate architecture through game days.
Plan resource and data decommissioning.

Expense Workflow Review

Trace one employee expense from Entra sign-in through Front Door or Application Gateway, application compute, receipt storage, Azure SQL transaction, approval event, notification worker, audit log, and reporting copy. At every hop, state the identity, timeout, retry, idempotency key, data classification, telemetry, and user-visible response. This reveals where one business operation crosses several technical owners.

Remove one Availability Zone and then slow the database without taking it offline. Confirm whether health probes, autoscale, connection pools, queue backlog, and alert routing preserve service or amplify the failure. Next deny the applications managed identity at Key Vault and exhaust a regional quota. Separate safe degradation from behavior that risks duplicate reimbursement or lost audit data.

Deploy a revision that writes a new schema and then roll the application back. Restore a receipt version and a point-in-time database into an isolated recovery environment, reconnect private DNS and identity, and process one approval. Compare the measured recovery and possible data loss with RTO and RPO.

Finish with a small ranked list of changes supported by evidence: perhaps a missing dead-letter owner, shared egress path, unsafe retry, untested key recovery, broad deployment role, or unaffordable log query. Give each item a verification test and owner. The review is successful when it changes operational confidence, not when it produces a larger diagram.

Follow one business operation across every Azure boundary.
Inject location, identity, quota, data, and release failures.
Measure user impact and recovery against requirements.
Turn findings into owned verification tests.

Architecture Review Examples

Azure architecture Bicep layout example

This tiny Bicep sketch shows a common beginner architecture shape: one plan and one web app defined as code so the system can be recreated consistently.

Azure architecture Bicep layout example

param location string = 'eastus'

resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: 'plan-web-prod'
  location: location
  sku: {
    name: 'B1'
    tier: 'Basic'
  }
}

resource app 'Microsoft.Web/sites@2023-12-01' = {
  name: 'app-web-prod'
  location: location
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
  }
}

Architecture becomes maintainable when the resource layout is reproducible.
Even a small Bicep file teaches naming, dependencies, and platform boundaries.

Choose a Regional Recovery Pattern

A customer portal requires regional recovery but cannot accept conflicting order writes.

Choose a Regional Recovery Pattern

Constraints: Read traffic may be stale briefly; order writes need one authority; failover is operator-controlled.
Decision: Use active-active stateless front ends with a single writable data region and a rehearsed promotion path for the secondary.
Verification: A regional exercise meets recovery objectives and no order identifier is committed twice.
Failure test: Delay replication during failover and confirm the runbook pauses writes until the recovery point is understood.

Output

Expected evidence: A regional exercise meets recovery objectives and no order identifier is committed twice.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on