Azure Fundamentals for Web Hosting: Azure account, subscriptions, resource groups, and regions

Core building blocks you use in every hosting setup

Tenant (Microsoft Entra ID tenant)

A tenant is your identity and directory boundary in Azure. It contains users, groups, app registrations, and the policies that control authentication. In practice, the tenant is where you decide “who can sign in” and “which identities can be granted access to Azure resources.”

• Isolation: Strong identity boundary. Separate tenants are used when you need hard separation of identities (for example, different companies or strict regulatory separation).
• Permissions: Role assignments in Azure ultimately map back to identities in the tenant.
• Lifecycle: Tenant-level decisions (identity governance, MFA, conditional access) affect every subscription connected to that tenant.

Subscription

A subscription is a billing and quota boundary and a common administrative boundary. Resources live inside a subscription, and access can be granted at the subscription scope (or narrower). Many organizations use subscriptions to separate environments (prod vs non-prod) or to separate business units for cost tracking.

• Isolation: Good isolation for cost, quotas, and access. Not as “hard” as separate tenants for identity separation, but often sufficient for environment separation.
• Permissions: You can assign roles at the subscription level (for example, give a team Contributor on a non-prod subscription).
• Naming: Subscription names should clearly indicate purpose and environment (for example, contoso-web-prod).
• Lifecycle: Decommissioning a subscription is a clean way to retire an entire environment or project.

Management groups (conceptual)

Management groups sit above subscriptions and let you apply governance at scale. Think of them as folders for subscriptions. You can apply policies and role assignments at a management group so they inherit down to all subscriptions underneath.

• Use case: Apply consistent rules (allowed regions, required tags, security baselines) across many subscriptions.
• Permissions: Central platform team can manage policy at the management group while app teams manage resources in their subscriptions.

Resource group

A resource group (RG) is a logical container for resources that share a lifecycle. For web hosting, an RG often contains the web app, its networking components, monitoring, and supporting services that should be deployed and retired together.

• Isolation: Not a hard security boundary by itself, but it’s a very practical scope for access control and organization.
• Permissions: Role assignments at RG scope are common (for example, give a team Contributor to rg-web-dev only).
• Naming: Consistent RG naming makes it easy to find and automate operations.
• Lifecycle: Deleting an RG deletes everything inside it—useful for dev/test cleanup, dangerous if used carelessly in prod.

Region

A region is a geographic area containing one or more datacenters. When you create a resource, you typically choose a region. Region choice affects user latency, data residency, service availability, and sometimes cost.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Latency: Place workloads close to users or to dependent systems (like databases) to reduce round-trip time.
• Compliance: Some workloads require data to stay in specific geographies.
• Availability planning: Some services support zone redundancy within a region; others require multi-region design.

How these choices affect isolation, permissions, naming, and lifecycle

Isolation

• Tenant: Identity isolation (who can authenticate, directory policies).
• Subscription: Billing/quota and administrative isolation (common for prod vs non-prod).
• Resource group: Operational isolation (deploy/rollback/clean up as a unit).
• Region: Geographic isolation and data residency (where data and compute run).

Permissions (RBAC scope)

Azure role-based access control (RBAC) can be assigned at multiple scopes. The broader the scope, the more resources the identity can affect.

• Management group: Governance across many subscriptions.
• Subscription: Team-wide access for an environment.
• Resource group: Access for a specific app or system.
• Resource: Access to a single resource (least common day-to-day, but useful for sensitive components).

Naming and discoverability

Consistent naming reduces mistakes and speeds up troubleshooting. A practical pattern is to encode organization, workload, environment, and region where it matters.

• Resource group example: rg-contoso-web-dev-westeurope
• Web workload example: app-contoso-web-dev-weu-001
• Shared resources example: rg-contoso-shared-prod-westeurope

Keep names readable and avoid embedding secrets or personal data. Also plan for growth: add a numeric suffix when you may need multiple instances (-001, -002).

Lifecycle management

• Resource group lifecycle: Best when resources are deployed and retired together (for example, a dev environment you can delete weekly).
• Subscription lifecycle: Best when an entire environment or business unit needs independent governance, budgets, and clean separation.
• Region lifecycle considerations: Moving regions later can be complex; choose carefully early (especially for data services).

Guided setup: resource group, naming/tags, region selection, and environment split

Step 1: Create a resource group

Use an RG as the first “container” for your web hosting resources. Decide the environment and region first, then create the RG.

Azure Portal (conceptual steps):

• Go to Resource groups > Create.
• Select the correct Subscription (double-check environment: dev/test/prod).
• Enter a Resource group name (use your naming standard).
• Select a Region (this is the RG metadata location; still choose the same region you plan to deploy into for consistency).
• Select Review + create > Create.

Azure CLI example:

az group create --name rg-contoso-web-dev-westeurope --location westeurope

Step 2: Apply consistent naming and tags

Tags are key/value metadata used for cost allocation, ownership, and automation. Tags don’t enforce security by themselves, but they enable reporting and governance (and can be required via policy).

Recommended baseline tags for web hosting workloads:

• Application: the workload name (for example, contoso-web)
• Environment: dev | test | prod
• Owner: team email or group name (for example, web-platform@contoso.com)
• CostCenter: internal code (for example, CC1234)
• DataClassification: public | internal | confidential

Azure CLI: add tags to the resource group

az group update --name rg-contoso-web-dev-westeurope --set tags.Application=contoso-web tags.Environment=dev tags.Owner=web-platform@contoso.com tags.CostCenter=CC1234 tags.DataClassification=internal

Practical tip: Treat tags as required inputs in your deployment process. If you later automate deployments (templates/pipelines), pass tags as parameters so every resource inherits them where possible.

Step 3: Select a region based on latency and compliance

Pick a region using a short, repeatable decision process:

• Start with user location: Where are most users? Choose the closest region to reduce latency.
• Check data residency requirements: If data must remain in a country/region, restrict your options accordingly.
• Co-locate dependencies: If your web app depends on a database or other services, keep them in the same region when possible to reduce latency and egress costs.
• Confirm service availability: Not every Azure service/feature is available in every region. Verify your required services are supported in the target region.
• Plan for resilience: Decide whether you need availability zones (in-region) or a secondary region (multi-region) for disaster recovery.

Example decision: A web app serving customers primarily in Western Europe with EU data residency requirements might choose westeurope (or another EU region that meets feature and compliance needs).

Step 4: Outline a simple environment split (dev/test/prod)

Separating environments reduces risk. The main choice is whether to separate by resource groups or by subscriptions.

Option A: Separate environments using resource groups (simpler)

Use one subscription and create three RGs:

• rg-contoso-web-dev-westeurope
• rg-contoso-web-test-westeurope
• rg-contoso-web-prod-westeurope

When this works well: Small teams, early-stage projects, or when you need quick setup and centralized billing.

What to watch: Be careful with permissions so dev contributors can’t modify prod resources. Use RBAC at RG scope and consider policy to prevent risky configurations in prod.

Option B: Separate environments using subscriptions (stronger isolation)

Use separate subscriptions, each with its own RG(s):

• Non-prod subscription: RGs for dev and test
• Prod subscription: RGs for production workloads only

When this works well: You need clearer separation for billing, quotas, access control, or compliance. It also reduces the blast radius of mistakes (for example, a script targeting the wrong subscription is easier to detect and block).

Practical governance pattern: Place subscriptions under management groups such as mg-nonprod and mg-prod, then apply stricter policies to mg-prod (for example, restrict allowed regions, require tags, enforce diagnostics).

Pre-deployment checklist for any web workload

• Tenant: Are the right users/groups in the tenant, and do you know which identities will administer the workload?
• Subscription: Are you deploying into the correct subscription for the environment (dev/test/prod) and billing?
• Resource group: Does the RG name clearly identify workload, environment, and region, and does it match the intended lifecycle?
• RBAC: Are roles assigned at the narrowest practical scope (RG or resource), and is prod access limited?
• Tags: Are required tags present (Application, Environment, Owner, CostCenter, DataClassification) for cost and governance?
• Region: Does the region meet latency expectations, compliance/data residency needs, and service availability requirements?
• Environment split: Is there a clear separation between dev/test/prod (RGs or subscriptions), and is it enforced by permissions/policy?
• Lifecycle plan: Do you know how you will update, scale, and eventually retire the resources (and what can be safely deleted)?