Your single default Amazon Virtual Private Cloud (Amazon VPC) might be a good way to start prototyping, but depending on the workloads you are managing, it can easily get complex and may require a lot of manual work on your part.
In this blog, we’ll take a look at the advantages of having multiple VPCs, and how AWS Organizations provide fine-grained control of multiple AWS accounts. (In an upcoming blog, we’ll cover AWS Control Tower, a service announced at AWS re:Invent 2018, that configures AWS Organizations to create a multi-account environment.)
You can create multiple VPCs within the same region or in different regions, in the same account or in different accounts. A multi-VPC architecture enables you to isolate environments.
Some things to consider:
How do you move from the mayhem of having your entire infrastructure on a single Amazon VPC to the harmony of multiple-VPC control? I’ll illustrate this with an example of a project I worked on.
The company had about 15 services running in their default VPC – all running in public subnets. Because of this setup, everything was accessible from everywhere, and network access restrictions were achieved by security group rules.
Since this wasn’t the ideal setup, we started to remediate it.
We realized that our initial separation between stage, integration, and prod VPCs wasn’t going to be enough. So, we started thinking about separating it into more than eight VPCs. As you are probably thinking, that sounds like a bit of overkill. We needed to find a better way to separate environments by network, user permissions, and cost that would allow us to maintain fine-grained control over everything without losing track of the big picture.
Manually managing multiple accounts is a hassle. Creating cross-account IAM roles on each of your accounts and then managing custom IAM policies on all those accounts is too much work. Just managing two accounts that way sounds way too tedious to me. (Imagine having more than that!) If that was the only way, I wouldn’t want to do it.
The better way? Use AWS Organizations to enable policy-based management of multiple AWS accounts. AWS Organizations eliminate all that manual setup. It even allows you to provision AWS accounts on demand and automatically adds them to your organization. Pretty cool, but should you go for it?
First, we need to evaluate the level of effort required for each solution – multiple VPCs vs. multi-account. If you choose to go multi-account after considering all the pros and cons, then you should start implementing it right away. If you are not sure, here are some indicators that point to a need for AWS Organizations:
As I mentioned before, cross-account roles are a lot of work. They are the obvious choice when you need access to AWS accounts that you don’t own. But if you own all the accounts, there are better ways.
You can manage the users for all your accounts from the root account using AWS Single Sign-on (SSO). It integrates perfectly with AWS Organizations and takes care of all the setup. You only create the users in one account, then assign who has permissions to access which account and which IAM role they will be allowed to assume when doing so. These roles only need to be created and managed from the root account of your organization.
If you don’t want to use AWS SSO, then there are still other solutions. Many third-party tools achieve the same goal of allowing you to manage access to many AWS accounts from a centralized location. Here are a few examples:
While securing user access to all your AWS accounts using SSO is a good practice, what happens if somehow someone manages to create a user in one of your accounts, allowing them to bypass your SSO altogether and enter directly into one of your accounts? That would be a huge security breach!
What if you could restrict the permissions of an AWS account, not only the permissions of users? You can achieve just that using Service Control Policies (SCPs), a feature of AWS Organizations. You can apply one or more SCPs to any account in your Organizations. These policies will allow or deny access to AWS services within an account.
To help us implement this, we need to understand that AWS accounts in an AWS Organization can be in two states – SCPs Enabled or Disabled. When SCPs are disabled, accounts in an Organization can make use of all AWS services. Things change when SCPs are enabled. If enabled in your root account, AWS will create a default SCP called “AWSFullAccess” and assign it to all accounts in the organization. You can create your own SCPs allowing or denying access to AWS services. If you were to assign a policy denying access to S3, for example, it wouldn’t matter if a user in that account has Administrator Access; they would not be able to use S3 at all because of the SCP.
There are a variety of ways to achieve proper security and establish order among your AWS cloud resources. If, after reading this, you think that going multi-account with AWS Organizations is the solution for you, then I encourage you to start planning. While it may be a lengthy process depending on the current amount of resources you have, once you’ve completed it you’ll have fine-grained control of your multiple AWS accounts.
Need help implementing AWS Organizations? The nClouds team is here to help with that and all your cloud security requirements.