MICROSOFT AZURE ARCHITECTURAL COMPONENTS

Azure architectural components refer to the building blocks of Microsoft Azure that can be combined to create robust, scalable, and secure architectures for developers, architects, and organizations to design, deploy, and manage scalable, secure, and efficient cloud-based systems.

AVAILABILITY ZONES, REGIONS AND REGION PAIRS

Availability zones are physically separate datacenters within an Azure region. Each availability zone is made up of one or more datacenters—physical facilities equipped with servers (these guys again!), independent power, cooling, and networking. Availability zones are connected through high-speed, private fiber-optic networks.
Azure regions are large geographic areas that contain multiple datacenters in close proximity linked together with low latency network.

• Having multiple datacenters in close proximity gives flexibility in choosing where to build applications.
• Regions help to optimise latency as they contain availability zones—separated groups of datacenters within a region, connected by a high-performance network with a round-trip latency of less than 2ms.
• There's a minimum of three availability zones within a single region. This helps ensure high availability and resilience for resources and applications.
• Azure regions preserve data residency and sovereignty—controlling and managing data within a specific geographic boundary or jurisdiction, ensuring that data is stored, processed, and governed according to local laws, regulations, and standards.
• Azure has global and industry compliance offerings; and depending on the region, regional/country compliance offerings are available.

Each Azure region is paired with another region within the same geography at least 300 miles away (480km), allowing for the replication of resources and reducing the likelihood of natural disasters, civil unrest, power outages, or physical network outages affecting both regions at once. Hence, possessing redundancy and failover capabilities. For instance, if a region in a pair was affected by a natural disaster, services would automatically failover to the other region in its region pair.

N.B:

• If an extensive Azure outage occurs, one region out of every pair is prioritized to make sure at least one is restored as quickly as possible for applications hosted in that region pair.
• Planned Azure updates are rolled out to paired regions one region at a time to minimize downtime and risk of application outage.

RESOURCES AND RESOURCE GROUPS

Resources are components made available to build cloud solutions. They are instances of services that you create and manage.
Some popular resources include:

• Virtual Machines (VMs).
• Storage Accounts.
• (SQL or NoSQL) Databases.
• Networking resources (e.g., Virtual Networks, Load Balancers).
• Security resources (e.g., Azure Active Directory, Key Vault).
• Web and mobile resources (e.g., Azure App Service, Azure Functions)
• Container resources (e.g., Azure Kubernetes Service, Container Instances).

Resources are combined into resource groups for management and organization purposes. Resource groups act as a logical container into which related Azure resources like web apps, databases, and storage accounts are deployed and managed.

• Resource groups aid logical grouping as they allow grouping related resources together, making it easier to manage and monitor them.
• Resources can be added or removed from a Resource group as needed.
• Access control policies can be applied to Resource Groups, controlling who can access or manage resources within the group.
• Resource Groups can be used to deploy and manage resources simultaneously, such as deploying a web application and its associated database.
• Resource Groups make it easier to monitor and troubleshoot resources, as they provide a centralized view of resource performance and health.
• Resource Groups can help track costs associated with resources, making it easier to manage expenses.
• When resource groups are deleted, all resources within the group are also deleted.
• Applications can utilise multiple resource groups.
• Resource groups cannot be nested.
• A particular resource can exist in only one resource group but can exist in different regions.
• Resource Groups can be deleted when backup data has been removed and a user has the permission to do so as specified by resource locks.

Resource locks are used to protect Azure subscriptions, resource groups or resources from accidental deletions and modifications.
There are two types of resource locks:

• Delete: Users can read and modify a resource, but they can't delete it.
• Read-only: Users can read a resource, but they can't delete or update it. Locks can be set up via the Azure portal, Azure PowerShell or Azure CLI.

SUBSCRIPTIONS

A subscription groups together user accounts and the resources that have been created by those user accounts. It provides authenticated and authorised access to Azure products and services.
Subscriptions manage and control access to resources that users can provision and helps generate separate billing reports and invoices for each subscription.
For each subscription, there are limits or quotas on the amount of resources that can be created and used. Organisations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.
An Azure account can have more than one subscription.

MANAGEMENT GROUPS

Azure management groups provide a level of scope above subscriptions as subscriptions are organised into containers called Management Groups.

• Each management group can have many subscriptions.
• All subscriptions and management groups are within a single hierarchy in each directory.
• All subscriptions within a management group automatically inherit the conditions applied to the management group.
• Management groups give users enterprise-grade management at a large scale no matter what type of subscriptions they might have.
• 10,000 management groups can be supported in a single directory.

Think of an Azure Active Directory (AAD) directory like a filing cabinet: you can have up to 10,000 folders (management groups) in a single cabinet (AAD directory) to organize your papers (subscriptions, resources, etc.).

• A management group tree can support up to six levels of depth. This limit doesn't include the root level or the subscription level.
• Each management group and subscription can support only one parent.

In Azure, each management group and subscription can only have one parent entity above it in the hierarchy. In other words:

• A management group can only be a child of one other management group (or the root node).
• A subscription can only be a child of one management group (or the root node).

This means that you can't have multiple parents or a complex hierarchy with multiple branches. It's a simple, straightforward parent-child relationship.
For example:

• Management Group A (parent)

  • Management Group B (child)

      - Subscription 1 (grandchild)
      - Subscription 2 (grandchild)
    

• Management Group C (parent)

  • Subscription 3 (child)

In this example, Management Group B and Subscription 3 can only have one parent each (Management Group A and Management Group C, respectively).