Managing complex architectures is entirely possible in public clouds, and on Amazon AWS, but how do you do it properly? When migrating from on-premises or starting a new project on AWS, you will wonder how you should set things up and how to organize your account.

Many approaches are possible, but over time, it has become evident that managing multi-tier applications in a single AWS account, which was actually commonplace originally, 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 one account for development, one for staging and integration, and another for the production and live environment. In fact, you should also consider to have separate accounts for logging, and for backups, so that a compromised account will not mean the intruder gets to delete your backups or view and modify your logs, covering their intrusion.

This sounds complex, and yes, this is certainly more complex to set up 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 it was some years ago. 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 to carry out well-architected reviews twice a year to ensure your AWS environments are still in line with the current – and future AWS 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!