You switch off an old service and expect its line on the bill to disappear. Next month it is still there. Often the switch stopped traffic or new work while leaving a provisioned resource behind. AWS can still charge for keeping that resource available.
The first useful question is “what unit am I paying for?” Hours of a retained address, allocated disk capacity and stored recovery data behave differently from requests. Find the usage type before deciding that billing is wrong or deleting the resource.
1. Separate traffic from provisioned capacity
A disabled Global Accelerator still has a fixed hourly charge until deletion. Public IPv4 addresses are a separate component, and traffic can add a transfer premium. These are stated separately on the Global Accelerator pricing page. Zero requests does not remove the fixed component.
Similarly, an AWS-provided public IPv4 address can be billed when it is attached or idle. The VPC pricing page distinguishes those states and exceptions such as customer-owned addresses. An unattached address can still be deliberately held for a future change, so the billing label is not the retirement decision.
| What you see | What may still be billed | Check before retirement |
|---|---|---|
| Disabled accelerator | Provisioned accelerator hours and public IPv4 | DNS, clients and rollback endpoints |
| Unattached Elastic IP | Retained public IPv4 address hours | External allowlists and planned reassignment |
| Detached EBS volume | Provisioned storage and configured performance | Filesystem contents and recovery purpose |
| Stopped automatic snapshots | Previously retained snapshot storage | Retention policy and replacement recovery copy |
2. Look for retained storage
A detached EBS volume still exists. Its provisioned capacity, rather than just the files currently on it, is part of the charge. Check any configured performance charges too. The EBS price breakdown separates these dimensions. An empty filesystem and an absent volume are different things.
Snapshots need their own inventory. In Lightsail, disabling automatic snapshots stops new daily copies but keeps existing ones, according to the snapshot FAQ. Do not confuse “stop making backups” with “stop storing backups”. The first can reduce protection while leaving storage charges in place.
Keep the inventory readable: resource type, region, purpose, owner, last meaningful use, charging unit and next review date. Put an unknown purpose in the evidence column. Do not translate it into “safe to delete”.
3. Put a small charge in context
Fictional example. One disabled standard accelerator with two AWS-provided IPv4 addresses exists for all 720 hours of September 2026. Its hypothetical application region is Europe (London), eu-west-2; the accelerator is global. There is no traffic. Pay-as-you-go USD rates were checked on 14 October 2026 in the accelerator and VPC sources above. Tax, credits and allowances are excluded; no Free Tier eligibility is assumed.
| Component | Calculation | USD before tax |
|---|---|---|
| Accelerator fixed fee | 720 hours × $0.025 | $18.00 |
| Two AWS public IPv4 addresses | 2 × 720 hours × $0.005 | $7.20 |
| Transfer premium | No traffic in this example | $0.00 |
| Total for these components | 18.00 + 7.20 + 0.00 | $25.20 |
This is an estimate of those components, not a complete application bill or an achieved saving. It assumes no premium contiguous address block or other chargeable resources. The point is that a quiet resource can have a predictable carrying cost. Whether that cost is worth removing depends on what the resource still protects.
4. Trace dependencies before giving up the resource
Ask who still connects to it. Check authoritative DNS configuration, including origins behind a proxy, application settings, external partner allowlists and operational documentation. Public DNS answers alone may show the proxy rather than the address you need to investigate.
Choose a representative observation period. A weekend with no traffic says little about a month-end import. Confirm whether a resource is deliberately retained for rollback and agree when that window ends. Keep a record of the configuration and the owner’s decision.
Do not assume an address can be recovered after release. If an integration depends on a fixed address, arrange and test the replacement first. For storage, identify the data and a usable recovery copy before proposing removal.
5. Verify billing after the approved change
Record the retirement time, expected final partial-period charge and any replacement costs. Confirm the intended resource state, then inspect subsequent usage and the next complete bill. Some remaining charge can belong to the part of the month before the change; a different retained resource may explain the rest.
Keep performance and recovery checks alongside that billing check. A smaller bill is not enough evidence if the next scheduled job fails. Investigate discrepancies by charging unit and time period rather than repeatedly removing things until the total falls.
What can go wrong?
The most expensive mistake may be retiring a cheap dependency. An old address can belong to a partner’s allowlist; a detached disk can hold the only recoverable upload. Also avoid buying a replacement service before including its costs in the comparison. Moving a charge elsewhere is not automatically a saving.
Proceed, investigate or keep?
- Proceed: purpose and dependencies are resolved, the owner approves retirement, and verification is scheduled.
- Investigate: recent activity is low but scheduled use or recovery purpose remains unclear.
- Keep: the retained resource still serves an agreed need at an acceptable cost.
If recovery is the reason for keeping something, the same restore-test principle applies to Git backups: availability is only the start of the evidence.
Continue the AWS review
If you are reviewing your website’s hosting, tell AceMedia Host what you need.