AWS Reservation Management

What Are Reserved Instances

AWS Reserved Instances (RIs) allow you to make an upfront monetary commitment to Amazon in return for a discount on your compute costs. By getting customers to commit to the usage of specific infrastructure, Amazon can better manage its capacity and therefore pass these savings onto you.

Benefits of RIs

All RI types provide the benefit of a price reduction. Some RI types also include the benefit of a capacity reservation, which guarantees you the right to launch an instance of the specified type for the term of the reservation.

Attributes of an RI

The configuration of each reservation is determined by these attributes:

• Instance Type (e.g., m3.large)
• Scope: Availability Zone or Region
• Location (e.g., us-east-1b)
• Term: Typically 1 or 3 years, although variable terms are available on the AWS Reserved Instance Marketplace
• Payment Option (e.g., No Upfront)
• Offering Class: Standard or Convertible
• Platform (e.g., Linux)
• Tenancy: Shared or Dedicated

How RIs Get Applied

A common misconception is that RIs are directly connected to specific launched instances. In fact, an RI is simply a pricing discount applied toward the usage of any instance of a specific type, for example, m3.large in us-east-1a running Linux.

AWS first evaluates the available reservations and runs instances on an hourly basis. Reservations are then applied randomly to usage. Each usage of an instance for the hour gets evaluated to determine if there is an applicable reservation to cover it. Applicability is determined by matching instance type (e.g., m2.2xlarge), location (e.g., us-east-1a), and operating system (e.g., Linux). Since multiple different reservation types and purchases can match, the selection of a reservation gives preference toward applying the lowest hourly rate first. Reservations also have an affinity toward the account in which they were purchased.

Consider that you launch an instance that matches a specific instance type, location, and operating system, for example, m3.large in us-east-1a running Linux. After one month of using this instance, you are billed at a discounted rate that is determined by the type of offering (no upfront, partial upfront, or all upfront). Your bill is therefore lower than what it would have been for on-demand usage of the same instance type.

RIs are both a powerful feature and a source of constant confusion. The confusion is often driven by customers purchasing RIs for a specific purpose (e.g. the marketing department), only to find its cost benefit is applied elsewhere.

Considerations When Managing RIs

Making your first RI purchase can be a daunting task. In addition to determining the attributes of the RI (Instance Type, Scope, Term, Offering Class, and so on), you need to predict usage across teams, applications, and functional areas. Some considerations can help simplify RI purchase decisions.

When to Purchase RIs

You can use two metrics to determine when to purchase RIs. Both metrics are associated with the usage cost of an RI.

Effective Rate

The actual rate you pay for running instances. This rate is applicable to different time intervals (e.g., 1 year, 1 month, or even 1 hour). It is calculated based on the following formula:

effective rate = upfront payment/reservation term/interval + recurring usage charges for interval

Here is an example table showing the effective rate for an m3.large Linux instance in us-east:

	On-demand	No Upfront	Partial Upfront	All Upfront
Upfront payment to Amazon	$0.00	$0.00	$443.00	$751.00
Recurring costs of running at 100% for term	$1226.40	$876.00	$324.12	$0.00
Total effective cost (monthly)	$1226.40	$876.00	$767.12	$751.00
Savings over on-demand	n/a	29%	37%	39%

Payback Period

The number of months that an RI must operate at 100% usage in order for it to be less expensive than an on-demand instance of the same type. This metric helps you understand how long you must use a reservation before it breaks even.

The payback period is applied to partial upfront and all upfront payment options, which are more expensive earlier in the term of the RI because of the initial payment you make to Amazon. The no upfront payment options do not have a payback period, since they are less expensive than on-demand instances. While the payback period varies by instance type, on average it is 6 months for a 1-year term and 9 months for a 3-year term.

The payback period is the point at which you can shut down an instance and still have benefited from the purchase of the RI. You can calculate the payback period as follows:

1. Compare the cash outlay for on-demand usage and the proposed offering over each month in a term.
2. Identify the month at which the cost for the on-demand instance usage exceeds the cost for the reserved offering.

Analyze Needs by Instance Group

Step 1: Group Like Instances

At any reasonable scale, making RI purchase decisions for each instance in your infrastructure is unmanageable. You can simplify the decision-making process by grouping instances by one or more perspectives, such as environment, function, and application. The most common approach is to group instances based on their application or functional purpose, such as MongoDB or web servers.

AWS prices images of platforms (e.g., Linux or Windows) differently so if possible, do not include different types of images in the same group.

Step 2: Evaluate Cost by Group

Start with the most expensive instance groups (such as MongoDB servers) when assessing the potential to migrate to RIs. More importantly, RIs are targeted at “always on” infrastructure. So you can skip the assessment for groups in which instances are used less than 65% of the time.

For each group, ask the following questions during the assessment.

• What percentage of the group do you expect will be running 1 year from now and 3 years from now
• How likely are the instances in this group to stay within their current region (ignore location for now)
• How likely are you to change the instance type family for the instances in this group (e.g., switching from m1 to m3 family)

Step 3: Make Reservation Decisions By Group

If you can, with reasonable confidence, expect to use a known percentage of the instances in a group in their current regions, without changing instance type family, for at least 7 months (the average payback period for a RI), that group is an RI candidate.

For each group, evaluate the value of the different reservation types and terms as illustrated in this example:

Sample evaluation for 10 m3.large instances in us-east for a 1-year term.

	On-demand	No Upfront	Partial Upfront	All Upfront
Upfront payment to Amazon	$0.00	$0.00	$4,430.00	$7,510.00
Recurring costs of running at 100% for term	$12,264.00	$8760.00	$3241.20	$0.00
Total effective cost (monthly)	$12264.00	$8760.00	$7671.20	$7510.00
Savings over on-demand	n/a	29%	37%	39%

The savings over on-demand vary by instance type and region, and the difference between two offers can be as low as 1%.

In this example, an all upfront reservation can be ignored because it requires an additional cash outlay of $3,080 for only 2% more savings over the partial upfront counterpart.

Be careful of making RI purchases for legacy instance types, which typically cost more, have less performance than newer instance types, and are difficult to sell on the AWS Marketplace. Before purchasing legacy instance types, validate that you do not plan to upgrade to another instance type family before the break-even month for your selected reservation offering. The break-even period is typically 6 months for a 1-year reservation and 9 months for a 3-year reservation. Typically, organizations take longer than they expect to migrate away from an instance type. Therefore, the months to break even can be helpful in making a reserved instance purchase decisions for legacy instance types.

Step 4: Pick Highest Value Targets

Budget is the common limiting factor among organizations considering an RI purchase. When making your first RI purchase, selectively choose RI offerings from the previous steps until you have reached your budget.

Establish RI Business Policies

Several infrastructure changes occur regularly in your cloud environment. As your cloud environment grows, monitoring and governing these changes becomes increasingly challenging. Business policies are an effective way to develop a blueprint for how and when your organization purchases reservations and modifies them.

Consider these key aspects when establishing policies for RI management.

• Budget: The amount budgeted for RI purchases in a fiscal or calendar year (e.g., $250K per calendar year)
• Purchase frequency: How often the organization plans to make purchases (e.g., purchase quarterly)
• Approval workflows: Who is involved in the process of approving a proposed purchase (e.g., approved by CTO and CFO)
• Reservation rates: Target reservation rates by business group (e.g., Production = 75%, Nonproduction = 50%)
• Preferred terms: Organizational policies around what terms to use and when (e.g., only commit to 1-year term to minimize impact of instance type family changes)
• Target savings: The minimum targeted savings goal, or average goal, before a purchase should be made (e.g., maintain at least 35% savings over on-demand usage)
• Usage of reservation types: Organizational guidelines for when to use different types of reservations
• Maintenance frequency: How frequently the organization reviews the usage of reservations and makes modifications or sales as needed

Fine-Tune RI Attributes

After making a decision to purchase RIs, determine the key attributes for each reservation.

Offering Class

Each reservation is tied to a specific instance type family (e.g., m4), payment option (e.g., All Upfront), location (e.g., us-east-1a), OS (e.g., Linux), and tenancy (e.g., Shared). Over time your organization may make changes to the type of instances it runs for specific workloads, forcing you to allow reservations to go unused or to sell them on the marketplace. In addition, as Amazon continues to innovate within its instance type families, you may find your applications can run with better performance and cost effectiveness on newer instance families. These two concerns have limited the willingness of some organizations to make reservation commitments, and/or make commitments that exceed a year.

Standard RIs

• Can be purchased for one-year or three-year terms.
• Can only be applied to a single instance family, location, platform, scope, and tenancy over the term.
• At purchase, instance is scoped to a specific Availability Zone or Region. After purchase, scope can be modified from an Availability Zone to a Region. Only reservations scoped to an Availability Zone have the benefit of capacity reservation.
• Cannot be exchanged for another Standard RI of same or different configuration.

Convertible RIs

Convertible Reserved Instances (RIs) have the following attributes:

• They can be purchased for one or three-year terms.
• They can be exchanged for Convertible RIs of different configuration, including different instance family, platform, tenancy, or scope during the term.
• Account and region are hard boundaries and cannot be altered.
• When you purchase Convertible RIs, they are scoped to a specific Availability Zone or Region. You can modify this scope after purchase.
• You can exchange convertible RIs for other convertible RIs. For more information on exchange criteria, see AWS documentation on Exchanging Convertible Reserved Instances.

Due to the flexibility they provide, Convertible RIs are slightly more expensive. Moreover, when you exchange them, you cannot receive a credit. You can only exchange existing Convertible RIs for new Convertible RIs whose cost is greater than or equal to the cost of the existing RIs.

Payment Option

RI payment options differ in the manner in which you make payments toward reservations. There are three options.

No Upfront

A successful billing history is required before an account is eligible to purchase through this option.

Amount	Pay no usage cost upfront
Term	1 year or 3 years for Standard, 3 years only for Convertible
Discount	27% to 50%

There are two reasons to choose a No Upfront payment option.

• Budget: If your budget next year does not permit Partial Upfront or All Upfront payments for a particular instance type (e.g., m3.large), consider the No Upfront option. Even though the option locks you into a reservation term, it provides compelling cost savings.
• Cost savings: Each organization assigns different weights when comparing cost savings and the cost of the upfront fees for making an RI purchase. If the difference between the cost savings with No Upfront and All Upfront payments is not significant (e.g., <5%) consider the No Upfront payment option.

Partial Upfront

Formerly, this type of RI was called a Heavy Reservation.

Amount	Pay part of usage cost upfront. Remaining hours in the term are billed at a discounted hourly rate, irrespective of usage.
Term	1 year or 3 years
Discount	32% to 53% for 1-year term, 53% to 74% for 3-year term

All Upfront

Formerly, this type of RI was called a Fixed Reservation.

Amount	Pay entire usage cost upfront. No other costs are incurred for the remainder of the term, irrespective of the number of hours used.
Term	1 year or 3 years
Discount	34% to 53% for 1-year term, 56% to 75% for 3-year term

The All Upfront payment option always provides the highest cost savings. However, those savings are not always sufficient to justify the additional cash outlay in the form of upfront fees. A sample evaluation for one m3.large instance reserved in us-east for a 1-year term is presented below. The evaluation shows that an All Upfront reservation requires an upfront payment of an additional $308 over a partial reservation, in return for a 2% savings over on-demand usage.

	On-Demand	No Upfront	Partial Upfront	All Upfront
Upfront Payment to Amazon	$0.00	$0.00	$443.00	$751.00
Recurring Costs of Running at 100% for Term	$1,226.40	$876.00	$324.12	$0.00
Total Effective Cost	$1,226.40	$876.00	$767.12	$751.00
Savings Over On-Demand	n/a	29%	37%	39%

An All Upfront reservation tends to be less popular due to the economics and sometimes ineffective use of capital and the low savings. Even so, it is essential to evaluate your instance requirements on a case-be-case basis. The evaluation might indicate that an All Upfront reservation provides the most compelling cost savings.

Offering Class and Payment Option Matrix

Offering Class	Payment Option	Term
Standard	No upfront	1 year
	Partial upfront	1 year or 3 years
	All upfront	1 year or 3 years
Convertible	Partial upfront	3 years
	All upfront	3 years

Scope

In order to understand the impact of scope, recall that some RIs provide two benefits: (i) price reduction and (ii) capacity reservation. While price reduction is an obvious benefit, capacity reservation guarantees you the right to launch an instance of the specified type for the term of the reservation. The latter benefit is often overlooked because the growth of cloud-based applications does not rely on committed capacity. RIs can be scoped to a Region or an Availability Zone, both of which provide the price reduction. For more information, see Regions and Availability Zones.

Availability Zone

If you scope an RI to an Availability Zone, you are guaranteed capacity for the reserved instance type. However, you only receive the guarantee for instances of that type running in that specific zone.

In addition, the capacity guarantee is only afforded to the AWS account in which the RI was purchased. For example, if you purchased the RI in a primary account and used the RI in other linked accounts, you do not receive the capacity guarantee.

Region

RIs scoped to a Region do not receive the capacity guarantee. However, Region-scoped RIs are automatically applied to any instance of that type running in the chosen region. Region-scoped RIs are beneficial when you do not require the capacity guarantee.

Size Flexibility of Region-Scoped Reservations

Regional reservations with shared tenancy and Amazon Linux have the additional benefit of size flexibility. Size-Flexible Regional Reservations are automatically applied to any running instance in the Region within the same family, regardless of size or Availability Zone.

AWS assigns Region-scoped reservations a size, which is expressed as a number of units. This number is proportional to the size of the instance, and it simplifies reservation management in AWS.

Here is a greatly simplified example of how size flexibility works.

A 40 count t2.small reservation is assigned 40 units. When one t2.small instance runs in region A for one hour, it consumes one unit. This consumption leaves the reservation with 39 unused units.

When a t2.medium instance runs for one hour in that same region, a part of the t2.small reservation is applied to that t2.medium usage. This time, however, 2 units of the t2.small reservation are consumed, based on this ratio.

t2.medium : t2.small :: 1 : 2

This usage leaves the t2.small reservation with 37 unused units. The units scale up and down. For example, a t2.micro instance running in the same region would also benefit from the t2.small reservation but it will only consume .5 units. Likewise, a t2.nano instance would consume .25 units, while a t2.32xlarge instance would consume 256 units.

This unit-based usage concept is documented as the Normalization Factor in AWS.

If you use Region-scoped reservations, you need to track consumption by number of units. Theoretically, you can purchase a single large Region-scoped reservation and let it apply to all instances of a family and never modify the reservation.

A region-scoped reservation is size-agnostic and can be applied to any instance within a family.

Choosing between Availability Zone and Region

Consider these two goals to determine whether you should scope an RI to a Region or an Availability Zone.

Goal 1: Purchase reservations for cost savings alone If you purchased RIs strictly for their cost benefit and the capacity benefit is not important to you, scope your reservations to a Region.

If you use Policies to automatically modify RIs, ensure that the policy modifies reservation scope to Regional.

Goal 2: Purchase reservations for both cost savings and capacity benefits If you purchased RIs and the capacity benefit is important to you, scope your reservations to an Availability Zone.

If you use Policies to automatically modify RIs, ensure that your policy modifications maintain scope.

Accounts and Billing

While many organizations have only a single AWS account, organizations with multiple accounts are common. Larger enterprises tend to have very complex account setups that include multiple consolidated bills and hundreds of linked or standalone accounts.

The best practice is to purchase reservations in the accounts in which you have specific instance usage, particularly if you have availability zone misalignment within your accounts.

Consolidated Account

An account designated by a customer as a billing account to which one or more additional accounts can be linked. The billing contact for a consolidated account receives a statement summarizing charges for all linked account.

Using this account simplifies the purchase and management of RIs. However, you lose the guaranteed ability to launch an instance based on a reservation in a linked account if the reservation was made in another account.

Linked Account

An account linked to a consolidated billing account. An account can only be linked to one consolidated bill.

Using this account complicates the purchase and management of RIs. However, you receive both the price reduction and capacity guarantee for the RI through this approach.

Standalone Account

An account that receives it own statement and is not linked to a consolidated billing account.

GovCloud Account

These accounts must be associated with either a consolidated or standalone account (a “commercial account”). Once associated, all billing and usage is reported as though it originated from this account.

Consolidated Bills

Organizations tend to link one or more accounts to a consolidated bill, which gives RIs the ability to “float” across accounts.

Consider that you purchase RIs in either a consolidated account or an account linked to the consolidated account (i.e., a billing family). In a given hour, if the account does not show RI utilization, the reservation can float to a matching instance usage in any other linked account within the consolidated bill.

By default, reservations have an affinity toward the account in which they are purchased. Reservations float only when no instance usage occurs in the account that can take advantage of the reservation. The price reduction benefit of RIs also floats across accounts within a consolidated bill, but the capacity reservation does not float. If you have an available reservation in account A, AWS allows you to launch an equivalent instance in account B if these accounts are linked to the same consolidated billing account.

Availability Zone Misalignment

Availability zones are assigned to an account at the time of account creation. If you have multiple accounts, there is a good chance that not all of them share the same availability zones. For example, if you have accounts A, B, and C, the availability zones for the us-east region might be as follows:

Availability Zone	Account A	Account B	Account C
us-east-1a	✓	✓
us-east-1b	✓		✓
us-east-1c	✓	✓	✓
us-east-1d	✓	✓	✓
us-east-1e		✓	✓

If you have one account, or only standalone accounts, this misalignment does not impact you. But if you have more than one account linked to a consolidated billing account, the misalignment can impact cross-account floating. In the above example, consider that accounts A and C are linked to the same consolidated account. If you purchase a reservation for us-east-1a in Account A, the reservation cannot float to Account C, which does not have the availability zone us-east-1a.

Setup Approval Process for RI Action

Purchasing, maintaining, and selling RIs is a complicated process. In addition to determining the attributes of the RI (Instance Type, Scope, Term, Offering Class, and so on), you need to predict usage across teams, applications, and functional areas.

VMware Tanzu CloudHealth helps you automate RI purchases through actions that are run through an approval process before being implemented. This approach helps you automate the labor-intensive and error-prone process of RI management without compromising on authorization and security.

Define Approvers and Authorizers

You can automate aspects of RI management by configuring actions that Tanzu CloudHealth runs through an approval process. An action must pass through at least one of these users:

• Approvers: Responsible for validating that a requested action is acceptable. When an action is triggered, they receive an email notification through which they must approve the action. Upon approval, the action passes to the next Approver in the sequence.
• Authorizer: After all Approvers have signed off on the action, the request is sent to an Authorizer to provision a temporary least privilege token that allows the token bearer to make a request using the AWS Security Token Service. Tanzu CloudHealth uses this token to perform an action on behalf of the user.

Setup Actions

1. Select Setup > Governance > Actions to view preconfigured actions. You can also create your own actions. Two preconfigured actions provided for EC2 RI management:
   • Modify Amazon EC2 Reserved Instances
   • Purchase Amazon EC2 Reserved Instances You can add one or more authorizers to these preconfigured actions by clicking Update.
2. Alternatively, create your own actions to build a chain of approvers and authorizers. Click Create Action.
3. Create a sequence of events that make up the action. For example:
   • Get approval for RI modification
   • Get authorization for RI modification
   • Modify Amazon EC2 Reserved Instances

Simplify RI Purchase Decisions Using EC2 RI Optimizer

The decision to make an accurate and effective RI purchase can be a daunting task, often requiring long, tedious, and error-prone analysis.

The EC2 RI Optimizer evaluates your AWS instances to determine if you can benefit from the use of RIs. During the evaluation, the Optimizer analyzes your previous usage and identifies the optimum purchase for a given budget.

Tanzu CloudHealth uses a constraint-based algorithm that makes recommendations by taking a greedy approach to the classic “knapsack problem.” The analysis is performed by reviewing hourly on-demand usage over a time period. The algorithm trades off one or more less efficient options for more efficient ones in order to identify the optimum reservation purchase that fits within your budget constraints. The aim is to provide the best recommendations for your specified constraints such as budget, purchase date, and filters.

Prerequisite: Enable Cost and Usage Report (CUR)

AWS Cost and Usage Reports (CUR) provide comprehensive data about your costs, including those related to product, pricing, and usage. For more information, see AWS Cost and Usage Reports.

Enable the CUR before using the EC2 RI Optimizer to evaluate your on-demand usage.

What happens if the CUR is not enabled

The recommendations that the RI Optimizer presents might be inaccurate for any EC2 instance family that has underutilized, size-flexible reservations.

How many days worth of data does the CUR need to have

At least 30 days of data. If you only recently configured the CUR, and have less than 30 days of data, Tanzu CloudHealth will provide correct analysis and recommendations based on the partial history. The platform will also present warnings that give the option of viewing the old report, populated with data that does not account for size-flexible RIs.

Step 1: Create Quote

The EC2 RI Optimizer analyzes your instance usage and requirements based on a quote that you build. You can also modify or delete existing quotes and execute a purchase within a quote.

1. Select Recommendations > Reservations > EC2 RI Optimizer.

2. Select Actions > New Quote.

   If you have not enabled the CUR,Tanzu CloudHealth does not receive the complete reservation history for the accounts and time period you specify in the Optimizer. As a result, Optimizer recommendations are based on incomplete information and might be inaccurate. By default, Tanzu CloudHealth proposes an RI purchase that provides close to 100% coverage of your instances without any limit on budget. The proposal is based on an analysis of current and historical on-demand usage of instances on an hourly basis.

   Tanzu CloudHealth does not autosave changes to the quote. After each set of changes, click Actions > Save at the top-right corner of the quote to retain your changes.

Step 2: Configure Quote Options

Review the default options that Tanzu CloudHealth sets when you create a quote. When modifying the options, consider what settings are ideal for your cloud environment.

• Time Period To Analyze: Specify the time period over which you want your on-demand usage analyzed. Select a time period that is most reflective of the usage you expect in the future. The best practice is to analyze usage over the last month. For highly dynamic environments, use a shorter period of time and for more static environments, a longer period of time. When you select Now, the Optimizer only looks at the most current possible usage data and build recommendations from that.
• Preferred Term: While 3-year terms provide the most cost savings, customers tend to choose a 1-year term to hedge against the potential for new instance types becoming available during the term.
• Target Coverage: Specify the maximum effective coverage that should be used to constrain the recommendations. Coverage is defined as the percentage of usage hours that are covered by reservations, and it is calculated as follows:

  Coverage = Reserved hours / (Reserved hours + On-demand hours)
  

For most usage patterns, 100% coverage is not financially optimal.

• Estimated Purchase Date: This date is critical if you have existing reservations that will expire before the expected purchase. When you choose a date, the Optimizer takes expiring reservations into account, ensuring that any renewals are included subject to your budget constraints.
• Purchase Account: Select a consolidated account or select All to make purchases in the account where the usage occurs.
• Offering Types: Uncheck payment options that you do not want to use for the analysis. For example, some organizations might prefer not to use the All Upfront payment option.
• Choose Lower Prepay Res Type if Savings < X%: This setting downgrades the payment option if the savings difference between payment options is smaller than the specified percentage. For example, if the savings from purchasing Partial Upfront RIs over No Upfront RIs is <3 %, the recommendation downgrades to suggest that you purchase No Upfront RIs, which have a lower prepay than Partial Upfront RIs.
• Reserve Capacity: Check to ensure that a capacity guarantee is provided in the Availability Zone. If this option is checked, the Optimizer recommends purchasing RIs scoped to an Availability Zone; otherwise, the Optimizer recommends purchasing RIs scoped to a Region.
• Use Convertible: Check if you want to only search for Convertible RI options.

Step 3: Constrain Quote to Subset of Infrastructure

The EC2 RI Optimizer allows you to constrain the quote to a subset of your infrastructure. For example, you might want to make an RI purchase for specific accounts, regions (e.g., us-east), instance types (e.g., m3 instance types), functions (e.g., Elasticsearch Clusters), or even business groups (e.g., marketing department).

Use the Filters function of the Extended Options section to target a specific subset of your infrastructure for an RI quote.

If you want to make more than one RI purchase for a subset of your infrastructure, be careful about targeting overlapping infrastructure (e.g., creating a quote that includes usage in the same account twice). This action can result in over-purchasing of reservations.

Effect of Account Filter

When you purchase RIs within a billing family, the EC2 Optimizer backfills EC2 usage data for the period between the start of the analysis period and the RI purchase date. This backfilling ensures that your RIs are correctly applied to EC2 Instance usage in that Billing Family for that period.

When you do not apply an additional Account Filter, the backfilling process accurately reflects your RI needs for the analysis period.

When you apply the Account Filter, Tanzu CloudHealth still backfills EC2 usage data by considering all the new RIs associated with the Billing Family. However, the backfilling process only considers usage in the Accounts you have filtered out. In effect, Tanzu CloudHealth applies the same number of RIs to Instances that represent less usage. This process might lead to an under-recommendation for RI purchase.

Click Run Optimizer after setting Options and Filters.

Step 4: Review Recommendations

After running an evaluation, the Optimizer returns recommendations for RI purchase. Recommendations include both high-level and detailed summaries.

Review High-level Summary

This section includes the following information.

• Instances: The hourly average number of running instances for the recommendations
• Reservations to Buy: The number of new reservations that the Optimizer recommends you buy
• Coverage: The effective coverage your environment receives with the recommended reservations. Why is coverage less than 100%, even though you specified 100% in the Target Coverage field
  Coverage is calculated as `Reserved hours / (Reserved hours + On-demand hours) For most usage patterns, 100% coverage is not financially optimal. The recommendations that the Optimizer provides with no budgetary constraints applied is the fully optimized reservation purchase for your usage pattern. This set of recommendations provides some level of coverage, but likely less than 100%. The effective coverage percentage provided by the fully optimized set of recommendations is the maximum coverage that the Optimizer proposes for your specific environment and usage pattern.
• Upfront Cost: The total upfront payment for the recommendations
• Break Even: The number of months to achieve the payback.
• Savings: Additional savings from making this recommendation purchase.
• Monthly Savings: The monthly savings realized from this recommendation purchase, including amortized prepay.
• Annual Savings: The annual savings realized from this recommendation purchase, including amortized prepay.

Review Detailed Summary

This section provides information on each unique recommendation. In addition to the information for each account, the section provides the summary for each proposal.

Only size-flexible recommendations are grouped by Instance Family, and each instance type with a size-flexible family is listed on a separate row. Each row in the recommendation summary includes the following information:

• Instance Type: The family and size of the reservation
• Account: The account into which this reservation will be purchased
• OS: The operating system of the reserved instance
• Tenancy: The tenancy of the reserved instance
• Instances: The hourly average number of running instances
• Normalized Instances: The hourly average number of running instances normalized by instance size
• Current: The number of existing reservations
• Buy: The number of recommended new instances to buy
• Upfront: The total upfront payment for the reservation
• Coverage: The effective coverage with the recommended reservations
• Current Monthly: The current monthly cost of on-demand instances and existing reservations
• Projected Monthly: The projected monthly cost after purchase, including reservations and remaining on-demand cost
• Current Annual: The current annual cost of on-demand instances and existing reservations
• Projected Annual: The projected annual cost after purchase, including reservations and remaining on-demand cost

If a proposed reservation is for a legacy instance type, a warning recommends moving away from the legacy instance type.

The %VPC column indicates what percentage of usage being optimized was identified as running within a Virtual Private Cloud (VPC). When purchasing a reservation, you specify whether the reservation should be for a VPC or Classic (non-VPC) instance. Both Classic and VPC instances receive the price reduction benefit. If you purchase a VPC reservation and no comparable instance is running in a given hour, the reservation can be applied to an equivalent running Classic (non-VPC) instance. However, the capacity reservation guarantee is specific to the type of instance you launch (Classic or VPC). So if you make a Classic reservation, you do not have the capacity guarantee if you launch a similar VPC instance and visa versa. For more information, see Amazon VPC FAQs.

Step 5: Modify Recommendations

The EC2 RI Optimizer presents recommendations based on the options that you configure. However, you can modify those recommendations.

For example, if the Optimizer recommends purchasing 10 Partial Upfront reservations for m3.large usage in us-east-1a running Linux, you can choose to purchase only 7 if you expect a future reduction in load that affects this instance type.

You can make modifications at the family level (for size-flexible reservations) or by instance type. You can also remove a specific row from the quote. Click any row in the recommendation summary to modify it.

The Recommended Usage view shows the on-demand usage overlaid on the recommended RI usage by type. This view helps you see what your usage looks like today and how Tanzu CloudHealth recommends this expense be managed with RI purchases.

In addition, the view presents these key attributes of the recommendation.

• Pricing: Upfront, monthly, and effective costs per unit purchased for the available offering types. The upfront fees and monthly costs are based on customer-specific pricing, which is impacted by tiered discounts and custom pricing plans. Tanzu CloudHealth derives this pricing from your Detailed Billing Record (DBR), which provides a summary from AWS of hourly costs for all usage. If customer pricing is unavailable, the on-demand pricing is displayed.
• Savings over On-Demand: Percentage savings over on-demand usage for 100% usage of the reservation.
• Quantity: An editable field where you can adjust the number of reservations for each offering type.
• Cost: The product of the Pricing column and Quantity column.
• Monthly Savings: Projected reduction in your monthly bill if you fully utilize the proposed reservation purchase.
• Term Cost: The total amount you will pay for this reservation based on full usage. This cost includes both the upfront fees and recurring monthly costs.

Step 6: Place Purchase Order

After you have customized the quote, you can export the order.

There are three ways to make the reserved instance purchase.

• Using Tanzu CloudHealth: Configure an approval workflow for purchasing reserved instances. Then, click the Purchase button on the Quote Summary page.

  This action initiates the request for approval for reservation purchase. After both Approver and Authorizer confirm the request, the purchase is initiated.

• Through your Amazon account representative: Review the quote and then select Actions > Export Order to download a file that you can share with your Amazon account representative.

• Through the AWS Console: Use the information in the Order tab to make a purchase through the AWS Console. If you have elected to purchase reservations in the accounts in which they are used, you must make a purchase within the AWS Console for each account.

Modify Reservations Using EC2 RI Modifier

Tanzu CloudHealth gives you the ability to modify coverage for all instances tied to your reservation, or just a subset, in one or more of the following ways:

• Switch availability zones within the same region
• Change between EC2-VPC and EC2-Classic
• Change the instance type within the same instance family

The EC2 RI Modifier analyzes your reserved instances as well as your instance usage and make cost-saving modification recommendations to consider.

Specify Criteria for Usage Calculation

1. Select Recommendations > Reservations > EC2 RI Modifier.

2. Review the default options that Tanzu CloudHealth sets when you specify the criteria. When modifying the options, consider what settings are ideal for your cloud environment.

   • Calculate Usage Over: Specify the time period over which you want your usage analyzed. Options are Now, Last Day, Last 7 Days, Last 30 Days, and Month-to-Date.
   • Minimum Modification Savings: Specify a threshold for the savings. Any modifications which result in savings less than this number will not show in the report.
   • Reserve capacity: Check to ensure that a capacity guarantee is provided in the Availability Zone.
3. Click Update after specifying the options.

Review Recommendations

After running the analysis, the Modifier returns recommendations for RI modifications. The Total Estimated Monthly Savings field represents the sum of all recommendations that meet your criteria.

1. Click a recommendation row item to view additional details about the proposed modification.
2. If you have not done this already, configure an approval workflow for purchasing reserved instances.
3. Perform a single modification, which might modify multiple reservations at once, by clicking Actions > Modify Amazon EC2 Reserved Instances. Alternatively, you can perform multiple modifications by checking the box to the a row item and selecting Bulk Actions > Modify Amazon EC2 Reserved Instances. This action initiates the request for approval for reservation modification. After both Approver and Authorizer confirm the request, the modification is initiated.

Exchange Convertible Reserved Instances

What Are Convertible Reserved Instances

Convertible Reserved Instances (RIs) have the following attributes:

• Can be purchased for one or three-year terms.
• Can be exchanged for Convertible RIs of different configuration, including different instance family, platform, tenancy, or scope during the term.
• Account and region are hard boundaries and cannot be altered.
• When you purchase Convertible RIs, they are scoped to a specific Availability Zone or Region. You can modify this scope after purchase.
• You can exchange convertible RIs for other convertible RIs. For more information on exchange criteria, see AWS documentation on Exchanging Convertible Reserved Instances.

Due to the flexibility they provide, Convertible RIs are slightly more expensive. You also do not recieve a credit when you exchange Convertible RIs. You can only exchange existing Convertible RIs for new Convertible RIs that have a cost greater than or equal to the cost of the existing RIs.

Key Challenges with Managing Convertible RIs

The biggest challenge for Tanzu CloudHealth customers using convertible RIs is ensuring that they are being well utilized. The challenges center on these specific areas:

• Identifying which convertible RIs are underutilized.
• Identifying instances that are running on-demand that are good candidates for migrating to convertible RIs.
• Selecting candidates that will migrate to convertible RIs most efficiently. Here, the focus is on maximizing savings while limiting additional investment.
• After these candidates are identified, building an exchange quote and manually performing the exchange through the AWS console.

What is the Convertible Reserved Instance Exchanger

The Convertible Reserved Instance Exchanger is a tool that helps you recoup savings from underutilized convertible RIs in your AWS infrastructure while limiting additional investment. The investment, in this case, is defined as follows:

Investment = True-up cost + Additional hourly commit charges

The true-up cost is the prorated, upfront cost of the difference between your old (pre-exchange) and new (post-exchange) convertible reservations.

The Exchanger performs the following actions:

• Identifies underutilized convertible reserved instances
• Identifies on-demand usage candidates
• Selects the most efficient candidates
• Builds you a quote that you can use to manually perform exchanges through the AWS console.

Compute Savings Plans and the Exchanger

The Exchanger is focused on covering on-demand usage and not usage covered by Compute Savings Plans. Compute Savings Plans are both highly dynamic and offer equivalent discounts to Convertible RIs. Because of this, the Exchanger may make a different recommendation from which RIs go unused.

If you have significant Compute Savings Plan covered usage, we recommend setting the beginning of the evaluation period to be after your most recent CRI exchange to ensure exchange recommendations are complimentary to your Compute Savings Plans.

How the Exchanger Works

The goal of the Exchanger is to recommend exchanges that provide the highest savings with the least investment. In other words, the Exchanger maximizes the ROI from an exchange, and produces a set of exchange recommendations that will save you money. This is how the Exchanger works:

1. Identifies all active convertible RIs that are losing money because they are underutilized, and represents them as exchange opportunities. To get an idea of your underutilized RIs, see the EC2 Underutilized RIs report (Reports > Usage > EC2 Underutilized RIs in the Platform). The EC2 Underutilized RIs report lists both standard RIs and convertible RIs. As a result, the recommendations you see in the Exchanger will not directly align with the information you see in the report. However, you can use the report to make an inference.
2. Ranks the exchange opportunities from lowest ROI to highest ROI.
3. Identifies on-demand usage patterns that you should cover using RIs. Represents them as savings opportunities. In order to understand your on-demand usage patterns, see the EC2 Instance report (Reports > Usage > EC2 Instance in the Platform).
4. Ranks the savings opportunities from highest ROI to lowest ROI.
5. Intelligently selects the best savings opportunity and covers it using the most efficient combination of exchange opportunities. If modifying a savings opportunity using the size-flexibility property of RIs is an option, the Exchanger suggests that modification as well. The most efficient combination maximizes savings while reducing the true-up cost.
6. Verifies that the exchange recommendation saves money.

Working with the Exchanger

Build an Exchange Quote

Navigate to select Recommendations > Reservations > EC2 CRI Exchanger. The Exchanger runs immediately, identifying both savings and exchange opportunities. You can constrain the recommendation by specifying a budget and by using filters.

Why do recommendations not appear for some accounts even though you selected those accounts when building a quote

When building a quote, you can specify which accounts the Exchanger should consider when providing exchange recommendations. If you do not see an account listed in the recommendations, then it likely means that one or more of these conditions was not satisfied:

(a) Tanzu CloudHealth does not have access to the account’s Cost and Usage Report (CUR) data for the entire duration that you specify in the Evaluation Period in the Exchanger.

(b) Tanzu CloudHealth does not have IAM permissions to read EC2 reservation information from the account.

Why do results only appear when the Evaluation Period is 7 days or Month to Date, but not when the period is Last 30 days

This scenario occurs when Tanzu CloudHealth has access to less than 30 days of data from the Cost and Usage Report (CUR).

Dive Deep into Exchange Recommendations

If you click one of the line items in the detailed recommendation section, a modal breaks down that recommendation.

Each row in the modal, except for the last row, describes what portion of an existing source reservation order you should consider exchanging. The final row shows what the recommended exchange should be.

There are two variants of rows that describe the source reservation:

Variant 1: Exchange source reservation as-is

In this variant, you exchange an existing source reservation order as-is so that none of the RIs in the order are remaining at the end of the exchange.

Variant 2: Modify a source reservation before the exchange

In this variant, you modify an existing source reservation order so that some of the RIs in that order remain in your inventory after exchange. In suggesting this modification, the Exchanger looks for opportunities to use the remaining RIs toward another exchange.

Remaining Value: (Remaining upfront cost + Remaining commitment) Monthly Waste: Measure of the unprofitability of the reservation. It is calculated as how much more expensive it is to own the reservation as compared to running the instance on-demand.

Export the Exchange Recommendation

You can export the recommendations that the Exchanger generates as a CSV. Then, use the information in the CSV to carry out the exchange in the AWS Console.

Tanzu CloudHealth generates two CSV files to help you perform the exchange action in the AWS Console:

• The first CSV file lists all the exchange recommendations.
• The second CSV file lists all the necessary modifications to enable the exchange.

The files contain drilldowns of the required modifications and exchanges. The ID of each reservation order that should be modified before the exchange is of particular importance. The IDs are required when processing the exchange through the AWS Console.

Automate an Exchange through Tanzu CloudHealth

Once you build an exchange quote, you can automate one or more exchanges in the quote using Tanzu CloudHealth. You can either allow Tanzu CloudHealth to perform the exchange or utilize the authorization workflow in the to initiate the exchange.

Select Level of Automation for Exchanging Convertible RIs

There are two types of automation that you can select from.

Option	Requirements
Delegate the exchange action to an authorizer in your organization	Enable the exchange action and select an authorizer. An Authorizer provisions a temporary least privilege token using the AWS Security Token Service once a request for an Action is approved. Tanzu CloudHealth uses the token to perform an Action on behalf of the authorizer.
Allow Tanzu CloudHealth to perform exchange	Update Tanzu CloudHealth IAM Policy permissions to exchange convertibles RIs

Option 1: Delegate Exchange Action to Authorizer

In this option, you provide privileges through an IAM policy to the AWS user you want to authorize to perform the exchange through Tanzu CloudHealth.

Configure Action for Exchange Automation

1. From the left menu, select Setup > Governance > Actions.
2. Navigate the the Available actions list on the right. Locate the action to Exchange Amazon EC2 Reserved Instances and click Setup.
3. In the Setup dialog box that appears, enter the name of an authorizer. This individual receives a notification when you initiate an exchange. They must then provide a secret key that accompanies the notification in order to initiate the automated exchange. If you do not enter an authorizer’s name, Tanzu CloudHealth will perform the exchange on your behalf, provided the correct privileges exist in the IAM policy associated with your account.
4. Specify a True Up Cost Threshold, which is set to 5% by default. Why do you need to specify this threshold As a best practice, get authorization on an exchange action as close to the time of quote generation as possible. This approach reduces the likelihood of large variances in the true-up cost. The true-up cost in a convertible RI exchange is transient because of the dynamic nature of the transaction. Between the time that Tanzu CloudHealth generates the quote and the time that you execute the exchange, your actual true-up cost can vary from the that specified in the quote. If the variance crosses the threshold that you specify,Tanzu CloudHealth does not allow the exchange action to get executed.
5. Click Save Action.

Update IAM Policy

If you have an IAM Policy associated with the Authorizer, add these privileges to that Policy so that Tanzu CloudHealth can perform the exchange on the Authorizer’s behalf.

1. Login to the AWS Console as an administrator. Navigate to Services > IAM and from the left menu, select Policies.
2. Locate the policy you are using to manage the Authorizer’s privileges.

3. Copy and paste the following section into the Policy Document field.

   {  
      "Effect": "Allow",  
      "Action": [  
          "ec2:ModifyReservedInstances",  
          "ec2:DescribeReservedInstancesOfferings",  
          "ec2:GetReservedInstancesExchangeQuote",  
          "ec2:AcceptReservedInstancesExchangeQuote"  
      ],  
      "Resource": "*"  
   }
   

4. Click Apply Policy.

Initiate an Automated Exchange

1. From the left menu, select Recommendations > Reservations > EC2 CRI Exchanger. A quote based on the selected evaluation period appears.
2. Select one or more exchanges from the quote and click Exchange. If an exchange is already in progress, you cannot initiate a new one.
3. Tanzu CloudHealth queues up the exchange transaction and notifies the Authorizer. The Authorizer must provide a least-privilege token that Tanzu CloudHealth then uses to performs the exchange. The STS token that is provisioned for the authorization flow is valid for 60 minutes.An exchange should take ~15-60 minutes from the point of approval/authorization to completion.

4. Click the Status and History tab to view the status of the exchange action.
   An exchange action cycles through these statuses.
   Pending: The action has been queued up.
   Failed: One or more exchanges in the batch failed.
   Completed: The action completed successfully or with partial failure of exchanges in the batch.

   Click an action to review details.

Option 2: Allow Tanzu CloudHealth to Perform Exchange Action

In this option, you edit the policy associated with the IAM Role you configured for your AWS account in the platform.

Update IAM Policy

1. From the left menu, select Setup > Accounts > AWS and edit the account in which you want to allow Tanzu CloudHealth to perform exchanges on your behalf.
2. Navigate to the Automation section and switch on the option to Exchange Amazon EC2 Reserved Instances.

3. Scroll to the bottom of the account setup page and click Generate Policy. The following section gets added to the policy.

   {  
      "Effect": "Allow",  
          "Action": [  
              "ec2:ModifyReservedInstances",  
              "ec2:DescribeReservedInstancesOfferings",  
              "ec2:GetReservedInstancesExchangeQuote",  
              "ec2:AcceptReservedInstancesExchangeQuote"  
          ],  
          "Resource": "*"  
   }
   

4. Copy the policy and paste.
5. Login to the AWS Console as an administrator. Navigate to Services > IAM and from the left menu, select Policies.
6. Locate the policy you are using to manage IAM. Paste the updated policy in the Policy Document field. Then click Apply Policy.

Configure Action for Exchange Automation

1. From the left menu, select Setup > Governance > Actions.
2. Navigate the the Available actions list on the right. Locate the action to Exchange Amazon EC2 Reserved Instances and click Setup.
3. In the Setup dialog box that appears, enter the name of an authorizer. This individual receives a notification when you initiate an exchange. They must then provide a secret key that accompanies the notification in order to initiate the automated exchange.
   If you do not enter an authorizer’s name, Tanzu CloudHealth will perform the exchange on your behalf, provided the correct privileges exist in the IAM policy associated with your account.
4. Specify a True Up Cost Threshold, which is set to 5% by default.

   Why do you need to specify this threshold As a best practice, get authorization on an exchange action as close to the time of quote generation as possible. This approach reduces the likelihood of large variances in the true-up cost. The true-up cost in a convertible RI exchange is transient because of the dynamic nature of the transaction. Between the time that Tanzu CloudHealth generates the quote and the time that you execute the exchange, your actual true-up cost can vary from the that specified in the quote. If the variance crosses the threshold that you specify, Tanzu CloudHealth does not allow the exchange action to get executed.

5. Click Save Action.

Initiate an Automated Exchange

1. From the left menu, select Recommendations > Reservations > EC2 CRI Exchanger. A quote based on the selected evaluation period appears.
2. Select one or more exchanges from the quote and click Exchange. If an exchange is already in progress, you cannot 
3. Tanzu CloudHealth queues up the exchange transaction. If the correct privileges exist in the IAM policy associated with the AWS Account, Tanzu CloudHealth performs the exchange.An exchange should take ~15-60 minutes from the point of approval/authorization to completion.
4. Click the Status and History tab to view the status of the exchange action.
   An exchange action cycles through these statuses.
   Pending: The action has been queued up.
   Failed: One or more exchanges in the batch failed.
   Completed: The action completed successfully or with partial failure of exchanges in the batch.
   Click an action to review details.

Analyze Reserved Instance Usage

Why Regular Analysis of Reserved Instance Usage is Essential

The approach of running instances On-Demand offers flexibility but can also drive up costs. AWS Reserved Instances (RIs) allow you to make an upfront monetary commitment to AWS in return for a discount on your compute costs. See What Are Reserved Instances

Due to the highly dynamic nature of cloud infrastructure, it is common for your RI usage to “drift” over time. For example, consider that you purchase ten m3.large reservations for Linux in us-east-1a. Later, your team might decide to move instances to other Availability Zones, rendering some of your RIs unused. The more dynamic your environment is, the more likely you are to see drift across your effective usage of RIs. Left unmonitored, the usage drift can cause a significant reduction in the cost savings that RIs help you realize.

One best practice for managing drift is to continuously assess the effectiveness of your usage of RIs over a predefined interval (for example, once a week). If you identify underutilization of RIs early, you can purchase and maintain the most cost effective RIs for your environment. Tanzu CloudHealth provides a report called the RI Analyzer to simplify the time-consuming and error-prone analysis of RI utilization in a complex cloud environment.

What is the RI Analyzer

The RI Analyzer is a report that provides an overview of your reservation usage for each EC2 instance type. The report is based on instance activity, and its primary purpose is to help you understand if your instances are well covered by reservations. The report is not intended to present reservation utilization or reservation inventory.

In order to develop this report, the platform first analyzes your hourly usage based on information in your Amazon Detailed Billing Record (DBR). The resulting report shows your instance and reservation usage as an average for the month to date (MTD) or now.

For each instance, the report shows you the following information:

• The Location, Instance Type, OS, and Tenancy
• Whether all purchased RIs are being used effectively
• Opportunities to buy more RIs for cost optimization

This report shows your inventory of reservations and identifies potential savings by comparing instances running versus reservations owned. Conversely, if you own many reservations and have fewer instances running, the Analyzer indicates how much your are overpaying.

The report can be sorted, exported to CSV, and filtered. You can also customize the report columns.

In order to compile the usage report, the Analyzer builds an inventory of your reservation purchases. Therefore, if you have one or more consolidated billing accounts, add all associated linked accounts in the platform. If one or more linked accounts are missing, reservation counts can be underreported, leading to inaccuracies.

Understanding the RI Analyzer Report

Effect of Analysis Period

You can set one of two values in the Analysis Period dropdown. Each setting results in a slightly different calculation approach for some report columns.

• Current Month: The ## Instances, ## Reserved Instances, and ## Unused Reserved Instances are averaged for the period between the beginning of the current month and now. In addition, the columns Effective Cost Per Month and Reservation Savings Per Month represent amounts since the beginning of the current month scaled to a month.
• Now: The ## Instances and ## Reserved Instances are retrieved from inventory at that specific time, i.e., now. All costs are scaled to a month.

Report Summary

The blue bar at the top of the report summarizes your reservation usage for the Analysis Period, which can be Current Month or Now.

• ## Instances: The average instance usage based on hourly data.
• ## Reservations: The average reservation usage based on hourly data.
• RIs (% of Total Hours): The percentage of the total hourly instance usage that was covered by a reservation.
• Reservation Savings: The total savings per month from the usage of reserved instances. This percentage represents the difference between the on-demand costs for all instance usage and the cost with your reservations based on the current reservation prices. A negative value in this column indicates that you have unused RIs.

Report Columns

The report shows a row for every instance type running in the Analysis Period. Default columns provide additional details to help you understand how each instance type is being used.

Using the Filters dropdown, you can narrow the report by Account, Operating System, Tenancy, or Instance Type.

Recommendations

Tanzu CloudHealth recommendation for how best to optimize this instance type based on current usage in the Analysis Period. For detailed recommendations and more options, see Modify Reservations Using EC2 RI Modifier.

• Recommendations are only made at the zonal level, not at the regional level. Tanzu CloudHealth considers regional reservations when making recommendations, but evaluates opportunities only for a given zone. Therefore, you can decide whether to purchase reservations scoped to a Region or an Availability Zone. For more information, see

  Consider this example report, which indicates that both the ## Instances and ## Reserved Instances are equal to 7. Yet notice that the report suggests that you Sell, modify or convert 4 reservations.

  The Reserved Instance shown on the third row is scoped to the us-west-1 Availability Zone, which contains 4.0 unused Reserved Instances. The Analyzer refers to these 4 Availability-Zone-scoped instances when suggesting that you sell or modify them.

  Moreover, the report will display a Region-scoped RI only if there are unused reservations scoped to a Region.

• When the Analysis Period is specified as Current Month, the ## Instances and ## Reserved Instances are averaged over a period of time.

  As a result, you might see a recommendation to buy more RIs while you have unused RIs, as this example shows. Alternatively, you might see a recommendation to buy more RIs scoped to an Availability Zone when you have unused RIs scoped to a Region. How instances are covered by RIs cannot be directly ascertained by comparing two numbers, but only by comparing the usage breakdown and RI breakdown over the analysis period. You can still see cost savings by purchasing more RIs even though those RIs or existing ones might not be fully used.

Instance Attributes

• Location: The region or Availability Zone to which the instance is scoped.
• Instance Type: The instance type, e.g., m2.2xlarge.
• Operating System: The operating system for the instance type, e.g., Linux.
• Tenancy: Type of hardware on which the instance type is running, e.g., shared, dedicated, or default.
• Account: The account to which the instance usage is attributed.

RI Usage Attributes

• ## Instances: The average number of instances of this type that are running in the analysis period.
• ## Reserved Instances: The average number of reservations of this instance type in the analysis period.

The key to effectively using the report is the intersection of (a) ## Instances and (b) ## Reserved Instances. You can compare these two columns to answer these questions:

• Do you have unused or underutilized reservations for this instance family
• Is there an opportunity to save money by purchasing more reservations

Result of comparison	Interpretation
(a > b)	You can probably save more money.
(b > a)	You have underutilized instances.
(a ~= b)	Your reservations are well utilized.

Cost Attributes

• Effective Cost Per Month: The cost you pay for that instance in an Availability Zone. It is computed by considering the following aspects:
  • On demand usage in that zone (if any)
  • Cost of Availability-Zone-Scoped RI in the zone (including both used and unused RIs)
  • Cost of Region-scoped RIs that floated into the zone

• Reservation savings per month: Your savings resulting from the purchase of RIs. It is calculated as follows:

  (Cost of running instances on-demand per month – Current Effective Cost Per Month)
  

Manage RDS Reservation Quotes Using RDS RI Optimizer

The decision to make an accurate and effective RI purchase can be a daunting task, often requiring long, tedious, and error-prone analysis.

The Tanzu CloudHealth RDS RI Optimizer evaluates your RDS instances to determine if you can benefit from the use of RIs. During the evaluation, the Optimizer analyzes your previous usage and identifies the optimum purchase for a given budget.

Tanzu CloudHealth uses a constraint-based algorithm that makes recommendations by taking a greedy approach to the classic “knapsack problem.” The analysis is performed by reviewing hourly on-demand usage over a time period. The algorithm trades off one or more efficient options for less efficient ones in order to identify the optimum reservation purchase that fits within your budget constraints. The aim is to provide the best recommendations for your specified constraints such as budget, purchase date, and filters.

Prerequisite: Enable Cost and Usage Report (CUR)

AWS Cost and Usage Reports (CUR) provide comprehensive data about your costs, including those related to product, pricing, and usage. For more information, see AWS Cost and Usage Reports.

Enable the CUR in the platform before using the EC2 RI Optimizer to evaluate your on-demand usage.

What happens if the CUR is not enabled

The recommendations that the RDS RI Optimizer presents might be inaccurate for any RDS instance family that has underutilized, size-flexible reservations.

How many days worth of data does the CUR need to have

At least 30 days of data. If you only recently configured the CUR, and have less than 30 days of data, the platform will provide correct analysis and recommendations based on the partial history. The platform will also present warnings that give the option of viewing the old report, populated with data that does not account for size-flexible RIs.

Step 1: Create Quote

The RDS RI Optimizer analyzes your instance usage and requirements based on a quote that you build. You can also modify or delete existing quotes and execute a purchase within a quote. 1. Select Recommendations > Reservations > RDS RI Optimizer. 2. Click New Quote.

If you have not enabled the CUR, Tanzu CloudHealth does not receive the complete reservation history for the accounts and time period you specify in the Optimizer. As a result, Optimizer recommendations are based on incomplete information and might be inaccurate.

By default, Tanzu CloudHealth proposes an RI purchase that provides close to 100% coverage of your instances without any limit on budget. The proposal is based on an analysis of current and historical on-demand usage of instances on an hourly basis.

Tanzu CloudHealth does not autosave changes to the quote. After each set of changes, click Actions > Save As at the top-right corner of the quote to retain your changes.

Step 2: Configure Quote Options

Review the default options that Tanzu CloudHealth sets when you create a quote. When modifying the options, consider what settings are ideal for your cloud environment.

• Choose Time Period To Analyze: Specify the time period over which you want your on-demand usage analyzed. Select a time period that is most reflective of the usage you expect in the future. The best practice is to analyze usage over the last month. For highly dynamic environments, use a shorter period of time and for more static environments, a longer period of time.
• Choose Preferred Term: While 3-year terms provide the most cost savings, customers tend to choose a 1-year term to hedge against the potential for new instance types becoming available during the term.
• Estimated Purchase Date: This date is critical if you have existing reservations that will expire before the expected purchase. When you choose a date, the Optimizer takes expiring reservations into account, ensuring that any renewals are included subject to your budget constraints.
• Purchase Account: Select a consolidated account or select All to make purchases in the account where the usage occurs.
• Reservation Types: Uncheck payment options that you do not want to use for the analysis. For example, some organizations might prefer not to use the All Upfront payment option.
• Choose Lower Prepay Res Type if Savings < X%: This setting downgrades the payment option if the savings difference between reservation types is smaller than the specified percentage. For example, if the savings from purchasing Partial Upfront RIs over No Upfront RIs is <3%, the recommendation downgrades to suggest that you purchase No Upfront RIs, which have a lower prepay than Partial Upfront RIs.

Step 3: Constrain Quote to Subset of Infrastructure

The RDS RI Optimizer allows you to constrain the quote to a subset of your infrastructure. For example, you might want to make an RI purchase for specific accounts, regions (e.g., US East (Northern Virginia) Region), instance types (e.g., db.m3 instance types), functions (e.g., Elasticsearch Clusters), or even business groups (e.g., marketing department).

Use the Filters function of the Extended Options section to target a specific subset of your infrastructure for an RI quote.

If you want to make more than one RI purchase for a subset of your infrastructure, be careful about targeting overlapping infrastructure (e.g., creating a quote that includes usage in the same account twice). This action can result in over-purchasing of reservations.

Click Run Optimizer after setting Options and Filters.

Step 4: Review Recommendations

After running an evaluation, the Optimizer returns recommendations for RI purchase. Recommendations include both high-level and detailed summaries.

Review High-level Summary

This section includes the following information.

• Potential monthly and annual savings through the RI purchase
• Number and types of RIs to purchase to achieve the savings
• Upfront Amazon payment required to achieve the savings
• Effective cost savings minus upfront payments.
• The percentage of reservation coverage you will have after the purchase
• The number of months to achieve the payback.

Review Detailed Summary

This section provides information on each unique recommendation. In addition to the information for each account, the section provides the summary for each proposal.

Step 5: Modify Recommendations

The RDS RI Optimizer presents recommendations based on the options that you configure. However, you can modify those recommendations.

For example, if the Optimizer recommends purchasing 10 Partial Upfront reservations for db.m4.large using a mysql DB Engine, you can choose to purchase only 7 if you expect a future reduction in load that affects this instance type.

Click the gear icon to modify a recommendation.

The Recommended Usage view shows the on-demand usage overlaid on the recommended RI usage by type. This view helps you see what your usage looks like today and how Tanzu CloudHealth recommends this expense be managed with RI purchases.

In addition, the view presents these key attributes of the recommendation.

• Pricing: Upfront, monthly, and effective costs per unit purchased for the available offering types. The upfront fees and monthly costs are based on customer-specific pricing, which is impacted by tiered discounts and custom pricing plans. Tanzu CloudHealth derives this pricing from your AWS bill, which provides a summary from AWS of hourly costs for all usage. If customer pricing is unavailable, the on-demand pricing is displayed.
• Savings over On-Demand: Percentage savings over on-demand usage for 100% usage of the reservation.
• Quantity: An editable field where you can adjust the number of reservations for each offering type.
• Cost: The product of the Pricing column and Quantity column.
• Monthly Savings: Projected reduction in your monthly bill if you fully utilize the proposed reservation purchase.
• Term Cost: The total amount you will pay for this reservation based on full usage. This cost includes both the upfront fees and recurring monthly costs.

Step 6: Review Post-Purchase Infrastructure

The purpose of the Summary tab in the RDS RI Optimizer is to help you visualize what your infrastructure will look like if you make purchases based on the recommendations.

The report uses up and down arrows to show where there are changes in usage of different offering types, as well as changes in cost and reservation rates. This information can be used to review with key stakeholders to gain agreement before making a purchase.

Step 7: Place Purchase Order

The Order tab displays the proposed reservation order and details that you need to make a purchase.

There are three ways to make the purchase.

• Using Tanzu CloudHealth: Configure an approval workflow for purchasing reserved instances. Then, click the Purchase button on the Quote Summary page.

  This action initiates the request for approval for reservation purchase. After both Approver and Authorizer confirm the request, the purchase is initiated.

• Through your Amazon account representative: Review the order and then select Actions > Export Order to download a file that you can share with your Amazon account representative.

• Through the AWS Console: Use the information in the Order tab to make a purchase through the AWS Console. If you have elected to purchase reservations in the accounts in which they are used, you must make a purchase within the AWS Console for each account.

AWS Commitment Discounts

Commitment Discount provides a list of reservation recommendations for all services available in AWS to view and purchase utilization. These recommendations are generated by Tanzu CloudHealth.

Commitment Discount for AWS supports the following Reservable Services:

• Amazon ElastiCache
• OpenSearch
• Amazon Redshift
• Amazon DynamoDB

Commitment Discount Reports

To access Recommendations from Commitment Discounts, navigate to AWS > Recommendations > Commitment Discounts. Click on the Export button to download the usage details in CSV format.

Click on any ID in the Account ID column or select View details from the 3-dot menu to view complete usage details.

FAQs on AWS Savings Plans

What Was Released

In November 2019, AWS announced a new offering called Savings Plans. Savings Plans are a new way to reduce your EC2 and Fargate costs while maintaining maximum flexibility. Read more about Savings Plans in the blog.

How Are These Changes Affecting Tanzu CloudHealth

If you have purchased a Savings Plan, Tanzu CloudHealth provides you with reporting to get better visibility into the costs of your Savings Plans, how your Savings Plans are being applied in conjunction with your RIs, and more. You can also use Tanzu CloudHealth Perspectives to group this analysis in the context of your business.

Cost History Report

EC2 Compute costs and Fargate costs are updated as follows.

• EC2 - Compute: This reflects the net cost of your EC2 instances after discount mechanisms, such as Savings Plans and RIs, and can be accurately grouped by perspective
• Savings Plan - Unused: This reflects the proportional cost of your Savings Plans that have not been applied to usage. This is an indirect cost item that can be reallocated.
• Savings Plan - Upfront Fee: The upfront payment upon Savings Plan purchase, for “partial upfront” and “all upfront” payment types. This is an indirect cost item that can be reallocated.
• Amazon EC2 Container Service: Indirect costs for ECS & Fargate are displayed as net costs (including Savings Plan discounts).
• EC2 - Savings Plan Negation Credits: This is an additional measure in the AWS bill that negates the portion of On Demand costs that were covered by a Savings Plan. Tanzu CloudHealth incorporates these credits directly into the EC2 - Compute line items to enable customers to attribute these credit amounts directly to usage. As a result, EC2 - Savings Plan Negation Credits appears as a $0 value.

EC2 Instance Usage and EC2 Instance Cost Reports

As with the Cost History Report, the EC2 Instance Cost and Usage Reports account for RI and Savings Plan discounts. In addition, to provide a full picture of what usage is On Demand, covered by Savings Plans, and covered by Reserved Instances, a new measure called “Coverage Type” has been introduced. This measure breaks down your cost and usage in the following manner: EC2 Savings Plan, Compute Savings Plan, Standard RI, Convertible RI, On demand, and Spot. Reservation Type will now include Savings Plans coverage in addition to Reserved Instance coverage. For example, All Upfront will show All Upfront RIs and Savings Plans coverage, thereby unlocking new views such as Coverage Type by Instance Family, filtering existing reports by Coverage type, and more.

EC2 Instance Hours

The EC2 Instance Hours report has been updated to provide new measures that enable more granular analysis of how Savings Plans are applied to EC2 usage, as well as the amortization of fees both for Savings Plans and RIs.

Updated Columns: * The RI specific measure Avg Amortized Cost has been renamed as Avg RI Amortized Cost.

New Columns:

• EC2 Savings Plan Hours: The number of hours this instance was covered by an EC2 Instance Savings Plan
• Compute Savings Plan Hours: The number of hours this instance was covered by a Compute Savings Plan
• % SavingsPlanCovered: The proportion of this instance’s usage covered by a Savings Plan (EC2 Instance Savings Plan or Compute Savings Plan)
• SP Amortized Cost: The proportion of Savings Plan fees (upfront and recurring fees) allocated to this instance based on how much of the Savings Plan was used for this instance’s coverage.
• RI Amortized Cost: The proportion of RI fees (upfront and recurring fees) allocated to this instance based on how much of the RI was used for this instance’s coverage.
• Total Amortized Cost: The sum of SP Amortized Cost and RI Amortized Cost for this instance.

Savings Plan Asset Report

Savings Plans now have their own asset report where users can get an overview of their Savings Plans, their status, associated fees, and more. As with other asset reports, to enable this report you will need to update your AWS IAM policy.

Convertible RI Exchanger

The Convertible RI Exchanger continues to make accurate recommendations and should be leveraged by all customers. Usage covered by a Savings Plan is excluded from recommendations. Since AWS applies RIs first and then applies Savings Plans, Tanzu CloudHealth recommends customers ensure they are getting the greatest value possible from their RI investment. Savings Plan discounts apply to On-Demand usage that is not covered by reservations. Note that projected savings may be overestimated if usage is also covered by a Savings Plan.

RI Pulse Reports

If you do not have a Savings Plan, these reports will continue to function as expected. If you have a Savings Plan, Savings Plan covered usage is temporarily considered as On Demand usage, affecting RI Savings (total amount is inflated), Reservation opportunities (shows Instances that are covered by a Savings Plan), and overestimated cost savings from RI modifications if usage is covered by a Savings Plan.

EC2 RI Analyzer

The RI Analyzer does not account for Savings Plans, so it may make inaccurate recommendations in these cases. Usage covered by Savings Plans is interpreted as On-Demand usage.

EC2 RI Optimizer

If you have not purchased a Savings Plan in the selected evaluation period, your RI recommendations are accurate. The RI Optimizer may make incorrect recommendations when a Savings Plan has been purchased within the selected evaluation period.

EC2 RI Modifier

The EC2 RI Modifier continues to make accurate recommendations, but may overestimate the savings if usage is also covered by a Savings Plan. Usage covered by Savings Plans is interpreted as On-Demand usage.

Policies

Policies behave as expected. Savings Plan discounts are included in policy evaluations for the EC2 Instance, AWS Billing Statement, and Multicloud Spend resource types.

Partner Platform

Partners and their customers can each purchase Savings Plans and have savings applied at the appropriate level in the Tanzu CloudHealth billing engine.