A Comparison of the Basic Building Blocks in AWS, Azure and GCP

Where Azure and Google Cloud shine and AWS fails

This sweet cloud promise, it sounds so simple - log into your cloud account, select a machine type and hit start. But as soon as you are running a dozen machines in all parts of the world for different projects and teams, you will start struggling with pulling apart your bill and granting rights to different people knowing which is what. Then you will find: this becomes unmanageable quite fast. Sure enough, every major cloud provider offers some kind of solution for this organisational mess, and this blog post will try to do a comparision. It is separated into two parts: the simple way, and the enterprise way.

All three major public cloud players (Amazon Web Service, Microsoft Azure, Google Cloud Platform) have two basic approaches: One low-barrier entry and a much more sophisticated approach targeted to enterprises. We start with the simple one, to learn the basic terms and differences between clouds, then will briefly touch on the extended version.

Part 1: Basic Building Blocks

There are some commonalities between Cloud providers, where the twist is in the details.

GCP

For starters, let’s look at Google Cloud (GCP). Log into Google Cloud Console and create a billing account. Now under this personal account and connected to the billing account, you are required to create your first “project”. The term project is well known to development teams, but is less intuitive for operations people where the term environment is much more common. The project will host all GCP resources you provision under one umbrella. Google is the only cloud using the term project (of the Big Three, though german provider Hetzner uses this term, too). GCP projects are the compartments to sort cloud stuff into. All things belonging together in one place in the logical sense, meaning that they hold resources independent of the geographical distribution of resources. That covers everything: storage, compute, network, as well as other services.

Projects also provide context: In the GCP console or on the command line using gcloud, there is always the current project. Commands will then apply to that project, unless you override the optional project parameter.

You will need to switch projects to work on other project’s resources.

A billing account can be reused for more than one project, which reduces overhead in cases where you want to keep a set of projects under one budget. You would set an alarm on the account giving you warnings when all those projects together exceed their thresholds.

Azure

Azure has a similar setup, but different wording, which should sound familiar if you’re already a Microsoft customer. Microsoft offers subscriptions for its products, be it Office 356, XBox, etc. The same applies to Azure, you need to have an Azure subscription to get going, for example the “Pay-as-you-go” subscription. This is the actual contractual relationship between you and Azure cloud, and it covers the billing aspect. Cloud resources aren’t directly attached to a subscription, there is an mezzanine logical level similar to a GCP project, called Resource Group (RG). It’s a right-to-point, less overloaded term than ‘project’ or ’environment’: It’s just a bunch of cloud resources. For you, a RG could identify a project, or an IT environment (dev, test, prod), a product, a customer or tenant. You decide. You should put a lot of effort into slicing and naming your resource groups. It’s hard to change their names later. Just like in GCP, a RG might contain resources everywhere in the world.

There is no single current resource group in Azure, although its often implicit. Due to how Azure’s Portal works, context is always given by the current view, which keeps a navigation breadcrump on the top. By navigating from one Azure object to the next, this breadcrump gets longer and longer, unless you choose to go back. It’s even possible to visit a resource group multiple times. In the example below, both rancher and bffunctions represent resource groups:

AWS

For AWS, you need a personal account, too. This account is directly linked to your credit card (no billing account nor subscriptions). The next organisational structure available is the AWS location, or region. Every AWS (Azure, GCP) region is a set of nearby data centers which work together “as one” and provide a defined set of services. In AWS, the primary view is on the current region. The region is also the context within the AWS console. In other words, there is no organisational structure which is forced on the user, besides the geographical separation. For those using more than one region or doing different things within the same region, this creates difficulties.

Nevertheless, AWS supports resource groups. But they work differently from Azure RGs and GCP projects. AWS RGs make use of resource tagging.

With Azure and GCP it’s easily possible to reliably list all resources relevant in a certain context. It’s much harder in AWS. If you failed to tag some resources appropriately, they can be anywhere, in any region. This can become especially cumbersome if you try to delete reliably all resources belonging together, but need to be sure that you won’t delete unrelated stuff. If you have geographically distributed resource, but have some places you rarely visit, you run the risk forgetting about resources in those parts of the world.

And if you have properly set up AWS Resource Groups doesn’t mean your collegues can see them at all!

However, there is a tool to ease the pain a little bit, AWS Systems Manager, but it’s not a structural thing, just a management UI.

If you fancy resource tagging, Google and Microsoft do support this as a complimentary feature as well. But I highly recommend using Azure resource groups and GCP projects as primary means of organisation.

AWS VPC to the rescue?

You might wonder if VPCs could solve the resource dilemma on AWS?

AWS VPC (“Virtual Private Cloud”) is grouping resources within a region. So this is the first restriction, it won’t work beyond a single region. VPCs are isolating resources, but only on network-level, from the rest of the world. VPCs don’t apply to resources which don’t have a network context, like S3 buckets.

While I recommend to use AWS VPCs extensively, I don’t think they should or even can be used for resource organisation.

Clean Clouds

Amazon’s cloud is much less structured than Azure and Google Cloud to the point of oversimplification. It’s like a cupboard with only one massive drawer where everything gets thrown into.

Google and Microsoft both allow you to have separate billing for multiple ‘projects’ under one account, which facilitates keeping things in order from a bookkeeper’s perspective.

Quotas

Let’s now look into quotas. A quota limits cloud resource usage. This protects the cloud as well as the customer. Just imaging you would have a script creating one machine per hour. Someone changes the setting of the script to one machine per second without anyone noticing. Soon, there are hundreds of machines running. To avoid problems like this to happen, all cloud resources have per-user usage limits, so called ‘quotas’. Quotas restrict the number of disks, IP addresses, CPUs and virtually everything else, to be used at the same time. Those limits are enforced per account and per region, at least for AWS.

Again, Microsoft and Google offer more flexibility here. They tie some quotas to account and region, but some to subscription/resource group and project, respectively. This results in even more accountability, since quotas can be raised only for those endevours which need them.

Part 2: Enterprise.

As a large company with a considerable cloud footprint, you’ll find that those simple tools (even in the case of GCP and Azure) are insufficient to support your enterprise. Needless to say that cloud providers very much want to support large customers efficiently. However, they require those organisations to make a dedication to use their enterprise offerings.

Requirements

What would be different in an enterprise setting? These are typical requirements:

• Departments have separate playgrounds, cannot interfere with others, yet under one company umbrella
• Existing company-wide Identity and Access Management (IAM) should federate with cloud’s IAM (Login, LDAP, Microsoft Exchange)
• Company policies should apply to every group using the cloud, even as they have independent areas and usage
• Company want to make use of gross discounts, central cloud vendor management and support contracts, yet need to break down costs to individual organisational entities (OEs)
• IT wants to impose their own limits and policies for cloud usage (security, usages of certain products)
• Enterprises need more tooling around being compliant and detecting anomalies

In supporting this, cloud providers require users to behave differently. At first, you need to stop using your individual account. For GCP you need to sign up with G Suite, for Microsoft an Enterprise Office 365 account is needed which is linked to your enterprise account.

Amazon AWS has no such business tool suite offerings like Office 356, so is again an exception here, but sthis time on the positive side: The process here seems a little bit more easy. Existing accounts can be integrated into their enterprise offering, called AWS Organizations, by simply sending out invites.

Now you can model your cloud infrastructure after your organisation. This is how this can look for Azure for example:

This looks simple, but actually getting there needs a lot more upfront preparation and planning. It looks more involved for Amazon AWS, where accounts and policy come into play on every level.

I won’t go into more of the details of those enterprise building blocks. If you need them, you want to talk to your cloud provider anyway. However, you will find some further reading on best practices for GCP or here for Azure or AWS Organizations Terminology and Concepts.

Part 3: Glossary

Let me conclude this post with a summary of the different nomenclature for the terms used in this article.

.

• Share this post: