Large businesses and startups alike want to invest their time and energies in product and business development,...
which requires an efficient infrastructure that can meet changing business needs. Development teams that deal with multiple software releases often maintain separate AWS accounts for different use cases, such as testing, production and development.
AWS-focused developers can achieve a segregated but coherent infrastructure deployment in a number of ways. They can create separate AWS accounts and link them through the AWS Management Console. AWS also offers a unified view of resource charges across a group of accounts in a consolidated billing report.
The AWS Organizations service lets teams create centralized Service Control Policies that manage usage across multiple AWS accounts. In addition, enterprises can use services like AWS Identity and Access Management (IAM) roles and policies to create segregated accounts at the account-access level.
There are many methods to manage multiple AWS accounts; follow these strategies to keep enterprise cloud operations humming along.
Design infrastructure to match requirements
Every business has different -- and dynamic -- requirements. The right infrastructure architecture improves developer productivity to add value at any point in time.
For example, a startup using AWS might set up linked accounts to manage dev, quality assurance (QA), staging and production environments separately, but then pay from a single account. After a year, new product features tax the infrastructure and slow down deployments and builds.
The initial architecture could look like this:
In this scenario, the business keeps only two accounts to accelerate deployments and releases. After adjusting the architecture, it looks like this:
Keep in mind: There always are trade-offs. Using two accounts reduces complexity, but it also increases risk. When an AWS footprint grows, it becomes complex to manage.
Strike a balance
There is no one-size-fits-all model when designing and building a cloud architecture. Designs can isolate environments, workloads and even business units with a multiaccount strategy, enabling them to use the inherent resources and security boundaries of an AWS account.
IT teams should consider business needs and resource use -- now and in the future – when planning an architecture. These four infrastructure models have their own pros and cons for designing an architecture that supports AWS. IT teams should choose the one that best meets their specific needs.
Single account (fully centralized): In this architecture, a business uses a single AWS account in which all AWS resources reside. This model, which is less complex, works well for smaller businesses, has several drawbacks.
As an infrastructure grows, account limits must also increase. Configuration and resource changes can affect other workloads in a development environment, including production workloads. And erroneous changes to IAM policies or security groups affect the entire cloud deployment.
Autonomous model: This type of architecture uses multiple, unlinked AWS accounts. IT teams use this model to create autonomous business or IT functions that operate independently. The autonomous model, like the single-account model, is simpler to use and contains well-defined resource sharing within each account.
With this model, errors to policy changes only affect the account in which they occur. But standards, such as access control, could drift if administrators struggle to manage IAM policies across separate accounts.
Single-master hierarchical model: Administrators centralize governance and control spending, while retaining some autonomy for business units. Incorrect policy changes only affect individual accounts.
IT teams can delegate administrative control to the appropriate business units, project team or functions. But IAM management across multiple AWS accounts requires duplicate configuration, making for a complex task.
Multimaster hierarchical model: IT teams create multiple master-payer accounts, each with subordinate child accounts. The model, which works for very large businesses or enterprises, has a centralized governance model for each business unit or division and maintains desired separation among accounts.
With this model, erroneous IAM or security group policy changes only affect individual accounts. But administrators face a tough task with IAM management, which becomes exponentially more complex across multiple AWS master and subaccounts.
Wrangle AWS accounts with IAM groups and roles
Multifactor authentication bolsters AWS security
Third-party tool assists in AWS cloud management