Multiple AWS accounts without complexity

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

Many approaches are possible. Originally, it was common to manage multi-tier applications in a single AWS account. Today we know that this is neither secure nor manageable.

Instead, you should set up separate AWS accounts for each individual environment:

For each project, you should have a separate account for development, staging, integration, production and live environment. You should also consider separate accounts for logging and backups. This way, the intruder can't delete your backups or change your logs to cover up their intrusion. This sounds complicated, and yes, it's certainly more complicated than placing all resources in a single account. In the meantime, AWS has evolved a lot. Therefore, managing different accounts or enabling permissions across account boundaries is much easier than it used to be. This offers significant advantages in terms of both security and manageability. We therefore recommend distributing your digital production platform across multiple AWS accounts.

The most important improvement that AWS has developed over time is that the central authorization management service, called IAM, can enable fine-grained authorization management for both "human" and technical (machine) users across account boundaries. Of course, authorization management can quickly get out of hand in such large environments, which is why AWS Control Tower was introduced. This can be understood as a user-friendly presentation and management front-end that gives you back control even when there are hundreds or thousands of policies, dozens or hundreds of IAM users, dozens of AWS accounts and complex organizations.

Apropos:

Organizations are another feature that has been introduced in the recent past. They help you structure your AWS accounts and apply corporate 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 wonder how this works with policies set for individual accounts, as these could conflict. Organization policies override accounts when conflicting policies are defined.

While Control Tower can help you set up your Landing Zone to reflect these best practices and detect and warn against deviations from your original definitions, it's a known fact that environments evolve, and what initially seemed to make sense can become an unmaintainable beast that no longer follows best practices. For this reason, it makes a lot of sense to perform well-designed reviews on a regular basis - make sure your architecture is still following current (and changing) AWS best practices.

We recommend a well-designed audit twice a year to ensure your AWS environments are compliant with current and future best practices. When was the last time you had a third party review your AWS account infrastructure? Our solution architects and engineers trained in AWS security will be happy to assist you.

So you better call Alice&Bob.Company!