## Introduction Why does Azure feel like a second platform rather than "Windows in the cloud"? Microsoft Azure is more than virtual machines and Office integration. It is a global system of regions, a distinct identity layer, and a management hierarchy that relies on understanding key ideas. This article explains Azure's structure: regions, Availability Zones, Microsoft Entra ID, resource groups, subscriptions, and the shared responsibility model. It highlights principles and trade-offs to help you make better decisions and avoid costly mistakes. **What this is (and isn't):** This article explains Azure principles and trade-offs, focusing on *why* Azure works and how core pieces fit together. It excludes tutorials, certification prep, or detailed service dives. **Why Azure fundamentals matter:** * **Fewer surprise bills:** Understanding billing and resource lifecycle helps avoid runaway costs. * **Safer defaults:** Understanding Entra ID, Azure RBAC, and the shared responsibility model reduces misconfigurations that lead to breaches. * **Smarter architecture:** Understanding regions, Availability Zones, and resource groups aids in designing for latency, resilience, and governance. * **Clearer conversations:** Align with stakeholders and specialists through a shared mental model. This article outlines a basic mental model for every project: 1. **Where it runs:** Regions and Availability Zones, and why placement matters. 2. **How it is organized:** Subscriptions and resource groups. 3. **Who can do what:** Identity (Entra ID), access (RBAC), and least privilege. 4. **What you use:** Core building blocks: compute, storage, networking. 5. **Who owns what:** The shared responsibility model and security. > Type: **Explanation** (understanding-oriented). > Primary audience: **beginner to intermediate** (developers, ops, and technical leads new to Azure) ### Prerequisites & Audience **Prerequisites:** Basic familiarity with servers, networking, and "the cloud." No Azure portal experience needed. **Primary audience:** Developers, DevOps, or technical leads using or considering Azure, seeking to understand the "why" behind the portal and APIs. **Jump to:** [Section 1: Global Infrastructure](#section-1-global-infrastructure--regions-and-availability-zones) • [Section 2: Subscriptions and Resource Groups](#section-2-subscriptions-and-resource-groups) • [Section 3: Identity and Access](#section-3-identity-and-access--entra-id-and-rbac) • [Section 4: Core Building Blocks](#section-4-core-building-blocks--compute-storage-network) • [Section 5: Shared Responsibility](#section-5-shared-responsibility-model) • [Section 6: Billing and Cost](#section-6-billing-and-cost) • [Common Mistakes](#section-7-common-azure-mistakes--what-to-avoid) • [Misconceptions](#section-8-common-misconceptions) • [When NOT to Use Azure](#section-9-when-not-to-use-azure) • [Future Trends](#future-trends--evolving-standards) • [Limitations & Specialists](#limitations--when-to-involve-specialists) • [Glossary](#glossary) Start at Section 1 if new to Azure; if familiar with virtual machines or Azure Functions but confused by regions or RBAC, jump to those sections. **Escape routes:** To secure a subscription quickly, read Section 3 (identity and RBAC) and Section 5 (shared responsibility), then tighten access and remove overly broad roles. For cost explanations, read Section 6 and "Common mistakes." ### TL;DR – Azure Fundamentals in One Pass If you only remember one mental model, make it this: * **Regions and Availability Zones:** Your workload runs in a region; Availability Zones are isolated data centers to survive a site failure. * **Subscriptions and resource groups:** Subscriptions define billing and governance; resource groups organize resources for lifecycle and access. * **Entra ID and RBAC:** Identity in Entra ID; RBAC controls access. Avoid long-lived keys; prefer managed identities and least privilege. * **Shared responsibility:** Microsoft manages infrastructure; you protect data, configurations, and access. * **Billing:** You pay for what you use; unused resources still cost money. **The Azure mental model:** ```mermaid flowchart TB subgraph placement["Placement"] SUB[Subscription] RG[Resource groups] R[Resources in region/AZ] SUB --> RG --> R end subgraph region["Region"] REG[Region] AZ[Availability Zones] SVC[Services: compute, storage, network] REG --> AZ --> SVC end subgraph security["Identity & responsibility"] E[Entra ID: who] RB[RBAC: what they can do] SR[Shared responsibility: who owns what] end subgraph cost["Cost"] B[Billing: pay for usage; clean up what you don't use] end placement --> security region --> security security --> cost ``` ### Learning Outcomes By the end of this article, you will be able to: * Explain **why** regions and Availability Zones exist and when to choose a region or multi-AZ. * Describe **why** subscriptions and resource groups exist and how they affect governance and cost. * Explain **why** Entra ID and RBAC are central to security and how least privilege reduces risk. * Describe **why** the shared responsibility model matters and what you are responsible for. * Describe how **billing** works (pay per use, no default shutdown) and how that drives cost control. * Explain **why** core services (e.g., Virtual Machines, Blob Storage, Virtual Network) are structured as they are and when to use them. * Describe common **mistakes** (open NSGs, broad roles, orphaned resources) and how to avoid them. ## Section 1: Global Infrastructure – Regions and Availability Zones Azure spans regions, each with separate data center clusters. Availability Zones in a region are physically distinct locations with independent power and networking. You select a region to create resources, and many services allow spreading workload across zones for resilience. ### Understanding the Basics – Regions and Availability Zones **Region:** A geographic area (e.g., East US, West Europe) where data and resources don't automatically replicate elsewhere. Region choice is based on regulatory and latency needs. **Availability Zone:** Each zone consists of one or more data centers spaced apart to minimize risk, connected by low-latency links for high-availability databases or apps across zones. **Why this design:** Customers need data control for sovereignty, compliance, and resilience against data center failures. A region is a geographic boundary; zones are locations within it. Regions define geography; zones provide local redundancy. ### Why This Works – Regions and Availability Zones Regions set failure and compliance boundaries. Availability Zones offer simple multi-datacenter resilience within a region. Cross-region replication and failover are more complex and costly, so many workloads stay in a single region across multiple zones. ### Trade-offs and Limitations – Regions and Availability Zones * **Single region:** Simpler and cheaper, but the whole region can have an outage (rare but possible). * **Multi-zone in one region:** Good balance of resilience and complexity; recommended for production. * **Multi-region:** Highest resilience and geographic distribution, but more cost and operational complexity. ### When Regions and Availability Zones Aren't Enough For global low-latency needs like edge caching or content delivery, use services like Azure Front Door or Azure CDN. Regions and zones relate to data and compute location, not user serving at the edge. ### Quick Check: Global Infrastructure Before moving on: * What is the difference between a region and an Availability Zone? * Why might you pick one region over another (besides latency)? * When would you use more than one zone? **Answer guidance:** Ideal result: You can say that a region is a geographic area with multiple zones, and zones are isolated locations for redundancy; region choice is driven by compliance and latency; multi-zone is for production resilience. If any part is fuzzy, skim the subsection on "Understanding the Basics" again. ## Section 2: Subscriptions and Resource Groups Azure adds a management layer that AWS does not emphasize in the same way: **subscriptions** and **resource groups**. Subscriptions are the unit of billing and governance. Resource groups are containers for resources that share lifecycle, access, or tagging. ### Understanding the Basics – Subscriptions and Resource Groups **Subscription:** A logical boundary for billing, quotas, and policies. You can have multiple subscriptions (e.g., dev, prod, per department). Access and policies are often applied at the subscription scope. **Resource group:** A container holding related resources (e.g., VM, disk, network). Each resource belongs to one resource group, which resides within a subscription. Resource groups help deploy, delete, or manage resources as a set and scope RBAC. **Why this design:** Think of a subscription as the billing account, and resource groups as folders for related resources you deploy or delete together. Subscriptions let you separate billing and governance (e.g., by environment or business unit). Resource groups give you a place to group resources and to apply roles at a scope smaller than the whole subscription. ### Why This Works – Subscriptions and Resource Groups Clear subscription boundaries reduce billing confusion and simplify policy application. Resource groups help clean up (delete group and resources) and grant access to subsets. Poor grouping causes orphaned resources or excessive access. ### Trade-offs and Limitations – Subscriptions and Resource Groups * **Too many subscriptions:** Use when real billing or policy separation is needed; can increase overhead and be harder to manage. * **Too few or huge resource groups:** Hard to clean up and to scope access; prefer smaller, purpose-based groups. * **Moving resources:** You can move resources between groups or subscriptions, but not all; plan grouping early. ### When Subscriptions and Resource Groups Aren't Enough Azure uses **management groups** above subscriptions for organization-wide governance, suitable for larger enterprises. Most teams find subscriptions and resource groups sufficient. ### Quick Check: Subscriptions and Resource Groups * What is a subscription used for? * What is a resource group, and why would you put several resources in one? * Can a resource belong to two resource groups? **Answer guidance:** Ideal result: A subscription handles billing and governance, a resource group contains related resources for lifecycle and access, and each resource belongs to one group. If unsure, re-read "Understanding the Basics." ## Section 3: Identity and Access – Entra ID and RBAC **Microsoft Entra ID** (formerly Azure Active Directory) is Azure's identity provider. **Azure Role-Based Access Control (RBAC)** determines permissions for actions on resources. Requests are checked against identity and RBAC. No identity means no permission; no permission means no action. ### Understanding the Basics – Entra ID and RBAC **Entra ID:** Manages users, groups, and service principals. It can federate with existing Active Directory or other identity providers. Apps and VMs use **managed identities** to access credentials without secrets. **RBAC:** Assigns a **role** (permissions) to a **principal** (user, group, service principal) at a **scope** (subscription, resource group, resource). Built-in roles (e.g., Contributor, Reader) cover common needs; custom roles are possible. Principle of least privilege: grant only what is needed at the smallest scope. **Credentials:** Long-term keys like storage account keys and secrets are risky if leaked. Use managed identities for Azure workloads to get short-lived tokens. Resort to service principals with certificates or secrets only if a managed identity isn't available. ### Why This Works – Entra ID and RBAC Entra ID centralizes identity; RBAC manages permissions. Together, they enable least privilege, auditing (e.g., Azure Monitor, logs), and reduce long-lived secrets. The challenge lies in scoping: who gets what at subscription, resource group, or resource levels. ### Examples A common mistake is assigning **Contributor** at the subscription level so someone can "do their job." Contributor permits creating, updating, and deleting most resources. A safer approach is assigning a limited role (like a custom or narrower built-in role) at the resource group. * Scope the role to the resource group only essential for that identity. * Use built-in roles like "Storage Blob Data Contributor" for data-plane access instead of broad control-plane Contributor. Managed identity example: An Azure Function using managed identity to read Blob Storage should have "Storage Blob Data Reader' access and no keys in code. ### Trade-offs and Limitations – Entra ID and RBAC * **Fine-grained roles:** Safer but requires more maintenance. Start narrow; widen only when necessary. * **Managed identities:** Prefer them for apps and VMs; use service principal secrets only if managed identity isn't available (e.g., some external systems). ### When Entra ID and RBAC Aren't Enough RBAC controls Azure control-plane and data-plane operations but doesn't replace application authorization, encryption, or network controls. Secure app and network design is still needed. ### Quick Check: Identity and Access * What is the difference between Entra ID and RBAC? * Why are long-lived storage keys or secrets in code problematic? * What does "least privilege" mean in practice? **Answer guidance:** Ideal result: Entra ID defines who you are; RBAC controls what you can do and on which resources. Long-lived keys in code can leak and are difficult to rotate. Least privilege means granting only necessary permissions at the smallest scope. If unsure, re-read relevant sections. ## Section 4: Core Building Blocks – Compute, Storage, Network Azure provides many services, key ones being **compute** (Virtual Machines, Azure Functions), **storage** (Blob Storage, Managed Disks), and **networking** (Virtual Network, subnets, Network Security Groups). Knowing their purpose and relationships aids in selection and integration. ### Compute **Azure Virtual Machines (VMs):** Select size, image, and region. Pay for runtime and storage. Use VMs for full OS control and long processes. **Azure Functions:** Executes code on events without managing servers; pay per run and compute, ideal for short, event-driven tasks like APIs or file processing. Cold starts and limits are trade-offs. **Why both exist:** VMs handle stateful, long workloads; Functions are for event-driven, stateless, variable loads. Many systems use both. ### Storage **Azure Blob Storage:** Object storage stores and retrieves data by key, without a traditional file system. It's durable, scalable, and ideal for backups, static assets, and data lakes. **Azure Managed Disks:** Block storage attached to VMs for databases, file systems, or low-latency I/O. Tied to a region, snapshots can be copied across regions. **Why this split:** Blob offers scalable, durable objects; Managed Disks provide block storage for a VM, with different access and durability models. ### Network **Azure Virtual Network (VNet):** Your isolated network with subnets, route tables, and gateways, hosting most resources like VMs and Azure SQL inside a VNet. **Network Security Groups (NSGs):** Stateful rules control traffic by type, port, and source, with a default deny setting, opening only necessary connections. **Why it matters:** A VNet provides a boundary; NSGs restrict resource access. Misconfigurations, like allowing SSH or RDP from the internet, often cause security issues. ### Quick Check: Core Building Blocks * When would you choose a VM over Azure Functions (or the reverse)? * What is Blob Storage best used for versus Managed Disks? * What is the role of an NSG in a VNet? **Answer guidance:** Ideal result: Use VMs for long or stateful control, Functions for short, event-driven tasks. Blob stores objects; Managed Disks are block storage; NSGs regulate traffic. Review your least familiar service subsection. ## Section 5: Shared Responsibility Model Microsoft explains security as **shared responsibility**: it manages cloud security (infrastructure, hardware, physical security, patching), while you oversee security *in* the cloud (data, configurations, identity, RBAC, network, encryption, app security). ### Why This Matters Assuming "Microsoft handles security" can lead to weak RBAC, open NSGs, or leaked keys. Breaches often result from customer mistakes like misconfiguration or credential theft. Understanding this split helps focus on your responsibilities. ### What Microsoft Typically Covers * Physical security of data centers. * Hardware and network infrastructure. * Hypervisor and underlying platform (e.g., Azure SQL patching) for managed services. * Global infrastructure (regions, Availability Zones). ### What You Typically Cover * Entra ID and RBAC (users, groups, roles, scopes). * NSG and network rules. * Encryption of your data (at rest and in transit, where you control it). * Patching and hardening OS and applications on VMs or containers. * Secure handling of secrets and access control. ### Quick Check: Shared Responsibility * What does "security of the cloud" mean versus "security in the cloud" in one sentence? * Give two examples of something *you* are responsible for. **Answer guidance:** Ideal result: "Of the cloud" is Microsoft's infrastructure; "in the cloud" is your data, config, identity, RBAC, and app security. You handle RBAC, NSGs, and patching. If you confuse them, review "What Microsoft Typically Covers" and "What You Typically Cover." ## Section 6: Billing and Cost Azure billing is **pay-as-you-go**: you pay for resources as long as they exist or run. Nothing turns off automatically when you leave. Unused VMs (even when deallocated), unattached disks, old snapshots, and unused Blob Storage keep costing you until you delete or change them. ### Why It Works This Way The model scales with usage and avoids high upfront costs. Cost control requires discipline: tagging, budgets, alerts, and cleanup. Surprise bills often result from a few large or long-running resources (like VMs, Azure SQL, data transfer) or many small ones (disks, snapshots, Blob Storage). ### How to Think About Cost * **Identify big spenders:** Use Cost Management tools by service and resource, focusing on compute, storage, and data transfer. * **Tag resources:** Tag by project, environment, or owner to attribute and review costs. * **Set budgets and alerts:** Set a budget and get alerts near thresholds. * **Clean up routinely:** Deallocate or delete dev/test resources, orphaned disks, and old snapshots. Review Blob lifecycle and retention. ### Quick Check: Billing * Why can an Azure bill grow even when "nothing is running"? * Name two resources that are easy to forget and keep billing. **Answer guidance:** Ideal result: Billing continues for existing disks, snapshots, Blob Storage, unattached Managed Disks, snapshots, and Blob containers. Re-read first two subsections if unsure. ## Section 7: Common Azure Mistakes – What to Avoid Common mistakes lead to security incidents, costs, or outages. Recognizing them helps prevent repeats. ### Mistake 1: Overly Permissive Network Security Groups Allowing SSH (port 22) or RDP (port 3389) from `0.0.0.0/0` or `*` exposes VMs to the internet. A weak password or key can lead to compromise. **Incorrect:** Allowing inbound from `*` on port 22 or 3389 for "convenience." **Correct:** Restrict access to your IP or a bastion in a locked-down NSG, and use key-based authentication and hardening. ### Mistake 2: Broad RBAC at Subscription or Resource Group Scope Assigning Contributor or Owner at a subscription or large resource group grants full control, risking widespread impact if an identity is compromised. **Incorrect:** Assign Contributor at subscription scope so teams can manage resources. **Correct:** Assign narrower roles (e.g., Contributor or custom roles) at the resource group or resource scope that contains what they need. ### Mistake 3: Long-Lived Keys or Secrets in Code Storing account keys or secrets in config or code can leak, are hard to rotate, and increase the blast radius if compromised. **Incorrect:** Hardcoding connection strings or secrets in code or configs. **Correct:** Use managed identities for Azure workloads; reference secrets at runtime via Azure Key Vault. Rotate secrets regularly. ### Mistake 4: Ignoring Idle and Orphaned Resources Deallocated VMs can still incur disk costs through unattached Managed Disks, old snapshots, and unused Blob Storage, accumulating over time. **Incorrect:** Leaving dev/test resources running or not deleting disks and snapshots after decommissioning. **Correct:** Tag by environment and purpose, set billing alerts, and regularly clean up non-production resources and orphaned storage (manually or automatically). ### Mistake 5: Single Zone or Single Region for Production Running production in one zone or region risks downtime if that location fails. Many workloads require at least two zones or regions for availability. **Incorrect:** Deploying production databases or critical app tiers in a single zone without accepting that risk. **Correct:** Use zone-redundant or multi-zone options where availability matters (e.g., Azure SQL, VMs across zones), and understand the trade-offs of single-zone or single-region designs. ### Quick Check: Common Mistakes * Why is opening SSH or RDP to the whole internet dangerous? * What should you use instead of long-lived keys in application code? * Name two resource types that often cause "forgotten" cost. **Answer guidance:** Ideal result: Open SSH/RDP exposes you to brute force and credential theft; use restricted IPs, bastion, and managed identities (or Key Vault) instead of keys in code. Managed Disks, snapshots, and Blob Storage are common sources of forgotten costs. If any answer is unclear, skim the matching mistake above. ## Section 8: Common Misconceptions * **"Microsoft is responsible for my security."** Microsoft handles cloud security; you manage security in the cloud (data, config, identity, RBAC, patching). Both matter. * **"If I deallocate my VM, I stop paying."** You stop paying for compute when the VM is deallocated but still pay for attached disks and other resources. * **"Regions are just for latency."** Regions matter for data residency, compliance, and isolation, not just latency. * **"RBAC is only for people."** RBAC covers users, groups, and service principals. Workloads should use managed identities and roles rather than shared accounts or keys. * **"Blob Storage is just file storage."** Blob Storage is object storage with its own API and consistency model. It is not a traditional file system; use it for objects and scale, not for random read/write like a local disk. ## Section 9: When NOT to Use Azure Azure isn't always suitable; recognizing when to skip or limit it helps concentrate efforts. **Strict data sovereignty or air-gapped requirements:** If data must stay within a specific facility or disconnected environment, a public cloud may not suffice; hybrid or on-prem may be necessary. **Very small or static workloads:** A small server or hosted app may be cheaper and simpler than learning Azure for a static site or low-traffic tool. Compare total cost and effort. **Team has no capacity to learn cloud:** If the team can't invest in identity, networking, and billing, a managed platform or limited services could reduce misuse risk and cost. **Existing long-term commitment elsewhere:** Move to Azure only if it adds value; otherwise, the cost of switching from another cloud or on-prem may not be justified. **Regulatory or contractual bars:** Some policies restrict data in public clouds or certain countries. Check before assuming Azure is allowed. Even when skipping Azure for some workloads, concepts like regions, least privilege, shared responsibility, and pay-for-use still apply. A minimal security-and-cost mindset remains useful. ## Building on Azure ### Key Takeaways * **Regions and Availability Zones:** Select a region for compliance and latency; use multiple zones for resilience. * **Subscriptions and resource groups:** Use subscriptions for billing and governance; group resources with resource groups to scope access. * **Entra ID and RBAC:** Prefer managed identities and least privilege; avoid long-lived keys in code. * **Shared responsibility:** You own security in the cloud; design and operate with that in mind. * **Billing:** You pay for what exists, runs, and is maintained to prevent waste and surprises. * **Core services:** Use VMs, Functions, Blob, Managed Disks, VNet, and NSGs with clear roles. ### How These Concepts Connect Placement (regions, zones) decides where data and workload are stored. Subscriptions and resource groups set governance and scope. Entra ID and RBAC specify permissions. The shared responsibility model clarifies security roles. Billing links everything to cost, forming a baseline for Azure. ### Getting Started with Azure Start with a narrow, repeatable workflow if new to Azure. 1. Pick one region and understand why you chose it. 2. Create a subscription or use an existing one, a resource group, a VNet, and lock down NSGs. 3. Use managed identities for VMs and Functions; avoid long-lived keys in code. 4. Enable billing alerts and basic cost visibility. 5. Run a small workload, then tear it down to confirm cost stops. Once routine, apply discipline (least privilege, tagging, and cleanup) to more services and environments. ### Next Steps **Immediate actions:** * Review RBAC at subscription and resource group levels; eliminate or restrict broad roles. * Enable billing alerts, Cost Management, and tag a project. * Review NSGs for allow rules from the internet and restrict them. **Learning path:** * Read the [Microsoft Azure Well-Architected Framework][well-architected] pillars (reliability, security, cost, etc.). * Compare with [Fundamentals of AWS][fundamentals-aws] for the same mental model (regions, identity, shared responsibility) on another cloud. * Try a hands-on tutorial for a service (e.g., VMs or Azure Functions) in a sandbox or trial subscription. * Map a workload to regions, resource groups, identity, and shared responsibility. **Practice exercises:** * Create a managed identity for an Azure Function and grant it only "Storage Blob Data Reader" on one storage account. * Deploy a small VM in a VNet with an NSG that restricts SSH or RDP access to only your IP. * Set a budget alert and trigger it safely to see how notifications work. **Questions for reflection:** * Which region and how many zones suit your workload? * What are your responsibilities in the shared responsibility model? * Which resources would you tag first for cost and ownership? ### The Azure Workflow: A Quick Reminder ```mermaid flowchart TB A[Choose region/zone] B[Organize with subscriptions & resource groups] C[Harden identity & NSGs] D[Run workload with least privilege] E[Tag & monitor cost] F[Clean up] A --> B --> C --> D --> E --> F ``` I see it as: first placement and organization; then identity and network; then run with minimal permissions; finally, make costs visible and cleanup. ### Final Quick Check Before you move on, see if you can answer these out loud: 1. What distinguishes a region from an Availability Zone? 2. Why choose managed identities over long-lived keys? 3. What does "security in the cloud" mean in the shared responsibility model? 4. Why can your bill stay high even after you "turn off" a VM? 5. What's a dangerous NSG pattern and alternative? If any answer feels fuzzy, recheck the matching section and skim the examples again. ### Self-Assessment – Can You Explain These in Your Own Words? * Regions and Availability Zones: when to use multiple zones. * Subscriptions versus resource groups and why both exist. * Entra ID and RBAC: why least privilege matters. * The shared responsibility model and your two responsibilities. If you can explain these clearly, you have internalized the fundamentals. ## Future Trends & Evolving Standards Azure and cloud practices keep evolving. Here are some directions affecting your Azure use: ### More Managed and Serverless Azure adds managed and serverless options like Azure Functions, Container Apps, managed databases. The trade-off is less control but reduced operational load. Deciding when to choose managed versus "bring your own" (e.g., VMs) remains important. **What this means:** More options between "run it yourself" and "let Azure run it." **How to prepare:** Decide based on workload, focusing on consistency, compliance, and cost, not just trends. ### Entra ID and Identity-First Security Microsoft invests in Entra ID as the access control plane, emphasizing conditional access, identity policies, and reducing long-lived secrets. **What this means:** Identity and RBAC will become even more important; managed identities and least privilege will be standard recommendations. **How to prepare:** Use managed identities and narrow roles; plan to reduce or rotate long-lived secrets. ### Sustainability and Cost Carbon and cost issues highlight the importance of region choice and resource efficiency. Right-sizing and cleanup improve costs and sustainability. **What this means:** Region selection and "right size, then clean up" will matter more for some organizations. **How to prepare:** Include efficiency and cleanup in regular operations, not just during cost reviews. ## Limitations & When to Involve Specialists Azure fundamentals provide a solid base, but some situations require specialist help. ### When Fundamentals Aren't Enough * **Complex compliance (e.g., HIPAA, PCI-DSS, FedRAMP):** Requires detailed control mapping, evidence, and often third-party assessments. * **Large-scale architecture (multi-region, high throughput):** Capacity, networking, and failure modes become complex. * **Migration at scale:** Moving large or critical systems needs careful planning, testing, and specialized tools and expertise. ### When Not to DIY Azure * **Audits and certifications** that require documented controls and evidence. * **Incident response** that involves legal, forensics, or regulatory reporting. * **Designing for very high availability or disaster recovery** across regions with strict RTO and RPO requirements. ### When to Involve Azure or Cloud Specialists Consider specialists when: * You need to design or review for compliance or certification. * You are planning a major migration or architectural change. * You had a security incident and need response and hardening. **How to find specialists:** Use Microsoft partners, Well-Architected reviews, or hire experienced staff or consultants for compliance, scaling, or migration. ### Working with Specialists * Share your constraints (budget, compliance, timeline) so they can propose options. * Ask for a clear responsibility split (identity, networking, backups). * Request documentation and handoff so your team can operate and extend what they build. ## Glossary **Availability Zone:** Azure regions have multiple data centers for fault isolation, with resources distributed across zones for higher availability. **Entra ID (Microsoft Entra ID):** Microsoft's identity provider (formerly Azure Active Directory) manages users, groups, and service principals for sign-in and RBAC. **Region:** A geographic area where Azure runs data centers. Each region is independent; data is not automatically copied across regions. **Resource group:** A container in a subscription that holds Azure resources, used for lifecycle, access, and tagging. Each resource belongs to one resource group. **RBAC (Role-Based Access Control):** Azure's permission system involves assigning roles to principals (users, groups, service principals) at a scope (subscription, resource group, resource). **Shared responsibility model:** Division of security: Microsoft (cloud security) versus customer (security in the cloud). **Subscription:** A logical unit in Azure for billing, quotas, and policies, containing resource groups and resources. **VNet (Virtual Network):** Your isolated Azure network for subnets, routing, and hosting resources such as VMs and Azure services. **NSG (Network Security Group):** Rules that control traffic to/from subnets or network interfaces in a VNet. ## References ### Microsoft Documentation and Frameworks * [Microsoft Azure Well-Architected Framework][well-architected]: Reliability, security, cost, and other pillars for designing workloads on Azure. * [Introduction to Azure][azure-overview]: High-level description of Azure and its services (Microsoft Learn). * [Shared responsibility in the cloud][shared-responsibility]: Official explanation of the division of security responsibilities (Microsoft Learn). * [What is Microsoft Entra ID?][entra-id]: Identity and access basics (Microsoft Learn). * [What is Azure role-based access control (RBAC)?][rbac-docs]: How RBAC works and how to assign roles (Microsoft Learn). ### Billing and Cost * [Azure cost management and billing][billing-docs]: How billing works and how to monitor and control cost (Microsoft Learn). ### Note on Verification Azure services and best practices evolve. Check current behavior in the [Azure documentation][azure-docs] and test in non-production before security or architecture decisions. [fundamentals-aws]: /blog/2026/03/06/fundamentals-of-aws/ [well-architected]: https://learn.microsoft.com/en-us/azure/well-architected/ [azure-overview]: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview [shared-responsibility]: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility [entra-id]: https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra [rbac-docs]: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview [billing-docs]: https://learn.microsoft.com/en-us/azure/cost-management-billing/ [azure-docs]: https://learn.microsoft.com/en-us/azure/