# Committed use discount

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/committed-use-discount

## Quick definition

A committed use discount is a way to save money on cloud services by making a promise to use a certain amount of resources for one or three years. In return, the cloud provider gives you a lower price, often 30% to 70% less than standard pay-as-you-go rates. This is common with services like virtual machines and databases. It helps businesses lower their IT costs when they know their usage will be steady.

## Simple meaning

Think of a committed use discount like a gym membership. If you pay for each visit separately, it costs more per visit. But if you commit to a yearly membership, the cost per visit drops significantly because the gym knows you’ll keep coming. In cloud computing, you tell the provider something like, “I will use 10 virtual machines for the next three years.” The provider then gives you a big discount because they can plan their own resources and know they will have your business.

This commitment is not about paying upfront; it is about promising to use a certain amount of computing power, memory, or storage. You are charged for the committed amount every month regardless of whether you actually use it. If you use more than your commitment, you pay the regular pay-as-you-go rate for the extra. If you use less, you still pay for the full committed amount. This makes it best for predictable workloads, like a company’s internal website that runs all the time, because you know exactly how much you need.

The discount applies to the specific types of resources you commit to, such as a certain number of virtual machine instances or a set amount of database capacity. You cannot change your mind without paying a cancellation fee, so it is a serious decision. Many cloud providers like AWS call this a Reserved Instance, Google Cloud calls it a Committed Use Discount, and Azure uses Reserved VM Instances. The core idea is the same: commit to steady usage and save money.

## Technical definition

A committed use discount is a contractual pricing mechanism offered by cloud service providers (CSPs) that allows customers to reserve a specified quantity of compute resources for a defined term (typically one or three years) in exchange for a significantly reduced hourly or monthly rate compared to on-demand pricing. This model is foundational to cost optimization in cloud computing, as it aligns a customer’s predictable resource consumption with the provider’s capacity planning and operational efficiency.

Under the hood, the committed use discount functions as a rate discount applied to eligible resource usage. When a customer purchases a commitment, they specify the resource type (e.g., general-purpose virtual machines, memory-optimized instances), the region, the term length, and the payment option (all upfront, partial upfront, or no upfront). The CSP then applies a discount rate to the resource’s on-demand price for the duration of the commitment. For example, an AWS m5.large Reserved Instance with a one-year term and all upfront payment might receive a 40% discount off the standard on-demand hourly rate. The actual discount percentage varies by provider, region, instance family, and term length.

Importantly, the committed use discount is not a physical resource allocation; it is a billing concept. The customer does not receive dedicated hardware or guaranteed capacity in most cases. Instead, the discount is automatically applied to matching resource usage each billing hour. If the customer has multiple resources that match the commitment attributes, the discount is shared across them. For example, if you commit to 10 vCPUs in the us-east-1 region for a general-purpose instance type, and you run two instances with 4 vCPUs each and one with 2 vCPUs, all three instances will receive the discounted rate as long as the total vCPU count does not exceed 10.

However, there are technical nuances. If the customer stops using the committed resources entirely, they are still billed for the commitment. Some providers offer flexibility through convertible commitments, which allow changing instance attributes (like moving from general-purpose to compute-optimized) within the same family, though often at a slightly lower discount. Committed use discounts are applied at the account or organization level, meaning that if a company has multiple accounts under a single billing entity, the discount can cover usage across all of them. This is known as sharing of benefits.

From a financial perspective, the committed use discount is a form of demand aggregation. The CSP uses the commitment to forecast demand, manage data center capacity, and purchase hardware at bulk rates. The savings are then passed to the customer. The break-even analysis is critical: if the customer’s actual usage falls below the committed level for sustained periods, the discount may not provide overall savings compared to on-demand. Therefore, IT professionals must monitor usage patterns using tools like AWS Cost Explorer, Google Cloud’s Recommender, or Azure Cost Management to identify which resources are good candidates for commitment.

In terms of implementation, a committed use discount is purchased through the provider’s console, CLI, or API. For example, in AWS, you use the EC2 console to purchase a Reserved Instance, selecting the instance type, scope (regional or zonal), term, and payment option. Once purchased, the discount takes effect immediately. There is no physical deployment; the discount simply modifies the billing rate. For large enterprises, the decision to commit often involves finance teams and cloud architects working together to analyze historical usage data and predict future needs. Providers also offer recommendations based on past usage, helping customers choose commitments that maximize savings without overcommitting.

## Real-life example

Imagine you run a small bakery, and you buy flour from a local supplier. If you buy flour one bag at a time each morning, you pay the full retail price. But suppose you talk to the supplier and say, “I will buy 100 bags of flour every month for the next two years.” The supplier is happy because they can order large quantities and plan their inventory. They give you a 50% discount on each bag. You win because your cost per bag drops. The supplier wins because they have guaranteed sales.

Now, here’s the catch: even if you have a slow month and only use 80 bags, you still must pay for 100 bags because that was your commitment. You cannot return the extra bags. But the next month, if you need 120 bags, you get the first 100 at the discounted price and pay full price for the remaining 20. That is exactly how a committed use discount works in cloud computing. You commit to a certain number of virtual machine hours or database capacity, and the cloud provider gives you a lower rate. If you use less, you still pay for the full commitment. If you use more, the extra is charged at the on-demand rate.

This analogy also highlights the importance of using committed discounts for predictable workloads. Just as a bakery knows roughly how much flour it needs every month because it bakes the same number of loaves daily, a company knows that its customer-facing website needs a fixed number of servers running 24/7. That kind of steady usage is perfect for a committed use discount. On the other hand, if your usage varies wildly, like a bakery that suddenly needs 500 bags for a festival but only 20 bags the next week, a commitment might not save you money because you will end up paying for unused capacity.

## Why it matters

Committed use discounts matter because cloud computing costs can spiral out of control without careful management. Many organizations start with pay-as-you-go pricing, which is flexible but expensive for long-running, predictable workloads. For example, running a set of 10 virtual machines continuously for three years at on-demand rates can cost significantly more than committing to those resources. In a large enterprise, the savings from committed use discounts can amount to hundreds of thousands of dollars per year, directly impacting the bottom line.

From a practical IT perspective, implementing committed use discounts requires a shift in how teams think about resource procurement. Instead of treating cloud resources as infinitely elastic and always pay-as-you-go, teams must analyze their usage patterns and identify resources that run consistently. This often leads to better capacity planning and governance. For instance, a DevOps team might discover that their development and test environments, which run 12 hours a day, are not good candidates for a three-year commitment, while production databases that run 24/7 are ideal.

Another reason it matters is that committed use discounts are not just about cost savings; they are also about financial predictability. By locking in a discount for a known workload, a company can forecast its cloud spending more accurately. The finance department can budget for the committed amount each month and avoid surprises. This is crucial for companies that must report cloud costs to stakeholders or that manage multiple cost centers.

cloud providers often adjust their on-demand prices, but a committed discount locks in a fixed rate for the term. This protects organizations from price increases. For example, if a provider raises on-demand rates by 10% over two years, the customer with a committed use discount is shielded from that increase for the duration of their term. However, this also means that if on-demand prices drop, the customer cannot benefit from the lower rate without converting or canceling the commitment, which may incur fees.

Finally, committed use discounts are a core component of cloud financial management (FinOps). In a mature cloud practice, teams use tools to continuously monitor utilization and recommend new commitments when usage is stable. They also track the expiration of commitments to avoid reverting to on-demand rates unexpectedly. Without this, an expired commitment can cause a sudden spike in costs, undoing months of savings. Therefore, understanding committed use discounts is not optional for IT professionals who manage cloud budgets; it is a fundamental skill.

## Why it matters in exams

Committed use discounts appear in several major cloud certification exams, including the AWS Certified Solutions Architect (Associate and Professional), AWS Certified SysOps Administrator, Google Cloud Associate Cloud Engineer, Google Cloud Professional Cloud Architect, Microsoft Azure Administrator (AZ-104), and Azure Solutions Architect (AZ-305). In these exams, the term is often tested as a cost optimization strategy. The objective map for these certifications includes a section called “Cost Management” or “Optimizing Costs,” where committed use discounts are a primary concept.

In AWS exams, candidates must know the difference between Reserved Instances (RIs) and other savings options like Savings Plans. A common exam objective is to choose the right pricing model for a given scenario. For example, a question might describe a company running a batch processing job that runs every day for four hours. The candidate must determine that a Reserved Instance is not ideal because the usage is not 24/7. Instead, a Spot Instance would be better. Conversely, for a web application that runs 24/7, a Reserved Instance is the appropriate choice.

In Google Cloud exams, the term is called Committed Use Discount (CUD). Candidates must understand that CUDs apply to both vCPUs and memory separately. A typical exam question may involve a scenario where a company has a predictable database workload and asks which pricing model reduces costs the most. The answer would be to purchase a one-year or three-year CUD for the specific machine series and region.

For Azure exams, the equivalent is Azure Reserved VM Instances. Candidates must know that reservations can be shared across multiple subscriptions within the same billing account. A scenario may show a company with multiple development and production subscriptions and ask how to maximize savings, the correct answer is to purchase a reservation at the management group scope and share it.

In all these exams, questions often test the trade-offs between payment options (all upfront, partial upfront, no upfront) and term lengths (1 year vs. 3 years). A common trap is that students think “no upfront” means no commitment, but it still requires a one- or three-year term. Another trap is believing that a committed use discount guarantees capacity. In most cases, it only provides a discount but does not reserve capacity. Only “Capacity Reservations” or “Reserved Capacity” (an add-on feature in some providers) guarantees capacity.

exams test the ability to calculate total cost of ownership (TCO) using committed discounts. A question might provide the on-demand hourly rate, the discounted rate, and the number of hours a resource runs, and ask the candidate to compute the savings over the term. These quantitative questions require careful reading of the payment option, as all-upfront payments have higher savings but also require capital expenditure.

Finally, the exams emphasize that committed use discounts are not applicable to all services. For example, AWS RIs are only for EC2 and RDS, while Savings Plans cover a broader set of compute services. Google CUDs apply to Compute Engine and certain Google Kubernetes Engine resources. In Azure, reservations are available for Virtual Machines, SQL Database, and App Services. Knowing these boundaries is critical for exam success.

## How it appears in exam questions

Committed use discount questions often take the form of scenario-based multiple choice or complex multi-part questions. In AWS certification exams, a typical pattern is: “A company runs a production web application on 20 EC2 instances in us-east-1. The application runs 24/7 and the team expects the same workload for the next three years. What is the most cost-effective pricing model?” The correct answer is to purchase EC2 Reserved Instances with a three-year term and all upfront payment. Distractors might include Spot Instances (not for 24/7), On-Demand (too expensive), or a Savings Plan (also valid but RIs may be cheaper for specific instance families).

Another common question pattern involves scenarios where a company has committed to resources but later needs to change instance types or stop using them. For example: “A company purchased a three-year Reserved Instance for an m5.large instance, but after one year, they need to upgrade to an m5.xlarge. What should they do?” The correct answer is to sell the existing RI on the Reserved Instance Marketplace and purchase a new one for the m5.xlarge or, if convertible RIs were used, modify the RI to the larger size. The distractor would be that the discount automatically applies to the larger instance, which it does not.

In Google Cloud exams, questions often present a scenario with a mix of workloads and ask for the optimal use of Committed Use Discounts. For instance: “Your company runs a set of n1-standard-4 instances for a batch processing job that runs for 12 hours every day. The job is flexible and can be interrupted. What is the best pricing strategy?” The correct answer is to use Preemptible VMs for the batch job because of the interruptibility and low cost, and not a CUD, because the usage is not continuous. A distractor might be to purchase a CUD for maximum savings, but the candidate must realize that the workload is not steady-state.

Configuration questions also appear. For example: “A company using AWS has two accounts: production and development. They want to use a single Reserved Instance purchase to cover both accounts. How should they configure the purchase?” The answer is to purchase the RI with the scope set to “Regional” and enable RI sharing via the AWS Organizations console. Alternatively, in Azure, the question might be about setting the reservation scope to “Shared” so it applies to multiple subscriptions.

Troubleshooting questions can appear as well. For example: “A company purchased a Reserved Instance for an m5.large in us-east-1a. They notice that the discount is not being applied. What is the most likely cause?” The answer could be that the instance is running in us-east-1b, and the RI was zonal rather than regional. Or the instance size or family does not match (e.g., they purchased an RI for a t3.large but are running an m5.large). These questions test the candidate’s understanding of how discounts are matched to resources.

Finally, some exams include questions about the financial impact of cancellation. For example: “A company wants to cancel a three-year Reserved Instance after six months. What will happen?” The answer is that cancellation is not allowed; they must continue paying for the entire term. However, they can sell the RI in the Reserved Instance Marketplace. The goal is to test knowledge about the rigid nature of commitments.

## Example scenario

A mid-size e-commerce company runs its website on 10 virtual machines in the cloud. These VMs run 24 hours a day, 7 days a week, because customers shop at all hours. The company knows that they will need these 10 VMs for at least the next two years because they have no plans to change their platform. Currently, they are paying the on-demand rate of $0.10 per hour per VM, which totals about $17,520 per year (10 VMs x 0.10 x 24 x 365). That is $35,040 over two years.

Their cloud provider offers a committed use discount: if they commit to using these 10 VMs for one year, the hourly rate drops to $0.06 per hour, a 40% discount. For a two-year term, the discount goes to $0.05 per hour. The company decides to commit to a one-year term, so they pay $0.06 per hour for each VM. Their new yearly cost is 10 x 0.06 x 24 x 365 = $5,256 per year, down from $8,760. They save $3,504 in the first year.

However, after six months, the company launches a new marketing campaign that drives a lot more traffic. They need to temporarily add 2 more VMs to handle the load. Because they only committed to 10 VMs, the extra 2 VMs are billed at the on-demand rate of $0.10 per hour. That is fine because the extra traffic lasts only two months. At the end of the year, they renew their commitment for another year, this time committing to 12 VMs because they expect the higher traffic to continue.

Now imagine that instead of the campaign working, the company faces a downturn and needs to reduce their VM count to 5 for a few months. Even though they are not using all 10 committed VMs, they still pay the full committed amount because the discount is based on their promise, not their actual usage. This scenario teaches a valuable lesson: committed use discounts work best when future resource needs are certain. For the e-commerce company, the savings were significant, but they also took a risk that they would not need to reduce capacity. In this case, the risk paid off because their business grew.

## How Committed Use Discount Cost Mechanics Work

Committed Use Discounts (CUDs) are a critical cost optimization tool in cloud computing, particularly within Google Cloud Platform (GCP). They offer significant savings in exchange for a commitment to use a minimum level of compute resources for a fixed term, typically one or three years. Understanding the cost mechanics is essential for IT professionals preparing for cloud certification exams like the Google Cloud Associate Engineer or Professional Cloud Architect. 

 At its core, a Committed Use Discount operates on a pricing model where you agree to pay for a certain amount of compute capacity (measured in vCPUs, memory, or both) for a specified duration. In return, the cloud provider applies a discounted rate to your usage, often ranging from 20% to 70% off the standard on-demand prices. The exact discount percentage depends on the type of resource, the term length (one-year vs. three-year), and whether you choose a flexible or rigid commitment. For exam purposes, you should memorize that three-year commitments offer deeper discounts than one-year ones, and that committing to resources like memory-optimized machine types can yield higher savings because those resources are typically more expensive on demand. 

 A key nuance in the cost mechanics is how CUDs are applied. They are not prepaid; instead, you are billed monthly for the committed amount, even if you do not use it. However, the discount applies to any eligible usage that matches the commitment, regardless of the specific machine type, region, or project. For example, if you commit to $100 worth of vCPUs per month, any vCPU usage within the same resource category (e.g., general-purpose) will be charged at the discounted rate, up to the committed amount. Usage beyond the commitment is billed at full on-demand rates. This pay-as-you-go component for overage is a frequent exam trap-candidates often assume discounts apply to all usage, but they only apply to the committed portion. 

 Another important cost consideration is the concept of “flexible” vs. “rigid” commitments. Flexible CUDs allow you to change machine families, regions, or even resource types within the same commitment, as long as the total resource consumption stays within the committed amount. Rigid commitments lock you into a specific configuration. For cost optimization, flexible CUDs are recommended because they provide more agility, though they may offer slightly lower discount rates. Exams often test your understanding that flexible CUDs are generally the better choice for most enterprise workloads due to their adaptability. 

the billing cycle for CUDs is monthly, and you must continue paying for the commitment even if you delete or stop the resources. This is a critical point for cost management-if you decommission a project, you still incur the committed cost unless you transfer the commitment to another project in the same billing account. This transferability is a key feature that helps avoid waste. In exam scenarios, you might be asked how to handle a situation where an organization wants to optimize costs after a migration: the correct approach is to analyze historical usage, identify steady-state workloads, and then purchase CUDs for those resources, ensuring the commitment period aligns with business plans. 

note that CUDs are applied at the billing account level, not the project level. This means that if you have multiple projects under one billing account, the combined usage across all projects counts toward the commitment. This pooling effect is beneficial for large organizations with distributed workloads. For example, if you commit to 100 vCPUs, and Project A uses 60, while Project B uses 40, the total is 100, and all usage gets the discount. This is a common exam point because it contrasts with other discount models like sustained use discounts, which are per project. 

 Finally, understanding the cost mechanics of CUDs requires familiarity with the billing reports in the Cloud Console. You should know how to identify underutilized commitments (where usage is less than the committed amount) and how to adjust them. The exam might present a scenario where you recommend whether to purchase a new CUD or let an expiring one renew, based on predicted usage trends. The cost mechanics of CUDs revolve around committing to a fixed monthly spend in exchange for a reduced rate, with flexibility options and billing account-level aggregation being pivotal concepts.

## Committed Use Discount Best Practices and Common Exam Scenarios

When studying for cloud certifications, mastering the best practices for Committed Use Discounts (CUDs) is paramount. CUDs are not a one-size-fits-all solution; they require careful planning and analysis to maximize savings. This section focuses on practical strategies and exam-specific scenarios that test your ability to apply these concepts in real-world situations. 

 The first best practice is to only commit to resources that have steady, predictable usage over at least one year. Workloads that are sporadic or bursty-such as batch processing or development environments that run only during business hours-are poor candidates for CUDs because you would pay for idle capacity. For exam questions, you might be asked to analyze a company’s usage patterns: a 24/7 production web server is ideal, while a data pipeline that runs once a week is not. The key takeaway is that CUDs are for baseline, not variable, workloads. 

 Another critical best practice is to start with a small commitment and gradually increase. This approach avoids overcommitting, which is a common mistake. For example, if a company’s current usage is 100 vCPUs but they expect growth, it is better to commit to 80 vCPUs initially and use on-demand for the rest. As usage stabilizes, they can purchase more CUDs. This strategy is often tested in scenarios where you must choose a cost-optimized plan for a growing startup. The correct answer usually involves a combination of flexible CUDs and on-demand or preemptible VMs. 

using the “recommendations” feature in the Cloud Console is a best practice. GCP’s recommender engine analyzes historical usage and suggests optimal CUD purchases. For exams, you should know how to interpret these recommendations, which include a commitment amount, term, and estimated savings. A typical exam question might present a recommender output and ask whether to accept or adjust it. The trick is to understand that the recommendation is based on past data, so you must also consider future changes-like migrating to different regions or using spot VMs-before committing. 

 A common exam scenario involves companies that have multiple accounts or complex organizational structures. For instance, you might be asked how to allocate CUDs across a parent and subsidiary. The correct approach is to use a single billing account to pool usage, because CUDs cannot span across different billing accounts. This is a frequent pitfall: candidates might assume that separate billing accounts lead to separate discounts, but in reality, the discount is applied per billing account. 

 Another scenario tests your understanding of what happens when a committed use discount expires. If a three-year commitment ends, your bill suddenly increases because all usage reverts to on-demand rates. The best practice is to set up automatic renewal or proactively purchase new CUDs before expiration. In exams, you might be asked to identify cost spikes in a billing report-the root cause is often an expiring CUD. The solution is to configure budget alerts or use the CUD dashboard to track expiration dates. 

 Importantly, there is a common misconception that CUDs are available for all compute resources. In reality, they primarily cover Compute Engine (VM instances) and a few other services like Cloud SQL, but not serverless products like Cloud Functions or App Engine. Exam questions often use this as a distractor: a candidate might suggest a CUD for a serverless workload, which would be incorrect. Always associate CUDs with virtual machine instance families. 

 Finally, best practices include combining CUDs with other discount mechanisms. For example, using preemptible VMs for fault-tolerant tasks alongside CUDs for baseline workloads achieves maximum savings. This multi-layered strategy is a common exam topic because it demonstrates a holistic understanding of cost optimization. For instance, you might be asked to design a cost-effective architecture for a batch processing application: the answer could involve using CUDs for the always-on coordinator nodes and preemptible VMs for the worker nodes. By internalizing these best practices and exam scenarios, you will be well prepared to answer any question about Committed Use Discounts.

## Common mistakes

- **Mistake:** Assuming a committed use discount applies to all cloud services automatically.
  - Why it is wrong: Committed use discounts are typically offered only for specific resources like virtual machines, databases, and certain compute services. They do not apply to storage, networking, or serverless functions unless separately specified.
  - Fix: Check the provider’s documentation to confirm which services are eligible for the discount. For AWS, Reserved Instances cover EC2 and RDS. Google CUDs cover Compute Engine and GKE resources. Azure Reservations cover VMs, SQL DB, and App Services.
- **Mistake:** Believing that paying no upfront means no commitment or obligation.
  - Why it is wrong: The “no upfront” option in a committed use discount still requires you to commit to a one-year or three-year term. You are billed monthly at the discounted rate for the entire term. It does not mean you can cancel anytime without penalty.
  - Fix: Read the terms carefully. “No upfront” only means you are not paying the full amount at the start. The commitment to use the resources for the full term remains binding.
- **Mistake:** Assuming the discount guarantees reserved capacity or performance.
  - Why it is wrong: A committed use discount only reduces the billing rate. It does not guarantee that the resources will be available when you need them unless you also purchase a separate capacity reservation. During resource shortages, you may not be able to launch instances even with an active discount.
  - Fix: If your workload requires guaranteed capacity, use a capacity reservation in addition to the discount. For example, AWS offers “Capacity Reservations” for EC2, which can be combined with Reserved Instances.
- **Mistake:** Thinking that any usage of the committed resource type will get the discount regardless of region or configuration.
  - Why it is wrong: Discounts are scoped to a specific region, instance family, and sometimes a specific availability zone. If you purchase a commitment for an m5.large in us-east-1, an m5.large instance running in us-west-2 will not receive the discount. Similarly, a t3.large instance in us-east-1 will not match an m5.large commitment.
  - Fix: Plan your commitments carefully. When purchasing, specify the exact region and instance family. If you have resources in multiple regions, you need separate commitments for each. Use regional scope (instead of zonal) to gain flexibility within a region.
- **Mistake:** Overcommitting based on peak usage rather than average steady usage.
  - Why it is wrong: If you commit to resources based on your highest usage spikes, you will pay for unused capacity during low-usage periods. This can result in higher overall costs than using on-demand for the peaks and paying for the base level with a smaller commitment.
  - Fix: Analyze your usage patterns over several months. Commit only to the baseline usage that runs consistently. For variable or burstable workloads, use on-demand or spot instances to cover the peaks.

## Exam trap

{"trap":"Confusing Savings Plans with Reserved Instances (or equivalent terms) regarding flexibility and scope.","why_learners_choose_it":"Learners think that Savings Plans cover everything that Reserved Instances do, but they are tempted because Savings Plans are often presented as more flexible. In exam scenarios with specific instance families or regions, they might incorrectly choose a Savings Plan when a Reserved Instance would be cheaper for a fixed workload.","how_to_avoid_it":"Remember that Reserved Instances offer deeper discounts for a specific instance family, while Savings Plans offer a bit less discount but more flexibility across instance families and regions. Use Reserved Instances when the workload is predictable and the instance family is fixed. Use Savings Plans when you have variable compute usage across different services. In the exam, read the scenario: if it says “use the same instance type for three years,” pick Reserved Instance. If it says “run different compute services or likely change instance types,” pick Savings Plans."}

## Commonly confused with

- **Committed use discount vs Savings Plans:** Savings Plans are similar to committed use discounts but offer more flexibility. With a Savings Plan, you commit to a dollar amount of compute spend per hour, and the discount applies to any compute usage, regardless of instance family or region. In contrast, a committed use discount (like a Reserved Instance) is tied to a specific instance type and region. Savings Plans are simpler to manage, but the discount is usually slightly lower than a dedicated Reserved Instance for the same term. (Example: If you commit to spending $100 per hour via a Savings Plan, you get a discount on any EC2, Fargate, or Lambda usage. With a Reserved Instance, you commit to 10 m5.large instances specifically, and only those get the discount.)
- **Committed use discount vs Spot Instances:** Spot Instances are unused cloud capacity sold at a discount of up to 90%, but they can be terminated by the provider at any moment with a short notice. Committed use discounts are stable and cannot be terminated, but they are only 30% to 70% off. Spot is for fault-tolerant, interruptible workloads, while committed use is for steady-state, critical workloads. (Example: Running a batch data analysis job that can be paused and resumed? Use Spot Instances. Running a customer database that must be up 24/7? Use a committed use discount.)
- **Committed use discount vs Capacity Reservations:** Capacity Reservations guarantee that the resources will be available in a specific availability zone when you need them. However, they do not provide any discount; you pay the on-demand rate. A committed use discount offers lower pricing but does not guarantee capacity. To get both a discount and guaranteed capacity, you must combine a committed use discount with a capacity reservation. (Example: You purchase a Reserved Instance for a discount but also buy a Capacity Reservation in the same availability zone. Now you are guaranteed to have that instance available, and you pay the discounted rate.)
- **Committed use discount vs On-Demand Instances:** On-Demand instances are the default pricing model where you pay per hour or per second with no commitment. They are the most expensive option for long-running workloads because you pay full price. Committed use discounts require a term commitment but offer lower rates. On-Demand is best for short-lived, unpredictable, or experimental workloads. (Example: Running a temporary server for a two-week project? Use On-Demand. Running a production server for three years? Use a committed use discount.)

## Step-by-step breakdown

1. **Analyze current usage** — Start by reviewing your cloud usage reports over the past 30-90 days. Identify resources that run consistently without stopping, such as production web servers, databases, or core business applications. Use cost management tools to see the average number of virtual machines, their instance types, and the regions they run in. This baseline is critical because committing to the wrong attributes wastes money.
2. **Determine the commitment term** — Decide whether to commit for one year or three years. A one-year term offers a moderate discount (around 30% to 40%), while a three-year term offers a deeper discount (up to 70%). However, a three-year term locks you in for a longer period. Choose the shorter term if you expect changes in your architecture or workload. Choose the longer term only for truly stable, long-term workloads.
3. **Select the payment option** — Cloud providers offer three payment options: all upfront, partial upfront, or no upfront. All upfront gives the highest discount but requires a large initial payment. No upfront requires no initial payment, but the discount is lower and you pay monthly. Partial upfront splits the difference. The choice depends on your company’s cash flow and financial strategy. If you have the capital, all upfront maximizes savings.
4. **Choose the scope (regional or zonal)** — Regional scope allows the discount to apply to any eligible instance in any availability zone within the chosen region. Zonal scope locks the discount to a specific availability zone. Regional scope offers more flexibility; zonal scope provides a slightly higher discount and can guarantee capacity if combined with a capacity reservation. Select based on whether you need availability zone control.
5. **Purchase the commitment** — Use the cloud provider’s console, CLI, or API to purchase the discount. For example, in AWS, go to the EC2 console, choose “Reserved Instances,” select “Purchase Reserved Instances,” and fill in the attributes. In Google Cloud, navigate to “Committed Use Discounts” under Compute Engine. In Azure, go to “Reservations” in the portal. Confirm the total cost and the effective discount before finalizing.
6. **Monitor and adjust** — After purchase, monitor your billing to ensure the discount is being applied correctly. Check that the usage matches the commitment attributes. If you change your resource configuration or if the workload evolves, consider modifying or exchanging the commitment (if convertible) or purchasing additional ones. Also, track the expiration date of your commitment to re-evaluate before it ends and avoid reverting to on-demand rates.

## Practical mini-lesson

Understanding and implementing committed use discounts is a core skill for cloud architects and FinOps practitioners. In practice, professionals do not simply buy a discount and forget about it. Instead, they follow a continuous cycle of analysis, purchase, and review. The first step is to gather historical usage data. Cloud providers offer native tools, such as AWS Cost Explorer, Google Cloud’s Recommender, and Azure Advisor, that analyze your usage and suggest commitment sizes and terms. These recommendations are based on your actual usage patterns over the last 30 days, and they can be trusted for stable workloads.

When you receive a recommendation, it usually shows the amount of vCPUs and memory you should commit to, along with the estimated savings. However, do not blindly accept recommendations. They are based on average usage, and if your workload has seasonal spikes, the recommendation might be too high. For example, a retail company may have a spike during December, but that does not mean it should commit to that many resources year-round. Instead, commit to the baseline and cover the spike with on-demand or spot instances.

Another practical aspect is that commitments can be shared across multiple accounts if you use a consolidated billing structure. In AWS, this is done through AWS Organizations. If your company has separate accounts for development, testing, and production, you can purchase the RI at the master account level and share it among all accounts. This maximizes utilization of the discount. In Azure, you can set the reservation scope to “Shared” to cover multiple subscriptions. In Google Cloud, commitments are applied at the project or billing account level.

A common headache is managing commitment expiration. If your three-year commitment is about to expire, and you do not purchase a new one, all covered resources will automatically switch to on-demand pricing. This can cause a sudden 30-70% increase in costs. To avoid this, set up alerts or use automation to notify the team 60 days before expiration. Some providers also offer automatic renewal of commitments, but be careful: this might lock you into a new term without reviewing your needs.

In terms of what can go wrong, the most common issue is purchasing a commitment with the wrong attributes. For example, you might buy a Reserved Instance for a Linux m5.large in us-east-1, but your actual instances are Windows-based and located in us-west-2. The discount will never apply, and you will be billed for the full commitment with zero usage against it. It is like buying a discount for a product you never use. Always verify the attributes against your running resources.

Finally, professionals should know that committed use discounts can also be sold or exchanged. AWS allows you to sell your Reserved Instances on the Reserved Instance Marketplace, albeit at a variable price. Google Cloud does not allow selling, but does allow exchanging for a different commitment (via convertible commitments). Azure allows exchanging reservations for other eligible products. These options are helpful if your needs change, but they often incur fees or reduced savings. The best practice is to avoid needing these options by committing only to stable, well-understood workloads.

To sum up the practical lesson: treat committed use discounts as a financial instrument, not a technical configuration. The decision to commit involves finance, operations, and engineering teams. Use data-driven analysis, start with a one-year term to test the waters, and always have an expiration management plan. This approach turns cloud cost management from a reactive game of paying bills into a proactive strategy that saves real money.

## Commands

```
gcloud compute commitments create example-commitment --region=us-central1 --resources=vcpu=10,memory=64GB --plan=12-month --type=MEMORY_OPTIMIZED
```
Creates a one-year committed use discount for 10 vCPUs and 64GB of memory-optimized resources in the us-central1 region.

*Exam note: Tests understanding of resource specification, term length, and type flags. Common scenario: select MEMORY_OPTIMIZED for high-memory workloads.*

```
gcloud compute commitments list --project=my-project
```
Lists all current commitments for a given project, showing status, remaining duration, and usage.

*Exam note: Exams often ask how to audit existing commitments to avoid waste. This command is used to review active commitments before making new purchases.*

```
gcloud compute commitments update example-commitment --flexible-resources=vcpu=10
```
Converts a rigid commitment to a flexible commitment, allowing resource changes within the same commitment amount.

*Exam note: Flexible commitments are a key exam concept. This command tests knowledge of updating commitment types for greater agility.*

```
gcloud compute commitments get-iam-policy example-commitment
```
Retrieves the IAM policy that controls who can modify or view a specific commitment.

*Exam note: Security and access control are exam topics. This demonstrates fine-grained permissions for managing CUDs at the resource level.*

```
gcloud beta billing commitments enroll --organization=12345
```
Enables the ability to purchase committed use discounts at the organization level, allowing cross-project aggregation.

*Exam note: Organization-level CUDs are a premium feature. Exams test the difference between project-level and organization-level billing.*

```
gcloud compute commitments delete example-commitment --region=us-central1
```
Deletes an existing commitment, but note that you are still billed for the remaining term unless you have a special agreement.

*Exam note: A trick question: deleting a commitment does not stop billing. Exams test that CUDs are binding and cannot be canceled early.*

```
# Example config line for terraform: resource "google_compute_commitment" "my_commitment" { name = "my-commitment" region = "us-central1" resources { type = "VCPU" amount = "20" } plan = "THIRTY_SIX_MONTH" }
```
Terraform configuration to create a three-year committed use discount for 20 vCPUs in us-central1.

*Exam note: Infrastructure-as-code is a trending exam topic. This shows how to manage CUDs declaratively, which prevents manual errors.*

```
gcloud recommender insights list --insight-type=google.compute.insight.CommittedUseDiscount --project=my-project
```
Lists recommendations for optimizing CUD purchases based on historical usage patterns.

## Memory tip

Think “A Smarter Discount”, the A stands for Analyze before committing, S is for Scope (regional or zonal), D is for Duration (1 or 3 years), and the rest reminds you to Discount on the baseline, not the spikes.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/committed-use-discount