Fotolia
AWS multi-account management best practices with Control Tower
With the help of AWS Control Tower, organizations who own and operate multiple cloud accounts can manage them all under one roof -- but not without challenges.
Enterprises that are heavy users of AWS often struggle to maintain oversight amid a proliferation of corporate accounts. Amazon added AWS Control Tower to address this issue and give admins the ability to manage multiple cloud accounts through one interface, but there's a catch for long-time users.
A cloud account represents the fundamental relationship between a cloud provider and an enterprise. It outlines the key parameters used to define permissions and administer billing, users, security, reporting and so on. As the use of the public cloud expands across groups and large-scale deployments within organizations, account management becomes more complex.
In many cases, an enterprise will have business-side rules, policies and processes necessary to separate different constituencies across the business. One way to simplify a broad and diverse base of public cloud users is to implement multiple cloud accounts. This assigns one account to each principal usage group where users, service permissions, billing and other aspects of the account might differ substantially from other groups. Using multiple, smaller accounts has many benefits, including:
- simplified auditing;
- greater portability if an organization opts to migrate to another cloud; and
- faster responses to security breaches by identifying and isolating the account that was used inappropriately.
And while a service like Control Tower might to be the answer for organizations that struggle to manage multiple cloud accounts, it's important to understand the service's limitations. Let's review some best practices for multi-account management in AWS and review the hurdles that might prevent some enterprises from using this service.
AWS Control Tower
Control Tower is a service designed to assist organizations in AWS multi-account management within AWS cloud environments.
AWS Control Tower establishes blueprints, which are policies a company's accounts must adhere to. The blueprints encapsulate workflows and best practices for identity and access management, security, monitoring, logging and so on. Policies are enforced through rules called guardrails, and policy violations are detected and reported through AWS Config rules that govern new and existing accounts. A policy dashboard outlines the primary policies of the AWS Control Tower environment and provides details about provisioned accounts, relevant guardrails and compliance status for each account.
Although the premise of AWS Control Tower is compelling, the service has notable limitations. The primary concern is the overall requirement for new accounts. AWS Control Tower does not currently support existing accounts or sub-accounts, so enterprises that already use AWS will need to create or re-create accounts from scratch to operate them through Control Tower.
Also, any organization that wants to adopt AWS Control Tower should be mindful of potential surprises that could arise as they fold in more native service. Each AWS service imposes its own usage limits -- or quotas, as AWS calls them. For one example, AWS Lambda has per-region limits of 1,000 concurrent executions, 75 GB of storage and 250 elastic network interfaces per VPC. There are also functional quotas in memory, timeouts, space allocated to environment variables, space for policies, burst concurrency, invocation frequency, payload size and more.
But in addition to Lambda, an IT team might want to use AWS Control Tower with AWS CloudTrail, AWS SSO, AWS Identity and Access Management (IAM) and many other services -- each with its own unique quotas. As AWS Control Tower begins to interact with a large number of Landing Zones, some organizations might struggle to set them up due to the myriad practical service quotas. AWS Support is usually best able to help examine quota usage, and resolve or extend quotas where possible.
Some Amazon cloud services or settings may not be fully compatible with AWS Control Tower. One noteworthy example is AWS Organizations. This tool also offers multi-account management, doing so through groupings called organizational units, or OUs. Admins can establish permission guardrails in AWS Organizations, but Control Tower doesn't support OUs created outside of the service. Thus, preexisting OUs are basically not supported in AWS Control Tower.
One of the best approaches for AWS Control Tower adoption is to start small with new account deployments and build out your use of the service over time. It is not necessarily appropriate for existing, large multi-account deployments.
Multi-account best practices
In spite of such management challenges, there are still meaningful best practices that can help to facilitate multi-account environments in Amazon's cloud.
Select regions carefully
When consolidating multiple accounts through a tool such as AWS Control Tower, the selection of a "home" region is particularly important since the accounts generated through the tool will be created within the selected region. Not all Amazon cloud services are available in every region, so make sure to create accounts in regions where all of the services and resources needed to deploy a workload are available.
It can also be helpful to create accounts in multiple regions so resources and workloads can be deployed closer to users. However, an organization may be subject to regulatory restrictions on where data and workloads can be deployed. Admins that oversee multi-account management in AWS must understand which regions are viable under their corporate governance model and ensure users comply with those restrictions.
Clarify resources
Organizations that use and manage multiple account users and managers can find it frustrating that resources and services available in one account might not be available in other accounts. When an account is created, it is the responsibility of the account administrator to only enable access to the resources needed to support services and workloads under that account. This reduces costs and limits possible attack vectors. It's vital to communicate those parameters to users of each account.
Some organizations opt to standardize a minimum suite of services to establish a common foundation of resources for all accounts, but the onus is typically on the account owners to delineate what is -- or is not -- available.
Tools such as AWS access advisor and AWS IAM policy simulator can help to identify and clarify the permissions assigned to users, while AWS CloudTrail and other log tools can help to recognize and review the actions taken by any entities.
