Create Your First Resource Group

You've got your Azure subscription ready, you know what a resource is, and now you're staring at a blank portal wondering: where do I actually put things? This is exactly where resource groups come in — the unsung backbone of every Azure deployment. Without understanding resource groups, you'll quickly end up with a tangled mess of resources that are hard to manage, track, and clean up. In this lesson, you'll learn how to create your first resource group and, more importantly, why it's the first step in any Azure project.

The problem this lesson solves

When you start working in Azure, it's tempting to just start creating virtual machines, databases, and storage accounts ad hoc. But without a logical container to organize them, you'll face a few immediate headaches:

• No clear ownership or cost tracking — you can't easily tell which team or project a resource belongs to.
• Hard to manage permissions — setting access for a group of resources means configuring each one individually.
• Messy cleanup — when a project is done, deleting every resource one by one is tedious and error-prone.
• Unexpected dependencies — resources often depend on each other (like a VM needing a network interface), and without grouping, those relationships are invisible.

Resource groups solve all of this by acting as a logical container that holds related resources for an Azure solution. They let you manage, monitor, and delete resources as a group, and they're the foundational unit for access control and cost reporting.

Core concept / mental model

Think of a resource group as a project folder on your computer. Just as you'd keep all files for one project in a dedicated folder, Azure resources that work together belong in the same resource group.

• Logical, not physical — resources in a group can be in different regions; the group just ties them together logically.
• One resource, one group — each resource can belong to only one resource group at a time, though you can move it later.
• Hierarchy — groups live inside a subscription, and you can have multiple groups per subscription.

Azure Resource Manager (ARM) treats the resource group as the deployment scope. When you deploy a template, you deploy it to a group, and that group becomes a boundary for lifecycle management and access control.

How it works step by step

Creating a resource group is a simple operation, but it's worth understanding what Azure does under the hood:

1. Authenticate — Azure CLI verifies your credentials (via az login or managed identity).
2. Check subscription — you must be in the correct subscription context (az account show).
3. Validate location — Azure checks that the group's location (the metadata region) is valid.
4. Create the group — ARM stores the group association in the control plane, not tied to any specific resource region.
5. Assign tags (optional) — you can add key-value tags immediately for organization.

The key insight: the location you choose for the resource group is not where resources live — it's where the metadata about the group is stored. Resources can be deployed to any region you choose.

Hands-on walkthrough

Let's create your first resource group using the Azure CLI, which is the most scriptable and repeatable method. If you haven't already, log in:

az login

Then set your subscription (optional if you only have one):

az account set --subscription "YourSubscriptionNameOrID"

Now create the resource group. In this example, we'll name it rg-mydemo-dev and place it in eastus (you can pick any valid region):

az group create --name rg-mydemo-dev --location eastus --tags "project=demo" "env=dev"

Expected output (abbreviated):

{
  "id": "/subscriptions/xxx/resourceGroups/rg-mydemo-dev",
  "location": "eastus",
  "name": "rg-mydemo-dev",
  "tags": {
    "project": "demo",
    "env": "dev"
  }
}

Pro tip: Adopt a naming convention like rg-[app]-[env]. It makes it easy to identify the resource group and its purpose at a glance.

To list your resource groups, run:

az group list --output table

Output:

Name           Location    Status
-------------  ----------  ----------
rg-mydemo-dev  eastus      Succeeded

Now let's add a simple resource to the group — a free-tier Log Analytics workspace, which is a good way to prove the concept:

az monitor log-analytics workspace create --resource-group rg-mydemo-dev --workspace-name my-demo-workspace --location eastus

After it finishes, verify the workspace is inside the group:

az resource list --resource-group rg-mydemo-dev --output table

You'll see the workspace listed. You can also check the Azure portal: navigate to Resource groups → select rg-mydemo-dev and you'll see the workspace inside.

Finally, consider tagging resources at creation time. For example:

az group create ... --tags "costCenter=12345" "owner=team-alpha"

This is invaluable for cost tracking when you have many groups.

Compare options / when to choose what

There are several ways to create a resource group. Here's a quick comparison:

Choose CLI for quick experiments and automation. Use Bicep/ARM for production deployments to ensure consistency across environments. Terraform is great if you're already using it for other clouds.

Troubleshooting & edge cases

Even this simple task can hit a few snags. Here are the most common:

• az: command not found — You haven't installed the Azure CLI. Install it first, then log in.
• ZSH: command not found: az — On macOS/Linux, you may need to restart your terminal or add az to PATH.
• No subscriptions found — You haven't logged in or have no active subscriptions. Run az login and ensure you have the right account.
• Location 'xyz' is not a valid location — You mistyped a region name. Use az account list-locations -o table to see valid names.
• Resource group should be a string — You used a variable that's empty. Double-check parameter spelling.
• Name conflicts — Resource group names must be unique within a subscription. If you see a conflict, choose another name.
• Tags with spaces — When passing tags with spaces, quote them: --tags "project=my demo".

Edge case: Resource groups are not bound to a single region. You can deploy a resource group in eastus and then place a VM in westus inside that group — Azure handles it logically.

What you learned & what's next

You now understand the core concept behind creating your first resource group and have completed a practical exercise that demonstrates it. You can:

• Explain what a resource group is and why it matters.
• Create a resource group via Azure CLI with tags.
• Add a resource (like a Log Analytics workspace) to the group.
• Compare different ways to create groups and choose the right one.

The next lesson in the Azure Tutorial path will build on this foundation by showing you how to deploy a real workload — like a virtual machine or a web app — into the resource group you just created. You'll learn how to bundle resources together and manage them as a unit.

Key takeaway: The resource group is your project's home in Azure. Always create it first, tag it meaningfully, and deploy resources into it — you'll thank yourself later.