Having an AWS Account is the first necessary step to using AWS. That account is tied to an email, phone number, and a credit card — and it gives you a place where you can create resources on AWS. Over time, for different reasons, people would create multiple AWS accounts. In 2017 AWS responded to this practice by releasing the AWS Organizations service to help manage the proliferation of AWS Accounts used to support a single organization.
When I was working in Cloud consulting in 2017 and we started using multi-account set-ups for our customers, I half-jokingly asked our VP of Engineering, “Can we go back to single account architectures? Multi-account is a huge pain in the butt.” Yes, it’s true that multi-account can add a lot of engineering work to managing your AWS environments, but there are good reasons for such a set-up. Enough good reasons that AWS even created an AWS Solution for managing multi-account setups called AWS Landing Zone.
So why should you care about a multi-account architecture for your AWS environments?
Increased Security: Minimize the blast radius of breaches
Being multi-account doesn’t bring any inherent security features, but it does minimize the blast radius in case of a security breach. This can be hugely important if you have development and staging environments that you’re using for building and testing new features. Having to do a full security audit before each iteration in your development process is unworkably onerous, but if an experimental feature deployed in your development environment was breached by a malicious actor, is your security tight enough to prevent that breach from escalating to your production environment? If your production environment is in its own dedicated account, separate from your development environment, that is a huge firewall between those workloads. Even if a malicious actor was able to escalate to full AWS Administrator privileges within your development account, there is no way to use those breached credentials in the production environment if it’s in a completely separate account.
Customers who are especially security-focused may create a special forensics account. If a security breach is detected on one of their virtual machines in their production account, a snapshot image can be taken of the compromised machine, the machine is then deleted and new, clean one created, and the compromised snapshot can be brought up in the forensics account, where it can be safely inspected from its own sandbox to determine how the breach happened without fear of malicious code being able to infect your other systems. This is the AWS equivalent of a medical clean room that is used for safely studying infectious viruses.
While many aspects of a multi-account architecture require increased configuration, when considering administrative isolation, multi-account can greatly decrease your configuration requirements. Consider a start-up developing a new feature who have hired an external group of consultants to build this feature for them. They’ve vetted the consultants to trust them to deliver robust, well-designed code, but they have little idea what kind of security practices those consultants use. AWS Identity and Access Management (IAM) is a wonderful service for creating Users, Roles, and Policies that dictate who can do what within an AWS account, but if a start-up wanted to ensure that their consultants were truly isolated within their own dedicated development environment and were running their production environment within that same account — then the creation (and auditing) of the needed IAM Roles and Policies to limit their permissions to just their own development environment is a massively time consuming process.
However, what if the start-up created a brand new account and provisioned a clone of their environment in there? Now they could completely side-step the morass of complex security policies, and even safely grant complete Administrator access to the external consultants, who would then have free rein to experiment ,including experimenting with new AWS services in the solution they built for the start-up. Creating a complete clone of your environment may sound like a massive (massive!) headache, but for those using 100% automated Infrastructure as Code solutions (like Waterbear Cloud’s AIM tooling), the creation of a new account and bringing up a cloned development environment is something that can usually be done in about an hour.
Simplify compliance requirements
Accounts can be firewalls be differing governance and compliance processes. Many organizations have special compliance or privacy considerations they need to apply to their data and processes. For example, sensitive patient health data or financial data need to be regulated by HIPPA or PCI compliance audits. Setting up the change management around environments that need to follow such compliance audits is a time consuming process. One these processes are in-place, changes to that environment can be tedious and onerous. However, if a company with a HIPPA-compliant workload also wanted to run a WordPress web site, an internal reporting tool, and other workloads that have no to access sensitive data and follow burdensome regulations, moving those workloads to their own distinct accounts completely sidesteps the need for them to participate in burdensome compliance processes.
Security Part 2: Backups, Logging, and Escrow
Creating backups that can be used for disaster recovery is another good use case for a multi-account architecture. If an account was compromised by a malicious actor, if logs and backups are automatically duplicated to a dedicated security account, then malicious actors are not able to modify the security logs to cover their tracks or delete all the existing backups and hold the company for ransom.
Customers especially sensitive to security around their logs and backups may also create a special security-escrow account. This is similar to a security account, except that no one in the IT or Ops teams has access to the security-escrow account. Typically the only people with the keys to this account might be elsewhere within the companies leadership, such as the CEO, COO, or CFO. This protects against worst-case security breach scenarios, such as a complete infiltration of your IT and Operations, where access to all your AWS Accounts are breached. By having no way for any operations people to access the security-escrow account, then there is a final line of defence against catastrophic security breaches.
Flexible Billing and Costing Options
AWS Organizations allows a company to roll up all its accounts’ bills into one single, central bill. Multi-account also enables better cost discovery, as you can see the billing costs for each individual account. The billing configuration is flexible for each account. For example, if a start-up wanted to collaborate with external consultants, they could take on the billing costs directly of the resources they use in their own development-consultant account.
Multi-Account with Waterbear Cloud
While there are increased engineering tasks to build and manage a multi-account architecture, the benefits are such that I’ve seen many organizations fund the costs of building out such architectures in the ballpark of $50k and sometimes north of $100k on their engineering team costs. AWS Landing Zone is one solution that helps reduce those engineering costs. However, at Waterbear Cloud it’s our mission to make managing cloud environments an exponentially better experience by creating innovative cloud solutions.
We liked the architectural design of AWS Landing Zone, but it’s a solution that needs it’s own mini-project to integrate with the rest of your cloud management project. We’ve experienced the pain of integrating and managing a cloud environment as a lot of small disconnected projects and we designed our open source AIM cloud orchestration software to seamlessly and easily integrate best practices such as multi-account architecture into the core tooling.
With Waterbear Cloud, adding a new account to your cloud project is as easy as adding a line of configuration and running a single command. Your baseline security tooling and other shared account configuration considerations are automatically applied to the new account. In addition, by having all your account information as semantic configuration, other tools and services driven by Waterbear Cloud can seamlessly integrate with your single source of account configuration.
We can now accomplish what was only a few years ago measured in tens of thousands of dollars and enabled those architectural best practices at a cost measured in hundreds of dollars. Through Waterbear Cloud innovations, we believe we can offer you a 10x cost reduction over traditional Infrastructure as Code project costs.
Interested in finding out more about how Waterbear Cloud can help guide you through your cloud journey? Ask us about a free consultation and insights into your cloud management strategy.