Conference opener. The original blueprint title slide follows unchanged.

The five pillars are lenses for decisions, not five independent scores to maximize. This first refresh introduces a retail checkout workload in the WAF section and uses it again for the reliability sequence and the retail discussion.

Legacy contact: Twitter https://twitter.com/Chris_L_Ayers. Keep the retired, struck-through link off the projected slide.

Introduce the architect's toolkit before applying WAF. The following roadmap names the habits; the supporting slides follow those same three groups.

Start with business requirements, then apply a decision framework, design patterns, forward thinking, supportability, continuous learning, collaboration, and a methodical approach. These are grouped here as strategic, operational, and collaborative habits rather than a numbered checklist. Architecture is a team sport played with strategic thinking.

Source: https://learn.microsoft.com/en-us/azure/well-architected/architect-role/fundamentals Include recovery, security, and compliance in the design rather than retrofitting. A workload can include AI models. Bring build, run, secure, and recover perspectives. Maintain an ADR log for architecturally significant choices, including rejected options. A proof of concept is often abbreviated PoC; a key performance indicator (KPI) is a measure of progress toward a business objective.

Capture stakeholder requests and their assumptions; probe the real motivation. Clarify requirements per flow. Evaluate feasibility, constraints, and cross-pillar tradeoffs. Recommend with rationale, proof-of-concept results, and business measures ready for an ADR. Repeat discovery after a major change in direction. The next two slides make requirements concrete with service and recovery targets.

These numbers are illustrative, not WAF defaults. A request-based availability budget counts failed eligible requests; do not convert it directly into downtime. An SLO is an internal target, not automatically a contractual service-level agreement. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics

Examples are hypothetical and separate: a 30-minute RTO does not imply a 5-minute RPO, and neither follows from the 99.9% SLO on the preceding slide. Disaster recovery (DR) restores service after a major disruption. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery The native SVG uses blueprint dimension lines. Entering the slide traces the backward data-loss bound, then the forward recovery bound; the full timeline is always visible. Revisit the slide to replay. Presenter previews remain static.

The decision framework is HOW; business alignment is WHY. Apply the requirements established earlier, then capture the chosen tradeoff in an ADR. Record the decision and alternatives; revisit the ADR when evidence changes.

Other patterns: cache-aside, bulkhead, valet key, claim-check, event-driven designs. Specialist workloads may need high-performance computing or AI inference with retrieval-augmented generation (RAG: retrieve relevant content before generation). Watch data residency, preview risk, model retraining, and model drift. Source: https://learn.microsoft.com/en-us/azure/architecture/patterns/

Azure services differ in regional and zonal support. Zones contain one or more datacenters and are physically separated within a region. A region's zones are not separate regions; regional outages and dependency failures need their own recovery analysis. Do not assume a paired region implies automatic recovery. Source: https://learn.microsoft.com/en-us/azure/reliability/regions-overview Source: https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview

Consolidates the second pass through the fundamentals; the first pass stays in the preceding slides. An ADR also records status, alternatives, rejected options, reversibility, ownership, and when to revisit the choice. Capture it before code, assess one-way versus two-way doors, and review it after implementation. The previous healthcare ADR assumed 99.99% availability implied active-active across three regions and a 3x infrastructure bill. Neither follows universally; the replacement is an explicit, testable example rather than a default topology. Supporting pattern catalog: circuit breaker, bulkhead, retry with backoff, cache-aside, CQRS, event sourcing, valet key, gatekeeper, federated identity, event-driven systems, service mesh, and edge computing. These solve different problems; select against requirements rather than adopting a catalog. Source: https://learn.microsoft.com/en-us/azure/architecture/patterns/ Forward scan: growth thresholds, regional expansion, compliance, preview risk, fallbacks, single points of failure, coupling, and deprecations. The previous Netflix migration claim was unsourced and is not retained as a factual example.

This supports both Operational roadmap bullets: design for support and keep learning. The former growth loop was Learn → apply → codify. Golden signals track latency, traffic, errors, and saturation. Synthetic tests simulate user journeys. Use consistent telemetry schemas and clear error contracts. External specialists can expose assumptions the workload team has missed. Instrument the checkout SLO, run a timed recovery drill, and compare the result with RTO and RPO. Use a proof of concept for uncertain behavior before adoption. Telemetry comprises logs, metrics, and traces. A correlation ID is a shared identifier linking events for one request. A runbook provides tested steps for an operational task or incident. Test risky assumptions, review incidents with the owner, share the results, and update the ADR and runbook.

The shared learning loop is Learn → apply → measure → share. Supporting detail from the consolidated fundamentals: Instrument, collect, analyze, visualize. Use structured logs and tiered retention; connect hot/warm/cold analysis to health and business KPIs. DLQs, graceful degradation, clear error contracts, runbook automation, and ChatOps support recovery. Measure MTTR against your own baseline; the former ~75% improvement claim had no specific supporting source and is not presented as an expected outcome. Continuous development: role-relevant Microsoft Learn paths, FinOps/MLOps, architecture katas, open source, hackathons, AI-assisted reviews/documentation, meetups, architecture forums, and conference participation. Choose current certification paths rather than treating a dated exam list as enduring guidance. External collaborators include cloud solution architects, partner specialists, and community experts. Useful shared artifacts: design reviews, failure scenarios, cost workshops, and a pattern/ADR library. Tools can include Visio/draw.io/Lucidchart/C4, wiki/Backstage, WAF Review/Advisor, and chaos/load testing. The method and evidence matter more than the tool brand.

This supports the second Collaborative roadmap bullet: use a repeatable method. Each step leaves an artifact another team member can inspect: requirements, alternatives, an ADR, test results, and the next review trigger. The former improvement loop was Assess → Prioritize → Implement → Validate → Instrument → Reassess. Preserve measurement throughout, not only after validation. Pillar-specific checklists and maturity baselines belong to the WAF application that follows. This working loop is the talk's method, not an official WAF sequence.

This is the boundary between the architect's general toolkit and its application through Azure WAF. The five-pillar map follows on the next slide.

Sources: https://learn.microsoft.com/en-us/azure/well-architected/ https://learn.microsoft.com/en-us/azure/well-architected/what-is-well-architected-framework The original five-pillar illustration remains at img/waf.png as a reference asset. The pillar names are the framework's; the following intent summaries are this talk's. Reliability: stay available and recover within targets. Security: verify access and limit the impact of a breach. Cost: know unit cost and spend intentionally. Operations: observe, automate, learn. Performance: test the slowest requests and scale. The native hub makes the shared workload explicit. Slide entry traces the five lenses once, without hiding labels or implying that one pillar is optional.

Framework goals include resilience, proactive security, cost efficiency, innovation, operational excellence, and predictable performance. The framework guides decisions; using it does not guarantee an outcome.

The former slide listed 304% ROI (Forrester TEI, Microsoft-commissioned), 40% less downtime (Global Retailer), 25% cost savings (Financial Services), 75% faster server updates (Manufacturing), and a 93/100 security score (Profisee). It did not identify the study URL, case-study URLs, dates, populations, or measurement methods. These figures are retained here for source follow-up, not presented as verified outcomes or promises for the audience's workload.

Each pillar has a tradeoffs page on Microsoft Learn. Evaluate the same workload across all five; reliability can expand attack surface, security affects operability, and tooling has a cost. Assessment is ongoing, not a one-time audit.

Assess user and system flows before redundancy spending. Failure mode analysis is abbreviated FMA. Distinguish failures requiring intervention from expected errors. Analyze read and write failures separately: their impacts and recovery paths differ. Engineer reliability across code, infrastructure, and operations.

Choose zonal or regional redundancy against failure modes and recovery targets, not as an automatic tier rule. Long-running work can need checkpoints. Service Bus PeekLock and duplicate detection support message handling, but do not alone guarantee end-to-end idempotency. Separate read/write recovery; secondary Blob reads are not write failover. Use supported client-library transient-fault handling, and isolate connection pools to prevent cascading failures. Fault injection tests graceful degradation as well as availability. Bounded retries have limits and delays. A dead-letter queue holds unprocessable messages for investigation; it is not automatic recovery. Isolate dependencies and test their failures. A stable key alone does not provide idempotency: atomically enforce it with the effect, and handle duplicates at every boundary.

Feed probes and synthetic journeys into a flow-level health model. Schedule end-to-end runbook and restore exercises at a risk-appropriate cadence; quarterly was the original example, not a universal requirement. Automate failover validation in delivery pipelines. Turn Azure Advisor findings into owned backlog actions. Scheduled fault injection and anomaly detection can inform bounded recovery automation.

Track detection/recovery trends, timed restore success, and failure-exercise coverage. The former 99.9% success, 20% budget burn, 99% drill success, and quarterly Tier-0 coverage figures were example targets, not Microsoft-prescribed thresholds. MTTR is ambiguous across teams (repair, recovery, or resolution); state the exact start/end events rather than using it without a definition.

Advance once after asking the room to predict the surviving load. Each slide is a complete state. Stable view-transition names let Marp morph the same cards without a custom runtime, timers, or hidden essential content. Three zones each have capacity C; total demand is 3 x 0.70C = 2.10C. This isolates stateless compute with evenly distributed, linearly scalable work. It does not model data replication, queue semantics, retries, routing delay, payment consistency, or other dependencies; those require their own tests. The former architecture image remains at img/resilient.png. Its regional standby, geo-replicated data, and DLQ ideas apply only to the failure modes they address; a paired region or redundant compute alone is not a complete recovery design. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/capacity-resilience

Demand remains 2.10C. Two survivors have 2C total capacity, so each would need 1.05C. Required utilization above 100% describes unmet demand, not a measured CPU value above its physical limit. Routing away from the failed zone does not create capacity; retries may make the problem worse and are excluded here. Ask: can we allocate more during an incident? Quota is necessary but not a guarantee of physical capacity. Do not make recovery depend on an untested scale-out. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/capacity-resilience

This is a redesign and a new experiment, not the next instant of the incident. Business demand is unchanged. Increase capacity in every zone from C to 7C/6 (about 16.7% more) BEFORE the failure, so 2.10C / (3 x 7C/6) = 60% normally and 2.10C / (2 x 7C/6) = 90% after one zone fails. The percentages use the new, larger per-zone capacity as the denominator. This does not imply a proportional Azure bill or guarantee an SLO: latency, throughput, data behavior, dependency quotas, routing, and cost must be measured. Alternatives include bounded admission, degradation of noncritical flows, and other deployment shapes; none removes the need to define the business promise. Rewind to compare the designs. PDF, reduced-motion, and no-JS views retain all labels, equations, and outcomes without relying on the transition. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/capacity-resilience

The September 2026 design guide distinguishes quota from physical supply. Allocation constraints can be regional, zonal, SKU/family-specific, or related to cluster placement and managed-service dependencies. Consider compatible deployment shapes, zone/region options subject to residency and latency, and capacity reservations where supported and justified. Reservations are not the same as pricing commitments. Capacity planning is ongoing operational work.

This talk's discussion ladder, not a certification scale. Original progression: ad hoc manual recovery; baseline failover documentation and probes; structured runbooks/SLOs/fault injection; proactive automated failover and shared failure libraries; adaptive self-healing and novel-failure rehearsal. Automated pipeline tests, restore cadence, dashboards, and anomaly triage are possible accelerators. Remove unknowns, speed detection, then widen safe automation.

Risks: L1 False recoverability; L2 Late backup corruption detection; L3 Hidden SPOF; L4 Design vs reality drift; L5 Slow novel failure detection.

Supporting signals: critical-flow availability, error budget use, restore success. Use health models, synthetic probes, replication, and backups where justified. A tabletop can identify an unknown, but is not a substitute for a real restore.

Verify human and workload identities; encrypt data in transit and at rest according to classification. STRIDE is one threat-model method: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Assign each threat a control, owner, and timeline. Prefer managed identities and time-limited elevation over embedded secrets and permanent administrator roles.

Use Conditional Access where applicable, managed identities, network segmentation, private endpoints, web application firewalls, and denial-of-service protection. WAF also abbreviates web application firewall; spell it out to avoid confusion with the Well-Architected Framework. CMK means customer-managed key; choose key ownership against explicit requirements rather than all regulated data by default. Defender for Cloud and Sentinel support detection and response. Rehearse tabletop, red-team (simulated attackers), and purple-team (joint attack/defense learning) drills.

SE:02: isolated workspaces (Dev Box/Codespaces), maintained base images, security editor tooling, credential managers, and default-deny code. SAST is static application security testing; DAST tests a running application. Scan supply chains. CVE means Common Vulnerabilities and Exposures, identifiers for known vulnerabilities. For AI, address prompt injection, content safety, and model supply-chain integrity. AI-assisted security operations need governed permissions and containment approvals.

Also track MFA coverage and Secure Score findings. Former >80% score, <1-hour detection, and <14-day critical-fix thresholds were illustrative, not WAF targets. Define detection and containment timestamps consistently. Dwell time is how long an attacker remains present before detection/removal; specify which end event is used.

Possible services: Front Door with a web application firewall, Application Gateway, Entra ID, private endpoints, Key Vault, Defender for Cloud, Sentinel. Mutual TLS authenticates both ends of a connection; apply it where required. SIEM means security information and event management; SOAR means security orchestration, automation, and response. Select controls for each actual flow; do not stack products or assume Conditional Access supports every workload call.

This is a discussion ladder, not a certification scale. Original accelerators: MFA/Key Vault; Defender/private endpoints; threat models/Sentinel analytics; automated response/risk-based access/PIM; continuous attack-defense exercises. Detection capability matters more than a posture score alone. AI assistance requires bounded permissions and validation, not assumed autonomous safety.

Outcome: lower dwell time & blast radius with reduced analyst toil. Risks if Ignored (by Level): 1: Credential stuffing / leaked keys / flat trust zones 2: Posture drift; Secure Score backlog rots 3: Slow breach containment, no IR muscle memory 4: Analyst fatigue / alert backlog / inconsistent response 5: Control regressions undetected; over-trust in aging controls

Other checks: secrets in pipelines, MFA and managed-identity coverage, critical vulnerability age, detection time, key rotation. Preserve emergency access and validate recovery before changing administrator roles.

Security, redundancy, and AI costs all belong in the workload cost model. Track spend against delivered value, not just individual resource line items.

Use ownership tags, budgets, business measures, and anomaly reviews. Unmeasured cost is uncontrolled cost; optimization needs an accountable owner.

CO:04 tags/budget alerts; CO:12 scaling and schedules; CO:05 reservations/savings plans; CO:10 interruptible Spot work and storage lifecycle; CO:03 anomaly detection; CO:07 AI allocation; CO:09 flow-cost analysis and caching. Original 50/80/100% alerts and quarterly rightsizing were examples. Tags such as environment, owner, and cost center support accountability. Not all resources support tags; apply enforcement with supported scopes and exceptions.

Also track ownership-tag coverage, suitable commitment coverage, and anomaly response time. Former 95%, 5%, 70%, 24-hour, and ±10% targets were illustrative. Quarter-over-quarter unit cost can rise legitimately for improved resilience, security, or changed demand; lower is not always better.

FinOps (financial operations) brings engineering, finance, and business together to manage technology value. Possible levers: tag policy, budget alerts, autoscale, Spot for interruptible work, storage lifecycle, read caching, Cost Management anomaly insights, and a monthly unit-cost review. Recovery headroom is not automatically waste. Budget alerts do not themselves cap spending.

Discussion ladder, not official scoring. Original accelerators: tagging policy, cost models and cost allocation, anomaly routing, lifecycle automation, autoscale, forecasting, AI-assisted insights. DRI means directly responsible individual. Former numeric thresholds were examples, not requirements for reaching a level.

Treat cost like a performance metric: observable, owned, iterated Cost Risks if Ignored (by Level): 1: Unattributed spend growth 2: Surprise overruns / reactive cuts 3: Persistent waste in idle flows 4: Scaling costs outpace revenue 5: Overpaying for unused resilience Aim for unit economics clarity before advanced forecasting automation.

Review idle resources, tag coverage, and anomaly response. Storage lifecycle and pricing commitments are levers, not a substitute for measuring delivered value.

OE:01 shared ownership; OE:07 health models/SLOs/error budgets; OE:11 reversible delivery; OE:02/05/10 standardization and automation; OE:08 structured response. Infrastructure as code (IaC) declares infrastructure in version-controlled files. Policy as code encodes enforceable rules. AI can assist routine work at any stage but is not a mandatory maturity prerequisite.

OE:06 secure supply chains: software bill of materials (SBOM), signing, scans, immutable artifacts. OE:09 workload-specific test plans cover unit, integration, end-to-end, load, and failure tests. OE:11 also includes blue-green releases (switch between old/new environments) and deployment stamps (repeatable independent deployment units), with observation time per wave. Production tests need feature flags, scope limits, and kill switches. OE:07 instrument/collect/analyze/visualize; OE:08 incident roles and blameless reviews close the ADR feedback loop.

The February 2026 OpEx maturity discussion includes AI assistance throughout. Buy established assistance first; build custom generative AI only for justified needs such as alert deduplication or risk suggestions. SRE means site reliability engineering. Protect personally identifiable information, restrict accessible data, and keep a human in the loop for consequential remediation.

DORA means DevOps Research and Assessment, a delivery-performance research program. This is a selected measurement set, not a complete current DORA taxonomy. Former daily+, one-day, 15%, and severity-specific recovery targets were examples. Define intervention and recovery boundaries consistently; distinguish time to acknowledge an incident from time to restore service.

Secure builds can include dependency scans, a software bill of materials, and signed artifacts. Progressive rings need observation time per wave. Correlation IDs connect the telemetry pipeline. AI-assisted alert grouping and remediation must remain governed. PR means pull request: a proposed change reviewed before merge. The decision is Review -> build and test -> canary -> observe -> expand only while healthy. Advance after asking the audience what to do when health worsens. These are complete presenter-controlled states, not timed automation. No cohort percentage is a universal recommendation.

Rollback is conditional on compatible data, side effects, dependencies, and capacity. Draining traffic does not undo already accepted work or database changes. Keep durable order state and queued processing correct. Recover first, then investigate; a fixed change needs a fresh test and canary, not automatic promotion. The board's stable objects morph on presenter navigation; reduced motion and PDF retain both complete states. Source: https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/safe-deployments

Short labels summarize the WAF OpEx model: DevOps Foundation, Process Standardization, Release Readiness, Change Management, Future Adaptability. Original AI examples progress through task assistance, recommendations, artifact generation, policy validation, and optimization. These are optional aids to tested practices, not proof of maturity or a requirement to build autonomous agents.

Operational Excellence Risks if Ignored (by Level): 1: Tribal ops knowledge silos 2: Inconsistent release quality 3: Alert noise & unclear severity 4: Repeating incidents / slow MTTR gains 5: Innovation slowdown / shadow ops Reliability & velocity converge when feedback loops are automated and trusted. Level names align with WAF OpEx maturity model (Feb 2026 update).

Track deployment frequency, change lead time, change failure rate, recovery, automation success, and incident-to-ADR feedback. Telemetry without actionable health targets cannot safely gate a release.

P50 is the median; P95 covers 95% of measured requests. Tail latency describes the slower end of the distribution. State the flow, sample, and measurement window. An average can conceal slow requests.

PE:01/09 per-flow targets; PE:02 validated capacity; PE:05/08 partitioning, caching and profiling; PE:04 baseline-driven improvement. A hot path is a frequently executed or performance-critical path.

PE:06 load/capacity tests; PE:05/08 data tuning; PE:09 tail latency; PE:12 gates. Scale on queue depth, requests per second, and latency as appropriate, not CPU alone. Possible cache layers: Front Door/content delivery network and Redis. Choose partitioning, indexes, and scale units against the actual bottleneck; do not partition early merely because it appears in a pattern catalog.

Evaluate controls against real behavior and bounded minimum/maximum capacity. KEDA scales on events; scaling is not itself adaptive concurrency or throttling. AI workloads need token throughput, prompt budgets, cache behavior, and provisioned throughput sizing. HPC needs placement-aware compute and low-latency interconnects. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling

Former P99 ≤3×P50, >85% cache hits, and <5-minute scaling thresholds were examples, not WAF requirements. Track performance-test results for critical flows and AI token throughput where applicable. TTL is time to live: how long a cached entry remains valid. Provisioned throughput units (PTUs) are a service-specific capacity measure, not a universal AI performance target. Other measures remain necessary: checkout throughput is completed orders per second; cache hit ratio is the share of lookups served from the cache; scaling response time runs from demand signal to usable capacity. The diagram's synthetic sample contains 60 requests at 100 ms, 25 at 200 ms, 10 at 300 ms, 4 at 600 ms, and 1 at 1200 ms. Counts sum to 100. Nearest-rank P95 is the 95th sorted request (300 ms); P99 is the 99th (600 ms). The bars are exact categories, not equal-width numeric latency bins. Compare real performance against the agreed load and SLO, not these illustrative values. The native chart keeps all values visible. Slide entry underlines P95, then P99, and brings attention to the tail; it does not animate or invent data.

Pause before changing the design. This illustrative baseline makes receipt email a synchronous dependency even though the business can accept later delivery. Agree that requirement first; do not defer work that must precede acknowledgement.

Cache safe reusable reads, move noncritical work to the queue, tune the measured data bottleneck, and test peak load and zone loss together. Possible implementation: Front Door edge cache, stateless application workers, bounded background processing, Redis, partitioned data, and performance gates. Do not cache sensitive or changing results without correct isolation/invalidation. Queue offload is asynchronous (work completes later); required durable order state still precedes acknowledgement. Predictive scaling is optional and needs evidence. Persist the intent to send the email with the order, then relay it to the queue, or use another validated consistency mechanism. A database write followed by an uncoordinated send can lose work. Consumers need idempotency, retries, and a recovery path. The diagram does not claim that a queue creates atomicity. Source: https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply

Discussion ladder, not certification scoring. Original accelerators: target worksheet, profiling, real user monitoring (RUM), load-test gates, data tuning, predictive/adaptive controls and model-drift review. PACELC describes distributed-data tradeoffs: during a partition, availability versus consistency; otherwise, latency versus consistency. Keep this specialist detail in notes unless the audience needs that specific design decision.

Outcome: Sustained latency control & scalable performance via automated, hypothesis-driven tuning loops. Performance Efficiency Risks if Ignored (by Level): 1: Over/under provision early tiers 2: Blind to regressions / tail spikes 3: Chasing symptoms not causes 4: Latency creep enters production 5: Plateau after easy wins

Supporting measures: percentile response times, cache hits, scale reaction, and AI throughput where relevant. A profiling span represents one operation within a trace. Repeat the same load before comparing changes.

Autoscale and simpler architecture can help cost, performance, and reliability when usable capacity is validated. Seek multi-pillar benefit, but do not require every investment to advance two pillars: necessary controls may have real costs.

Previous bullet list version retained for reference: Global edge + health routing; Strong identity + least privilege; Observability spine (logs, metrics, traces); Autoscale + lightweight architecture; Policy & automation as guardrails. Guiding Principle: One design decision, multi-pillar benefit.

Original trade-offs block preserved for rollback: # Trade-Offs (empty slide) # Key Well-Architected Framework Trade-Offs (two-column layout: Performance vs Security, Reliability vs Cost) -- End original block

Original friction signals: standby cost, inspection latency, change failures, reactive scaling/throttling, and privilege-elevation toil. Possible responses: criticality-based recovery, measured inspection, progressive delivery, tested scaling, and governed just-in-time access. Surface, record, measure, recalibrate.

Other original examples: regional redundancy versus cost; deeper security inspection versus latency; underprovisioning versus reliability/performance; oversized resources versus cost; rapid delivery versus failure risk. Mitigations include criticality-based recovery, measured inspection, load-tested capacity, rightsizing, secure builds, and progressive delivery. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/tradeoffs

Operational automation turns policy into repeatable behavior. Begin with business outcomes and critical-flow SLOs; avoid treating entire pillars as optional when prioritizing one requirement. Review decisions as evidence changes.

A discussion cadence and ladder, not official WAF scoring or mandatory review intervals. Adapt cadence to workload change and risk.

PHI is a legal term in the US HIPAA context; use jurisdiction-specific definitions and requirements for an actual deployment. Original audience options ranked the pillars, preferring security/reliability before performance/cost. Replace a universal ordering with explicit confidentiality, access, audit, retention, and clinical availability requirements. Establish baseline controls early; no pillar is optional. Discuss identity, encryption, logging, and recovery before tuning. PHI means protected health information: identifiable health data subject to applicable privacy rules. Use "patient data" on screen to avoid specialist jargon. Pause for A/B/C/D and a reason before revealing consequences. These are access patterns, not complete architectures; combine them only with explicit boundaries. All options require appropriate identity, authorization, encryption, audit, retention, and jurisdiction-specific controls. A local copy is not a backup. The fallback must be approved by clinical and privacy stakeholders, not an improvised bypass of access controls. Establish clinical safety and recovery requirements before choosing a pattern.

These are conditional tradeoffs, not a clinical recommendation. Validate what data each role needs, acceptable staleness, copy revocation/expiry, audit capture, device management, and conflict resolution. A downtime workflow may be paper or a separately approved system; it still needs controlled access, secure handling, training, and later reconciliation. Do not equate application availability with clinical safety. Test the chosen pattern with authorized clinical stakeholders.

Pause here. Ask the audience to choose A/B/C/D or explain what is missing. Do not advance until they have offered a reason. The following slides contain consequences and additional assumptions, so the reveal follows presenter navigation. 10x is an illustrative business forecast, not a measured load-test result. Missing requirements include per-flow SLOs, RTO/RPO, data consistency, dependency recovery, traffic geography, capacity readiness, and the team's operating capacity. The earlier version preselected B and conflated serverless with no planning. Serverless is a compute model, not a regional recovery topology; any option can use it where appropriate. A 10x forecast alone cannot select a DR architecture. Warm standby keeps a secondary ready to take over; active-active serves live traffic in both regions. Pilot light runs essentials and activates the rest during recovery. Lines are conceptual relationships, not a complete replication design. Checkout continuity and cost both matter; neither dictates a topology alone.

These are qualitative tradeoffs, not cost rankings or guarantees. Warm standby, active-active, and pilot light have different readiness and recovery assumptions. A running secondary region does not prove failover works, and its capacity must support the required recovery load. Active-active does not remove the need for fault isolation, data recovery, or tests. Pilot light may need new compute allocation during recovery, linking back to quota versus capacity. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery

These are new hypothetical constraints for the discussion, not facts about a customer deployment or an official WAF recommendation for all retail systems. Suppose one primary market serves most traffic; validate dependencies as well as data and routing during the drill. B is a candidate under these assumptions, not automatically the lowest-cost or best design. Start by agreeing numerical targets with stakeholders, then rehearse the failure and recovery. A region, SKU, or data-store dependency can invalidate the proposal. A and D remain candidates if their recovery behavior meets the business requirements; C may fit global serving or stricter recovery needs if the team can justify and operate its added complexity. Load/chaos rehearsal, autoscale thresholds, error budgets, and cost evidence inform the decision. Do not deploy predictive controls merely because demand is forecast to increase; establish a repeatable baseline first.

Original choices: lift-and-shift virtual machines; full microservices/events; managed-service replatforming; full rebuild with AI/machine learning. Replatforming is a candidate when compatible and measurable, not an automatic answer. Moving unchanged may meet immediate needs; rebuilding may be justified by actual constraints. Assess the bottleneck, managed database/queue/scheduler fit, migration risk, and a baseline before decomposing hotspots. Pause for a choice before revealing consequences. Establish the completion deadline, input size, current duration, cost per run, and recovery behavior. Managed services reduce selected operating tasks, not all operational ownership.

Facilitator Notes: Map quick wins: managed DB, queue, scheduler; carve out hotspots post replatform KPI baseline.

No option guarantees a faster batch or a lower bill. Profile CPU, storage, network, locking, and dependency waits before committing. A cloud move may be sufficient if measured capacity meets the deadline within budget. For managed services, test quotas, scheduling, data movement, and supported APIs. For a refactor or rebuild, compare output correctness as well as elapsed time; rehearse restart, duplicate processing, partial failures, rollback, and cutover. Replatforming is a candidate when evidence supports it, not an answer key.

Optimize for validated learning with baseline identity, data protection, dependency hygiene, and observability in place. Incremental hardening does not mean delaying essential security. B is a candidate if it meets those requirements.

Original options contrasted broad up-front controls, secure MVP, immediate multi-region, and heavy automation. Choose proportionate controls based on data, users, and obligations. Do not treat compliance or essential security as optional because the company is early-stage.

Facilitator Notes: Introduce maturity runway: baseline hygiene → observability → scaling → advanced security & multi-region.

MVP means minimum viable product: the smallest product that tests a useful business hypothesis. The expanded question avoids needing the acronym on screen. Pause for a choice before revealing consequences. All options require baseline identity, data protection, abuse prevention, dependency hygiene, and observability. An invite-only pilot limits exposure; it does not waive security or privacy duties. Decide audience geography, data handling, spend limits, and operating ownership.

These choices describe launch scope and operating models, not mutually exclusive features forever. Managed hosting still needs application security, monitoring, incident ownership, and cost controls. Multiple regions do not automatically provide working failover; test routing, data recovery, and dependency behavior. Choose measurable learning goals and a reassessment trigger before launch. Retain proportionate, required controls whichever scope is chosen.

Pair service guides with Azure Advisor findings and a Well-Architected Review. March 2026 examples included SQL Managed Instance, MySQL flexible server, Container Apps, Event Grid, Event Hubs, Service Bus, Blob, Databricks, Virtual WAN. Consult the current guide for each service rather than treating a dated list as an exhaustive or permanently current feature guarantee.

The workload record can include user/agent personas, technical debt, business indicators, and assessment results. Balance functional behavior with quality requirements; include AI models when they participate in the business outcome. Clarify responsibilities between workload teams and centralized platform teams.

Examples highlighted on the current WAF hub: https://learn.microsoft.com/en-us/azure/well-architected/ https://learn.microsoft.com/en-us/azure/well-architected/sustainability/ The preceding list also included Azure Virtual Desktop, Azure VMware Solution, Oracle, and SAP; consult the workload index for guidance relevant to the actual scenario rather than treating the hub's featured cards as an exhaustive catalog.

Supporting actions: governed PIM/JIT elevation; supported ownership tags and idle reports; SLO/error-budget alerts delivered to the operational team; profiling the slowest request. Protect emergency access when changing roles. One ADR, one drill, one baseline at a time.

The original Q&A backdrop (./img/questions.jpg) is retained as an asset. Use the shared blueprint theme here so the closing discussion stays consistent.

Additional resources: Full contact details are on the opening bio slide and in README.md. Legacy contact: Twitter https://twitter.com/Chris_L_Ayers. https://learn.microsoft.com/en-us/training/paths/azure-well-architected-framework/ https://learn.microsoft.com/en-us/azure/cost-management-billing/ https://learn.microsoft.com/en-us/azure/advisor/advisor-score https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling https://learn.microsoft.com/en-us/azure/well-architected/design-guides/testing https://learn.microsoft.com/en-us/azure/well-architected/design All new visuals are authored slide states; no runtime diagram CDN is required.

Invite the audience to scan the supplied SpreaView QR code and review The Well-Architected Architect. Leave this slide visible during final feedback.