AWS 168: AWS Global Accelerator
Why this lesson matters
Use anycast static IPs and the AWS global network for TCP or UDP applications that need endpoint health and regional traffic controls, not content caching.
Global Accelerator provides stable anycast IP entry points and carries TCP/UDP traffic over the AWS global network toward healthy Regional endpoints. It does not cache objects, terminate your application TLS by default, host DNS zones or replicate state.
What you will be able to do
By the end, you can:
- explain aws global accelerator in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Use anycast static IPs and the AWS global network for TCP or UDP applications that need endpoint health and regional traffic controls, not content caching. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Global Accelerator. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Global Accelerator. |
| Cost model | Accelerator hours, data transfer premium, endpoints, public IPv4, and workload resources can charge, so use supplied evidence only. |
| Safe rejection rule | Avoid choosing it as a cache or assuming it supplies application-layer WAF inspection. |
How the request flows
+------------------------+
| Client to anycast IP |
+------------------------+
|
v
+-------------------------------+
| AWS edge and global network |
+-------------------------------+
|
v
+-----------------------------+
| Healthy regional endpoint |
+-----------------------------+
|
v
+------------------------------------+
| Connection and failover evidence |
+------------------------------------+For AWS Global Accelerator, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Global Accelerator. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Global Accelerator. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Global Accelerator for non-cacheable TCP or UDP and static anycast entry points with regional endpoint steering. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid choosing it as a cache or assuming it supplies application-layer WAF inspection. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Standard accelerator path
A standard accelerator has two static IPv4 anycast addresses (and dual-stack/BYOIP options where supported), listeners with protocol/port ranges, Regional endpoint groups and endpoint weights. Supported endpoints include ALB, NLB, EC2 and Elastic IP with current restrictions. Clients enter at a nearby edge; AWS selects an endpoint group using client geography/health and traffic dial, then an endpoint using weight/health. Traffic dial applies to traffic already assigned to that Region, not a percentage of all global traffic.
For ALB/NLB endpoints, underlying load-balancer target health drives endpoint health; for EC2/EIP, configure accelerator checks. If every endpoint is unhealthy, current fail-open behavior can route to all endpoints, so an unhealthy mark is not a firewall. Endpoint weight zero/drain and traffic dial zero affect new traffic; existing TCP/UDP flows and application sessions need planned drain. Client affinity can reduce endpoint changes but is not durable session state.
Client IP preservation depends on endpoint type/configuration. When preserved, SG rules and applications see user addresses and must still admit Global Accelerator/control health paths correctly; EIP and some NLB configurations do not support it. Accelerator-created ENIs and SG references have cleanup dependencies. TLS termination/certificates remain at ALB/NLB/instance unless the application architecture terminates elsewhere.
Custom routing accelerators map listener IP/port combinations deterministically to EC2 destinations/ports in selected subnets for game/VoIP session placement. They do not health check or automatically fail over; the application decides assignment and allow/deny destinations. They are IPv4-specific under current docs and should not be selected for ordinary resilient endpoint routing.
Compare CloudFront for cacheable/dynamic HTTP edge proxy, Route 53 for DNS policy/failover and Global Accelerator for static-IP TCP/UDP acceleration. GA can front ALBs that themselves use CloudFront/WAF patterns only when each layer adds a proven requirement; WAF is not directly associated with every GA endpoint type. Monitor new/processed flows, bytes, unhealthy endpoints and application latency/errors. Price fixed accelerator-hours plus data transfer premium and endpoint/normal transfer resources.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open Global Accelerator, Accelerators, Listeners, Endpoint groups; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws globalaccelerator list-accelerators --region us-west-2 --query 'Accelerators[].{Name:Name,Status:Status,Enabled:Enabled,IPs:IpSets[0].IpAddresses}' --output tableExpected interpretation
An enabled accelerator proves global network configuration. Listener, endpoint group, endpoint health, traffic dial, client path, and application result require deeper evidence.
Practical work
Compare a global gaming TCP service and a cacheable website across Global Accelerator and CloudFront. Draw static IPs, listeners, endpoint groups, health, traffic dial, failover, TLS ownership, and cost.
Add enterprise client allow-list needing fixed IP and session-directed game servers. Test endpoint unhealthy, all unhealthy, traffic dial/weight drain, one Region loss, client-IP preservation SG mismatch, long-lived connection during shift, UDP fragmentation and custom-routing destination denial. Benchmark public-internet versus accelerator latency from multiple locations and define sample/confounders.
Diagnose this topic from its own evidence
Start with accelerator/listener enabled state, client destination/protocol/port, endpoint-group dial, endpoint weight/health and underlying LB targets. Connection timeout with healthy endpoint requires SG/NACL/route/listener/backend; wrong Region requires client location, dials and endpoint health; source-IP mismatch requires preservation support/config. Custom routing has no health failover - inspect deterministic mapping and destination allow state.
Cost and cleanup
Accelerator hours, data transfer premium, endpoints, public IPv4, and workload resources can charge, so use supplied evidence only.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Use anycast static IPs and the AWS global network for TCP or UDP applications that need endpoint health and regional traffic controls, not content caching.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Global Accelerator.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Global Accelerator.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid choosing it as a cache or assuming it supplies application-layer WAF inspection.
- Which cost dimensions and retained resources need an owner?
Expected direction: Accelerator hours, data transfer premium, endpoints, public IPv4, and workload resources can charge, so use supplied evidence only.
Lesson acceptance
Pass when the learner distinguishes standard/custom accelerators, calculates endpoint-group and endpoint selection, handles health/all-unhealthy/drain/client IP/TLS and prices fixed plus transfer cost. Fail if GA is called a cache/CDN/DNS service, custom routing is assumed to fail over, or traffic dial is interpreted as exact global request percentage.