☁️ Series: AZ-104 → AZ-305 Foundation Module 6 of 6 — Series Complete

"This is where the series comes together. The Well-Architected Framework, HA patterns, architecture design patterns, and cost optimisation are the lenses every AZ-305 scenario question is written through. Learn to see through those lenses and every exam question becomes a design conversation."

The Urban Planner Analogy

🏙️ Analogy A Solutions Architect is like a master urban planner. You do not lay bricks — you design the city. You decide where roads go (networking topology), which zones are residential versus industrial (resource groups and subscriptions), how power and water flow (identity and access), what the flood defences look like (disaster recovery), and whether the city can grow without rebuilding from scratch (scalability). Every decision has tradeoffs between cost, speed, safety, and future flexibility.

The Well-Architected Framework — Your Design Lens

Every AZ-305 scenario question is written through one or more of the five WAF pillars. Learning to identify which pillar a question is testing tells you what the answer should optimise for.

Pillar
Core question
Azure services and patterns
Reliability
Will it keep running when things fail?
Availability Zones, Site Recovery, SQL Geo-Replication, Front Door, VMSS health probes, multi-region deployment
Security
Is it protected at every layer?
Key Vault, Managed Identity, Private Endpoints, NSG, WAF, Defender for Cloud, MFA, Conditional Access
Cost Optimisation
Are we paying for what we actually use?
Reserved Instances, Spot VMs, Auto-shutdown, Lifecycle Policies, right-sizing, Azure Advisor recommendations
Operational Excellence
Can we deploy, monitor, and change safely?
Bicep IaC, CI/CD pipelines, Azure Monitor, Application Insights, deployment slots, runbooks
Performance Efficiency
Does it respond fast enough under load?
Auto-scale (VMSS, App Service), Azure Cache for Redis, Front Door CDN, Cosmos DB multi-region reads, read replicas
🎯 AZ-305 Exam Technique When reading a scenario, identify: which pillar is the PRIMARY constraint? "The company cannot afford downtime" = Reliability. "The company must minimise Azure costs" = Cost Optimisation. "The security team requires no public endpoints" = Security. The primary pillar tells you what to optimise — secondary pillars are constraints you must not violate.

High Availability — The SLA Spectrum

Every HA design has a cost. The architect's job is to match the design to the SLA requirement — not exceed it unnecessarily (wastes money) and not fall short (breaks the SLA agreement).

HIGH AVAILABILITY SLA SPECTRUM

99.9% SLA (3 nines) -- single region, single zone
  Downtime allowed: ~8.7 hours per year
  Design: App Service (single region) + Azure SQL (standard)
  Cost: baseline

99.95% SLA -- single region, redundant instances
  Downtime allowed: ~4.4 hours per year
  Design: App Service (2+ instances) + availability set for VMs
  Cost: +slight (second instance)

99.99% SLA (4 nines) -- multi-zone within region
  Downtime allowed: ~52 minutes per year
  Design: App Service (Zone Redundant) + Azure SQL (Business Critical)
           Resources spread across Availability Zones 1, 2, 3
  Cost: ++significant (Zone Redundant tier is premium)

99.999% SLA (5 nines) -- multi-region active-active
  Downtime allowed: ~5 minutes per year
  Design: Front Door -> App Service (Zone Redundant) in 2 regions
           Azure SQL (Business Critical + Geo-Replication auto-failover)
  Cost: +++expensive (duplicate infrastructure in 2 regions)

AVAILABILITY ZONES:
  Physical separation within one Azure region
  3 zones per region -- each in a different building, power, cooling
  VMs in different AZs survive datacenter-level failure
    
⚠️ Design to the SLA If a customer requires 99.9%, do not design a 99.999% solution — you are spending 3x the budget for an SLA they did not ask for. The exam includes deliberately over-engineered answer choices. Choose the MINIMUM architecture that meets the stated requirement.

Active-Active vs Active-Passive — The Multi-Region Decision

When a workload requires multi-region deployment, the choice between Active-Active and Active-Passive determines both cost and recovery speed.

Dimension
Active-Passive
Active-Active
Traffic
All traffic to primary. Passive waits.
Traffic split across both regions simultaneously
Routing
Traffic Manager (DNS failover) or Front Door (priority routing)
Front Door (performance routing — nearest region)
RTO
Minutes (DNS TTL + health probe detection + warm-up)
Near-zero (Front Door reroutes within seconds)
RPO
Depends on replication lag (ASR: minutes)
Near-zero with synchronous replication (SQL Business Critical)
Cost
Lower — passive region runs minimal capacity
Higher — full capacity in both regions at all times

Architecture Patterns — The AZ-305 Vocabulary

AZ-305 scenario questions map to recognised architecture patterns. Knowing these patterns by name — and when to apply them — is the architect's vocabulary.

Pattern
When to apply
Azure implementation
N-Tier
Classic web application with presentation, application, and data layers
App Service + Azure SQL + separate subnets per tier
Microservices
Independent, separately deployable services; large teams; polyglot architecture
AKS + Service Bus + API Management + separate databases per service
Event-Driven
Loose coupling, async processing, fan-out notifications
Event Hub (stream), Event Grid (reactive), Service Bus (reliable messaging)
CQRS
Read and write workloads have very different scale and model requirements
Write to Azure SQL (normalised); Read from Cosmos DB or Redis Cache (denormalised, fast)
Strangler Fig
Migrate a legacy monolith to cloud incrementally — without a big-bang rewrite
Front Door or API Management as router; new services alongside legacy; gradual traffic shift

Strangler Fig — The AZ-305 Migration Pattern

The Strangler Fig is named after a tropical tree that grows around a host tree, gradually replacing it. Route traffic through a new facade, add new cloud capabilities, and gradually transfer functionality — eventually decommissioning the legacy system without a big-bang cutover.

STRANGLER FIG MIGRATION PATTERN

PHASE 1: Add routing layer (no functionality change)
  Users -> Front Door / API Management -> Legacy system (100% traffic)
  Legacy continues to serve everything. No change visible to users.

PHASE 2: Add new Azure service for ONE feature
  Users -> Front Door -> Route /new-feature -> Azure App Service (new)
                      -> Route /everything-else -> Legacy (still running)

PHASE 3: Gradually expand routing
  Users -> Front Door -> Route /checkout -> Azure (new)
                      -> Route /catalog -> Azure (new)
                      -> Route /account -> Azure (new)
                      -> Route /legacy-reports -> Legacy (shrinking)

PHASE 4: Legacy decommissioned
  Users -> Front Door -> All routes -> Azure services
  Legacy system removed. Migration complete.
  Zero downtime. Fully reversible at each phase.
    
✅ AZ-305 Signal When a scenario says "migrate legacy application with zero downtime" or "incrementally modernise on-premises application" — the answer pattern is Strangler Fig. The exam distinguishes it from "lift-and-shift" (moving legacy as-is to a VM) and "big-bang rewrite" (risky full replacement).

Cost Optimisation — The FinOps Toolkit

Cost optimisation scenarios are common in AZ-305. The exam tests whether you know the specific tools and their appropriate use cases.

Tool
Discount
Condition
Best for
Reserved Instances (1 year)
Up to 40% vs pay-as-you-go
Commit to VM size + region for 1 year
Stable, predictable workloads running 24/7 — production servers, databases
Reserved Instances (3 year)
Up to 72% vs pay-as-you-go
Commit to VM size + region for 3 years
Long-lived stable workloads — data warehouses, ERP systems
Spot VMs
Up to 90% vs pay-as-you-go
Interruptible — Azure can evict with 30-second notice. No SLA.
Batch processing, rendering, CI/CD agents, fault-tolerant distributed jobs
Dev/Test Auto-shutdown
Significant — VMs not running = not billed
Schedule VM shutdown at end of business day
Development and test environments not needed 24/7
Blob Lifecycle Policy
Significant — Archive ~95% cheaper than Hot
Automate tier transitions based on last access time
Aging data: logs, backups, compliance archives
ENTERPRISE REFERENCE ARCHITECTURE -- 3-Tier HA Web Application

                    Internet Users (Global)
                            |
              +-------------+-------------+
              |       Azure Front Door     |
              |   WAF + CDN + Anycast      |
              +-------------|-------------+
                            | (routes to nearest region)
              +----------------------------+
              |  Region A  |  Region B     |
              |  App Service  App Service  |
              |  Zone Redundant (auto-scale 2-10) |
              +-----------+----------------+
                          |
              +-----------+----------+
              |  Azure SQL Business  |
              |  Critical (Primary)  |---> SQL (Secondary) Region B
              |  Auto-failover group |
              +----------------------+
                          |
        +-----------------+-----------------+
        |                 |                 |
  Azure Key Vault   App Insights      Entra ID
  (secrets)         (APM + logs)      (identity)
    

Architect Scenario — Global E-Commerce

A global e-commerce company has users in Europe and Asia. Their requirement: RTO less than 5 minutes and RPO less than 1 minute during a complete regional Azure outage. Their current architecture is a single App Service + Azure SQL in West Europe only. What is the correct redesign?

Show Answer + Reasoning

Active-Active architecture: Azure Front Door + App Service Zone Redundant in 2 regions + Azure SQL Business Critical with Geo-Replication auto-failover group.

Why Active-Active, not Active-Passive? RPO < 1 minute means we cannot afford replication lag. Azure Site Recovery (Active-Passive) has RPO of minutes — not guaranteed sub-1-minute. RTO < 5 minutes means we cannot wait for DNS TTL to propagate (Traffic Manager failover typically takes 2-6 minutes including DNS caching). Front Door detects failure in seconds and reroutes — meeting the 5-minute RTO.

Why the current single-region architecture fails: A regional outage takes the entire application offline. RTO = hours to days (Azure region restoration or manual recreation). RPO = all data since last backup. Neither meets the requirement.

Complete redesign:

  • Azure Front Door (WAF + performance routing): routes European users to West Europe, Asian users to Southeast Asia. On failure: reroutes within seconds.
  • App Service (Zone Redundant) in West Europe + Southeast Asia: both serving live traffic at all times.
  • Azure SQL Business Critical in West Europe (primary) with Geo-Replication auto-failover group to Southeast Asia: auto-failover triggers when primary is unreachable — application continues writing to secondary, which becomes new primary.
  • Key Vault in each region: each App Service accesses its regional Key Vault.

🎯 Final Series Quiz — Module 6

Q1: A company plans to auto-scale their App Service based on CPU usage. Which Well-Architected Framework pillar does this primarily address?

Show Answer

Performance Efficiency. Auto-scaling ensures the application has enough compute capacity to handle load efficiently — matching resource supply to demand. It also touches Cost Optimisation (scale down when load is low = pay less) and Reliability (more instances = fewer individual failures causing downtime), but the PRIMARY pillar is Performance Efficiency — the application must perform adequately under variable load. When you see "handle peak traffic" or "respond quickly under load" in a scenario, that is a Performance Efficiency signal.

Q2: What is the Strangler Fig pattern and when does AZ-305 expect you to recommend it?

Show Answer

The Strangler Fig pattern migrates a legacy monolith to cloud services incrementally — without a big-bang rewrite. A routing layer (Front Door or API Management) is placed in front of the legacy system. New cloud services are built for specific features and traffic is gradually redirected. The legacy system shrinks as each feature migrates until it is decommissioned entirely. Recommend it when: a scenario describes a legacy application needing modernisation but the company cannot afford downtime or a full rewrite; OR when the scenario mentions "incremental migration", "zero-downtime modernisation", "move to cloud without disrupting users". It is the safe migration pattern — each step is independently reversible.

Q3: A company runs a stable, predictable data analytics workload on 20 Azure VMs, 24 hours a day, 7 days a week, with no expected changes for the next 3 years. What is the most cost-effective pricing option?

Show Answer

3-Year Reserved Instances — up to 72% discount versus pay-as-you-go. The signals are: stable (no need for flexibility), predictable (known size and region), 24/7 (VMs running continuously — full discount benefit), and 3-year horizon (long enough to commit). Spot VMs (90% discount) are not appropriate — they can be evicted with 30 seconds notice, unacceptable for a continuous analytics workload that cannot tolerate interruption. 1-year Reserved Instances give less discount (40%) for the same commitment risk when the 3-year horizon is already confirmed.

Series Complete — The Complete AZ-305 Foundation

  • WAF pillars are the AZ-305 design lenses: identify the primary pillar in each scenario, optimise for that pillar without violating the others
  • HA spectrum: 99.9% (single region) to 99.99% (Availability Zones) to 99.999% (Active-Active multi-region) — design to the stated SLA, not beyond it
  • Active-Active (Front Door) for near-zero RTO/RPO; Active-Passive (ASR/Traffic Manager) for moderate RTO/RPO at lower cost
  • Strangler Fig = the safe incremental migration pattern for legacy modernisation — never big-bang rewrite when Strangler Fig is an option
  • Cost optimisation: Reserved Instances for stable 24/7 workloads, Spot VMs for interruptible batch, auto-shutdown for dev/test, Lifecycle Policies for aging data
  • You have now covered the complete AZ-104 to AZ-305 gap: Identity, Services, Networking, IaC, Monitoring, Design Thinking