How do you keep track of your cloud environments, and can you set up some rules that guard against the worst blunders? We will give you a quote on that – based on our own experience and AWS standard recommendations. We will get into the typically used concepts, organization of 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 a database for a business application? Check. Need a test environment for that? Done. Are you going to experiment with something new? No problem.

It’s easy, and if you can even figure out a little code to automate the process, you’ll get a lot of infrastructures built in a flash. And, naturally, more employees (e.g., Anne, Frank, and Arne) get access to work and experiment – the whole idea is that people should be self-sufficient.

When the honeymoon days end

But then there is the other side. Maybe Anne has reasonable control of AWS and is very safety conscious. And she has also told Frank and Arne how to do it “right”. But it’s much easier for Arne to “just go” into the console and spin up a few test servers in the heat of battle. And maybe make them “X-Large” just in case. And perhaps it’s faster to enable username/password on the server instead of that certificate, which is a bit difficult to download from the shared drive (where it should never be, by the way), just as a service for Frank, who can never remember where it’s located.

And then it’s just a matter of remembering to delete those servers again when they are no longer needed…

What to do?

Let’s get to grips with the basics

AWS defines some abstractions that are useful to know when setting up your environments. The most basic are Accounts, Organizations, and Organizational Units (OUs). In addition, the term workload is used, which covers a collection of resources (e.g., servers and databases) and application code, which 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 commissioned 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 you can use OUs to group and manage accounts as a single entity.

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

Example on organizing accounts with Organizations and Organizational Units

The diagram above shows that an account and an OU per application environment (development, testing and production) have been created for each given system/workload. The main reasons for making this breakdown are to sharpen access to the specific application environments and minimize the “blast radius”, which defines the maximum damage that can occur in a system failure or a 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, the chance of cross-cutting errors in the different settings is reduced by minimizing the blast radius to the individual workloads in isolated accounts.

An Organization also has a root account, where it is possible to consolidate invoicing to get an overview of what you have consumed in all accounts. You can get one invoice for the services used throughout the organization, which can thus also be used for procurement and internal settlement. Since it does not cost anything to open an account, it is obvious to use them for splitting workloads.

AWS Control Tower

The organization described in the previous section may seem complicated at first glance, and you may think it is challenging to manage and maintain all accounts. So how do you keep track of them all? And how do you manage user access to the individual account? And how to ensure all accounts are compliant with required rules e.g., data encryption and logging? Here, AWS comes to the rescue with its AWS Control Tower service.

AWS Control Tower is a potent tool that ensures that environments are built and maintained with best practices within safety and compliance. The essential features are outlined below:

• User management and access control for the various accounts are managed using AWS Single Sign-On (AWS SSO) and Identity Access Management (IAM). It is possible to integrate this service 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-cutting 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-cutting access system is set up using IAM and AWS SSO to perform security audits across accounts.
• AWS Control Tower comes packed with many standard governance rules (so-called “guardrails”) to enforce policies and report violations. For example, it can ensure that audit logging is turned on in all accounts and logs cannot be deleted. It is possible to extend this setup with its own rules using Service control policies (SCPs) and AWS Config. For a production workload, it can e.g. be that one wants to enforce that data on all servers is encrypted on all accounts in an OU.

Key takeaways

We hope the above has provided an overview of basic concepts and services that secure the environment. The most important 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 control of compliance with the rules you as a company (or your customers) set.