VPC Endpoints for Private AWS Deployments: A Practical Guide

If your app talks to S3, DynamoDB, Secrets Manager, or ECR, a VPC endpoint lets that traffic stay inside AWS’s network instead of hair-pinning out through a NAT gateway and back. The payoff is two-fold: private subnets stop needing a route to the public internet just to reach AWS APIs, and you stop paying NAT data-processing charges (roughly $0.045/GB in us-east-1) on that traffic. There are two kinds — gateway endpoints (free, for S3 and DynamoDB) and interface endpoints (billed per hour plus per GB, for almost everything else). This post covers which to use where, what they cost, and how a private-by-default network actually comes together. If you want the managed context first, our AWS deployment guide walks through the model end to end.

The two endpoint types, and why the difference matters #

Gateway endpoints attach to a route table and cover exactly two services: S3 and DynamoDB. They cost nothing — no hourly charge, no per-GB fee. If your app reads and writes S3 from private subnets, adding a gateway endpoint is close to free money: traffic that would otherwise cross a NAT gateway now routes directly. There is no reason not to add one, and they’re the first move in almost any private topology.

Interface endpoints are different beasts. They’re backed by an elastic network interface (ENI) in each subnet you enable them in, powered by AWS PrivateLink, and they cost about $0.01 per hour per endpoint per Availability Zone plus ~$0.01/GB of data processed. Two AZs means two ENIs, which works out to roughly $14.60/month per endpoint before data. That adds up fast. Secrets Manager, ECR (which needs both ecr.api and ecr.dkr), CloudWatch Logs, STS, and SSM can easily be five or six endpoints. Across two AZs you’re looking at $85–100/month in fixed cost before a single byte moves.

So the honest trade-off is this: interface endpoints buy you privacy and remove the NAT dependency, but they are not automatically cheaper than a NAT gateway for low-traffic workloads. A single NAT gateway costs about $32/month plus data processing. If you only need occasional outbound API calls, one NAT gateway may be the cheaper and simpler choice. Interface endpoints win decisively when you have high AWS-API data volume, a hard compliance requirement to keep traffic private, or you’re eliminating the NAT gateway entirely.

What a private deployment needs to actually run #

The trap people fall into is enabling one or two endpoints, killing the NAT gateway, and then watching container pulls or log delivery fail. A truly private ECS or Fargate deployment needs a specific set of endpoints or nothing starts. Because completeness genuinely matters here, this is the one place a checklist earns its keep:

• Gateway endpoint for S3 — required for ECR image layers, which are stored in S3
• Interface endpoints for ecr.api and ecr.dkr — to authenticate and pull images
• Interface endpoint for CloudWatch Logs (logs) — or your container logs silently vanish
• Interface endpoint for Secrets Manager and/or SSM — to inject secrets at task start
• Interface endpoint for STS — for role assumption and credential validation

Miss any one of these and the failure mode is confusing: a task that pulls its image but can’t start, or starts but never emits a log line. Each interface endpoint also needs its own security group allowing HTTPS (port 443) from your task subnets, and ’Enable DNS name’ turned on so the standard AWS SDK endpoints resolve to the private ENI automatically. This is exactly the kind of tightly-scoped rule set that’s easy to get subtly wrong by hand — the same problem we dig into in our AWS network security baseline.

How Vylara fits into private networking #

Vylara connects to your repo through the GitHub App, and the Vylara agent analyzes your code to figure out which AWS services the app depends on — PostgreSQL via prisma, Redis via ioredis, S3 via aws-sdk, and so on. When you approve the plan, the first deploy provisions infrastructure in your own AWS account using a blue/green strategy, and the security groups it generates are derived from what your code actually reaches, not a permissive default. We wrote about why that produces tighter rules than most hand-written ones in security groups generated from your code.

One honest limit: Vylara is AWS-only for deploys today (GCP and Azure are on the roadmap), and it doesn’t hand you a menu of every VPC endpoint to toggle. What it does give you is visibility. After launch, the in-app infrastructure chat has read access to your network configuration — it can describe your VPC, security groups, and load balancer, read CloudWatch logs, and help diagnose why a service is returning 502 without you SSHing anywhere. When a private task fails because an endpoint is missing, that log context is what shortens the debugging loop from an afternoon to a few minutes.

A sane default before you go fully private #

For most startups, the pragmatic path is: add the free S3 and DynamoDB gateway endpoints immediately, keep a single NAT gateway for everything else while traffic is low, and only migrate to a full interface-endpoint topology when your NAT data-processing bill or a compliance line item justifies the ~$85+/month floor. Going private is a decision to make deliberately, not a default to reach for on day one. Endpoint policies — IAM-style documents attached to the endpoint — let you further restrict which buckets or secrets are reachable, and they’re worth adding once the endpoints exist. A minimal S3 endpoint policy locking access to one bucket looks like this:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-assets/*"
  }]
}

The broader point is that private networking is a set of trade-offs — cost, blast radius, operational complexity — not a switch you flip for a security checkbox. If you want the full picture of how these pieces sit together in a managed setup, our AWS pillar covers the deployment model in detail. Start with the free gateway endpoints, measure your NAT bill, and let the numbers tell you when the interface endpoints are worth it.