Reducing AWS EC2 and RDS Costs for Early-Stage SaaS

Cost Explorer grouped by service is the view everyone opens, and it is nearly useless for deciding what to do. “EC2-Other: $780” is not an action. Group by usage type instead, and the same money resolves into NAT gateway hours, EBS volume GB-months, snapshot storage and data processing charges — four completely different fixes.

Then do the thing most teams skip: turn on tagging and give it two weeks. Without tags you cannot say whether that RDS instance belongs to production, to a demo environment, or to a migration that finished last year. With them, the argument about what to delete takes ten minutes instead of a fortnight.

Finally, enable the Cost and Usage Report or at least Cost Anomaly Detection. You want the alert that says “something changed on the 14th”, because the most expensive mistakes are the ones that only become visible in a monthly total.

• Group by usage type, not service: NatGateway-Hours, NatGateway-Bytes, EBS:VolumeUsage.gp2 and DataTransfer-Regional-Bytes each have a different fix. Service-level totals hide all four inside EC2.
• Tag environment, owner and service: Three tags are enough. Enforce them with a tag policy so new resources cannot be created untagged, then treat untagged spend as a deletion candidate.
• Compare month over month, not against a budget: The interesting question at this stage is what changed and when, which points at a deploy or a new feature far faster than any absolute number.

The single most common finding is a production instance averaging six to twelve percent CPU, chosen eighteen months ago on a guess about launch traffic. It has never been revisited because nothing is broken, and nothing is broken because it is four times too large.

Use Compute Optimizer rather than intuition: it reads fourteen days of CloudWatch metrics and recommends a size, flagging where memory data is missing. Where it hesitates, pull p95 CPU and network yourself — but do look at p95 rather than the average, because the average of a bursty workload will talk you into an instance that falls over at lunchtime.

Two structural moves usually beat pure rightsizing. Graviton instances (the g-suffix families) price roughly ten to twenty percent below the equivalent x86 size, and for a typical Node, Python, Java or Go service the port is a base-image change and a rebuild. And gp3 volumes cost about twenty percent less per GB than gp2 while letting you buy IOPS separately, so you stop over-provisioning a terabyte of disk to get throughput.

Rightsize before you commit to anything. A three-year Reserved Instance on a box that is four times too big is a three-year subscription to your own mistake.

RDS is usually the second line on the bill and the one teams are most nervous about touching, so it gets left alone the longest. Four things account for most of the waste, and none of them involves risking production data.

Multi-AZ on non-production doubles the instance cost to protect a database whose loss would cost you an afternoon. Storage that was autoscaled up during a one-off import never comes back down — RDS cannot shrink storage, so the only path back is a dump and restore into a right-sized instance, which is worth doing once when the gap is large. Snapshots accumulate for years because nobody owns the retention policy. And the instance class itself is frequently the pre-launch guess again, with a db.r-family memory-optimised box serving a working set that fits comfortably in a db.t4g.

On Aurora, check whether you are on the right billing mode. Standard Aurora bills per I/O request, which for write-heavy workloads can quietly exceed the instance cost; Aurora I/O-Optimized removes the per-request charge for a higher instance price. Whichever direction the arithmetic points, it is a console setting rather than a migration.

• Turn off Multi-AZ on staging and demo: Halves the instance cost immediately. Keep it on production, always — that is what it is for.
• Set a snapshot retention policy and then enforce it: Snapshot storage bills per GB-month indefinitely. Thirty days of automated backups plus a documented list of keepers is usually the whole policy.
• Check the storage type: On RDS, gp3 lets you provision IOPS independently of capacity. Teams on gp2 routinely carry hundreds of unnecessary gigabytes purely to reach an IOPS number.
• Read replicas you are not reading from: A replica costs a full instance. If nothing routes to it and it is not part of your failover plan, it is a spare you are renting monthly.

This is where the strangest money hides, because none of it corresponds to a decision anyone remembers making. A single NAT gateway is roughly thirty-two dollars a month before it moves a byte, and then charges per gigabyte processed — so a chatty service pulling container images or writing to S3 through NAT can turn a routing detail into a four-figure annual line. A VPC endpoint for S3 removes that traffic from NAT entirely and is free.

Unattached EBS volumes keep billing after the instance they served was terminated. Since early 2024 every public IPv4 address carries an hourly charge, which turns a handful of forgotten Elastic IPs into real money. CloudWatch log ingestion is billed per gigabyte, so a debug logger left on in production is a bill with no product attached. And cross-AZ traffic is charged in both directions, which is why a chatty service and its database in different availability zones can cost more in transfer than in compute.

Each of these is a deletion rather than a redesign. That is what makes this the highest-return hour in the whole exercise.

There are 168 hours in a week. A staging environment is genuinely used for perhaps fifty of them, and billed for all 168. Scheduling non-production to run only during working hours removes roughly seventy percent of its cost, and it is a tag plus a scheduler rather than an architectural change.

EC2 instances stop and start cleanly. RDS instances can be stopped too, with one wrinkle worth knowing: AWS restarts a stopped RDS instance automatically after seven days, so the scheduler has to stop it again rather than assuming it stays down.

The cultural half matters as much as the technical half. Someone has to own the rule that demo environments have an expiry date, or you will be back here in a year with three of them.

• Tag, then schedule: A schedule tag read by EventBridge plus a small Lambda, or the AWS Instance Scheduler solution. Either is an afternoon of work with a permanent return.
• Remember RDS restarts itself after seven days: Stopped RDS instances come back on their own. The scheduler must handle that, and you still pay for storage while stopped.
• Give ephemeral environments an expiry: Per-branch preview environments are worth the money only if they disappear when the branch merges. Wire teardown into CI, not into someone's memory.

Savings Plans and Reserved Instances are the last step, not the first, because they are a discount on a shape. Fix the shape first, then buy against the part of it you are confident will still be there in twelve months.

For early-stage companies the honest recommendation is almost always a one-year, no-upfront Compute Savings Plan covering your stable floor — the baseline you never drop below — with on-demand absorbing everything above it. The discount is smaller than a three-year all-upfront commitment, but a three-year commitment assumes an architecture and a growth rate you cannot yet predict. RDS Reserved Instances work the same way and are worth buying for the production database once its class has settled.

Spot instances belong in this conversation too, but only for interruptible work: batch jobs, CI runners, queue consumers that can be restarted. They are a poor fit for a stateful web tier at this stage, and the engineering time to make them safe is rarely worth it before you have a platform team.

Cover your floor, not your peak. Coverage above your steady baseline is money spent on capacity you may not use, and it is far harder to unwind than to add.

Cost work decays. Without a ceiling and an owner, the bill reinflates over about two quarters as new services arrive and old ones are never retired. Three lightweight habits keep it flat.

Set AWS Budgets with alerts at both a monthly amount and a forecast threshold, so you hear about the overrun in week two rather than on the invoice. Turn on Cost Anomaly Detection, which is free and catches the step change a budget misses. And put one number in front of the team every month — infrastructure cost per active tenant is the one that best survives growth, because it goes down when things are working and up when they are not.

The table below is what a representative cleanup looks like end to end. The exact numbers will differ; the proportions rarely do, and the two largest cuts are both attention rather than engineering.