How to Stop AWS Charges: Find What Is Billing You, Shut It Off, Keep It Off
AWS keeps charging you because resources bill until they are deleted, not stopped. Here is the sequence that actually ends the charges: read the bill by usage type, stop or delete whatever sits behind each line, verify on the next day of usage data, and close the account properly if you want everything off.
Self-estimated cloud spend wasted
~28%
Charges continue until
Deletion, not stopping
Time to audit your own bill
About an hour
SEO Focus Topics
Key Takeaways
- • Stopped does not mean free. A stopped EC2 instance stops compute billing, but its EBS volumes and snapshots keep billing until deleted. An RDS instance left stopped restarts itself after seven days.
- • Read the bill by usage type, not by service. The service view says EC2-Other; the usage-type view tells you it is NAT Gateway data processing. You cannot stop a charge you cannot name.
- • Deleting beats stopping for almost everything except compute. Load balancers, NAT gateways, unattached public IPv4 addresses and idle SageMaker notebooks bill by the hour whether or not anything uses them.
- • If you deleted something and it came back, something is managing it: Auto Scaling groups replace terminated instances, CloudFormation and Terraform recreate deleted resources. Fix the manager, not just the resource.
- • Closing an account is a process, not a switch: cancel Marketplace subscriptions, downgrade the support plan, delete resources first, then expect a final bill up to a month later. Savings Plans commitments do not vanish with closure.
- • Genuine accidental charges are often recoverable. AWS billing support issues one-time courtesy credits for clear accidents far more often than people expect, if you ask politely with exact line items and dates.
Why the charges keep coming after you stopped using AWS
AWS does not bill intentions; it bills provisioned resources, hourly or by consumption, until those resources are deleted. The most common version of this problem looks like this: a project winds down, someone stops the EC2 instances, everyone calls it done, and three months later the account is still paying for the EBS volumes attached to those stopped instances, the snapshots taken before them, an elastic IP nobody released, and an application load balancer forwarding nothing to nowhere.
The second most common version is quieter: a credit ran out, a free tier expired, a Marketplace trial converted to paid, or a support plan carried on at its monthly rate. None of these appear as a dramatic line item. They appear as a slightly higher number than last month, which is exactly why unexplained billing drift goes unchallenged for quarters.
Step 1: find out exactly what is charging you
Open the Billing console and go to Bills, pick the month, and expand by service, then by usage type. The service-level total is where explanations go to die: EC2-Other tells you nothing, but its usage-type breakdown will say NAT Gateway data processing or EBS snapshot storage, and that is a thing you can act on. This is the same distinction that makes EC2-Other the most misunderstood line in the bill.
Then open Cost Explorer, group by usage type instead of service, and scan for lines that are small but nonzero. A $0.02 line item is rarely a rounding error; it is usually a live resource idling in a region you forgot about. Filter out credits so you are looking at real charges, and switch the date range to daily granularity, because flat lines across every day are the signature of an always-on resource that nobody remembers starting.
For anything you still cannot explain, Cost Optimization Hub lists idle and unattached resources directly, and a daily Cost and Usage Report queried in Athena gives you resource-level IDs, which is the difference between knowing that something billed and knowing exactly which volume did.
- ✓ Billing console → Bills → expand service → usage type. Name every line or mark it for deletion.
- ✓ Cost Explorer → group by Usage Type, filter Service = EC2-Other first. That is where the hidden stuff lives.
- ✓ Look for flat daily charges in regions with no known workloads. Forgotten regions are the classic ghost-billing ground.
- ✓ Run Cost Optimization Hub or the idle-resource recommendations for a machine-generated suspect list.
Step 2: the usual suspects that bill while doing nothing
Most mystery spend comes from a short list of resources that bill by existence rather than use. Delete-first applies here: for everything below except running compute, stopping is not available as an option, and pausing is not what the console button does.
- ✓ Unattached EBS volumes: a terminated instance can leave its volumes behind, and they bill every month forever. Check for volumes with no attachment before deleting their snapshots too.
- ✓ Old snapshots: incremental storage bills monthly. Snapshot chains from decommissioned databases are a quiet five-figure annual line at some companies.
- ✓ Public IPv4 addresses: since February 2024, every public IPv4 address costs about $0.005 per hour, including unattached ones. An unused elastic IP is roughly $3.60 a month for precisely nothing.
- ✓ Load balancers: ALBs, NLBs and Classic ELBs bill hourly plus per-unit charges whether or not any target exists behind them.
- ✓ NAT gateways: hourly charge while they exist, plus processing per GB. A NAT gateway in an empty subnet still bills.
- ✓ RDS instances: stopped RDS auto-restarts after seven days, so a "stopped" database quietly becomes a running one you pay for again.
- ✓ ElastiCache clusters, OpenSearch domains, SageMaker notebook instances and endpoints: all bill hourly while provisioned, idle or not.
- ✓ CloudWatch logs: ingestion and storage charges accumulate from Lambda, containers and VPC flow logs long after the workload they monitored is gone.
- ✓ Marketplace subscriptions and the support plan: fixed monthly fees that survive the death of every workload on the account.
Stop versus delete versus close the account
Escalate in that order, and know what each level actually does. Stopping is only real for EC2-style compute: it halts instance-hour billing but leaves EBS volumes, elastic IPs and anything attached still billing. Deleting removes the resource and its billing, but only if nothing recreates it.
- ✓ Stop: compute only. Billing pauses for instance hours; storage, IPs and attachments keep billing.
- ✓ Delete: the resource stops billing, but check for managers first: Auto Scaling groups, CloudFormation stacks, Kubernetes operators and Terraform will resurrect what you killed.
- ✓ Close the account: the nuclear option, which works cleanly only if you prepare it (next section).
How to close your AWS account without a nasty final bill
Closing the account does stop future resource billing, but the order of operations matters, because several things either block closure or bill after it. Prepare the account first: export or back up anything you need, because S3 buckets and snapshots go with the account.
- ✓ Delete all resources yourself before closing. Closure is not a cleanup tool, and usage between your last cleanup and the closure timestamp still bills normally.
- ✓ Cancel every AWS Marketplace subscription first. Closing the account does not automatically unsubscribe you from Marketplace sellers.
- ✓ Downgrade the support plan to Basic. Otherwise the monthly support fee rides along into your final bill.
- ✓ Check commitments: Savings Plans and Reserved Instances are contractual. Closure does not refund them, and outstanding amounts remain owed.
- ✓ Close from Account settings while signed in as the root user, then keep root access somewhere safe: you still sign in to see final bills.
- ✓ Expect the final bill up to a month or more later. Data transfer and usage processed before closure frequently lands on a post-closure invoice, which surprises everyone.
Getting unexpected AWS charges refunded
AWS does not advertise refunds, but billing support issues one-time courtesy credits for genuine accidents more often than most people expect: a forgotten test fleet, a resource a departed contractor left running, a duplicate account, a Marketplace trial that converted silently. The magic words are honest, specific and small: explain exactly what happened, cite the exact line items, usage types, regions and dates, and say plainly that it was unintentional and has been fixed.
What kills these requests is vagueness ("I did not authorise this") or repetition (a second courtesy credit for the same mistake). Open a support case under Account and billing, which is free on every plan including Basic, attach the bill excerpt, and ask politely for a courtesy credit as a one-time exception. If the charge stems from actual account compromise, say so immediately: that is a security case, not a billing dispute, and it gets handled differently.
- ✓ Include: exact service, usage type, region, dates, and dollar amount of the charge in question.
- ✓ Explain the mechanism: "a SageMaker notebook instance left running by a departed intern", not "charges I do not recognise".
- ✓ State the remediation: the resource has been deleted and guardrails added. Support wants to know it will not recur.
- ✓ Ask once, nicely. Courtesy credits are discretionary, one-time, and granted far more often than refused for plausible first offences.
Keep it off: guardrails that survive your attention span
An account you have cleaned once will drift straight back without guardrails, because the conditions that created the ghost resources never went away. Four mechanisms do most of the work, and none cost more than the waste they prevent.
- ✓ AWS Budgets with alerts at 80% and 100% of expected monthly spend, scoped per account or per tag so alerts route to whoever owns the spend.
- ✓ Cost Anomaly Detection wired to a channel a human actually reads. Detection without a route to a person is decoration.
- ✓ Tag enforcement plus activated cost allocation tags, so next month's mystery line already carries an owner.
- ✓ Scheduled shutdown for non-production: an Instance Scheduler or equivalent turns off dev environments nights and weekends, which is most of the week.
- ✓ A standing monthly ritual: read the bill by usage type and challenge any line you cannot explain in ten seconds. The cadence is the deliverable.
- For the full optimisation sequence after the bleeding stops: the 30-day AWS cost reduction guide . If the bill spiked suddenly rather than drifted, start instead with the triage playbook, and the EC2-Other case study shows how much hides inside one innocent-looking service line.
- AWS bill doubled overnight? A triage guide
Frequently Asked Questions
Why am I still being charged after stopping my EC2 instance?
Stopping an instance halts instance-hour billing only. Attached EBS volumes keep billing at full rate, snapshots keep billing for their storage, and an associated elastic IP bills around $0.005 per hour even unattached since February 2024. To end those charges you must delete the volumes, remove unneeded snapshots and release the addresses. Only terminating the instance and deleting its storage stops the billing completely.
How do I find out exactly what AWS is charging me for?
In the Billing console, open Bills, select the month, and expand charges by service, then by usage type. Follow with Cost Explorer grouped by usage type to spot flat daily charges that indicate always-on resources. For resource-level detail, enable a daily Cost and Usage Report and query it in Athena, or use Cost Optimization Hub for a generated list of idle and unattached resources.
Does closing my AWS account stop all charges?
It stops new resource billing, but not everything: cancel Marketplace subscriptions and downgrade the support plan before closing, because neither cancels automatically. Usage processed before closure, particularly data transfer, can land on a final bill up to a month or more later, and active Savings Plans or Reserved Instance commitments remain contractually owed after closure.
Can I get a refund for AWS charges made by mistake?
Often yes, via a one-time courtesy credit. Open a free support case under Account and billing, state the exact service, usage type, region, dates and amount, explain honestly how the charge happened and confirm the cause has been fixed. Credits are discretionary and one-time, but billing support grants them regularly for plausible first-time accidents described specifically.
Why did my AWS bill go up even after I deleted resources?
Two common reasons: delayed metering, where data transfer and some managed services report usage days late and bill it onto the current month, and resurrection, where an Auto Scaling group or infrastructure-as-code stack recreated what you deleted. Check whether the resource came back before assuming the bill is wrong, then look at the previous month's CUR for late-arriving usage.
Will AWS keep charging my credit card after I close the account?
Only for genuinely owed amounts: the final bill covering usage before closure, which can arrive up to a month or more after closure, plus any outstanding commitment payments. Future recurring charges stop once closure completes and pre-closure resources were deleted. Keep access to the root email address so you can see and settle the final invoice when it arrives.
Sources
- AWS: Closing your account
- AWS: Viewing your bill
- AWS: EC2 Stop and Start Your Instance (billing while stopped)
- AWS: Public IPv4 address pricing
- AWS: Stopping an RDS DB instance (seven-day restart)
- AWS: Cost Optimization Hub
- AWS Marketplace: Managing your subscriptions
- Flexera State of the Cloud Report (waste estimate)
About the author
Hermann Lotter
FinOps practitioner who has led cloud and AI cost optimization inside a 180-person organisation, identifying six-figure annual savings across AWS and LLM spend. He writes Easy Entropy from hands-on engagements, not theory. LinkedIn
Free Assessment
Want this outcome in your AWS bill?
Get a free cloud cost analysis and a prioritized optimization roadmap.
Request Free Analysis →Related Articles
Cost Optimization
AWS Savings Plans vs Reserved Instances 2026: Which to Buy
A practical comparison of AWS Savings Plans and Reserved Instances for 2026, with decision frameworks, pricing examples, and a recommended purchase sequence for every team size.
Cost Optimization
How to Reduce Your AWS Bill: A 30-Day Step-by-Step Guide
To reduce your AWS bill, work in this order: turn on Cost Explorer and daily CUR to find where the money actually goes, delete idle and orphaned resources, right-size overprovisioned compute and storage, then buy Savings Plans against the baseline that survives. Most accounts that have never been optimized give up 20% to 35% within 30 days, and the first two steps cost nothing and carry no production risk. Buying commitments first is the common mistake: it locks in the waste you have not removed yet.