Publicly Accessible RDS and Unrestricted Security Groups: The Cost Side of Risky Cloud Config

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.

Unrestricted security groups (0.0.0.0/0). Open inbound on 80/443 behind a load balancer is the job. Open inbound on SSH, RDP, database ports, or "all traffic" is the classic pre-incident finding, and the incident it precedes is very often a cost incident: the most common monetization of a compromised cloud resource is cryptomining, which means the attacker's first move is launching or saturating compute. Companies discover these breaches on the bill, not in the SIEM: a $40,000 anomaly weekend on GPU instances nobody in the org launched. The audit: aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values='0.0.0.0/0' and then filtering out the intentional web-facing rules.

Wildcard IAM. Roles with AdministratorAccess or "Principal": "*" don't cost anything while nothing goes wrong. They define the blast radius for when something does: one leaked key with admin scope is the difference between an incident report that says "attacker enumerated one bucket" and one that says "attacker launched 400 instances in three regions we don't use." Cost-wise, wildcard IAM is unpriced tail risk, and the mitigation (scoping roles, requiring MFA, alerting on use of broad roles) is nearly free.

The bastion tax, as a bonus. Teams that fix public exposure the old way (a bastion host per VPC) buy a small standing cost: an instance, its EIP, its patching. Session Manager and its equivalents removed the need for most of these years ago; retiring bastions is a rare win that removes cost and attack surface in the same change.

Why this pairing is worth institutionalizing

Cost has something security usually lacks: a monthly forcing function that executives already read. Security has something cost usually lacks: veto power. Findings that carry both labels ("this database is exposed AND its egress pattern is costing us") clear prioritization queues that pure-risk findings sit in for quarters. In practice that means one shared audit list, run on a cadence, where each item carries both a risk note and a dollar note, and either team can champion it.

The honest scope note: none of this is a security program. Closing 0.0.0.0/0 on port 5432 doesn't make you secure; it makes you not-negligent, cheaper, and harder to monetize. The full security job (identity, detection, response) belongs to security tooling and people. This list is the overlap zone where the cheapest security wins and the cheapest cost wins are the same three commands.

The one-afternoon audit

1. Public databases: the PubliclyAccessible query above, cross-checked against each one's security group. Expected output: empty, or a short list with written justifications.
2. Open security groups: the 0.0.0.0/0 filter, minus intentional web listeners. Every remaining rule gets closed or documented today, not sprint-after-next.
3. Wildcard IAM: list roles carrying AdministratorAccess and policies with * actions on * resources; each either gets scoped or gets an owner and an expiry.
4. Anomaly tripwire: whatever cost alerting you run, confirm it would actually page on a sudden compute spike in an unused region, because that's what "we got mined" looks like on day one.

FAQ

Why does a publicly accessible RDS instance cost more?

Beyond the risk: internet-facing endpoints absorb continuous scanning and connection-attempt load (consuming connections and CPU that get "solved" by upsizing), and everything they serve outward bills at internet egress rates. Moving the database private removes attack surface and those cost pressures in one change.

Is an open security group ever acceptable?

For web-facing listeners (80/443) behind a load balancer, yes, that's what they're for. For SSH, RDP, database ports, or all-traffic rules, effectively never; those are the standard entry points for compromises whose most common outcome is cryptomining billed to your account. Scope them to known CIDRs or replace interactive access with Session Manager.

How do compromised cloud accounts usually show up?

On the bill. The dominant monetization is compute abuse (mining on large or GPU instances, often in regions the victim doesn't use), which means a sudden spend anomaly is frequently the first detection signal. That's also why cost anomaly alerting with per-region granularity doubles as a security tripwire.

Do wildcard IAM roles cost anything?

Not until they do. Their cost is the blast radius they grant to any leaked credential: the difference between a contained incident and a three-region instance-launch spree. Scoping roles and alerting on broad-role use is one of the cheapest risk reductions in cloud, which is exactly why it belongs on the shared cost-and-security list.