I’m spending more time thinking about Cloud Security in Google and Azure and trying to grok the differences between those platforms and AWS. One of the critical components for understanding your enterprise security stance is what is the source of authority for creating & managing resources in the cloud. As I was thinking about this, I realized that the three main players have very different models. Each model reflects on that companies pre-cloud origins.
In Microsoft’s Azure, the top most entity is the Azure Enrollment1. From there, corporate Departments are created and those Departments have accounts in them. Those account holders can then create Subscriptions (which is a very weird name for a cloud resource container). However, Microsoft was born selling software and is still mostly focused on Enterprise sales model. Thus the License is the central corporate identity for Azure.
In the case of Google the top most authority for creating resources is the Organization. The Organization then owns multiple Projects, and GCP Resources live inside those Projects. The Organization is deeply intertwined Cloud Identity which uses the DNS domain and this is deeply intertwined with their other products like G Suite. Google’s first real foray into selling to businesses was their GMail product, and so it makes sense that the domain name is the central corporate identity for GCP.
AWS has always been a company focused on the individual consumer. So in the case of AWS, the central authority for creating resources is the root account which is tied to an individual email address. While AWS has the concept of Consolidated Billing (and now Organizations), each AWS account is a separate and distinct entity2. The email address is thus the central corporate identity for AWS. It should also be noted, that email address is the same identity and uses the same authentication as a Amazon Retail account. So when signing up for AWS, don’t use the email address you use for Amazon if you ever intend to transfer ownership of the AWS resources.
1 https://marckean.com/2016/06/03/azure-enterprise-enrollment-hierarchy/
2 Don’t get me started with how obstinate AWS can be around security issues for a corporate account when you’re not the one individual named on the account.