Best practices for multi-account management

Follow these recommendations to help walk you through setting up and managing a multi-account environment in AWS Organizations.

Topics

• Manage your accounts within a single organization
• Use a strong password for the root user
• Document the processes for using the root user credentials
• Enable MFA for your root user credentials
• Apply controls to monitor access to the root user credentials
• Keep the contact phone number updated
• Use a group email address for root accounts
• Group workloads based on business purpose and not reporting structure
• Use multiple accounts to organize your workloads
• Enable AWS services at the organizational level using the service console or API/CLI operations
• Use billing tools to track costs and optimize resource usage
• Plan the tagging strategy and enforcement of tags across your organization resources
• Best practices for the management account
• Best practices for member accounts

Manage your accounts within a single organization

We recommend creating a single organization and managing all your accounts within this organization. An organization is a security boundary that lets you maintain consistency across accounts in your environment. You can centrally apply policies or service-level configurations across accounts within an organization. If you want to enable consistent policies, central visibility, and programmatic controls across your multi-account environment, this is best achieved within a single organization.

Use a strong password for the root user

We recommend that you use a password that is strong and unique. Numerous password managers and strong password generation algorithms and tools can help you achieve these goals. For more information, see Changing the password for the AWS account root user. Use your business' information security policy to manage long-term storage and access to the root user password. We recommend storing the password in a password manager system or equivalent that meets the security requirements of your organization. To avoid creating a circular dependency, do not store the root user password with tools that depend on AWS services that you sign in to with the protected account. Whatever method you choose, we recommend that you prioritize resiliency and potentially consider requiring multiple actors to authorize access to this vault for enhanced protection. Any access to the password or its storage location should be logged and monitored. For additional root user password recommendations, see Root user best practices for your AWS account.

Document the processes for using the root user credentials

Document the execution of important processes as they are performed to ensure you have a record of the individuals involved in each step. To manage the password, we recommend using a secure encrypted password manager. It’s also important to provide documentation about any exceptions and unforeseen events that might occur. For more information, see Troubleshooting AWS Management Console sign-in in the AWS Sign-In User Guide and Tasks that require root user credentials in the IAM User Guide.

Test and validate that you continue to have access to the root user and that the contact phone number is operational on at least a quarterly basis. This helps to affirm the business that the process works and that you can maintain access to the root user. It also demonstrates that the people responsible for root access understand the steps they must perform for the process to succeed. To increase response time and success, it's important to make sure that all personnel involved in a process understand exactly what they must do in case access is needed.

Enable MFA for your root user credentials

We recommend that you enable multiple multi-factor authentication (MFA) devices to the AWS account root user and IAM users in your AWS accounts. This lets you raise the security bar in your AWS accounts and simplify managing access to highly privileged users, such as the AWS account root user. To meet different customer needs, AWS supports three types of MFA devices for IAM, including FIDO security keys, virtual authenticator applications, and time-based one-time password (TOTP) hardware tokens.

Each type of authenticator has slightly different physical and security properties that are best suited for different use cases. FIDO2 security keys offer the highest level of assurance and are phishing resistant. Any form of MFA offers more robust security posture than password-only authentication, and we strongly recommend that you add some form of MFA to your account. Select the device type that best aligns with your security and operational requirements.

If you choose a battery-powered device for your primary authenticator, such as a TOTP hardware token, consider also registering an authenticator that doesn't rely on battery as a back-up mechanism. Regularly checking the functionality of the device and replacing it before the expiry date is also essential to maintain uninterrupted access. No matter what type of device you choose, we recommend registering at least two devices (IAM supports up to eight MFA devices per user) to increase your resiliency against device loss or failure.

Follow your organization's information security policy for the storage of the MFA device. We recommend that you store the MFA device separately from the associated password. This ensures that access to the password and the MFA device requires different resources (people, data, and tools). This separation adds an extra layer of protection against unauthorized access. We also recommend that you log and monitor any access to the MFA device or its storage location. This helps detect and respond to any unauthorized access.

For more information, see Secure your root user sign-in with multi-factor authentication (MFA) in the IAM User Guide. For instructions about enabling MFA, see Using multi-factor authentication (MFA) in AWS and Enabling MFA devices for users in AWS.

Apply controls to monitor access to the root user credentials

Access to the root user credentials should be a rare event. Create alerts using tools like Amazon EventBridge to announce the login and use of the management account root user credentials. This alert should include, but should not be limited to, the email address used for the root user itself. This alert should be significant and hard to miss. For an example, see Monitor and notify on AWS account root user activity. Verify that personnel who receive such an alert understand how to validate that the root user access is expected, and how to escalate if they believe that a security incident is in progress. For more information, see Report Suspicious Emails or Vulnerability Reporting. Alternatively, you can Contact AWS for assistance and additional guidance.

Keep the contact phone number updated

To recover access to your AWS account, it is crucial to have a valid and active contact phone number that allows you to receive text messages or calls. We recommend using a dedicated phone number to make sure that AWS can contact you for account support and recovery purposes. You can easily view and manage your account phone numbers via the AWS Management Console or Account Management APIs.

There are various ways to obtain a dedicated phone number that ensures AWS can contact you. We strongly recommend that you obtain a dedicated SIM card and physical phone. Safely store the phone and the SIM long-term to guarantee the phone number remains available for account recovery. Also make sure the team responsible for the mobile bill understands the importance of this number, even if it remains inactive for extended periods. It is essential to keep this phone number confidential within your organization for additional protection.

Document the phone number in the AWS Contact Information console page, and share its details with the specific teams that must know about it in your organization. This approach helps minimize the risk associated with transferring the phone number to a different SIM. Store the phone according to your existing information security policy. However, do not store the phone in the same location as the other related credential information. Any access to the phone or its storage location should be logged and monitored. If the phone number associated with an account changes, implement processes to update the phone number in your existing documentation.

Use a group email address for root accounts

Use an email address that is managed by your business. Use an email address that forwards received messages directly to a group of users. In the event that AWS must contact the owner of the account, for example, to confirm access, the email message is distributed to multiple parties. This approach helps to reduce the risk of delays in responding, even if individuals are on vacation, out sick, or leave the business.

Group workloads based on business purpose and not reporting structure

We recommend that you isolate production workload environments and data under your top-level workload-oriented OUs. Your OUs should be based on a common set of controls rather than mirroring your company’s reporting structure. Apart from production OUs, we recommend that you define one or more non-production OUs that contain accounts and workload environments that are used to develop and test workloads. For additional guidance, see Organizing workload-oriented OUs.

Use multiple accounts to organize your workloads

An AWS account provides natural security, access, and billing boundaries for your AWS resources. There are benefits of using multiple accounts because it lets you distribute account level quotas and API request-rate limits, and additional benefits listed here. We recommend that you use a number of organization-wide foundational accounts, such as accounts for security, logging, and infrastructure. For workload accounts, you should separate production workloads from test/development workloads in separate accounts.

Enable AWS services at the organizational level using the service console or API/CLI operations

As a best practice, we recommend enabling or disabling any services you’d like to integrate with across AWS Organizations using that service’s console, or API operations/CLI command equivalents. Using this method, the AWS service can perform all required initialization steps for your organization, such as creating any required resources and cleaning up resources when disabling the service. AWS Account Management is the only service that requires use of the AWS Organizations Console or APIs to enable. To review the list of services that are integrated with AWS Organizations, see AWS services that you can use with AWS Organizations.

Use billing tools to track costs and optimize resource usage

When managing an organization, you get a consolidated bill that covers all charges from accounts in your organization. For business users who need access to cost visibility, you can provide a role in the management account with restricted read-only permissions to review billing and cost tools. For example, you can create a permission set that provides access to billing reports, or use the AWS Cost Explorer Service (a tool for viewing cost trends over time), and cost-efficiency services such as Amazon S3 Storage Lens and AWS Compute Optimizer.

Plan the tagging strategy and enforcement of tags across your organization resources

As your accounts and workloads scale, tags can be a useful feature for cost tracking, access control, and resource organization. For tagging naming strategies, follow the guidance in Tagging your AWS resources. In addition to resources, you can create tags on the organization root, accounts, OUs, and policies. Refer to the Building your tagging strategy for additional information.