Getting started with Azure — Governance

A lovely header image generated by Dall-E through Bing AI

This blog post is taken from my Azure Practical Training, which is available for free. It is designed to guide beginners through Microsoft’s public cloud platform. The training includes the same content as this post but also provides exercises for hands-on learning opportunities.

What is Azure

Let us begin with the obvious — a definition of what Microsoft Azure is and is not.

According to Microsoft:

The Azure cloud platform is more than 200 products and services designed to help you bring new solutions to life — to solve today’s challenges and create the future. Build, run, and manage applications across multiple clouds, on-premises, and at the edge, with the tools and frameworks of your choice.

But in plain English, Azure is the public cloud offering from Microsoft that provides a wide range of IaaS (Infrastructure-as-a-Service) and PaaS (Platform-as-a-Service) services, which allow you to run almost any application or workload.

I am unaware of any SaaS (Software-as-a-Service) offering that would be a part of Azure, but that statement might not age well, so feel free to reach out if you’d like to correct me on that. Before you do so, I want to acknowledge that Azure Active Directory is a SaaS offering. However, despite what the name indicates, it’s not Azure. I will go deeper into that in a later blog post, so please hold on before sending me an angry message.

If you’d like to refresh your memory on the differences between IaaS, PaaS and SaaS, I’ll leave that to the fantastic Microsoft Lean site.

Buying Azure

Now that we’ve covered the basic definition of Azure let’s look at how we can get started with the cloud platform. There are many ways to buy Azure and several programs aimed at helping newcomers take their first steps.

The list below describes the options we have to procure Azure Subscriptions:

• Free — A complimentary account with 200$ USD credits for 30 days and limited free access for 12 months
• Pay-As-You-Go (PAYG) — Sign-up online with a Credit Card with no discounts — publicly available list prices apply
• Cloud Solutions Provider (CSP) - Buy via a Microsoft Partner. The discount options depend on the partner (and are limited), but there are no barriers to entry, and you pay monthly.
• Enterprise Account (EA) — Buy directly from Microsoft via the volume licensing program (minimum 500 users or devices) also used for software licences. Based on the value of your contract, you can be eligible for significant discounts, but you lock in a 3-year financial commitment with an option to pay annually.

There are also specific programs and incentives for educational use. For example, the Student subscription gives 100 USD for 12 months.

While we always buy the same Azure, no matter how we purchase, specific options and possibilities will vary based on the channel you use to purchase your Azure Subscriptions. For example, the workflow for creating new Subscriptions works differently — with EA, you can quickly deploy them using Infra-as-Code templates, but in CSP, that is not a feasible option.

It’s also important to mention that most of us use (probably without realising) the public version of Microsoft’s public cloud called “Azure Cloud”. Now you might wonder, if there is a public version of the public cloud, are there private ones as well? The answer to this question is — no, but there are two sovereign clouds with limited access:

• Azure Government (US Gov and US DoD).
• Azure China (served by 21Viatel under license from Microsoft).

All three clouds are separate, with different management APIs and identity services used to grant access. A programmatic check will tell us the following:

PS /home/rwiankowski> Get-AzEnvironment 

Name              Resource Manager Url                  ActiveDirectory Authority         Type
----              --------------------                  -------------------------         ----
AzureUSGovernment https://management.usgovcloudapi.net/ https://login.microsoftonline.us/ Built-in
AzureCloud        https://management.azure.com/         https://login.microsoftonline.com Discovered
AzureChinaCloud   https://management.chinacloudapi.cn/  https://login.chinacloudapi.cn/   Built-inpower

Fun fact — in the past, we also had Azure Germany (operated by T-Systems under license from Microsoft). In 2018 Microsoft stopped accepting new customers or adding new features to the German sovereign cloud. It was discontinued in late 2021. Today, the general Azure Cloud has two data centre regions in Germany.

The two dimensions of Azure

When exploring how Microsoft Azure is structured, we must start by identifying two distinct dimensions:

• Geographical Location
• Logical Structure

Let’s explore each of them in detail.

Geographical Location

Regions

An Azure Region is the primary unit of consideration when discussing geographical location. A region represents a collection of data centre facilities and ensures data residency.

Almost every Azure Resource has to be deployed to a specific region. Some resources are global and not bound to a particular location. In that case, the resource metadata will be stored in the area specified by the Resource Group.

There are 60+ Azure regions across all (habitable) continents, and new ones are added regularly.

Azure Regions

The region(s) you choose to run your application(s) will have a significant impact down the line:

• The latency of the network connection between the end users of the applications and the region will, in most cases, dictate the performance and, thus, the experience.
• Therefore, you should aim to deploy your Resouces to a Region as close to the end users as possible. With a geographically distributed user base, you might choose a multi-region approach.
• You might be subject to regulatory requirements dictating where your and your users’ data can be stored and processed.
• Some services and features are only available in select regions.
• Prices can vary between regions located close to each other.
• Regions have different capacity pools available, so scaling out could be impacted.

Geographies

While it might not be evident initially, all Regions are grouped into Geographies. Geography (often called Geo) represents a discrete market to preserve data residency and compliance boundaries.

Most geographies have two regions designated as a Region Pair, but a few exceptions exist. In most cases, however, the two locations will be separated by hundreds of kilometres, thus allowing customers to configure Disaster Recovery and retain business continuity in a regional disaster.

Also, please remember that certain regions are restricted to support specific customer scenarios, such as in-country disaster recovery. These regions are available only upon request by creating a new support request.

You can find detailed info on regional pairs in the official Microsoft docs.

By design, at least one region within a geography will support availability zones.

Availability Zones

Availability Zones

Availability Zones represent separate data centre facilities within the same region. What is crucial is that they:

• are located tens of kilometres apart,
• are connected by dedicated high-throughput and low-latency fibre-optic networks,
• have independent power, cooling, and networking.

Thus Availability Zones protect against local outages within a specific region.

Some Azure services are zone-redundant by default, some can be configured to span multiple Availability Zones, and others can be zonal — deployed to a specific zone.

IMPORTANT — The configuration of zone redundancy will be an essential aspect of your architectural considerations and a fundamental component of highly-available applications.

Final Picture

By consciously designing our topology to use Geographies, Regions, and Availability Zones, we can achieve very high levels of resiliency. With a zone-redundant topology in the primary region and presence in a paired location, we can protect our application(s) from various outages. But bear in mind that such solutions come at a cost — not only resource price but also the cost of significantly increased complexity.

Example topology spanning regions and availability zones

Logical Structure

In the management hierarchy of Azure, we have five primary levels:

• Azure Active Directory — The non-optional authentication provider for Azure. This SaaS service is the root of every Azure deployment. It stores security principals like user accounts and groups and offers authentication and authorisation capabilities. We will dive deeper into Azure AD in the next post.
• Management Group — The optional logical container helps us efficiently manage multiple subscriptions. We commonly use it to group subscriptions that are used by a given business unit, host a specific workload or are operated by a unique team.
• Subscription — The primary unit of purchasing Azure.
• Resource Group — The non-optional logical container for Azure Resources. Resource groups should bring together resources that share the same lifecycle.
• Resource — the service or component which we want to use. Every resource must be deployed to a specific Azure Region and a Resource Group.

Example Management Hierarchy

Management Groups, Subscriptions, and Resource Groups all allow for the following:

• granting RBAC permissions (access rights flow down the hierarchy in a waterfall way)
• assigning policies
• scoping costs

We will dive deeper into all three concepts later in this series. If this doesn’t make complete sense, the upcoming posts should address this issue.

Considerations for Management Groups

• Management Groups are not enabled by default — you need to opt-in to get this functionality.
• When you enable Management Groups, the platform will create the Tenant Root Group for you. The id of this group cannot be changed and is always the same as the id of your Azure AD tenant.
• You can create a tree-like structure of Management Groups up to six levels deep (seven with the root).
• But Microsoft recommends keeping the hierarchy as flat as possible
• Consider groupings by location, environment, and business unit.
• Having two specific Management Groups — Sandbox and Decommissioned- is standard practice. The names should be self-explanatory.

Example Topology of Management Groups

Considerations for Subscriptions

• The Subscription is the primary unit of purchasing and governance in Azure (like an AWS account or a GCP Project).
• You need at least one and can use only one subscription, but I recommend following the recent trend of subscription democratisation — use at least one subscription per application/workload and, ideally, several to isolate DTAP environments.
• I recommend a one-to-many relationship between teams and subscriptions and strongly advise against many-to-one/many relationships. In the latter scenario, teams will get into each other’s way.
• Services and features (called Resource Providers) are enabled per subscription. You can use this granularity to control which resources can be deployed in various subscriptions.
• Subscriptions have quotas that limit the number of resources of a given type that can be created in a given subscription. Some of those limits are soft and can be quickly increased via a support request, but others are hard and will force you to add additional subscriptions. You can find detailed info on this topic in the official Microsoft documentation.

Considerations for Resource Groups

• Resource Groups are logical containers for Azure Resources.
• They are only virtual entities without a physical representation, but each must be deployed to a specific Azure Region. The specified location will be where the metadata is stored, so keep it in mind for regulatory compliance.
• Every Resource needs to be in a Resource Group. This is the way.
• Every Resource also must be deployed to an Azure Region, but this region does not to be the same as the region of the Resource Group. You can deploy the Resource Group to West Europe (to keep the metadata with the EU) and deploy child Resources to East US (because that’s where your users are located). However, I prefer to align the Resource Groups and child Resources locations. I will soon show you why.
• Most significantly — Resource Groups should hold together Resources that share the lifecycle. That is, they are created, updated, and destroyed together. For example, if you have an application consisting of a web front end and a relational database, both components belong in different Resource Groups. You will update the front end often and may even replace it with something completely new. But your database will remain as is or see only minor schema updates.

Naming and Tagging

Naming and Tagging play a crucial role in the governance of any cloud environment, and Azure is no Exception. While there is no single way of approaching both topics, it is imperative to include them in your design considerations and implement your designs consistently.

Naming

As one of the industry’s legends quickly reminds us, creating a good naming convention is among the most challenging tasks an IT professional must tackle. At the same time, as experience teaches us, it doesn’t matter how it looks — what matters most is that you have one and stick to it.

Therefore, I recommend you resist spending several weeks inventing the perfect naming convention. Instead, make sure that it does the following:

• allows the users to quickly and easily identify the resources they are looking for,
• complies with the requirements set by the platform regarding uniqueness and character limits,
• provides room and flexibility for exceptions,
• supports automation mechanisms (for example, by using consistent delimiters).

Tagging

Tags provide metadata for your Azure Resources. They are key-value pairs of your choice that allow for enriching resources with valuable information. This information organises your resources for billing, automation, or anything else you want to achieve.

You can find yourself in a situation where a well-designed Management Hierarchy and a solid Naming Convention leave little need for tagging, and that’s OK. Use tags when needed to make your life easier, but I recommend avoiding duplicating information — the DRY principle works here as it does in software engineering.

My favourite examples of how to use tags focus on automation. The includes but isn’t limited to:

• scaling, both vertical (changing the SKU) and horizontal (starting/stopping instances), based on the demand or time/date,
• deploying updates in batches,
• configuring backup strategies.

Azure RBAC

Finally, we must discuss assigning permissions to complete the topic of governance. In Azure, we use Role-Based Access Control (RBAC) to define access rights. It provides fine-grained access management of resources in Azure​, thus allowing you to segregate duties within the organisation.

How RBAC works

Let’s first describe how you implement RBAC, and then I’ll explain what the different terms mean:

You create an assignment of a role definition to a security principal at a particular scope.

where:

• Scope — a boundary for the level of access that is required.
• Security Principal — An object representing an entity requesting access to resources.
• Role Definition — A collection of permissions that lists the operations that can be performed.
• Assignment — attaching a role definition at a selected scope.

In simpler words, we define who, what, and where.

Security Principals

A Security Principal for Azure RBAC in an Azure AD object (or its logical representation). I will cover Azure AD in the next post, so for now, expect that you can create RBAC assignments using the following:

• users,
• groups,
• service principals,
• managed identities.

Security Principal options

Role Definitions

The Azure platform comes with a very long and ever-growing list of RBAC role definitions, but you can also create custom ones if you need more than the built-in options.

IMPORTANT — Be very cautious about creating custom RBAC roles. They remain your responsibility and require periodic reviews.

In the long list of role definitions, there are three fundamental ones:

• Reader — Allows reading all information about Azure Resources.
• Contributor — Allows reading, creating, managing, and deleting Azure Resources.
• Owner — Extents the Contributor role by granting rights to set permissions on Azure Resources.
• User Access Administrator — It lets you manage user access to Azure resources, but not the resources themselves, a bit like Owner-Contributor.

These three generic roles include all types of resources, but there are also resource-specific roles, such as Network Contributor, which should be self-explanatory.

Every Role Definition indicates which actions are allowed or not for a chosen Resouce Provider (for now, think resource type, we will dive deeper into the topic later).

Role Definitions from up close

IMPORTANT — “Actions” and “NotActions” apply to the management plane, that is, the configuration of Azure resources. “DataActions” apply to the data plane, representing data stored within the resources, such as BLOBs stored in a Storage Account. Be careful when you only want to grant access to the management plane and not the data plane or the other way around

You can find the complete list of built-in Azure RBAC Role Definitions in the official documentation from Microsoft.

Scopes

Any of the following entities from the Management Hierarchy can act as a scope for an Azure RBAC assignment:

• management group,
• subscription,
• resource group,
• unique resource.

Scopes for Azure RBAC

Assignments

Most RBAC assignments (called “Role Assignments”) are intended to allow a security principal to perform a set of actions over the selected scope.

You can quickly check the status of RBAC by navigating to the “Access Control (IAM)” section of a chosen scope in the Azure Portal. You will find the same interface on all levels of the management hierarchy.

RBAC in the Azure Portal

Azure also supports “Deny Assignments,” which attach a set of deny actions to a security principal at a particular scope to deny access.

You do, however, need to keep a few critical facts in mind:

• Deny assignments are currently read-only and are set by Azure Blueprints and Azure Managed Apps.
• Deny assignments block users from performing specified actions even if a role assignment grants them access.
• Deny assignments take precedence over role assignments.

Recommendations for Azure RBAC

Microsoft’s recommendations for RBAC include the following:

• Grant only the access to users that they need to perform their jobs​.
• Assign at the highest scope level that meets the requirements
• Assign roles to groups, not users
• Know when to create a custom role
• Consider what happens if you have overlapping role assignments

Keep those in mind for the exams, but also be mindful that this advice works best in organisations that use functional silos.

When your environment consists of cross-functional DevOps teams, I suggest giving the entire group Contributor rights on the Management Group or Subscription dedicated to the application/workload managed by the team. This way, everyone can fix an issue when they are on call. You also save yourself the headache of managing custom RBAC roles.

Conclusion

While this blog post does not exhaust the topic of Azure governance, I hope it provides sufficient information to give you a consistent and concise overview of how the cloud platform is organised.

I recommend following all the links to Microsoft’s documentation I provided in the text — they should provide detailed information where I only explained the high-level concept.