Block public access to AWS resources

Public access across AWS is the single biggest source of accidental data exposure, and almost every control in this group costs nothing in AWS spend to fix. Turning off a public IP, tightening a resource policy or un-sharing a snapshot does not change your bill. The cost sits entirely in the few exceptions: the buckets and endpoints that genuinely serve public traffic and need to move behind CloudFront or a load balancer first.

Frame each failing control as a line on the risk register rather than a compliance checkbox. A publicly accessible RDS instance holding customer records carries a far higher expected loss than a public IP on a throwaway test box, yet both show up as a single red finding. Map the failures to the data behind them and prioritise by exposure, not by control count.

The insurance maths is one-sided. The remediation is engineering time plus a small, bounded migration for the legitimate exceptions. The downside of leaving it is the documented cost of a public-exposure breach: regulatory fines, breach notification, forensics, legal fees and reputational damage.

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with twenty-three public-access failures spread across S3, EC2, RDS and SNS in three older accounts. Her instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Closing a public IP or tightening a resource policy changes nothing on the AWS bill, so the spend question is narrow: only the handful of resources that genuinely serve public traffic carry a real migration cost when they move behind CloudFront or a load balancer.

She asks the team to map each failing control to the data sitting behind it. Two findings are publicly accessible RDS instances holding customer records, one is a public download bucket that is meant to be reachable, and the rest are public IPs on test boxes and a couple of open SNS policies. Priya reframes the list on the risk register: the two customer databases are high expected-loss items to close today at zero AWS cost, the public bucket is a small, bounded CloudFront migration to schedule, and the test-box IPs are low-value drift to sweep up. Her finance pack reads: 'Twenty-one findings close at no incremental spend; one legitimate public service needs a bounded migration; the only thing standing between us and a clean posture is engineering time, not budget.'

The cost model here is asymmetric in a way that is rare for security work. Closing public access costs nothing in AWS spend, and leaving it open creates an unbounded tail risk. Each failing control is a resource where a future accident could expose its contents, and while the probability per event is low, the probability across all resources over years is not.

The documented cost of a public-exposure breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is engineering time plus a bounded migration for the few legitimately public services. The finance role is to attach expected loss to each failing resource so the work is prioritised by risk, not by the order the report lists it.

Public access is the category of risk that turns a configuration mistake into a headline. A bucket, a database or a queue that can be reached from the open internet is one bad change away from exposing data, and the report shows this as a scatter of separate findings across many services.

The leadership question is not "are we compliant today?" It is "if a deployment makes a mistake tomorrow, can it expose data to the internet?" The defensible end state is that public reachability is prevented by policy, with the small number of genuinely public services routed through a controlled front door, not left on the open internet.

None of this is a cost decision. Closing public access is free in AWS terms. It is a governance decision about whether exposure is prevented by design or only by everyone remembering not to make a mistake.

After a peer company made the news for a leaked customer database that turned out to be a publicly accessible RDS instance nobody meant to expose, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to check, because public reachability across the estate was governed by habit rather than policy.

The team's response was to stop treating public access as a per-resource cleanup and start treating it as a guardrail. They inventoried everything reachable from the internet, routed the genuinely public services through CloudFront and a load balancer, closed the rest, and then turned on account-level S3 Block Public Access and VPC Block Public Access as backstops that no individual resource can override. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform prevents it by design, and the few intentional public front doors are documented.' That shift, from relying on everyone remembering not to make a mistake to making the mistake structurally hard, is the one-line confidence signal this control delivers, and it costs nothing in AWS spend to reach.

Nearly every major cloud data breach that involved exposed storage came back to the same root cause: a resource that could be made public was made public by an internal change. Blocking public access is the control that makes that root cause structurally difficult, and the account-wide and VPC-wide blocks make it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.