Most startup AWS bills do not explode in a single day. They grow through small decisions: a test environment left running, a database sized for a launch that never came, logs kept forever. By the time someone opens Cost Explorer, the bill is forty percent higher than last month while traffic is up only ten percent. The fix is not a FinOps team or an expensive platform. It is knowing where the money usually leaks and pulling the right levers in the right order.

Clean Before You Commit

The most expensive mistake in cost work is pulling levers in the wrong order. Never buy a Savings Plan or Reserved Instance before cleaning up, because you will commit to capacity you do not need. Start with idle resources: delete unattached EBS volumes and old snapshots, release unused Elastic IPs, which AWS has billed for since 2024 at roughly $3.60 a month each, and remove idle load balancers. Then right-size using real data: open the free AWS Compute Optimizer, look at fourteen to thirty days of CloudWatch metrics, and drop a size wherever p95 CPU stays under forty percent with memory headroom. Switch EBS volumes from gp2 to gp3, which costs about twenty percent less per GB and can be modified while in use. These steps alone commonly cut twenty to forty percent off an overprovisioned bill, and they cost nothing.

The Two Silent Costs: NAT and Data Transfer

Two charges hide inside a line called EC2-Other and confuse almost every startup. The first is the NAT gateway: around $33 a month per gateway plus $0.045 per GB processed, so three gateways across three availability zones cost about $100 a month before any traffic flows. Add free VPC gateway endpoints for S3 and DynamoDB so that traffic stops flowing through the NAT. The second is data transfer, especially egress. Use CloudFront to cache content and cut bandwidth costs, keep traffic inside one region where possible, and watch inter-region transfers, which are easy to create by accident. Fix these two before anything else, because they grow silently with traffic.

Commit, Then Optimise the Variable Layer

The One-Hour Monthly Routine

Cost optimisation fails when it is a one-off project, so turn it into a monthly routine that takes one hour. In the first fifteen minutes, open Cost Explorer, group spend by service and by tag, and note the three largest changes since last month. In the next fifteen, check Compute Optimizer for new right-sizing recommendations and delete anything that has been idle for thirty days. In the next fifteen, review your Savings Plan coverage and your Spot usage, and confirm your Budgets alerts are still set at 50, 80 and 100 percent. In the final fifteen, write down what changed and what you will do next month, and share the note with the team so everyone sees the bill. A routine like this catches a runaway cost in its first month instead of its sixth, and it keeps the bill close to the true cost of running the product rather than drifting upward unnoticed.

Once the bill reflects your true baseline, commit to it. Compute Savings Plans save up to about 66 percent off on-demand prices and apply across EC2, Fargate and Lambda, while EC2 Instance Savings Plans reach up to 72 percent for a fixed instance family. Prefer Compute Savings Plans while your architecture is still changing, because flexibility matters more than the last few percent of discount. Move interruptible work such as CI builds, batch jobs and video rendering to Spot instances, which sell spare capacity at up to 90 percent off. Add S3 lifecycle rules to move old data to Intelligent-Tiering or Glacier, schedule non-production environments to run only during working hours, and set AWS Budgets alerts at 50, 80 and 100 percent of your expected spend. Finally, name one person as bill owner and review Cost Explorer weekly. Cloud costs do not stay optimised by themselves, but a one-hour monthly routine keeps them from ever exploding again.