TIL you can use VPC endpoints instead of endless network policy updates

June 2025

Today I learned that VPC endpoints can dramatically simplify network security management compared to constantly updating network policies for AWS service access.

The Problem

I was constantly handling requests to update network policies to allow access to sts endpoints for amazon Web Services (AWS) services. This was a never-ending cycle of:

Adding new IP ranges for sts endpoints which could be hundreds of IPs found in the AWS documentation (https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)

This led to:

Brittle network configurations
Having to update policies every time AWS changed their IP ranges
Complex rule management across multiple environments

The Solution: VPC Endpoints

VPC endpoints allow private connectivity to AWS services without going through the public internet, eliminating the need for constantly changing IP-based rules.

Visual Comparison: EKS Pod Assuming IAM Role via STS

WITHOUT VPC Endpoint (Complex Network Path):
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  Kubernetes Pod │    │  EKS Node SG    │    │   NAT Gateway   │
│                 │    │ Rules Required: │    │                 │
│ AssumeRole()    │───▶│ • 54.230.0.0/15 │───▶│  $0.045/GB      │
│ API Call        │    │ • 52.95.0.0/16  │    │  processed      │
│                 │    │ • 54.239.0.0/16 │    │                 │
└─────────────────┘    │ • 100+ more IPs │    └─────────────────┘
                       │ • Updated weekly│              │
                       └─────────────────┘              ▼
                                                ┌─────────────────┐
┌─────────────────┐                            │ Internet Gateway│
│   Network ACL   │                            │                 │
│ Same 100+ IPs   │                            │ Route to public │
│ Must be updated │                            │ sts.region.     │
│ when AWS changes│                            │ amazonaws.com   │
│ their ranges    │                            │                 │
└─────────────────┘                            └─────────────────┘

WITH VPC Endpoint (Direct Private Path):
┌─────────────────┐                            ┌─────────────────┐
│  Kubernetes Pod │                            │ STS VPC Endpoint│
│                 │                            │                 │
│ AssumeRole()    │───────────────────────────▶│ Interface Type  │
│ API Call        │     Direct VPC Routing     │                 │
│                 │                            │ DNS: sts.region.│
└─────────────────┘                            │ amazonaws.com   │
                                               └─────────────────┘
┌─────────────────┐                                      │
│  EKS Node SG    │                                      │
│ Rules Required: │                                      ▼
│ • Port 443 to   │                            ┌─────────────────┐
│   VPC Endpoint  │                            │   AWS STS       │
│ • That's it!    │                            │                 │
└─────────────────┘                            │ arn:aws:iam::   │
                                               │ account:role/   │
┌─────────────────┐                            │ EKSServiceRole  │
│   Network ACL   │                            │                 │
│ • Allow VPC     │                            │ Returns temp    │
│   CIDR range    │                            │ credentials     │
│ • Static rule   │                            └─────────────────┘
└─────────────────┘

Traffic Flow Comparison:
❌ Without: Pod → Node SG (100+ IPs) → NAT → IGW → Internet → STS
✅ With:    Pod → Node SG (1 rule) → VPC Endpoint → AWS Backbone → STS

Network Admin Pain Points:
❌ "Why is my pod getting 'connection timeout' to STS?"
❌ "AWS updated IP ranges again, all pods failing AssumeRole"  
❌ "NAT Gateway bill is $500/month just for STS calls"
✅ "VPC endpoint works, no more network tickets!"

Interface Endpoints (AWS PrivateLink)

For most AWS services, you can create interface endpoints:

# Create a VPC endpoint for STS
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-12345678 \
    --service-name com.amazonaws.us-west-2.sts \
    --subnet-ids subnet-12345678 \
    --security-group-ids sg-12345678

Gateway Endpoints

For S3 and DynamoDB, gateway endpoints are even simpler:

# Create a gateway endpoint for S3
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-12345678 \
    --service-name com.amazonaws.us-west-2.s3 \
    --route-table-ids rtb-12345678

Benefits

Static network rules - No more chasing IP ranges
Better security - Traffic never leaves AWS backbone
Lower latency - Direct private connectivity
Cost savings - Reduced NAT gateway usage
Simplified compliance - Easier to audit private-only access

Key Takeaway

Instead of managing complex network policies that break when AWS changes IP ranges, VPC endpoints provide stable, private connectivity that “just works.” Your security team will thank you, and your infrastructure will be more resilient.

The mental shift: Route traffic privately through AWS backbone instead of managing public internet access rules.