Getting the AWS services configured

Perhaps this is just AWS being AWS, but if you want to get the information you need to help you save you money, there are a few hoops you have to jump through. First you need to turn on AWS Cost Optimization Hub and AWS Compute Optimizer, because by default they are turned off. For small companies and individual builders, nine times out of ten you're not even going to be thinking about saving a few dollars here and or there, even if it would be pretty trivial, so most people don't bother turning them on.

Then you need to let the results trickle through which can take a day or two. So, again, even if you get around to turning them on, you might forget to go and check the results, because you're too busy trying to ship your next feature.

Making sense of the data

The AWS Compute Optimizer web UI is fairly easy to get to grips with, and while the recommendations it finds should definitely be actioned, do not expect them to be exhaustive. For example, only in June of 2026 did they add six new idle findings, but obviously those findings existed for years, if not decades in some cases.

The Web UI for the Cost Optimization Hub and other AWS savings related interfaces like the recommendations in the Billing and Cost Management section I have always found to be a bit of a disaster, and the major focus is on trying to sell you saving plans, because surprise surprise, AWS wants to make money from you.

You might save money with the savings plan, but it also locks you in to a fixed spending pattern with AWS for a fixed amount of time. This then removes the incentive for you to optimize your workload: if you just bought ec2 5 instances for the next 2 years, whats the point of optimizing your setup so you only need 2 instances?

When you should use savings plans

You should only use saving plans when you're platform is mature enough that you know you're not going to be touching it, and you've already exhausted all the optimization that you feel is worthwhile investing in. So for people building stuff on their own and small companies, I generally wouldn't recommend it, because almost certainly there's a better way to save money than using the savings plan. The first focus should always be optimizing your setup.

Why you should use a non-AWS tool

The reason you should rely on another company (not AWS) to help you save money with AWS is simple: your interests align. If the third party can save you money, then both of you are happy, whereas AWS really doesn't give much of a shit if they can save you money or not.

I built Jungle Cleaner to be a simple MCP-first tool to help you optimize your AWS setup, but there's lots of other companies out there that also do a much better job than AWS, so take your pick! Just don't expect AWS to break a sweat trying to lower your bill.

The problem with Classic

OpenSearch Serverless Classic was a great way to get started with OpenSearch without managing cluster sizing yourself. But it had one expensive catch: the minimum indexing and search capacity was fixed at 2 OCUs each, regardless of whether your index was doing anything. (An OCU, or OpenSearch Compute Unit, is the billing unit AWS uses for serverless compute and memory capacity — you're charged per OCU-hour whether or not it's actually processing anything.) For an always-on production workload that's a reasonable floor. For a staging environment, a side project, or anything with bursty or intermittent traffic, you're paying a constant baseline cost 24/7 for capacity you're mostly not using.

What NextGen changes

The headline feature: NextGen can scale down to zero. If nothing's querying or indexing, you stop paying for that capacity.

There's a real trade-off to know about before you migrate: scaling up from zero isn't instant. If your search capacity has scaled to zero, the first request back can see latency in the tens of seconds while it spins back up. For dev/staging that's a non-issue. For production, you'll want to keep at least 1 unit of search capacity always on so user-facing queries never hit a cold start — you can still let indexing scale to zero if ingestion is intermittent.

The upside on the scaling side isn't just the zero floor. AWS reports NextGen scales roughly 20x faster than Classic, in both directions — it reacts to load spikes faster, and it scales back down faster too, which is what actually turns "can scale to zero" into "spends most of its time at zero" instead of getting stuck at higher capacity from residual traffic.

NextGen also lets you set minimum and maximum capacity independently for indexing and search. So rather than a single fixed floor applying to both, you can, for example, let indexing scale to zero while keeping a minimum of 1 OCU on search — or cap maximum capacity on either side if you want a hard ceiling on cost regardless of load.

Why this matters for cost

In short: you're no longer stuck paying for a fixed floor of 2+2 OCUs whether you need it or not. You pay for roughly what you actually use. That's most impactful for dev, staging, and any environment with uneven or intermittent traffic — the exact cases where Classic's fixed minimum was hardest to justify.

Whether this is actually worth doing depends on your traffic pattern, though — a consistently busy production index may not see much of a difference. If you want a quick look at whether you'd see real savings before committing to a migration, you can run the Jungle Cleaner MCP scan tool against your account — it looks at your current OpenSearch Serverless usage and estimates what you'd save by moving to NextGen.

Why the migration isn't a simple upgrade

There's no in-place upgrade path. Collection generation (Classic vs. NextGen) is immutable in OpenSearch Serverless — you can't flip a setting on an existing collection. You have to:

1. Create a brand-new NextGen collection group, then a collection inside it (with its own access, network, and encryption policies)
2. Copy your data across
3. Point your application at the new endpoint
4. Delete the old Classic collection once you've confirmed the cutover worked

AWS doesn't provide a first-party tool for step 2. Their own recommendation for cross-collection copies is to stand up an OpenSearch Ingestion pipeline — which means an IAM role, a data access policy, pipeline YAML, and its own OCU capacity, just for a one-time copy job. That's a lot of infrastructure for something you'll run once.

Setting up the new NextGen group and collection

We've put together a simple example stack — a single Lambda connecting to the index — showing how to provision a NextGen collection with sensible defaults (access policy, network policy, encryption policy): opensearch-nextgen.yaml. If you're setting this up with a coding agent, it's worth pointing it at our template as a guide rather than letting it write the policies from scratch — agents often trip up on NextGen because their training data cuts off before these settings existed, so they'll confidently reach for Classic-era configuration that doesn't apply.

Migrating the data

Once your NextGen collection exists and is up and running, use our open source migration script to copy everything over:

migrate-opensearch-classic-to-nextgen.py

A few things worth knowing about how it works:

• No _reindex. Serverless doesn't support _reindex with a remote source, so the script copies documents directly — opening a Point-in-Time on the source index, paginating with search_after, and writing batches via _bulk. This is the same fundamental approach an Ingestion pipeline uses under the hood, minus the setup overhead.
• It's idempotent. Documents are written to the target with their original _id, so re-running the script never creates duplicates — it just overwrites with identical content. This matters in practice: if new data gets written to the old collection while you're mid-migration, you can point your application at the new collection and then simply run the script again to pick up anything that landed after your first pass.
• Mappings and analyzers come across too. Custom field mappings and analyzers are copied before data, so the target index doesn't end up with OpenSearch guessing field types via dynamic mapping.
• Failures don't kill the run. Any document that fails after a retry gets logged to a separate file instead of aborting — one bad document won't block migrating the other few million.

Basic usage:

python3 migrate-opensearch-classic-to-nextgen.py \
  --source-collection-id <classic-collection-id> \
  --target-collection-id <existing-nextgen-collection-id> \
  --region us-east-1

Add --dry-run first to see index and document counts without copying anything.

After the migration

Once you've cut your application over to the NextGen endpoint and confirmed traffic is flowing correctly, delete the old Classic collection to stop paying for it:

aws opensearchserverless delete-collection --id <classic-collection-id>

To help you clean it up, use the Jungle Cleaner MCP cleanup tool, which will identify the exact commands you (or your agent) needs — it verifies the old Classic collection has had no read or write activity since your cutover before suggesting removal, so you're not deleting anything that's still quietly in use somewhere.

FAQ

What's new in OpenSearch Serverless NextGen? NextGen can scale indexing and search capacity down to zero, and scales roughly 20x faster than Classic in both directions. Classic had a fixed minimum of 2 OCUs each for indexing and search, regardless of usage.

Can I upgrade a Classic collection to NextGen in place? No. Collection generation is immutable — you must create a new NextGen collection and migrate data into it.

Will I lose data during migration? Not if you follow the standard cutover order: create the new collection, run the migration script, verify data and application behavior against the new endpoint, and only then delete the old collection.

What happens if search scales to zero in production? The first query after a cold start can take tens of seconds to respond. Keep at least 1 unit of search capacity provisioned in production to avoid this; indexing capacity is generally safer to let scale to zero.

Does the migration script support incremental re-runs? Yes — it's idempotent by document ID, so re-running it after cutting over your application catches any writes that happened during the migration window.

How do I install Jungle Cleaner? Go to junglecleaner.com and follow the instructions there to install the MCP tool.

One savings plan, sixteen services, no upfront payment, happy days! That sounds amazing, but unfortunately, you're gonna be hard pushed to cut 35% — or even 20% — off your database spending, thanks to some sneaky little caveats that Amazon doesn't make immediately obvious.

The marketed deal: sixteen services, one simple savings plan

Open the Database Savings Plans pricing page and you'll find usage broken across the services covered by the plan:

• Aurora and RDS Instances
• Aurora Serverless v2
• Aurora DSQL
• DynamoDB
• ElastiCache for Valkey Instances
• ElastiCache for Valkey Serverless
• Amazon DocumentDB Instances / Serverless
• Neptune Instances / Serverless / Analytics
• Keyspaces
• Timestream
• DMS Instances / Serverless
• Amazon OpenSearch Service

Amazon sells it as a commitment to spending a certain dollar amount per hour for the whole year for all these services. It doesn't matter if you spin up new databases, spin down old ones, move stuff between services, or switch regions — the saving remains. Unfortunately, the devil's in the detail, because not everything is covered by the plan, which means it could be that most of your usage is actually excluded!

The catch: only newer and more expensive instance families

The pain in the bum that AWS doesn't advertise is that it only supports Gen 7 and newer instance families. Scan the full RDS/Aurora list and you won't find a single row for:

• db.t4g — AWS's own recommended burstable family for dev/test and small production workloads, and Graviton2-based, not some ancient relic
• db.t3 / db.t3g
• db.m5 / db.r5
• db.m6 / db.r6 (non-Graviton or earlier Graviton generations)

There's also a floor on size, not just generation — no savings for us peasants on the smaller instance types. Scan the eligible Gen 7+ families and the smallest size you'll find is .large; there's no .medium, .small, or .micro variant anywhere in the m7g/r7g/m8g/r8g/m9g lineup. If you're running anything that's excluded from the plan it will never apply to that instance.

And this isn't just related to RDS — AWS's own Savings Plans FAQ states plainly that Database Savings Plans only offer coverage for Generation 7 and newer instances. So the same exclusions apply to DocumentDB, Neptune, OpenSearch, and DMS too. Any usage on those services that's still pre-Gen-7 gets zero benefit from a Database Savings Plan commitment, just like RDS.

ElastiCache adds an extra restriction on top: coverage is Valkey-only, so even a Gen 7+ Redis OSS or Memcached node doesn't qualify — you need both the newer generation and the Valkey engine. Timestream has its own narrow scope too, limited to InfluxDB instances specifically.

That last point about T-class is kind of a big deal. T-class instances are how a huge number of teams run dev, staging, QA, and small production databases — precisely the "not core revenue, but still on the AWS bill every month" workloads that make ideal Savings Plan candidates. Under Database Savings Plans, none of that spend is eligible, no matter how large a commitment you buy — and the same logic extends to any pre-Gen-7 instance sitting inside DocumentDB, Neptune, OpenSearch, or DMS.

Serverless Savings Baby

The two services that dodge this entirely are DynamoDB and Keyspaces — they're throughput/capacity-based rather than instance-based, so there's no "generation" to be excluded from. And every serverless offering gets the same free pass: Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, DMS Serverless, and OpenSearch Serverless are all covered from the first hour you spin them up, with no instance-generation check to clear. If your workload lives on any of these, the generational cliff simply doesn't apply to you.

Compute Only!

There's another caveat here that's just as easy to miss as the generation cliff: Database Savings Plans only ever discount compute usage. Storage and backup costs sit outside the plan entirely, no matter how eligible the instance sitting next to them is.

That is a big deal because storage and backup can be a big slice of the total — provisioned IOPS on RDS/Aurora, snapshot storage, continuous backups, and for DynamoDB specifically, on-demand storage and backup charges. None of that gets touched by your commitment, even if the compute portion is fully Gen 7+ and otherwise perfectly eligible.

When it comes to DynamoDB, it's easy to assume "DynamoDB is covered" means the whole bill is covered. It isn't — only the request/throughput (compute) side gets discounted. Storage and backup keep billing at full price no matter how large a commitment you buy.

Things to think about before you commit

Database Savings Plans are a fixed 1-year commitment. There's no early exit and no ability to reduce it if your workload composition doesn't match what you assumed. That makes the coverage gap a real financial risk, not a footnote:

• If your stack is mostly Gen 7+ already, this is close to a no-brainer — flat 20%+ savings with total flexibility to change instance type, engine, or region without losing the discount.
• If you're spending a lot on t4g, t3, m5, or r5, that portion gets zero benefit from a Database Savings Plan commitment. You'd either need to upgrade those instances to a Gen 7+ family first (itself a cost change, before any discount applies) or accept that your commitment will be sized against a smaller pool of eligible usage than your total database bill suggests.
• There's no t-class equivalent in the Gen 7+ range — AWS hasn't shipped a burstable t7g/t8g/t9g family, so "just upgrade the generation" isn't a drop-in option here the way it is for Aurora r7g → r8g. Moving off T-class means moving to a non-burstable family entirely, which is a different cost and performance profile, not a like-for-like swap.
• If a decent portion of your bill is already spent on the eligible serverless services, the sizing exercise is much simpler, but baseline only the compute portion of that spend. Strip out storage and backup charges first (DynamoDB storage/backup, snapshot storage, and the like), then find the level your remaining serverless compute usage never drops below, month over month, and commit against that floor.

The practical takeaway

Before sizing a Database Savings Plan commitment, don't just total your eligible-sounding database spend from Cost Explorer — cross-reference it against the actual instance types you're running. A commitment built against your full database bill, without checking generational eligibility first, will systematically overestimate your effective coverage. The gap between "total database spend" and "Database Savings Plan-eligible database spend" is exactly the kind of thing that's invisible until the first invoice lands with a lower discount than expected.

Curious whether your own AWS account has hidden non-eligible instances sitting inside what looks like Database Savings Plan-covered spend? Jungle Cleaner checks for exactly this kind of coverage gap automatically.