Stable adds 6 recommendations to help teams clean up AWS costs with less guesswork

 |  Eric Pinet

Stable has added six new AWS cost optimization recommendations to help teams find specific savings opportunities across Aurora, DynamoDB, OpenSearch, and EBS.

In most AWS environments, costs do not necessarily ramp up instantly. They usually build up through normal decisions that made sense at the time. A database starts on Aurora Serverless because traffic is unpredictable. A DynamoDB index gets created to support a feature. An OpenSearch workload runs On-Demand until usage patterns are clearer. An EBS volume stays attached because no one is quite sure whether it is still needed.

Over time, those decisions can stop matching reality.

The new Stable recommendations help teams catch those gaps. They flag resources that may be running on the wrong pricing model, sitting underused, or ready for a more cost-effective configuration.

1. Move predictable Aurora Serverless workloads to provisioned instances

Aurora Serverless is ideal for workloads with unpredictable demand or short periods of very high traffic.. It gives teams flexibility because capacity can scale up or down based on workload needs.

But once usage becomes stable, that flexibility can become more expensive than necessary.

If an Aurora Serverless database has been running long enough to show a clear usage pattern, and its ACU range is consistently predictable, a provisioned Aurora instance may be more cost-effective. The savings can be even stronger when the instance is covered by a one-year Reserved Instance.

This recommendation makes sense when:

  • The workload has at least 31 days of usage history.
  • ACU consumption stays within a predictable range.
  • The projected annual savings are significant.
  • The application does not require rapid, unpredictable scaling.

Moving from Aurora Serverless to provisioned Aurora requires creating a new cluster, restoring from a snapshot, validating the new environment, updating endpoints, and decommissioning the old cluster only after testing is complete.

The question is simple: are you still paying for flexibility because you need it, or because no one revisited the original setup?

2. Upgrade Aurora storage from Standard to IO-Optimized

Aurora Standard storage can be cost-effective for workloads with moderate I/O activity. But when I/O charges become a major part of the bill, Aurora IO-Optimized may be the better option.

With Aurora Standard, you pay for storage and I/O requests. With Aurora IO-Optimized, storage costs more per GB, but I/O charges are removed. For high-I/O workloads, that tradeoff can reduce total cost.

Stable flags this opportunity when I/O charges represent a significant share of total Aurora storage and I/O spend.

This recommendation makes sense when:

  • The Aurora cluster has high I/O activity.
  • I/O charges represent roughly 25% or more of combined storage and I/O costs.
  • The workload is expected to keep generating high I/O volume.
  • The projected savings justify the switch.

The change can be applied online, without downtime or an instance restart. Still, it needs to be reviewed carefully. Once a cluster is moved to IO-Optimized, it cannot be switched back to Standard for at least 30 days.

This is a good example of why AWS cost optimization cannot rely on unit pricing alone. The cheaper-looking option is not always cheaper once real usage is factored in.

3. Delete unused DynamoDB indexes

Global Secondary Indexes are useful when applications need alternate query patterns. They can also become expensive leftovers when those query patterns are no longer used.

Stable identifies DynamoDB tables or indexes with no read activity over the last 30 days. For an unused GSI, the potential savings can include index storage and write capacity costs.

This recommendation makes sense when:

  • A DynamoDB GSI has no read activity.
  • The index is still generating storage or capacity costs.
  • No application, job, report, or admin process depends on it.
  • The development team confirms it is safe to remove.

This is one of those recommendations that looks simple but needs serious validation.

Deleting a GSI is permanent. If the application still relies on it, queries can break. Recreating the index later requires a full reindex of the table, which can take time and consume write capacity.

So yes, unused indexes should be challenged. But they should not be deleted just because a dashboard says they look idle.

The right process is to confirm ownership, check application dependencies, review query patterns, and document approval before removing anything.

4. Move low-access DynamoDB tables to Standard-Infrequent Access

Some DynamoDB tables are rarely accessed.

They may store historical records, audit data, customer history, operational logs, or other data that needs to remain available without being queried constantly. In those cases, the Standard table class may not be the most cost-effective option.

DynamoDB Standard-Infrequent Access offers lower storage costs, with slightly higher read and write request costs. It can be a strong fit when storage represents most of the table’s cost and access is low.

This recommendation makes sense when:

  • A DynamoDB table has high storage costs.
  • Read and write activity is low.
  • The table is not part of a Global Table setup.
  • Storage costs dominate throughput costs.
  • The projected savings are meaningful.

The key is the access pattern. Standard-IA is not automatically better because it has lower storage pricing. If a table is queried frequently, the higher request costs can reduce or eliminate the savings.

There is also a commitment strategy to consider. Standard-IA tables cannot benefit from DynamoDB Reserved Capacity. For provisioned-capacity tables that could qualify for Reserved Capacity, both options need to be compared before making a change.

5. Purchase Reserved Instances for steady OpenSearch workloads

OpenSearch can become expensive when steady-state workloads remain on On-Demand pricing.

For domains with predictable usage, Reserved Instances can reduce costs compared with On-Demand rates. Stable identifies OpenSearch nodes that are not currently covered by Reserved Instances and have maintained stable usage long enough to support a commitment decision.

This recommendation makes sense when:

  • OpenSearch nodes run consistently.
  • The instance type and region are unlikely to change soon.
  • The workload is expected to continue for the commitment term.
  • The projected savings justify a one-year or three-year commitment.

Reserved Instances can be a smart move to get discounts, but they are a commitment.

OpenSearch Reserved Instances are tied to a specific instance type and region. If the workload changes, the RI may no longer fit. Teams may need to sell the unused RI on the AWS Marketplace or keep paying for it until the term ends.

Before purchasing, review the roadmap. Will the domain be resized? Will the instance family change? Is there a migration planned? Is the workload stable enough to commit?

6. Delete idle EBS volumes

EBS volumes are easy to create and easy to forget.

A volume may have supported a test, migration, temporary workload, backup process, or older application path. If it remains attached to a running EC2 instance but shows little or no I/O activity, it may be adding cost without providing value.

Stable identifies EBS volumes attached to running EC2 instances with very low read and write activity over the last 30 days.

This recommendation makes sense when:

  • The volume has very low I/O activity.
  • The volume is not a root volume.
  • The data is no longer needed.
  • A snapshot has been created before deletion.
  • The owner confirms it is safe to remove.

This is one of the more direct savings opportunities, but it still needs a specific strategy.

Deleting an EBS volume is permanent unless a snapshot exists. Root volumes require extra caution because deleting or detaching them can affect the instance itself. Before removing anything, teams should check mount points, application dependencies, backup status, and ownership.

What these recommendations have in common

These six recommendations are different, but the logic behind them is the same.

Stable looks for mismatches between AWS resources and actual workload behaviour.

That can mean:

  • A flexible database that has become predictable.
  • A storage model that no longer fits the I/O profile.
  • An index that no longer supports active queries.
  • A table class that does not match the access pattern.
  • A workload that is stable enough for a commitment.
  • A volume that no longer appears to serve a useful purpose.

This is where AWS cost optimization becomes operational.

The best savings opportunities are not always the obvious ones. They often sit inside configuration choices that were reasonable when they were made, but have not been reviewed since.

Final thoughts

With these new recommendations, Stable gives teams more visibility into the AWS resources that can directly affect monthly spend, identifying potential new savings and making those opportunities easier to review, prioritize, and validate with the right technical context.

For teams managing growing AWS environments, that matters. Cost optimization becomes less reactive, less manual, and more connected to how workloads are actually running.

Start your free trial today!