Welcome to this lesson on evaluating Azure reservations for predictable workloads.

What do we mean by predictable workloads?

A compute task that has consistent and stable usage over time. Things like always-on services, like domain controllers and web servers, long-running batch processing jobs with a consistent schedule, and steady-state production databases.

These kinds of workloads are ideal candidates for Azure reservations.

What can be reserved? Most services. In compute terms, that includes VMs, SQL Database Compute, App Service Environments, Cosmos DB Throughput, Synapse Analytics, Azure Red Hat Openshift, and Azure VMware Solution.

But other services have reserved models as well, like Azure Blob Storage with capacity reservations.

Apart from our gut instincts, there are a number of tools to help us identify candidates for reservations.

The first of which is Azure Advisor, which provides recommendations for all five pillars of the well-architected framework, including cost savings, which naturally includes reservations.

We don't even need to visit Advisor because the reservation purchase page provides recommendations. I'll show you that shortly.

More manually, we can perform billing analysis in the Cost Management + Billing area of the portal, or we could put even more effort in and create custom dashboards to analyze and visualize VM usage.

How it works: a reservation is for either one or three years, either pay upfront or pay monthly, providing up to a 72% discount on compute.

Once we purchase one, we're locked in, so we need to be certain that we're reserving the right thing.

We can choose the instance size flexibility option, which means we can move to a different size within the same series of VMs, or we can choose capacity priority, which restricts us to that specific VM size but means that if the region is available, we will definitely be able to run our VMs.

If we're using the cloud as our disaster recovery technology, then we really want to be able to get those servers when we ask for them. Although under those circumstances, we'd probably be better off using pay-as-you-go capacity reservations, which don't have any kind of term commitment.

So, we could reserve them just for the two days or whatever we need to get our primary data center back up and running, rather than paying for a one-year reservation that we hope never to have to use.

When we make the purchase, we select a scope. Either shared across all subscriptions within our billing context, a management group, a group of subscriptions, a single subscription, or a single resource group.

We're better off sharing as much as possible so that even if the workload we purchased the reservation for isn't running, something will benefit from the discount.

Remember, we're paying for the reservation whether we're using it or not, so sharing the reservation helps us to make the most of our money.

And here's the reservation purchase page providing recommendations based on 7, 30, or 60 days of usage.

Some do's and don'ts: do start small. We can always buy more reservations.

Use instance size flexibility, or consider savings plans which don't provide as great a discount but do apply to all of our compute consumption, for even more flexibility.

Monitor your reservation utilization. Don't overcommit to reservations (see also: do start small. Forget to account for changes to the workload. Purchase reservations for too narrow a scope.

Key takeaways: Reservations provide major cost savings for predictable workloads.

Azure has tools to help us identify candidates. Evaluate before committing. Monitor reservation usage regularly.

Evaluating Azure Reservations for Predictable Workloads

About