Nobody ever got fired for using the default settings.
That's the lie, anyway. In practice, plenty of teams are bleeding $50K, $100K, $200K a month because someone hit "next, next, next, deploy" eighteen months ago and nobody ever went back to check. The defaults shipped. The bill grew. And now the finance team is asking uncomfortable questions that nobody can answer because the person who stood up that RDS instance left the company in Q3.
Here's the thing about cloud provider defaults: they're not neutral. They're not "safe." They're optimized for one thing — making sure you don't file a support ticket. And the easiest way to prevent support tickets is to overprovision everything.
I've been auditing cloud environments for years, and there's a pattern so consistent I could set my watch by it. Somewhere between 30% and 40% of every AWS bill I look at traces back to default configurations that nobody consciously chose.
Let me give you some examples that show up in nearly every audit:
RDS Multi-AZ on dev databases. AWS defaults you into Multi-AZ on production templates, and most teams copy those templates for dev and staging without thinking twice. That's 2x the cost for a database that nobody accesses on weekends. I audited a Series C startup last quarter that had 14 RDS instances in Multi-AZ across three environments. Seven of them were dev/staging. Turning off Multi-AZ on non-production saved them $4,200/month. Took about fifteen minutes. EBS gp3 volumes at default IOPS. When gp3 launched, everyone celebrated the price drop from gp2. But gp3 ships with 3,000 baseline IOPS and 125 MB/s throughput — and the provisioning console lets you crank those numbers up with a slider. Guess what teams do when they see a slider? They slide it. I routinely find gp3 volumes provisioned at 10,000-16,000 IOPS attached to workloads that average 200 IOPS. The delta between baseline gp3 and "someone touched the slider" gp3 can be 3-4x per volume. CloudWatch log retention set to "Never Expire." This is the silent killer. CloudWatch Logs defaults to indefinite retention. Every Lambda invocation, every ECS task, every API Gateway request — logging forever, at $0.50/GB ingestion plus $0.03/GB/month storage. I worked with a team spending $18,000/month on CloudWatch Logs. They needed 30 days of retention for debugging. Thirty days. The other eleven months of logs were pure waste, just sitting there accumulating charges because nobody set a retention policy. NAT Gateway as the default egress path. This one hurts because it's architecturally baked in. Teams follow the AWS VPC best-practice docs, set up private subnets with NAT Gateways, and then route everything through them — including traffic to S3, DynamoDB, and other AWS services that support VPC endpoints. NAT Gateway charges $0.045/GB processed. VPC endpoints for S3 are free. I've seen NAT Gateway bills north of $30K/month at companies that could cut 60% of that traffic with three VPC endpoint configurations.Let's be clear about something: this isn't a conspiracy. Cloud providers aren't sitting in a room cackling about your CloudWatch bill. But the incentive structure is real and it's powerful.
Cloud providers optimize for two things: reducing support burden and increasing consumption. Those goals are perfectly aligned when it comes to defaults. Overprovision everything, log everything, replicate everything — and the customer never calls to complain about downtime. They might complain about cost eventually, but that's a billing conversation, not a P1 incident. And by the time they complain about cost, they're already locked into an architecture that's expensive to refactor.
This is why the "shared responsibility model" is such a clever piece of framing. AWS tells you security is a shared responsibility. But they never say cost is. The implicit message is: we'll give you the tools to manage cost (Cost Explorer, Budgets, Trusted Advisor), and if you don't use them, that's your problem.
The tools exist. The defaults don't change.
Here's where I see teams get stuck. They discover the problem — usually after a painful bill shock — and their first instinct is to build a dashboard. Map out all the defaults. Create a spreadsheet of "default vs. optimal" configurations. Maybe even write a Confluence page titled "Cloud Configuration Standards."
And then absolutely nothing happens.
The dashboard gets built. The Confluence page gets 12 views. Engineers keep deploying with defaults because the path of least resistance hasn't changed. The Terraform modules still ship with Multi-AZ enabled. The CloudWatch log groups still don't have retention policies. The NAT Gateway is still routing S3 traffic.
Visibility didn't fix this. It never does.What actually works is changing the defaults themselves. Not documenting what the good settings should be — actually enforcing them at the infrastructure layer.
The teams I've seen actually solve this do three things:
1. They own the Terraform modules. Platform engineering writes opinionated modules that ship with cost-sane defaults. Dev/staging RDS? Single-AZ, t3.medium, 30-day backup retention. Want Multi-AZ? You can enable it, but you have to explicitly opt in and tag it with a cost center. The default path is the cheap path. 2. They set guardrails with teeth. Not "best practice" documents — actual SCPs and OPA policies that prevent the expensive path. Can't provision gp3 volumes over 3,000 IOPS without a tag justifying it. Can't create a CloudWatch log group without a retention policy. Can't launch an instance type larger than 2xlarge in a dev account. These aren't suggestions. They're guardrails. 3. They run automated sweeps, not quarterly reviews. A Lambda function that runs weekly, checks every CloudWatch log group for missing retention policies, and either sets 30-day retention or pages the owning team. A scheduled job that identifies EBS volumes with provisioned IOPS exceeding 2x their p95 utilization. Automation that acts, not automation that reports.Here's a rough calculation I run with every new audit client. Take your monthly AWS bill. Multiply by 0.35. That's roughly what you're paying in "default tax" — configurations nobody consciously chose, settings that exist because the deployment went out and nobody went back.
On a $500K/month bill, that's $175K/month. $2.1M/year. Not in underutilized resources or zombie infrastructure — in active workloads running with dumb configurations.
The frustrating part? Most of this is fixable in days, not months. Changing CloudWatch retention policies is a one-liner. Turning off Multi-AZ on dev databases is a maintenance window. Adding VPC endpoints is an afternoon of Terraform. The technical lift is trivial.
The organizational lift is where it falls apart. Because someone has to own it. Someone has to decide that the default path should be the cost-optimized path, not the "nobody complains" path. And that means a platform team or FinOps team that has the authority to change shared modules, enforce policies, and push back on "but we've always done it this way."
Cloud providers will never optimize their defaults for your bill. That's not cynicism — it's incentives. Their job is to make the cloud easy to use and hard to leave. Your job is to make sure "easy to use" doesn't mean "expensive by default."
Start with one thing this week: pick your three most expensive AWS services, pull up the configuration on your largest resources, and ask one question — "Did someone consciously choose this setting, or did we just accept the default?"
If you can't answer that question, you've found your next $50K in savings.
---
Want to know exactly how much your defaults are costing you? Our free Cloud Waste Audit scans your AWS environment and identifies the configuration choices — including the ones nobody made — that are inflating your bill. 24 hours, zero engineering time, real dollar figures.
