One of the most interesting differences between GCP and AWS is how each vendor recommends you isolate the blast radius of functional teams. AWS will tell you that in all likelihood, you will need at least two accounts, but possibly more. Referring to their white paper on the subject, you can see the questions they pose to decide if you need multiple accounts:
- Does the business require administrative isolation between workloads?
- Does the business require limited visibility and discoverability of workloads?
- Does the business require isolation to minimize blast radius?
- Does the business require strong isolation of recovery and/or auditing data?
While on the GCP side of things, best practice is to use Projects to provide a functional grouping of resources. In fact, much of the content I intended to focus on with this blog post was recently provided by Google in this excellent writeup. I strongly recommend anyone reading this blog post to also read that writeup, which was referenced earlier this month via this blog post by Google. So who got it right?
The truth is, except for a few specific areas, in my opinion the two systems deliver equal functionality. Accurate cost allocation can be done in either system. Projects and AWS Accounts are global, not regionally, bound; they can service many users in many regions with many services. So on and so forth. There are two key areas however where I think Google has a distinct advantage:
The biggest reason why a GCP Project is such an effective model is at the network level. Within AWS, the VPC is isolated to a region and an account. In order to connect other AWS VPCs within the same region, you can use peering, but that requires a well planned and scaled approach on how a fully meshed intra-region multi Account / multi-VPC network would look like and scale without any IP overlap. And all of this assumes that the customer is ok with potentially 100’s of accounts and 100’s of networks (or make that 100s x 2 since we should isolate production in its own account). Some customers simply do not want to manage all these accounts and networks. This is especially true when those networks must connect back to a corporate location or data center.
GCP on the other hand does not require that each Project have its own network. In fact, you could create one large development network within GCP (global or regional) and then create unique development Projects to isolate resources for each development team. The fact that all these resources are in the same network does not diminish the security that the Project boundary creates. This makes things like shared services and security auditing tools much easier to orchestrate since they can have cross Project access. Not to mention the network does not require a complicated meshed structure. The network could be created based on routing principals rather than development teams, simplifying the use for both the network administrators and the developers using the network.
I can’t overstate how significant the Project feature is within GCP. In my opinion, this is a much cleaner solution to isolating access than anything AWS currently provides. Having had numerous conversations with AWS customers explaining the difficulties providing resource based access control within the same account and network, to have such a simple solution on GCP is excellent.
The second reason I think Google got it right on Projects is how you assign user access. You can simply create a Google Group for a GCP Project. Add users to the Google Group (within your organization, or maybe even outside your organization like 3rd party contractors or consultants). By contrast, there is no equivalent user grouping structure on the AWS side. You could use an Identity account to consolidate user management and then use cross-account access with roles. This would enable you to manage which users can access which accounts, but this is significantly more complicated than using a Google Group.
Stay tuned for how to manage a large scale deployment or projects or AWS accounts in a future blog post.