Multiple AWS Accounts without complexity

Managing complex architectures is entirely possible in public clouds, and on Amazon AWS, but how do you do it properly? How you should set things up? And how should you organize your account?

Many approaches are possible. Originally it was commonplace to manage multi-tier applications in a single AWS Account. At present we know this is neither secure nor manageable.

Instead, what you should do is to set up separate AWS accounts for every distinct environment:

For each project have an individual account for development, staging, integration, production and live environment. Further, you should also consider to have separate accounts for logging, and backups. This way the intruder will not be able to delete your backups or modify your logs to cover their intrusion. This sounds complex, and yes, this is certainly more complex than placing all resources in a single account. In the meantime, AWS has evolved a lot. Thus, the management of diverse accounts or the enabling of permissions across account boundaries is much easier as ealier. Which provides substantial benefits regarding both security and manageability. Therefore we recommend spreading your digital production platform across multiple AWS accounts.

The core improvement AWS has developed over time is how the central permissions management service, called IAM, can enable fine-grained permissions management for both “human” and technical (machine) users across account boundaries. Of course, permission management in such large environments can quickly get out of hands, which is why AWS Control Tower was introduced. This can be understood as a human-friendly presentation and management frontend which gets you back into control, even when there are hundreds or thousands of policies, dozens or hundreds of IAM users, dozens of AWS accounts, and complex organizations.

Speaking of which:

organizations are another feature that was introduced in the recent past. They help you to structure your AWS accounts, as well as to apply company policies to all accounts and organizational units. For example, you could enforce that all users set up multi-factor authentication or that EC2 instances can only be created in a specific AWS region etc. You may be wondering how this works out with policies set on single accounts since they could be in conflict. Oganizational policies will override accounts if conflicting policies are defined.

While Control Tower can help you set up your Landing Zone in a way which takes this best practices into account and can detect and warn about deviations from what you defined originally, it is a well known fact that environments evolve, and what seemed to make sense initially can become an unmaintainable beast, which no longer follows best practices. This is why it makes a lot of sense to carry out regular well-architected reviews – ensure your architecture is still in line with current (and changing) AWS best practices.

We recommend a well-architected review twice a year to ensure alignment of your AWS environments current and future best practices. When was the last time you had a third party carry out a review of your AWS account infrastructure? Our AWS security trained solution architects and engineers would be pleased to support you.

So better call Alice&Bob.Company!