Reserved Capacity & Commitment Optimization

This dimension covers turning steady-state database usage telemetry into defensible commitment decisions — RDS and Aurora Reserved Instances, Compute Savings Plans, and Azure reserved capacity — then tracking coverage, utilization, and break-even so a discount never quietly decays into waste.

Back to: Cloud Database Cost Fundamentals & Architecture

Commitment discounts are the largest single lever on a managed-database bill, and also the easiest to get wrong. A one- or three-year Reserved Instance or Savings Plan trades flexibility for a 30–60% rate reduction, but the discount only materializes if the committed capacity is actually consumed for the full term. Buy too little and on-demand spend leaks around the commitment; buy too much and you pay upfront for capacity that idles. The decision cannot be made from an invoice snapshot — it has to be driven from a usage baseline that is stable enough to commit against, and then continuously reconciled against what you actually run. For Cloud DBAs, FinOps engineers, and platform teams, this is a data problem before it is a purchasing one: the quality of the commitment is bounded by the quality of the telemetry feeding it. This page covers the billing models you are committing against, how to extract and normalize the usage that justifies a commitment, the Python patterns that automate recommendation and monitoring, how coverage signals feed quota enforcement, and the failure modes that turn a good commitment into stranded spend.

The lifecycle below traces a commitment from a stable usage baseline through purchase to the monitoring loop that decides whether it gets renewed, resized, or allowed to expire.

Reserved-capacity commitment lifecycle: baseline, recommend, purchase, monitor coverage and utilization, then renew or adjust and re-baselineA steady-state usage baseline feeds a commitment recommendation, which produces a purchase of reserved capacity or a savings plan. The purchase feeds continuous coverage and utilization monitoring, whose output drives a renew-or-adjust decision that loops back to re-baseline usage.renew, resize, or re-baseline each cycleSteady-stateusage baselineCommitmentrecommendationPurchase RI /savings planCoverage &utilization monitorRenew /adjust decision

Billing Model & Attribution Challenges

The three commitment vehicles you will manage do not discount the same thing, and conflating them is the first way a commitment plan goes wrong. An RDS or Aurora Reserved Instance discounts a specific instance configuration — engine, instance family, size (unless size-flexible within a family), region, and multi-AZ flag. A Compute Savings Plan discounts a dollar-per-hour commitment against any matching compute usage regardless of instance family or region, which makes it strictly more flexible but almost always a slightly shallower discount than an equivalent RI. Azure reserved capacity for SQL Database, Managed Instance, or Cosmos DB commits to a quantity of vCores or throughput at a scope (subscription or resource group) for one or three years. Each vehicle attaches its discount at a different granularity, so the usage figure you commit against has to be measured at that same granularity or the recommendation is built on sand.

The measurement unit matters as much as the amount. RDS RIs are reserved per instance-hour of a normalized size; a size-flexible RI in the db.r6g family covers db.r6g.large at one normalization factor and db.r6g.xlarge at twice that, so a fleet of mixed sizes has to be converted to normalized units before you can decide how many RIs actually cover it. This normalization is the same discipline as mapping heterogeneous provider SKUs onto a canonical model — get the unit wrong and a “100% covered” fleet is quietly 60% covered because the sizes did not add up the way a raw instance count suggested.

Commitments also interact with the compute-versus-storage split. Reserved Instances and Savings Plans discount compute only — the instance hours. Storage, provisioned IOPS, backups, and I/O all remain on-demand regardless of how deep your commitment goes. A team that reads a 40% blended discount off the top-line bill and assumes the whole database spend is now committed is misreading the instrument; separating the committable compute base from the always-on-demand remainder is exactly the work of compute versus storage cost disaggregation, and it must happen before any break-even math. Only the compute line is a candidate for a commitment.

Two further attribution traps recur. First, amortization: an all-upfront RI shows a large one-time charge in the month of purchase and zero recurring cost thereafter, which wrecks any monthly chargeback unless the upfront fee is amortized across the term. A commitment ledger must carry the amortized monthly figure, not the cash-basis charge, or one tenant absorbs a full year of another tenant’s discount in a single month. Second, shared scope: a Savings Plan or account-level RI applies its discount to whichever eligible usage the billing engine matches first, which is not necessarily the tenant that “owns” the commitment. Attributing a shared commitment’s benefit back to the tenants who consumed it requires the same tenant-key allocation used across the broader cost model, and it is why coverage has to be tracked per scope, not just in aggregate.

Telemetry Extraction & Metric Normalization

A commitment is only as good as the baseline behind it, and a baseline is a statistical claim about usage stability, not a single number. The input is a time series of hourly compute consumption per instance family and region, pulled from Cost Explorer usage data and, where finer resolution is needed, CloudWatch instance-hour metrics. Those pulls are concurrent and rate-limited, so they run through the same async, semaphore-controlled usage parsing that the rest of the extraction layer uses — a commitment analysis over a 12-month lookback across dozens of accounts is exactly the kind of fan-out that trips Cost Explorer’s request quotas if issued naively.

The normalization that matters most for commitments is converting raw instance-hours into a committable steady-state floor. You do not commit against average usage — you commit against the stable base that is present essentially all the time, because any usage above that floor is cheaper left on-demand than locked into a reservation that idles when the peak recedes. A robust baseline takes a low percentile (commonly the 10th to 20th) of hourly usage over the lookback window per family, so transient spikes and scale-in troughs both fall out of the committed figure:

committable_units=P20({ uh:h∈lookback })\text{committable\_units} = P_{20}\big(\{\,u_h : h \in \text{lookback}\,\}\big)

Here $u_h$ is normalized compute units in hour $h$, and $P_{20}$ is the 20th percentile — the level below which usage rarely falls. Committing to that floor captures the deep discount on the always-on base while leaving the volatile top of the load on flexible on-demand or a shallower Savings Plan.

Size-flexibility normalization is the second required transform. Before percentiles mean anything, every instance-hour is converted to normalization-factor units within its family so that a db.r6g.large hour and a db.r6g.2xlarge hour are expressed on one scale. Only then can a single reserved-unit count be compared against the fleet. Skipping this step is the single most common reason a recommendation over-buys: raw instance counts hide the fact that a handful of large instances dominate the committable base.

Python Automation Patterns

The idiomatic implementation reads recommendations and coverage straight from the Cost Explorer API and wraps every call in retry-with-backoff, because Cost Explorer throttles aggressively under the multi-account fan-out a commitment review requires. The two workhorses are get_reservation_purchase_recommendation and get_savings_plans_purchase_recommendation for the buy side, and get_reservation_coverage, get_savings_plans_coverage, and get_savings_plans_utilization for the monitoring side. The break-even arithmetic that turns a recommendation into a go/no-go decision is worked end to end in calculating RDS Reserved Instance break-even; the coverage and utilization monitoring loop is detailed in tracking Savings Plan coverage and utilization.

A resilient recommendation pull looks like this — note the tenacity retry guarding the exact throttling exception Cost Explorer raises:

import os
import boto3
from botocore.exceptions import ClientError
from tenacity import retry, wait_exponential, stop_after_attempt, retry_if_exception

ce = boto3.client("ce", region_name=os.environ.get("AWS_REGION", "us-east-1"))


def _is_throttle(exc: BaseException) -> bool:
    return (
        isinstance(exc, ClientError)
        and exc.response["Error"]["Code"] in {"ThrottlingException", "LimitExceededException"}
    )


@retry(
    retry=retry_if_exception(_is_throttle),
    wait=wait_exponential(multiplier=1, min=2, max=30),
    stop=stop_after_attempt(5),
    reraise=True,
)
def rds_ri_recommendation(term="ONE_YEAR", payment="NO_UPFRONT", lookback="SIXTY_DAYS"):
    """Fetch AWS's RDS Reserved Instance purchase recommendation."""
    resp = ce.get_reservation_purchase_recommendation(
        Service="Amazon Relational Database Service",
        LookbackPeriodInDays=lookback,          # SEVEN_DAYS | THIRTY_DAYS | SIXTY_DAYS
        TermInYears=term,                        # ONE_YEAR | THREE_YEARS
        PaymentOption=payment,                   # NO_UPFRONT | PARTIAL_UPFRONT | ALL_UPFRONT
    )
    return resp["Recommendations"]


if __name__ == "__main__":
    for rec in rds_ri_recommendation():
        summary = rec["RecommendationSummary"]
        print(summary["TotalEstimatedMonthlySavingsAmount"], summary["CurrencyCode"])

Expected output for an account with an under-committed RDS fleet:

1284.60 USD

The important structural choice is that recommendation, break-even evaluation, and monitoring are separate functions over the same client, not one monolith. AWS’s recommendation is an input, not an instruction — it optimizes for AWS-visible usage and cannot see your planned migrations, decommissions, or engine changes. The automation’s job is to pull the recommendation, re-run the break-even against your own baseline percentile and your own knowledge of upcoming changes, and only then surface a candidate for human approval. Purchases are never auto-executed; a one- or three-year commitment is exactly the class of action that should require a person to click.

For Azure reserved capacity the shape is the same but the transport differs: recommendations come from the Cost Management GenerateReservationDetailsReport and the reservation recommendations API via azure-mgmt-costmanagement with DefaultAzureCredential, and the same percentile-baseline logic is applied to the vCore usage series before a quantity is committed.

Quota Enforcement Integration

Coverage and utilization are not just reporting metrics — they are control signals. A commitment that drifts out of its healthy band should change behavior, and the cleanest place to wire that is the same threshold engine used for spend. Two conditions matter. Under-coverage means eligible usage is running on-demand outside any commitment: the discount opportunity is being missed and on-demand spend is climbing. Under-utilization means committed capacity is going unused: you are paying for a reservation that no workload is matching against, which is pure waste and, on an all-upfront plan, unrecoverable.

Both feed naturally into database quota boundary design. A coverage figure that falls below target for a sustained window is a signal that new provisioning has outrun the committed base — a soft condition that should prompt a commitment review before it becomes chronic on-demand leakage. A utilization figure that drops sharply is often the early symptom of a workload being decommissioned or migrated away from the reserved family, and it should hold any further commitment purchases for that family until the baseline restabilizes. The rule that keeps this safe is the same one that governs all enforcement: act only on validated, deduplicated figures over a defined window, never on a single hour’s coverage dip that a nightly batch job or a maintenance window can easily explain.

from decimal import Decimal


def commitment_action(coverage_pct: Decimal, utilization_pct: Decimal,
                      coverage_target: Decimal, util_floor: Decimal) -> str:
    """Map a commitment's coverage and utilization onto a control action."""
    if utilization_pct < util_floor:
        return "hold_purchases"      # committed capacity idling; do not buy more
    if coverage_pct < coverage_target:
        return "review_increase"     # eligible on-demand leaking; evaluate a top-up
    return "healthy"


# >>> commitment_action(Decimal("0.72"), Decimal("0.99"), Decimal("0.80"), Decimal("0.90"))
# 'review_increase'

Failure Modes & Troubleshooting

Commitment automation fails in characteristic ways, most of them silent until a renewal or an invoice makes them expensive.

  • ThrottlingException / LimitExceededException mid-analysis. Cause: Cost Explorer rate limits under the multi-account fan-out a commitment review issues. Resolution: bound concurrency with a semaphore and wrap every call in exponential backoff; treat a persistent limit as a signal to widen the request window rather than hammer harder.
  • DataUnavailableException on a fresh account. Cause: get_reservation_purchase_recommendation needs a usage history; a lookback that predates the account’s activity returns no data. Resolution: shorten the lookback to SEVEN_DAYS, or defer the analysis until at least 30 days of steady-state usage exists — committing against a sub-month baseline is unsound anyway.
  • Recommendation over-buys because sizes were not normalized. Cause: raw instance counts were fed to the baseline instead of normalization-factor units. Resolution: convert every instance-hour to family-normalized units before taking the percentile; verify the reserved-unit count reconciles against the normalized fleet total.
  • Coverage looks fine but on-demand spend is rising. Cause: coverage was measured in aggregate while a specific instance family drifted out of commitment. Resolution: track coverage per family and region, not just at the account level, so a single drifting dimension is not masked by a well-covered average.
  • Utilization collapses after a migration. Cause: a reserved family was decommissioned or the workload moved regions, stranding the reservation. Resolution: alert on the utilization drop immediately, then use RI modification (ModifyReservedInstances-equivalent flows) or Savings Plan flexibility to redirect the discount before the term burns off.
  • Chargeback spikes in the purchase month. Cause: an all-upfront fee was booked on a cash basis instead of amortized. Resolution: carry the amortized monthly figure in the ledger and reconcile against NetRISavings/amortized cost fields, never the raw invoice line.

Underpinning all of it, emit structured metrics for coverage, utilization, and realized-versus-projected savings per family so an on-call FinOps engineer can rank drift by dollars, and route the alerts through the delivery layer rather than a dashboard nobody watches. A commitment that nobody is watching is a commitment that decays.

Back to: Cloud Database Cost Fundamentals & Architecture