AWS Cost Optimization for SaaS in 2026: A Practical Playbook

For most SaaS companies, the AWS bill is the second-largest cost after salaries, and it rarely grows in a straight line. A new feature ships, a staging environment is left running, a log group keeps everything forever, an LLM feature goes live, and suddenly finance is asking why cloud spend went up faster than revenue.

The good news is that AWS cost optimization in 2026 is far less of a dark art than it used to be. AWS now has Database Savings Plans alongside Compute Savings Plans, more idle-resource recommendations in Compute Optimizer and Cost Optimization Hub, Graviton5 instances, cheaper ways to run Amazon Bedrock workloads, and an AI-driven FinOps Agent (in preview) that can answer cost questions in plain English. But tools only help if you apply them in the right order.

This guide is the playbook we use when a SaaS team asks us to cut their AWS bill without slowing the product down: visibility first, cleanup second, architecture third, commitments last.

Why the order matters

The most common mistake we see is buying Savings Plans or Reserved Instances first. It feels like the fastest win, but if you commit to a $/hour level based on an oversized, messy fleet, you lock in waste for one or three years. Rightsizing after you commit means paying for a commitment you no longer use.

The safe sequence is:

1. Visibility – know which product, team, customer tier and environment each dollar belongs to.
2. Cleanup – delete what nobody uses and shrink what is oversized.
3. Architecture – fix the structural cost drivers (data transfer, NAT, logging, database shape, LLM usage).
4. Commitments – buy Savings Plans for the stable baseline that is left.

Step 1: Get real cost visibility

Tag everything that costs money

Without tags, Cost Explorer tells you "EC2 went up", not "the reporting service in production went up". Agree on a short, enforced set of tags and activate them as cost allocation tags in the Billing console:

• env – production, staging, dev, preview
• service – api, worker, web, search, ai
• team or owner – who answers when it spikes
• tenant-tier (optional) – useful if enterprise customers run on dedicated resources

Enforce tags in infrastructure as code rather than by hand. In Terraform, default_tags on the AWS provider applies them to every supported resource:

provider "aws" {
  region = "eu-west-2"

  default_tags {
    tags = {
      env     = var.env
      service = var.service
      owner   = "platform-team"
    }
  }
}

Back this up with an AWS Organizations tag policy or a CI check so untagged resources fail review.

Use multiple accounts as cost boundaries

Separate AWS accounts for production, staging and sandbox (managed through AWS Organizations or Control Tower) are the cleanest cost boundary there is. They also make it trivial to put a hard budget on sandbox accounts.

Turn on budgets and anomaly detection

AWS Budgets and Cost Anomaly Detection are cheap insurance. Set a monthly budget per account with alerts at 80% and 100% of forecast, and create an anomaly monitor per service so a runaway Lambda loop or a misconfigured crawler gets noticed in hours, not at month end. Send alerts to the Slack channel the engineering team actually reads.

If you are in the preview, the AWS FinOps Agent can also answer questions like "why did data transfer go up last week?" and pull recommendations from Cost Optimization Hub and Compute Optimizer. Treat its suggestions as a starting point and verify them before acting.

Step 2: Clean up waste

This is usually where the fastest savings come from, and it carries almost no product risk.

Idle and orphaned resources

• Unattached EBS volumes and old snapshots left behind after instances were terminated.
• Old-generation EBS volumes – gp2 volumes can usually move to gp3, which lets you set IOPS and throughput independently and is typically cheaper per GB.
• Idle load balancers and unused Elastic IPs (AWS charges for all public IPv4 addresses now, attached or not).
• Unused NAT Gateways in VPCs that were created for a test and never removed. Compute Optimizer now flags these.
• Forgotten preview and staging environments. Schedule non-production environments to stop outside working hours, or tear down preview environments automatically when a pull request is closed.

A quick CLI check for unattached volumes:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}' \
  --output table

Rightsize compute and databases

Open AWS Compute Optimizer and Cost Optimization Hub and work through the rightsizing recommendations for EC2, ECS on Fargate, Lambda and EBS. Pay attention to:

• Instances that sit below 20–30% CPU most of the day.
• Fargate tasks with memory reservations far above actual usage.
• Lambda functions with too much (or too little) memory – more memory also means more CPU, so sometimes increasing it makes a function cheaper because it finishes faster.
• RDS or Aurora instances sized for a launch-day traffic spike that never came back.

Rightsize in small steps, watch p95 latency and error rates for a few days, then move again.

Logs and storage lifecycle

CloudWatch Logs with "never expire" retention is one of the quietest cost leaks in AWS. Set retention on every log group and lower log levels in production:

for lg in $(aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].logGroupName' --output text); do
  aws logs put-retention-policy --log-group-name "$lg" --retention-in-days 30
done

For S3, use S3 Storage Lens to find the big buckets, then apply lifecycle rules: S3 Intelligent-Tiering for data with unknown access patterns, Glacier classes for backups and archives, and expiry rules for temporary uploads and incomplete multipart uploads.

Step 3: Fix the architecture-level cost drivers

Data transfer and NAT Gateway charges

NAT Gateways charge per hour and per GB processed. If your private-subnet services pull container images, talk to S3, or call DynamoDB through a NAT Gateway, you are paying processing charges on traffic that does not need to leave AWS's network. Add VPC gateway endpoints for S3 and DynamoDB (they have no hourly charge) and interface endpoints for heavy-use services such as ECR where the numbers justify it.

Also check cross-AZ traffic between chatty services, and put CloudFront in front of public assets and APIs where caching makes sense – it reduces origin load and data transfer out from your servers.

Move to Graviton – but benchmark first

AWS Graviton (ARM) instances generally offer better price-performance than comparable x86 instances, and most Laravel, Node.js, Python and Go stacks run on ARM with no code changes – you mainly need multi-architecture Docker images:

docker buildx build --platform linux/amd64,linux/arm64 \
  -t 123456789012.dkr.ecr.eu-west-2.amazonaws.com/api:1.42.0 --push .

The newest generation, Graviton5 (M9g and C9g), is faster than Graviton4, but faster is not automatically cheaper. In some regions the per-hour price is higher than the previous generation, so the move only pays off if the extra performance lets you run fewer or smaller instances. Load-test your real workload on both before switching a whole fleet. Graviton is also available for RDS, Aurora, ElastiCache and Lambda, often with an easier migration than EC2.

Pick the right compute model

Spiky, event-driven work often belongs on Lambda; steady APIs are often cheaper on Fargate or EC2; background workers that can tolerate interruption are ideal for Spot capacity (EC2 Spot or Fargate Spot). We compared these options in detail in AWS Lambda vs Fargate vs EC2 for web app hosting.

Right-shape the database

Databases are usually the biggest single line after compute. Common wins:

• Fix slow queries and missing indexes before scaling up the instance – a bigger box hides problems for a while, then costs you twice.
• Use read replicas or a cache (ElastiCache for Valkey or Redis) for read-heavy endpoints instead of a larger primary.
• Consider Aurora Serverless v2 for workloads with big idle periods, and provisioned instances for steady load. See our comparison of Aurora Serverless vs RDS PostgreSQL vs Aurora DSQL.
• Check Aurora storage I/O: for I/O-heavy workloads, Aurora I/O-Optimized can be cheaper than paying per request.

Control AI and LLM spend

For many SaaS products in 2026, Amazon Bedrock or third-party LLM APIs are the fastest-growing cost line. The main levers are choosing the smallest model that meets your quality bar, prompt caching for repeated system prompts and context, batch inference for non-interactive jobs (Bedrock batch is priced below on-demand), and tagging or attributing usage per feature so you know which feature drives the bill. We covered this in depth in how to reduce LLM API costs in a SaaS product.

Step 4: Commit with Savings Plans (last, not first)

Once the fleet is clean and right-sized, look at the steady baseline that runs 24/7 and cover it with commitments. AWS currently offers four Savings Plan types:

Practical rules:

• Do not cover 100% of usage. Commit to the floor of your usage over the last few months, not the average. Many teams target 60–80% coverage and leave the rest on-demand or Spot.
• Start with one-year, no-upfront plans unless you are very confident in your three-year architecture.
• Stagger purchases – buy in smaller tranches every quarter so commitments expire at different times and track growth.
• Use the Savings Plans Purchase Analyzer to model different commitment levels before you buy.

Make cost part of engineering, not a yearly clean-up

The teams that keep AWS bills under control treat cost like performance: it is measured, owned and reviewed. A lightweight routine works well:

• A monthly 30-minute cost review per team, using tagged Cost Explorer views.
• Infracost or a similar tool in CI so pull requests show the cost impact of infrastructure changes.
• A "unit cost" metric such as cost per active customer or cost per 1,000 API requests, so you can tell healthy growth from waste.
• Clear owners for anomaly alerts.

Quick AWS cost optimization checklist

• Cost allocation tags enforced and activated
• Separate accounts for production and non-production
• Budgets and Cost Anomaly Detection alerts configured
• Unattached EBS volumes, old snapshots, idle load balancers and unused IPs removed
• gp2 volumes migrated to gp3
• Non-production environments scheduled or auto-destroyed
• CloudWatch log retention set on every log group
• S3 lifecycle rules and Intelligent-Tiering where it fits
• VPC endpoints for S3/DynamoDB to cut NAT processing
• Graviton benchmarked and adopted where it wins
• Database queries and instance sizes reviewed
• LLM usage attributed per feature, with caching and batching
• Savings Plans covering the stable baseline only

Summary

Cutting an AWS bill safely is a sequence, not a single trick. Get visibility with tags, accounts and anomaly alerts; clean up idle and oversized resources; fix structural drivers like NAT traffic, logging, database shape and LLM usage; and only then commit to Savings Plans for the baseline that remains. Done in that order, you reduce spend without risking performance – and you avoid locking waste into a multi-year commitment.

Frequently asked questions

How much can a SaaS company save with AWS cost optimization?

It depends entirely on how the account has been run. Accounts that have never been reviewed often have significant idle resources and oversized instances, while well-managed accounts may only have small gains left. The only honest answer comes from a review of your own Cost Explorer data and Compute Optimizer recommendations.

Should I buy Savings Plans or Reserved Instances in 2026?

For compute, Savings Plans have largely replaced Reserved Instances because they are more flexible. Compute Savings Plans cover EC2, Fargate and Lambda across regions and instance families. Reserved Instances still matter for some services such as ElastiCache, OpenSearch and Redshift. Either way, rightsize first.

Is migrating to AWS Graviton worth it?

Usually yes for modern Laravel, Node.js, Python and Java workloads, because the code rarely needs changes and Graviton generally offers better price-performance. Benchmark first, especially for the newest Graviton5 instances, whose hourly price can be higher than the previous generation.

What is the quickest AWS cost win?

Deleting idle resources and setting CloudWatch log retention. Both are low-risk, can be done in a day, and do not require any change to application code.

Does the AWS FinOps Agent replace a cost review?

No. It is useful for answering questions and surfacing recommendations faster, but someone still needs to understand the architecture, judge the trade-offs and own the changes.

Can an outside team optimize our AWS account safely?

Yes, if access is set up properly: read-only billing and Cost Explorer access for the review, and changes delivered through your infrastructure-as-code repository with your team approving each pull request.

Want a second pair of eyes on your AWS bill?

DayDecoder helps SaaS companies in the US, UK, Europe and Australia reduce cloud spend without slowing down their product – from tagging and cleanup to Graviton migrations, database tuning and LLM cost control. Learn more about our cloud cost optimization service and cloud and DevOps services, or hire dedicated AWS developers.

Contact DayDecoder for a free AWS cost review and quote →