AWS Global Accelerator
Does ZopNight manage AWS Global Accelerator?
AWS Global Accelerator charges a fixed hourly fee for every accelerator from creation until deletion, plus a data transfer premium on traffic riding the AWS backbone. ZopNight discovers accelerators on the 6-hour cycle, attributes their spend through Cost Explorer or CUR 2.0, and recommends removing accelerators whose applications stopped receiving traffic.
Rules that fire on AWS Global Accelerator
No active rule family targets AWS Global Accelerator today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
AWS Global Accelerator provides static anycast IPs that route user traffic over the AWS backbone, billed per accelerator-hour plus a data transfer premium. Accelerators bill their fixed hourly fee continuously, even for applications no longer receiving traffic.
The always-on anycast fee
Every accelerator bills a flat hourly rate from the moment it is created, independent of traffic, plus a DT-Premium charge per GB on top of standard data transfer for the traffic it does carry. The hourly component is the trap: it continues while an accelerator fronts nothing. Disabling an accelerator in the console stops it routing but does not stop the hourly fee. Only deletion does. That detail catches teams who “turn off” an accelerator during a migration and assume the meter stopped with it.
What ZopNight sees per accelerator
The 6-hour discovery sweep inventories each accelerator, and per-resource spend comes from Cost Explorer or CUR 2.0. Idle-accelerator recommendations target the fixed fee: an accelerator whose endpoints are gone, whose endpoint groups are empty, or whose application traffic went elsewhere is billing its hourly rate for nothing. Because there is no meaningful stop state (disabled still bills), scheduling does not apply, and the recommendation is deletion, with the static IPs as the one thing to think about first.
Where accelerator spend goes quiet
Typical leaks: an accelerator created for a latency experiment that ended without a verdict; one fronting an ALB that was itself deleted, leaving empty endpoint groups; and accelerators kept purely because their static anycast IPs are referenced in a partner’s allowlist even though the workload moved behind CloudFront. The last case is the only defensible one, and it deserves an explicit note rather than silent billing.
Checking your accelerators
Global Accelerator is a global service surfaced in its console regardless of region selection. The accelerators list shows state and endpoint groups; empty groups or a disabled state that has persisted for weeks are the deletion candidates. Confirm nothing external pins the static IPs before removing one.