Private endpoints & east-west TLS

PrivateLink, endpoint policies, mTLS internally.

Two habits quietly leave AWS data exposed: sending traffic to managed services across the public internet, and trusting the internal network enough to run it in plaintext. Private connectivity and end-to-end encryption close both.

Reach services privately

A managed database, queue, or partner API with a public endpoint does not have to be reached over the internet. Gateway endpoints (S3, DynamoDB) and Interface endpoints / PrivateLink project a service into your VPC as a private interface, so the data plane stays on the AWS backbone. That removes a whole class of exposure — no public route to firewall, no data on the open internet — and access is governed by your network policy plus IAM. Endpoint policies further scope which actions and resources are reachable through the endpoint.

# Endpoint policy: traffic through this VPC endpoint can only touch our bucket,
# so even a broad IAM policy cannot exfiltrate to an arbitrary S3 bucket.
{
  "Statement": [{
    "Effect": "Allow", "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject"],
    "Resource": ["arn:aws:s3:::acme-data/*"]
  }]
}

TLS everywhere, including east-west

Terminating TLS at the ALB and letting the internal hop run plaintext leaves every service-to-service call exposed inside the VPC. Push encryption to the workload: use ACM certificates on internal listeners, or a service mesh (App Mesh, Istio) that transparently wraps east-west traffic in mutual TLS with short-lived, auto-rotated identity certs. Assume the internal network is hostile — "internal" is not a security property.