How to Set Up VPC Endpoint for S3

Summary:

• Learn the critical differences between gateway and interface VPC endpoints for S3, including cost structures, IPv6 dual-stack support, and optimal use cases for each approach.
• Follow step-by-step instructions for setting up a VPC endpoint for S3 using both the AWS Console and CLI, with detailed DNS configuration options.
• Discover how to integrate S3 Access Points with VPC endpoints for simplified policy management and granular access control at scale.
• Understand the cost implications of each endpoint type with real traffic volume calculations to inform your architecture decisions.

Every byte of data traveling from your EC2 instances to Amazon S3 over the public internet represents a potential security vulnerability, an unnecessary data transfer cost, and a latency penalty that compounds at scale. Setting up a VPC endpoint for S3 eliminates these concerns by creating a private pathway that never touches the public internet, keeping your data within the AWS network backbone.

Whether you are architecting a compliance-sensitive healthcare application or optimizing a high-throughput data pipeline, understanding how to properly configure VPC endpoints for S3 is a foundational skill. It separates production-ready architectures from proof-of-concept deployments. This guide walks you through the complete process, from selecting the right endpoint type to implementing advanced access controls with S3 Access Points.

The following diagram illustrates the fundamental difference between S3 access patterns with and without a VPC endpoint configured.

Gateway endpoint vs interface endpoint for S3

AWS provides two distinct mechanisms for establishing private connectivity between your VPC and Amazon S3. Selecting the appropriate option requires understanding their architectural differences, cost models, and operational characteristics.

Gateway endpoints have existed since 2015 and operate at the routing layer by adding entries to your route tables that direct S3-bound traffic through a gateway managed by AWS. Interface endpoints, powered by AWS PrivateLink, create elastic network interfaces (ENIs) within your subnets that provide private IP addresses for S3 connectivity. The choice between these options affects everything from your monthly AWS bill to your ability to access S3 from on-premises networks.

Gateway endpoints remain the default recommendation for most workloads accessing S3 from within the same AWS Region. They incur no hourly charges and process unlimited data without per-gigabyte fees, making them economically attractive for high-volume data transfers. However, gateway endpoints only work for resources within the VPC and cannot extend connectivity to on-premises environments through AWS Direct Connect or VPN connections.

Interface endpoints address this limitation by providing routable private IP addresses that on-premises systems can reach. This capability comes with hourly and data processing charges.

IPv6 dual-stack support and DNS considerations

Recent updates to AWS PrivateLink have introduced IPv6 dual-stack support for interface endpoints, enabling workloads that require IPv6 connectivity to access S3 privately. When you create an interface endpoint with dual-stack enabled, AWS provisions both IPv4 and IPv6 addresses on the ENIs. The endpoint-specific DNS names resolve to both address types.

Gateway endpoints also support IPv6 through the dual-stack prefix list, which includes both IPv4 and IPv6 CIDR ranges for S3 in your route tables. This capability is particularly relevant for organizations modernizing their network infrastructure or operating in regions where IPv6 adoption is mandated.

DNS configuration represents one of the most significant operational differences between the two endpoint types. Interface endpoints offer private DNS functionality that, when enabled, overrides the default public DNS resolution for S3 endpoints within your VPC. This means existing applications using standard S3 endpoint URLs like s3.us-east-1.amazonaws.com automatically route through the interface endpoint without code changes.

Gateway endpoints do not modify DNS behavior. Applications continue resolving S3 endpoints to public IP addresses, but the route table entries ensure traffic flows through the gateway rather than the internet gateway.

Comparative analysis of endpoint characteristics

The following table summarizes the key differences between gateway and interface endpoints to help you make an informed architectural decision.

With these architectural distinctions clarified, the next step involves understanding the practical implementation process for each endpoint type.

Step-by-step setup using AWS Console and CLI

Implementing a VPC endpoint for S3 requires careful attention to subnet selection, route table associations, and policy configuration. The process differs significantly between gateway and interface endpoints. Both can be accomplished through the AWS Management Console or programmatically via the AWS CLI. This section provides detailed instructions for both approaches.

Creating a gateway endpoint through the console

Begin by navigating to the VPC Dashboard in the AWS Management Console and selecting Endpoints from the left navigation panel. Click Create endpoint to launch the configuration wizard. For the service category, select AWS services, then search for the S3 service in your target region.

You will see two options: one with “Gateway” type and another with “Interface” type. Select the gateway option, which appears as com.amazonaws.region.s3 with Type listed as Gateway.

The next configuration step requires selecting your target VPC and associating route tables. Every route table you select will receive automatic entries pointing S3 traffic to the gateway endpoint. For most deployments, you should associate all private subnet route tables to ensure consistent behavior across your infrastructure. The console displays the prefix list ID that will be added to each route table, which you can reference later for security group rules if needed.

CLI commands for gateway endpoint deployment

For automated deployments or infrastructure-as-code pipelines, the AWS CLI provides a streamlined approach to endpoint creation. The following command creates a gateway endpoint and associates it with specified route tables:

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

The command returns a JSON response containing the endpoint ID, state, and the route table associations. You can verify the route table entries using the describe-route-tables command, which will show new entries with the destination set to the S3 prefix list and the target pointing to your endpoint ID. Testing connectivity is straightforward using any S3 operation from an instance in an associated subnet.

The following diagram shows the route table configuration after gateway endpoint creation.

Interface endpoint configuration with private DNS

Creating an interface endpoint requires additional considerations around subnet placement and security group configuration. Unlike gateway endpoints, interface endpoints create ENIs that consume IP addresses from your subnet CIDR ranges and require security group rules to permit traffic.

Navigate to the same Endpoints section in the VPC console, but this time select the interface type for S3 when choosing the service.

The subnet selection determines where AWS provisions the ENIs. You should select subnets in multiple Availability Zones for high availability. Each selected subnet receives one ENI, and you must attach a security group that permits HTTPS traffic (port 443) from your application subnets.

The private DNS option, when enabled, creates a Route 53 private hosted zone that overrides public S3 DNS resolution within your VPC. Consider the following configuration checklist:

• Subnet selection: Choose subnets in at least two Availability Zones for redundancy
• Security groups: Allow inbound HTTPS (443) from application CIDR ranges
• Private DNS: Enable for transparent application integration without code changes
• IP address type: Select IPv4, IPv6, or Dualstack based on your network requirements

Testing endpoint connectivity

Validating your endpoint configuration ensures that traffic flows through the private pathway rather than the public internet. For gateway endpoints, you can verify routing by examining the route tables and testing S3 operations from instances without public IP addresses or NAT gateway access. The following CLI command tests basic connectivity:

aws s3 ls s3://your-bucket-name --region us-east-1

For interface endpoints, you can additionally verify DNS resolution to confirm private DNS is functioning correctly. The nslookup or dig commands should return private IP addresses from your VPC CIDR range rather than public AWS IP addresses.

If private DNS is not enabled, you must use the endpoint-specific DNS names in your application configuration. These follow the pattern bucket.vpce-0123456789abcdef0-ab1cd2ef.s3.us-east-1.vpce.amazonaws.com.

With endpoint connectivity established, the next consideration involves implementing fine-grained access controls through endpoint policies and S3 Access Points.

Integrating S3 Access Points with VPC endpoints

S3 Access Points provide a powerful mechanism for simplifying access management when multiple applications or teams share S3 buckets. When combined with VPC endpoints, Access Points enable you to create VPC-restricted entry points that only permit access from specific network locations.

This integration addresses a common challenge in enterprise environments where bucket policies become unwieldy as the number of access patterns grows. Each Access Point can have its own policy, and you can configure Access Points to only accept requests originating from a designated VPC.

Creating a VPC-restricted Access Point involves specifying the VPC ID during Access Point creation. Once configured, the Access Point rejects any requests that do not originate from the specified VPC, providing network-level isolation regardless of IAM permissions. This approach complements VPC endpoint policies by adding another layer of access control that operates at the S3 service level rather than the network level.

Configuring endpoint policies for Access Points

VPC endpoint policies control which S3 resources can be accessed through the endpoint, and they support Access Point ARNs alongside traditional bucket ARNs. A well-designed endpoint policy can use wildcard patterns to automatically permit access to new Access Points without policy updates. The following policy example demonstrates how to allow access to all Access Points owned by your account while restricting direct bucket access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessPointAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:us-east-1:123456789012:accesspoint/*",
        "arn:aws:s3:us-east-1:123456789012:accesspoint/*/object/*"
      ]
    }
  ]
}

Restricting bucket access to VPC endpoint traffic only

A common security requirement involves ensuring that S3 buckets only accept requests that traverse a VPC endpoint, blocking all public internet access even if IAM permissions would otherwise allow it. This configuration requires a bucket policy condition that checks the aws:sourceVpce condition key. The following policy denies all requests that do not originate from the specified VPC endpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonVPCEndpointAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

This policy pattern is essential for compliance frameworks that mandate private-only data access, such as HIPAA or PCI-DSS environments. You can extend the condition to include multiple VPC endpoints by using the StringNotEquals condition with an array of endpoint IDs.

Understanding the cost implications of your endpoint architecture helps optimize this configuration for both security and budget requirements.

Cost analysis and optimization strategies

The financial impact of VPC endpoint selection becomes significant at scale, particularly for organizations processing terabytes of data through S3 daily. Gateway endpoints provide unlimited data transfer at no additional cost beyond standard S3 request and storage charges. Interface endpoints incur both hourly charges for each ENI provisioned and per-gigabyte data processing fees that accumulate quickly under heavy workloads.

As of 2026, interface endpoint pricing in the US East (N. Virginia) region stands at $0.01 per hour per Availability Zone plus $0.01 per gigabyte of data processed for the first PB, $0.006 for the next 4 PB, and $0.004 for anything over 5 PB. For a deployment spanning three Availability Zones, the hourly cost alone reaches $0.03, translating to approximately $21.90 monthly before any data transfer. The following table illustrates cost projections across different traffic volumes:

Regional pricing variations

Interface endpoint pricing varies by AWS Region, with some regions charging premium rates due to infrastructure costs. Before deploying interface endpoints in regions outside US East, consult the AWS PrivateLink pricing page for current rates. Regions like São Paulo and Singapore historically carry higher per-hour and per-gigabyte charges that can significantly impact total cost of ownership for data-intensive workloads.

The cost analysis naturally leads to automation considerations, as manually managing endpoints across multiple accounts and regions becomes operationally burdensome.

Automating deployment with Terraform

Infrastructure-as-code tools like Terraform enable consistent, repeatable endpoint deployments across environments. The AWS provider for Terraform includes resources for both gateway and interface endpoints, supporting all configuration options available through the console and CLI. Automating endpoint creation ensures that development, staging, and production environments maintain identical network configurations.

The following Terraform configuration creates a gateway endpoint with associated route tables and a restrictive endpoint policy:

resource "aws_vpc_endpoint" "s3_gateway" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [aws_route_table.private.id]

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "AllowS3Access"
        Effect    = "Allow"
        Principal = "*"
        Action    = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
        Resource  = ["arn:aws:s3:::${var.bucket_name}", "arn:aws:s3:::${var.bucket_name}/*"]
      }
    ]
  })

  tags = {
    Name        = "s3-gateway-endpoint"
    Environment = var.environment
  }
}

For interface endpoints, the Terraform configuration requires additional resources for security groups and subnet associations. The aws_vpc_endpoint resource with vpc_endpoint_type = "Interface" accepts parameters for private DNS enablement, IP address type selection, and security group attachment. Organizations adopting GitOps practices can integrate these configurations into CI/CD pipelines that automatically apply endpoint changes through pull request workflows.

Conclusion

Establishing a VPC endpoint for S3 transforms your AWS architecture from a public-internet-dependent design to a secure, private connectivity model. This reduces the attack surface and eliminates data transfer costs through NAT gateways.

The choice between gateway and interface endpoints hinges on your specific requirements. Gateway endpoints serve the vast majority of use cases with zero additional cost. Interface endpoints unlock on-premises connectivity through Direct Connect at a predictable hourly and per-gigabyte rate. Combining these endpoints with S3 Access Points and restrictive bucket policies creates a defense-in-depth approach that satisfies even the most stringent compliance requirements.

AWS continues expanding PrivateLink capabilities with improved IPv6 support and cross-service integrations that will further simplify private connectivity architectures. Organizations should establish endpoint deployment patterns now, codified in Terraform or CloudFormation, to ensure consistent security postures as their AWS footprints grow. The investment in understanding VPC endpoint configuration pays dividends across every S3-dependent workload in your environment, from simple backup operations to petabyte-scale analytics pipelines.