Reliability and Predictability

Reliability in cloud computing means that a service or application continues to operate correctly and without interruption, even when underlying components fail. Predictability means that you can forecast the behavior of the system—its performance, cost, and availability—with a high degree of confidence. Together, they allow businesses to move critical workloads to the cloud without fear of unexpected downtime or budget overruns.

On-premises, building reliability requires massive capital investment in redundant hardware, backup generators, and disaster recovery sites. Even then, failures happen. Predictability is also hard: capacity planning is guesswork, and costs spike when you need to scale. Azure solves this by abstracting hardware management and offering built-in redundancy, global scale, and multiple pricing models.

Azure operates from data centers grouped into regions (e.g., East US, West Europe). Each region is paired with another region hundreds of miles away to form a region pair. Data is replicated between pairs for disaster recovery. Within a region, availability zones are physically separate data centers with independent power, cooling, and networking. By deploying resources across multiple zones, you protect against a single data center failure.

On-premises, you buy and maintain redundant servers, storage, and networking. Achieving 99.99% uptime requires duplicate everything, plus a secondary site. Azure provides this as a service: you pay only for what you use, and Microsoft handles hardware failures, power outages, and network issues. The trade-off is that you share infrastructure with other tenants (multi-tenancy), but Azure isolates workloads via virtual networks and security boundaries.

In the Azure portal, you can configure availability zones when creating a VM (select 'Availability zone' in the Basics tab). You can create an availability set under 'High availability' options. For cost predictability, use the Azure Pricing Calculator to estimate costs, and purchase Reserved Instances under 'Reservations'.

CLI example to create a VM in availability zone 1:

az vm create \
  --resource-group myRG \
  --name myVM \
  --image UbuntuLTS \
  --zone 1

To see available VM sizes and their SLA:

az vm list-sizes --location eastus --output table

An e-commerce company runs its website on Azure VMs. During Black Friday, traffic spikes 10x. With auto-scaling and load balancing, Azure adds VMs automatically. The company uses reserved instances for baseline capacity (predictable cost) and pay-as-you-go for burst capacity. The site stays up because VMs are spread across availability zones. If one zone fails, traffic shifts to another. The SLA guarantees 99.99% uptime for the multi-VM deployment, and the company receives a credit if the SLA is not met.

On the AZ-900, you will be asked to identify which configuration achieves a given SLA percentage. Remember: one VM = 99.9%; two VMs in same availability set = 99.95%; two VMs in different availability zones = 99.99%. Also, know that SLAs do not cover application-level failures—only infrastructure uptime.

A SaaS company provides a customer relationship management (CRM) application to clients worldwide. They deploy their multi-tier application across Azure regions: primary in West Europe, secondary in North Europe. They use Azure Traffic Manager to route users to the nearest healthy endpoint. Inside each region, they use availability zones for each tier: web servers, application servers, and database. The database tier uses Azure SQL Database with active geo-replication to the secondary region. The team configures auto-scaling for web servers based on CPU load. Cost is managed by reserving 70% of capacity with Reserved Instances, leaving 30% for pay-as-you-go burst. The SLA for the multi-region deployment is 99.99%. If West Europe goes down, Traffic Manager automatically fails over to North Europe within minutes. The business problem solved: zero downtime for critical sales operations, and predictable monthly cloud spend.

An online retailer experiences 100x traffic during Black Friday. Their on-premises data center cannot handle the peak. They migrate to Azure using VM Scale Sets and Azure Kubernetes Service (AKS). They deploy across two availability zones in East US. During normal days, they run 10 VMs (all reserved). During spikes, auto-scaling adds up to 200 pay-as-you-go VMs. They use Azure Load Balancer to distribute traffic. The database is Azure Cosmos DB with multi-region writes for high availability. The team monitors with Azure Monitor and sets alerts for cost anomalies. The business problem: ability to handle massive traffic without provisioning for peak capacity, and cost that scales with revenue. Misconfiguration risk: if auto-scaling rules are too aggressive, costs can skyrocket; they set a maximum instance limit and use budget alerts.

A bank runs a trading application that requires 99.999% uptime and data residency in the US. They deploy across three availability zones in East US 2. They use Azure Proximity Placement Groups to keep VMs close for low latency. They configure Azure Site Recovery to a paired region (Central US) for disaster recovery. The database uses SQL Server with Always On availability groups across zones. They purchase three-year Reserved Instances for all baseline VMs. The SLA for three-zone deployment is 99.99% (cannot reach 99.999% with standard SLAs, but they combine with custom redundancy). The business problem: meeting regulatory requirements while avoiding massive capital expenditure on a secondary data center. Common mistake: forgetting to test failover regularly; they run a failover drill quarterly.