Introduction

At Priocept we regularly use both Amazon Web Services (AWS) and Google Cloud Platform (GCP) for cloud based hosting services, and manage numerous systems on behalf of our clients that use one or the other, or a combination of both. As a result, we have developed some strong views on how each platform compares, and in what scenarios one is strong or weak compared to the other.

In this article we will compare the “project isolation” features of each platform.

Project Isolation

With old-school “bare metal” server infrastructure, there is often some natural isolation between infrastructure for unrelated systems or unrelated projects, simply by virtue of physical separation of server or datacentre A, from server or datacentre B. But with cloud based infrastructure, careful planning is required to ensure that infrastructure is suitably isolated and to ensure that there is zero possibility that actions taken on one set of infrastructure, will affect the state of a different set of unrelated infrastructure.

Here are some examples of where you might need strong isolation between different sections of your cloud infrastructure:

1. You have multiple systems, which are completely unrelated to each other. For example, you might host both your public website and a customer portal on AWS. But there may be zero interdependencies between them, and you might have two completely separate teams, perhaps even two separate suppliers, developing and supporting them. Clearly you will need isolation between them so that a change (or mistake) on one, has no possibility of breaking the other.
2. For a given system, you have multiple concurrent environments for that system. You might have “development”, “test”, “staging” and “production” environments, or similar arrangement. Again, you may want to give one team free-reign on the development environment, but zero access to the production environment.
3. As an organisation, you manage infrastructure for multiple clients or customers. In this scenario, you should be able to perform any action on a set of infrastructure for a given customer, with no concern as to whether it might adversely affect a different customer.

Here we are using the term “project” to mean any entity that needs isolating from another, at an infrastructure level. But a project might represent a customer, a system, or a specific environment within a broader system. And so it becomes important to provide “project isolation” within your cloud architecture.

As obvious and as common as this requirement may seem, it is very common for us to see multiple unrelated projects living under a single AWS account, or to see development/test/production environments living under a single AWS account. Where we see this, we try to introduce better isolation between the projects or environments as soon practical.

Google’s Approach to Project Isolation

Google Cloud Platform has a very simple, effective and powerful approach to this problem. Every single piece of GCP infrastructure is created underneath a “project” entity. In addition to creating a GCP account you must also then create one or more GCP projects under that account.

By default, these projects are completely isolated from each other (unless you grant permissions and connectivity between them). Each project has a globally unique ID. For example, you might have projects called “systemx-dev”, “systemx-test”, and “systemx-production”. Or you might create projects called “customer1-website”, “customer2-website” and “customer3-website”. Although these projects will all be associated with your GCP user account (login details), they are completely isolated from (and unaware of) each other.

Amazon’s Approach to Project Isolation

Unfortunately, AWS does not support the concept of project isolation as described above for GCP. There is no project entity that is distinct from the account entity. Using one of the examples above, if full isolation is required between “dev”, “test” and “production” environments for “System X”, then it is necessary to create three separate AWS accounts. And yes, that means:

1. Three accounts with three passwords (and three multi-factor authentication setups if you are securing things properly).
2. Three email addresses, one for each account, e.g. systemx.dev@priocept.com, systemx.test@priocept.com, systemx.production@priocept.com. You cannot have multiple accounts on a single common email address.
3. Three duplicated entries of the same billing details (e.g. card number), with triplicate updates whenever the payment details expire or need changing.

As you can see, this gets messy quite quickly.

If you research this issue further, or discuss it directly with Amazon, you will receive suggestions to address this problem in one of a number of ways. These include the use of VPCs (https://aws.amazon.com/vpc/), security configuration (Roles and Policies), or Resource Groups.

Unfortunately, none of these approaches give you true project isolation. VPCs are very specific to networking architecture and relate to IP address ranges, subnets and so on. They do not provide a master container within which any type of AWS resource can be placed. Roles and Policies can be used to limit access to resources by user or group, but this approach quickly becomes very complex and is prone to errors that leave poorly secured resources. Resource Groups provide a way of organising and structuring groups of resources from a user interface perspective, but do nothing to isolate and protect unrelated set of resources from a security perspective. Which brings us back to the need to create completely separate AWS accounts, if we want pure and simple isolation between different sets of cloud infrastructure.

If you are committed to using AWS and need isolation and protection of different sets of infrastructure, then the use of multiple accounts, plus delegated access via Role and Policies, while not entirely satisfactory, is currently the best approach. Setting this up is not straightforward and is a subject for a future blog article.

Project Transfer

In addition to isolating different groups of cloud infrastructure, you may also want to transfer that infrastructure to someone else – perhaps to your customer after you have set it up for them.

With the AWS model, you can only achieve this by transferring the entire account to the new owner. This means changing the email address of the account to their email address, removing your payment details from the account, and removing any other account-related information that is specific to your organisation, such as your billing address. Again, it gets quite messy quite quickly.

With the GCP model, you can simply transfer ownership of the project to your customer, or whoever the new owner is. This is achieved by assigning your customer “Project Owner” permissions for the project. Thereafter, they can remove you as a Project Owner, to complete the ownership transfer. Transfer of the responsibility for future bills is achieved via a separate billing account.

Billing Accounts

As we have seen above, AWS effectively has a one-to-one mapping between user accounts and projects, while GCP treats them as two separate entities, with a many-to-many mapping between the two.

But AWS also has a one-to-one mapping between user accounts and billing accounts. If, for example, you want to bill two different parts of your infrastructure to two different payment methods, you need two different user accounts to achieve this. On the other hand, GCP has the concept of separate, multiple billing accounts for a single user account. Each project is then assigned to a given billing account, which determines where charges for that project are applied.

AWS does have the concept of “consolidated” billing, which is a subject for another article, but this doesn’t fully separate the concept of a user account from a billing account.

As with the lack of a separate project entity, the lack of a concept of separate billing accounts in AWS can lead to proliferation of large numbers of user accounts as a workaround.

Summary

While AWS is a longer established and more comprehensive platform than GCP, its model for managing user accounts, project-related groups of infrastructure, and assignment of billing rules to those user accounts and infrastructure groups, seem far behind GCP. Google provide a solution that is both simpler to use, and more powerful at the same time.

For those who need to implement complex cloud based infrastructure for a wide range of unrelated systems, unrelated projects, or unrelated customers, while at the same time wanting a degree of centralised user account and centralised billing management across all the infrastructure, we recommend a close look at GCP before you jump straight in to AWS.

If you would like support in choosing the right cloud platform, or consultancy support to ensure that your existing AWS or GCP infrastructure is properly configured and optimised, please contact us at info@priocept.com.

Footnote – Microsoft Azure

Like AWS, Microsoft Azure also has the concept of resource groups.  Again, these allow logical grouping of sets of resources, but do not provide full isolation from a security perspective.  As with AWS, it is also not possible to transfer a resource group to a different Azure account (“subscription”), but it is at least possible to transfer some types of individual resource between two subscriptions.