Move resources into private networks (VPC isolation)

Most of this capability is free in AWS terms. Turning on Redshift enhanced VPC routing, placing a new domain inside a VPC, or moving an RDS instance to a private subnet group does not change instance, storage or compute charges. The cost sits in a small number of exceptions: rebuilding a public OpenSearch domain is a one-time migration with a brief double-running window, and a Lambda or EC2 fleet that moves into private subnets needs a private egress path, which is either a free S3 or DynamoDB gateway endpoint, a paid interface VPC endpoint, or a NAT gateway with per-GB charges.

The right framing is to scope remediation by data sensitivity and pick the cheaper egress path. Interface VPC endpoints are roughly $7 per month each per Availability Zone and keep traffic inside AWS; a NAT gateway is a flat hourly charge plus a per-GB data-processing fee. For a workload calling one or two AWS services, endpoints are usually far cheaper than routing everything through NAT, and a gateway endpoint for S3 is free outright.

Map each failing control to the data behind it and prioritise by exposure. A publicly reachable database or search domain holding customer records carries a far higher expected loss than a utility Lambda that only posts to Slack. The insurance maths is one-sided: the remediation is engineering time plus a small, bounded egress cost for the few legitimate exceptions, against the documented cost of a data-exposure breach.

Priya is the finance partner working alongside the platform team on the SOC 2 programme. Security Hub returns a wall of network-placement failures: a handful of public Lambda functions, two RDS instances in subnets with an internet gateway route, a public OpenSearch domain, and a Redshift cluster with enhanced VPC routing off. Her instinct is not to ask how much it all costs, because most of it costs nothing; it is to ask which of these resources actually hold data that would hurt the business if it leaked.

The team annotates the list. The OpenSearch domain indexes customer support tickets and the two RDS instances hold orders and billing records, so those three carry real expected loss. The Lambda functions only post to a Slack webhook, and Redshift is internal analytics behind a private VPN. Priya re-orders the work by data sensitivity rather than by the report's order, funds the one item with a genuine cost (the OpenSearch rebuild, a one-time migration with a short double-running window), and notes that the rest is free configuration plus a few interface VPC endpoints at roughly seven dollars per month per Availability Zone. Her output for the finance pack is a single line: the data-bearing exposures close this quarter at a bounded egress cost, the cosmetic findings close as routine hygiene.

The cost model here is asymmetric. Most of these controls cost nothing in AWS spend to fix, and leaving them open creates an unbounded tail risk. The few that do carry a cost are bounded and knowable: a one-time OpenSearch migration with a day or two of double-running, and a small recurring egress charge for workloads moved into private subnets, which is minimised by preferring a free gateway endpoint or a narrow interface endpoint over a NAT gateway.

The documented cost of a data-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 egress cost for the legitimate exceptions. The finance role is to attach expected loss to each failing resource so the work is prioritised by the sensitivity of the data behind it, not by the order the report lists it, and to insist the cheaper egress path is chosen for every workload that moves into a private subnet.

Network isolation is the discipline of running workloads inside a private network the security team controls, and giving them a private path to the AWS services they depend on, rather than a route out to the open internet. The report shows this as a scatter of findings across databases, search, serverless and compute, but it is one governance question.

The leadership question is not "are we compliant today?" It is "do the systems that hold our data sit inside a network we observe and control, or out where a misconfiguration could expose them?" The defensible end state is that data-bearing workloads are private by default, enforced by policy, with the few legitimately public services routed through a controlled front door.

Most of this is free to fix. The exceptions are bounded: a one-time migration for a public search domain, and a small recurring egress cost for workloads moved into private subnets. It is a governance decision about whether isolation is built in by design or left to everyone remembering to set it.

After a peer company made headlines for a customer database that turned out to be reachable from the open internet, the board asked the CTO a direct question: could that happen to us? The honest answer at the time was that nobody could say for certain, because workloads were placed on the network by whoever provisioned them, and there was no enforced default keeping data-bearing services private.

The response was to make network placement a governance question rather than a per-resource engineering choice. Data-bearing workloads are now private by default, pinned in the Terraform modules and backed by a Service Control Policy that blocks creating a public search domain or a database in a subnet with an internet gateway route. The few legitimately public services sit behind CloudFront or a load balancer, never directly exposed. A quarter later the same board question had a one-line answer: every system that holds customer data sits inside a network the security team observes and controls, and the platform cannot create a new one any other way.

Nearly every major cloud data breach that involved exposed storage or search came back to the same root cause: a data-bearing resource that was reachable from the internet, usually by accident. Network isolation is the capability that makes that root cause structurally difficult, and enforcing private-by-default for data infrastructure makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is mostly engineering time plus a small, bounded egress cost for the exceptions. This is the class of control where the risk of inaction is severe and the cost of action is modest and knowable, which is exactly the trade leadership should be quickest to approve.