Azure capacity management

Estate-level capacity and quota management for SaaS ISVs operating workloads in subscriptions they own or control under an Enterprise Agreement (EA) or Microsoft Customer Agreement (MCA). This skill aligns with the ISV landing zone guidance and covers pure SaaS and stamp-based isolation patterns where customers are isolated through dedicated or shared deployment stamps inside the ISV's Azure estate.

Read the full Azure implementation reference at references/docs/operations/capacity-and-quotas/README.md.

FinOps capability mapping

Treat Azure capacity management as implementation detail under the canonical FinOps Framework. Capacity evidence commonly supports Planning & Estimating, Forecasting, Architecting & Workload Placement, Usage Optimization, Rate Optimization, Budgeting, Governance, Policy & Risk, and Automation, Tools & Services. Use Well-Architected capacity planning, reliable scaling, and workload supply chain guidance as Azure implementation guidance, not as a replacement framework. Source Source

Read references/docs/operations/capacity-planning/README.md for forecasting details and references/docs/operations/capacity-governance/README.md for the governance program design.

Quota operations

Azure assigns default quota limits per subscription. EA subscriptions typically start with 350 cores; pay-as-you-go subscriptions start with 20 cores. Some VM series have offer restrictions that block deployment until you request access.

Key workflows:

• Region access: Submit a region access support request when a subscription can't deploy to a restricted region.
• Zonal enablement: Submit a zonal enablement request for restricted VM series in specific availability zones.
• Quota increases: Use per-VM quota requests for individual subscriptions or quota group limit increases for grouped subscriptions.

CLI reference:

# List quota usage for a subscription
az quota usage list --scope /subscriptions/{sub-id}/providers/Microsoft.Compute/locations/{location}

# Request a quota increase
az quota create --resource-name "StandardDSv3Family" --scope /subscriptions/{sub-id}/providers/Microsoft.Compute/locations/{location} --limit-object value=500

Read references/docs/operations/quota/README.md for the complete quota operations reference.

Quota groups

Quota groups are ARM objects that aggregate compute quota across eligible subscriptions at the management group scope. They reduce stranded VM-family headroom and let you request group-level increases.

Prerequisites: Register the Microsoft.Quota resource provider on each member subscription. The management group must exist before creating the quota group.

Limitations:

• IaaS compute only — doesn't cover storage, networking, or PaaS services
• A subscription can belong to a single quota group at a time (source)
• Doesn't grant region or zone access — those require separate support requests
• Quota transfers move allocation between member subscriptions but don't change the group total

Lifecycle: Create the quota group under a management group, add subscriptions, then request group-level limit increases. Monitor allocation snapshots and transfer as demand shifts between subscriptions.

Read references/docs/operations/quota-groups/README.md for the complete reference including ARM lifecycle, transfer mechanics, and monitoring integration.

Capacity reservations

Capacity reservation groups (CRGs) guarantee compute capacity for specific VM sizes in a region or availability zone. CRGs are capacity guarantees, not pricing commitments — unused reserved capacity is billed at the pay-as-you-go rate for the VM size.

Cost implications: Reserved capacity is billed whether or not VMs run against it. Pair CRGs with Azure Reservations or savings plans to get both capacity guarantee and pricing discount.

Sharing (preview): CRGs can be shared across subscriptions within the same tenant. The ODCR owner in the consumer subscription needs Microsoft.Compute/capacityReservationGroups/share/action. The VM owner in the consumer subscription needs Microsoft.Compute/capacityReservationGroups/read, Microsoft.Compute/capacityReservationGroups/deploy, Microsoft.Compute/capacityReservationGroups/capacityReservations/read, and Microsoft.Compute/capacityReservationGroups/capacityReservations/deploy. Portal support isn't available in preview; use CLI, PowerShell, or REST API.

Overallocation: Overallocation lets you deploy more VMs than the reserved quantity. Excess VMs don't have capacity guarantees but benefit from the reservation when capacity is available.

Zone alignment: CRGs are zone-specific. Before sharing across subscriptions, verify logical-to-physical zone mapping with the Get-AzAvailabilityZoneMapping.ps1 script — logical zones can map to different physical zones across subscriptions.

Read references/docs/operations/capacity-reservations/README.md for the complete reference including automation patterns (REST API, Bicep, Terraform).

AKS capacity governance

AKS node pools consume VM quota and can associate with capacity reservation groups, but with constraints specific to the AKS lifecycle:

• Node pool CRG association happens at creation time — you can't associate an existing node pool with a CRG after the fact
• Identity requirement: The AKS cluster must use a user-assigned managed identity with Microsoft.Compute/capacityReservationGroups/read permission on the CRG
• Disassociation removes the CRG association but doesn't delete the node pool
• Zone alignment matters for cross-subscription CRG sharing — verify physical zone mapping before configuring AKS node pools against shared CRGs

Read references/docs/operations/aks-capacity/README.md for the complete reference including Bicep and Terraform examples.

Non-compute quotas

Storage accounts, App Service plans, Cosmos DB throughput, Service Bus namespaces, Key Vault transactions, and other services have their own quota limits outside the compute quota system. Quota groups don't cover these — manage them through standard quota requests and service-specific scaling controls.

Read references/docs/operations/non-compute-quotas/README.md for service-specific quota references.

Monitoring and governance

Three alert types cover the capacity governance space:

1. Quota alerts: Azure Monitor alerts triggered when quota usage crosses a configured threshold. Requires Reader or higher on the subscription.
2. Budget alerts: Cost Management alerts triggered when actual or forecasted spend exceeds budget thresholds. Uses Cost Management RBAC.
3. Anomaly alerts: Cost Management anomaly detection that flags unexpected spending patterns. Deploy with references/scripts/anomaly-alerts/Deploy-AnomalyAlert.ps1 or bulk deploy with references/scripts/anomaly-alerts/Deploy-BulkALZ.ps1.

Governance cadence: Monthly quota reviews, quarterly capacity planning cycles, and post-incident reviews when scaling events fail. Read references/docs/operations/monitoring-alerting/README.md for alert configuration details and references/docs/operations/capacity-governance/README.md for the governance program design.

Scripts quick reference

Read the README in each script directory for parameter requirements and prerequisites.

Key distinctions

These are commonly confused — keep them separated:

• Capacity reservation vs Azure Reservation vs savings plan: Capacity reservations guarantee compute supply. Azure Reservations and savings plans provide pricing discounts. Capacity guarantees supply; pricing commitments reduce cost.
• Quota group vs management group: Quota groups aggregate compute quota. Management groups organize subscriptions for RBAC and policy. Quota groups are created under management groups but don't inherit their policy or access controls.
• Logical vs physical zone: Logical zones are subscription-specific labels. Physical zones are datacenter locations. Zone 1 in subscription A may map to a different physical zone than zone 1 in subscription B.
• Region access vs quota increase: Quota increases raise limits within an already-enabled region. Region access requests unblock a restricted region for the subscription.

Operational agent

The azure-capacity-manager agent is a capacity evidence specialist for FinOps workflows. It handles operational tasks like quota analysis and reservation evaluation, maps Azure capacity evidence back to FinOps capabilities, has access to the same references, and can run scripts and az commands for live operations.

Documentation map

Vendored upstream skills (microsoft/azure-skills)

Content under references/vendor/ is unmodified, byte-identical material copied from microsoft/azure-skills — it is not azcapman-authored, is not edited to fit this skill's voice, and is exempt from AGENTS.md's authored-content rules per the exemption clause in AGENTS.md §1. Full source attribution, license text, and last-synced commit are in references/vendor/MANIFEST.md.

The three whole-skill copies (azure-quotas, azure-cost, azure-aigateway) keep their own internal SKILL.md structure for their own references and scripts — they are not separately registered as standalone skills in this repo; this skill is the only discovery path into them.

Updating vendored content

references/vendor/ is refreshed manually, not by a script or scheduled job. To update it:

1. For each of the 8 paths listed in references/vendor/MANIFEST.md, re-fetch the file from microsoft/azure-skills's main branch (e.g. via gh api or curl against raw.githubusercontent.com/microsoft/azure-skills/main/<path>) and overwrite the vendored copy byte-for-byte.
2. Verify each file with git hash-object <file> against the new upstream blob SHA (from the GitHub API for that path) to confirm an exact copy — no manual retyping or edits.
3. Update MANIFEST.md's "last synced" commit SHA and date to the new commit.
4. Note any files added or removed upstream within those same 8 paths in MANIFEST.md. This is a refresh of existing content, not a re-scoping exercise — the 8-target list itself only changes via a deliberate, separate decision, not as a side effect of a routine sync.

Notification procedures

The capacity manager can send alerts and reports through SRE Agent's notification connectors. Use Teams for urgent capacity events and email for periodic reports.

Teams channel alerts

Use Teams notifications for urgent capacity events that need immediate attention, following the Azure SRE Agent notification guidance. The SRE Agent sends messages through the Teams connector in HTML format, so keep the payload compact, scannable, and action-oriented, as described in Send notifications from Azure SRE Agent.

When to send Teams alerts:

• Quota utilization exceeds 80 percent for any VM family in a production region.
• VM deployment fails with a quota or capacity error.
• Capacity reservation group utilization drops below 50 percent, which points to wasted spend.
• Quota group is depleted or nearly depleted.
• Region access or zonal enablement request is needed.

Teams alert template:

Use this HTML template when you compose a Teams message. Include alert severity, the affected resource, current state, the recommended action, and links to the relevant Azure portal blades, following Send notifications from Azure SRE Agent.

<h3>⚠️ Quota utilization alert</h3>
<p><b>Severity:</b> warning<br>
<b>VM family:</b> Standard_D_v5<br>
<b>Region:</b> eastus<br>
<b>Subscription:</b> prod-001<br>
<b>Usage:</b> 85/100 vCPUs (85%)</p>
<p><b>Recommended action:</b> Request a quota increase before the next deployment cycle.</p>
<p>
  <a href="https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade">Open quota blade</a><br>
  <a href="https://portal.azure.com/#view/HubsExtension/BrowseResource/resourceType/Microsoft.Compute%2FcapacityReservationGroups">Open capacity reservation groups</a>
</p>

Email capacity reports

Use Outlook email for periodic capacity reports and non-urgent recommendations, following the same Azure SRE Agent notification guidance. The SRE Agent sends email through the Outlook connector in HTML format, so structure the message for scanning first, and detailed follow-up second.

When to send email reports:

• Weekly capacity digest, including quota utilization trends across the estate.
• Reservation expiring within 30 days, including a renewal recommendation and cost analysis.
• Monthly savings plan optimization review.
• Quarterly capacity planning summary.
• Post-incident capacity analysis.

Email report template:

Use this HTML template for email reports. Include the report title, date range, a summary table of key metrics, highlighted findings, recommended actions with priority, and links to Azure portal resources or supporting documentation, as described in Send notifications from Azure SRE Agent.

<h2>Weekly capacity digest</h2>
<p><b>Period:</b> March 3–9, 2026<br>
<b>Subscriptions analyzed:</b> 47</p>
<h3>Key findings</h3>
<table border="1" cellpadding="8">
<tr><th>Region</th><th>VM family</th><th>Utilization</th><th>Action</th></tr>
<tr><td>eastus</td><td>Standard_D_v5</td><td>92%</td><td>Request increase</td></tr>
<tr><td>westus2</td><td>Standard_E_v5</td><td>78%</td><td>Monitor</td></tr>
</table>
<h3>Recommendations</h3>
<ol>
<li>Request quota increase for Standard_D_v5 in eastus (critical)</li>
<li>Review CRG utilization in westeurope—45% utilized, consider right-sizing</li>
<li>Savings plan expires April 15—evaluate renewal versus pay-as-you-go</li>
</ol>
<p>
  <a href="https://portal.azure.com/#view/Microsoft_Azure_Capacity/QuotaMenuBlade">Open quota blade</a><br>
  <a href="https://learn.microsoft.com/en-us/azure/quotas/how-to-guide-monitoring-alerting">Review quota monitoring guidance</a>
</p>

Scheduled notification patterns

Configure recurring notifications with Azure SRE Agent scheduled tasks, and pair the schedule with the connector flow from Send notifications from Azure SRE Agent.

• Daily: quota utilization check, then send a Teams alert if any family is above 80 percent.
• Weekly: capacity digest, then send email to stakeholders.
• Monthly: savings plan and reservation review, then send email with recommendations.