How to prevent member accounts from leaving your AWS organization

When you start in AWS, you probably start small.

You open an account and start trying out services, building PoCs, and understanding how everything works before committing to designing environments to host your production workloads.

Other teams hear that you have AWS access and start requesting access to the same account to also build PoCs for their specific use cases. But soon the account starts to get messy: resources from different teams are scattered everywhere, and teams see their PoCs impacted by others deleting resources. So, you start looking for a better solution.

You then create a second standalone account, and then a third, and a fourth. You grant access to each team so that everyone has environments completely isolated from each other.

However, you soon realize that dealing with separate billing, security, and governance across multiple accounts is a pain, so you start looking for a better alternative again.

You start exploring AWS Organizations. You create one org and invite each of the standalone accounts so you can now benefit from consolidated billing, access to org-wide discounts, enhanced governance, and improved security.

But just as easily as the AWS accounts joined, they can also leave your organization, which represents a significant security problem.

Think about the consequences of having an AWS account with access to sensitive information suddenly becoming independent. You lose all your governance and security controls that were implemented at the organization level.

So, you start thinking about implementing security controls to prevent this.

When it comes to security, the best approach is having a layered defense. Just in case one fails, another is active to protect the fort.

The first control that we can implement is tied to the Principle of Least Privilege. Closing an account or leaving an organization are highly sensitive operations, and nobody should have enough permissions to perform them. It could be argued that you could have a handful of privileged users in case of an emergency, and that's fine as long as you accepted the risk. Just make sure that those privileged users are highly restricted and monitored.

The specific permissions you should restrict are:

• organizations:LeaveOrganization
• account:CloseAccount

So, simply don't add them to any IAM policy.

The second control would be at the org level via a Service Control Policy (SCP). These are organizational policies that let us control the maximum permissions principals can have across the organization. They act as guardrails and are enforced in every single AWS account in your organization, assuming you have attached them at the root level.

The following SCP blocks principals in your organization from closing accounts and from attempting to remove member accounts from the organization.

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

The good thing is that if you created an AWS Organization via the AWS console after July 10, 2026, an SCP is created for you and attached at the root level to prevent this very same concern. If you did it before that date, or used the API, you will still need to manually configure the SCP.