AWS S3 Gateway Endpoints in Terraform

“An application running in a VPC may write, build artefacts, read uploads, ship logs, restore backups, or fetch data from Amazon S3 many times each day.”

Each request follows a network path. That path deserves the same review as a subnet or NAT Gateway because it affects routing, access controls, failure behaviour, and sometimes the data-processing charges around the workload.

An S3 Gateway Endpoint adds an S3 route to selected VPC route tables. AWS then directs matching S3 traffic through the endpoint. Terraform gives that routing decision a visible, repeatable home in the infrastructure configuration.

This guide explains the pattern for workloads that access S3 from the VPC where the endpoint exists. It also covers the limits that matter before a team adopts it across environments.

Why the route to S3 matters

S3 often appears in an architecture diagram as a storage component. The workload path is still a network decision. A private EC2 instance may send a backup archive to S3, an ECS task may fetch an uploaded file, and a data job may read input objects for every run. If those workloads use a NAT path for S3, the route table and NAT capacity become part of the operating picture.

AWS states that a Gateway Endpoint lets a VPC access S3 without an internet gateway or NAT device for that S3 traffic. Gateway Endpoints carry no additional AWS charge. The wider cost effect depends on the previous route, the volume of S3 traffic, and the account's pricing model. Treat the endpoint as a route and access-design choice first. Evaluate cost effects from your own traffic and billing data alongside the full operating cost of the cloud platform.

What an S3 Gateway Endpoint does

An S3 Gateway Endpoint is a VPC endpoint associated with one or more route tables. AWS adds the service route when a route table is associated. Subnets that use those route tables send S3-destined traffic through the endpoint.

The route-table selection is the important implementation detail. Associate the tables used by the workload subnets that require S3. Review other tables before associating them. A shared VPC can have different subnet purposes and different access requirements.

The endpoint is regional. Create it in the same AWS Region as the S3 buckets the workload needs to reach. It serves resources inside its VPC through the associated route tables.

When the pattern fits

Gateway Endpoints fit applications and jobs running in the VPC that need S3 access in that Region. Common cases include:

• private application subnets that read and write user uploads;
• compute that sends logs or backup objects to S3; and
• data-processing workloads that consume or produce S3 objects.

The pattern also makes the S3 path visible in a Terraform plan. That helps reviewers see which route tables gain the route and lets teams apply the same decision across development, staging, and production environments.

Where the pattern stops

Gateway Endpoint connections stay within the VPC. AWS documents the VPN, Direct Connect, VPC peering, and Transit Gateway boundary. The endpoint also applies in its own Region.

Those boundaries change the design question for hybrid or multi-VPC networks. For traffic that must reach S3 through an on-premises path or an interconnected VPC, evaluate an S3 Interface Endpoint and its private DNS design. Interface Endpoints have a different pricing and operating model, so capture that choice in the architecture decision record.

Create the endpoint with Terraform

The minimal resource needs the VPC ID, the regional S3 service name, the Gateway endpoint type, and the route table IDs. Those arguments follow the current aws_vpc_endpoint resource contract. This example chooses the private route table used by the application subnet.

data "aws_region" "current" {}

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.application.id
  service_name      = "com.amazonaws.${data.aws_region.current.region}.s3"
  vpc_endpoint_type = "Gateway"

  route_table_ids = [
    aws_route_table.application_private.id,
  ]

  tags = {
    Name = "application-s3-gateway-endpoint"
  }
}

This configuration deliberately keeps the policy outside the first example. The endpoint policy needs to match the buckets, S3 actions, principals, and AWS-managed services used by the environment. A copied restrictive policy can block logging, agent downloads, or workload recovery.

Run the normal Terraform review path in an account and Region that represent the target environment:

terraform fmt -check
terraform validate
terraform plan

The plan should show the endpoint and the intended route-table associations. Then test S3 operations from a workload subnet before rolling the change across environments.

Apply the pattern through the Das Meta VPC module

Das Meta's public dasmeta/vpc/aws module release v1.1.0 added S3 Gateway Endpoint support on Sep 10, 2026. The release source creates the endpoint by default, associates its public and private route tables, and exposes the endpoint ID. Set the input explicitly when the endpoint is an intended part of the environment contract:

module "network" {
  source  = "dasmeta/vpc/aws"
  version = "1.1.0"

  name = "application-network"
  cidr = "10.42.0.0/16"

  availability_zones = [
    "eu-central-1a",
    "eu-central-1b",
  ]

  private_subnets = [
    "10.42.1.0/24",
    "10.42.2.0/24",
  ]

  public_subnets = [
    "10.42.101.0/24",
    "10.42.102.0/24",
  ]

  enable_s3_gateway_endpoint = true
}

The v1.1.0 output s3_gateway_endpoint_id can be passed to a later configuration when that configuration needs to refer to the endpoint. Pin the version and review the plan. A module standardises an implementation, while the root configuration still owns the decision about VPC scope, route tables, policies, and rollout.

Key takeaways

• The route to S3 is an infrastructure decision. Logs, backups, uploads, static assets, and data jobs depend on the path workloads use to reach S3.
• Gateway Endpoints use VPC route tables. Associating selected route tables creates an S3 route for workloads in those subnets.
• The pattern has a clear scope. It fits workloads accessing S3 from the VPC and Region where the Gateway Endpoint exists.
• Architecture still needs review. Endpoint policies, bucket policies, route tables, DNS, and connection behaviour require a pre-rollout check.
• Terraform makes the pattern repeatable. A tested module helps teams apply the same networking decision across environments.

For related operating context, browse the Das Meta cloud infrastructure guides.