Cloud Concepts

Azure publishes Service Level Agreements (SLAs) per service — for example a percentage-uptime guarantee for a given redundancy configuration — with service credits if the target is missed. High availability is achieved through redundancy: multiple instances, availability zones and paired regions so a single hardware failure, or even a whole data center outage, does not take the application down.

The ability to add capacity to meet demand. Vertical scaling ("scaling up") means moving a resource to a larger size — more CPU/RAM on the same virtual machine, for example — and has a ceiling (the largest available SKU) plus usually a restart. Horizontal scaling ("scaling out") means adding more instances behind a load balancer, which has a much higher ceiling and no downtime, at the cost of needing the application to be stateless or session-aware across instances.

The automated version of horizontal scaling: capacity expands and contracts automatically as load rises and falls — for example an autoscale rule that adds virtual machine instances above 70% CPU and removes them again once load drops — so the customer pays only for capacity that is actually in use at each moment, rather than provisioning for peak load year-round.

The ability of a system to recover from failures and keep functioning, addressed through redundancy, health probes and automated failover, and measured separately from raw uptime through the achieved recovery time objective (RTO) and recovery point objective (RPO) in an actual incident.

Pay-as-you-go consumption pricing (covered in more detail below) replaces large upfront hardware purchases with a variable operating cost, while reservations and savings plans let a customer trade flexibility for a discount once usage patterns stabilize.

The provider invests in physical security, DDoS protection at the network edge and a large security engineering team that a single company rarely can, but security within the cloud remains the customer’s job — see the shared responsibility model below.

Azure Policy, management groups and blueprints let an organization enforce and audit rules (allowed regions, allowed SKUs, mandatory tags, encryption requirements) centrally across every subscription, instead of relying on manual review of each server.

Often summarized as "management of the cloud" versus "management in the cloud." Management of the cloud covers governance-level tasks: assigning role-based access control, setting budgets and alerts, applying policies. Management in the cloud covers day-to-day operational tasks inside a deployed resource: configuring an application, deploying code, monitoring an individual virtual machine’s disk usage.

The provider supplies virtual machines, virtual networks and storage; the customer manages the operating system upward — patching, runtime, application and data. Closest to running your own hardware, with the most control and the most operational responsibility. Example: an Azure Virtual Machine.

The provider also manages the operating system, runtime and middleware; the customer deploys application code and data and configures the platform’s settings. Less operational burden, less low-level control. Example: Azure App Service or Azure SQL Database.

The provider runs the entire application; the customer only configures it and supplies data. Example: Microsoft 365.

The customer supplies only a function’s code (for example on Azure Functions); the platform provisions, scales and tears down the underlying compute automatically, including scaling to zero when idle, and billing is per execution/consumption rather than per allocated instance.

The customer supplies a container image; the platform (for example Azure Container Apps or Azure Kubernetes Service in its managed-control-plane form) handles scheduling, scaling and the underlying host operating system, while the customer still owns everything packaged inside the container image.

Resources run on infrastructure owned and operated by the provider and shared, at the virtualization layer, among multiple customers — the default and lowest-friction Azure deployment model.

Infrastructure dedicated to a single organization, whether run in that organization’s own data center or as a dedicated deployment (for example Azure Local, formerly Azure Stack HCI); higher control and compliance posture at the cost of the operational burden the public cloud is designed to remove.

A deliberate mix of on-premises/private and public cloud, connected (for example via Azure ExpressRoute or a site-to-site VPN) so workloads and data move between the two, often used to keep sensitive data on-premises while bursting compute to the cloud.

Deliberately running workloads across more than one public cloud provider (for example Azure and AWS), usually to avoid a single vendor’s regional footprint, pricing, or outage risk, at the cost of duplicated tooling and expertise.