Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Best practices for member accounts

Follow these recommendations to help protect the security of the member accounts in your organization. These recommendations assume that you also adhere to the best practice of using the root user only for those tasks that truly require it.

Define account name and attributes

For your member accounts, use a naming structure and email address that reflects the account usage. For example, Workloads+fooA+dev@domain.com for WorkloadsFooADev, Workloads+fooB+dev@domain.com for WorkloadsFooBDev. If you have custom tags defined for your organization, we recommend that you assign those tags on accounts that reflect account usage, cost center, environment, and project. This makes it easier to identify, organize, and search for accounts.

Efficiently scale your environment and account usage

As you scale, before creating new accounts, make sure accounts for similar needs do not already exist, to avoid unnecessary duplication. Amazon Web Services accounts should be based on common access requirements. If you are planning to reuse the accounts, such as a sandbox account or equivalent, we recommend that you clean up unneeded resources or workloads from the accounts, but save the accounts for a future use.

Before closing accounts, note that they are subject to close account quota limits. For more information, see Quotas for Amazon Organizations. Consider implementing a cleanup process to reuse accounts instead of closing them and creating new ones when possible. This way, you will avoid running into incurring costs from running resources, and reaching CloseAccount API limits.

Use an SCP to restrict what the root user in your member accounts can do

We recommend that you create a service control policy (SCP) in the organization and attach it to the organization's root so that it applies to all member accounts. For more information, see Secure your Organizations account root user credentials.

You can deny all root actions except a specific root only action that you must perform in your member account. For example, the following SCP prevents the root user in any member account from making any Amazon service API calls except “Updating a S3 bucket policy that was misconfigured and denies access to all principals” (one of the actions that requires root credentials). For more information, see Tasks that require root user credentials in the IAM User Guide.

{
 "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "NotAction":[

            "s3:GetBucketPolicy",

            "s3:PutBucketPolicy",

            "s3:DeleteBucketPolicy"

                 ],

            "Resource": "*",

            "Condition": {
 "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }

            }

        }

    ]
 }

In the majority of circumstances, any administrative tasks can be performed by an Amazon Identity and Access Management (IAM) role in the member account that has relevant administrator permissions. Any such roles should have suitable controls applied to limit, log, and monitor activities.