Best practices for a multi-account environment
Follow these recommendations to help walk you through setting up and managing a multi-account environment in Amazon Organizations.
Account and credentials
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 Amazon Web Services 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 Amazon 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 Amazon Web Services 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 Amazon Web Services Management Console sign-in in the Amazon 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 Amazon Web Services account root user and IAM users in your Amazon Web Services accounts. This lets you raise the security bar in your Amazon Web Services accounts and simplify managing access to highly privileged users, such as the Amazon Web Services account root user. To meet different customer needs, Amazon 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 Amazon and Enabling MFA devices for users in Amazon.
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 Amazon Web Services account root user activity
Keep the contact phone number updated
To recover access to your Amazon Web Services 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 Amazon can contact you for account support and recovery purposes. You can easily view and manage your account phone numbers via the Amazon Web Services Management Console or Account Management APIs.
There are various ways to obtain a dedicated phone number that ensures Amazon 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 Amazon 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 Amazon 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.
Organization structure and workloads
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.
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 Amazon Web Services account provides natural security, access, and billing boundaries for your Amazon 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.
Service and cost management
Enable Amazon 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 Amazon Organizations using that service’s console, or API operations/CLI command equivalents. Using this method, the Amazon service can perform all required initialization steps for your organization, such as creating any required resources and cleaning up resources when disabling the service. Amazon Account Management is the only service that requires use of the Amazon Organizations Console or APIs to enable. To review the list of services that are integrated with Amazon Organizations, see Amazon Web Services services that you can use with Amazon 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
Amazon Cost Explorer Service (a tool for viewing cost trends over time), and
cost-efficiency services such as Amazon S3 Storage Lens
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 Amazon 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.