Microsoft Azure
Master Azure: Microsoft cloud services, enterprise integration, hybrid cloud, and Azure DevOps.
What is Microsoft Azure?
Microsoft Azure is a public cloud platform that lets teams provision compute, storage, databases, networks, identity, analytics, and operational services through a common management plane. Instead of buying every server and building every platform capability, a team declares resources in Azure regions and pays for the capacity and managed features it uses.
Azure matters because it can shorten the path from a system requirement to an operated workload. Managed services can absorb patching, replication, scaling, and backup work, while Microsoft Entra ID, Azure Policy, and Azure Resource Manager give enterprises common identity and governance boundaries.
The core invariant is: Azure operates the cloud platform, but the workload team still owns its architecture, identities, data rules, recovery plan, and cost controls. A managed service changes which tasks the team performs; it does not remove ownership of the system's user-visible outcome.
Separate Azure's control plane from the workload data plane
Four responsibilities form a useful beginner mental model. They explain why a healthy Azure portal does not guarantee a healthy application and why a denied deployment can be a governance success rather than a platform failure.
Azure Resource Manager
Resource control plane
Creates, updates, tags, locks, and deletes declared resources. Azure Policy and role assignments evaluate management actions at inherited scopes.
Microsoft Entra ID
Identity plane
Authenticates people and workloads, issues tokens, and supports conditional access. Authorization still depends on the role and resource scope receiving that token.
Application traffic
Workload data plane
Carries requests, messages, queries, and stored data through the deployed services. Data-plane health and permissions are distinct from resource deployment permissions.
Operating ownership
Shared responsibility
Microsoft protects the facilities and managed platform boundary. The customer owns application code, configuration, access, data protection, observability, and recovery.
Ask two questions during every incident
- Can Azure accept a management change? Check Resource Manager, policy, quota, role assignment, deployment state, and the regional control plane.
- Can users complete the workload journey? Check routing, compute, dependencies, identity tokens, data correctness, saturation, and the application's service-level indicators.
Treating these as one health signal creates misleading runbooks. An existing workload can keep serving during a control-plane disruption, while a perfectly successful deployment can still produce a broken data plane.
Organize resources so ownership and policy inherit correctly
Azure Resource Manager applies management settings at a scope. Lower scopes inherit policy and access decisions from higher scopes, so the hierarchy is an operating model, not merely a folder tree.
Azure management scope flows from organization to resource
Place a control at the highest scope where it is true for every descendant, then make exceptions explicit and reviewable.
Enterprise policy
Management group
Groups subscriptions so location policy, security requirements, and broad role assignments can follow an organizational boundary.
Quota and billing
Subscription
Creates a strong boundary for regional quotas, cost attribution, access, and workload or platform ownership. One tenant can contain many subscriptions.
Lifecycle boundary
Resource group
Collects related resources that are commonly deployed, authorized, observed, or deleted together. A resource belongs to one resource group at a time.
Data-plane capability
Resource
Represents one service instance such as an app, identity, database, vault, network, or monitoring workspace with its own configuration and data-plane behavior.
Place boundaries deliberately
- Use separate subscriptions when workloads need independent quota, ownership, billing, policy, or incident blast radius.
- Group resources by lifecycle rather than by resource type. A resource group named
databasesoften couples unrelated applications that should change independently. - Put deny policy high only when every descendant must follow it. Test policy rollout and exemptions before blocking production deployment paths.
- Remember that tags help inventory and cost attribution, but they do not replace identity, policy, or an owner with a response obligation.
See the current Azure Resource Manager scope model when designing a hierarchy or validating platform limits.
Build a landing zone before multiplying workloads
An Azure landing zone is a repeatable environment where workloads inherit an intentional identity, network, governance, security, management, and delivery foundation. It separates shared platform responsibilities from application ownership without forcing every team into one subscription or one deployment pipeline.
Shared foundation
Platform landing zone
Owns tenant integration, management-group structure, shared connectivity, security monitoring, policy, and platform automation. Changes have a broad blast radius and need platform-level review.
Workload boundary
Application landing zone
Gives one workload team subscriptions, networks, identities, budgets, deployment paths, and observability that fit its risk and lifecycle.
Governed autonomy
Policy as a guardrail
Audit first, remediate deliberately, then deny unsafe states only after teams have a supported path. Exemptions need scope, owner, reason, and expiry.
Keep the platform contract explicit
- The platform team defines supported regions, network connectivity, identity patterns, logging destinations, policy, and escalation paths.
- The workload team owns its service objectives, data classification, deployment, application authorization, dependency behavior, and recovery exercises.
- Shared services publish capacity, availability, maintenance, and onboarding contracts. A central hub with no owner becomes a hidden single point of failure.
- Infrastructure changes use reviewed code and a promotion path. Manual portal changes are detected as drift and either codified or removed.
Microsoft's current landing-zone design areas cover billing and tenant structure, identity, resource organization, networking, security, management, governance, and platform automation.
Choose a compute model by operational ownership
Azure exposes many service names, but the useful question is how much platform behavior the workload team needs to control. Prefer the highest-level service that still meets the workload's runtime, networking, scaling, compliance, and portability requirements.
Infrastructure as a service
Virtual Machines
Use when the application needs operating-system control, legacy middleware, custom drivers, or an appliance model. The team owns guest patching, process supervision, scaling, and host-level hardening.
Managed application platform
App Service or Container Apps
Use for web apps, APIs, jobs, and containers that fit a managed runtime and networking contract. The platform handles more host and rollout mechanics.
Container orchestration
Azure Kubernetes Service
Use when teams genuinely need Kubernetes APIs, scheduling controls, ecosystem tooling, or multi-workload orchestration and can operate cluster, workload, and upgrade policy.
Event-driven execution
Azure Functions
Use for bounded event handlers whose scale-to-zero, trigger, startup, execution-time, and concurrency model match the job. Make retries and side effects idempotent.
Do not select from the happy path alone
- Model startup time, rollout overlap, autoscale delay, peak concurrency, and one lost failure domain.
- Verify outbound connection limits, private networking, certificate rotation, quota, regional availability, and deployment-slot behavior.
- Size downstream databases, queues, identity providers, and third-party APIs before scaling callers. More compute can amplify a fixed dependency failure.
- Compare the operating labor and recovery complexity, not only the service's unit price.
Trace one request through an Azure workload
A production request crosses global, regional, application, and data boundaries. Each boundary needs a timeout, identity, telemetry, and an owner for degraded behavior.
A public request through a governed Azure application
The global edge reduces exposure and chooses a healthy region; the regional path authenticates, admits, executes, and persists within an end-to-end latency budget.
Global edge
Azure Front Door
Terminates public traffic, applies edge policy, and routes to a healthy regional origin. A second region helps only when routing health probes represent the complete journey.
Network boundary
Regional ingress
Application Gateway, API Management, or another ingress validates protocol and policy, then forwards a correlation ID and the remaining deadline.
Application decision
Managed compute
App Service, Container Apps, AKS, Functions, or VMs execute bounded business logic with a managed identity instead of a long-lived credential.
Durable state
Managed data
Azure SQL, Cosmos DB, Storage, Cache, or messaging services enforce the selected data, consistency, partitioning, and recovery contract.
Decision evidence
Azure Monitor
Metrics, logs, traces, resource health, and deployment events show user impact, dependency pressure, responsible version, and the action an operator should take.
Pass one request identity and deadline through the path. Independent retries at the edge, application, SDK, and database can multiply load after a slowdown; choose one layer that understands whether the operation is safe to repeat.
Estimate capacity and cost from workload shape
Cloud cost is architecture made visible. Compute hours, retained data, outbound bytes, telemetry volume, regional redundancy, and managed-service baselines respond to different design choices, so a single "price per server" is not a useful workload budget.
Peak / tested capacity
Compute floor
Include target utilization and one failure domain
Requests x bytes
Network volume
Separate public egress from private and cached traffic
Events x retention
Telemetry volume
Keep decision evidence without logging every success forever
Owner + budget + SLO
Cost accountability
A cheap resource with no owner is still operational debt
Loading the workload model
The lesson is loading workload profiles and transparent planning assumptions.
Loading planning assumptions...
Read the estimate as a set of hypotheses
- Benchmark sustainable requests per instance at the target tail latency and error rate, including real dependencies.
- Use measured average-to-peak ratio, response size, cache hit rate, log volume, and retention instead of copying the lesson defaults.
- Price the selected region, operating system, service tier, support plan, private networking, backups, reservations, and negotiated benefits with the current Azure Pricing Calculator.
- Validate quota in every deployment and recovery region before the incident.
- Reconcile actual cost by workload, environment, owner, and business unit; investigate unallocated spend rather than spreading it invisibly.
Design for failure domains, not region labels
An Azure region is a geographic deployment boundary containing datacenters and network infrastructure. Many regions expose availability zones, which isolate power, cooling, and networking inside that region. Some regions are paired and others are not; region pairing is not automatic workload disaster recovery.
Define four different promises
- High availability: the workload keeps serving during routine instance and zone failures using independent, ready capacity.
- Disaster recovery: the workload can restore or fail over after a regional or destructive event within a tested recovery time objective (RTO).
- Data-loss tolerance: the recovery point objective (RPO) names how much committed history the business can lose.
- Historical recovery: isolated backups preserve a prior correct state when live replication faithfully copies deletion or corruption.
Loading the resilience model
The lesson is loading topologies, recovery policies, and failure scenarios.
Loading failure scenarios...
Prove the complete failover path
- Inject the failure without telling responders which dependency will break.
- Detect user impact from service indicators, not only Azure resource status.
- Fence the old writer, select an accepted data position, and move routing through one controlled authority.
- Verify identity, secrets, certificates, quotas, private DNS, dependencies, and observability in the recovery region.
- Reconcile delayed or ambiguous writes, then document measured RTO, RPO, and manual decisions.
Use the current Azure reliability guidance to verify each chosen service's zonal and multiregion behavior. Service support differs by region and configuration.
Treat identity as the primary workload boundary
Network isolation reduces exposure, but identity decides which human or workload can perform an action. Microsoft Entra authentication, Azure role-based access control, resource data-plane roles, and application authorization solve different parts of that decision.
1 Identity
Authenticate the caller
Entra ID verifies a person, service principal, or managed identity and issues a short-lived token for an intended audience.
2 Azure RBAC
Authorize at the resource
The target evaluates role assignments and scope. Management-plane rights do not automatically grant access to a resource's stored data.
3 Application policy
Authorize the business action
The workload verifies tenant, subject, claims, and domain rules such as who may approve an order. A broad cloud role cannot replace application-level authorization.
4 Evidence
Audit the decision
Record actor, workload identity, action, resource, result, correlation ID, and policy version without leaking tokens or sensitive payloads.
Remove standing credentials from the normal path
- Prefer managed identities for Azure-hosted workloads and federated workload identity for supported external deployment systems.
- Assign the narrowest data-plane role at the smallest durable scope; separate runtime, deployment, migration, and emergency access.
- Keep secrets and certificates in Key Vault, but design cache, rotation, throttling, private connectivity, and outage behavior for the applications that consume them.
- Make privileged human access time-bound, approved, strongly authenticated, logged, and reviewed after use.
Choose managed data services from the required contract
Service selection starts with data shape, access paths, consistency, ownership, retention, recovery, and scale. Product names come after the contract.
Relational transactions
Azure SQL Database
Use when tables, constraints, joins, SQL access, and transactional invariants fit a managed SQL Server-compatible engine. Design indexes, connection bounds, and geo recovery explicitly.
Distributed document data
Azure Cosmos DB
Use when partitioned document access, global distribution, and selectable consistency fit the workload. A poor partition key creates hot logical ownership regardless of provisioned throughput.
Objects, files, queues
Azure Storage
Use Blob Storage for durable objects and lifecycle tiers, Files for managed shares, and queues for simple asynchronous handoff. Versioning and replication do not replace an application recovery policy.
Asynchronous communication
Event Hubs or Service Bus
Use Event Hubs for partitioned event streams and Service Bus for enterprise messaging features. Define ordering, duplicate handling, retention, poison work, and replay.
Keep state ownership recoverable
- Give one service authority over each business invariant and expose an API or event contract instead of sharing write access broadly.
- Use idempotency keys for retried commands and an outbox or equivalent durable handoff when database state and emitted events must agree.
- Encrypt in transit and at rest, classify sensitive fields, restrict export paths, and test key rotation without losing access to historical data.
- Restore backups into an isolated environment and run application-level integrity checks. A successful platform restore command is not proof of correct business state.
Deploy the application boundary as reviewed code
Bicep, ARM templates, Terraform, and other infrastructure-as-code tools make the desired resource state reviewable and repeatable. The deployment engine can validate structure and policy; the workload team still has to prove compatibility and runtime behavior.
Promote infrastructure safely
- Lint and validate declarations, resolve policy effects, and preview the change set before mutating a shared environment.
- Pin module and provider versions, scan artifacts, and promote the same reviewed source through environments.
- Separate additive application rollout from destructive data migration. Use backward- compatible expansion, migration, verification, and later contraction.
- Correlate deployment identity, commit, resource changes, and application version with Azure Monitor evidence.
- Keep rollback honest: some data and identity changes need forward repair or restore, not a template redeployment.
GitHub Actions and Azure DevOps can both drive this workflow. The important contract is reviewed identity, deterministic inputs, bounded permissions, policy evaluation, deployment evidence, and a tested recovery action.
Connect hybrid systems without hiding split ownership
Azure VPN Gateway, ExpressRoute, Virtual WAN, Private Link, DNS, and Azure Arc can connect and govern resources across cloud and on-premises environments. They also add latency, routing, certificate, quota, and incident boundaries that one platform team does not fully control.
Review the hybrid path end to end
- Draw source and destination address ranges, route propagation, firewalls, private endpoints, name resolution, and return paths. Test them from the real workload subnet.
- Define which identity authority issues tokens, how trust is federated, and what happens when the on-premises or cloud identity dependency is slow.
- Measure bandwidth and tail latency during backup, replication, patching, and peak business traffic, not only with an idle connectivity test.
- Assign owners for carrier, edge device, Azure gateway, DNS, certificate, firewall, and application failures, with one cross-boundary escalation path.
- Decide whether the application may degrade locally, queue work, or become unavailable when the private connection fails.
Balance the five Well-Architected pillars
The Azure Well-Architected Framework evaluates a workload through five connected quality areas. Improving one can pressure another, so every architecture decision should name the requirement and accepted trade-off.
Recoverable service
Reliability
Define service objectives, failure domains, capacity headroom, dependency behavior, backups, and exercised recovery.
Least privilege
Security
Protect identity, data, network paths, software supply chain, privileged operations, and incident evidence according to the workload threat model.
Value and accountability
Cost optimization
Attribute spend, remove waste, match service level to business value, and measure the operating cost shifted onto engineers.
Safe change
Operational excellence
Automate repeatable work, observe important journeys, own alerts, rehearse incidents, and turn production evidence into the next improvement.
Measured demand
Performance efficiency
Select architecture and capacity from workload shape, test bottlenecks, and adapt without exceeding latency, correctness, reliability, or cost constraints.
Production readiness review
- Important user journeys have latency, success, freshness, durability, and correctness objectives with accountable owners.
- Every regional service, feature, and quota is verified in both deployment and recovery locations.
- Identity roles, policy assignments, network paths, secrets, certificates, and data retention are tested from the workload's actual runtime identity.
- Autoscale, retry, timeout, connection, queue, and circuit-breaker limits are measured under peak load and one failed dependency.
- Budgets and anomaly alerts map spend to workload, environment, and owner; unused and unallocated resources are reviewed regularly.
- Deployment, rollback, failover, backup restore, and destructive-operator scenarios are rehearsed and produce measured evidence.
Compare the service vocabulary and operating trade-offs with AWS, Google Cloud, and the broader cloud-native operating model.