Global Accelerator: Client IP Preservation, and What It Takes Out of the Path

Global Accelerator gets introduced as two things: static anycast addresses, and a shorter path to your application over the AWS backbone. Both are true and neither is the part that changes your design.

The consequential setting is client IP address preservation. It decides what your targets see as the source, which means it decides what your security groups have to permit — the subject lesson one works through for load balancers. Global Accelerator sits in front of those load balancers and adds its own copy of the question, with a different set of answers, three different defaults, and a side effect on what else is in the path.

One option, three different defaults#

There is no single default. There is a default per endpoint type, and two endpoint types where the option is not yours at all.

From the guidelines and restrictions and the endpoint list. Two rows deserve calling out.

The two load balancer types default opposite ways. An internet-facing Application Load Balancer arrives with preservation on; a Network Load Balancer with security groups arrives with it off. Same accelerator, same console screen, opposite starting state — so "we enabled it on the accelerator" is not a statement about what your targets are seeing.

A Network Load Balancer without security groups cannot do it at all. Security groups on a Network Load Balancer can only be attached at creation, so this is not a setting you go and switch on. It is a replacement load balancer.

Unusually, the console and the CLI agree here. The documentation states the same defaults for both paths, which is worth noting only because the more common shape of this problem is a console default that the API does not share.

Enabling it takes controls out of the path#

This is the part that does not appear in any introduction to the service, and it is the reason to read the guidelines page before enabling anything.

Read that against what the option is usually enabled for. Teams turn on preservation to get real client addresses into access logs, rate limiters, and security group rules — a security and observability improvement. The same change removes three enforcement points from the path. Nothing fails, nothing alarms, and an inspection appliance that was covering this traffic yesterday is now being paid to watch an empty path.

The relationship to lesson one's inspection note is worth holding onto: there, inserting a Gateway Load Balancer endpoint between a load balancer and its targets costs you preservation. Here, enabling preservation costs you the inspection. The two features are in tension from both directions, and in neither direction does the tooling say so.

The control that survives is the security group. That is where to put the rule.

Two pages of the same guide disagree about network ACLs#

The claim above has a direct contradiction inside the same documentation set, and since the answer changes whether a subnet-level deny is doing anything, it is worth stating rather than smoothing over.

Both are current pages of the Global Accelerator developer guide. They are not describing different features or different endpoint types. They are describing the same traffic, and one says a control applies while the other says it does not.

Global Accelerator puts network interfaces in your subnets#

Preservation is not free of footprint. To deliver traffic with the client address intact, Global Accelerator creates elastic network interfaces in your account — one for each subnet that contains an endpoint interface fronted by an accelerator.

The allocation rules are worth knowing before an accelerator fails to come up:

• One interface per subnet, not per endpoint. A load balancer in two subnets produces two.
• Interfaces are reused across accelerators. Two accelerators fronting two load balancers that share a subnet get one interface in that subnet, delivering traffic for both.
• Each one needs at least one free address in the subnet. An accelerator can therefore fail on a subnet with no headroom, which is a reason to care about the sizing discussed in subnet tiering.
• When no endpoint needs an interface any more, Global Accelerator deletes it.

Alongside them, Global Accelerator creates one security group per VPC, shared by every interface it owns in that VPC regardless of subnet. Two things follow, and they pull in opposite directions:

• You may reference that security group as the source in security groups you maintain. That is the clean way to permit accelerator traffic without naming addresses.
• You must not edit it. AWS states that modifying those rules can make the endpoint unhealthy, and that the remedy is to contact Support. It is a resource in your account that you can change and should treat as read-only.

Internet traffic arriving in a private subnet#

An internal Application Load Balancer or an EC2 instance endpoint has preservation permanently on, and the consequence is structural rather than cosmetic: adding one lets internet traffic reach a target in a private subnet, with no internet gateway route involved.

The subnet is private by the usual definition — its route table has no entry for an internet gateway — and internet clients still reach the instance, because the accelerator's own interface delivers the traffic inside the VPC. Drawn because the tier label and the route table both say this target is unreachable from the internet and they are both wrong once the endpoint is registered. AWS describes this as a deliberate feature for reaching private subnets; the point here is that a reader auditing the route table will not find the path.

AWS presents this as a feature, and it is one — it removes a public subnet and a load balancer from some designs. It also means "the subnet has no internet gateway route" has stopped being sufficient evidence that a target is not internet-reachable. Anyone auditing exposure from route tables alone will miss it.

Switching it on is a migration, not a toggle#

For endpoints where preservation is adjustable, the documented way to adopt it is not to flip the setting. AWS recommends adding a duplicate endpoint with preservation enabled, pointed at the same backends, and then shifting traffic by adjusting endpoint weights until the old one is drained.

The reason is the section above: turning preservation on changes what your targets see as the source, and therefore whether your security group rules still match. A toggle would move every connection at once onto a source address your rules may not permit. The weight-based transition exists so that failure is partial and reversible.

The same applies in the other direction — an Elastic IP endpoint cannot preserve the client address, so moving to preservation means adding an EC2 instance endpoint and shifting weight onto it. In both cases the work is a migration with a rollback, which is a different-sized piece of work from what "enable client IP preservation" sounds like.

Cost, and the word provisioned#

Global Accelerator has a cost shape worth internalising, because one word in it catches people.

The fixed fee applies to every accelerator that is provisioned, and AWS is explicit that this means enabled or disabled. Disabling an accelerator stops it serving traffic and does not stop the bill — roughly $18 a month for something switched off. The only action that stops the charge is deleting it.

Two smaller details. DT-Premium is charged on the dominant direction rather than both, recomputed hourly, so for a normal request-response application you are billed on egress and the inbound request volume is free. And it is in addition to the standard data transfer you already pay for the endpoint, not instead of it.

What to instrument#

• Accelerator count against what you think you have. Given that a disabled accelerator bills at the same rate as a live one, an inventory check has a direct cost consequence here that it does not have for most resources.
• Whether preservation is on, per endpoint, as a tracked fact. It defaults three different ways and is immutable on two endpoint types, so it is not safely inferable from the accelerator's configuration alone.
• Free addresses per subnet holding an endpoint. The accelerator needs one per subnet, and the failure lands at accelerator creation rather than at deploy time.
• Health of endpoints after any security group change. The interfaces Global Accelerator owns carry a security group you are not supposed to edit; an endpoint going unhealthy shortly after a security group change in that VPC is the signal that something touched it.

Next#

Lesson one is the load balancer half of this question and is worth reading first if you have not — the accelerator adds a layer in front of the behaviour described there rather than replacing it. Target health and zonal distribution covers how a Network Load Balancer withdraws a zone, which is the mechanism an accelerator's endpoint weights sit on top of.

Lab 06 is the closest thing to rehearsing this: an internal Network Load Balancer whose target reports healthy through an entire outage, where the whole diagnosis turns on reading the source address on arrival. That reading skill is the one this lesson depends on, and it is cheaper to acquire there than in front of an accelerator.