NAT Gateway vs PrivateLink vs VPC Endpoints — Cost & Architecture Trade-offs

AWS Networking Series | Part 3 — Building secure, cost-optimised, cloud-native infrastructure on AWS

TL;DR Comparison

Introduction

One of the most misunderstood areas in AWS networking is knowing when to use a NAT Gateway, when to use PrivateLink, and when to use a VPC Endpoint. Engineers often default to NAT Gateway for everything — and then get a nasty AWS bill at the end of the month.

These three constructs solve different problems. Using the wrong one means either paying too much, exposing traffic unnecessarily, or building overly complex architecture. In this post, we'll break down each option — how they work, when to use them, their cost models, and how to choose the right one for your workload.

1. NAT Gateway — Outbound Internet Access

A NAT Gateway (Network Address Translation Gateway) is an AWS-managed service that allows resources in a private subnet to initiate outbound connections to the internet, without those resources being directly reachable from the internet.

How Traffic Actually Flows:

1. Your EC2 in a private subnet sends a packet to PyPI (e.g., 151.101.1.140).
2. The subnet's route table has 0.0.0.0/0 → nat-xxxxxxxx.
3. NAT Gateway translates the source IP to its Elastic IP.
4. Packet exits via the Internet Gateway to PyPI.
5. Response comes back to the NAT Gateway, which translates back and forwards to your EC2.

# IaC Example — Terraform
resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
  tags          = { Name = "main-nat-gateway" }
  depends_on    = [aws_internet_gateway.main]
}

    nat_gateway_id = aws_nat_gateway.main.id
  }
}

Real-World Cost Comparison: NAT-Only vs Optimised

Modelling a production ECS cluster: 200 GB/month ECR pulls, 500 GB/month S3 writes, 5 GB/month SSM traffic, across 2 AZs.

Scenario A — NAT Gateway Only

Scenario B — Gateway Endpoint + Interface Endpoints + NAT GW for internet only

The Cost Reality:

# High Availability Per-AZ NAT Gateway Pattern
resource "aws_eip" "nat" {
  for_each = toset(["eu-west-1a", "eu-west-1b", "eu-west-1c"])
  domain   = "vpc"
  tags     = { Name = "nat-eip-${each.key}" }
}

resource "aws_nat_gateway" "az" {
  for_each      = toset(["eu-west-1a", "eu-west-1b", "eu-west-1c"])
  allocation_id = aws_eip.nat[each.key].id
  subnet_id     = aws_subnet.public[each.key].id
  tags          = { Name = "nat-gw-${each.key}" }
}

resource "aws_route" "private_nat" {
  for_each               = toset(["eu-west-1a", "eu-west-1b", "eu-west-1c"])
  route_table_id         = aws_route_table.private[each.key].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.az[each.key].id
}

2. AWS PrivateLink (Interface Endpoints)

AWS PrivateLink provides private connectivity between your VPC and AWS services or SaaS partners — without exposing traffic to the public internet. Traffic flows entirely over the AWS private network backbone.

Real-World Use Cases:

• Private access to SSM, Secrets Manager, ECR, or KMS from private subnets.
• ECS tasks pulling images from ECR without internet access.
• Accessing SaaS partners like Datadog, Snowflake, or Confluent Cloud privately.

# Terraform — Interface Endpoints
resource "aws_vpc_endpoint" "interface" {
  for_each            = local.interface_endpoints
  vpc_id              = aws_vpc.main.id
  service_name        = each.value
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true # Makes existing DNS names resolve privately
}

3. VPC Gateway Endpoints — S3 & DynamoDB

VPC Gateway Endpoints are a specific, older type of VPC endpoint that provide private access to Amazon S3 and Amazon DynamoDB only. Unlike Interface Endpoints, they work via route table entries and are **completely free**.

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Practical Security: Enforcement via S3 Bucket Policy

A common compliance requirement is to ensure data never leaves your network. You can enforce this by adding a condition to your S3 bucket policy that only allows access via your specific VPC Endpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Access-to-specific-VPCE-only",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-secure-bucket/*"],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1a2b3c4d"
        }
      }
    }
  ]
}

Case Study: ECS Fargate in a Private VPC

If you are running ECS Fargate in a VPC with no Internet Gateway (for maximum security), your tasks will fail to start because they can't reach the ECR APIs to pull images. You must create the following **Interface Endpoints**:

• com.amazonaws.[region].ecr.dkr (Docker image pull)
• com.amazonaws.[region].ecr.api (ECR API calls)
• com.amazonaws.[region].s3 (ECR uses S3 to store image layers)
• com.amazonaws.[region].logs (CloudWatch Logs for task logs)

# S3 Bucket Policy enforcing VPC Endpoint access
resource "aws_s3_bucket_policy" "enforce_vpce" {
  bucket = aws_s3_bucket.sensitive_data.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "Access-to-specific-VPCE-only"
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource  = ["${aws_s3_bucket.sensitive_data.arn}/*"]
      Condition = {
        StringNotEquals = {
          "aws:sourceVpce" = aws_vpc_endpoint.s3.id
        }
      }
    }]
  })
}

The Decision Framework

How do you choose? Follow this simple logic:

• Need general internet? → NAT Gateway.
• Need S3 or DynamoDB? → Gateway Endpoint (It's free!).
• Need other AWS services (ECR, SSM, etc)? → Interface Endpoint (PrivateLink).
• Need a supported SaaS partner? → PrivateLink.

Common Mistakes & Anti-Patterns

• Using NAT Gateway for S3: This is a major "bill shock" waiting to happen. S3 traffic is high-volume; routing it through a NAT Gateway is throwing money away.
• Forgetting endpoints in fully private accounts: Engineers consistently fail ECS Fargate deployments in private subnets because of this gap.

locals {
  required_endpoints = {
    ecr_api = "com.amazonaws.${var.region}.ecr.api"
    ecr_dkr = "com.amazonaws.${var.region}.ecr.dkr"
    logs    = "com.amazonaws.${var.region}.logs"
    ssm     = "com.amazonaws.${var.region}.ssm"
    # ... and others like secretsmanager, kms, sts
  }
}

resource "aws_vpc_endpoint" "interface" {
  for_each            = local.required_endpoints
  vpc_id              = aws_vpc.main.id
  service_name        = each.value
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  private_dns_enabled = true
}

• Forgetting private_dns_enabled: Without this, your application code needs to be modified to use the endpoint's unique DNS name. With it, the standard SDK resolution just works.
• No Endpoint Policies: By default, an endpoint allows all actions. Always scope your policies to the minimum required resources.