All cheat sheets
Databasescheat sheet

OpenSearch Reserved Instances

Commit to 1 or 3 years of OpenSearch capacity for 30–50% off on-demand on the nodes you already run 24/7. Instance-family- and region-locked, no refunds, compute-only — reserve the baseline, not the peak.

Last reviewed: July 14, 2026

Prefer step by step? Take the guided OpenSearch Reserved Instances walkthrough — free, anonymous, interactive.Have an AI assistant? Jump to the copy-paste audit prompt at the bottom of this sheet.

TL;DR: For an OpenSearch domain already running 24/7, Reserved Instances cut 30–50% off the same nodes with a 1- or 3-year commitment. The discount applies automatically to matching instances (no attach step), but RIs are instance-family-locked, region-specific, non-refundable, and compute-only. It's mostly commitment math: if you're right that you'll use the cluster consistently, it's some of the easiest savings in AWS.

The numbers

  • Payment tiers: All Upfront (deepest), Partial Upfront (balanced), No Upfront (smallest but preserves cash) — collectively the 30–50% range; longer term = bigger discount.
  • Worked example — an r6g.xlarge.search log/monitoring cluster running 24/7 at $4,200/mo on-demand dropped to ~$2,600/mo on a 1-yr Partial Upfront RI (~$1,600/mo, ~$20K/yr saved).
  • Coverage is count-based: reserve for the baseline; peak nodes above it bill on-demand.
  • Field examples: a stable 50K-user SaaS logging cluster locked a 1-yr Partial for ~$20K/yr; a large org reserved only its 5 unchanged-for-a-year production domains 3-yr All Upfront and left dev/test on-demand, experimental on Serverless.

Do this

  1. Analyze 3–6 months of actual node-hours by instance type in Cost Explorer — buy what matches reality, not what you intended to run.
  2. Cover the baseline, not the peak — steady at 6 nodes, spiking to 9 → reserve 6, let 3 ride on-demand (the #1 way teams overpay is reserving for peak).
  3. Match instance family and region exactly — an r6g.large.search RI does nothing for m5.xlarge.search or another region.
  4. Compare against Compute Savings Plans — for some workloads a CSP applies more flexibly than an instance-family-locked RI; run both numbers.
  5. Set an expiration reminder 60 days out — RIs don't auto-renew and silently flip back to on-demand.

Gotchas

  • Instance family is locked — migrate from r6g.large.search to m5.xlarge.search mid-term and you pay for the old reservation and full on-demand on the new nodes.
  • Compute only — EBS storage, snapshots in S3, UltraWarm/cold tiers, and data-transfer-out all still bill on-demand; the OpenSearch bill never reaches zero.
  • No refunds — the Reserved Instance Marketplace exists but selling is rarely clean.
  • Region-locked — cross-region setups need separate reservations.

Skip this if

  • The workload is variable, dev/test, or experimental — on-demand or OpenSearch Serverless (billed on OCUs, not nodes) fits better.
  • The architecture might change within 12 months, or you haven't confirmed a steady baseline — stay on-demand and revisit after a few months; confirm baseline node-hours with AWS Cost Explorer before committing.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Amazon OpenSearch Service domains for
Reserved Instance savings. Use the AWS CLI with READ-ONLY credentials.
Do not create, modify, or delete anything — report findings and
recommended (unapplied) fixes only.

1. Inventory: aws opensearch list-domain-names + describe-domain — capture
   per domain the instance type (e.g. r6g.xlarge.search), node count, and
   whether it runs 24/7. aws opensearch
   describe-reserved-instances — existing RIs and end dates.
2. Baseline: pull 90 days of node-hours per (region, instance type) from
   Cost Explorer. The sustained floor is the reservable count.
3. Fit: flag steady 24/7 production/log-analytics domains as RI
   candidates; flag variable/dev/experimental domains for on-demand or
   OpenSearch Serverless instead.
4. Savings math: on-demand $/node-hr × 730 × 12 vs reserved (All Upfront
   deepest, then Partial, then No Upfront ~30-50% range). Reserve
   baseline only; note compute-only (EBS, snapshots, UltraWarm, transfer
   still on-demand).

Report a table: domain | region | instance type | steady node count |
current RI | recommended reserve | term/payment | est. $/mo saved | notes.
Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The OpenSearch Reserved Instances walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough

More Databases cheat sheets

Amazon RDS Proxy

Connection count, not CPU, is often what forces an RDS upsize. RDS Proxy pools thousands of client connections (especially from Lambda) onto ~10–30 real ones, so a small instance stays small — the proxy fee typically covers 10–25% of the avoided upsize.

Athena Partition Projection

Instead of asking S3 which partitions exist before every query, Partition Projection lets Athena calculate the paths from a pattern you declare — near-instant query startup on tables with thousands of partitions, zero LIST metadata calls.

Athena Query Result Reuse

Athena caches identical query results in S3, so a repeated dashboard refresh or scheduled report returns instantly with zero bytes scanned. A workgroup checkbox that routinely cuts thousands off a scan-heavy bill.

Aurora I/O-Optimized

Aurora bills a sneaky third bucket — I/O operations at ~$0.20/million — that can dwarf compute and storage on I/O-heavy workloads. I/O-Optimized zeroes it out for a ~30–40% higher instance rate. A break-even calc, not a default.