---
title: Azure
kind: note
description: Link Microsoft's cloud hosting platform Competitors AWS GCP Resources Learning DevOps Get started with Azure DevOps learning path FAQ Management Hierarchy (Top to Bottom) The management hierarchy,…
words: 390
readingMinutes: 2
created: '2025-06-28T08:48:20+02:00'
updated: '2026-06-29T11:03:43+02:00'
website: https://azure.microsoft.com/
---
## Link

<https://azure.microsoft.com/>

[Microsoft](/notes/microsoft)'s cloud hosting platform
# Competitors
- [AWS](/notes/aws)
- [GCP](/notes/google-cloud)
# Resources
## Learning
### [DevOps](/notes/devops)
- [Get started with Azure DevOps](https://learn.microsoft.com/en-us/training/paths/evolve-your-devops-practices/) learning path
# FAQ
## Management Hierarchy (Top to Bottom)
The management hierarchy, using a storage blob as an example:

**Azure Active Directory Tenant**
- The root identity boundary for your organization
- Contains all users, groups, and applications
- Can contain multiple subscriptions

**Management Groups** (Optional)
- Containers for organizing multiple subscriptions
- Used for applying governance policies across subscriptions
- Can be nested up to 6 levels deep
- Helpful for large enterprises with many subscriptions

**Subscriptions**
- Billing and access boundary
- Contains resource groups and resources
- Has spending limits and quotas
- Where you get billed for Azure services

**Resource Groups**
- Logical containers for Azure resources
- Share the same lifecycle, permissions, and policies
- Must exist in a specific Azure region (though resources inside can be in different regions)

**Storage Accounts**
- Your actual storage service
- Must be placed within a resource group
- Inherits permissions and policies from above levels

So the complete hierarchy for a "blob" looks like: **AAD Tenant → Management Groups (optional) → Subscription → Resource Group → Storage Account → Container → Blob**
## Block storage configuration at different hierarchies
Azure block storage has a clear hierarchical structure where configuration options are available at different levels:
### Storage Account Level
The storage account is the top-level container and sits within an **Azure region**. Key configurations at this level include:
- **Performance tier** (Standard vs Premium)
- **Replication strategy** (LRS, GRS, RA-GRS, ZRS, etc.)
- **Access tier defaults** (Hot, Cool, Archive)
- **Security settings** like encryption, access keys, and Azure AD integration
- **Networking rules** including firewalls and virtual network access
- **Data protection policies** like soft delete and versioning
### Container Level
Containers sit within storage accounts and have their own configuration options:
- **Access level** (Private, Blob, or Container)
- **Metadata** for organizing and tagging
- **Access policies** for shared access signatures
- **Immutability policies** for compliance scenarios
### Blob Level
Individual blobs within containers can be configured for:
- **Access tier** (Hot, Cool, Archive) - can override account defaults
- **Metadata and custom properties**
- **Content type and encoding**
- **Cache control and content disposition headers**

The hierarchy flows: **Azure Region → Storage Account → Container → Blob**

Most foundational settings like replication and performance are locked in at the storage account level since they affect the underlying infrastructure. More granular settings around access and lifecycle can be managed at the container and blob levels.