A Detailed Examination of Interface Endpoint vs Gateway Endpoint in AWS

Summary:

• Gateway endpoints provide free, route-table-based connectivity exclusively for Amazon S3 and DynamoDB, while interface endpoints leverage AWS PrivateLink with ENIs to support over 100 AWS services at a cost.
• Understanding the routing mechanics, DNS resolution patterns, and security model differences between these endpoint types is essential for designing secure, cost-effective VPC architectures.
• Recent AWS enhancements including IPv6 dual-stack support, cross-region PrivateLink capabilities, and private DNS only inbound endpoints expand the strategic options for modern hybrid and multi-region deployments.
• This guide provides implementation examples, cost analysis, and decision frameworks to help you select the right endpoint strategy for production workloads.

Every packet that leaves your VPC for an AWS service faces a critical routing decision. The choice between interface endpoint vs gateway endpoint determines whether that traffic traverses the public internet or stays within the AWS backbone network. This architectural decision impacts your security posture, operational costs, and network latency in ways that compound across thousands of daily API calls. For engineers architecting production workloads, mastering VPC endpoint strategies separates surface-level AWS knowledge from genuine infrastructure expertise.

AWS introduced VPC endpoints to solve a fundamental problem: how do you access AWS services privately without exposing traffic to the internet? The answer evolved into two distinct mechanisms with different trade-offs. Gateway endpoints arrived first, offering a simple route-table integration for S3 and DynamoDB. Interface endpoints followed, bringing the flexibility of AWS PrivateLink to dozens of additional services.

Understanding when to deploy each type requires examining their architectural foundations, cost structures, and operational characteristics.

Defining gateway endpoints and interface endpoints

Gateway endpoints function as route targets within your VPC route tables. They direct traffic destined for specific AWS service prefixes through a managed gateway rather than through an internet gateway or NAT device. When you create a gateway endpoint, AWS automatically manages a prefix list containing the IP ranges for the target service in that region. Your route tables reference this prefix list, and the VPC routing infrastructure handles the rest transparently. This approach requires no additional network interfaces, no IP address consumption from your subnets, and incurs no hourly or data processing charges.

Interface endpoints operate on a fundamentally different model. Each interface endpoint provisions one or more Elastic Network Interfaces (ENIs) in subnets you specify, with private IP addresses from your VPC CIDR range. These ENIs serve as entry points into AWS PrivateLink, a technology that creates private connectivity between your VPC and AWS services without exposing traffic to the public internet.

Traffic flows from your resources to the ENI, through PrivateLink, and into the target service. This architecture enables features impossible with gateway endpoints. These include security group attachment, VPC Flow Logs at the endpoint level, and connectivity to services beyond S3 and DynamoDB.

Services supported by each endpoint type

Gateway endpoints support exactly two services: Amazon S3 and Amazon DynamoDB. This limitation exists because gateway endpoints rely on prefix list routing, which works well for services with stable, well-defined IP ranges but becomes impractical for services with dynamic or distributed endpoints. AWS has maintained this constraint since gateway endpoints launched, and there are no announced plans to expand the supported service list.

Interface endpoints support over 100 AWS services and continue expanding with each AWS release cycle. The list includes:

• Compute services: EC2 API, Lambda, ECS, EKS
• Security services: Secrets Manager, Systems Manager, KMS, Security Hub
• Monitoring services: CloudWatch Logs, CloudWatch Metrics, X-Ray
• Database services: RDS API, Redshift API, and notably S3 (as an alternative to gateway endpoints)
• Networking services: API Gateway, Elastic Load Balancing API, Route 53 Resolver

The availability of interface endpoints for S3 creates an interesting architectural choice. You can access S3 through either endpoint type, each with distinct trade-offs that become significant at scale. Consider the following comparison to understand the full scope of differences between these endpoint mechanisms.

Cost analysis and pricing structures

Gateway endpoints carry no charges whatsoever. There is no hourly fee, no data processing fee, and no additional cost beyond standard S3 or DynamoDB request pricing. This zero-cost model makes gateway endpoints the default recommendation for S3 and DynamoDB access when their architectural constraints are acceptable. For workloads processing terabytes of S3 data daily, the cost savings compared to interface endpoints can reach thousands of dollars monthly.

Interface endpoints follow a two-component pricing model that requires careful capacity planning. First, you pay an hourly charge for each ENI provisioned, currently approximately $0.01 per AZ per hour in most regions. A highly available deployment spanning three AZs costs roughly $22 monthly before any data transfer. Second, you pay a data processing charge for each gigabyte processed through the endpoint, typically $0.01 per GB. For a workload processing 10 TB monthly through an interface endpoint, data processing charges alone reach $100.

The cost comparison becomes nuanced when factoring in NAT Gateway expenses. Without VPC endpoints, traffic to AWS services must traverse either the public internet (requiring an Internet Gateway and public IPs) or a NAT Gateway (for private subnets). NAT Gateway pricing includes both hourly charges and $0.045 per GB processed, making interface endpoints potentially cheaper than NAT for high-volume service API calls despite their own processing fees.

Routing architecture and traffic flow

Gateway endpoint routing integrates directly with VPC route tables through prefix lists. When you associate a gateway endpoint with a route table, AWS adds entries pointing the service’s prefix list to the endpoint as the target. For S3, this prefix list contains all IP ranges AWS uses for S3 in that region. Traffic matching these destinations routes through the gateway endpoint automatically, with no application-level changes required. The routing decision happens at the VPC infrastructure layer before packets leave your subnet.

The following AWS CLI command creates a gateway endpoint for S3 and associates it with a specific route table:

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

Interface endpoint routing relies entirely on DNS resolution rather than route table manipulation. When you create an interface endpoint, AWS generates endpoint-specific DNS names that resolve to the private IP addresses of the provisioned ENIs. Applications must use these DNS names, or you must enable private DNS to override the default public DNS resolution for the service. With private DNS enabled, the standard service endpoint (like ec2.us-east-1.amazonaws.com) resolves to your interface endpoint’s private IPs instead of public AWS IPs.

Route table configuration deep dive

Gateway endpoint route table associations require careful planning in complex VPC architectures. Each route table can associate with multiple gateway endpoints, but you must explicitly select which route tables receive the prefix list entries. Subnets using route tables without the gateway endpoint association will not benefit from private connectivity. Their traffic will follow the default route, typically through a NAT Gateway or Internet Gateway.

A common architectural mistake involves creating a gateway endpoint but forgetting to associate it with all relevant route tables. The following CloudFormation snippet demonstrates proper gateway endpoint configuration with multiple route table associations:

Resources:
  S3GatewayEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId: !Ref VPC
      ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
      VpcEndpointType: Gateway
      RouteTableIds:
        - !Ref PrivateRouteTableAZ1
        - !Ref PrivateRouteTableAZ2
        - !Ref PrivateRouteTableAZ3
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal: '*'
            Action: 's3:*'
            Resource: '*'

Security controls and access policies

Gateway endpoints support a single security mechanism called endpoint policies. These IAM-style policy documents control which principals can use the endpoint and which actions they can perform against the target service. Endpoint policies act as an additional authorization layer, evaluated alongside IAM policies and resource policies. A request must pass all applicable policy evaluations to succeed. You cannot attach security groups to gateway endpoints because they operate at the routing layer without dedicated network interfaces.

Interface endpoints provide layered security through both endpoint policies and security groups. The security group attached to an interface endpoint’s ENIs controls network-level access, specifying which source IP ranges and ports can reach the endpoint. This enables scenarios impossible with gateway endpoints:

• Subnet isolation: Allow only specific subnets to reach the Secrets Manager endpoint
• Port restrictions: Limit connectivity to HTTPS (443) only
• Logging granularity: VPC Flow Logs capture all traffic to and from the ENI

Private DNS configuration options

Interface endpoints offer sophisticated DNS configuration through the private DNS feature. When enabled, AWS creates a private hosted zone associated with your VPC that overrides public DNS resolution for the service endpoint. This means existing applications using standard AWS SDK configurations automatically route through the interface endpoint without code changes. The AWS PrivateLink DNS documentation details the resolution hierarchy.

AWS introduced private DNS only for inbound endpoints, addressing a specific hybrid connectivity scenario. This feature allows interface endpoints to provide private DNS resolution for resources connecting from on-premises networks through Direct Connect or VPN, without affecting DNS resolution for resources within the VPC itself. The configuration requires Route 53 Resolver inbound endpoints and careful DNS forwarding rules.

IPv6 and cross-region capabilities

IPv6 support for VPC endpoints has expanded significantly through recent AWS releases. Gateway endpoints now support dual-stack configurations for S3, allowing IPv6-enabled resources to access S3 through the gateway endpoint using IPv6 addresses. This capability, announced in November 2025, requires enabling dual-stack on the endpoint and ensuring your route tables include IPv6 prefix list entries. The gateway endpoints documentation provides current configuration guidance.

Interface endpoints support IPv6 through dual-stack ENI configurations for most services. When you create an interface endpoint with IPv6 enabled, the provisioned ENIs receive both IPv4 and IPv6 addresses. DNS resolution returns the appropriate address type based on the client’s query. This enables seamless IPv6 transition strategies where applications can gradually migrate to IPv6 while maintaining IPv4 compatibility.

Cross-region PrivateLink patterns

Gateway endpoints operate strictly within a single region. A gateway endpoint in us-east-1 cannot provide connectivity to S3 buckets in eu-west-1. Cross-region S3 access through gateway endpoints requires the traffic to exit through the gateway endpoint, reach S3 in the local region, and then S3 handles any cross-region replication or redirection internally.

Interface endpoints gained cross-region capabilities through AWS PrivateLink cross-region support, initially available for select services. This feature enables an interface endpoint in one region to connect to a service endpoint in another region, keeping traffic entirely within the AWS network. The primary use cases include:

1. Centralized security services: Access a Secrets Manager endpoint in a central security region from workload VPCs in multiple regions
2. Disaster recovery: Maintain connectivity to critical services during regional failover scenarios
3. Data residency compliance: Access services in specific regions to meet regulatory requirements while running workloads elsewhere

Limitations and strategic use cases

Gateway endpoints carry inherent limitations that shape their appropriate use cases. Beyond the S3 and DynamoDB service restriction, gateway endpoints do not support cross-region access. They cannot be accessed from on-premises networks through Direct Connect or VPN because traffic must originate from within the VPC. They also provide no mechanism for security group attachment. These constraints make gateway endpoints ideal for straightforward, high-volume S3 and DynamoDB access from EC2 instances and Lambda functions within the same region.

Interface endpoints introduce their own constraints despite greater flexibility. The cost structure makes them expensive for high-throughput data transfer scenarios. Each interface endpoint consumes IP addresses from your subnet CIDR ranges, potentially exhausting address space in tightly allocated VPCs. Additionally, interface endpoints require careful DNS configuration to ensure applications resolve to the endpoint rather than public service IPs.

Decision framework for endpoint selection

Selecting between interface endpoint vs gateway endpoint requires evaluating multiple factors against your specific requirements. The following decision process helps structure the analysis:

1. Service requirement: If you need private access to any service other than S3 or DynamoDB, interface endpoints are your only option
2. Cost sensitivity: For S3 and DynamoDB workloads processing large data volumes, gateway endpoints eliminate significant data processing costs
3. Security requirements: If security group controls or VPC Flow Logs at the endpoint level are mandatory, interface endpoints provide these capabilities
4. Hybrid connectivity: On-premises access to AWS services through Direct Connect requires interface endpoints
5. Cross-region needs: Cross-region private connectivity mandates interface endpoints with PrivateLink cross-region support

Many production architectures deploy both endpoint types strategically. A common pattern uses gateway endpoints for S3 data plane operations (high volume, cost sensitive) while deploying interface endpoints for S3 access from on-premises networks and for all other AWS service connectivity. This hybrid approach optimizes both cost and capability.

Conclusion

The interface endpoint vs gateway endpoint decision fundamentally shapes your VPC’s security architecture, operational costs, and connectivity capabilities. Gateway endpoints deliver zero-cost, route-table-based connectivity for S3 and DynamoDB, making them the default choice for high-volume data operations within a single region. Interface endpoints provide the flexibility of AWS PrivateLink, supporting over 100 services with security group controls, private DNS integration, and cross-region capabilities at the cost of hourly and data processing charges.

Modern AWS architectures increasingly combine both endpoint types strategically. Use gateway endpoints where their constraints are acceptable and cost savings are significant. Deploy interface endpoints for services beyond S3 and DynamoDB, for hybrid connectivity scenarios, and where security group controls are non-negotiable. The recent additions of IPv6 dual-stack support and cross-region PrivateLink expand the strategic options available, particularly for organizations operating globally or transitioning to IPv6.

As AWS continues expanding PrivateLink capabilities and potentially introducing new endpoint types, the core architectural principles remain constant. Minimize public internet exposure, optimize data transfer costs, and implement defense-in-depth security controls. Mastering VPC endpoint strategies positions you to design resilient, secure, and cost-effective cloud architectures that scale with organizational growth.