Workload
What it is
A workload is the application or business capability being operated, together with its custom code, data, Azure resources, supporting infrastructure, and operational choices. It is more useful than a product list because it connects compute, identity, network, data, deployment, observability, recovery, ownership, and cost.
Why it exists
Azure services are not a system by themselves. A learner needs to ask: what runs, who owns it, how does it authenticate, where does its data go, how is it reached, how is it changed, and how is failure detected and recovered?
Workload map
- Owner and outcome: name the person or team accountable for the business result, risk, and cost.
- Runtime: azure-vm, app-service, azure-app-container-apps, or aci.
- Identity and access: managed-identity, service-principal, rbac.
- Data and network boundary: storage-account, vnet, private-endpoint, nsg.
- Change path: bicep, pipeline-yaml, service-connection.
- Operations and recovery: azure-monitor, azure-backup, azure-site-recovery.
- Cost and trade-offs: identify the subscription/budget owner and balance reliability, security, cost optimization, operational excellence, and performance efficiency.
Learning use
Use a workload node to make a scenario or lab connect at least three domains. A learner should be able to trace one workload from source change to deployment, request path, telemetry, and recovery.
Related
service-account · service-connection · azure-monitor · azure-backup
📘 Source: Azure Well-Architected Framework workloads, checked 2026-08-22. Re-audit when workload guidance or the framework pillars change.