In the beginning, there was nothing but the default VPC
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.)
Considerations for a multi-VPC architecture
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:
- While the default VPC in each AWS Region is suitable for getting started quickly, it is designed as public only. (If you want to, you can add private subnets to it manually.) So, in order to properly deploy production workloads in there, you’d need to create private subnets and network address translation (NAT) gateways manually. If you are going to add resources manually, then you might as well just create your own.
- It’s important to make sure that your VPC network ranges (CIDR blocks) do not overlap one another or other private network ranges. CIDR shouldn’t be forced on you but should come out of a carefully thought-out network plan.
From single-VPC mayhem to multiple-VPC control
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.
- First, we created the necessary private subnets and slowly moved stuff into them. It was a good first step, but we still wanted to achieve further separation between environments (e.g., Staging, Integration, Production).
- Our next step was separating every environment into a different VPC, and that’s where things started getting more complex. It began with a single exception to a rule, when a resource in one VPC also needed to be accessed from another VPC due to a very old dependency. Before we knew it, those exceptions to the rules had piled up, and we could see the mess this was going to create.
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.
The better way: AWS Organizations
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:
- Are people wreaking havoc in your account? Are you having trouble keeping people in check? Are there too many IAM users in your account? Are people messing with things they shouldn’t be (like updating resources outside of their department or just provisioning stuff without telling anybody)? If so, you should consider separating each department in your company to their own AWS account.
- Having trouble putting a finger on a cost leak? Is your bill growing out of control and you can’t figure out what exactly is causing it? Is R&D doing crazy things that are driving up costs? Is QA spinning up too many resources? Or is your dev team over-provisioning their cloud workstations? There is more than one way you can track costs. You can use cost allocation tags, or you can create a separate AWS account for each department and track the cost of each account with the consolidated billing feature provided by AWS Organizations.
- Do you need to strengthen security and compliance? Multiple accounts are easily the best way to prevent people from messing with resources they are not supposed to. It’s true that you could also accomplish this with the proper set of IAM policies, but moving resources to a different account really puts them out of reach. Multiple accounts provide blast-radius isolation to limit the impact of a critical event, e.g., a security breach. And, multiple accounts can address your compliance requirements on the production side, e.g., HIPAA compliance.
Managing user access
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:
Securing user access even further
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.
In conclusion
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.
