Understanding Shared Capacity Reservations

Key Concepts

• Capacity Reservation: A mechanism to guarantee the availability of specific compute capacity (VM SKUs) in a particular region and Availability Zone (AZ).
• On-Demand Capacity Reservation: Capacity reservations that can be created and deleted at will, with no minimum term.
• Capacity Reservation Group: A parent resource that defines the region and optionally the AZs for capacity reservations.
• Capacity Reservation: Individual reservations within a group, specifying the exact VM SKU and the number of instances to reserve.
• Quota: The maximum amount of a resource that can be created in a subscription, but not a guarantee of availability.
• SLA (Service Level Agreement): A financially backed guarantee of service availability.
• Availability Zone (AZ): Distinct sets of data centers within a region with independent power, cooling, networking, and control planes.
• Shared Capacity Reservations: The ability to share a capacity reservation group with up to 100 other subscriptions.
• Provider Subscription: The subscription where the capacity reservation group is created.
• Consumer Subscription: Subscriptions that are granted permission to use the capacity reservation group.
• Logical vs. Physical AZ Mapping: The mapping of physical AZs within a region to a subscription's logical view of AZs can differ between subscriptions.

On-Demand Capacity Reservations: Guaranteeing Compute Availability

The video introduces the concept of on-demand capacity reservations as a solution to guarantee compute capacity in the cloud, moving beyond the typical assumption of infinite scalability. While cloud providers generally have ample spare capacity, specific requirements for region, availability zone (AZ), and VM SKU can lead to provisioning errors, especially during "rainy day scenarios" like regional disasters or sudden surges in demand.

Key Points:

• The Problem: Standard cloud provisioning relies on available capacity. While quotas define the maximum allowed resources, they do not guarantee their availability. In specific scenarios (e.g., a particular region, AZ, and SKU), capacity might be temporarily unavailable, leading to provisioning failures.
• Capacity Reservation as a Solution: An on-demand capacity reservation provides an SLA-backed guarantee for specific compute capacity. This means you pay for the reserved capacity, and in return, the cloud provider guarantees its availability.
• Prerequisites for Creation:
  • Sufficient quota must exist in the subscription for the target region and SKU.
  • The desired capacity must be available at the moment of creation. If a VM of that SKU cannot be provisioned at that exact time, a capacity reservation cannot be created.
• Structure of a Capacity Reservation:
  • A capacity reservation group acts as a parent resource, defining the region and optionally the AZs.
  • Within the group, one or more capacity reservations are created, each specifying an exact VM SKU and the number of instances to reserve.
• Cost and SLA:
  • You start paying for the capacity reservation as soon as it's successfully provisioned, even if no VMs are currently running in it.
  • This payment triggers the SLA-backed guarantee. The SLA document outlines compensation for minutes of unavailability.
• Provisioning VMs: Once a capacity reservation is active, VMs, virtual machine scale sets, or AKS node pools of the specified SKU and quantity can be provisioned into these reserved slots. You do not pay extra for the VMs themselves; the cost is covered by the reservation.
• Moving Running VMs: A significant enhancement is the ability to move a running VM into a capacity reservation without deallocating it. This is particularly useful for critical VMs that need to be protected against potential provisioning issues during maintenance or unexpected events.
• Restrictions on Moving VMs: A running VM cannot be moved out of a capacity reservation to prevent abuse of the reservation system.
• Interaction with Other Savings Mechanisms:
  • Reserved Instances (RIs): RIs provide a discount for a commitment period but do not guarantee capacity. Combining RIs with capacity reservations is beneficial, especially when specifying exact SKUs and sizes.
  • Azure Savings Plan: Savings plans apply to both used and unused capacity reservation slots.

Shared Capacity Reservations: Expanding Utilization and Flexibility

The introduction of shared capacity reservations addresses the challenge of capacity reservations sitting idle for extended periods, especially in production subscriptions that are not constantly at peak utilization.

Key Points:

• The Challenge of Idle Capacity: In scenarios where a production subscription needs guaranteed capacity for disaster recovery (DR) or critical operations, the reserved capacity might be unused 99.99% of the time, leading to significant costs.
• Sharing Mechanism: A capacity reservation group can be shared with up to 100 other subscriptions.
  • The subscription where the capacity reservation group is created acts as the provider.
  • Other subscriptions granted access become consumers.
• Benefits of Sharing:
  • On "sunny days" (normal operations): Consumer subscriptions (e.g., dev/test, QA, lower-priority workloads) can utilize the reserved capacity, ensuring no money is wasted.
  • On "rainy days" (disasters, scaling events): The provider or consumer subscriptions can shut down lower-priority workloads and provision critical DR or scaled-up applications into the guaranteed capacity.
• Total Consumers: A capacity reservation group can be consumed by the provider subscription plus up to 100 consumer subscriptions, totaling 101 subscriptions.
• Critical Consideration: Logical vs. Physical AZ Mapping:
  • While AZs are distinct physical data centers within a region, each subscription has its own logical view of these AZs.
  • The mapping of a subscription's logical AZ (e.g., AZ 1) to a physical AZ can differ from another subscription's mapping.
  • When sharing capacity reservations, especially those tied to specific AZs, it's crucial to understand this mapping. A VM provisioned in a consumer subscription must target the correct logical AZ that corresponds to the physical AZ where the reservation was made in the provider subscription.
  • The video recommends a separate video and PowerShell script for understanding and managing this AZ mapping.
• Permissions for Sharing:
  • Provider Subscription: The owner of the capacity reservation group needs a Microsoft.CapacityReservation/capacityReservationGroups/share/action permission in the consumer subscriptions.
  • Consumer Subscription:
    • Identities (users, service principals) that will consume the capacity reservation need specific rights (e.g., Microsoft.CapacityReservation/capacityReservationGroups/read, Microsoft.Compute/virtualMachines/write) on the capacity reservation groups and reservations.
  • If an identity has Owner or Contributor roles in both subscriptions, these permissions are often implicitly handled.
• Portal Limitations: At the time of recording, the sharing functionality for capacity reservations was not yet available in the Azure portal. It could be managed via CLI, PowerShell, or ARM templates.

Conclusion

On-demand capacity reservations offer a vital mechanism for guaranteeing compute availability in Azure, moving beyond the limitations of quotas. The introduction of shared capacity reservations significantly enhances their value by allowing organizations to leverage reserved capacity for lower-priority workloads during normal operations, thereby optimizing costs and ensuring critical capacity is available when needed for DR or scaling events. Understanding the nuances of AZ mapping and managing permissions are key to successfully implementing shared capacity reservations.