AWS Cost Optimization Checklist for Startups: Where to Look First

Start in the cost analysis tool and work from broad to narrow. Don't open individual resources until you know which services matter.

1. Group last month's cost by service and write down the top five. Everything below them is noise for now.
2. Re-group each of those five by usage type. This is where surprises show up: data transfer, NAT gateway processing, or log ingestion hiding inside a "compute" line.
3. Group by account or environment tag. If staging costs about as much as production, you've found your first target.
4. Compare this month to three months ago. A line that grew faster than your traffic is either waste or a design problem.

If half your spend has no owner tag, stop and fix that first. You can't cut what nobody claims. The rule is simple: every resource gets an owner and an environment tag, enforced when it's created.

These are the items that cost money while doing nothing. Each one is safe to remove once you've confirmed nobody uses it:

• Unattached block storage volumes and old snapshots left behind by terminated instances.
• Load balancers with no healthy targets, and elastic IP addresses that aren't attached to anything.
• Development and staging environments that run around the clock. Schedule them off nights and weekends.
• Log groups with no retention setting, which keep every line forever.
• NAT gateways in environments that don't need outbound internet, and one per availability zone in dev where one would do.
• Test databases that were sized like production and never shrunk.

Before deleting, snapshot anything you're unsure about and tag it "scheduled for deletion" with a date. Deleting after a two-week quiet period beats guessing.

Right-sizing means matching instance and database sizes to measured usage. The risk is shrinking something that spikes.

Pull two weeks of CPU and memory data at the peak percentile, not the average. Say a service averages 12% CPU but touches 70% during a nightly batch. It is not oversized; it has a bursty load. Now say a different service never crosses 25%: dropping one size is a reasonable test there.

Change one thing at a time, in the quietest window, and keep the old size as your rollback. Databases deserve more caution than stateless services because a resize can mean a restart. Memory-bound workloads are the most commonly oversized, because teams pick instance families for CPU and never revisit the choice.

Savings Plans and reserved capacity trade flexibility for a lower rate. They pay off only for usage you're certain to keep.

A workable rule: commit only to your floor, the amount you'd still run in your quietest month, and only after right-sizing. Leave the peaks on regular rates. If your architecture is about to change, for example a move from virtual machines to containers, pick the more flexible plan type or wait a quarter.

Startup credits are a separate lever. They hide waste while they last, so track your bill at list price and be ready for the day credits end. The startup credits comparison covers how the programs differ.

A one-time cleanup decays within a quarter unless something watches it. Three habits are enough for a small team:

• A budget alert at a forecasted-overrun threshold, sent to a channel someone reads.
• A monthly 30-minute review of the top five services and anything that moved.
• A rule that new services ship with a tag, a log retention setting and a named owner.

For context, the median private B2B SaaS company's hosting spending is about 5% of ARR¹. If you're far above that, look at architecture and data transfer before hunting small line items. Observability tooling can become its own cost center, so review your monitoring bill alongside compute.