Security findings and cost findings are usually filed by different teams into different tools, and treated as different kinds of problem. But a specific set of configurations sits squarely in both piles: a database open to the internet, a security group accepting traffic from anywhere, an IAM role with a wildcard where a scope should be. The security report calls them risk. The invoice, eventually, calls them money. Treating them as one category gets both teams moving on the same afternoon.
How risky config becomes spend
Publicly accessible RDS. A database with PubliclyAccessible: true and a permissive security group doesn't just widen your attack surface; it works harder. Internet-facing databases absorb continuous scan and connection-attempt traffic, which burns connections, CPU, and sometimes forces the "we need a bigger instance" conversation that a private subnet would have made unnecessary. And every byte an exposed endpoint serves outward is data transfer billed at internet egress rates. The audit is one query: aws rds describe-db-instances --query 'DBInstances[?PubliclyAccessible].DBInstanceIdentifier'. The right answer for almost every production database is an empty list, with access via VPC peering, private endpoints, or a bastion pattern.
