Last updated on February 6th, 2023 at 2:37pm
We've long been an advocate of the multi-account cloud approach at cloudtamer.io. In this post, I'll share the reasons why you're much better off with more, rather than fewer, accounts.
A Good Idea at the Beginning
When companies started moving workloads from on-prem to cloud providers like AWS, Azure, and Google, many of them adopted the single account or monolithic account strategy. This is where more than one workload (or all your workloads) live in a single cloud account. Rightfully so because this was the messaging by cloud providers who wanted to reduce complexities for customers and make the experience less overwhelming. A single account is easier to get our arms around.
Of course, more and more workloads moved to the cloud. Organizations found it increasingly difficult to effectively manage workloads out of the same account.
Let's review a few of the challenges you'll hit as you grow. For this post, I'm defining a workload as a lifecycle environment for an application. For example, three workloads could be: a development (dev), staging, and production (prod) web application. Smaller companies may want to combine dev and staging into a single workload, but prod should always be separated for the reasons I'll detail below.
Managing Account Limits
AWS, Azure, and Google have soft and hard limits you need to stay within:
The cloud is a great tool for builders because you can spin up what seems like endless resources to help your applications scale and handle any type of load from customers. In reality, there are limits that you need to respect or you risk hampering the full potential of your workloads or, worse, you risk production downtime.
Luckily, the limits for single workloads rarely exceed the capacity of a single account. However, as the number of workloads in a single account increases, you can easily reach those limits. The soft limits may require a quick support ticket or an increase request to the cloud provider. You can usually increase your soft limits up to the hard limits.
The hard limits cannot be increased by even the cloud providers themselves. Those hard limits can help inform your decisions about what defines a good architecture. Instead of spinning up more small virtual machines until you reach the hard limit, you can increase the size of your current instances to handle the customer demand. Larger instances can handle more requests, process more data, and reduce your processing time, but your application needs to support the increased hardware available to it. This is where software and hardware teams need to work together to architect a solution that can scale well as the demand increases. By separating your workloads into multiple accounts, you are less at risk of hitting the cloud provider service limits.
Build Once, Deploy Everywhere
A best practice when architecting the deployment strategy for your application is to build it so that it can be deployed reliably every time. The simpler the deployment, the easier it will be to test and maintain. Each of the cloud providers has a template-based deployment method:
The goal is to create a template where your deploy process into dev or prod is the same. You should have parameters that you can easily change: the number of nodes or the size of the nodes to help reduce costs in dev or staging environments. However, the architecture should not change because you need to ensure all tests that you run in a dev or staging environment will get you the same results in a prod environment.
By separating out your environments with a multi-account cloud approach, you'll have the positive side effect of determining if you're missing any dependencies. You've probably had the experience of building an application in an environment, testing in the same environment, then deploying to a completely new environment where things don't quite work as expected. You later found out that a developer didn't document a change to a permission or a new package they installed in the dev environment and it never made it to the prod environment. Multiple accounts provide your development team with a clean separation that ultimately makes your application more reliable.
Accidental Misconfigurations
Picture this: you have 25 workloads running in a single cloud account. A new member of your operations team accidentally creates a new role with administrator access. This same team member then runs a cleanup script using the new role that is only supposed to affect resources in the dev environments he has access to. Unfortunately, since the role has administrator access, the script tries to clean up the prod environments as well. Needless to say, running all your workloads in the same account increases your risk of a single misconfiguration bringing your business to a halt.
Separate out those workloads to ensure the new operations team member doesn't have access to modify permissions in your prod accounts. That way, an accidental change has a much smaller impact. We call this limiting your "blast radius". Ask yourself, what is the most dangerous outcome if someone incorrectly configures a permission? Your answer will be a good way to determine the level of risk across your organization and cloud accounts.
Hack Attack!
Let's suppose you don't have any misconfigurations, but you do have a single cloud account with 25 applications running. One of those applications is a web server that is exposed to the internet by design. All is well until the web server on the virtual machine isn't updated frequently enough and an exploit is released for the same version of the web server. Now, bots are ruthlessly searching the internet for any vulnerable web servers so they can exploit the weakness. Once the hacker receives notification from the bot that it found a hackable web server (your application), the hacker sneaks into the virtual machine and compromises all 25 applications running in the same account (assuming other hardening mechanisms are not applied properly).
For this scenario to play out to its full potential, there will need to be a few weaknesses in the overall architecture of the environment, but this is good example of how a single account strategy can pose significant risk for a growing business. Separating those workloads into multiple accounts allows you to more easily harden your production environment so, in the event of compromise, it's an isolated incident that doesn't affect your other accounts and workloads.
Multi-Account Cloud is Now a Struggle, Right?
As you plan your multi-account cloud strategy, you'll quickly realize all the work you performed in that one account has to be reproduced in every account. The cloud providers now have tools to make that easier, but those tools typically don't work across cloud providers. Those tools may have some gaps as well. Cloud providers typically provide 80% of the tools to get you where you need to go. The other 20% is typically up to you to figure out because there are customizations and use cases that are unique to you.
And here comes the pitch: cloudtamer.io delivers the remaining 20% percent (that's ultimately going to take up 80% percent of your time - thanks Pareto principle). Whether it's managing your growing number of cloud accounts, your fluid financial landscape, or helping you reach a compliance standard, we can help. Request a demo to learn more.
About the Author
Joseph Spurrier
Joe was previously the CTO at Kion.
