Can't Close Your AWS Account? The Blockers, in Order

If AWS will not let you close an account, deleting more EC2 instances, buckets, and databases is usually the wrong first move. The blocker is normally the account's identity or governance state: you are not signed in as the root user, the account is an AWS Organizations management account with active members, a policy denies closure, AWS Control Tower still manages the member, or the organization has reached a closure limit. The surprising 2026 case is newer: organizations created through the AWS Organizations console after July 10, 2026 can receive a default service control policy that prevents member accounts from closing themselves. Sign in as the root user first, then check which of those blockers applies before you delete anything else.

Jake has reached the unpleasant end of a cloud experiment. His phone shop used an old AWS account for a booking page, a small backup bucket, and a Lambda function that sent order messages. The workload has moved elsewhere. He wants the account gone before another bill arrives.

He stops the obvious resources, returns to the Account page, and still cannot close the account. His first reaction is reasonable: "There has to be one billable thing hidden in another Region." Ethan stops him there. A resource that costs money and a rule that prevents account closure are two different problems. You should investigate them separately.

AWS Billing cannot close account: the blockers list

The fastest diagnosis starts with what you actually see. Do not treat every failed closure as the same problem.

The important split is between closure eligibility and financial cleanup. Closure eligibility answers, "Will AWS accept this account-closing action?" Financial cleanup answers, "Could anything still cost me money, create an obligation, or disappear in a way I regret?"

Those lists overlap less than most beginners expect. An undeleted S3 bucket is worth investigating before you abandon an account, but it does not explain why an IAM administrator cannot see the root-only Close account button.

Blocker 1: you are not signed in as the AWS account root user

If the Close account button is missing from the Account page, check who you are signed in as before doing anything else.

The root user is the identity created with the AWS account itself. It signs in with the account's root email address and password. An IAM user or IAM role lives below that root identity. Even an IAM principal with broad administrative permissions is not automatically allowed to perform every root-only account action.

Direct account closure from the Account page is one of those actions. You cannot close a standalone account from that page while signed in as an IAM user or role.

How to close a standalone account from the console

1. Sign out of the AWS console session you are currently using.
2. Choose the root-user sign-in path.
3. Enter the root email address for the account you want to close.
4. Complete the root password and MFA challenge if MFA is configured.
5. Open the account menu in the upper-right corner.
6. Choose Account.
7. Find the account closure section and choose Close account.
8. Enter the 12-digit account ID when the confirmation dialog asks for it.
9. Confirm the closure.

If the button appears after you switch from an IAM administrator to root, you have your answer. Nothing was wrong with EC2, S3, Billing, or Organizations. You were simply using an identity that was not allowed to perform that root-level action.

If you cannot sign in as root, solve that problem first. A forgotten root password, inaccessible root mailbox, or unavailable root MFA device is an account-access problem. Granting an IAM user more permissions does not repair root access.

Keep this distinction in mind because it saves a lot of destructive troubleshooting. If you cannot find the Close account button, do not start terminating databases to see whether the button appears. A UI control hidden because of identity does not become visible because an RDS instance was deleted.

First identify what kind of AWS account you are closing

Several AWS account-closing instructions look contradictory until you notice they apply to different account types.

A standalone account is not currently part of AWS Organizations. Close it from its own Account page while signed in as root. Direct standalone closure is a console task rather than an AWS CLI or SDK operation.

A member account belongs to AWS Organizations under a management account. When the organization has All features enabled, an authorized administrator can centrally close that member from AWS Organizations. The Organizations CloseAccount API and the CLI's organizations close-account command are for this member-account path.

A management account sits at the top of an AWS Organization. It cannot be closed with the Organizations CloseAccount API. You must first close or remove active members, then sign in to the management account as root and close it from its own Account page.

This is the source of a common CLI mistake. Someone finds aws organizations close-account, assumes it means "close any AWS account," and runs it against the organization management account. The command name is shorter than the rule: the Organizations action closes member accounts.

Ethan tells Jake, "Before you troubleshoot the lock, make sure you're standing at the right door." That is not just an analogy here. AWS exposes different doors for the three account roles.

Blocker 2: the account is the Organizations management account

You cannot close the management account directly from the AWS Organizations console. You also cannot pass the management account ID to CloseAccount and turn it into an ordinary member.

The management account owns the organization relationship. Before it can close, there must be no active member accounts left beneath it. You can satisfy that requirement by closing member accounts you no longer need or removing accounts that should continue independently.

Removing and closing are not synonyms. Removing a member from an organization makes it a standalone account. It can continue operating and becomes responsible for its own billing. Closing the member starts the account's post-closure lifecycle.

Once no active member accounts remain, sign in to the management account as root, open the Account page, and start closure there.

If you instead try to close the management account through the Organizations member-account route, a ConstraintViolationException can be the clue that you chose the wrong closure path.

There is another subtlety here: a member account can remain visible after you close it. Visibility is not the same as activity. Check account state instead of counting names on the screen and assuming every visible row still blocks you.

Blocker 3: you are reading the wrong account lifecycle field

This is an especially easy trap in 2026 because older scripts, examples, and saved snippets may still check the older account Status field.

The AWS Organizations Status parameter was retired on September 9, 2026. New automation should use the account State field.

When you submit a closure request, the account can move into PENDING_CLOSURE while AWS processes the request. After processing completes, the account moves to CLOSED.

That means an accepted API call is not the same thing as immediate permanent deletion. The CloseAccount action is asynchronous. AWS can accept the operation while closure is still in progress.

Use DescribeAccount when you need to inspect a particular member:

aws organizations describe-account \
  --account-id 123456789012

If you maintain a cleanup script that was written before the Status retirement, update it instead of concluding that account closure has become unreliable. A lifecycle field that changed underneath your script is a monitoring bug, not necessarily a closure failure.

You can also use the AWS Organizations console to inspect member state. During the 90-day post-closure period, a closed account can remain listed with a CLOSED label.

This matters to management-account cleanup because the requirement is no active members. A closed member still shown in the organization tree is not equivalent to a live account that continues blocking management-account closure.

Blocker 4: a service control policy denies member-account closure

A service control policy, or SCP, is an Organizations policy that limits the permissions available to accounts beneath the organization. Think of it as the outer fence. IAM permissions inside the member operate inside that fence.

If an SCP explicitly denies account:CloseAccount, giving an IAM administrator broader permissions inside the member does not override that deny.

This is one of the strongest reasons not to diagnose an Access denied message by randomly editing IAM policies. If the effective deny comes from an SCP above the member account, repeatedly attaching AdministratorAccess inside that account will not solve it.

The useful questions become: Which SCPs apply to this account? Does one deny account:CloseAccount? Is the account intended to self-close, or should the central administrator close it from Organizations instead?

A representative deny looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "account:CloseAccount",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

Do not copy that snippet into your environment as a fix. Its purpose here is to show what sort of explicit deny creates the symptom. Your task is to inspect the policies actually attached to your root, OU, and account.

The central management account is different. SCPs do not restrict principals in the Organizations management account. That lets the organization retain central lifecycle control while members can be prevented from departing on their own.

Blocker 5: the central administrator cannot call Organizations CloseAccount

SCPs are not the only policy layer. The identity making the central Organizations call also needs authorization to perform the action.

If you are signed in to the management account with a role that can list accounts, move them between OUs, and inspect policies, that does not automatically prove the role is allowed to close them. An IAM policy can intentionally withhold organizations:CloseAccount.

This is useful governance. Account closure is destructive enough that many teams do not want every cloud administrator who can create or move accounts to be able to close them.

If the command returns an access error, inspect the permissions of the actual caller. Do not switch to the member account and start deleting application resources; application resources do not grant the management role permission to call an Organizations API.

A second trap is assuming that because the member's root user can close its own account, the organization administrator must also be authorized to do so centrally. These are separate authorization paths.

Ethan tells Jake, "There are two keys here. One belongs to the apartment, the other to the building office. Proving one works does not prove you have the other."

Blocker 6: the organization is not using All features mode

Central member-account closure through AWS Organizations requires All features mode.

If your organization is using consolidated billing mode and you open the Organizations console looking for the member's Close action, you may not see it. That missing control does not mean the account is permanently trapped.

The alternative is to sign in to the member account itself as root, open its Account page, and close it from there.

This is another good example of why "Close button missing" is not a complete diagnosis. The same visible symptom can mean different things depending on where you are looking.

Missing from the member's own Account page usually sends you toward root-user identity. Missing from the AWS Organizations member-management view sends you toward organization feature mode and central permissions.

When somebody gives you a screenshot of a missing button, ask which console page they are on before prescribing a fix.

Blocker 7: AWS Control Tower still manages the member account

If the account belongs to an AWS Control Tower landing zone, do not jump straight from "we no longer need this account" to Organizations CloseAccount.

Unmanage the member account first. In plain language, you are telling Control Tower to stop treating that account as one of the accounts it governs.

Then proceed with account closure through the appropriate AWS Organizations or direct account route.

Why does the order matter? Closing a still-managed Control Tower account can leave the surrounding Control Tower view and provisioned-account state in an awkward condition. You may end up with a suspended or closed AWS account that Control Tower still considers enrolled.

If your goal is a clean decommission rather than merely making the account inaccessible, unmanage it before closure.

Jake's original AWS experiment had been created from a tutorial. He remembers clicking through Control Tower once but not what it created. That is exactly the situation in which you should check enrollment before deleting OUs or CloudFormation stacks by hand.

Control Tower is not just a folder around the account. It manages governance resources and account enrollment state. Let it release the member cleanly before you close the underlying AWS account.

Blocker 8: CLOSE_ACCOUNT_QUOTA_EXCEEDED

Organizations with many accounts have a completely different kind of blocker: the rolling member-account closure quota.

As of October 2026, within a rolling 30-day period an organization can close the higher of 250 member accounts or 20% of its member accounts, with a maximum of 1,000 closures.

The quota is not adjustable.

The words rolling 30-day period are the important part. It is not a calendar-month quota. If you close accounts on September 25, those closures do not vanish from the calculation because the calendar reaches October 1.

Worked quota example: 2,000 member accounts

Imagine an organization with 2,000 member accounts.

Twenty percent of 2,000 is 400.

The rule chooses the higher of 250 or 20%, so 400 beats the 250-account floor. It is also below the overall 1,000-account cap.

That organization can therefore close 400 member accounts within the applicable rolling 30-day window.

If the team closes 400 and immediately attempts another qualifying closure, the request can fail with:

CLOSE_ACCOUNT_QUOTA_EXCEEDED

There is no IAM permission you can add to turn 400 into 401. There is no service quota request that raises this limit. The practical fix is time: wait until enough earlier closures fall outside the rolling 30-day window.

Worked quota example: 500 member accounts

Twenty percent of 500 is only 100. The rule uses the higher value, so this organization gets the 250-account floor rather than being limited to 100 closures.

This is why memorizing "20%" without the floor produces bad advice.

Blocker 9: CLOSE_ACCOUNT_REQUESTS_LIMIT_EXCEEDED

This error is not the same as the rolling 30-day quota.

CLOSE_ACCOUNT_QUOTA_EXCEEDED means too many accounts have been closed during the rolling quota window. CLOSE_ACCOUNT_REQUESTS_LIMIT_EXCEEDED means too many closure operations are currently being processed at once.

The distinction matters because the fixes are different.

For the rolling quota, you may need to wait until old closures age out of the 30-day window. For concurrent requests, you normally wait for in-progress closure operations to complete and then submit more.

Member-account closure through Organizations is asynchronous. The command can be accepted while AWS still has work to do.

The CLI command is:

aws organizations close-account \
  --account-id 123456789012

A successful CLI invocation produces no ordinary output. That silence does not mean "the account and every resource vanished in the same millisecond."

Check the account afterward:

aws organizations describe-account \
  --account-id 123456789012

If the state is PENDING_CLOSURE, the request is still moving through the lifecycle. When it reaches CLOSED, AWS has processed the closure.

This is where bulk-decommission scripts need restraint. Submitting hundreds of destructive requests as fast as a loop can generate them is not automatically better automation. Track state, limit concurrency, and do not retry an accepted operation merely because it did not become CLOSED instantly.

What ConstraintViolationException actually tells you

ConstraintViolationException is a family of errors, not a complete root cause by itself.

When account closure triggers it, read the accompanying reason instead of copying the exception name into a search box and applying the first fix you find.

For example, CANNOT_CLOSE_MANAGEMENT_ACCOUNT tells you that the target is the management account and must be handled through the management-account closure path after member cleanup.

CLOSE_ACCOUNT_QUOTA_EXCEEDED points to the rolling 30-day limit.

CLOSE_ACCOUNT_REQUESTS_LIMIT_EXCEEDED points to concurrent closure pressure.

An already-closed account, an account that is not where the caller expects it to be, and other organization state conflicts can produce different failures.

There is also a nearby error worth recognizing: AWSOrganizationsNotInUseException. If you call an Organizations operation with credentials for an account that is not actually using AWS Organizations, the fix is not "add more Organizations permissions." Use the account's correct closure route instead.

AccountNotFoundException deserves the same discipline. Confirm the 12-digit account ID and confirm that the caller belongs to the organization that contains the target.

ConcurrentModificationException means another request is modifying the target. Let the competing operation finish before you stack another lifecycle change on top of it.

The useful troubleshooting habit is simple: preserve the complete exception, including its reason. "ConstraintViolationException happened" is much less useful than "ConstraintViolationException with CLOSE_ACCOUNT_QUOTA_EXCEEDED."

Can an AWS account still bill me after I close it?

Yes. This is where the word "Billing" in the problem deserves attention, but not because an ordinary final bill is necessarily a closure blocker.

You remain responsible for charges incurred before account closure. AWS billing runs after usage occurs, so closing an account halfway through a month does not erase usage from the first half of that month.

Suppose Jake closes his AWS account on October 15. If services generated $18.40 of usage from October 1 through October 15, that amount does not disappear because the account entered closure on the 15th. A later invoice can still contain that usage.

Reserved Instances create a second category of post-closure billing. If the account has active Reserved Instances, charges can continue until the reservation term expires.

Savings Plans can also continue producing invoices until their commitment term finishes.

This is why "the account is closed, so every future AWS invoice must be a mistake" is not safe reasoning.

There is another billing wrinkle if you reopen the account during the post-closure period: charges for services that remained in the account can start again.

That is one reason to clean up intentionally even though AWS does not require you to manually delete every resource as a prerequisite to closure.

Do you need to delete every AWS resource before closing the account?

No. Manually deleting every ordinary AWS resource is not a prerequisite to closing an account.

During the 90-day post-closure period, resources remaining in the account are unavailable unless the account is reopened. After permanent closure, AWS deletes remaining content and resources, with the documented exception for CloudTrail trails.

That does not mean "ignore cleanup." It means the purpose of cleanup is different from what many people assume.

Clean up because you want to stop avoidable usage before closure finishes, preserve data you care about, cancel subscriptions or commitments that have their own lifecycle, simplify any possible reopening, and avoid losing something important.

Do not clean up because you believe a leftover security group is mechanically hiding the Close account button.

If you have databases, snapshots, object data, logs, customer exports, or anything else that may matter later, make the preservation decision before closing the account. After permanent closure, recovery is no longer the plan.

Jake has customer booking exports in an S3 bucket. Ethan does not tell him, "Delete it because AWS requires an empty account." He tells him to copy the data he actually needs elsewhere, confirm the backup location is independent of the account being closed, and then continue.

The difference sounds small, but it changes the mindset from frantic destruction to deliberate decommissioning.

Two cleanup traps: AWS Marketplace and Route 53 domains

AWS Marketplace subscriptions require separate attention. Closing the AWS account does not automatically cancel every Marketplace subscription.

If the account uses Marketplace software, terminate the relevant software instances and cancel the subscriptions from the Marketplace subscription-management area before treating the account closure as the end of that commercial relationship.

This is a good place to be precise about language. A Marketplace subscription is not automatically a blocker that makes the Close account button disappear. It is a cleanup item with financial consequences.

Route 53 domain registration can be even more painful because it can break your path back into the account.

Imagine that the AWS root email is owner@example.com and the domain example.com is registered through Route 53 inside the same AWS account you are closing.

After account closure, registered domains go through a suspension and deletion or release process. AWS sends daily notices before suspension. If the domain stops working, email to owner@example.com can stop too.

Now the address needed for AWS account recovery depends on a domain trapped inside the account you are trying to recover. That is a self-inflicted lockout loop.

Route 53 begins notifying the account that the domain will be suspended within the next five days. The later deletion or release behavior depends on the registrar involved.

This is the kind of edge case that does not appear when you think only in terms of "what AWS resource is still billing me?" The domain may be cheap. Its role in recovering the account is what makes it critical.

The account is closed but still appears in AWS Organizations

This is expected during the post-closure period.

An AWS account has a 90-day period between closure and permanent closure. A closed member account can continue to appear in AWS Organizations with a CLOSED label during that time.

After the 90-day period, the member is permanently closed and eventually disappears from the Organizations view.

There is a quota consequence: a closed member can still count toward the organization's account quota during the post-closure period.

If account-quota capacity matters to a large organization, removing a member from the organization before closing it can be worth considering when your governance and billing setup allow that sequence. Once removed, it is a standalone account and has its own billing responsibility.

Do not confuse that organization account-count quota with the rolling closure quota discussed earlier. One governs how many accounts the organization contains; the other governs how many members you may close during the rolling period.

The 90-day period also gives you a limited recovery window. If you need the account back, contact AWS Support as soon as possible during that period.

Outstanding balances matter when reopening. Full payment of outstanding amounts must be received under the reopening requirements.

Once the account reaches permanent closure after the 90-day period, you cannot reopen it. The AWS account ID is not reused.

No closure email, MFA still attached, or root access looks strange

The account-closure confirmation is sent to the root user's email address.

If it does not arrive within a few hours, do not use the missing email as your only evidence that closure failed. Sign in as root and inspect the account. A successfully closed account displays a closed-account message.

For an Organizations member, the management account can also inspect the member in Organizations and look for the closed state.

If the account you tried to close is the management account and no confirmation arrives, active member accounts deserve another check. The management account cannot close while active members remain.

MFA has its own post-closure behavior. Closing the account does not automatically remove MFA from the root user.

If you leave root MFA enabled, keep the MFA device available throughout the 90-day post-closure period in case you need to access or reopen the account.

This matters with physical hardware tokens in particular. A hardware TOTP token cannot simply be treated as free for reuse after permanent closure. If you know you intend to reuse that hardware device with another user, handle the MFA choice before account closure rather than assuming closure will detach everything cleanly for you.

Jake laughs when Ethan tells him to label the old MFA key and keep it somewhere safe for three months. "So even the account I'm trying to forget needs a retirement box?" For 90 days, yes. A shoebox is cheaper than discovering the only available MFA device was thrown away on day two.

The GovCloud case: closing one account can affect its linked account

AWS GovCloud (US) accounts have a linked standard AWS account relationship for billing and payment.

If the account you are closing is linked to an AWS GovCloud (US) account, treat that as a special case rather than applying the ordinary commercial-region checklist blindly.

Closing the standard account is part of the GovCloud closure path, and a programmatic Organizations CloseAccount request against a linked standard account can close both linked accounts.

That is an excellent reason to identify linkage before automating account retirement by account ID.

If your organization operates GovCloud, put an explicit GovCloud-link check into the decommission approval process. Do not rely on an engineer noticing the relationship after the closure request has already been submitted.

This is also a useful reminder that a 12-digit AWS account ID is not enough business context for a destructive workflow. Your closure record should identify what the account does, which organization owns it, whether Control Tower manages it, whether it has a GovCloud link, and who approved retirement.

When the AWS console itself is the problem

After you eliminate the structural blockers, give the browser one chance to be boring.

If you are definitely signed in as root for the correct account, the account type and organization state are correct, there are no active-member or policy problems, and the Account page still behaves unexpectedly, retry from a clean browser session.

Clear AWS-related cookies and cached site data, sign back in, or use another supported desktop browser.

Do this late in the diagnostic order, not first. Browser cleanup cannot turn a management account into a member account, remove an SCP, raise an Organizations quota, or unmanage a Control Tower account.

It is useful only after those structural explanations no longer fit.

That is why this article does not start with "clear cache and cookies." Cheap troubleshooting is good; irrelevant troubleshooting is not.

The safest order to troubleshoot an AWS account that will not close

1. Write down the 12-digit account ID. Do not rely on an account nickname when the action is destructive.
2. Identify the account role. Standalone, Organizations member, or Organizations management account?
3. Identify the current identity. If you are closing from the account's own Account page, are you signed in as root?
4. If it is a member, check organization mode. Central Organizations closure requires All features mode.
5. Check governance. Look for SCP denies, caller IAM restrictions, and Control Tower enrollment.
6. If it is the management account, resolve active members. Close members you no longer need or remove members that should survive independently.
7. If you are doing bulk closure, inspect quota and concurrency errors. Distinguish rolling 30-day quota exhaustion from too many in-progress requests.
8. Inspect the account's current State. An asynchronous closure may already be in progress.
9. Review billing commitments and service-specific cleanup. Reserved Instances, Savings Plans, Marketplace, Route 53 domains, backups, and MFA deserve deliberate handling.
10. Only then eliminate browser trouble. Retry from a clean supported desktop-browser session if the structure is correct but the UI remains abnormal.

This order is intentionally conservative. It starts with observation and permissions, not deletion.

It also protects you from the worst troubleshooting mistake in this problem: destroying resources in a production account because you were trying to make an account-level button appear.

When nothing works: build a useful AWS Support case

If the account still will not close after you have walked the decision path, stop changing unrelated resources and capture the state of the problem.

Start with the account ID and the account type. Say plainly whether it is standalone, a member account, or the Organizations management account.

Copy the exact error message. Do not reduce ConstraintViolationException: ... CLOSE_ACCOUNT_QUOTA_EXCEEDED ... to "AWS gives an error."

Record whether you used the Account page, the Organizations console, AWS CLI, or an SDK.

If it is a member, include the current account State.

If you used Organizations, note whether All features mode is enabled.

If the member belongs to Control Tower, state whether it is still enrolled.

If access is denied, identify the relevant SCPs and the IAM principal making the call. Do not attach a hundred application logs that have nothing to do with account lifecycle.

If this is a management account, state the number of active member accounts remaining. "I think they are all gone" is less useful than "zero active members; three CLOSED members remain visible."

If this is a bulk account retirement, include the number of member accounts in the organization and how many accounts were closed during the preceding 30 days.

If the account contains a Route 53 domain used by its root email, mention that before somebody treats reopening as a trivial fallback.

Your goal is to give Support the information needed to identify an account-lifecycle constraint, not to prove how frustrated you are. The error text and account topology will do more work than a page of guesses.

AWS Billing cannot close account FAQ

Why is the AWS Close account button missing?

The most common first check is your sign-in identity. The direct Account-page closure control is available to the account root user, not an IAM user or role. Sign out, use the root-user login for the exact account you want to close, and return to the Account page. If you mean the Close option inside AWS Organizations instead, also check whether the organization has All features enabled.

Can an IAM administrator close an AWS account?

An IAM administrator cannot use the standalone account's root-only Account-page closure path merely because it has AdministratorAccess. An authorized identity in an AWS Organizations management account can separately close eligible member accounts through Organizations. Those are two different permission models.

How do I close a standalone AWS account with the CLI?

You do not. Direct closure of a standalone account is performed in the AWS Management Console as the root user. The aws organizations close-account command is for member accounts in AWS Organizations, not arbitrary standalone accounts.

What AWS CLI command closes an Organizations member account?

Use aws organizations close-account --account-id 123456789012 from an appropriately authorized Organizations context. The request is asynchronous, so inspect the member's account State afterward rather than assuming the lifecycle completed instantly.

Why do I get ConstraintViolationException when closing an AWS account?

The exception means an Organizations constraint was violated; the attached reason is the important part. Closing the management account through the member-account API, exceeding the rolling closure quota, or hitting another account-lifecycle constraint can all lead you into this family of errors. Preserve the complete reason string.

What does CLOSE_ACCOUNT_QUOTA_EXCEEDED mean?

Your organization has reached its member-account closure allowance for the rolling 30-day period. As of October 2026, the limit is the higher of 250 accounts or 20% of member accounts, capped at 1,000. The quota is not adjustable.

Does the AWS account closure quota reset on the first day of the month?

No. It is a rolling 30-day window, not a calendar-month counter. Closures performed near the end of one month still count after the calendar moves into the next month until they fall outside that rolling window.

What does CLOSE_ACCOUNT_REQUESTS_LIMIT_EXCEEDED mean?

Too many account-close requests are being processed concurrently. Let existing asynchronous closure requests progress and complete before submitting more. This is separate from the rolling 30-day account-closure quota.

Why can my AWS Organizations member account not close itself?

Check inherited service control policies. Since July 10, 2026, organizations newly created through the AWS Organizations console can receive default account-departure controls that prevent member accounts from leaving the organization or closing themselves. The central organization administrator can modify the policy or perform the appropriate central lifecycle action.

Can I close an AWS Organizations management account with the CLI?

Not with the Organizations CloseAccount operation. First close or remove active member accounts. Then sign in to the management account itself as root and use its Account-page closure process.

Do I have to delete every EC2 instance and S3 bucket before closing AWS?

No. Manually deleting every ordinary resource is not required before account closure. You should still back up data you need, stop unnecessary usage, and handle subscriptions, domains, commitments, and other service-specific items deliberately before you lose normal access to the account.

Can AWS charge me after my account is closed?

Yes. A later bill can include usage incurred before closure. Active Reserved Instance and Savings Plans commitments can also continue billing until their terms expire. Closing the account does not erase charges that were already incurred or contractual commitments already made.

Does closing AWS automatically cancel Marketplace subscriptions?

No. AWS Marketplace subscriptions require separate cleanup. Terminate the relevant software instances and cancel subscriptions from the Marketplace subscription-management area instead of assuming account closure performs that cancellation for you.

Why is my closed AWS account still visible in Organizations?

A closed member account can remain visible with a CLOSED label during the 90-day post-closure period. Visibility does not mean the closure failed. Check the account State and the closure date.

How long can I reopen a closed AWS account?

The post-closure period is 90 days. Contact AWS Support as soon as possible if you need reinstatement during that window. After permanent closure, the account cannot be reopened and its account ID cannot be reused.

Why did I not receive the AWS account closure confirmation email?

The confirmation goes to the account's root email address. If it does not arrive within a few hours, sign in as root and inspect the account. For a member account, also check AWS Organizations for the CLOSED state. For a management account, recheck whether any active members remain.

The last check before you close the account

Once the actual blocker is gone, give yourself five quiet minutes before pressing the final button.

Confirm the 12-digit account ID. Confirm that you are closing the account you intended to close, not another member with a nearly identical display name.

Check whether any data needs to survive outside this account. A backup stored in the same account is not an independent backup for an account you are permanently retiring.

Check the root email address. If its domain is registered in this same account, remove that dependency before closure.

Review Marketplace subscriptions, Reserved Instances, Savings Plans, and any other commitment that can create charges after the day of closure.

If the account belongs to Control Tower, make sure it has been unmanaged.

If it is a member account, check the policy path and make sure the person or automation performing closure is intentionally authorized.

If it is the management account, verify there are no active member accounts left.

If MFA remains enabled, keep the device available during the 90-day post-closure period.

Then close the account using the route that matches its real role.

Jake's final question is less technical than the first one: "How do I know I'm not missing one more blocker?" Ethan's answer is the one worth keeping: "Stop looking for a mystery blocker. Name the account role, the identity, the organization state, the policy, and the lifecycle state. Once those are explicit, the mystery usually disappears."

If your AWS screen shows an error that is not covered here, copy its exact text before changing anything. The full exception, the account ID, and the account's role will give you a much better starting point than another round of deleting resources and hoping the button changes.

Revision note. Written October 3, 2026, after the Status field gave way to State. An account that refuses to close is usually waiting on one named blocker, and once you find it, the rest is a few clicks.