Benefits of Cloud Services: An Azure AZ-900 Guide

High availability means keeping an application up and reachable with as little downtime as possible, even when individual components fail. In the cloud it is a benefit you gain from the provider's infrastructure rather than something you must build from nothing: Microsoft Azure operates many datacenters and offers features that spread your workload so that a single failure does not take your whole application offline.

High availability comes from redundancy: running more than one copy of a component so that another copy keeps serving users if one fails. Ask what an extra copy is for: copies added because one could not carry the workload provide capacity (horizontal scaling), while a copy that stands ready to take over from a failed one provides availability. Placing copies in physically separate locations, such as different Azure availability zones, extends the same protection from the loss of one machine to the loss of a whole datacenter.

Service-level agreements (SLAs)

A service-level agreement (SLA) is the provider's formal commitment to the uptime of a service, expressed as a percentage such as 99.9%. If Microsoft misses an Azure SLA, eligible customers can claim service credits. An Azure SLA is mainly a commitment to uptime and connectivity; it is not a price guarantee or a list of datacenters. The headline percentage tells you how much downtime is allowed and nothing about how quickly the service responds. (A few SLAs add other commitments on top of availability; Azure Cosmos DB's, for example, also covers throughput, consistency and latency.)

The useful way to read an SLA is as allowed downtime. A 30-day month has 43,200 minutes, so each percentage converts to a downtime budget, and every extra nine after the decimal point divides the allowed downtime by ten:

So a higher percentage always means a commitment to less downtime. To check whether a service fits a requirement, convert its SLA into minutes and compare: a business that can tolerate at most 30 minutes of downtime a month is covered by 99.95% (about 22 minutes) but not by 99%, which allows more than seven hours.

The benefit is that customers can reach your application without interruption, and you did not have to buy duplicate hardware or build a second datacenter to achieve it. For example, an online store on Azure can stay open through its busiest day because the platform keeps services running even when individual components fail.

Scalability is the ability to add or remove resources to meet changing demand. When demand grows you add capacity; when it falls you remove capacity and stop paying for it. The benefit is that the resources you pay for match the workload you actually have, rather than being bought for the busiest moment and wasted the rest of the time.

There are two ways to scale.

Vertical scaling changes the power of an existing resource: adding CPU or memory to one virtual machine (scaling up), or reducing it (scaling down). Moving a web server to a smaller size once a seasonal promotion ends is scaling down, and it is just as much vertical scaling as making the server bigger.

Horizontal scaling changes the number of resources: adding identical machines to share the load, usually behind a load balancer (scaling out), or removing some (scaling in). You add or remove copies rather than resizing one.

When only vertical scaling helps

Horizontal scaling works only if the application can spread its work across several servers. Some applications were written to run on exactly one server, for example because they keep the information they need between requests on that server. Extra copies cannot help them: a new copy would not hold that information, so work cannot be shared. Until the code is redesigned, the only way to give such an application more capacity is to scale up. Any method that adds instances, whether by hand or automatically, is horizontal scaling and depends on the application being able to share its work. Vertical scaling has a ceiling (the biggest size on offer), which is one reason new applications are usually designed to scale out.

In short: making one machine bigger or smaller is vertical scaling; changing how many identical machines share the work is horizontal scaling.

Scalability is the ability to add or remove resources; elasticity is doing it automatically in response to real-time demand. Scalability is the capacity to grow and shrink; elasticity is the system growing and shrinking on its own without someone pressing a button.

With elasticity, resources are added when demand rises and removed when it falls, so the application has enough capacity and you do not pay for much idle capacity. In Azure, elasticity is typically delivered by autoscale rules that watch a metric such as CPU usage or request count and add or remove instances when it crosses a threshold.

A concrete example: a news website publishes a story that suddenly goes viral. With autoscale configured, the platform adds instances to handle the flood of visitors, then removes them once traffic returns to normal, and no engineer has to watch the traffic and react. The site stays fast, and the bill reflects only the brief surge.

Scaling by hand is scalability, not elasticity: a person decides when to add or remove capacity, which works for growth you can plan for but depends on someone noticing. Azure Autoscale can also follow a schedule, adding instances at set times with no one involved; that is automatic, but it follows the clock rather than demand, so it cannot catch a surge that arrives at an unexpected time. Elasticity in the full sense is capacity that tracks measured demand, which is what metric-based autoscale rules provide.

Reliability is the ability of a system to recover from failures and continue to function; it is also one of the pillars of the Microsoft Azure Well-Architected Framework. The cloud improves reliability through two capabilities that differ in when they act.

Fault tolerance means a redundant component takes over the moment one fails, so users see no outage at all. Disaster recovery means restoring service after an outage has already happened, for example by bringing an application back online in a second Azure region from data that was replicated there. Because Azure spans many regions worldwide, you can design for both: survive the loss of a single component without interruption, and recover even from the loss of a whole location.

Predictability lets you trust what will happen with both performance and cost, and it comes in two forms.

Performance predictability means the application keeps performing consistently as demand changes, because autoscaling, load balancing, and high availability add capacity and spread the load when needed.

Cost predictability means you can forecast and track what you will spend. Because cloud billing is based on measured consumption, you can use the Azure pricing calculator and the Total Cost of Ownership (TCO) calculator to estimate costs in advance, then track actual spending against the estimate with cost-management tools.

Together, reliability and predictability let you promise a dependable service and a dependable budget.

The security benefit of the cloud is that you build on protection the provider maintains, at a scale few organizations could afford alone; the governance benefit is that you can set, enforce, and audit rules consistently across every resource.

Security

Microsoft Azure provides physical security for its datacenters (guards, controlled and biometric entry), protection of its global network, encryption options for data, and tools that detect and respond to threats. Every customer, whatever its size, builds on that foundation without having to staff or fund it.

How much of the remaining security work you hand off depends on the service type, which forms a gradient:

This is a trade-off, not a free gain. Handing off OS patching to PaaS, serverless, or SaaS also means giving up administrator access to the operating system. The further along the gradient you move, the more maintenance the provider carries, with SaaS handing off the most. Anything that needs control of the operating system itself, such as a particular OS configuration or software that must run with administrator rights on the machine, is possible only with IaaS, and you keep the patching work that comes with it. Whatever the model, protecting your data and deciding who can access it stays with you. The shared responsibility model and the IaaS, PaaS, and SaaS lesson cover the split in detail.

Governance

Governance is setting and enforcing rules and standards, then auditing whether they are followed: requiring that resources carry tags such as a cost center, allowing deployments only in approved regions, enforcing a naming standard, or requiring deployment from approved templates. Cloud platforms apply these rules automatically across many resources and report on compliance (in Azure, mainly through Azure Policy), which helps you meet company policies and regulations. Depending on your service type, software patches and updates may also be applied automatically, which helps both governance and security.

For example, an organization can require every new resource to carry a cost-center tag and block deployments that break the rule, keeping the whole estate tidy and compliant.

Manageability is the benefit of being able to run your resources with less manual effort, and it has two sides: management of the cloud and management in the cloud.

Management of the cloud is about managing your resources themselves, largely automatically. Microsoft describes it as being able to automatically scale resource deployment based on need, deploy resources from a preconfigured template so an environment is recreated the same way every time, monitor the health of resources and automatically replace failing ones, and receive automatic alerts based on configured metrics, so you know about performance in real time. A rule that notifies the on-call engineer when a database's storage passes 80% full is management of the cloud: the platform watches the metric and acts on a rule you set once.

Management in the cloud is about how you interact with and control your resources: through the web-based Azure portal, a command-line interface (Azure CLI), Azure PowerShell and scripts, or application programming interfaces (APIs) called from code. Whenever a person or their code issues the instruction, through any of these tools, that is management in the cloud, even when what they are looking at is a metric.

The overall benefit is less manual effort: routine work is automated, and when you do step in, you have flexible ways to do it.

Bringing the benefits together helps you answer questions quickly. Each benefit solves a problem that was hard and expensive to solve with your own datacenter.

Matching the situation to the benefit is the core skill. Minimal downtime when a component fails is high availability. More identical servers sharing the work is horizontal scaling; a bigger or smaller single server is vertical scaling. Capacity that follows demand with no one stepping in is elasticity. Carrying on through a failure is fault tolerance, and restoring service after an outage is disaster recovery. Forecasting the monthly bill is cost predictability, enforcing tags or approved regions is governance, and an alert the platform raises from a configured metric is management of the cloud.