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 and attributes their spend through Cost Explorer or CUR 2.0; no rule evaluates their traffic yet.
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 and cost tracking 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. No recommendation rule evaluates accelerators today, so finding an idle one is a console check: 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 fix 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.