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.
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.
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
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
|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|
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.
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
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.
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.