Private Connectivity Patterns in AWS

Understanding why keeping traffic off the public internet matters, and the architectural tradeoffs between each approach

Why Private Connectivity Matters?

When your application in AWS needs to talk to a service like S3, that request has to travel from point A to point B. The question is: what path does it take?

By default, that traffic goes over the public internet. Now, it doesn’t leave AWS’s physical infrastructure, but it does pass through public IP space. Think of it like sending an internal company memo through the public postal system. It’ll probably arrive fine, but it’s traveling on roads you don’t own, past people you don’t know, through systems you don’t control.

Private connectivity changes the route. Instead of the public path, your traffic moves entirely through AWS’s internal network, a dedicated, private backbone that never touches the public internet. Same origin, same destination, completely different path.

Why does this matter?

Smaller attack surface. Every time data crosses public infrastructure, there’s an opportunity, however small, for it to be observed, intercepted, or targeted. Private connectivity removes that opportunity entirely.

Compliance requirements. Industries like healthcare, finance, and government often have strict rules about how data moves. Many regulations require that sensitive information never traverse public networks. Private connectivity satisfies this by design.

Defense in depth. No single security measure is perfect. Private connectivity adds a network level layer of protection that works independently of your identity policies, encryption, or application level controls. If any of those layers fail, the network layer is still doing its job.

The bottom line: if your data doesn’t need to travel on public roads, it shouldn’t.

Pattern 1: VPC Endpoints

VPC Endpoints allow resources inside your VPC to communicate with AWS services without going through an internet gateway, NAT gateway, or using a public IP address. They are the easiest way to set up private connectivity.

There are two types, and they work quite differently.

Gateway Endpoints

Gateway Endpoints are available for only two services: S3 and DynamoDB. When you create one, AWS adds a route to your VPC’s route table that sends all traffic headed for these services through a private gateway instead of the public internet. Think of it like this: normally your traffic would take the highway (public internet) to reach S3. A Gateway Endpoint builds a private road directly from your VPC to S3. Your traffic never has to merge onto the highway at all. They are completely free, controlled through route tables, secured with endpoint policies, and work within the same AWS region. There is very little reason not to set them up in every VPC.

Interface Endpoints

Interface Endpoints use AWS PrivateLink technology and support over 100 AWS services including KMS, Secrets Manager, CloudWatch, SQS, SNS, and Lambda. They work by creating an Elastic Network Interface (ENI) inside your subnet with a private IP address. When your application makes a request to the AWS service, the traffic resolves to this private IP instead of the service’s public address. In simpler terms, instead of your request going out to the internet to find KMS, it finds KMS right there inside your own network through a private door. Use them whenever your security requirements demand that API calls stay completely off the public internet, especially for services handling sensitive data like KMS and Secrets Manager.

Pattern 2: AWS PrivateLink (Service to Service)

So far we have talked about using PrivateLink to connect to AWS services. But PrivateLink can also let you expose your own services privately to other VPCs or AWS accounts. No VPC peering, no public IPs, no complex routing.

This is especially valuable for multi account organizations and SaaS providers who need to give customers private access to their services.

How It Works

The provider places their service behind a Network Load Balancer (NLB) and creates an Endpoint Service pointing to it. The consumer creates an Interface Endpoint in their own VPC that connects to that Endpoint Service. Traffic flows through AWS’s private network. Neither side sees the other’s network.

Think of it like a restaurant kitchen window. The customer (consumer) places orders and receives food through the window, but never enters the kitchen (provider’s network). The kitchen staff never walks into the dining room either.

Why This Architecture Matters

1. One directional by design. The consumer can reach the provider’s service, but the provider cannot initiate connections back. VPC peering does not offer this.
2. No IP address conflicts. Both sides can use the same IP ranges since there is no routing between the VPCs.
3. Both sides must opt in. The provider approves which accounts can connect. The consumer creates the endpoint. Neither side is forced into it.

Simple rule: if you are sharing a specific service, use PrivateLink. If two VPCs need full open connectivity and you trust both equally, use peering.

Pattern 3: AWS Transit Gateway

As organizations grow, they end up with dozens or even hundreds of VPCs. If you try to peer each VPC to every other one, you get an unmanageable web of connections. Transit Gateway solves this by acting as a central hub that all VPCs connect to.

How Transit Gateway Works

Transit Gateway is a regional, managed router. You attach your VPCs, VPN connections, and Direct Connect gateways to it. It then routes traffic between those attachments based on route tables that you define. The real security power lies in those route tables. You can create completely separate routing domains so that certain VPCs can only reach specific destinations and nothing else.

This means a development VPC physically cannot send traffic to a production VPC because the route simply does not exist. This is network level segmentation at the organization level, and it is one of the most powerful security controls available in AWS.

Additional Security Features

1. Route table isolation. Each attachment gets its own route table, creating hard boundaries between network segments. If the route does not exist, the traffic cannot flow. It is that simple.
2. Appliance mode. When you need inline security inspection using firewalls or IDS/IPS, appliance mode ensures traffic between two VPCs always passes through the same inspection appliance, maintaining proper stateful flow.
3. Multicast support. For specialized use cases like financial market data distribution, Transit Gateway supports multicast domains with fine grained membership controls.

Putting It All Together: Reference Architecture

Here is how these three patterns combine in a real world, security focused AWS architecture:

Traffic Flows

1. App server to S3: Goes through the Gateway Endpoint. Never touches the internet. Free.
2. App server to KMS: Goes through an Interface Endpoint. Private. Encrypted API calls stay on AWS’s backbone.
3. VPC to VPC: Routed through Transit Gateway. Route tables enforce that production and development are isolated.
4. Shared services: Both environments reach shared services VPC through Transit Gateway, but shared services routes are the only ones they have in common.
5. On premises: Connected via Direct Connect or VPN to the Transit Gateway. Routed to the appropriate VPC based on route tables.

Cost Considerations

A data breach resulting from exposed traffic or lateral movement across overly connected networks is orders of magnitude more expensive than any of these charges.

Key Takeaways

1. Keep traffic off the public internet by default. Use Gateway Endpoints (free) for S3 and DynamoDB in every VPC.
2. Use Interface Endpoints (PrivateLink) for sensitive AWS service calls like KMS, Secrets Manager, and STS.
3. Use PrivateLink for service to service connectivity across accounts. It is one directional by design and avoids IP overlap issues.
4. Use Transit Gateway to replace VPC peering meshes at scale, and leverage its route tables for hard network isolation.
5. Layer these patterns together: Transit Gateway for macro level segmentation, PrivateLink for service level access, VPC Endpoints for AWS service access.
6. Private connectivity is a foundational building block for Zero Trust. It ensures that even if identity and application controls fail, the network layer provides defense in depth.