Is Your AWS Spend Out of Control? 5 Warning Signs

Why It Matters

A healthy cloud environment scales costs roughly in proportion to business growth. If your AWS bill is increasing 15-20% month over month while your revenue or user base is growing at 5%, something is fundamentally wrong. This disconnect is the single most reliable indicator that waste is accumulating somewhere in your infrastructure. Left unchecked, it erodes margins and can turn a profitable product into a cash-burning operation.

Real-World Examples

We recently worked with a SaaS company whose monthly AWS bill had grown from $28K to $47K in nine months while their customer count only increased by 12%. The culprit was a combination of over-provisioned RDS instances that had been scaled up during a traffic spike and never scaled back down, plus a data pipeline that was reprocessing historical data nightly instead of incrementally. Another common scenario: a company migrates to the cloud with a lift-and-shift approach, mirroring their on-premise over-provisioning habits directly into EC2, and the bill immediately balloons beyond projections.

What To Do About It

• Track your cost-to-revenue ratio monthly. Plot your AWS spend against a meaningful business metric like monthly recurring revenue, active users, or transactions processed. If the lines diverge, dig in.
• Set up AWS Budgets with alerts. Configure budget alerts at 50%, 80%, and 100% of your expected monthly spend. This gives you early warning before a surprise bill lands.
• Review your Cost Explorer trends weekly. AWS Cost Explorer is free and powerful. Look at the month-over-month comparison view broken down by service to identify which services are driving the increase.

For a deeper dive into understanding every line item, see our guide on how to read your AWS bill.

Why It Matters

If you ask your engineering team “why did our AWS bill go up $8,000 last month?” and the answer is a shrug, you have a visibility problem. Without proper tagging, cost allocation, and reporting, your bill is essentially a black box. You cannot optimize what you cannot measure. Organizations without cost visibility consistently overspend by 20-35% compared to those with mature tagging and allocation practices.

Real-World Examples

A healthcare technology company we audited had 340 EC2 instances, and fewer than 40 of them had any cost allocation tags. Nobody knew which instances belonged to which team, product, or environment. When we tagged everything and generated a cost-by-team report, they discovered that their QA environment was costing more than production because load-testing infrastructure had been left running 24/7 for months. Another client had $2,800 per month in S3 costs from a bucket that was feeding a dashboard nobody had looked at in over a year.

What To Do About It

• Implement a mandatory tagging policy. At minimum, every resource should be tagged with environment (production, staging, development), team or owner, project or application, and cost center. Use AWS Organizations Tag Policies to enforce compliance.
• Enable Cost Allocation Tags in the Billing Console. Creating tags is not enough. You must activate them as cost allocation tags in the AWS Billing console for them to appear in Cost Explorer and cost reports.
• Assign cost ownership to teams. Each engineering team should receive a monthly cost report for their tagged resources. When people see the dollars attached to their decisions, behavior changes fast.
• Use AWS Cost Anomaly Detection. This free service uses machine learning to identify unusual spend patterns and alert you before they snowball.

Why It Matters

On-demand pricing is the most expensive way to consume AWS resources. It exists for flexibility, not for running steady-state production workloads. If more than 30% of your compute spend is on-demand instances that run 24/7, you are leaving significant money on the table. Reserved Instances and Savings Plans can reduce compute costs by 30-72% depending on commitment term and payment structure. For a company spending $50K per month on EC2 alone, that is $15K-$36K in monthly savings just by making commitments on workloads you already know will be running.

Real-World Examples

A fintech startup we worked with was spending $38K per month on EC2, all on-demand. Their production workload had been stable for 14 months with no plans to change instance families. By implementing a mix of Compute Savings Plans for their baseline and reserving their RDS instances, we reduced their monthly compute and database costs by $14,200 — a 37% reduction with zero architectural changes. Similarly, many organizations overlook the fact that RDS, ElastiCache, Redshift, and OpenSearch all offer reserved pricing that can cut costs dramatically.

What To Do About It

• Analyze your on-demand vs. committed usage ratio. In Cost Explorer, filter by purchase option to see what percentage of your compute is on-demand versus reserved or covered by Savings Plans. Anything above 40% on-demand for steady workloads is a red flag.
• Start with Compute Savings Plans. They offer the most flexibility — they apply across EC2, Fargate, and Lambda regardless of instance family, region, or operating system. Start conservatively by committing to your minimum baseline usage.
• Use Spot Instances for fault-tolerant workloads. Batch processing, CI/CD pipelines, development environments, and stateless workers are ideal candidates for Spot, which can save 60-90% over on-demand pricing.
• Do not forget about non-EC2 reservations. RDS Reserved Instances, ElastiCache reserved nodes, and Redshift reserved nodes often provide even higher percentage savings than EC2 commitments.

Use our AWS Cost Savings Estimator to see how much you could save with commitment strategies.

Why It Matters

Developer autonomy is critical for velocity, but autonomy without guardrails is how sandbox accounts end up costing $15K per month. When any engineer can spin up a p3.8xlarge GPU instance or provision a multi-AZ RDS cluster for a proof of concept, costs spiral quickly. The intent is never malicious — developers are solving problems, not watching budgets. But the financial impact is real. We have seen individual developer sandbox accounts generate $5K-$20K in monthly charges from forgotten experiments, oversized test databases, and machine learning training jobs that ran longer than expected.

Real-World Examples

One of our clients gave every developer their own AWS account through AWS Organizations, which is a great practice for isolation. However, they set no Service Control Policies or budget limits. Three months later, they discovered a single developer account was running eight GPU instances for a machine learning experiment that had finished weeks ago — at a cost of $12,400 per month. Another common scenario is development environments that mirror production sizing. There is no reason a staging database needs to be a db.r6g.4xlarge when a db.t3.medium would suffice for testing.

What To Do About It

• Implement Service Control Policies (SCPs). Use SCPs to restrict which instance types and services can be used in non-production accounts. Block expensive GPU instances, large memory-optimized instances, and services like SageMaker in sandbox accounts unless explicitly approved.
• Set per-account AWS Budgets with automated actions. Configure budgets that trigger notifications at thresholds and can automatically restrict IAM permissions when budgets are exceeded. This creates a natural feedback loop.
• Use Infrastructure as Code exclusively. Require all infrastructure to be provisioned through Terraform, CloudFormation, or CDK with pre-approved modules that enforce sensible defaults. This eliminates click-ops provisioning that bypasses cost guardrails.
• Schedule non-production environments. Use AWS Instance Scheduler or a simple Lambda function to automatically stop development and staging environments outside business hours. This alone can cut non-production compute costs by 65%.

Why It Matters

Cloud environments are dynamic. New services get deployed, traffic patterns shift, old features get deprecated but their infrastructure stays running. Without regular cost reviews, waste accumulates through a phenomenon called cost drift. Zombie resources — load balancers with no targets, unattached EBS volumes, idle NAT Gateways, and forgotten Elastic IPs — silently drain your budget every day. In our experience, companies that go six months or more without a thorough cost review typically find 15-30% of their spend is waste that accumulated gradually.

Real-World Examples

During a cost optimization engagement with a healthcare SaaS company, we identified $4,200 per month in zombie resources alone: 47 unattached EBS volumes (some with daily snapshots still running), 12 idle Elastic IPs, 3 NAT Gateways serving VPCs with no active workloads, and an old Elasticsearch domain that was receiving zero queries. None of these appeared in any alert because each individual cost was small — $30 here, $150 there — but they added up. We also found that their data transfer architecture had drifted over time, with services making cross-region API calls that were originally designed to be same-region, adding $1,800 per month in data transfer fees.

What To Do About It

• Schedule quarterly cost reviews. Put a recurring event on the calendar. A proper cost review examines right-sizing opportunities, commitment coverage, zombie resources, data transfer patterns, and storage lifecycle policies. Do not let it slip.
• Use AWS Trusted Advisor and Compute Optimizer. Trusted Advisor (Business or Enterprise Support plan) flags idle resources, underutilized instances, and unassociated Elastic IPs. Compute Optimizer analyzes CPU, memory, and network metrics to recommend right-sized instance types.
• Audit your storage lifecycle. Review S3 bucket sizes, access patterns, and lifecycle policies. Move infrequently accessed data to S3 Infrequent Access or Glacier. Delete old snapshots and AMIs that are no longer needed. Implement S3 Intelligent Tiering for buckets with unpredictable access patterns.
• Hunt for zombie resources systematically. Check for unattached EBS volumes, idle load balancers with no healthy targets, unused Elastic IPs, empty or stale ECR repositories, and CloudWatch log groups with no retention policy set (defaulting to indefinite retention).

Our AWS Cost Optimization Checklist walks through 25+ specific actions you can take during your next cost review.

The Common Thread: Cost Management Is Not a One-Time Project

Every one of these warning signs points to the same underlying issue: treating cloud cost management as a one-time initiative rather than an ongoing practice. The organizations that keep their AWS spend under control are the ones that build cost awareness into their engineering culture, establish clear governance policies, and review their infrastructure regularly.

You do not need a massive FinOps team to do this well. You need visibility into what you are spending and why, a commitment strategy that matches your usage patterns, guardrails that prevent accidental waste, and a recurring review cadence that catches drift before it becomes a crisis.

If you recognized your organization in two or more of these warning signs, you are not alone. Most companies we work with check at least three of these boxes before they decide to take action. The important thing is that you have identified the problem — now it is time to fix it.