How do you keep track of your cloud environments and can you set up rules to guard against the worst mistakes? We’ll give you an idea based on our own experience and AWS standard recommendations. We will cover the typical concepts used, organizing environments, access control, ensuring compliance, and the associated tools.

New servers? No problem!

Setting up environments for different purposes is easy in AWS. Do you need servers and database for a business application? Check. Need a test environment for it? Done. Are you experimenting with something new? No problem at all.

It is is easy, and if you can even figure out how to code a little to automate the process, you can build a lot of infrastructure in no time. And it’s natural that more employees (e.g. Anne, Frank and Arne) get access to be able to work and experiment – the whole idea is for people to be self-reliant.

When the honeymoon ends

But then there’s the other side of the coin. Because maybe Anne has a good grasp of AWS and is very security conscious. And she has also told Frank and Arne how to do it “right”. But in the heat of the moment, it’s much easier for Arne to “just” go into the console and spin up a few test servers. And maybe make them “X-Large” just in case. And maybe it’s faster to enable the username/password on the server instead of the certificate, which is a bit cumbersome to download from the shared drive (where it should never be), just as a favor to Frank, who can never remember where it is.

And then there’s the matter of remembering to delete those servers again when they’re no longer needed…

What to do?

Let’s get the basics right

AWS defines some abstractions that are useful to know when setting up your environments. The most basic ones are Accounts, Organizations and Organizational Units (OUs). In addition, the term workload is used to refer to a collection of resources (e.g. servers and databases) and application code that supports a system that brings business value (e.g. a customer-facing web application or an internal CRM system).
Workloads and associated infrastructure are recommended to be provisioned and managed in different accounts. An account is an administrative unit to which differentiated access can be granted. Accounts can be organized into Organizations, for which OUs can be used to group and manage accounts as a single unit.

Wow, that’s a lot of new concepts… Let’s look at how it can be implemented in practice:

Example of organizing accounts with Organizations and Organizational Units

As shown in the diagram above, one account and one OU are created per application environment (development, test and production) for each given system/workload. The main reasons for making this division are to tighten access to the specific application environments and to minimize the blast radius, which defines the maximum damage that can occur in the event of a system failure or human error. For example, an error click in the console in a development environment that Arne may negligently cause should not affect the test or production environment. More generally, minimizing the blast radius for individual workloads in isolated accounts reduces the chance of cross-environment errors.

An Organization also has a root account, where it is possible to consolidate invoicing, so you can get an overview of what you have consumed in all accounts. You can get one invoice for services used throughout the organization, which can then also be used for procurement and internal settlement in the company. Since it doesn’t cost anything to open an account, it’s ideal to use them to split workloads.

AWS Control Tower

The organization described in the previous section may seem complicated at first glance, and you may think it’s difficult to manage and maintain all accounts. So how do you keep track of them all? And how do you control user access to each account? And how can you ensure all accounts are compliant with required rules for e.g. data encryption and logging? This is where AWS comes to the rescue with their AWS Control Tower service.

AWS Control Tower is an incredibly powerful tool that ensures environments are built and maintained with security and compliance best practices. Below is an outline of the essential features:

• User management and access control for the different accounts is managed using AWS Single Sign-On (AWS SSO) and Identity Access Management (IAM). This service can be integrated with Microsoft Active Directory, Google Workspaces, etc. so that existing user accounts and access control groups can be used in AWS.
• A centralized and cross-site audit logging system ensures that user activity, API usage, and the configuration of resources in all accounts are logged and stored using AWS CloudTrail and AWS Config.
• A cross-access system is set up using IAM and AWS SSO so security audits can be performed across accounts.
• AWS Control Tower comes packaged with many standard governance rules (so-called “guardrails”) that aim to enforce policies and report violations. For example, ensuring that audit logging is enabled on all accounts and logs cannot be deleted.
  In addition, it is possible to extend this setup with custom rules using Service control policies (SCPs) and AWS Config. For example, you may want to enforce that data on all servers is encrypted on all accounts in an OU for a production workload.

Key takeaways

We hope the above has given you an overview of basic concepts and services that secure the environments. The key takeaway should be that AWS has invested heavily in enabling customers to build well-organized structures that support a high degree of transparency and enable automated compliance checks with the rules you as a company (or your customers) set up.