Private Connectivity to Data Services: Closing the Last Gap

Part 4 of 6 in the Networking & VPC Foundations for Data Engineering series

Quick gut check before we start: in Part 3's 3-tier architecture, when your Spark cluster in the private subnet needs to read from S3 or write to BigQuery, where does that traffic actually go?

If your answer is "out through NAT, same as any other internet call" — you're right, and that's the gap this article closes. Even though S3 and BigQuery are the cloud provider's own services, sitting on the same network as your VPC, traffic to them by default still leaves through your NAT Gateway or Cloud NAT and travels over the public internet as far as routing is concerned. It works, but it's not actually private, and it's not free.

Why This Is Worth Fixing

Three concrete reasons this matters for a data platform specifically:

1. Cost. NAT charges per gigabyte processed. Data pipelines reading and writing large volumes to S3 or GCS through NAT can rack up meaningful NAT data-processing charges for traffic that never needed to leave the provider's network in the first place.
2. Security posture. "Traffic to our data services goes over the public internet" is exactly the kind of finding that fails a security review, even if the traffic is encrypted in transit.
3. It's avoidable. Both clouds offer a way to route this traffic entirely within their private backbone — no NAT, no internet exposure, often no cost at all for the most common services.

AWS: Gateway Endpoints vs. Interface Endpoints (PrivateLink)

AWS actually gives you two different mechanisms here, and which one you use depends on the service:

Gateway Endpoints — for S3 and DynamoDB only. These work by adding a route to your route table pointing at the service, with no new network interface, no hourly charge, and no data-processing charge at all. If your data platform's main need is private S3 access, this is the one you want, and there's no real reason not to enable it.

Interface Endpoints — powered by AWS PrivateLink — cover the other 100+ AWS services (and third-party SaaS via the AWS Marketplace) that Gateway Endpoints don't reach. These create an actual network interface (ENI) with a private IP inside your subnet, governed by a security group like any other resource. They carry an hourly charge per AZ plus a data-processing fee — not free, but still typically far cheaper than the NAT charges they replace.

One newer option worth knowing about: AWS introduced Resource Endpoints, which let a VPC privately reach a specific resource — like an RDS instance — in another VPC or on-premises, without needing a Network Load Balancer in front of it. If you're designing a fresh multi-VPC data platform today, it's worth a look, though Gateway and Interface Endpoints still cover the overwhelming majority of day-to-day data engineering needs.

GCP: Private Google Access vs. Private Service Connect

GCP splits this along a similar line, though the mechanics differ:

Private Google Access — a simple, subnet-level setting. Turn it on, and instances with no external IP in that subnet can reach Google APIs (Cloud Storage, BigQuery, Pub/Sub, etc.) using Google's own shared IP ranges for those APIs. No new resource to manage, no direct cost. This is the GCP rough-equivalent of AWS's Gateway Endpoints in spirit — flip a switch, get private access to the common case.

Private Service Connect (PSC) — the more flexible, more deliberate option. Instead of relying on Google's shared public-API IP ranges, PSC creates an actual endpoint with your own internal IP address inside your VPC, which then privately forwards traffic to the target service. PSC covers Google APIs (with more routing/DNS control than Private Google Access gives you) and — this is the part that maps most directly to AWS PrivateLink — lets you privately reach services published by other VPCs or third parties, including your own internal services shared across teams.

The rule of thumb: start with Private Google Access for straightforward private access to Google's own APIs. Reach for PSC when you need your own IP addressing, tighter DNS/routing control, or you're connecting to something that isn't a first-party Google API at all.

Side by Side

The DNS Piece Nobody Mentions Until It Bites You

Here's a detail that trips people up on both clouds: creating the endpoint isn't the whole job. Your application is almost certainly still resolving s3.amazonaws.com or storage.googleapis.com to the service's public IP by default — which means it'll try to reach that public IP, and depending on your routing, that might still mean going out through NAT, or simply failing if there's no route out at all.

To actually route traffic through the endpoint, DNS resolution for that service needs to return the endpoint's private address instead of the public one. AWS Interface Endpoints handle this via private DNS, which — when enabled on the endpoint — overrides the service's standard DNS name within your VPC to resolve privately. GCP's PSC endpoints similarly need appropriate private DNS zone configuration pointing at the endpoint's internal IP.

If you've done everything right — endpoint created, security group/firewall configured — and traffic still isn't using it, DNS resolution is the first thing to check. It's the same lesson from Part 1's DNS section, just showing up again in a new context.

What's Next

We've been assuming a single VPC this whole series. Real organizations rarely stop at one — different environments, different teams, sometimes different AWS accounts or GCP projects entirely, all needing to talk to each other. Part 5 covers how: VPC Peering, Transit Gateway, and Shared VPC.