Setting the file. One moment.
Subchapter 28.42
references/vendored/estimate/ri-sp-eligibility.mdMarkdown20 KBView on GitHub
Canonical AWS commitment-discount eligibility reference for estimate cost engines, vendored into each skill that emits () and kept byte-identical by . This file answers ONE question: It is deliberately source-cloud-agnostic — nothing here depends on whether the workload came from GCP, Heroku, Azure, or anywhere else. Source-cloud billing quirks (e.g. a source platform showing for a pre-paid reserved resource) belong in that skill’s own discovery phase, not here.
optimization_opportunities[]references/vendored/estimate/ri-sp-eligibility.mdshared:sync$0Before this file, gcp-to-aws and heroku-to-aws each carried their own,
independently-drifting list of “which services get a Savings Plan/RI callout.”
Both lists had real gaps: Database Savings Plan coverage was gated on
“RDS/Aurora in design” only, missing DynamoDB/ElastiCache entirely; neither
skill distinguished DynamoDB on-demand from provisioned (only provisioned
supports DynamoDB reserved capacity); neither distinguished ElastiCache engine
(Database Savings Plans cover ElastiCache for Valkey only — Redis OSS and
Memcached still require Reserved Nodes); and Bedrock Provisioned Throughput
was implicitly lumped in with “1-year or 3-year” language it does not have
(its commitment terms are no-commit / 1-month / 6-month, billed hourly). This
file is the single source of truth so those distinctions get made once and
stay correct everywhere they’re consumed.
| AWS service / usage mode | RI-eligible | SP-eligible | Which SP | Notes |
|---|---|---|---|---|
| EC2, Fargate, Lambda | EC2 only (EC2 Reserved Instances or EC2 Instance Savings Plans) | Yes | Compute Savings Plan | Compute SP applies automatically across EC2 (any family/size/OS/region/tenancy), Fargate, and Lambda. Do not gate SP eligibility on “serverless vs provisioned” — gate strictly on this product list. |
| RDS / Aurora — provisioned | Yes (RDS/Aurora Reserved DB Instances) | Yes | Database Savings Plan | RI and Database SP are mutually exclusive on the same instance — pick one per workload; a workload may use RIs while another workload on the same account uses Database SP. |
| Aurora Serverless v2 | No | Yes | Database Savings Plan | No RI product exists for serverless database capacity. |
| DynamoDB — provisioned, Standard table class | Yes (DynamoDB reserved capacity: 1-year or 3-year term, up to 54%/77% savings) | Yes | Database Savings Plan | RI and Database SP are mutually exclusive on the same capacity, same rule as RDS. Reserved capacity is purchased in 100 WCU/RCU allocations. |
| DynamoDB — on-demand, or Standard-IA table class | No — AWS explicitly excludes on-demand and Standard-IA from reserved capacity | Yes | Database Savings Plan | Database Savings Plan is the only commitment lever for on-demand DynamoDB. Never present a DynamoDB on-demand design with an RI-style callout. |
| ElastiCache — Valkey, provisioned (node-based) | Yes (ElastiCache Reserved Nodes) | Yes | Database Savings Plan | Database SP coverage for ElastiCache is Valkey-only. Both RI and SP apply here — Database SP is generally preferable post-migration for flexibility (see gcp-to-aws’s RDS-parallel guidance); Reserved Nodes remain an option for a stable, long-lived node footprint. |
| ElastiCache — Valkey, serverless | No — ElastiCache Serverless has no node concept (billed in ECPUs + GB-hours); Reserved Nodes require a node-based cluster and do not apply | Yes | Database Savings Plan | Database SP is the only lever for serverless ElastiCache, regardless of engine. |
| ElastiCache — Redis OSS or Memcached, provisioned (node-based) | Yes (ElastiCache Reserved Nodes) | No | — | Not Database-SP-eligible. This matters directly for any skill whose default target engine is Redis OSS — check the Design phase’s actual selected engine before emitting a Database SP opportunity for ElastiCache; fall back to “Reserved Nodes only” language for Redis OSS/Memcached targets. |
| ElastiCache — Redis OSS or Memcached, serverless | No — same Serverless/Reserved-Nodes incompatibility as above | No | — | No commitment product of any kind applies — not Database SP (wrong engine) and not Reserved Nodes (serverless, no nodes to reserve). State this plainly rather than defaulting to the Reserved Nodes language used for the provisioned case. |
| DocumentDB, Neptune, Keyspaces, DMS | Some have their own RI-equivalents (verify per-service before claiming one exists) | Yes | Database Savings Plan | Lower priority — surface only when present in the design. |
| OpenSearch Service | Yes (OpenSearch Reserved Instances) | Yes | Database Savings Plan | — |
| Timestream | Unconfirmed whether Database SP coverage is restricted to a specific sub-product (e.g. InfluxDB) — verify against current AWS documentation before shipping copy more specific than “Timestream is on AWS’s Database Savings Plan coverage list.” | Yes (generic Timestream is listed) | Database Savings Plan | Flagged as needing verification; do not assert a sub-product restriction without confirming it. |
| Bedrock (on-demand inference) | No | No | — | The only commitment lever is Provisioned Throughput (type: provisioned_throughput in optimization_opportunities[]) — a distinct product, not a Savings Plan or RI variant. Terms: no-commit, 1-month, or 6-month, billed hourly. Never describe Provisioned Throughput as having 1-year or 3-year terms. Gate on sustained, predictable high-volume usage, not on cost-sensitivity alone. |
| AgentCore | No | No | — | Pure consumption-based pricing. No commitment product of any kind exists. State this plainly rather than omitting AgentCore from the section silently. |
| S3 | No | No | — | Intelligent-Tiering is the available lever, not a commitment plan. |
Generation restriction (applies to Database Savings Plans generally): AWS’s own documentation states Database Savings Plans apply to “the latest provisioned instance generations” — older-generation instances are excluded. Ship the qualitative “latest generation only” caveat; do not assert a specific generation-number cutoff unless it has been confirmed against current AWS documentation.
Do not collapse eligibility into a single “does this design qualify, yes or no” fallback message. A design’s services will typically split across states, and each state needs distinct handling:
| State | Example | What to say |
|---|---|---|
| RI and/or SP eligible | Fargate, RDS provisioned, DynamoDB provisioned, EC2 | Emit real optimization_opportunities[] entries (Compute SP, Database SP, RDS RI / DynamoDB reserved capacity as applicable). |
| SP-eligible, no RI product | Lambda + DynamoDB on-demand, or Aurora Serverless v2, or ElastiCache Valkey serverless | State explicitly: “No Reserved Instance product applies to this usage mode, but it still qualifies for a Compute/Database Savings Plan once usage is stable.” |
| Truly no commitment product | AgentCore + S3 + Bedrock on-demand only | State explicitly: “No 1-year/3-year commitment product exists for this stack. Bedrock inference has its own separate mechanism (Provisioned Throughput, 1- or 6-month commitment) — worth evaluating only above sustained high-volume, predictable traffic.” |
Never merge per-service product attribution into one sentence. Write “Lambda qualifies for a Compute Savings Plan.” as its own sentence, and “DynamoDB on-demand qualifies for a Database Savings Plan.” as a separate one — these are two separate facts about two separate products; Lambda has no Database-SP path and DynamoDB has no Compute-SP path. State each service’s eligible product by name, in its own sentence.
Always render the Cost Optimization Opportunities section, even when the design lands entirely in the “truly no commitment product” state. Silent omission reads as an analysis gap, not as “nothing applies” — say so explicitly instead.
This file is read by each skill’s Estimate-phase cost engine when constructing
optimization_opportunities[]. It replaces each skill’s previously
independent, partially-divergent lists. See the skill-specific cost engine
(estimate-infra.md for gcp-to-aws infra, estimate-cost-engine.md for
heroku-to-aws, estimate-ai.md for gcp-to-aws’s AI/Bedrock track) for the JSON
entry shapes and per-skill gating thresholds — this file defines eligibility
and required caveats, not the JSON schema or dollar formulas.
AI-track note (estimate-ai.md): this file’s Bedrock row is the source of
truth for the Provisioned Throughput type value and commitment vocabulary.
The other six AI-side optimizations (prompt caching, model tiering, batch API,
input token reduction, multi-model routing, intelligent prompt routing) are
not AWS commitment products — they carry commitment: "none" and are outside
this file’s eligibility matrix, which covers only RI/SP-style commitment
products. Do not add them to the matrix above; this file’s scope is
commitment-product eligibility, not a general catalog of every Bedrock cost
lever.