Account Structure Comparison between AWS and Azure

Thoughts

Both AWS and Azure provide multi-account structure to empower users to manage their growing workloads in secure, scalable and resilient manner. The multi-account structure is like a tree structure, where you have leaves, branches and trunk. So how does each level of the multi-account structure look like in AWS and Azure?

Well, let’s put both AWS and Azure “trees” (i.e. account structure) upside down and compare them at each level.

Account Structure Mapping

As usual, a picture is worth a thousand words. I got “two thousands words” prepared. Let’s start with AWS first.

Having looked at the AWS account structure, let’s have a look at Azure’s.

Both AWS and Azure have well defined their terminologies and concept, so I won’t reinvent the wheel in this article. Please find the detailed terminology definition from both platforms via the links below.

• AWS Organizations terminology and concepts
• Azure Subscriptions, licenses, accounts, and tenants
• Azure Management Groups
• Azure Resource Groups

(Yes, Microsoft/Azure have well written knowledge articles, but are they well indexed? No comment )

With a fair view and understanding of overall shapes of trees and their terminologies, Let’s compare these two trees in the Comparison section below.

Comparison

As shown in the account structure diagrams, both AWS and Azure “trees” have five levels. If we treat the top level as the “trunk” and the bottom level as “leaves” (remember it’s upside-down tree), then the three levels in the middle are the “branches”. For the “leaves” level, i.e. AWS services vs Azure services, there are a few good articles that provided the detailed comparison.

• AWS to Azure service comparison
• AWS vs Azure in 2021

We’ll spend a bit time on the remaining four levels in this article. Let’s start from the next level above the the “leaves”.

Resource Groups vs Resource Groups

Both AWS and Azure provide resource grouping capabilities to their users, which enable users to effectively navigate and manage resources that match the same grouping criteria. A typical example is that if you use a number of resources to form an application, you can put them together under one group, so called Resource Group.

The ways how AWS and Azure’s Resource Groups work are similar but not identical. The key differences are:

• One AWS resource can be mapped to multiple Resource Groups, while one Azure resource can only be mapped to one Resource Group
• AWS resources can be grouped in to Resource Groups via tags, while Azure Resource Groups can’t be built via tagging
• Deleting an AWS Resource Group will not impact the resources, while deleting an Azure Resource Group will delete all resources under it

For more information about AWS and Azure Resource Groups, see AWS Resource Groups and Azure Resource Manager.

Account vs Subscription

Having looked at how the “leaves” are grouped together, let’s take a look at how “branches” are grouped together. Before we start, some terminologies need to be clarified first. For the next level above the Resource Groups, AWS call it Account while Azure call it Subscription.

(please note that Azure does have an Account concept as well, but it’s more related to Billing Management).

If we look at the relationships between AWS account and its resource groups and resources, it’s optional one-to-many relationships. In other words, one AWS account can have multiple resource groups. With or without resource groups, one AWS account can have multiple resources created and tied to it. And it’s the same for Azure subscriptions, as one Azure subscription to many resource groups (optional) and to many resources.

From the grouping of resource groups aspect, there isn’t much difference at this level. Billing management wise, there is one key difference:

• AWS account owner can pay the bill for the account *
• Azure subscription owner can’t pay the bill for the subscription

This leads to a key difference between AWS and Azure, i.e. service management scope and billing management scope. AWS account takes care of both scopes, while Azure subscription focuses on the service management scope. Azure’s billing management scope goes beyond the five levels we mapped. We’ll explore more about these two scopes in the Organization vs Tenant section.

* If the billing is centralised at the organisation level, individual account owner won’t be able to pay the bill. For more information, see Billing Management.

Organizational Unit vs Management Group

When we move one level up further, it comes to multi-account/subscription management. The multi-account/subscription practice is often adopted by medium and large organisations who have hierarchical organisation structures, or by users who need to establish and manage multiple environments. AWS provides Organizational Unit (OU) to group accounts together, comparing with Azure’s Management Group (MG) that groups subscriptions together.

To compare AWS OU with Azure MG, we’ll assess them from the following angles:

• Nested Structure
• Compliance Policy
• Access Control
• Navigation

Comparison	AWS OU	Azure MG
Nested Structure	Up to five levels of depth	Up to six levels of depth
Compliance Policy	Supports Service Control Policy (SCP)	Supports Azure Policy
Access Control	User access and roles can’t be granted at the OU level, but can be restricted using SCP	Roles can be assigned to MGs and inherit the access to their Resource Groups and Subscriptions.
Navigation	Can be accessed from Management account’s Organization page	Can be accessed from the Management Group service page

For more information about AWS OU and Azure MG, see Managing AWS Organizational Units and Azure Management Group Documentation

Organization vs Tenant

Last but not least, let’s move to the “trunk” part of the “trees”. For AWS, the hierarchy pretty much ends at the Organization level. In other words, there isn’t any higher level that logically groups multiple Organizations together. However, for Azure, the service management scope may end at the tenant level, but its billing scope extends the hierarchy further. We’ll talk more about the billing scope in the Billing Management section. Let’s just focus on the service management in this section.

So from the service management aspect, both AWS and Azure provide guidance on best practices of managing multiple accounts/subscriptions. Among all the practices, the Landing Zone solution is often put under the spotlight.

Landing Zone is like a template of a “tree’ that has well structured baseline and predefined key “branches”. If you want to grow your own “tree” to meet certain standard or following best practices, you can use the Landing Zone as your starting point instead of starting from scratch. A typical Landing Zone structure is like below.

Based on the diagram and the purpose behind the design, we can summarise the key concept of the Landing Zone as:

• baselined grouping of core services (e.g. shared services) and managed services (e.g. workloads)
• pre-packaged core accounts/subscriptions (e.g. Shared, Audit, Network and Security)
• pre-packaged guardrail options (e.g. governance policies)
• automated provisioning and change management
• centralised control and governance

Both AWS and Azure provide multiple Landing Zone implementation options to suit different needs, e.g. start small and expand, or start enterprise scale. The options are listed below.

AWS Landing Zone Options

AWS first had their Landing Zone webinar broadcasted in June 2018. They have evolved this solution idea into a packaged cloud service, called Control Tower. The three well known options are:

• LandingZone – Introduced in 2018 as the initial version of Landing Zone, now in long-term support with no new features added.
• Control Tower – New version of AWS’s LandingZone that provides better automation and user experience on deploying and managing a multi-account environment.
• AWS Secure Environment Accelerator (ASEA) – If you need to build a Landing Zone that meet certain security compliance, e.g. Canada government’s PBMM or Australia government’s ISM Control, ASEA can provide a good starting point.

Azure Landing Zone Options

Different from the Landing Zone offerings from AWS, Azure/Microsoft have embedded their Landing Zone guidelance in their Cloud Adoption Framework (CAF). Based on use cases, deployment velocity and design principles, Azure have provided the following Landing Zone implementation options:

• Migration landing zone blueprint
• Foundation blueprint
• Enterprise-scale landing zone (hybrid connectivity with Virtual WAN)
• Enterprise-scale landing zone (hybrid connectivity with hub and spoke)
• Enterprise-scale landing zone (foundation)
• Enterprise-scale landing zone (small and midsize enterprise)
• Terraform module for Cloud Adoption Framework enterprise-scale
• CAF Terraform modules
• Partner landing zones

To summarise the difference between AWS’s Landing Zone and Azure’s Landing Zone, AWS has wrapped the Landing Zone concept in their Control Tower service, or we can call it Landing Zone as a service, while Azure has made the Landing Zone part of their Cloud Adoption Framework.

For further information about multi-account/subscription practices, see Establishing your best practice AWS environment and Organize and manage multiple Azure subscriptions.

Billing Management

AWS and Azure have their own ways to accommodate the billing management requirements form various sizes of companies.

For AWS’s billing management design, it’s pretty straight forward. We can summarise it as:

• Centralised or
• Distributed

Users can manage their billing either on the Organization level (centralised) or the Account level (distributed). When choosing the centralised way, the billing admin goes to the management/master account to pay the charges of all member accounts. When choosing the distributed way, the billing admin will need to go to each individual account to pay the charges. For details of these two billing management options, see AWS Billing and Cost Management.

When it comes to the Azure billing management design, let’s buckle up first. Azure has introduced four different billing scopes:

• Microsoft Online Services Program/Agreement (OSA)
• Enterprise Agreement (EA)
• Microsoft Customer Agreement (CA)
• Microsoft Partner Agreement (PA)

Why this many options? Let’s comb through them a little bit. First of all, we can count the EA as the old version of the CA. Microsoft introduced the CA in 2019 and started to recommend organisations to transition from EA to CA. So that leaves us three options.

If we map these options in the “centralised vs distributed” way as AWS, then we can put CA in the centralised bucket and OSA in the distributed bucket, where PA can fit in both buckets.

Let’s use a few use cases to compare the billing management between AWS and Azure.

Use Cases	AWS Billing Management	Azure Billing Management
Use Case 1: Personal Account	via distributed management	via OSA
Use Case 2: Small Business	via distributed or centralised	via OSA, CA or PA
Use Case 3: Enterprise Organisation	via centralised management	via EA, CA or PA

For further information about the billing scopes, see Billing accounts and scopes in the Azure portal.

Summary

Having the AWS “tree” and Azure “tree” compared, my personal opinion is that AWS has its “tree” planted with a public cloud mindset from beginning, while Azure/Microsoft who have existing on-prem trees well grown, plant and grow their public cloud version of tree by doing a number of graftings. Both approaches have their own pros and cons. When it comes to the fruits, as which one is sweeter, I’ll leave it to you to decide.