AWS Bill Too High: 7 Checks Before You Call a Consultant

Your AWS invoice landed and it's £4,200 — up from £1,800 three months ago. Nobody changed anything obvious. The product has the same number of users. Your CTO (or your agency) says it's 'normal growth.'

It usually isn't. In FinOps reviews for UK startups and scale-ups, we consistently find 20–40% avoidable spend: resources left running after a demo, databases sized for a launch that never came, logging that costs more than compute, NAT gateways nobody remembers deploying.

Before you sign a FinOps contract — or worse, ignore the problem until your next fundraise — run these seven checks. They take an afternoon with read-only console access. Document what you find. Many teams cut 15–25% of their bill without touching application code.

Before you start: get a baseline

Open AWS Cost Explorer and set the date range to the last three months. Note your total monthly spend and the top five services by cost. Screenshot it — you want a before-and-after when you make changes.

If you do not have a dedicated AWS account per environment, assume production, staging, and forgotten experiments are mixed together. That makes attribution harder but does not stop you finding waste.

Work through the checks in order. Checks 1–3 find the fastest wins. Checks 4–6 catch structural problems. Check 7 prevents you locking in waste at a discount.

Check 1: Inventory everything that is running

Founders are routinely shocked by what is still switched on. A staging environment from a Y Combinator demo six months ago. A proof-of-concept EC2 instance someone spun up to test a PDF export. A second RDS instance 'just in case.'

In the AWS console, work through this list and export or screenshot each:

• **EC2 → Instances** — note instance type, state, and launch date for anything running
• **RDS → Databases** — include dev/staging databases; these often run 24/7 on production-sized instances
• **EC2 → Elastic IPs** — any address not associated with a running instance
• **EC2 → Volumes** — filter by *available* (unattached) state
• **EC2 → Snapshots** — sort by age; anything older than your backup policy
• **Load Balancers (ELB)** — ALBs cost ~£16/month minimum even with zero traffic
• **NAT Gateways (VPC)** — often the surprise line item on vibe-coded Terraform stacks
• **Lambda** — check for functions with high invocation counts you do not recognise

For each resource, ask: does this serve a user today? If the answer is no, tag it `candidate-delete` and note the monthly cost from Cost Explorer.

Cross-reference with CloudWatch over 30 days. Zero network in/out on an EC2 instance that is 'running' is a strong delete signal — after confirming with the team.

Check 2: Hunt for orphaned storage

Unattached EBS volumes and stale snapshots are silent budget killers. They bill every month and deliver nothing.

In EC2 → Volumes, filter state = *available*. Each volume is typically £8–£80/month depending on size and type (gp3 vs io2). We have seen accounts with £400+/month in volumes nobody knew existed — leftovers from terminated instances.

For snapshots: sort by Start Time. Apply your retention policy aggressively. If you back up daily but only need 14 days of recovery, snapshots older than that are waste unless compliance requires otherwise.

S3 is a separate pass. In S3 → Storage Lens (or bucket-by-bucket metrics), look for buckets with growing storage but no lifecycle policy. Log archives, user uploads, and failed CI artifact buckets often grow unbounded.

Quick win: Enable S3 Intelligent-Tiering or lifecycle rules to move objects older than 90 days to Infrequent Access. On a 500GB bucket, that can save £30–50/month with zero code changes.

Check 3: Right-size compute and databases

Oversized instances are the most common mistake on AI-assisted or agency-built infrastructure. The default is 'pick something that won't fail' — which means a `t3.large` or `db.r6g.large` when a `t3.small` would suffice.

For EC2: open CloudWatch → Metrics → EC2 → Per-Instance Metrics. Pull CPUUtilization and NetworkIn/Out for two weeks. If peak CPU is under 20% and memory (via CloudWatch agent or instance type headroom) is similarly low, you are over-provisioned.

For RDS: same exercise with CPUUtilization, DatabaseConnections, and FreeableMemory. A database running at 5% CPU on a `db.r6g.xlarge` is a downgrade candidate.

Run AWS Compute Optimizer (free, in the console under *Management & Governance*). It gives specific instance-type recommendations with estimated savings. Downgrading one oversized RDS instance often saves more than hours spent shopping for reserved instances.

Caution: right-size during a low-traffic window and watch for 48 hours after. Memory pressure is harder to see without detailed metrics — if unsure, downsize one step at a time.

Check 4: Elastic IPs and NAT gateways

These two line items confuse non-infrastructure founders — and they add up fast.

Elastic IPs: An EIP allocated to your account but not attached to a running instance costs ~£3/month. Small individually, but teams accumulate them. Release any you do not need.

NAT Gateways: Each NAT gateway costs roughly £30–40/month in hourly charges, plus £0.045/GB processed. Vibe-coded stacks often deploy one NAT per availability zone for 'high availability' when the startup has 200 users and no SLA.

Draw a simple network diagram: which subnets need outbound internet? Can staging share a single NAT? Can you use VPC endpoints for S3 and DynamoDB to avoid routing that traffic through NAT entirely?

For early-stage startups, a single-AZ deployment with one NAT — or a NAT instance on a tiny EC2 box for non-production — is often the right tradeoff until you have real HA requirements. Do not pay for three NAT gateways because a template defaulted to multi-AZ.

Check 5: Data transfer and egress

Egress is where architectural decisions show up on the invoice. Cross-region replication, serving S3 assets without CloudFront, chatty microservices, and database queries that pull large result sets across AZs all generate transfer charges that do not appear in obvious 'compute' line items.

In Cost Explorer, filter by service = EC2-Other and Data Transfer. Look for month-on-month spikes. Ask: did we launch in a new region? Add a mobile app that pulls full-resolution images? Turn on cross-region RDS read replicas?

Common fixes:

• Put CloudFront in front of S3 for static assets — egress to CloudFront is cheaper than direct S3 public access at scale
• Keep inter-service traffic within the same AZ where possible for non-HA workloads
• Compress API responses — JSON payloads with redundant nesting add up over millions of requests
• Review cross-region backups and replication — are you paying to replicate data you never read?

If data transfer is your second-largest line item after RDS, the fix is usually architectural, not a smaller instance type.

Check 6: Logging and monitoring spend

CloudWatch Logs charges per GB ingested and per GB stored. At $0.50/GB ingested, an API logging every request body at DEBUG level on 50k daily requests can exceed your compute bill.

Audit your log groups: CloudWatch → Log groups. Sort by Stored bytes and Incoming bytes. For each high-volume group, ask:

• Is this production or staging? Staging should not log at the same verbosity as production
• Are we logging full request/response bodies when status codes would suffice?
• What is the retention period? 14–30 days is enough for most startups; 365 days on verbose logs is expensive
• Can we sample — log 1% of successful requests and 100% of errors?

Third-party tools (Datadog, New Relic) have their own cost curves. If your observability stack is a top-five line item, review whether you are on startup pricing, whether every service needs full APM, and whether metrics cardinality (high-cardinality tags) is inflating bills.

Check 7: Reserved capacity — only after right-sizing

Reserved Instances and Savings Plans give 30–60% discounts on predictable baseline load. They are also how teams lock in waste at a lower price.

Do not buy reserved capacity until checks 1–3 are complete. If you reserve a `db.r6g.xlarge` that should be a `db.t4g.medium`, you are committing to 12 months of overspend.

Good candidates for reservations: production app servers and primary databases with stable load for 6+ months, running 24/7. Bad candidates: staging environments, batch jobs, anything you might right-size next quarter.

Start with one-year, no upfront Savings Plans for compute if your instance mix is varied. They offer flexibility across instance families within the same region.

Track what you find

Use a simple spreadsheet with columns: Resource ID, Service, Monthly cost, Action (delete / downsize / investigate), Owner, Date completed. Assign an owner for each row — orphaned resources stay orphaned when 'everyone' is responsible.

Most teams complete checks 1–2 in under two hours and find £200–£800/month in obvious waste on a £3k–£8k monthly bill. Checks 3–6 take longer but address the structural issues that make bills climb every quarter.

When DIY is not enough

These checks catch low-hanging fruit. They do not replace an architectural review: shared NAT design, multi-account strategy, FinOps tagging, container rightsizing, or a codebase that provisions oversized resources on every deploy.

Call a FinOps consultant when:

• Your bill is above **£5k/month** and still growing faster than revenue
• Nobody on the team can explain the top three line items in Cost Explorer
• You are preparing for **fundraising or technical due diligence** and need defensible cloud economics
• You completed checks 1–3 and savings were under 10% — the waste is structural, not obvious
• You run in **multiple regions or accounts** and cost attribution is impossible

A good FinOps review uses read-only billing access, produces a waste inventory with estimated savings ranked by effort, and gives you a fixed quote before any implementation work. You should not need to hand over admin keys to production.