Cloud cost optimization isn’t usually a security conversation. It should be. The line items piling up on your AWS bill often point directly to forgotten infrastructure, and forgotten infrastructure is where breaches start.

We’ve worked with at least half a dozen mid-market software companies over the past two years where the CFO was asking about cloud spend and the security team was asking about risk. They were looking at the same resources from different angles and never realized it. The EC2 instance that’s been running since a proof-of-concept last January? It’s on your bill every month. It’s also running an unpatched AMI with a public elastic IP that nobody monitors.

The Overlap Between Waste and Risk

When a DevOps team flags cloud waste, they’re typically looking at utilization metrics. Low CPU on EC2 instances, idle RDS databases, S3 buckets with no recent access. When a security team flags AWS security misconfigurations, they’re looking at exposure. Public access, overly permissive IAM roles, and missing encryption at rest.

These are often the same resources.

A mid-market SaaS company we worked with last year had its data engineering team spin up a set of S3 buckets for a machine learning experiment. The experiment ended, but the buckets stayed. The DevOps team noticed it seemed abandoned and was costing the company money.

When we looked at those same buckets during a CSPM engagement, half of them had default ACLs that allowed broader access than anyone intended. One contained a full copy of their production customer database, sitting in a bucket with no access logging, no versioning, and no lifecycle policy.

That’s one problem wearing two hats.

Lambda Functions and the Ownership Gap

Serverless creates a specific version of this issue. Lambda functions are cheap to run individually, so they rarely trigger cost alerts until you have hundreds of them. And because they’re cheap, nobody cleans them up.

We routinely find Lambda functions in client environments that were created by engineers who left the company a year ago. The functions still run on a schedule or sit behind an API Gateway endpoint. They still have the IAM execution roles they were given at creation. Those roles frequently have far more permissions than the function ever needed, because during development it was easier to attach a broad managed policy than to write a scoped one.

One client had 340 Lambda functions. Fewer than 200 were in active use. Of the remaining 140, about 60 had execution roles that could read from or write to production DynamoDB tables. Nobody was reviewing CloudWatch logs for any of them. The monthly compute cost was trivial, but the security exposure was anything but.

What a CSPM Engagement Finds

When we run a cloud security posture management assessment against a typical $50M-$500M software company’s AWS environment, the first week usually surfaces 200 or more misconfigurations. The breakdown tends to follow a pattern.

Roughly a third are IAM issues. Roles with wildcard permissions, service accounts with console access, cross-account trust policies that are too broad.

Another third are patching issues related to AMIs or containers. Ancient images, lack of patching, pets vs cattle approaches, the list goes on and on. The blend of OS patching vs App library patching, and the associated ownership confusion, leads to no one owning it. Most of the time we can tell when a project was started since it maps to the release date of the now unsupported version of Alpine.

The remaining third splits between encryption gaps, logging blind spots, and storage permissions and other miscellaneous issues.

The part that surprises most CTOs is how many of those findings also represent cost and waste problems in the cloud. The security group that’s too permissive is attached to an instance that should have been terminated. The S3 bucket with public read access contains data from a discontinued feature. The IAM role with admin permissions belongs to a CI/CD pipeline for a service that was decommissioned.

Fixing the security issue and reducing the bill happen in the same action.

The Takeaway

Cloud cost optimization and cloud security are the same conversation held in different rooms. The CFO’s spreadsheet of underutilized resources and the security team’s list of misconfigurations overlap more than most organizations realize.

If you’re already planning a cloud cost review, you should be reviewing security posture at the same time. If you’re already planning a security assessment, pull in the finance data. You’ll find that the resources costing you money for no reason are often the ones creating risk for no reason.

The fix is getting the people who care about cost and the people who care about security to look at the same inventory together.