Interface Endpoint vs Gateway Endpoint in AWS Explained

Summary:

• Interface endpoints use Elastic Network Interfaces (ENIs) with private IPs inside your VPC, while gateway endpoints modify route tables to direct traffic to S3 or DynamoDB without additional network interfaces.
• With the introduction of cross-region PrivateLink connectivity (initially launched in late 2024 and expanded in 2025), interface endpoints can now connect to supported services across regions without traversing the public internet.
• Gateway endpoints remain free but support only S3 and DynamoDB, whereas Interface endpoints incur hourly and data processing charges and support many AWS services as well as third-party SaaS integrations through AWS PrivateLink.
• Enterprise architects must weigh cost, security controls, DNS configuration complexity, and multi-region requirements when selecting the appropriate endpoint type for production workloads.

When your application running inside a VPC needs to reach AWS services like S3 or DynamoDB, the traffic path you choose determines your security posture, operational costs, and architectural flexibility for years to come. The decision between interface endpoint vs gateway endpoint in AWS is not merely a checkbox exercise during infrastructure setup. It represents a foundational architectural choice that affects network isolation, compliance boundaries, and your ability to scale across regions. With the introduction and expansion of cross-region PrivateLink support throughout 2024 and 2025, the calculus has shifted significantly, making this comparison more nuanced than ever before.

The following diagram illustrates the fundamental architectural difference between how interface and gateway endpoints route traffic from your VPC to AWS services.

Understanding VPC endpoint types and their core mechanisms

VPC endpoints enable private connectivity between your Virtual Private Cloud and supported AWS services without requiring traffic to traverse the public internet. This private connectivity removes the need for NAT gateways, internet gateways, or VPN connections when accessing supported services and reduces exposure to the public internet. AWS provides two distinct endpoint types, each engineered for different use cases and operational requirements. Understanding their underlying mechanisms is essential before evaluating which fits your architecture.

Gateway endpoints function by inserting entries into your VPC route tables that direct traffic destined for specific AWS services through a gateway managed by AWS. These endpoints use prefix lists, which are collections of CIDR blocks representing the IP ranges of the target service. When you create a gateway endpoint for S3, AWS automatically maintains the prefix list as the service’s underlying IP ranges change. Your route tables reference this prefix list, ensuring traffic flows privately without manual IP management.

Interface endpoints operate through an entirely different mechanism. When you provision an interface endpoint, AWS creates one or more Elastic Network Interfaces (ENIs) in subnets you specify. Each ENI receives a private IP address from your subnet’s CIDR range, making the service accessible through private IP addresses within your VPC. Traffic flows through AWS PrivateLink, a service that provides private connectivity at scale. This ENI-based approach enables security group attachment, VPC Flow Logs integration, and DNS-based service discovery.

How DNS resolution differs between endpoint types

The DNS behavior of each endpoint type creates distinct operational patterns that architects must understand. Gateway endpoints do not modify DNS resolution. When your application resolves s3.amazonaws.com, it receives public IP addresses. However, because your route table contains entries for the S3 prefix list, traffic destined for those IPs routes through the gateway endpoint rather than the internet gateway. This transparent routing requires no application changes.

Interface endpoints introduce private DNS capabilities that fundamentally change name resolution. When you enable private DNS for an interface endpoint, AWS creates a private hosted zone that overrides the public DNS for that service within your VPC. Applications resolving dynamodb.us-east-1.amazonaws.com receive the private IP addresses of your ENIs rather than public addresses. This behavior requires the VPC to have DNS hostnames and DNS resolution enabled.

Consider the following key differences in DNS behavior:

• Gateway endpoints: No DNS changes. Routing handled entirely through route table prefix list entries.
• Interface endpoints without private DNS: Accessible via endpoint-specific regional and zonal DNS names only.
• Interface endpoints with private DNS: Service’s default DNS name resolves to private ENI IP addresses within the VPC.

With DNS mechanics clarified, the next critical consideration is understanding which services each endpoint type actually supports.

Service support and the cross-region PrivateLink expansion

The service coverage gap between gateway and interface endpoints is substantial and continues to widen. Gateway endpoints support exactly two services: Amazon S3 and Amazon DynamoDB. This limitation exists because gateway endpoints rely on route table mechanics that work only with services having stable, well-defined IP prefix lists. AWS has not expanded gateway endpoint support since adding DynamoDB in 2017, and there are no indications of future expansion.

Interface endpoints, powered by AWS PrivateLink, support over 100 AWS services including EC2, Lambda, Secrets Manager, Systems Manager, CloudWatch, and many others. Beyond AWS services, interface endpoints enable private connectivity to third-party SaaS applications available through the AWS Marketplace. This extensibility makes interface endpoints the only viable option for organizations requiring private access to the broader AWS ecosystem.

The following diagram shows the service coverage landscape for both endpoint types as of 2025.

Cross-region PrivateLink and the November 2025 paradigm shift

On November 19, 2025, AWS announced cross-region connectivity for AWS PrivateLink, fundamentally expanding interface endpoint capabilities. Previously, interface endpoints could only connect to services within the same AWS region. This limitation forced architects to deploy redundant infrastructure or accept internet traversal for cross-region service access. The new cross-region PrivateLink feature eliminates this constraint.

With cross-region interface endpoints, a workload in us-east-1 can privately access an AWS service endpoint in eu-west-1 without traffic leaving the AWS network. This capability enables several previously difficult architectures:

1. Centralized security services: Deploy Secrets Manager or Systems Manager in a single region while providing private access from workloads globally.
2. Data residency compliance: Access region-specific services from centralized management planes without internet exposure.
3. Disaster recovery: Maintain private connectivity to services in recovery regions without pre-provisioning duplicate endpoints.

Gateway endpoints do not support cross-region connectivity and likely never will due to their route-table-based architecture. Route tables operate at the VPC level and cannot direct traffic to resources outside the region. Organizations requiring private cross-region access to S3 must use interface endpoints, accepting the associated costs.

Understanding service support naturally leads to examining the cost implications of each endpoint type.

Cost structure and pricing comparison

The pricing models for gateway and interface endpoints differ dramatically, and this difference often drives architectural decisions in cost-sensitive environments. Gateway endpoints carry no hourly charges and no data processing fees. Traffic flowing through a gateway endpoint to S3 or DynamoDB incurs only the standard service charges for requests and storage. This zero-cost model makes gateway endpoints extremely attractive for high-throughput workloads.

Interface endpoints introduce multiple cost components. AWS charges an hourly fee for each ENI provisioned, currently $0.01 per availability zone per hour in most regions. Additionally, data processing charges apply at $0.01 per GB for the first petabyte. For cross-region interface endpoints, inter-region data transfer charges apply on top of the standard data processing fees, following AWS’s standard cross-region pricing.

For S3 and DynamoDB access specifically, the cost difference is stark. An organization transferring 100 TB monthly through a gateway endpoint pays nothing for the endpoint itself. The same traffic through an interface endpoint costs approximately $1,000 in data processing fees plus roughly $15 in hourly charges for a two-AZ deployment. This 100x cost difference explains why gateway endpoints remain the default recommendation for S3 and DynamoDB despite interface endpoint flexibility.

Cost considerations must be balanced against security requirements, which differ substantially between endpoint types.

Security controls and policy mechanisms

Both endpoint types support endpoint policies, which are IAM resource policies that control which principals can use the endpoint and which actions they can perform. However, the additional security controls available differ significantly. Gateway endpoints rely solely on endpoint policies and route table associations for access control. You cannot attach security groups to gateway endpoints because they do not create network interfaces in your VPC.

Interface endpoints provide layered security controls that satisfy enterprise compliance requirements:

• Security groups: Attach security groups to the ENIs, controlling inbound traffic by source IP, port, and protocol.
• Endpoint policies: Define which AWS principals and actions are permitted through the endpoint.
• VPC Flow Logs: Capture traffic metadata for the ENIs, enabling security monitoring and forensics.
• AWS PrivateLink: Ensures traffic never traverses the public internet, satisfying data isolation requirements.

The following diagram illustrates the security control layers available for interface endpoints compared to gateway endpoints.

Endpoint policies and IAM condition keys

Endpoint policies use standard IAM policy syntax but apply specifically to traffic flowing through the endpoint. A well-crafted endpoint policy can restrict access to specific S3 buckets, limit actions to read-only operations, or require specific IAM roles.

To govern cross-region connectivity, security teams must ensure the IAM principal creating the endpoint has the vpce:AllowMultiRegion action permitted. Furthermore, within the endpoint policy itself, you can use the ec2:VpceServiceRegion condition key to enforce granular control over exactly which destination regions are allowed.

Consider this endpoint policy example that restricts S3 access to a specific bucket while strictly denying any cross-region requests (forcing traffic to remain in us-east-1):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictToSpecificBucket",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-approved-bucket/*",
      "Condition": {
        "StringEquals": {
          "ec2:VpceServiceRegion": "us-east-1"
        }
      }
    }
  ]
}

With security mechanisms understood, architects can make informed decisions about implementation approaches for their specific requirements.

Implementation guidance for enterprise deployments

Deploying VPC endpoints in production requires careful planning around high availability, DNS configuration, and monitoring. For gateway endpoints, implementation is straightforward. Create the endpoint, associate it with route tables, and optionally attach an endpoint policy. The following AWS CLI command creates a gateway endpoint for S3:

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

Interface endpoints require additional configuration decisions. You must select subnets across multiple availability zones for high availability, configure security groups, and decide whether to enable private DNS. The following CloudFormation snippet demonstrates a production-ready interface endpoint configuration:

InterfaceEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: com.amazonaws.us-east-1.secretsmanager
    VpcEndpointType: Interface
    SubnetIds:
      - !Ref PrivateSubnetAZ1
      - !Ref PrivateSubnetAZ2
    SecurityGroupIds:
      - !Ref EndpointSecurityGroup
    PrivateDnsEnabled: true

Enterprise architecture patterns for 2026

Modern enterprise architectures increasingly combine both endpoint types to optimize for cost and capability. The recommended pattern uses gateway endpoints for all S3 and DynamoDB traffic while deploying interface endpoints for services requiring security group controls or cross-region access. This hybrid approach minimizes costs while maintaining security flexibility.

For multi-region deployments, consider these architectural best practices:

1. Centralize management plane services: Use cross-region interface endpoints to access centralized Secrets Manager, Systems Manager Parameter Store, and security services from workload regions.
2. Deploy gateway endpoints in every VPC: The zero-cost model means there is no reason to omit gateway endpoints for S3 and DynamoDB access.
3. Implement endpoint monitoring: Use CloudWatch metrics for PrivateLink to track bytes processed, active connections, and error rates.
4. Automate endpoint deployment: Include endpoint creation in your VPC provisioning automation using CloudFormation, Terraform, or AWS CDK.

Conclusion

The interface endpoint vs gateway endpoint decision ultimately depends on your specific service requirements, cost constraints, and security posture. Gateway endpoints remain the optimal choice for S3 and DynamoDB access due to their zero-cost model and operational simplicity. Interface endpoints provide the flexibility, security controls, and service breadth required for comprehensive private connectivity across the AWS ecosystem. The November 2025 cross-region PrivateLink expansion significantly enhances interface endpoint value for organizations operating across multiple AWS regions.

Looking ahead, AWS continues investing heavily in PrivateLink capabilities, suggesting interface endpoints will gain additional features and service support. Organizations should establish endpoint governance policies now, defining when each type should be used and how cross-region connectivity will be controlled. The architectural decisions made today around VPC endpoints will influence network security, operational costs, and compliance posture for years to come. Start with gateway endpoints for S3 and DynamoDB, layer in interface endpoints for everything else, and embrace cross-region PrivateLink where it simplifies your multi-region architecture.