Proactive Reliability Series — Article 2: Regional Distribution Patterns for Azure Workloads
Introduction Public cloud platforms — including Microsoft Azure — are built on three foundational principles that distinguish them from traditional on-premises infrastructure: Elasticity: The platform can automatically expand and contract resource capacity in response to demand. Capacity is not statically provisioned; it is drawn from a shared pool and released when no longer needed. Scaling: Workloads can scale horizontally (adding more instances) or vertically (increasing instance size) on demand, without pre-procurement of physical hardware. Consumption-based billing: Customers pay for what they use, when they use it. Cost is proportional to resource consumption, not to physical capacity reserved in advance. These principles are properties of the platform, not of any single location. Microsoft Azure Cloud is not a single region — it is a globally distributed platform comprising dozens of regions across every major geography, interconnected by a private backbone network. When an organisation deploys to Azure, it is deploying into this global system; the choice of which region or regions to use is based on an organizational strategy and architectural decision. Using a single Azure region is a valid choice in many scenarios, but it has to be a deliberate architecture decision, not an omission. Why multi-region? Microsoft Azure CTO Mark Russinovich summarises the case for multi-region in Achieve agility and scale in a dynamic cloud world: organisations that span multiple regions gain scalability and flexibility (choosing from the full Azure region portfolio, including differentiated pricing, AI capabilities, and deployment options), resilience and availability (reducing the impact of regional disruptions through multiple backup and recovery options), and performance and reduced latency (serving users from infrastructure that is geographically closer to them). The post's closing recommendation — "leverage Azure as a cloud platform, not a datacenter region" — makes explicit what the multi-region decision ultimately is: a choice to treat the platform's global footprint as an asset, not a constraint. Mark Russinovich — Achieve agility and scale in a dynamic cloud world (Microsoft Azure, September 2024) This article also does not argue whether to adopt a multi-region strategy — that is a business and risk decision. It describes what the options are: the available regional distribution patterns, the forces each resolves, and the trade-offs each accepts. Regional workload distribution is not simply an application-level decision — it is an organisational one. It shapes how a company scales its cloud presence, manages cost and operational complexity across a growing portfolio, meets data residency and regulatory obligations, and positions itself to respond to changing conditions. Multi-region is often a necessity, not a free choice: growth ambitions, compliance requirements, or risk obligations may demand it. But necessity does not determine form. These patterns define the decision space: whether operating across multiple regions is warranted at all, and if so, which structural arrangement fits the organisation's scale, objectives, and operational capability. Several patterns are adapted from Gregor Hohpe's multi-cloud strategy patterns, originally described in Multi Cloud Architecture: Decisions and Options and further elaborated in Multi-cloud: From Buzzword to Decision Model. Note: This is an unofficial guide to regional distribution patterns for Azure workloads. It is not an official Microsoft publication and is not officially supported, endorsed, or maintained by Microsoft. All descriptions and recommendations are based on publicly available Azure documentation and general distributed systems principles. Always refer to official Azure documentation and the Azure Well-Architected Framework for authoritative guidance. The risks and opportunities Pattern selection is a direct response to specific risks or solution quality requirements. Before evaluating patterns (options), it is necessary to understand what risks are actually relevant — infrastructure faults, capacity constraints, service coverage gaps, and compliance or business obligations — and what their scope of impact is. Azure infrastructure is complex and distributed. While Microsoft invests heavily in reliability, faults can and do occur across a wide range of blast radii — from a single compute instance at the narrowest end, through Availability Zone and regional failures, to global service disruptions at the widest. The appropriate pattern is the one that reduces unacceptable risks to a tolerable level. The Azure Well-Architected Framework — Reliability pillar recommends Failure Mode Analysis (FMA) as the structured technique for enumerating failure modes, assessing their impact, and identifying mitigations before they are needed in production. The fault types below are the infrastructure-layer inputs to that analysis. For a detailed breakdown of each fault type — including likelihood analysis, real-world incident examples, and detection guidance — see Proactive Reliability Series — Article 1: Fault Types in Azure. Risk catalog (sample) The following is a representative sample of risks relevant to regional workload distribution decisions, not an exhaustive catalogue. Not all entries are infrastructure faults — some represent business and compliance obligations. The Category column identifies the type of each risk. Likelihood values are relative planning heuristics to help prioritise resilience investments — they are not statistical probabilities and do not represent Azure SLA commitments. Risk Category Blast Radius Likelihood Primary Mitigation Service Fault (Region) Infrastructure Fault Single service within a region Medium Region redundancy Region Fault Infrastructure Fault Regional degradation or full regional loss (partial-to-full region impact) Low Region redundancy; cross-region failover Network POP Location Fault Infrastructure Fault Network colocation site (affects connectivity, not compute) Low ExpressRoute Metro (dual peering locations); network path redundancy Service Fault (Global) Infrastructure Fault Worldwide or multiple regions simultaneously Very Low Accept risk; use alternative service if downtime is intolerable Regional Service Capacity Constraint Infrastructure Capacity Single region (required capacity unavailable — whole service or specific SKU — at failover time or sustained shortage) Low Region redundancy; Capacity Reservations; Hot Standby; alternative region Service Regional Unavailability Infrastructure Fault Single region (desired service not offered in that region) Low Deploy to a region where the service is available Geopolitical Risk Compliance One or more regions (regulatory or political mandate to relocate) Low Portable pattern; pre-validated alternative region Sustainability Constraint Compliance One or more regions (sustainability targets unachievable in current region) Low Portable pattern; relocate to region with required sustainability profile The patterns While there could be many ways to distribute workloads across Azure regions, the following patterns represent the most common and widely applicable approaches. Each pattern is a structural topology that defines how workloads are deployed and how they respond to Risks and Quality Requirements. The patterns are not mutually exclusive — they can be combined or layered to meet specific requirements. The following patterns describe the principal ways workloads can be distributed across Azure regions. Patterns 1-3 are described and found very often, while patterns 4-5 are less common but still important to consider. The table below summarises the patterns, their intent, and the primary driver for their adoption. # Pattern Intent Primary Driver 1 Single All resources in one Azure region; AZ redundancy optional Simplicity; cost; data residency constraints 2 Failover Primary region serves traffic; secondary region is a cold or hot standby for DR Business continuity 3 Parallel Same workload deployed to multiple regions simultaneously; all active Continuous availability; zero-downtime failover 4 Segmented Services or service portfolio distributed across regions by BU, LOB, tenant, or data residency Isolation; sovereignty; independent release cadence 5 Portable Full portability; workloads can be relocated between regions without application changes Operational flexibility; on-demand relocation 1. Single region pattern Pattern Name: Single Region Workload Distribution Classification: Regional workload distribution Scope: Workload — applies to a single application or service deployment, Workload (Application) Portfolio Intent: Deploy all workload resources in one Azure region. Context: A workload is being deployed to Azure and must decide how many regions to use. The business impact of a regional outage has been assessed — either as tolerable within the workload’s criticality tier, or as not applicable because data sovereignty constraints prohibit cross-region replication. The team needs to treat Single Region as an explicitly chosen architecture, not an omission. Problem: Every additional Azure region adds infrastructure cost and workload integration complexity due to the network latency it introduces. Not all workloads justify this overhead. The question is not “should I always use multiple regions?” but “when is a single region the correct and explicitly chosen answer, and when does adding a second region produce risk-reduction that justifies the cost?” Forces: The workload’s risk profile does not justify cross-region redundancy: the business impact of a regional outage is tolerable, data sovereignty rules prohibit cross-region replication, or reliability requirements are fully met within a single region with Availability Zone redundancy. The cost of multi-region infrastructure produces no corresponding risk-reduction return for this workload. Solution Place all compute, data, and networking resources in a single Azure region. Apply Availability Zone redundancy within that region for protection against datacenter-level failures. Formally accept region-level risk as within tolerance for this workload’s criticality tier — this is a deliberate architecture decision, not an omission. Implementation: Enable Availability Zones for all production resources where supported. Use Azure Infrastructure Resiliency Manager (AIRM) to validate zone-redundancy posture across the workload. Document the risk-acceptance decision explicitly at the application level. Consequences Benefits: Lowest cost and operational footprint of all patterns. No cross-region routing, replication lag, or failover coordination complexity. Simplest deployment pipeline, observability surface, and incident response. Liabilities: No mitigation for any region-level fault — full workload loss on regional failure. Data concentrated in one geography; no cross-region durability without explicit configuration. No pre-deployed capacity in an alternative region. Risk posture: Risk Assessment Region Fault ❌ Primary unaddressed risk — partial degradation or full regional failure has no cross-region recovery path; accept or upgrade pattern Service Fault (Region) ❌ Regional service failures have no cross-region alternative Regional Service Capacity Constraint ❌ No alternative region available; both on-demand failover provisioning and sustained SKU shortages have no mitigation path Network POP Location Fault ✅ Addressable within this pattern via ExpressRoute Metro (dual peering locations in the same metro); does not require a multi-region distribution change Known uses Development and test environments; Bronze- or Non-Critical-tier workloads; workloads with strict data residency constraints that prohibit cross-region replication; proof-of-concept and time-limited deployments. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping for how individual Azure services implement this pattern. References Azure reliability documentation overview Availability zones overview Azure Well-Architected Framework — Reliability pillar Availability zone support for Azure services Azure Infrastructure Resiliency Manager (AIRM) — Public Preview 2. Failover pattern (primary + standby region) Pattern Name: Failover Workload Distribution Also Known As: Active-Passive, Disaster Recovery (DR), Business Continuity and Disaster Recovery (BCDR) Classification: Regional workload distribution, Application Design, Platform/Infrastructure Design, Disaster Recovery Scope: Workload — an application and infrastructure design pattern that requires both layers to work in tandem; Workload (Application) Portfolio Intent: Recover from a regional disaster or other longer duration region outage by designating a primary region to carry all production traffic and a standby region to absorb that traffic upon primary region failure. The typical quality attribute metrics that govern its design are RTO (Recovery Time Objective — maximum tolerable downtime), RPO (Recovery Point Objective — maximum tolerable data loss), and MTTR (Mean Time To Recovery — the observed average recovery time, measured through drills and real incidents, that validates whether the RTO target is achievable in practice). Context: A workload must survive region-level failures, but the architectural complexity of running two fully active deployments simultaneously — with multi-region write-conflict resolution — is not justified. The business can tolerate a bounded recovery time and, depending on the sub-variant chosen, a bounded data loss window. Problem: A fully active multi-region deployment (Parallel pattern) introduces multi-region write-conflict complexity that the application cannot or need not absorb. The Failover pattern trades continuous availability for single-writer simplicity: one region is active, one is standby, and recovery is bounded by RTO/RPO targets. The sub-variant choice (Cold / Warm / Hot) then determines how much cost is invested in standby readiness — from minimal (~1.1×) to near-full duplication (~2×) — based on how fast recovery must be. Forces: A single active write region is required — multi-region write-conflict resolution adds unacceptable consistency risk or development complexity. RTO and RPO targets must be met, but budget constrains how pre-warmed the standby region can be, driving the Cold / Warm / Hot sub-variant selection. Regional Service Capacity Constraint in the standby region is a residual risk for Cold and Warm sub-variants — the standby may fail to scale at failover time unless capacity is pre-reserved. Solution Designate one region as primary (all production traffic under normal conditions) and a second as standby (no production traffic until failover). The standby’s readiness level — the sub-variant choice — is determined by the RTO/RPO requirements and cost envelope. Replication from primary to standby is continuous; failover is triggered manually or automatically when the primary becomes unavailable. Note on "Active-Passive": This pattern is often called Active-Passive in Microsoft documentation. That framing is accurate at the traffic level (one region active, one passive), but it can obscure the architectural intent. The Failover label here emphasises the capability being purchased: the ability to redirect the entire workload to a pre-designated region when the primary is unavailable. Implementation: The key design decision is how ready the standby is at the moment it is needed. Three sub-variants define this readiness spectrum: Sub-variant Secondary state Cost multiplier Cold Standby No running compute; data either in scheduled backups or continuously replicated ~1.1–1.5× Warm Standby Reduced-scale compute running; data continuously replicated ~1.5–1.8× Hot Standby Full-scale compute running; data continuously replicated ~2× Cold Standby — No compute is running in the standby region under normal conditions. Cold Standby covers two positions within this state, differing in how the data layer is protected: Backup/Restore: Data is backed up or geo-replicated on a scheduled basis. On failover, infrastructure must be deployed from scratch and data restored before traffic can be redirected. RTO is measured in hours; RPO equals the interval between the last backup cycle and the failure event. Data-layer live, compute stopped: Core infrastructure (networking, identity, data tier) is kept running with continuous replication to the standby region; compute is stopped or scaled to zero. On failover, compute is started and scaled up to meet full load. RTO is typically 15–60 minutes; RPO is bounded by async replication lag rather than backup interval. Both positions share the defining characteristic of Cold Standby: no production-equivalent compute running in the secondary region under normal conditions. The difference is the investment in keeping the data layer live, which reduces both RTO and the data loss window at a modestly higher steady-state cost. Warm Standby — The standby region runs a scaled-down but functionally complete version of the workload. Traffic is not routed there under normal conditions. On failover, the secondary scales up and traffic is redirected. A brief scale-out lag occurs before the secondary absorbs full traffic; the running environment eliminates cold-start delay. Hot Standby — The standby region runs a full, production-equivalent deployment — same compute capacity, same configuration — but receives no traffic under normal conditions. Data is continuously and near-synchronously replicated. Failover is fast and often automated because no scale-up is required. Consequences Benefits: Enables recovery from region-level faults at a fraction of Parallel pattern cost. Flexible cost-vs-RTO trade-off across Cold / Warm / Hot sub-variants. No multi-region write-conflict complexity; single active write region throughout normal and recovery operation. Liabilities: Cold and Warm standby introduce meaningful RTO (minutes to hours). Replication lag creates a data loss window (RPO > 0) at the moment of failover. The failover path is the least-exercised code path — untested recovery inflates actual RTO. Failover is often neglected and not properly and regularly tested — this leads to a fear of executing failover when needed (and not only a full-region disaster demands it). Risk posture: Risk Assessment Region Fault ⚠️ Primary driver; standby region absorbs traffic on full regional loss, but partial regional degradation may not trigger automated failover. RTO depends on sub-variant Regional Service Capacity Constraint ⚠️ Cold/Warm Standby are exposed to both on-demand provisioning failure and sustained SKU shortages — mitigated by Capacity Reservations or Hot Standby Service Fault (Region) ✅ Standby region provides an alternative deployment for regional service failures Service Regional Unavailability ⚠️ Secondary region must be verified for full service parity at design time — absent services block failover regardless of compute readiness Known uses Business-critical workloads with defined RTO/RPO targets that cannot accept region-level risk but do not require continuous multi-region availability; workloads with single-writer data models where multi-region write-conflict resolution is unacceptable; regulatory environments where a designated recovery region must be pre-approved. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. References Business continuity and disaster recovery — Azure reliability WAF Reliability — Disaster recovery Azure Site Recovery overview Azure SQL Database active geo-replication Azure SQL Database auto-failover groups 3. Parallel workload distribution (simultaneous active deployment) Pattern Name: Parallel Workload Distribution (Simultaneous Active Deployment) Also Known As: Active-Active Classification: Regional workload distribution, Application Design Scope: Workload — an application-level design pattern; requires the application and its data layer to be explicitly designed for concurrent multi-region operation, Workload (Application) Portfolio Intent: Deploy the same workload simultaneously to two or more Azure regions, all serving production traffic. Context: Two independent drivers lead to this pattern, often simultaneously: the workload serves geographically distributed users who require regional proximity to meet latency targets, and the availability tier demands zero-downtime through region-level failures. A single deployment point cannot satisfy both. Manual failover timelines, standby region promotion, and RPO windows are incompatible with the required availability tier. This pattern is the mandated baseline for Mission-Critical workloads in the Azure Well-Architected Framework. Problem: Passive standby and failover mechanisms introduce recovery time and data loss windows that are incompatible with high-availability targets (e.g. 99.99%+). Meeting both demands requires all regions to be equal active participants — not a primary and a standby. But this demands that the data layer either supports concurrent writes across regions, relies on continuous cross-region replication with a defined consistency model, or is predominantly read-heavy — and that pre-provisioned capacity is maintained in every active region at all times. Forces: Regional failure must produce zero downtime — manual failover timelines cannot satisfy the availability target. Traffic originates from geographically distributed users who require regional proximity to meet latency SLAs. Availability targets (e.g. 99.99%+) eliminate passive standby as a viable option. The application can tolerate eventual consistency or is read-heavy enough that multi-region write complexity is manageable. Once multi-region data access is solved, every region's compute actively serves production traffic — the capacity that Failover Hot Standby holds idle is fully utilised; the cost multiplier buys active production capacity, not idle insurance. Solution Deploy the workload identically to two or more Azure regions. Route production traffic to all active deployments simultaneously via a global load balancer — under normal conditions, each user is directed to the nearest active region, minimising latency. On regional failure, the load balancer automatically rebalances traffic to the remaining healthy regions — no manual promotion, no scale-up delay. All regions are equal peers; there is no concept of primary and secondary. Implementation: Deployment Stamps are commonly used to implement Parallel at scale — multiple active regional instances behind global routing. See Deployment Stamps pattern — Azure Architecture Center. Stamps are not exclusive to Parallel: the same approach can also support Segmented and, in some designs, Failover. Regions active: 2+ (all serving production traffic simultaneously). Typical cost multiplier: ~2–3×. Microsoft guidance — Mission-Critical workloads: The Azure Well-Architected Framework’s Mission-Critical design methodology explicitly advises active-active multi-region deployment as the baseline for workloads targeting 99.99% availability or higher. The application design guidance states: “The application must be able to withstand regional and zone failures. It must be deployed in an active/active model so that the load is distributed among all regions.” The regions and availability zones guide reinforces this: “Mission-critical workloads should use both multiple availability zones and multiple regions.” The WAF Reliability pillar describes active-active as the mechanism to achieve zero downtime, noting it is “ideal for mission-critical workloads that require uninterrupted availability.” Consequences Benefits: Regional failure triggers automatic traffic rebalancing — no manual failover, no service interruption. Lowest RTO of all patterns; zero-downtime regional failure recovery. On regional failure, remaining regions absorb redirected traffic immediately — if at capacity, the workload degrades under load rather than failing completely; degraded performance is a fundamentally better failure mode than an unavailability window. Serves geographically distributed users within latency bounds simultaneously from the nearest active region. Compute deployed per region actively generates production value under normal conditions — the nominal cost multiplier buys utilised capacity, not idle standby insurance. Liabilities: Highest nominal cost (~2–3×) — though compared to Failover Hot Standby (~2×), the effective cost of resiliency is lower: every unit of deployed capacity actively serves production traffic rather than sitting idle as insurance. Requires the application to support multi-region writes or be predominantly read-heavy; write-conflict resolution is an application responsibility. Multi-region CI/CD, distributed observability, and write-conflict handling add steady-state operational overhead — but eliminate the failure-event burden: no failover procedure, no drill schedule, no risk of untested recovery paths inflating actual RTO. Risk posture: Risk Assessment Region Fault ✅ Primary driver; automatic traffic rebalancing handles both partial regional degradation and full regional loss — no promotion or manual steps required Service Fault (Global) ⚠️ No regional workload distribution pattern mitigates a truly global service disruption — but the impact is often partial: only specific SKUs, tiers, or versions of a service may be affected, leaving workloads on unaffected variants operational. Where the risk is intolerable, the mitigation is service substitution: switching to an alternative Azure service with equivalent functionality, or a third-party / self-hosted equivalent Service Fault (Region) ✅ Automatic rebalancing redirects traffic away from the affected region without manual failover Regional Service Capacity Constraint ✅ All regions are pre-deployed and running; no on-demand capacity provisioning required at failover time — if a region fails and remaining regions reach capacity limits, the result is degraded performance under load, not complete unavailability Known uses Mission-Critical workloads targeting 99.99%+ availability per WAF guidance; globally distributed consumer applications where regional proximity is a primary SLA requirement; financial trading and payment platforms where any recovery window is commercially unacceptable; real-time communication and streaming services where failover lag degrades the user experience. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. References Mission-critical baseline architecture on Azure WAF Reliability — Mission-critical workloads Azure Cosmos DB — Distribute data globally Azure Cosmos DB — Multi-region writes Azure Front Door — Multi-region load balancing Azure API Management — Multi-region deployment 4. Segmented workload distribution (regional distribution by boundary) Pattern Name: Segmented Workload Distribution Also Known As: Deployment Boundaries, Regional Portfolio Allocation Classification: Regional workload distribution (portfolio scope) Scope: Portfolio / Organisation — a structural pattern for distributing a portfolio of workloads, tenants, or business units across regions; individual workloads within a segment may independently apply any other pattern Intent: Assign each Azure region a distinct, non-overlapping responsibility boundary so that regions are differentiated by ownership and isolation rather than by redundancy. Context: A portfolio of workloads, a multi-tenant application, or a multi-LOB organisation must distribute services or data across regions. The drivers include regulatory boundaries, tenant isolation, blast-radius containment, or operational independence — not simply increasing redundancy. Individual boundaries within the portfolio have materially different criticality tiers, release cadences, and recovery requirements. Problem: Running a second Azure region purely as a Failover standby generates ongoing cost without delivering business value under normal conditions. How can an organisation operate multiple regions so that every region carries real production workload, the cost is justified by utilisation rather than insurance alone, and each region's scope is independent enough that faults and changes in one area do not propagate to others? Forces: Regulatory, sovereignty, or compliance obligations drive geographic boundary placement — but strict data residency that prohibits cross-boundary replication also prevents the cross-region recovery that makes Segmented cost-efficient; a boundary whose data cannot leave its region can only recover within that region (Single Region posture), regardless of what neighbouring segments deploy. Independent release cadences, lifecycle autonomy, and scaling requirements across services, tenants, or business units conflict with coupled shared-infrastructure deployments. Blast-radius containment requirements prevent a single fault or bad deployment from affecting the entire portfolio. This pattern does not answer how each boundary recovers; that choice is made independently per boundary using Single, Failover, or Parallel. Solution Define non-overlapping responsibility boundaries and assign each boundary to a region. Each region owns its boundary exclusively — no region is a replica of another. Each boundary independently selects its own recovery posture (Single, Failover, or Parallel) based on its own criticality and requirements. The key structural advantage is region reuse: because multiple regions are already deployed and carrying real production load, each region can simultaneously serve as the Failover standby or Parallel peer for a neighbouring boundary — the same infrastructure investment delivers both production utilisation and recovery capability. This dual-purpose reuse is only available where cross-boundary data replication is permitted; where strict data residency prohibits it, each boundary must treat itself as isolated and plan recovery within its own region. Implementation: The boundary can be defined at different scopes: Within one application: tenants, markets, release rings, or data partitions assigned to different regions. Across a service portfolio: different applications, domains, or business capabilities intentionally placed in different regions. Segmentation axis Example Geography / data residency EU services and data in West Europe, US services and data in East US Business unit / LOB Finance portfolio in Region A, HR portfolio in Region B Customer tier Premium customer workloads in dedicated region(s), standard in shared region(s) Release ring Ring 0 workloads in Region A, Ring 1 workloads in Region B Scale tier High-volume service groups in larger regions, low-volume groups in smaller regions Segmented is orthogonal to the Single / Failover / Parallel dimension. It answers what is each region responsible for, not how does each responsibility recover? A global organisation might run some boundaries as Single, some as Failover (warm standby), and selected mission-critical boundaries as Parallel — all within one Segmented topology. Consequences Benefits: A fault in one boundary is contained to that region and does not propagate to adjacent boundaries. Each boundary independently selects its own recovery posture, cost level, and compliance configuration. Supports independent release cadences, scaling policies, and lifecycle management per boundary. Region reuse: already-deployed regions carrying production load can simultaneously serve as Failover standby or Parallel peer for neighbouring boundaries — the infrastructure investment delivers both production utilisation and recovery capability without paying for idle standby capacity. Liabilities: Cross-boundary dependencies — shared identity, shared data stores — undermine isolation guarantees and must be minimised by design. Governance overhead scales with the number of active boundaries; requires a formal boundary ownership model to remain manageable. Risk posture: Risk Assessment Service Fault (Region) ⚠️ Fault is contained to the affected boundary; adjacent boundaries continue operating — within-boundary recovery depends on that boundary’s posture Region Fault ⚠️ Only the boundary hosted in the affected region is impacted — RTO/RPO is determined by that boundary's individual recovery posture Regional Service Capacity Constraint ⚠️ Only the boundary in the capacity-constrained region is affected; other boundaries continue operating — mitigation depends on the boundary's own topology (Failover or Parallel provides alternatives; Single does not) Geopolitical Risk ✅ Boundaries can be relocated independently; the rest of the estate continues operating while the affected boundary is relocated Service Regional Unavailability ✅ Each boundary can be independently placed in a region where all required services are available Known uses Geo-distributed enterprise application portfolios; organisations with a federated business model where autonomous business units operate independently with their own release cadence, cost accountability, and compliance obligations; SaaS platforms with tenant-per-region isolation; regulated financial and healthcare services with strict data residency by jurisdiction. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. 5. Portable workload distribution (full abstraction) Name: Portable Workload Distribution (Full Abstraction) Also Known As: Region-Agnostic Deployment, Cloud-Neutral Deployment Classification: Operational property (applicable to any structural pattern) Scope: Workload — a design property of an individual workload; composable with any structural pattern at either workload or portfolio scope Intent: Fully abstract the workload from the underlying Azure environment so it can be relocated to any Azure region at any time without modifying application code or configuration. Context: A workload is subject to compliance obligations — regulatory, geopolitical, or sustainability — that may require region relocation on short notice. Or the workload's operational requirements include the ability to optimise cost, respond to capacity constraints, or avoid service unavailability across regions. Portability is not the default outcome — it requires an explicit design decision and sustained engineering investment. Without that intent, the default is a workload that is structurally bound to its current region. Problem: Without a portability investment at design time, a relocation trigger forces significant rearchitecting under pressure rather than as a controlled migration. Forces: Compliance obligations — regulatory, geopolitical, or sustainability — may require relocation on short notice; deferring the portability decision converts a design choice into a forced rearchitecting event at the worst possible time. Data portability is the hardest dimension: scheduled backup/restore, continuous replication, and live migration each introduce cost, complexity, and consistency trade-offs that must be accepted at design time. Relocation may be temporary or permanent; the architecture must support both without distinguishing between them at deploy time. A port may be partial (subset of workloads) or full (entire estate); partial porting creates transient cross-region dependencies that must be explicitly designed for and eliminated as the migration progresses. Solution Select and implement a data portability mechanism — continuous replication, backup/restore, or live migration — whose cost, RPO, and operational model are explicitly accepted at design time. The target region is not fixed at design time — it is chosen when a trigger event occurs, and can be any eligible region. The workload stays in its current region under normal conditions and relocates only when a trigger event warrants it. Implementation: Portable is a layered property, not a separate structural topology. The underlying structural topology (Single, Failover, Parallel, or Segmented) determines traffic routing and redundancy; Portable governs whether that topology can be instantiated in a different region without application changes. The cost multiplier adds toolchain and abstraction overhead on top of the chosen structural topology. Data portability — the critical path: Compute portability is straightforward — container images and environment-agnostic configuration are standard practice. Data portability is the harder problem. Two mechanisms make it achievable: Continuous replication: The data layer replicates to the target region at all times, so the data is already present when a relocation is triggered. Azure Cosmos DB with multi-region writes, Azure SQL Database geo-replication, and Azure Storage geo-redundancy (RA-GRS/RA-GZRS) are common implementations. Continuous replication minimises RPO but adds steady-state cost. Automated data migration: A codified and continuously tested migration pipeline moves data to the target region at relocation time. Appropriate when continuous replication cost is not justified, or when the data tier does not support native geo-replication. The migration must be automatable, testable in isolation, and fast enough to satisfy the workload’s RTO for the trigger event. Port modes: Partial vs. Full A port — the act of relocating a workload using the Portable pattern — can be scoped in two ways: Partial port: A subset of workloads is relocated to the target region while others remain in the source region. This creates transient cross-region dependencies — service calls, data access, shared identity — between moved and not-yet-moved workloads. These dependencies must be explicitly designed for, monitored for latency and failure, and eliminated progressively as the migration advances. Partial porting is the natural execution mode for large estates where simultaneous full relocation is operationally infeasible. Full port: All workloads are relocated to the target region, either simultaneously or in a planned sequence that keeps cross-region dependencies only for the duration of each step. A full port is a long-term, intentional change of primary region. It is fundamentally different from a Failover event: Dimension Failover Full Port (Portable) Intent Quick recovery and return to primary region when resolved Permanent change of the region Duration Temporary — primary is restored after the event Long-term or permanent — target becomes the new primary Return Expected — traffic and workloads revert to original region Not expected — no return is planned Driver Region fault, outage, or transient unavailability Compliance, cost, sustainability, or strategic decision Transition Time Aiming for RTO Transition can take weeks or months (but it can be designed to serve the Failover purpose and meet RTO and RPO requirements) Transition disruption Minimal — automated or semi-automated failover Managed — gradual migration with a cross-region dependency period The Portable pattern must support both modes and both scopes. A workload that can only be relocated as an atomic all-or-nothing operation has limited practical utility; a workload designed for incremental partial porting is far more executable at scale. Consequences Benefits: Workload can relocate to any Azure region without application changes — eliminates region lock-in. Target region is determined at the time of the trigger, not at design time — unlike Failover's fixed designated standby, the destination can be any eligible region and can change between port events as requirements evolve. Primary architectural mitigation for compliance-driven relocation risks (Geopolitical Risk, Sustainability Constraint). Relocation can be temporary (workload returns after trigger resolves) or permanent — the architecture supports both without distinguishing between them. Liabilities: Portability is costly to establish and maintain; data portability and the abstraction layer add ongoing engineering and toolchain overhead. Data portability is the hardest and most underestimated engineering challenge — relocating compute is straightforward; relocating live data at acceptable cost, latency, and consistency is not. Introduces dependency on the abstraction toolchain — portability conventions must be actively enforced as engineering standards; without governance, individual implementation decisions erode them over time. Risk posture: Risk Assessment Geopolitical Risk ✅ Primary driver — region-agnostic workload relocates to a compliant region; unportable workloads face forced migration under time pressure Sustainability Constraint ✅ Workload moves to a region with the required sustainability profile without application-level changes Regional Service Capacity Constraint ✅ Workload can be relocated to an alternative region with available capacity — addresses both on-demand provisioning failure and sustained shortages Region Fault ✅ Workload can be relocated to an alternative region; recovery speed depends on data portability readiness Service Regional Unavailability ✅ Workload can be redirected to any region where required services are available — portability removes the fixed-region constraint Known uses Workloads subject to data sovereignty or geopolitical obligations that may require region relocation on regulatory notice; sustainability-committed workloads that may need to move to regions with a lower carbon intensity; workloads in rapidly expanding organisations that need to follow business growth into new geographies without rearchitecting. Several patterns are adapted from Gregor Hohpe's cloud strategy patterns: Multi Cloud Architecture: Decisions and Options — Architect Elevator. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. Related patterns Portable vs. Failover — Both result in a workload running in a different region, and a full port and a Hot Standby activation look nearly identical at execution time. The distinctions are fundamental: Failover is a topology (one region is permanently designated as standby); Portable is a property that can be layered on top of any topology. Failover requires a fixed secondary region to be designated at design time — the target is known, pre-provisioned, and not interchangeable. Portable has no fixed target: the destination region is chosen at the time of the trigger, can be any eligible region, and can differ between port events as compliance, cost, or operational requirements change. Failover is triggered by an unplanned disruption and is temporary — the expectation is to return to the original primary when the event resolves. A Portable port is triggered by a deliberate decision and is permanent — the destination becomes the new primary with no planned return. A Failover workload can also be Portable, applying both patterns simultaneously: Failover handles unplanned disruptions; Portable handles deliberate relocation decisions. They are orthogonal — not alternatives. Azure service pattern mapping - sample services Each pattern places specific demands on the services that compose the workload. Some services provide native capabilities — zone redundancy, built-in replication, independent deployment per region, parameterised failover targets — that simplify implementation of specific patterns. Others provide fewer native capabilities, requiring the pattern to be constructed at the deployment and application level. The service examples below illustrate how native capabilities map to pattern implementation for four representative services across IaaS and PaaS. Azure Virtual Machines Azure VMs are IaaS compute — the platform provides the virtualisation layer and the building blocks (Availability Zones, proximity placement, VM scale sets) but leaves resilience orchestration to the operator. This makes VMs fully flexible: every pattern is implementable, but none is provided out of the box — the operator constructs the desired topology. Attribute Value Cross-Region Replication Azure Site Recovery (ASR) — continuous replication to any target region; orchestrated failover supported Deployment model Independent — each VM or scale set is deployed per region with no shared control plane; fully independent instances per region are the norm Provisioning guarantee Capacity Reservations: pre-purchase VM SKU and quantity in any region; eliminates capacity risk at failover or scale-up Pattern implications Single: One region plus Availability Zone redundancy is the default deployment model; AIRM can audit zone distribution across VM resources. Failover: ASR makes Cold, Warm, or Hot standby feasible depending on how much compute is pre-provisioned. Parallel: Independent VM deployments per region behind a global load balancer are feasible; write-conflict handling remains an application responsibility. Segmented: VMs can be partitioned by boundary, region, or workload ownership with independent recovery postures. Portable: VMs are redeployed to the target region using ASR (continuous replication already in place) or fresh IaC deployment with capacity reservations pre-secured; the original region's instances are decommissioned once the target is operational. Azure App Service Azure App Service is a fully managed PaaS application platform. An App Service Plan runs in a single region and provides zone redundancy within that region, but no built-in replication or failover beyond it. Any topology beyond Single Region is constructed at the deployment level using independent plans and external traffic routing. Attribute Value Cross-Region Replication No live replication — the platform does not continuously replicate app content or state between regions; cross-region failover is constructed via independent plans and global traffic routing. Custom backup/restore (Basic tier and above) provides scheduled backup of app files and configuration to a storage account, restorable to any region — this supports Cold Standby and Portable scenarios. Deployment model Independent — each App Service Plan is a standalone regional resource; no shared control plane between plans in different regions Provisioning guarantee Not supported — no mechanism to pre-reserve compute in a target region; a Hot Standby (always-running plan) is the only way to guarantee capacity availability Pattern implications Single: A single App Service Plan in one region with zone redundancy is the normal starting point. Failover: Use independent App Service Plans per region with Front Door or Traffic Manager; the application state must live elsewhere. Parallel: Independent plans per region fit active-active traffic routing, but the data tier must support the write/read pattern. Segmented: Separate plans per boundary or tenant group provide clean ownership and isolation. Portable: A new App Service Plan is deployed in the target region and traffic is routed to it; the original plan is decommissioned once the target is serving production. Connected stateful services (databases, storage) must be independently relocated or already replicated to the target. Azure SQL Database (Business Critical) Azure SQL Database Business Critical is a fully managed relational database with extensive built-in resilience at every level: local high availability within a region (Always On replicas), zone redundancy, and native replication to other regions (active geo-replication, auto-failover groups). This breadth of built-in capability means more patterns are natively supported without additional construction. Attribute Value Cross-Region Replication Active geo-replication: continuously synchronised readable secondary in any region (up to 4 secondaries); auto-failover groups: stable read-write and read-only listener endpoints that survive failover without connection string changes Deployment model Managed instance per region — each database or elastic pool is a regional resource; geo-replication creates linked but independently addressable secondaries Provisioning guarantee No explicit provisioning at current tier — the platform manages the underlying infrastructure. Scaling up or changing service tier is subject to regional capacity availability and subscription quota, as with any Azure service. Geo-replicated secondaries are pre-provisioned and running before any failover, so failover itself does not require on-demand capacity provisioning Pattern implications Single: A single database in one region with zone-redundant replicas provides high availability without additional topology. Failover: Geo-replication and auto-failover groups are the built-in path; the service is natively designed for this pattern. Parallel: Readable secondaries can serve read traffic, but fully symmetric writes across regions are not natively supported. Segmented: Each boundary can own its own database instance and replication policy. Portable: A geo-replica is added on demand in the target region; once seeded, it is promoted to primary via planned failover (no data loss); the original region's replica is then removed. This is natively supported as a database relocation scenario. Azure API Management Azure API Management (APIM) is a fully managed API gateway platform. Within a single region it provides zone redundancy for the gateway. Beyond that, APIM offers a native multi-region deployment capability (Premium tier) that places gateway nodes into additional regions while sharing a single management plane. This makes it representative of services with a shared-control-plane architecture where the data plane scales independently per region. Attribute Value Cross-Region Replication Configuration replicated automatically to all regional gateway units; no stateful data plane — backend data replication is the responsibility of connected services Deployment model Shared control plane — a single APIM instance owns the management plane; additional regional gateway units are extensions of the same instance, not independent deployments Provisioning guarantee Not supported — capacity is allocated per gateway unit (scale units); provisioning additional units in a region before a failover event is the closest equivalent to a reservation Pattern implications Single: One APIM instance in one region with zone-redundant gateway units is viable for region-bound APIs. Failover: Secondary APIM capacity or a second instance can be provisioned, but the management plane must stay consistent. Parallel: The multi-region add-on is a strong native fit; gateway units run in multiple regions behind global routing with shared configuration. Segmented: Separate APIM instances per boundary, or boundary-specific gateway units where shared management-plane control is acceptable. Portable: Gateway units are added on demand in the target region while the original continues serving traffic; once the target is operational, the original region's gateway units are removed — completing the relocation without recreating the instance. Note: the APIM control plane (instance state) remains in the original region where the instance was created; unless a fault renders that region wholly inoperable, this is not an implication for the pattern — the control plane does not carry data-plane cost and does not affect request routing once gateway units are active in the target region. From patterns to a cloud growth strategy The patterns in this article show that regional distribution is not a single decision — it is a spectrum of options, each with a different cost, complexity, and risk mitigation profile. The patterns are not mutually exclusive: a portfolio — or even a single workload — may combine multiple patterns to achieve its reliability, compliance, and operational goals. Having the full range of patterns available does not answer the harder question: which patterns are right for your organisation, which applications need them, and what will it take to get there? That is a strategy question — and it requires a deliberate answer. Most organisations today operate their workloads in the Single Region or Failover pattern. Transitioning from that baseline to Parallel, Segmented, or Portable distribution is not an infrastructure change — it is a programme of work that requires investment justification, architectural readiness, and a governed execution plan. A Cloud Growth Strategy based on regional workload distribution starts by defining the organisation's objectives: what reliability targets must be met, which compliance or sovereignty constraints apply, what operational scale is planned, and where the current estate falls short. From those objectives it derives what the regional footprint should look like for this organisation — not as a generic best practice, but as a concrete commitment about which patterns apply to which parts of the portfolio, at what pace, and at what cost. Conclusion Azure's global footprint makes regional workload distribution a choice for every workload — but not a requirement for all of them. The decision starts with risk: the Risk Catalog identifies which fault types and capacity or compliance constraints are actually relevant to the workload, and what blast radius each carries. From that foundation, five patterns emerge — Single Region, Failover, Parallel, Segmented, and Portable — each resolving a distinct set of forces at a different cost and complexity point. Real Azure services rarely fit one pattern cleanly; the service examples in this article illustrate how capability gaps, consistency models, and replication architectures constrain which patterns are structurally achievable. Translating this into organisational practice requires a deliberate Cloud Growth Strategy: classify applications by criticality, assess their suitability for each pattern against their current state, and produce a governed distribution map that is maintained as the portfolio and platform evolve.Portable Azure topology and documentation snapshots with OSIRIS JSON
Ciao everyone, I’m working on https://github.com/osirisjson/osiris, a vendor-neutral specification for describing infrastructure resources and their relationships as portable point-in-time snapshots. To proof that the specification could work in real-scenarios I already built an initial https://osirisjson.org/en/docs/producers/hyperscalers/microsoft-azure in Go. You run on-premise and it connects through the Azure CLI, reads Azure subscriptions and emits an OSIRIS JSON document that can be used for documentation, topology diagrams, audits, configuration drift analysis, CMDB/IPAM/DCIM workflows, or controlled AI/context workflows without giving those platforms/tools direct access to Azure. The producer currently covers several Azure areas, including networking, compute, storage, identity, databases, containers, integration, observability, backup, automation, management groups, and cross-resource dependency edges such as Private Endpoint to PaaS targets, App Service to Application Insights / Log Analytics, AKS to subnets and node pools, and backup vault relationships. It supports two output purposes: documentation: minimal high-level projection for diagrams, inventory dashboards, and architectural documentation audit: deeper projection with readable properties and extensions after sensitive-field redaction This is not intended to replace Azure tooling, Azure Resource Graph, IaC, Azure Policy, or any existing governance/control-plane workflow. OSIRIS JSON is simply a read-only external producer that generates a vendor-neutral snapshot of the observed Azure environment. I would really appreciate feedback from Azure architects, cloud engineers, and governance practitioners on the mapping model: Which Azure resources and relationships are the most important for documentation and topology generation? Are the current connection types useful for real-world architecture views? What should be prioritized in next releases? Would a documentation/audit split be useful in enterprise environments? You find the current Azure producer documentation here: https://osirisjson.org/en/docs/producers/hyperscalers/microsoft-azure I would really appreciate any feedback, suggestions, edge cases, or ideas from people who operate, document, audit, or govern Azure environments and I also welcome anyone who want to participate on development. Ciao from Italy, Tia
Protect Azure Cosmos DB with vaulted backups using Azure Backup (public preview)
As organizations increasingly rely on Azure Cosmos DB to power mission‑critical, globally distributed applications, protecting this data from accidental deletion, malicious activity, and ransomware has become more important than ever. At MS Build 2026, we’re excited to announce the preview of Azure Backup for Cosmos DB, which introduces vaulted backups—a secure, isolated, and fully managed backup solution designed to strengthen cyber‑resilience and support compliance requirements. Why vaulted backups for Azure Cosmos DB? Azure Cosmos DB already provides built‑in data protection capabilities such as replication and availability features to help ensure application uptime. However, these capabilities alone may not be sufficient to protect against scenarios such as: Accidental or malicious deletion of data or accounts Compromised credentials or insider threats Ransomware attacks targeting production environments Compliance requirements that mandate off‑site, immutable backups Vaulted backups add an independent protection layer by storing backup copies in an Azure Backup vault, isolated from the source Cosmos DB account and managed through Azure Backup. How vaulted backups protect your Cosmos DB data With this preview, Azure Backup enables you to protect Azure Cosmos DB using a policy‑driven, automated backup experience. Once configured, Azure Backup manages backup scheduling, retention, and lifecycle without manual intervention. Key protection capabilities include: Isolation from production data: Vaulted backups are stored in a separate, Microsoft‑managed backup vault, ensuring that backup data remains protected even if the source Cosmos DB account is deleted or compromised. Resilience against ransomware and malicious attacks: Because backups are isolated and protected by Azure Backup security controls, attackers cannot directly access or tamper with recovery points, helping ensure reliable recovery when it matters most. Policy‑based backups with long‑term retention: Define backup schedules and retention periods using Azure Backup policies to support long‑term compliance and audit requirements. Security‑first design: Azure Backup safeguards vaulted backups using encryption, soft delete, immutability, and role‑based access control, helping protect backup data against unauthorized deletion or modification. Designed for compliance and enterprise resilience Vaulted backups for Azure Cosmos DB help organizations align with industry and regulatory expectations that require: Off‑site and isolated backup copies Strong access controls and separation of duties Protection against premature deletion Long‑term retention of critical data By integrating Cosmos DB protection into Azure Backup, customers can manage backups centrally alongside other Azure workloads using a consistent governance and monitoring experience. Getting started with the preview Please refer to the product documentation for details on supported scenarios, limitations, and onboarding steps. For Cosmos DB vaulted backup (preview), you incur charges from, 1 July 2026. Refer to Azure Backup pricing page and pricing calculator for more details.[Now Generally Available] Customizable Security Baseline Policies in Machine Configuration!
Background: Azure Machine Configuration remains committed to enabling greater security and simplicity in at-scale server management for all Azure customers. Machine Configuration (previously known as Azure Policy Guest Configuration) enables both built-in and custom configuration as code allowing you to audit and configure OS, app, and workload level settings at scale, both for machines running in Azure and hybrid Azure Arc-enabled servers. We're excited to announce the General Availability of Customizable Security Baselines in Azure Policy and Machine Configuration. What began as a Public Preview is now a mature, production-grade capability that empowers you to tailor industry security benchmarks to your organization's unique compliance standards across both Azure and Arc-connected machines, at scale. This release moves the experience from "useful" to "everyday default." Standards coverage has expanded, the customization and assignment flow is faster, full lifecycle management is now possible directly from the Azure Portal, and a new Overview page gives you a single pane of glass into which parts of your estate are unprotected. What is Baseline Customization? The core experience remains: tailor security standards through the Modify Settings wizard under Policy > Machine Configuration. You can enable, exclude, or adjust rules from existing benchmarks, apply organization-specific parameters, and export your custom configuration as a downloadable JSON file. Each baseline JSON file serves as a reusable, declarative artifact, ideal for policy-as-code workflows, version control, and CI/CD integration. What's New? GA brings four substantive shifts to the customizable baselines experience: broader standards coverage, a faster path from customization to deployment, lifecycle management directly in the portal, and a new Overview page that surfaces compliance gaps at the subscription level. Together, these changes reflect what we heard from early customers during Preview: that custom baselines need to live alongside the rest of their governance workflows, not in a one-time wizard. This cloud-native approach continues to embody Microsoft's Secure by Design and Secure by Default principles, with a sharper focus on the operational reality of running compliance at scale. Built-in Policy Standards Coverage GA expands what you can customize and where it's supported. Standard Status Notes CIS Benchmarks for Linux Generally Available Expanded distribution coverage since Public Preview. See the full list of supported distros in the official documentation. [NEW!] CIS Benchmarks for Windows Public Preview Initial release covers L1 settings for WS2025 Domain Controller and Member Server roles. Azure Compute Security Baseline for Windows Generally Available Now supports customization for Windows Server 2016 and 2019, in addition to 2022 and 2025. Azure Compute Security Baseline for Linux Generally Available Aligned with Azure Compute recommendations across supported Linux distributions. Key Scenarios Faster Time to Deployment The customization-to-assignment path is now a single continuous flow. You can: Skip the JSON download step entirely. Baseline settings are auto-populated into the Azure Policy assignment flow, so you no longer have to download a JSON file, browse for it, and upload it back. The settings ride with you from Modify Settings straight into Assign Policy. Use the improved settings editor. Role-specific values (Domain Controller, Member Server) and formatted inputs render cleanly in the UX, with validation that prevents malformed parameters from reaching the policy assignment. Still export when you need to. The JSON download remains available for teams that want to commit baselines to source control, share with reviewers, or pipe through CI/CD. The net result: what used to take a multi-step download-and-reupload sequence is now a few clicks inside one blade. Lifecycle Management in the Portal Compliance baselines are not write-once artifacts. They evolve as benchmarks update, as your controls tighten, and as your estate changes. GA introduces two capabilities that treat baselines as living configuration: Import and Modify. From the Definitions tab under Machine Configuration, you can now import an existing baseline JSON and iterate on it directly in the portal. This closes the loop between policy-as-code workflows and ad-hoc edits, so you no longer have to choose between version-controlled artifacts and in-portal convenience. Edit Settings on existing Assignments. The Assignments tab now supports updating an active baseline assignment in place. You can refine rules, adjust role-specific values, or exclude controls without tearing down and re-creating the assignment. All you have to do is select the policy assignment and the "Edit Settings" button should be enabled. Together, these turn baselines into something you maintain, not something you set and forget. New Overview Page: See Where You're Unprotected A new Overview page on Policy > Machine Configuration gives you subscription-level visibility into where Machine Configuration is enabled and where it isn't. For each subscription it surfaces status (At Risk, Not Enabled, Enabled), machines missing prerequisites, machines with prerequisites in place, and total eligible machines. From the same view you can enable Machine Configuration on selected subscriptions to onboard eligible VMs and activate baseline auditing in a single action. This shifts the first question from "is this one machine compliant?" to "which corners of my estate aren't even being assessed yet?", which is usually the more consequential gap. Integration and Automation Security baselines continue to integrate into your DevOps pipelines and configuration management workflows. Each baseline produces a declarative settings catalog (JSON) that can be versioned and deployed using Azure CLI, ARM templates, Bicep, and CI/CD automation, ensuring reproducible, traceable compliance configurations across environments. Availability Customizable security baselines are now generally available in all public Azure regions, Azure Government, and Sovereign Clouds. Getting Started Prerequisites Before you begin: Deploy the Azure Machine Configuration prerequisite policy initiative. (This installs the required Guest Configuration extension on supported VMs.) You can also do this in a single action from the new Overview page. Ensure your Azure subscription or management group includes supported Windows or Linux VMs. Have sufficient permissions (Owner or Resource Policy Contributor) to create and assign custom policy definitions. Step-by-Step Guidance Check your coverage on the Overview page to see which subscriptions are unprotected and onboard them with one click. Select a baseline from the Definitions tab in Machine Configuration or use Import and Modify to iterate on an existing baseline JSON. Modify settings to enable, exclude, or parameterize rules to match your internal policies. Assign the policy directly from the wizard. Settings are auto populated into the assignment flow, no JSON upload required. Iterate when needed. Use Edit Settings on the Assignments tab to refine active baselines in place. Review compliance results to track outcomes in Azure Policy, Azure Resource Graph, or the Guest Assignments page. Learn More Azure Machine Configuration security baselines official documentation CIS Benchmark for Windows Server (Preview) documentation CIS Benchmark for Linux documentation Azure Windows Baseline and Azure Linux Baseline documentation Please note that the use of Azure Machine Configuration on Azure Arc-enabled servers will incur a charge.Introducing the Azure Resource Manager MCP Server!
We're super excited to announce the public preview of the Azure Resource Manager MCP Server! This is a remote MCP server that provides tools to give AI agents first-class access to Azure infrastructure operations through Azure Resource Manager (ARM). AI agents can now be equipped with tools to generate, validate, execute Azure Resource Graph (ARG) queries and tools to deploy and manage ARM template deployments. This server is able to generate and execuite queries that return data across all your Azure resource types! At its core, this server is built to help AI agents interact with Azure resources seamlessly. What this means for you Ask natural language questions about your Azure estate to your agents and get real time, accurate answers backed with an ARG query Deploy and manage infrastructure easily by having AI deploy ARM templates for you Monitor deployment status and catch issues before they escalate Ability to build more advanced AI agents that understand your Azure environment What You Can Do Today Generate, Validate, and Execute Azure Resource Graph Queries from Natural Language No need to struggle with writing KQL from stratch! Describe what you need, and the MCP server tool generates Azure Resource Graph queries that match your intent. You ask an AI Agent: "Find all virtual machines in my subscription that don't have managed disks". It uses the tool and returns: A ready-to-execute ARG query without manual KQL writing. These queries spans across all your azure resource types so can learn and navigate across any type! Deploy, monitor and cancel ARM Templates Pass an ARM template, and the MCP server kicks off the deployment targeted to an existing resource group scope. Monitor the deployment by getting status about it and even cancel it if you decide its not doing what you need it to. Here is the complete list of the tool available in this preview: generate_query validate_query execute_query create_template_deployment get_arm_template_deployment_status cancel_arm_template_deployment Real-World Scenarios Infrastructure Compliance Audit "Show me all resources created in the last 30 days that don't have required tags." - The MCP server generates and executes the query, returning resources that need remediation. Your team can then fix them programmatically or through Copilot. Rapid Infrastructure Provisioning "Using this ARM template <path to template>, deploy a secure storage account with HTTPS-only access, private endpoints, and Standard_LRS replication to my production resource group." This will take an existing ARM template and deploy it to a resource group scope. Policy Compliance Check "Check if all resources in my subscription comply with the latest policy applied to it." - The MCP server generates and executes the query, returning resources that are non-compliant. Your team can then take corrective actions programmatically or through Copilot. Building Agents with Azure Resource Manager MCP Server The MCP server's tools can be integrated into custom agents you build with GitHub Copilot. What this means is you can create custom agents that automatically check compliance, track changes in a scope, or ensure all resources have a particular tag applied to them! Getting Started Prerequisites VS Code installed Valid Azure account with appropriate permissions GitHub Copilot subscription Installation Install the MCP Server Open https://aka.ms/JoinARMMCP VS Code launches automatically Click Install under Azure Resource Manager MCP Server Sign in with your Azure credentials If you hit any authentication issues see Troubleshooting Guide in our repo Check tools are enabled in Chat Open Chat in VS Code (View > Chat) Click Configure Tools Ensure the six Azure Resource Manager MCP Server tools are enabled Start Using It Ask Copilot a question about your Azure resources or infrastructure needs The MCP server handles the rest Governance & Security The Azure Resource Manager MCP Server respects your Azure permissions and governance policies. All operations run in the context of your signed-in user. Additionally you can apply Azure Policies to prevent deployments via the MCP Server. Find more details in the README of our documentation repo. What's Next? We are actively expanding the capabilities of the Azure Resource Manager MCP Server! The Server will expand to include: Additional ARM API capabilities with ARM Enhanced query generation and optimization Support for additional MCP clients beyond VS Code, next up: Claude Get Feedback We want to hear from you. Try the public preview and share your feedback. Found a bug? Or have a feature request? Open an issue on GitHub at https://aka.ms/ARMMCPIssue Resources - 📖 Full Documentation – Complete setup and usage guide - 🔗 Install Now – Get started with the public preview - 🐛 Report Issues – Share feedback and bugs - ❓ FAQ – Common questions answered - 🛠️ Troubleshooting – Resolve common issues Try It Today The Azure Resource Manager MCP Server public preview is available now. Visit https://aka.ms/JoinARMMCP to install and start automating your Azure infrastructure with AI. What agents will you build with these tools? We can't wait to see how you'll use this. Steven Bucher PM on Azure Resource Manager and Azure GovernanceImproper AVD Host Decommissioning – A Practical Governance Framework
Hi everyone, After working with multiple production Azure Virtual Desktop environments, I noticed a recurring issue that rarely gets documented properly: Improper host decommissioning. Scaling out AVD is easy. Scaling down safely is where environments silently drift. Common issues I’ve seen in the field: Session hosts deleted before drain completion Orphaned Entra ID device objects Intune-managed device records left behind Stale registration tokens FSLogix containers remaining locked Defender onboarding objects not cleaned Host pool inconsistencies over time The problem is not technical complexity. It’s lifecycle governance. So I built a structured approach to host decommissioning focused on: Drain validation Active session verification Controlled removal from host pool VM deletion sequencing Identity cleanup validation Registration token rotation Logging and execution safety I’ve published a practical framework here: The framework is fully documented and includes validation logic and logging. https://github.com/modernendpoint/AVD-Host-Decommission-Framework The goal is simple: Not just removing a VM — but preserving platform integrity. I’m curious: How are you handling host lifecycle management in your AVD environments? Fully automated? Manual? Integrated with scaling plans? Identity cleanup included? Would love to hear how others approach this. Menahem Suissa AVD | Intune | Identity-Driven ArchitectureAnnouncing General Availability for Azure Resource Graph (ARG) GET/LIST API
ARG GET/LIST API delivers 10X higher throttling quotas to callers compared to ARG query unlocking a more scalable, resilient way to perform resource lookups in Azure. ARG GET/LIST API is a new platform capability within Azure Resource Graph that provides a high-performance experience for both Point GET and collection GET requests. A key advantage of this capability is its ability to significantly reduce READ throttling for high volume calls efficiently. This is made possible through intelligent control plane routing based on a query parameter controlled by the caller. When a specific query parameter is included, requests are automatically directed to this optimized ARG GET/LIST backend. When the parameter is omitted, requests flow to the Resource provider —ensuring flexibility and backward compatibility. What Challenge Are We Addressing? Azure Read Throttling is a significant challenge for many customers. When services hit throttling limits, applications may experience performance degradation, elevated latency, or even failed requests—issues that can disrupt critical workloads and customer operations. The ARG GET/LIST API is designed to directly address this problem. By routing GET and LIST calls through Azure Resource Graph’s scalable indexing infrastructure and intelligent control-plane routing, it dramatically reduces the likelihood of read throttling. Best of all, it follows the ARM control plane GET APIs request response contract, allowing you to benefit from improved performance and reliability with minimal effort, appending the flag “useResourceGraph=true”. When to use Azure Resource Graph (ARG) GET/LIST API The ARG GET/LIST API is designed for scenarios where you need to retrieve a single resource by its ID or list resources of the same type within a defined scope—whether that's a subscription, resource group, or parent resource. You should consider using the ARG GET/LIST API if your service fits into one or more of the following categories: High Volume of GET Calls Within a Single Scope: Your service issues a large number of GET requests targeting resources within a single subscription or resource group, without the need for cross-subscription queries, complex filters, or joins. Risk of Throttling or Quota Competition: Your service produces a high volume of requests and may encounter issues such as:: Experience throttling during sudden traffic spikes. Quota competition, where other workloads in the same subscription consume shared quota limits, causing your service to be throttled. Bursty traffic patterns, where large volume of GET requests are issued within a short time window, increasing the chance of throttling. Need for High Availability and Faster Performance: Your service depends on consistent; low-latency GET operations for either single-resource lookups or listing resources within a specific scope Note: The ARG GET/LIST API is currently supported only for resources in the resources and computeresources tables. Using the ARG GET/LIST API To get started with the ARG GET/LIST API, begin by assessing whether your scenario aligns with the recommended calling patterns and throttling considerations described earlier. Once confirmed, simply append the parameter &useResourceGraph=true to your eligible GET/LIST API calls. This flag routes your request through the Azure Resource Graph GET/LIST API backend, allowing you to take advantage of its optimized performance and query efficiency. No calls will route to ARG GET/LIST backend automatically. The switch is entirely in the user’s control—the call will route to ARG GET/LIST API only when you explicitly include the useResourceGraph=true parameter in your request. Follow the ARG GET/LIST API contract here - Azure Resource Graph GET/LIST API Guidance - Azure Resource Graph | Microsoft Learn Let’s walk through a simple example of retrieving a Virtual Machine (VM) along with its InstanceView through ARG Query vs. ARM API vs. ARG GET/LIST API to show the difference in the calling experience. Using an ARG Query (via ARG Explorer) In ARG Explorer, you can use Kusto Query Language (KQL) to query resources. A sample query to retrieve a specific VM looks like this: Resources | where type =~ 'microsoft.compute/virtualmachines' | where id =~ '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}' This query filters the Resource Graph index to return the VM resource. Using the ARM (Compute RP) API The equivalent ARM API call to retrieve the VM with InstanceView is: GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView This hits the Compute Resource Provider, pulls the VM state, and expands the instanceView section. Using the ARG GET/LIST API ARG GET/LIST APIs that follow the same request structure as ARM—but with an additional flag that routes the call through ARG: GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView&useResourceGraph=true The important distinction here is the useResourceGraph=true parameter, which routes the call through ARM to serve the response through ARG’s GET/LIST backend. Sample Response - You can find more examples in our documentation - Azure Resource Graph GET/LIST API Guidance - Azure Resource Graph | Microsoft Learn Video Walkthrough Increase Throttling Quota via Azure Resource Graph Learn More Azure Resource Graph GET/LIST API Overview Known Limitations Frequently Asked Questions Share Your Feedback For questions and feedback, you can reach us at Azure Resource Graph team Share Product feedback and ideas with us at Azure Governance · Community Happy Querying!
Optimize Your Cloud Environment Using Agentic AI
In today’s cloud-first world, optimization is no longer a luxury—it’s a strategic imperative. As IT professionals and developers navigate increasingly complex environments, the need to reduce costs, improve sustainability, and accelerate decision-making has never been more urgent. At Ignite 2025, Microsoft is introducing a new wave of agentic capabilities within Azure Copilot—one of the key capabilities includes the optimization agent, designed to help you identify, validate, and act on opportunities to streamline cloud operations. For FinOps teams, this agent becomes especially powerful, enabling cost governance, carbon insights, and actionable recommendations to maximize financial efficiency at scale. From Complexity to Clarity For users familiar with Azure’s cost and performance tools, the new operations center experience in the Azure Portal provides a unified agentic experience to monitor spend and carbon emissions side by side, surface the most critical optimization opportunities, and seamlessly trigger actions by invoking the Optimization agent—bringing governance, efficiency, and sustainability into one streamlined experience. What’s New in Optimization The optimization agent in Azure Copilot empowers teams to: Identify top actions prioritized by impact, cost savings, and ease of implementation. Evaluate cost and carbon impacts side-by-side, helping you make informed decisions that align with financial and sustainability goals. Validate recommendations with supporting evidence, current / projected utilization trends, and alternative SKU choices. Accelerate implementation with step-by-step guidance and agentic workflows that reduce toil and increase confidence. These capabilities are designed to scale FinOps impact, enabling collaboration across engineering, finance, procurement, and sustainability teams—all within a unified experience. A Day in the Life: FinOps in Action Let’s step into the shoes of a FinOps practitioner at a large enterprise navigating the complexities of cost management. It’s Monday morning. Over the weekend, a set of development VMs were left running, quietly accumulating costs. The optimization agent—a capability within Azure Copilot—surfaces a top action: resize or shut down the idle resources. With a few clicks, the practitioner reviews the supporting evidence, including usage trends, cost impact, and carbon footprint. The agent offers visibility over alternative SKUs and guides the practitioner through a step-by-step implementation—all within the same interface. But it doesn’t stop there. For teams that prefer automation or scripting, the agent also generates Azure CLI and PowerShell scripts tailored to the recommended action. This gives practitioners flexibility: they can execute changes directly in the portal or integrate scripts into their existing workflows for repeatability and scale. The experience is seamless—every recommendation is actionable, verifiable, and aligned with enterprise policy. By midweek, the practitioner has implemented multiple optimizations without leaving the console or writing custom code. Each action is logged for audit visibility, ensuring compliance and transparency across the organization. What used to take hours of manual investigation and coordination now happens in minutes, freeing the team to focus on strategic initiatives rather than firefighting cost overruns. Why It Matters These aren’t just features—they’re answers to the pain points customers have been voicing for years. Cost visibility and predictability: Azure Copilot centralizes insights across subscriptions, helping teams avoid surprise bills and understand where every dollar goes. Resource inefficiencies: The optimization agent proactively identifies underutilized resources and guide teams to act before costs escalate. Scalability and complexity: Azure Copilot’s unified experience simplifies operations for even the most complex setups. Azure Copilot isn’t just simplifying cloud operations—it’s transforming how teams collaborate, govern, and optimize. Get Started at Ignite At Ignite 2025, you’ll get hands-on with Azure Copilot’s optimization capabilities. Explore how intelligent assistance can help you: Reduce cloud costs Improve sustainability metrics Strengthen governance and compliance Drive better outcomes—faster Azure Copilot: turning cloud operations into intelligent collaboration. Sign up for the Agents in Azure Copilot Limited (Preview) and try the experience today.
Improve your resiliency posture with new capabilities and intelligent assistance
At Microsoft Ignite 2025, Azure introduces intelligent automation and expanded capabilities to keep your business running—no matter what. From zonal protection and disaster recovery to ransomware defense, discover how the new AI innovations in Azure Copilot helps you move from reactive recovery to proactive resilience.[Public Preview] Introducing Customizable Security Baseline Policies in Machine Configuration
Background: Azure Machine Configuration remains committed to enabling greater security and simplicity in at-scale server management for all Azure customers. Machine Configuration (previously known as Azure Policy Guest Configuration) enables both built-in and custom configuration as code allowing you to audit and configure OS, app, and workload level settings at scale, both for machines running in Azure and hybrid Azure Arc-enabled servers. We’re excited to announce Public Preview support for Customizable Security Baselines in Azure Policy and Machine Configuration. This feature empowers you to tailor industry security benchmarks—such as CIS benchmarks for Linux or Azure Security Baselines for Windows and Linux —to align with your organization’s unique compliance standards across both Azure and Arc-connected machines. This feature builds on top of our existing audit baseline capabilities for Windows and Linux. Now you can create, parameterize, and assign custom baselines at scale, enabling continuous compliance visibility across your entire environment. Learn more about how to get started here: Customize Security Baselines with Azure Policy and Machine Configuration. What's New? Customizable security baselines in Azure Policy and Machine Configuration bring a powerful new way to assess, monitor, and improve your security posture across both Windows and Linux servers. Built on industry benchmarks such as the Center for Internet Security (CIS) and Microsoft’s own Azure Compute Security Baselines, this capability enables you to adapt compliance frameworks to your organization’s specific needs — all while maintaining a consistent governance model across Azure and hybrid environments. By passing custom baseline parameters directly into Azure Policy, you can represent internal controls at scale, ensuring that compliance reflects your enterprise’s unique standards and regulatory requirements. This cloud-native approach embodies Microsoft’s Secure by Design and Secure by Default principles — ensuring your workloads stay compliant, wherever they run. Key Scenarios Baseline Customization Tailor your security standards through the Modify Settings wizard under Policy > Machine Configuration. You can: Enable, exclude, or adjust rules from existing benchmarks Apply organization-specific parameters Export your custom configuration as a downloadable JSON file Each baseline JSON file serves as a reusable, declarative artifact—ideal for policy-as-code workflows, version control, and CI/CD integration. Assign Audit Policies When you assign a baseline via Azure Policy, it automatically: Evaluates configurations against your defined standards Reports compliance in near real time Surfaces findings in Azure Policy, Azure Resource Graph, and the Guest Assignments view This integrated visibility helps IT administrators, security teams, and auditors track compliance status with minimal overhead. Integration and Automation Security baselines integrate seamlessly into your DevOps pipelines and configuration management workflows. Each baseline produces a declarative settings catalog (JSON) that can be versioned and deployed using: Azure CLI ARM templates Bicep CI/CD automation This ensures reproducible, traceable compliance configurations across environments. Supported Standards Standard Description CIS Linux Benchmarks Official CIS Benchmarks for Azure-endorsed Linux distributions, matching the latest CIS versions. Azure Compute Security Baseline for Windows Applies security controls for Windows Server 2022 and 2025, aligned with Azure Compute guidance. Azure Compute Security Baseline for Linux Enforces consistent controls aligned with Azure Compute recommendations. Availability Customizable security baselines are available in all public Azure regions. NOTE: Support for Azure Government and Sovereign Clouds will be added in a future release. These environments are not included in the current Public Preview. Getting Started Prerequisites Before you begin: Deploy the Azure Machine Configuration prerequisite policy initiative. (This installs the required Guest Configuration extension on supported VMs.) Ensure your Azure subscription or management group includes supported Windows or Linux VMs. Have sufficient permissions (Owner or Resource Policy Contributor) to create and assign custom policy definitions. Step-by-Step Guidance Select a baseline from the Machine Configuration tab in Azure Policy. Modify settings to enable, exclude, or parameterize rules to match your internal policies. Download JSON to export your customized baseline configuration file for programmatic and repeatable customization. Assign the policy which can be deployed through the Azure portal, CLI, or your CI/CD pipeline. Review compliance results to track outcomes in Azure Policy, Azure Resource Graph, or the Guest Assignments page. Coming Soon Leverage baseline customization to gradually remediate server security non-compliance using Azure Policy! Join the waitlist here: https://aka.ms/BaselineRemediationWaitlist Learn More Azure Machine Configuration security baselines official documentation CIS Benchmark for Linux documentation Azure Windows Baseline and Azure Linux Baseline documentation Please note that the use of Azure Machine Configuration on Azure Arc-enabled servers will incur a charge.
