A Comprehensive Guide on AWS Gateway Endpoint

Summary:

• AWS gateway endpoints provide free, private connectivity from your VPC to Amazon S3 and DynamoDB. Traffic remains on the AWS network and does not require an Internet Gateway or NAT Gateway.
• Unlike interface endpoints that use Elastic Network Interfaces, gateway endpoints operate through route table entries and prefix lists, offering unlimited throughput with zero hourly or data processing charges.
• Organizations often achieve significant networking cost reductions by routing S3 and DynamoDB traffic through gateway endpoints instead of NAT gateways.
• Proper endpoint policy configuration, dual-stack IPv6 support (where available), and strategic route table associations are essential for secure, modern implementations.

Every gigabyte of data flowing from your private subnet to Amazon S3 through a NAT gateway costs you money twice. You pay once for the NAT gateway’s hourly charge and again for its per-gigabyte processing fee. For organizations moving terabytes monthly, this architectural choice can silently drain budgets while adding latency and creating unnecessary failure points.

AWS gateway endpoints eliminate this entire cost category while simultaneously improving security posture by keeping traffic entirely within the AWS network backbone. Understanding when and how to deploy them has become a fundamental skill for cloud architects. Yet many teams still route S3 and DynamoDB traffic through expensive, unnecessary intermediaries.

What is a gateway VPC endpoint

A gateway VPC endpoint is a horizontally scaled, redundant VPC component that enables private connectivity between your VPC and supported AWS services. It does not require an internet gateway, NAT device, VPN connection, or AWS Direct Connect. Unlike interface endpoints that provision elastic network interfaces within your subnets, gateway endpoints function as route targets specified in your route tables.

When traffic destined for a supported service matches the prefix list associated with the gateway endpoint, AWS routes that traffic directly through its internal network fabric rather than through the public internet.

The architectural distinction matters significantly for both cost and performance. Gateway endpoints exist at the VPC level rather than the subnet level, meaning a single endpoint can serve all subnets within a VPC that have appropriate route table associations. AWS manages the underlying infrastructure entirely, automatically scaling to handle whatever throughput your applications require.

There are no bandwidth constraints, no hourly charges, and no per-gigabyte data processing fees. This makes gateway endpoints fundamentally different from nearly every other networking component in AWS, which typically charges based on time, data volume, or both.

Supported services for gateway endpoints

AWS currently supports gateway endpoints for exactly two services: Amazon S3 and Amazon DynamoDB. This limited scope is intentional and reflects the unique architectural requirements these services share. Both S3 and DynamoDB are regional services with public endpoints that handle massive request volumes across millions of customers. The gateway endpoint architecture leverages prefix lists that AWS maintains, containing the IP address ranges for these services within each region.

The restriction to only two services often surprises engineers who expect broader coverage. However, AWS addresses other services through interface endpoints powered by AWS PrivateLink, which use a fundamentally different mechanism involving elastic network interfaces and private IP addresses within your subnets. The following services and their endpoint types clarify this distinction:

• Amazon S3: Supports both gateway endpoints (free, route-based) and interface endpoints powered by AWS PrivateLink (charged, ENI-based)
• Amazon DynamoDB: Supports only gateway endpoints with no interface endpoint option
• All other AWS services: For private connectivity, most other AWS services use interface endpoints powered by AWS PrivateLink.

This dual-option availability for S3 creates strategic decisions that architects must navigate carefully, particularly when cross-region access or on-premises connectivity requirements enter the picture. The routing mechanics of gateway endpoints provide the foundation for making these decisions intelligently.

How gateway endpoints work

Gateway endpoints operate through a coordination of three AWS components: the endpoint itself, route table entries, and managed prefix lists. When you create a gateway endpoint, AWS generates a prefix list identifier (formatted as pl-xxxxxxxx) that represents the current IP address ranges for the target service in your region.

You then associate this endpoint with one or more route tables, which automatically adds entries pointing traffic for those IP ranges through the endpoint. This route-based approach means no changes to your application code, DNS configuration, or security group rules are required for basic functionality.

Route table configuration and prefix lists

The prefix list abstraction solves a critical operational challenge. AWS service IP ranges change frequently as capacity expands across availability zones and regions. Rather than requiring customers to manually track and update these ranges, AWS maintains the prefix lists automatically. When you reference a prefix list in a route table or security group, AWS resolves it to the current set of CIDR blocks at evaluation time. This dynamic resolution ensures your routing remains accurate without manual intervention.

Each route table associated with a gateway endpoint receives an entry that cannot be manually modified or deleted while the association exists. The entry specifies the prefix list as the destination and the endpoint as the target. Consider the following route table structure after gateway endpoint association:

DNS resolution and dual-stack IPv6 support

Gateway endpoints do not modify DNS resolution for the services they support. Your applications continue resolving s3.amazonaws.com or dynamodb.amazonaws.com to public IP addresses. The routing layer handles the redirection. When your instance attempts to reach those public IPs, the route table intercepts the traffic and directs it through the gateway endpoint instead of toward the internet gateway or NAT gateway. This transparent interception means existing applications work without modification.

Gateway endpoints support IPv4, IPv6, and dual-stack configurations in regions where the feature is available. When configuring a gateway endpoint, you can specify the IP address type as ipv4, ipv6, or dualstack. For organizations modernizing their network architecture to support IPv6, this eliminates a previous limitation that forced IPv6 traffic through alternative paths. The DNS record IP type setting controls which address family resolves when applications query service endpoints, enabling gradual IPv6 migration strategies.

Gateway endpoints versus interface endpoints

The choice between gateway and interface endpoints involves trade-offs across cost, functionality, and architectural flexibility. Gateway endpoints excel in simplicity and cost elimination but support only S3 and DynamoDB with region-local access. Interface endpoints provide broader service coverage and cross-region capabilities but introduce hourly charges and data processing fees. Understanding these differences prevents both over-engineering simple use cases and under-serving complex requirements.

Architectural differences drive most decision criteria. Gateway endpoints operate at the routing layer without consuming IP addresses in your subnets. Interface endpoints provision elastic network interfaces that occupy private IPs and can be targeted by security groups. This distinction affects how you control access. Gateway endpoints rely on endpoint policies and route table associations, whereas interface endpoints add security group rules as an additional control plane. The following comparison highlights key differentiators:

Pricing and cost comparison for 2026

Gateway endpoints remain completely free in 2026, with no hourly charges, data processing fees, or bandwidth limitations. This pricing model has remained unchanged since their introduction, making them one of the few AWS networking components with zero direct cost. The economic impact becomes dramatic when compared against NAT gateway pricing, which, using typical US-region pricing, charges approximately $0.045 per hour plus $0.045 per gigabyte processed. Organizations routinely discover that S3 data transfer through NAT gateways represents a significant portion of their monthly AWS bills.

Consider the cost implications across different data transfer volumes. A workload transferring 100 GB monthly to S3 through a NAT gateway incurs approximately $37 in combined hourly and processing charges. At 1 TB monthly, this grows to approximately $78. At 10 TB monthly, the NAT gateway costs approach $483. Replacing this path with a gateway endpoint reduces these specific charges to zero while simultaneously reducing latency and improving reliability. The following table illustrates monthly cost comparisons:

Security and endpoint policies

VPC endpoint policies provide resource-based access control for gateway endpoints, enabling you to restrict which principals can access which resources through the endpoint. By default, gateway endpoints allow full access to the associated service, meaning any IAM principal with appropriate permissions can use the endpoint to reach any S3 bucket or DynamoDB table.

Implementing restrictive endpoint policies adds defense-in-depth by limiting access regardless of IAM permissions. This prevents data exfiltration scenarios where compromised credentials attempt to access unauthorized resources.

Endpoint policies use the same JSON syntax as other IAM policies but evaluate differently. The policy attached to a gateway endpoint acts as a boundary. Even if an IAM policy grants access to a resource, the request fails if the endpoint policy denies it. This creates a powerful control point for enforcing organizational boundaries. A common pattern restricts the endpoint to accessing only buckets owned by your organization:

1. Identify your AWS Organization ID: Retrieve this from AWS Organizations or your account settings
2. Construct a condition key: Use aws:ResourceOrgID to match resources belonging to your organization
3. Apply the policy: Attach it during endpoint creation or modify an existing endpoint

Implementation guide

Creating a gateway endpoint requires minimal configuration. Specify the VPC, the service, and the route tables to associate. AWS handles provisioning instantly with no deployment delays or capacity planning. The implementation approach varies by tooling preference, but all methods produce identical results. The following sections demonstrate creation through the AWS Console, CLI, and Terraform, covering the most common operational scenarios.

AWS Console implementation

The console workflow provides visual confirmation of each configuration choice. Navigate to the VPC Dashboard, select Endpoints from the left navigation, and click Create Endpoint. Select the gateway endpoint type, choose your target service (S3 or DynamoDB), select the VPC, and check the route tables that should receive the endpoint association. The console immediately displays the prefix list that will be added to each selected route table, allowing verification before creation.

AWS CLI implementation

Command-line creation suits automation scripts and CI/CD pipelines. The following command creates an S3 gateway endpoint and associates it with a specific route table:

aws ec2 create-vpc-endpoint --vpc-id vpc-0123456789abcdef0 --service-name com.amazonaws.us-east-1.s3 --route-table-ids rtb-0123456789abcdef0 --vpc-endpoint-type Gateway

The command returns the endpoint ID and confirms the route table associations. You can verify the route table entries using aws ec2 describe-route-tables and filtering for the prefix list destination.

Terraform implementation

Infrastructure as code deployments benefit from Terraform’s declarative syntax and state management. The aws_vpc_endpoint resource handles gateway endpoint creation with explicit route table associations:

resource "aws_vpc_endpoint" "s3" {
   vpc_id       = aws_vpc.main.id
   service_name = "com.amazonaws.us-east-1.s3"
   vpc_endpoint_type = "Gateway"
   route_table_ids = [aws_route_table.private.id]
 }

Limitations and best practices

Gateway endpoints carry inherent limitations that shape architectural decisions. They support only S3 and DynamoDB, cannot span regions, and provide no mechanism for on-premises access without additional proxy infrastructure. Traffic must originate from within the VPC. Resources in peered VPCs or connected through Transit Gateway cannot use another VPC’s gateway endpoint. These constraints are architectural, not configuration oversights, and stem from how gateway endpoints integrate with the VPC routing fabric.

Best practices for gateway endpoint deployment address both operational efficiency and security posture:

• Deploy in every VPC: Gateway endpoints cost nothing and provide immediate benefits. There is no reason to omit them from any VPC that accesses S3 or DynamoDB.
• Associate with all private route tables: Ensure every subnet that might access supported services routes through the endpoint rather than through NAT gateways.
• Implement restrictive endpoint policies: Default full-access policies create data exfiltration risks. Scope access to specific buckets or tables.
• Monitor with VPC Flow Logs: Flow logs capture traffic metadata for endpoint connections, enabling security analysis and troubleshooting.
• Plan for dual-stack: If IPv6 adoption is on your roadmap, configure endpoints with dualstack IP type from the start.

Conclusion

AWS gateway endpoints reduce cost, improve security, and simplify operations simultaneously. By routing S3 and DynamoDB traffic through AWS’s internal network rather than through NAT gateways or the public internet, organizations eliminate per-gigabyte processing charges while keeping sensitive data off public networks. The implementation requires minimal effort, whether through console clicks, CLI commands, or infrastructure as code, yet delivers immediate and measurable benefits.

The strategic value extends beyond direct cost savings. Gateway endpoints reduce attack surface by eliminating internet exposure for storage and database traffic. They improve reliability by removing NAT gateway as a potential failure point. They simplify compliance by keeping data within AWS’s network boundary.

As data volumes continue growing and security requirements tighten, gateway endpoints transition from optimization to necessity. Every VPC accessing S3 or DynamoDB should include gateway endpoints as foundational infrastructure, configured with restrictive policies and comprehensive route table associations from day one.