This chapter covers the Microsoft Azure Well-Architected Framework (WAF), a set of best practices for designing and operating reliable, secure, efficient, and cost-effective cloud workloads. For the AZ-305 exam, understanding the five pillars—Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency—is critical, as questions directly test your ability to apply these principles to solution architecture decisions. Approximately 15-20% of exam questions touch on the Well-Architected Framework, either explicitly or as a lens for evaluating design choices. Mastery of this topic differentiates a candidate who memorizes services from one who truly understands how to architect resilient solutions.
Jump to a section
Imagine you are building a large office complex. Before any construction begins, you hire an architect to create a comprehensive blueprint. This blueprint isn't just a drawing; it's a detailed plan covering five key aspects: structural integrity (how the building stands up to wind and earthquakes), operational efficiency (how HVAC and lighting systems run day-to-day), security (access control, fire exits), performance (elevator speed, network cabling bandwidth), and cost (material choices, labor estimates). The architect also provides a set of principles—like "use steel beams with a minimum 2-hour fire rating" or "design corridors for 200 people per minute evacuation." Now, you also hire a building inspector who visits regularly. The inspector checks that the actual construction follows the blueprint. If the electrician uses cheaper wiring than specified, the inspector flags it. Over time, as tenants move in, the inspector returns to ensure the building still meets safety codes and operational standards. In this analogy, the blueprint is the Well-Architected Framework's pillars and design principles. The inspector is the Microsoft Azure Well-Architected Review—a structured assessment that validates your workload against those pillars. Just as a building must be designed, constructed, and maintained according to a proven blueprint, a cloud workload must be architected, deployed, and operated following the framework's guidance to avoid costly rework, security breaches, or performance failures.
What Is the Microsoft Azure Well-Architected Framework?
The Microsoft Azure Well-Architected Framework (WAF) is a set of guiding tenets that help architects and engineers build high-quality workloads in Azure. It was introduced in 2018 and is continuously updated based on lessons learned from Microsoft's own cloud operations and customer deployments. The framework consists of five pillars, each with its own set of design principles, best practices, and assessment questions. Unlike a rigid checklist, the WAF is a decision-making framework: it provides trade-off guidance so you can balance conflicting requirements (e.g., cost vs. reliability).
The five pillars are: - Reliability: Ensuring your workload can recover from failures and continue to function. - Security: Protecting your workload from threats and vulnerabilities. - Cost Optimization: Managing costs to maximize the value delivered. - Operational Excellence: Running and monitoring systems to deliver business value. - Performance Efficiency: Scaling to meet user demand efficiently.
The framework also includes the Microsoft Azure Well-Architected Review—a structured assessment available through the Azure portal or as a partner-led engagement. This review evaluates your workload against the pillars and provides actionable recommendations.
Why the Framework Exists
Cloud architecture is fundamentally different from on-premises. In traditional IT, you control every layer—hardware, OS, network, application. In the cloud, you share responsibility with Microsoft. The WAF acknowledges that success requires intentional design across all layers, not just slapping VMs together. Common failure patterns include:
Over-provisioning resources for peak load (cost waste).
Under-provisioning redundancy (downtime).
Ignoring identity and network security (breaches).
Not instrumenting for observability (blind operations).
The WAF provides a common language and methodology to avoid these pitfalls. For AZ-305, the exam expects you to recommend Azure services and configurations that align with these pillars.
Deep Dive into Each Pillar
#### Reliability Pillar
Goal: Achieve and maintain a defined level of availability and resilience.
Design Principles:
Design for business requirements: Define availability, recovery point objective (RPO), and recovery time objective (RTO).
Design for resilience: Use redundancy, fault isolation, and graceful degradation.
Design for recovery: Automate recovery processes; test failover regularly.
Design for operations: Monitor health and trigger automated responses.
Key Concepts: - Availability Zones (AZs): Physically separate datacenters within an Azure region. Each AZ has independent power, cooling, and networking. Deploying across at least two AZs protects against datacenter-level failures. Not all regions support AZs (e.g., UK South does, but UK West does not). - Region Pairs: Each Azure region is paired with another region at least 300 miles away (e.g., East US paired with West US). Region pairs enable geo-redundancy and are used for planned maintenance and disaster recovery. Data is replicated within the pair for some services (e.g., Geo-Redundant Storage). - Service Level Agreements (SLAs): Microsoft guarantees uptime percentages for Azure services. For a Virtual Machine (VM) with two or more instances across AZs, the SLA is 99.99% uptime. For a single VM with premium SSD, it's 99.9%. Composite SLAs are calculated by multiplying individual SLAs. For example, a web app (99.95%) + SQL Database (99.99%) = 99.94% (0.9995 * 0.9999). - Health Probes and Load Balancers: Azure Load Balancer uses health probes (HTTP, TCP, or HTTPS) to determine if a backend instance is healthy. If a probe fails (e.g., 404 or timeout), the load balancer stops sending traffic. Default probe interval is 5 seconds, with a threshold of 2 consecutive failures to mark unhealthy. - Autoscaling: Scale out/in based on metrics like CPU > 75% or queue length. Use Azure Autoscale with a cool-down period (default 10 minutes) to avoid flapping.
Common Exam Trap: Candidates assume that deploying a single VM with premium SSD gives 99.99% SLA. Wrong—single instance VM SLA is 99.9%. Only multi-instance across AZs gets 99.99%.
#### Security Pillar
Goal: Protect data, systems, and assets from unauthorized access and attacks.
Design Principles:
Use a strong identity foundation: Implement least privilege, use Azure AD, enable MFA.
Protect data in transit and at rest: Use TLS 1.2+, Azure Storage encryption, Azure Disk Encryption.
Centralize security management: Use Azure Security Center, Azure Sentinel.
Plan for incident response: Have playbooks, use Azure Monitor alerts.
Key Concepts: - Shared Responsibility Model: Microsoft secures the cloud infrastructure (physical security, hypervisor, network). You secure what you deploy (VMs, applications, data). For PaaS, Microsoft secures the OS and middleware; you secure your app and data. - Azure AD: Identity provider for authentication and authorization. Supports Conditional Access policies (e.g., require MFA from untrusted locations). - Role-Based Access Control (RBAC): Assign roles (Owner, Contributor, Reader) to users/groups at a scope (subscription, resource group, resource). Use built-in roles or create custom roles. Deny assignments (via Azure Policy) can block specific actions. - Network Security Groups (NSGs): Stateful firewall rules at subnet or NIC level. Default rules allow outbound traffic and block inbound from internet. Order of rules is evaluated by priority (lower number = higher priority). - Azure Firewall: Managed, stateful firewall as a service. Supports application and network rules, threat intelligence, and central logging. - Encryption: Azure Storage Service Encryption (SSE) encrypts data at rest using AES-256. Azure Disk Encryption uses BitLocker for Windows, DM-Crypt for Linux. TLS 1.2 is the default for Azure services; older versions should be disabled.
Common Exam Trap: Confusing NSG with Azure Firewall. NSG is layer 3/4 stateless? Actually, NSG is stateful—it tracks connections and allows return traffic automatically. Azure Firewall is also stateful but adds application-level inspection and centralized management.
#### Cost Optimization Pillar
Goal: Maximize business value while minimizing costs.
Design Principles:
Adopt a consumption model: Pay only for what you use.
Measure and optimize: Use Azure Cost Management + Billing to track spending.
Use right-sizing: Choose appropriate VM sizes; use Reserved Instances for steady-state workloads.
Stop/Deallocate resources when not in use: Use Azure Automation to shut down dev/test VMs.
Key Concepts: - Azure Reservations: Commit to 1 or 3 years for VMs, SQL Database, etc., and get up to 72% discount compared to pay-as-you-go. Reserved capacity is region- and size-specific. - Azure Hybrid Benefit: Use existing Windows Server or SQL Server licenses with Software Assurance to reduce costs on Azure VMs. Can be applied at scale via the Azure portal. - Azure Spot VMs: Use unused Azure capacity at up to 90% discount. Suitable for batch processing, dev/test, and stateless workloads. Can be evicted with 30-second notice. - Autoscaling: Scale in during low demand to reduce costs. Combine with Azure Reservations for baseline capacity. - Cost Management: Azure Cost Management provides budgets, alerts, and recommendations. Use tags to group resources by cost center, environment, or owner.
Common Exam Trap: Assuming Reserved Instances are always the cheapest. For unpredictable workloads, pay-as-you-go with autoscaling may be cheaper. Also, forgetting that Azure Hybrid Benefit only applies if you have Software Assurance.
#### Operational Excellence Pillar
Goal: Run and monitor systems to deliver business value and continuously improve.
Design Principles:
Design for operations: Use Infrastructure as Code (IaC) with ARM templates or Terraform.
Monitor and diagnose: Use Azure Monitor, Application Insights, and Log Analytics.
Automate deployments: Use Azure DevOps or GitHub Actions for CI/CD.
Use testing and validation: Load test, failover test, chaos engineering.
Key Concepts: - Azure Monitor: Collects metrics and logs from Azure resources. Metrics are numerical values (CPU, memory) stored for 93 days. Logs are text-based (application logs, custom logs) stored in Log Analytics workspace. - Application Insights: Application Performance Management (APM) service. Tracks requests, dependencies, exceptions, and page views. Supports distributed tracing and smart detection. - Log Analytics Workspace: Central repository for log data. Use Kusto Query Language (KQL) to query logs. Workspace pricing is per GB ingested. - Azure Automation: Automate tasks like VM start/stop, patching, and configuration management. Use runbooks (PowerShell or Python) or Desired State Configuration (DSC). - Infrastructure as Code (IaC): Define resources declaratively. ARM templates are JSON; Bicep is a domain-specific language. Store in source control, version, and deploy via pipelines.
Common Exam Trap: Believing that Azure Monitor and Application Insights are the same. Azure Monitor is the platform; Application Insights is a specific feature for application monitoring. Also, logs retention default is 30 days for free tier, not indefinite.
#### Performance Efficiency Pillar
Goal: Efficiently meet changing demands through scaling and optimization.
Design Principles:
Use horizontal scaling (scale out) rather than vertical (scale up).
Use caching to reduce load: Azure Cache for Redis, CDN.
Use the right data store: SQL for relational, Cosmos DB for NoSQL, Blob for unstructured.
Design for performance testing: Use Azure Load Testing.
Key Concepts: - Scaling Methods:
Vertical: Increase VM size (e.g., D2s v3 to D4s v3). Requires restart.
Horizontal: Add more instances behind a load balancer. No downtime.
Azure Load Balancer: Distributes traffic across VMs in a backend pool. Supports public and internal load balancing. Uses a 5-tuple hash (source IP, source port, destination IP, destination port, protocol) for session persistence.
Azure Traffic Manager: DNS-based load balancing across regions. Uses routing methods: Priority, Weighted, Performance, Geographic, Multivalue, Subnet.
Azure Front Door: Global HTTP/HTTPS load balancer with acceleration. Supports SSL offload, URL rewrite, and WAF policies.
Azure CDN: Content Delivery Network with edge nodes worldwide. Caches static content; dynamic site acceleration for dynamic content.
Azure Cache for Redis: In-memory data store. Use for session state, output caching, and real-time analytics. Standard tier offers 99.9% SLA; Premium tier offers persistence and clustering.
Database Performance: Use indexing, query optimization, and read replicas. Azure SQL Database offers DTU or vCore-based purchasing models. Use Hyperscale tier for large databases.
Common Exam Trap: Choosing vertical scaling as the primary scaling strategy. The exam expects horizontal scaling for cloud-native applications. Vertical scaling has limits and causes downtime.
The Well-Architected Review
The Azure Well-Architected Review is a systematic assessment of your workload against the five pillars. It is available as a self-service tool in the Azure portal (under Help + Support > Well-Architected Review) or as a partner-led engagement. The review consists of a questionnaire (about 50 questions) covering each pillar. Based on your answers, it generates a report with scores and recommendations. The review is not a one-time event; it should be performed regularly as your workload evolves.
For AZ-305, you should know that the review helps identify risks and improvements, and it aligns with the Microsoft Cloud Adoption Framework (CAF) for governance and strategy.
Identify Workload Requirements
Begin by documenting business and technical requirements. Define availability targets (e.g., 99.99% uptime), RPO (e.g., 1 hour of data loss), RTO (e.g., 15 minutes to recover), security compliance (e.g., HIPAA), and budget constraints. Use Azure Advisor and Azure Monitor to baseline current performance. This step ensures that subsequent design decisions are driven by clear, measurable goals. Without this, you risk over-engineering or under-engineering the solution.
Evaluate Each Pillar Individually
For each of the five pillars, assess your current architecture against the design principles and best practices. For Reliability, check if you have redundancy across AZs or regions, and if you have automated failover. For Security, verify RBAC roles, network segmentation, and encryption. For Cost Optimization, analyze resource utilization and reservations. For Operational Excellence, review IaC adoption and monitoring coverage. For Performance Efficiency, test scaling and caching. Use the Well-Architected Review tool to get a structured score.
Identify Trade-offs and Prioritize
No design can optimize all five pillars simultaneously. For example, adding geo-redundancy improves reliability but increases cost. You must balance based on business priorities. The WAF provides trade-off guidance: e.g., for a critical financial system, reliability and security may outweigh cost. Document trade-offs in a decision log. Common trade-offs include: cost vs. performance (using premium SSD vs. standard HDD), security vs. usability (requiring MFA for all users), and reliability vs. latency (cross-region replication).
Implement Improvements Iteratively
Based on the assessment, create a backlog of improvements. Prioritize high-impact, low-effort items first. For example, enable Azure Backup for VMs (low effort, high reliability impact) or right-size underutilized VMs (cost savings). Implement changes using IaC to ensure repeatability. Use deployment slots for zero-downtime updates. After each change, re-run the Well-Architected Review to measure progress. This iterative approach aligns with DevOps principles.
Monitor and Continuously Improve
After implementation, set up monitoring to validate that the design meets its goals. Use Azure Monitor alerts for SLA breaches, cost anomalies, or security incidents. Schedule regular Well-Architected Reviews (e.g., quarterly) to catch drift. As business requirements change (e.g., new compliance regulations or growth), revisit the design. The WAF is not a one-time certification; it is a continuous improvement cycle. For AZ-305, remember that the review is a living process, not a checkbox.
Enterprise Scenario 1: Global E-Commerce Platform
A multinational retailer migrates its e-commerce platform to Azure. The workload must handle Black Friday traffic spikes with 99.99% availability and sub-second response times. The architecture team uses the WAF to design a solution: - Reliability: Deploy the web tier across three Availability Zones in East US, with Azure Front Door for global load balancing and failover to West Europe region. Use Azure SQL Database with active geo-replication for database redundancy. - Performance: Use Azure Cache for Redis for session state and product catalog caching. Autoscale web servers based on CPU (threshold 70%) with a minimum of 2 instances per AZ. - Cost: Use Reserved Instances for baseline VM capacity (3-year term) and Azure Spot VMs for batch processing of inventory updates. Use Azure Cost Management budgets to alert if spend exceeds 10% of forecast. - Operational Excellence: Deploy via Azure DevOps CI/CD pipeline using ARM templates. Use Application Insights for real-time monitoring and Azure Monitor for infrastructure alerts. - Security: Enforce MFA for admin access via Conditional Access. Use NSGs to restrict inbound traffic to only Front Door IPs. Encrypt all data at rest with Azure Storage Service Encryption.
Common Pitfall: The team initially used a single region for simplicity. After a regional outage, they added geo-redundancy, increasing costs by 40% but meeting the SLA.
Enterprise Scenario 2: Healthcare SaaS Application
A healthcare SaaS provider must comply with HIPAA and ensure patient data is protected. They use the WAF to architect a multi-tenant solution: - Security: Use Azure AD B2C for customer identity, with RBAC for tenant isolation. Encrypt all PHI with Azure Key Vault-managed keys. Use Azure Policy to enforce TLS 1.2 and deny public storage access. - Reliability: Deploy the app across two regions (East US and West US) with active-passive failover. Use Azure SQL Database with failover groups for database disaster recovery. RTO: 1 hour, RPO: 5 minutes. - Cost: Use reserved capacity for SQL Database and VMs. Right-size VMs based on performance monitoring. - Operational Excellence: Use Azure Automation runbooks for patching and backup verification. Use Log Analytics for security auditing.
Common Pitfall: The team initially used a single VM for the database, causing a single point of failure. They moved to SQL Managed Instance with geo-replication after a security audit.
Enterprise Scenario 3: Media Streaming Service
A media company streams live events to millions of viewers. They need low latency and high throughput: - Performance: Use Azure CDN with dynamic site acceleration to cache content at edge nodes. Use Azure Media Services for encoding and streaming. Autoscale encoding jobs with Azure Batch. - Reliability: Use Azure Front Door for global load balancing with health probes. Use multiple origin servers behind an internal load balancer. - Cost: Use Spot VMs for encoding jobs (preemptible) and Reserved Instances for origin servers. - Security: Use Azure WAF with Front Door to block SQL injection and XSS attacks.
Common Pitfall: The team initially used a single CDN profile; after a regional CDN outage, they added a second CDN provider for redundancy.
What AZ-305 Tests on the Well-Architected Framework
The AZ-305 exam focuses on your ability to apply the WAF to design solutions. Specific objective codes include: - 1.3: Design governance and manageability (includes Well-Architected Review). - 1.4: Design for cost optimization. - 2.1: Design a compute solution (including reliability and performance). - 2.2: Design a networking solution (including security and performance). - 3.1: Design for identity and security. - 4.1: Design a data storage solution (including reliability and cost).
Questions are scenario-based: you are given a set of requirements and must choose the architecture that best aligns with the pillars. You will need to identify trade-offs and justify decisions.
Most Common Wrong Answers and Why Candidates Choose Them
Choosing a single large VM instead of multiple smaller VMs for high availability: Candidates think 'bigger is better' for performance, but the exam tests reliability—multiple VMs in an availability set or zone provide redundancy. The single VM is a single point of failure.
Selecting Azure SQL Database single instance without geo-replication for disaster recovery: Candidates forget that a single database in one region can go down. The correct answer includes geo-replication or failover groups.
Assuming all Azure regions support Availability Zones: They don't. For example, US Gov Virginia does, but US Gov Texas does not. The exam may test this nuance.
Using NSG rules in the wrong order: Rules are evaluated by priority (lower number = higher priority). Candidates often think it's last-match-wins, but it's first-match-wins.
Choosing vertical scaling over horizontal scaling: The exam expects horizontal scaling for cloud-native apps. Vertical scaling is acceptable only for legacy apps that can't be distributed.
Specific Numbers, Values, and Terms That Appear on the Exam
SLA for a single VM: 99.9% (with premium SSD).
SLA for two VMs in an Availability Set: 99.95%.
SLA for two VMs across Availability Zones: 99.99%.
Default autoscale cool-down: 10 minutes.
Default health probe interval: 5 seconds, unhealthy threshold: 2 failures.
Azure Storage replication: LRS (99.999999999% durability), GRS (99.999999999999999% durability).
Azure Backup retention: Maximum 99 years.
Azure Site Recovery RPO: As low as 30 seconds.
Reserved Instance term: 1 or 3 years.
Azure Hybrid Benefit: Requires Software Assurance.
Well-Architected Review: Available in Azure portal under Help + Support.
Edge Cases and Exceptions
What if a region doesn't support Availability Zones? Use Availability Sets or deploy to a paired region.
What if the workload is stateless vs. stateful? Stateless workloads can use Azure Load Balancer; stateful need session persistence (client IP affinity).
What if the budget is fixed? Use Reserved Instances and Spot VMs, but ensure reliability by having a minimum number of on-demand instances.
What if compliance requires data residency? Use Azure Policy to restrict resource creation to specific regions.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When faced with a scenario question: 1. Identify the primary requirement (e.g., 99.99% uptime). This immediately eliminates options that don't meet the SLA (e.g., single VM). 2. Look for trade-off keywords: 'cost-effective' may point to using Spot VMs or Reserved Instances; 'lowest latency' may point to using Azure Front Door or CDN. 3. Check for security requirements: If 'least privilege' is mentioned, RBAC with custom roles is correct; avoid giving Contributor role when Reader suffices. 4. Eliminate answers that violate shared responsibility: e.g., expecting Microsoft to patch your application OS. 5. Use the Well-Architected Review as a tie-breaker: if two options seem valid, the one that aligns with continuous improvement and monitoring is usually correct.
The Well-Architected Framework has five pillars: Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency.
The Well-Architected Review is a structured assessment available in the Azure portal that scores your workload and provides recommendations.
SLA for a single VM with premium SSD is 99.9%; for two VMs in an Availability Set, 99.95%; for two VMs across Availability Zones, 99.99%.
Availability Zones are not available in all regions; always verify regional support.
Horizontal scaling (scale out) is preferred over vertical scaling (scale up) for cloud-native applications.
Reserved Instances offer up to 72% discount for 1 or 3-year commitments; Azure Hybrid Benefit requires Software Assurance.
Azure Monitor collects metrics (93-day retention) and logs (configurable retention).
The framework emphasizes trade-offs: e.g., cost vs. reliability, security vs. usability.
The Well-Architected Review should be performed continuously, not as a one-time event.
For AZ-305, apply the pillars to scenario-based questions by identifying the primary requirement first.
These come up on the exam all the time. Here's how to tell them apart.
Well-Architected Framework (WAF)
Focuses on the technical architecture of a single workload.
Provides five pillars: Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency.
Used for designing and assessing workload-specific designs.
Includes the Well-Architected Review tool.
Output is a set of recommendations for workload improvement.
Cloud Adoption Framework (CAF)
Focuses on the overall cloud adoption strategy for an organization.
Provides methodologies: Strategy, Plan, Ready, Adopt, Govern, Manage.
Used for planning and governing cloud adoption at scale.
Includes tools like Azure Landing Zones and Azure Policy.
Output is a cloud adoption plan and governance framework.
Mistake
The Well-Architected Framework is only for new designs, not existing workloads.
Correct
The framework is designed for both greenfield and brownfield deployments. The Well-Architected Review specifically assesses existing workloads and provides recommendations for improvement.
Mistake
Availability Zones are available in all Azure regions.
Correct
As of 2025, Availability Zones are supported in many but not all regions. For example, UK South supports them, but UK West does not. Some regions have three zones, others have two. Always check the latest Azure documentation.
Mistake
The Well-Architected Framework is a set of rigid rules that must be followed exactly.
Correct
The framework is a set of guiding principles with trade-off guidance. It acknowledges that you cannot optimize all pillars simultaneously; you must make decisions based on business priorities.
Mistake
Azure Security Center (now Microsoft Defender for Cloud) replaces the need for the Security pillar.
Correct
Defender for Cloud is a tool that helps implement security best practices, but the Security pillar provides the design principles and architecture guidance. The pillar is broader, covering identity, encryption, network security, and incident response.
Mistake
Cost Optimization pillar means always choosing the cheapest option.
Correct
Cost Optimization is about maximizing value, not minimizing cost. Sometimes spending more on reserved capacity or higher-tier services yields better reliability or performance, which is more valuable for the business.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Well-Architected Framework (WAF) focuses on the technical architecture of a single workload, providing design principles for reliability, security, cost, operations, and performance. The Cloud Adoption Framework (CAF) is a broader strategy for an organization's entire cloud adoption journey, covering governance, management, and landing zones. For AZ-305, you need to know both: WAF for workload design, CAF for organizational governance.
Multiply the SLAs of each component. For example, a web app (99.95%) + a database (99.99%) = 0.9995 * 0.9999 = 0.9994, or 99.94% uptime. Note that dependencies in series multiply; if you have redundant components in parallel (e.g., two load balancers), the composite SLA is higher. For AZ-305, you may be asked to calculate or compare composite SLAs.
Azure Monitor metrics are stored for 93 days. You can extend retention by archiving to a Log Analytics workspace (additional cost). For logs, the default retention in Log Analytics is 30 days for the free tier and up to 730 days for paid tiers. This is a common exam detail.
Azure Front Door is an HTTP/HTTPS global load balancer with application-layer features (SSL offload, URL rewrite, WAF). Traffic Manager is a DNS-based load balancer that works at the DNS level for any protocol (HTTP, TCP, etc.). Use Front Door when you need application acceleration and security; use Traffic Manager for simple DNS-based routing across regions. For AZ-305, scenarios with web applications often favor Front Door.
An Availability Set is a logical grouping of VMs that Azure distributes across fault domains (hardware racks) and update domains (maintenance windows) within a single datacenter. An Availability Zone is a physically separate datacenter within a region, with independent power and cooling. Availability Zones provide higher resilience (99.99% SLA) but cost more due to cross-zone traffic. Availability Sets protect against rack failures, not datacenter failures.
Azure Policy enforces organizational rules and compliance. For example, you can create a policy to deny creation of storage accounts without encryption, or require TLS 1.2 on all resources. This aligns with the Security pillar's principle of 'centralize security management.' Policy can also be used for cost governance (e.g., restrict VM sizes).
Use Azure Dev/Test pricing (lower rates for VMs and other services), implement shutdown schedules (e.g., stop VMs at 7 PM and start at 7 AM), use Azure Spot VMs for batch jobs, and right-size resources based on usage monitoring. Avoid Reserved Instances for dev/test since workloads are often temporary. The Cost Optimization pillar emphasizes 'stop when not in use.'
You've just covered Microsoft Azure Well-Architected Framework — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?