AWS Global Accelerator with Terraform

Your application can change across Regions without asking clients to chase a new entry point. This guide shows how to model that traffic layer with AWS Global Accelerator and Terraform.

If you are moving an application across Regions, changing load balancers, or planning a controlled rollout, traffic should not depend on a last-minute AWS Console change. This guide focuses on standard accelerators for applications behind Application Load Balancers, Network Load Balancers, Amazon EC2 instances, or Elastic IP addresses.

What AWS Global Accelerator does

AWS Global Accelerator provides static entry points for applications and routes client traffic to regional endpoints. A listener accepts traffic for a configured protocol and port range. Each listener is associated with one or more regional endpoint groups, and each group contains the application endpoints that can receive traffic.

For a standard accelerator, AWS considers user location, endpoint health, and configured endpoint weights when it selects an endpoint. The listener, endpoint-group, and endpoint model is the part you need to make explicit before a change reaches production.

This is not a blanket latency or availability promise. It gives your team one place to define ingress addresses, listener behavior, regional routing, and the controls used when the architecture changes.

When a standard accelerator fits

Use a standard accelerator when clients need fixed entry points and your application must route new connections to supported endpoints in one or more AWS Regions. It is useful when traffic controls belong in the same review as the rest of a release.

• Choose it for a stable application ingress layer with regional endpoint groups.
• Use endpoint groups when the team needs to manage regional rollout or maintenance decisions.
• Treat CloudFront, Route 53, and load balancers as separate architectural choices. They operate at different layers.

For AWS DevOps teams, the practical objective is a configuration that can be planned, reviewed, applied, and handed over without relying on undocumented AWS Console changes.

Model AWS Global Accelerator in Terraform

Terraform exposes this configuration through the aws_globalaccelerator_accelerator resource, including the accelerator name, address type, flow logs, and tags.

Core configuration choices

• Listeners define protocol, port ranges, and optional client affinity.
• Endpoint groups identify the AWS Region that receives traffic for a listener.
• Endpoints identify the ALB, NLB, Amazon EC2 instance, or Elastic IP address that should receive traffic.
• Health checks define how EC2 and Elastic IP endpoints are checked. For ALB and NLB endpoints, AWS uses the existing load balancer health checks.
• Port overrides map a listener port to a different endpoint port when the architecture requires it.

Use the Das Meta wrapper module

The Das Meta wrapper keeps the Global Accelerator configuration in one focused contract instead of spreading related controls through a hand-built setup. Released in terraform-aws-modules v3.1.0, it provides typed listeners and endpoint groups; validates ports, regional uniqueness, weights, traffic dials, health checks, and port overrides; and supports optional flow-log delivery to an existing Amazon S3 bucket.

Das Meta's global-accelerator wrapper module was released in v3.1.0. Its listener and endpoint-group contract makes traffic controls reviewable before deployment.

This minimal example follows the v3.1.0 input interface. Before production use, the module owner should confirm the source address, provider constraints, endpoint ARN values, and test coverage.

module "global_accelerator" {
  source = "git::https://github.com/dasmeta/terraform-aws-modules.git//modules/global-accelerator?ref=v3.1.0"

  name            = "public-api"
  ip_address_type = "IPV4"

  listeners = {
    https = {
      protocol    = "TCP"
      port_ranges = [{ from_port = 443, to_port = 443 }]
      endpoint_groups = {
        eu_central_1 = {
          endpoint_group_region   = "eu-central-1"
          traffic_dial_percentage = 100
          health_check = {
            protocol         = "HTTPS"
            port             = 443
            path             = "/health"
            interval_seconds = 30
            threshold_count  = 3
          }
          endpoints = [{ endpoint_id = var.eu_central_1_alb_arn, weight = 128 }]
        }
        us_east_1 = {
          endpoint_group_region = "us-east-1"
          endpoints = [{ endpoint_id = var.us_east_1_alb_arn, weight = 128 }]
        }
      }
    }
  }

  flow_logs = {
    enabled   = true
    s3_bucket = var.flow_logs_s3_bucket
    s3_prefix = "global-accelerator/public-api"
  }

  tags = { ManagedBy = "Terraform" }
}

The example intentionally omits application-specific networking, DNS, security-group, and deployment decisions. Those remain part of the surrounding architecture and require their own review.

Traffic dials and endpoint weights operate at different levels

Think in two levels. Endpoint weights distribute traffic between endpoints inside one endpoint group. Traffic dials control the percentage of traffic accepted by a regional endpoint group after traffic has already been directed there. They work together, but they do not solve the same problem.

At regional level, traffic_dial_percentage determines how much traffic an endpoint group accepts. Within that group, endpoint weight decides how traffic is distributed.

A simple rollout scenario

Say you are updating one Region. Reduce that Region's traffic dial for new connections, keep the change in version control, and check the expected new-connection path. In the receiving Region, use endpoint weights if you need to distribute traffic between two endpoints during a controlled test. Plan the rollback before the change window.

An update to traffic_dial_percentage affects new connections; it does not close existing ones. That distinction matters during a regional change window.

Safe implementation and verification checklist

• Confirm the client traffic pattern and endpoint types.
• Define regions, listener protocols, port ranges, and health-check behavior.
• Run terraform fmt, terraform validate, and terraform plan.
• Review the plan with application, platform, and security owners.
• Test new-connection routing and unhealthy-endpoint behavior.
• Use observability and flow logs after rollout.
• Document traffic-dial and endpoint-weight change ownership and rollback.

Conclusion

Do not start with the service. Start with the traffic decision: which entry points clients use, which Regions may receive new connections, who approves a change, and how you roll it back. AWS Global Accelerator and Terraform give that decision a repeatable form before it reaches production.

After the rollout, the same ownership question remains: Cloud Infrastructure Management is for teams that need day-to-day control, whereas Cloud Architecture Consulting helps teams map traffic and endpoint decisions before implementation.

Key Takeaways

• Standard accelerators receive two static IPv4 addresses by default, so your client entry point remains independent from the regional endpoint configuration behind it.
• Set traffic_dial_percentage from 0 to 100 for a regional endpoint group. It only affects traffic already directed to that group and gives you a scoped control for new connections.
• Endpoint weight accepts values from 0 to 255 and defaults to 128. Use it when the decision is between endpoints in one group, not between Regions.
• The wrapper's health-check inputs accept 10 or 30 second intervals and a threshold between 1 and 10. Treat those values as validation limits, not service promises.