40:16
Describe the core architectural components of Azure | AZ-104 | Episode 4
Microsoft Learn
Overview
This video explains the hierarchical structure of Azure's architecture, starting from the top-level tenant down to resource groups. It details different Azure environments like public, sovereign, and Azure Stack Hub, and introduces core components such as regions, availability zones, and region pairs for high availability and fault tolerance. The summary also covers organizational and billing constructs like management groups and subscriptions, and explains how resource groups are used to organize resources, emphasizing Microsoft's recommendation to group them by lifecycle. Finally, it touches upon governance tools like tags, locks, and policies, highlighting inheritance rules for permissions and locks, but not for tags.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- Azure exists in multiple forms: Public Azure (most common), Sovereign Clouds (e.g., US government, Germany, China) with specific compliance, and Azure Stack Hub for on-premises or disconnected environments.
- Public Azure is a global service with numerous regions, each containing multiple data centers.
- Regions are geographical areas where Azure services are hosted, and they contain data centers.
- Data centers within a region are grouped into Availability Zones (AZs) to provide redundancy against data center failures.
- Region pairs are pre-defined, geographically separated regions managed by Microsoft for disaster recovery and data sovereignty.
Understanding these different Azure environments and their global distribution is crucial for selecting the right deployment location based on compliance, performance, and availability needs.
US East is a region containing multiple data centers, which are further grouped into Availability Zones (AZ1, AZ2, AZ3) for redundancy. US East is also paired with US West for disaster recovery.
- The Azure hierarchy starts with a Tenant, which is a global instance of Microsoft Entra ID and the foundation for governance.
- Within a tenant, Management Groups provide a way to organize resources hierarchically for governance and policy enforcement.
- There's a default Tenant Root Management Group, and you can create up to six additional layers, allowing for a deep organizational structure (up to 7 layers total).
- Management groups can be structured to mirror an organization's structure (e.g., by department, geography, or environment like production vs. test).
This hierarchical structure allows for centralized management of policies, access controls, and compliance across your Azure resources, ensuring consistency and adherence to organizational standards.
An organization might create management groups for 'Sales', 'HR', and 'IT', with further sub-groups for 'Production' and 'Development' within each.
- Subscriptions are primarily a billing construct, allowing you to manage costs and allocate spending.
- Multiple subscriptions can exist within a tenant and can be assigned to management groups, inheriting policies and permissions from their parent.
- Resource Groups are logical containers used to group related Azure resources that share a common lifecycle.
- Microsoft recommends grouping resources within a resource group based on their shared lifecycle (creation, management, and retirement) rather than by resource type.
Subscriptions help control and track spending, while resource groups facilitate efficient management and deployment of related services.
A web application with its associated database, networking components, and storage could all be placed in a single resource group because they are deployed, managed, and retired together.
- Permissions (Role-Based Access Control - RBAC) are inherited down the management group hierarchy; what's assigned at a higher level is available to child objects.
- Locks, which prevent accidental deletion or modification, are also inherited down the hierarchy.
- Tags are name-value pairs used for organization, cost allocation, and management, but they are NOT inherited from parent objects.
- Each object can have up to 50 tags, and consistent naming conventions are important for effective tag management.
Understanding inheritance rules for permissions and locks, and the non-inheritable nature of tags, is crucial for effective governance, security, and cost management across your Azure environment.
A 'Read-Only' lock applied to a resource group will apply to all resources within that group, preventing their deletion, but a 'CostCenter' tag applied to a resource group will not automatically appear on the individual resources within it.
Key takeaways
- Azure's architecture is structured hierarchically, starting from the Tenant and extending down through Management Groups, Subscriptions, and Resource Groups.
- Different Azure environments (Public, Sovereign, Stack Hub) cater to diverse compliance and operational needs.
- Regions, Availability Zones, and Region Pairs are fundamental concepts for ensuring high availability and disaster recovery.
- Management Groups are essential for applying consistent governance, policies, and access controls across your Azure estate.
- Subscriptions serve as the primary billing boundary, while Resource Groups logically group resources with shared lifecycles.
- Permissions and locks are inherited down the hierarchy, simplifying management, but tags are not inherited and require explicit application.
- Effective use of tags is vital for cost tracking, organization, and automation, necessitating clear naming conventions.
Key terms
TenantPublic AzureSovereign CloudAzure Stack HubRegionAvailability ZoneRegion PairManagement GroupSubscriptionResource GroupRole-Based Access Control (RBAC)TagLockPolicy
Test your understanding
- How does the hierarchical structure of Azure (Tenant, Management Groups, Subscriptions, Resource Groups) facilitate governance and management?
- What is the difference between a Region, an Availability Zone, and a Region Pair, and why are they important for application resilience?
- Explain the purpose of Subscriptions and Resource Groups, and how do they differ in their primary function?
- Describe the inheritance model for permissions, locks, and tags within Azure's management hierarchy.
- Why does Microsoft recommend grouping resources into Resource Groups based on their lifecycle, and how does this differ from older methods?