Reduce Your AWS Bill by 40%: The FinOps Playbook

Most AWS accounts can cut 30–60% of their bill. The approach we use to find the savings and keep them.

We've done cost optimization engagements across dozens of AWS accounts. The pattern is almost always the same: the bill is too high, nobody knows exactly why, and there's a vague sense that something should be done about it.

Here's the uncomfortable truth: most of the waste is structural. It's not one forgotten EC2 instance — it's architectural decisions that made sense at launch but haven't been revisited since.

Step 1: Get visibility before you start cutting

Before touching anything, spend a week in AWS Cost Explorer. Enable cost allocation tags and set up a proper billing dashboard. You need to know which services, teams, and environments are driving the bill.

The three questions you need answered: Where is money being spent? Is it being spent proportionally to usage? Are there resources running that nobody owns?

Step 2: Low-hanging fruit (week one)

• Identify and terminate unused EC2 instances and unattached EBS volumes — this alone often yields 5–15% savings

• Review S3 buckets for lifecycle policies — old object versions and incomplete multipart uploads add up fast

• Check RDS instance sizes against actual CPU and memory utilization — dev databases running on prod-sized instances are common

• Audit NAT Gateway usage — data transfer costs through NAT are frequently 2–3× what teams expect

• Review CloudWatch log retention — logs held forever in high-frequency groups can quietly cost thousands per month

Step 3: Compute rightsizing

AWS Compute Optimizer gives you rightsizing recommendations for EC2, Lambda, ECS, and RDS. Don't dismiss these — they're based on actual utilization data. The common objection is "we need headroom." That's almost never true at the instance sizes most teams are running.

For Lambda: review memory settings against actual usage. Lambda pricing is memory × duration, so overprovisioned functions are pure waste. Many Lambda functions are configured at 512MB or 1024MB when 256MB works fine — the 50% memory reduction directly becomes a 50% cost reduction on that function.

Step 4: Savings Plans and Reserved Instances

Compute Savings Plans give you 30–40% off EC2 and Fargate with just a 1-year commitment to a spend level (not specific instance types). This is almost always worth doing for production workloads with stable baseline usage.

Don't commit until you've done the rightsizing work — you don't want to lock in overprovisioned capacity. Once you know your actual baseline, a 1-year Compute Savings Plan is a safe, easy win.

Step 5: Architecture-level improvements

The biggest savings usually come from architecture changes. Common examples we see:

• Replacing always-on EC2 with Lambda + SQS for workloads that run in bursts

• Moving RDS instances to Aurora Serverless v2 for dev/staging environments with low traffic

• Replacing synchronous API calls with async SQS/SNS patterns to reduce Lambda concurrency costs

• Adding a CloudFront distribution in front of S3 to reduce data transfer costs

• Consolidating small, numerous Lambda functions that share the same purpose

Making it stick: the FinOps culture piece

Cost optimization is not a project — it's an ongoing practice. The engagements that stick are the ones where we also put in place: budget alerts with actionable thresholds, cost allocation tags enforced via SCPs, a monthly cost review cadence owned by engineering (not finance), and runbooks for common cost anomalies.