AWS Closed Account Still Charging? The 90-Day Tail

If you closed an AWS account and another charge appeared afterward, the 90-day post-closure period does not mean AWS simply keeps ordinary pay-as-you-go resources billing for another 90 days. You can still owe the final bill for usage before closure, plus outstanding Reserved Instance or Savings Plans commitments, and AWS Marketplace subscriptions need separate attention. The counterintuitive part is that those famous 90 days are primarily the account's recovery window before permanent closure—not a 90-day extension of normal usage billing.

A charge dated after your closure date is not automatically a charge for usage after your closure date. AWS bills on a billing-cycle timeline, while you close an account on a particular day. Those two dates can cross.

That distinction sounds small until money is leaving your card. Then it is the difference between a normal final invoice, a commitment you still owe, a Marketplace agreement that needs cancellation, and a charge that genuinely deserves a billing case.

What the AWS 90-day tail actually is

The phrase 90-day post-closure period has caused years of confusion because three separate things get mixed together: account recovery, retained resources, and billing.

When you close an AWS account, you enter a post-closure period that lasts 90 days. During that period, the account has been closed, but it has not yet crossed into permanent closure. You can still reopen it before that deadline.

After the post-closure period finishes, the account cannot be reopened. Content and remaining resources that follow the normal closure lifecycle are permanently removed.

That does not mean the account behaves like a normal active account for those 90 days. Normal access to AWS services is restricted. You retain narrow account-level access for things such as billing information, account settings, payment, and Support.

That is the first mental model to keep: closed but recoverable is not the same thing as active and running normally.

Ethan put it in shop terms: "Your phone shop can be closed while the landlord still keeps your deposit paperwork for a while. Keeping the paperwork alive is not the same thing as keeping the shop open and selling phones."

For AWS billing, the practical job is to separate four categories:

• usage that happened before you closed the account;
• Reserved Instance commitments;
• Savings Plans commitments;
• AWS Marketplace subscriptions or agreements.

Once you know which bucket your charge belongs to, the mystery usually gets much smaller.

The final bill can arrive after the account closes

This is the cleanest explanation for many "AWS charged me after closure" cases.

Suppose you close your AWS account on January 15. You already used AWS services from January 1 through January 15. Closing the account does not erase that usage. The bill for those January charges can arrive at the beginning of February.

So the card debit is in February, but the underlying service consumption belongs to January.

That is why a bank-statement date cannot tell you whether AWS billed you for activity after the account was closed.

Worked example: the bill date versus the usage date

Imagine Jake closes the AWS account for his small phone shop on January 15. From January 1 through January 15, the account accumulates a hypothetical $36.00 of ordinary service charges.

There is no new ordinary service usage after closure. The February billing cycle then settles the $36.00 that Jake already incurred before January 15.

The $36.00 in this example is only there to make the timeline visible; it is not a quoted AWS service price. The important factual point is the billing sequence: AWS can bill the following month for service consumption that occurred before the account closed.

The old “everything bills for 90 days” explanation is misleading

You can still find older answers online that describe the closure period as if ordinary running resources simply continue generating normal charges for all 90 days.

That is not a safe description to use for the current account-closure model.

The current account-closing rules separate your responsibilities much more clearly. You remain responsible for fees and charges for services consumed before account closure. You also remain responsible for unpaid invoices and outstanding Reserved Instances and Savings Plans. If you reopen the account, charges for services that remained in it can restart.

Those are three different ideas.

Past usage can still be invoiced.

Financial commitments can still have installments or committed charges due.

Retained services matter if you reopen the account because charging for those retained services can restart when access is restored.

That wording is much more useful than telling someone, "AWS bills everything for 90 days."

It also explains an otherwise confusing situation. You might close an account on Monday, receive a bill next month, and still have done nothing wrong. The later invoice does not prove ordinary resources stayed active for a full 90-day tail.

How to diagnose an AWS charge after closing the account

Do not begin with Resource Explorer, Tag Editor, EC2, S3, or twenty browser tabs. Begin with the bill because the bill tells you which branch of the problem to investigate.

1. Write down the exact AWS account ID associated with the closed account.
2. Find the email confirming the account closure and note the closure date.
3. Sign in to the closed account during the post-closure period.
4. Open Billing and Cost Management.
5. Choose Bills.
6. Select the month containing the unexpected amount.
7. Expand Charges by service.
8. Expand the relevant service and Region where the billing view provides that breakdown.
9. Look for language identifying a Reserved Instance, Savings Plan, Marketplace product, or ordinary service usage.
10. Compare the usage or commitment period with the account closure date.
11. Open the payment information if you need to reconcile the invoice with the debit on your bank card.
12. If the line item still has no sensible explanation, open an Account and billing Support case.

That sequence matters. You are moving from evidence to cause rather than from fear to random cleanup.

If you have multiple AWS accounts, check the account ID carefully. One of the nastiest versions of this problem is spending an hour inspecting the closed account while the debit actually belongs to a second AWS account created years ago with a different email address.

Reserved Instances are a commitment, not a running-server switch

If your invoice names a Reserved Instance, forget the question "Which server is still running?" for a moment.

A Reserved Instance is a pricing commitment. It can reduce eligible usage costs in exchange for committing to specified terms. For Amazon EC2, Reserved Instance terms are typically one year or three years.

Closing the account that purchased a Reserved Instance does not magically unwind the purchase agreement.

For an account inside consolidated billing, the payer account can continue to be charged for the Reserved Instance until it expires. After the closed account reaches permanent deletion at the end of the 90-day period, other member accounts no longer receive the discount benefit from that Reserved Instance.

That produces a particularly irritating outcome: the organization can keep paying for the reservation until expiration while eventually losing the ability to benefit from the discount after the owner account is permanently deleted.

This is not the same as an On-Demand EC2 instance that you forgot to stop.

If Jake bought a reservation because his booking server was supposed to run for years and then closed the account six months later, closing the account does not turn the remaining reservation term into an On-Demand resource cleanup problem.

Ethan's line to remember is: "A commitment is something you promised to pay for; a resource is something you can stop using. Do not treat those as the same object."

Savings Plans can keep appearing after account closure

Savings Plans create the same conceptual trap in a different form.

A Savings Plan is based on a commitment to a consistent amount of eligible compute usage measured in dollars per hour for a one-year or three-year term. You receive discounted rates in return for making that commitment.

If you later stop the workloads, the commitment does not disappear merely because there is less eligible compute left to receive the discount.

If you close the account, AWS still treats outstanding Savings Plans as obligations you remain responsible for.

That means a closed account can legitimately be associated with later Savings Plans invoices even when the ordinary server that originally motivated the purchase is no longer available.

Organizations make this more complicated because discounts can be shared across accounts. The management account can control Reserved Instance and Savings Plans discount sharing preferences across eligible accounts.

Closing or removing an account can therefore change not only who is paying, but also who benefits from the discount. If your organization has central FinOps or billing management, involve that person before assuming a line disappeared merely because the workload account was closed.

AWS Marketplace is the separate subscription trap

AWS Marketplace deserves its own section because account closure does not automatically cancel Marketplace subscriptions.

That sentence is easy to read and even easier to forget when you are doing account cleanup at 11 p.m.

If you have Marketplace software, the safe pre-closure sequence is to terminate the software instances associated with the subscription and then cancel the subscription from the Marketplace Manage subscriptions page where the agreement permits cancellation.

A Marketplace line on the invoice is not proof that an AWS infrastructure resource such as EC2 remained active after account closure. It can represent a commercial subscription or agreement with its own lifecycle.

This becomes especially important with private offers, contracts, and products whose agreement terms differ from a simple hourly software subscription. Do not assume the word "subscription" guarantees a one-click, immediate, retroactive cancellation.

First identify:

• the Marketplace product name;
• the seller;
• the agreement or subscription;
• its cancellation status;
• the dates covered by the charge.

Then compare those details with the account-closure timeline.

Jake learned this distinction the annoying way in our example. His booking server was gone, but a third-party product agreement was a separate financial object. Ethan did not send him back to EC2. He sent him to the agreement.

A disabled Region is not a closed AWS account

This is an adjacent billing trap that often appears during account cleanup.

Disabling an AWS Region does not automatically remove resources in that Region. If billable resources remain there, charges can continue even though you cannot normally access those resources while the Region is disabled.

That behavior is different from closing the entire AWS account.

If you have not closed the account yet and Billing shows a Region you thought you were no longer using, do not assume the Region toggle solved the problem.

Enable the Region again if necessary, identify the remaining resources, terminate the resources you no longer need, confirm that the billing source is gone, and only then disable the Region again.

Reopening the account can restart charges

This is the part I would put a red sticky note on if Jake were sitting beside me.

You do not necessarily need to reopen the AWS account merely to look at old billing information or contact Support during the post-closure period.

That matters because reopening changes the situation.

If services remained in the account and you reopen it during the 90-day post-closure period, charges for those services can restart.

So do not treat Reopen account as a harmless "let me look around" button.

If your only question is "Why did my card get charged?", first use the billing information available to the closed account and contact billing Support.

Reopen when you actually need access to retained resources, need to recover something, or need normal account functionality restored.

If you do reopen, immediately audit what remains.

1. Confirm the account has returned to an active state.
2. Open Billing before launching anything new.
3. Review active resources in every relevant Region.
4. Check compute, storage, databases, networking resources, snapshots, and other charge-producing items.
5. Review Reserved Instances and Savings Plans separately from ordinary resources.
6. Review AWS Marketplace subscriptions.
7. Delete or stop anything you do not intend to keep.
8. Do not assume the closure process previously deleted a resource just because you could not access it while the account was closed.

There is also a timing wrinkle. After an account is reopened, AWS services can take time to become fully available again. Do not interpret temporary service unavailability as proof that resources no longer exist.

AWS Organizations can make a closed-account charge look like it belongs somewhere else

If your account belonged to AWS Organizations, you have two identities to keep straight: the account that owned the resource or commitment and the account responsible for consolidated payment.

Those are not always the same account.

The organization's management account can receive charges associated with a member account. That remains important after member-account closure, especially for commitment products.

A member account that is being closed also has a lifecycle state inside Organizations. During closure processing, it can enter PENDING_CLOSURE. In that temporary state, the closure request exists but processing is not complete, and the account can still function.

After closure processing completes, the account transitions to CLOSED. It remains represented in that closed state during the 90-day post-closure window before permanent closure removes it from the normal organization view.

This distinction matters when somebody says, "I clicked close yesterday but it still looks alive in Organizations."

The first question is not whether the request failed. The first question is which account state is currently shown.

The current CLI route for a member account

A management account can request closure of an Organizations member account with:

aws organizations close-account --account-id 123456789012

The account ID is the 12-digit member account you intend to close.

That API request is not a generic "delete any AWS account" command. It is an AWS Organizations operation used from the organization management context for an eligible member account.

Organizations also imposes a rolling closure quota. Within a rolling 30-day period, you can close the higher of 250 member accounts or 20% of member accounts, with a maximum of 1,000. That matters mainly to large organizations, but it is exactly the kind of limit that can make a perfectly valid automation suddenly stop closing accounts.

The September 2026 account-state change

If you maintain scripts around AWS Organizations, use the account State model rather than building new automation around the old Status parameter. The older Organizations Status parameter reached its retirement date on September 9, 2026.

That change matters here because PENDING_CLOSURE and CLOSED make the closure lifecycle explicit. A billing workflow that only asks "active or suspended?" throws away useful information.

The payer account can keep seeing a commitment after the member account closes

This deserves its own section because it can look like billing has ignored the closure entirely.

Imagine a member account purchased an EC2 Reserved Instance. The organization uses consolidated billing. Later, somebody closes the member account because the project is finished.

The reservation term does not disappear. The payer account can continue being charged for that Reserved Instance until the reservation expires.

After the closed account is permanently deleted following the 90-day closure period, the member accounts no longer receive the discount benefit from that reservation.

That means there are two timelines:

• the AWS account lifecycle;
• the financial commitment lifecycle.

They do not have to end on the same date.

If you operate a multi-account environment, record commitment ownership before closing accounts. A simple internal note containing the purchaser account ID, commitment type, start date, end date, and payer account can save the finance team from treating a valid invoice as a phantom resource next month.

Ethan's advice to Jake would be overkill for Jake's one-account shop, but perfect for a company with 200 AWS accounts: "Never close an account until somebody has checked whether that account owns a commitment the rest of the organization still depends on."

CloudTrail has special behavior after AWS account closure

Most people researching a surprise bill do not need to begin with CloudTrail, but it is one of the closure edge cases worth knowing because its trail objects do not follow the simplest "account closed, everything instantly disappears" story.

CloudTrail trails can continue to exist after an account closes.

If a trail delivers to an S3 bucket inside the same account, the account-closure lifecycle of the bucket prevents that setup from behaving like a normal active destination.

If the trail delivers events to an S3 bucket in another account and delivery is still possible, the trail can continue delivering events. Organization trails are a good example of why cross-account destinations make closure behavior more complicated than a single isolated account.

CloudTrail also provides a route for requesting trail deletion after account closure through Support.

Why include this in a billing article? Because it is a useful warning against assuming every AWS object has identical post-closure semantics.

The general billing diagnosis still begins with the bill. If the invoice has nothing to do with CloudTrail, you do not need a CloudTrail archaeology expedition. But if CloudTrail is actually the line item or surrounding service context, treat it as a service-specific closure case rather than applying a generic rule.

Closing the account does not erase an unpaid AWS balance

An AWS account is not a prepaid wallet that resets to zero when you close it.

You remain responsible for outstanding fees and charges already incurred.

During the post-closure period, the limited account access is deliberately useful for this exact reason: you can review past billing and deal with payment obligations without having ordinary service access.

If your account was closed with an unpaid invoice, do not interpret a later payment attempt as evidence that a hidden resource has continued consuming AWS.

First reconcile the amount against the unpaid invoice.

There are three dates worth writing down:

• the usage period;
• the invoice date;
• the payment transaction date.

They can all be different.

This table sounds almost painfully obvious until the bank sends a notification saying AWS took money today. At that point, "today" becomes emotionally sticky. The invoice is what gets you back to the actual usage period.

When the correct next step is AWS billing Support

You do not need to solve every billing mystery yourself before contacting Support.

The right time to open an account-and-billing case is when you have already matched the transaction to the AWS account, opened the invoice, identified the service or charge category, and still cannot reconcile it with the closure timeline.

Prepare the case before you submit it.

• AWS account ID;
• root email associated with the account;
• date the account was closed;
• invoice month;
• invoice or payment identifier shown in Billing;
• amount you are questioning;
• service name;
• Region, where applicable;
• Reserved Instance details, if present;
• Savings Plans details, if present;
• Marketplace product and agreement details, if present;
• a one-paragraph explanation of why the dates do not make sense to you.

A useful message would be:

"I closed AWS account 123456789012 on September 10, 2026. The October invoice contains a $X charge under service Y. I have compared the line item with the closure date and cannot determine whether it represents pre-closure usage, an outstanding commitment, or another billing obligation. Please identify the billing period and basis for this charge."

That gives the billing team a timeline and a specific invoice to investigate.

"AWS stole money after I deleted everything" may accurately express how the bank notification felt, but it does not give Support enough structure to diagnose the invoice quickly.

What if you cannot sign in to the closed AWS account?

This is where a billing problem becomes an account-recovery problem.

During the post-closure period, normal service access is gone, but the account still has narrow billing and Support access. To use it, you still need to prove you are the account owner through the available sign-in and recovery process.

If you lost the root password, recover the root sign-in rather than creating a brand-new AWS account and expecting the new account to control the old one.

If you lost access to the root email address or MFA device, use the account-recovery and general account/billing Support paths available for sign-in problems.

Keep the MFA device associated with the root user available during the post-closure period if you left MFA enabled when closing the account.

This is one reason I would never recommend deleting the email mailbox or throwing away the MFA device the same afternoon you close AWS. Ninety days feels short until you need an invoice from day 67.

If the account belongs to an organization, the management account might also need to be involved in a reinstatement request for a closed member account.

What happens when the 90 days end?

The end of the post-closure period is the hard boundary.

Once the account reaches permanent closure, you cannot reopen it.

Remaining content and resources that follow the normal account-closure lifecycle are permanently deleted.

For AWS Organizations, the account also stops occupying the same closed-account representation after permanent closure.

This is why the 90-day period should be treated as your last recovery window, not as a convenient reminder to look at the account later.

If there is data you might need, deal with it before closure or reopen within the allowed period and recover it.

If there is an invoice dispute, raise it while you still have the clearest access path to that account's billing history and Support context.

If there is a commitment such as a Reserved Instance or Savings Plan, do not assume permanent account deletion automatically rewrites the financial term you previously bought.

Permanent closure ends the account lifecycle. It does not travel backward in time and erase valid fees, invoices, or contractual commitments.

The pre-closure checklist that prevents most surprise bills

You do not have to manually delete every AWS resource before closing an account for the closure request itself to exist. But relying on closure as your entire cleanup strategy makes the final billing investigation harder.

A better process is:

1. Open Bills first. Note every service currently generating a charge.
2. Record every relevant Region. Do not assume your usual home Region is the only one with billable resources.
3. Inspect disabled Regions. If Billing points to one, enable it as needed and clean up the resources before disabling it again.
4. Terminate ordinary resources you no longer need. Do not stop at EC2 instances; inspect storage, databases, snapshots, network resources, and service-specific leftovers shown on the bill.
5. Check Reserved Instances separately. Write down the owner account and expiration date.
6. Check Savings Plans separately. Write down the commitment and end date.
7. Check AWS Marketplace. Terminate associated software instances and cancel eligible subscriptions through Manage subscriptions.
8. Check Organizations relationships. Know which account pays the bill and which account owns commitments.
9. Back up anything you may need. Do this before closing, not on day 89.
10. Keep root access alive. Preserve the email address and MFA method through the post-closure period.
11. Save the account ID. Twelve digits on a text file can save an absurd amount of detective work later.
12. Save the closure confirmation. The exact date is the anchor for every later billing comparison.
13. Close the account last. Closure should be the final administrative step, not your first attempt at cost cleanup.

This is less dramatic than clicking "Close account" and hoping the cloud evaporates. It is also much easier to audit.

The 60-second decision path for a post-closure AWS charge

If you are staring at the bank notification right now, use this table before reading another forum thread.

If you remember only one practical idea from this table, make it this: read the line item before diagnosing the infrastructure.

The service name and charge type tell you whether you are dealing with usage, a commitment, a third-party subscription, or an organization billing relationship.

Will AWS refund a charge that appears after closure?

Do not start from the assumption that "charged after closure" equals "refund due."

The date the payment reaches your bank can be later than the usage date. A Reserved Instance or Savings Plan can still represent a valid outstanding obligation. A Marketplace agreement can have its own cancellation terms.

So the first job is classification, not refund negotiation.

If the charge is legitimate pre-closure usage, there may be nothing to correct.

If it is an ongoing commitment, you need to understand the commitment term.

If it is Marketplace, identify the agreement and seller relationship.

If the amount appears inconsistent with those explanations, open the billing case and ask AWS to identify exactly what billing event generated the line.

When asking about an adjustment, be specific. "Please refund my AWS bill" is less useful than "This $X charge is dated after closure and does not match the pre-closure usage or commitments shown in my Billing console; please review this invoice line."

Also avoid jumping straight to a card dispute before you have identified the AWS account and invoice. A dispute does not explain the underlying AWS billing object, and if you have another AWS account or an outstanding valid invoice, you can end up solving the wrong problem.

AWS closed account still charging: 16 questions people actually ask

Why am I still being charged after closing my AWS account?

The most common explanations are a final bill for usage that occurred before closure, an outstanding Reserved Instance, a Savings Plan commitment, or an AWS Marketplace subscription. Start with Billing → Bills and identify the exact charge type before looking for resources.

Does AWS keep charging all resources for 90 days after account closure?

Do not treat the 90-day post-closure period as a blanket 90-day continuation of ordinary pay-as-you-go billing. You remain responsible for pre-closure charges and outstanding commitments. Charges for services retained in the account can restart if you reopen the account during that window.

What happens during the AWS 90-day post-closure period?

The account is closed but has not yet reached permanent closure. Normal AWS service access is restricted, but you can still use limited account functions such as viewing past billing information and contacting Support. The account can be reopened during this period.

Will AWS send me a bill the month after I close my account?

Yes, that can be normal. If you close the account partway through a billing month, AWS can issue the following month's invoice for usage you accumulated between the start of that month and your closure date.

Can I sign in to a closed AWS account to check billing?

During the post-closure period, access is restricted, but the closed account can still be used for limited purposes including viewing past billing information, accessing relevant account settings, dealing with bills, and contacting Support.

Do Reserved Instances keep billing after AWS account closure?

Outstanding Reserved Instance obligations can continue until the reservation expires. In an organization, the payer account can continue to be charged for a Reserved Instance purchased by the closed account.

Do Savings Plans keep billing after I close AWS?

You remain responsible for outstanding Savings Plans. Closing the AWS account or stopping the workloads does not erase the compute commitment you purchased for the plan term.

Does closing an AWS account cancel AWS Marketplace subscriptions?

No. AWS Marketplace subscriptions are not automatically canceled merely because the AWS account is closed. Before closure, terminate associated software instances and cancel subscriptions through Manage subscriptions where the agreement allows it.

Will reopening my AWS account make charges start again?

It can. If services remained in the account, charges for those services can restart after you reopen the account. If you only need to understand an invoice, use the closed account's billing and Support access first.

Can AWS reopen an account after the 90-day period?

No. After the post-closure period ends and the account becomes permanently closed, you cannot reopen it. Treat the 90-day window as the final period for recovery or reinstatement.

Why does my closed account still appear in AWS Organizations?

A member account can remain represented in Organizations during the closure lifecycle and the 90-day post-closure period. A closure request can first show a pending state before the account reaches CLOSED.

What is PENDING_CLOSURE versus CLOSED in AWS Organizations?

PENDING_CLOSURE means the request to close the account is being processed and the account can still function. CLOSED means closure processing has completed and the account is in its post-closure window before permanent closure.

Can a disabled AWS Region still generate charges?

Yes. Resources left in a disabled Region can still generate charges even though normal access to those resources is restricted. Before closing the account, enable the Region if needed, terminate unwanted resources, and then disable it again.

How do I find which AWS service caused the charge?

Open Billing and Cost Management, choose Bills, select the billing period, and expand Charges by service. Use the service, Region, usage dates, and charge description to determine whether the amount is ordinary usage, a commitment, or a Marketplace item.

Can I contact AWS Support about billing after closing my account?

Yes. During the post-closure period, you can contact AWS Support about the closed account. Include the account ID, closure date, invoice, amount, service, and commitment or Marketplace information so the billing team can investigate the exact line item.

Should I dispute the card charge if AWS bills me after closure?

First reconcile the bank transaction with the AWS invoice. A later card transaction can represent earlier valid usage or an outstanding commitment. If the invoice cannot be reconciled or appears incorrect, raise the specific line with AWS billing Support before assuming the payment date proves post-closure usage.

The clean way to think about the AWS 90-day billing tail

The easiest way to get this topic wrong is to compress everything into one sentence: "AWS keeps your stuff for 90 days, so it keeps billing you for 90 days."

That sentence mixes account recovery, resource retention, service usage, commitments, and subscriptions into one blurry rule.

The useful model has four lines.

First: usage that happened before closure still has to be paid, even if the invoice arrives the following month.

Second: Reserved Instances and Savings Plans are commitments with their own terms, so closing the account does not simply erase what remains due.

Third: AWS Marketplace subscriptions require separate attention because they are not automatically canceled by closing the AWS account.

Fourth: the 90-day period is the window between closure and permanent closure in which the account can still be reinstated. If you reopen it, charges for services that remained can restart.

That framework also gives you a much better troubleshooting order.

Do not start by asking, "What resource did AWS secretly leave on?"

Start by asking, "What exactly does this invoice line represent, and what dates does it cover?"

For Jake, that turned an alarming card notification into a short decision tree. The charge was either old usage, a commitment, a Marketplace agreement, or something that needed Support to explain. He did not have to search every service in every Region before reading the bill.

Ethan's final advice is the same advice I would use here: "Do not argue with the payment date. Trace the charge back to the thing that created it."

If your closed-account invoice still does not line up after you compare the closure date, usage period, commitment terms, Marketplace agreements, payer account, and invoice details, put those facts together in one billing case. That gives AWS Support a concrete discrepancy to investigate instead of leaving you staring at a card notification and wondering whether the 90-day clock is quietly draining your account.

Revision note. Written October 2, 2026, for anyone who closed the door and still saw a charge come through. The tail is short and it has a shape; read the invoice line, and you'll know which of the few causes it is.