Create an Azure Storage Account

Creating an Azure Storage account sounds like a one-click task, but when you’re new to Azure, the portal’s dozens of options can be overwhelming — and a misconfigured account can cost you money or lock you out of your data. This lesson walks you through the core decisions, gives you a repeatable process, and shows you a hands-on example so you can create a storage account with confidence, whether you’re using the portal, the CLI, or infrastructure as code.

The problem this lesson solves

When you need to store blobs, files, queues, or tables in Azure, you can’t just start uploading — you first have to create a Azure Storage account. The problem is that the Azure portal presents you with a form full of fields: subscription, resource group, region, performance tier, redundancy, access tier, network access — and if you pick wrong, you might end up with a storage account in the wrong region (increasing latency), paying for geo-replication you don’t need, or opening your data to the public internet. Without a clear mental model, new developers either freeze at the form or click through defaults without knowing what they just chose, and later struggle to fix misconfigurations.

This lesson solves that by breaking down each setting, giving you a repeatable decision process, and walking you through a concrete example.

Core concept / mental model

Think of an Azure Storage account as a top-level container that holds all your data services: Blob Storage (for unstructured files), File Storage (for SMB shares), Queue Storage (for messages), and Table Storage (for NoSQL data). You can create multiple storage accounts, but each one has its own settings for performance, redundancy, and access.

A helpful analogy: your storage account is like a warehouse — the warehouse itself is the account, and inside it are different aisles (blobs, files, queues, tables). The warehouse’s location (region), security (access keys), and maintenance level (redundancy) are all decided when you build it. You can’t change some of these settings easily later (like performance tier), so it’s worth getting them right the first time.

Key terms you’ll see: - Resource group: a logical folder for Azure resources. Almost everything else — VMs, databases, functions — lives in a resource group, so the storage account should usually go in the same one as the rest of your app. - Region: the Azure datacenter location (e.g., East US, West Europe). Choose the region closest to your users or your other services. - Performance tier: Standard (for most workloads, uses magnetic/SSD mix) vs. Premium (for high-throughput or low-latency, uses SSDs). - Redundancy: how many copies of your data are kept, and where. Options range from LRS (locally redundant) to GRS (geo-redundant) and ZRS (zone-redundant). - Access tier (for blobs): Hot (frequently accessed), Cool (infrequently), Archive (long-term).

How it works step by step

Step 1: Plan your resource group and region

Before you create anything, check if you already have a resource group for your project. If not, create one. Use a naming convention like rg-your-project-<env> (e.g., rg-pythonblog-prod). Choose a region that is either close to your users or where your other Azure services reside — this reduces latency and data egress costs.

Step 2: Choose your storage account settings

When you open the Create storage account blade, you’ll fill in: - Basics: subscription, resource group, storage account name (globally unique, lowercase letters and numbers), region. - Performance: Standard or Premium. For most web apps, start with Standard; switch to Premium only when you have a clear performance need. - Redundancy: For dev/test, LRS saves money; for production with no data loss tolerance, GRS or ZRS is safer. If you don’t know, LRS is fine and can be upgraded later (for most options). - Advanced: set the minimum TLS version (1.2 is a good default) and choose access tier (Hot/Cool) if you’re using blobs.

Step 3: Create and verify

Click Review + create, let Azure validate, then Create. After a minute or so, you’ll see the deployment success message. Navigate to the storage account overview page to see your blob service, file shares, queues, and tables — all empty, waiting for data.

Step 4: Secure and connect

Your new storage account comes with two access keys. For real apps, you should use managed identities or shared access signatures (SAS) instead of keys. But for a quick test, the connection string is handy.

Hands-on walkthrough

Let’s do it for real — you can use the Azure portal, the CLI, or both. First, the portal route, because it gives you a visual feel.

Create via the Portal

1. Go to portal.azure.com and sign in.
2. In the search bar, type storage account and select Storage accounts under Services.
3. Click + Create.
4. On the Basics tab, pick your subscription, then select or create a resource group.
5. Enter a unique name, e.g., mystorageacct1234 (must be lower case, no hyphens).
6. Choose a region — pick the one closest to you.
7. Keep Standard performance and Locally-redundant storage (LRS) redundancy for now.
8. Leave other defaults, click Review + create, then Create.

Wait for the deployment to finish — you’ll see a green checkmark.

Verify with the CLI

If you have the Azure CLI installed, you can list your account and get its keys.

# List storage accounts in your resource group
az storage account list --resource-group rg-tutorial --output table

# Get the connection string for your account
az storage account show-connection-string --resource-group rg-tutorial \
  --name mystorageacct1234

Expected output (similar):

Name                 ResourceGroup    Location    Sku        Kind
------------------   ---------------  ----------  ---------  ---------
mystorageacct1234    rg-tutorial      eastus      Standard   StorageV2

Create a container and upload a file

Once your account exists, the real magic happens in containers. Let’s create one and upload a file using the CLI.

# Create a container called 'mycontainer'
az storage container create \
  --account-name mystorageacct1234 \
  --name mycontainer \
  --auth-mode key

# Upload a local file to the container
az storage blob upload \
  --account-name mystorageacct1234 \
  --container-name mycontainer \
  --name hello.txt \
  --file ./hello.txt \
  --auth-mode key

Output will show a JSON response or just a success message. You can then access your blob via the URL: https://mystorageacct1234.blob.core.windows.net/mycontainer/hello.txt (but it’s private by default — you’d need a SAS or public access to view it).

Or use Bicep (infrastructure as code)

For reproducible deployments, here’s a minimal Bicep file:

resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageacct1234'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
  }
}

Deploy it with:

az deployment group create --resource-group rg-tutorial --template-file storage.bicep

This is the pattern you’ll use in production, where everything is versioned and reviewed.

Compare options / when to choose what

Here’s a quick comparison table to guide your decisions:

Pro tip: You can change the redundancy layer later (e.g., from LRS to GRS) in most cases, but you cannot change the performance tier after creation. So if there’s any chance you’ll need Premium, consider starting with it — or design your app to use a separate Premium account for high-throughput workloads.

Troubleshooting & edge cases

"Storage account name is already taken"

Storage account names are globally unique. If you see this error, add a random suffix like 1234 or your initials. Keep it under 24 characters, lowercase, no hyphens.

Connection string or key not working

• Double-check you’re using the correct account name (not your storage account’s DNS name).
• Verify the key hasn’t been rotated — go to Access keys in the portal to see the current keys.
• If you’re using a SAS URL, check its expiry and permissions.

Public access issues

If you try to access a blob and get 404 AuthorizationFailure, the blob is private by default. You have to either generate a SAS token or set the container’s public access level (if you truly want it public).

TLS errors

Some older SDKs or tools might still use TLS 1.0/1.1, but Azure Storage now requires TLS 1.2 by default. If you see TLS-related errors, upgrade your client library or your own app’s TLS settings.

High storage costs

Unexpected costs often come from forgetting the access tier or leaving a high redundancy level. Set up cost alerts in the Azure portal to monitor spend.

What you learned & what's next

You now know how to create an Azure Storage account with the right settings for your workload. You learned the difference between redundancy options, how to choose between Standard and Premium, how to create containers and upload blobs, and how to avoid common pitfalls. You also saw how to do it reproducibly with Bicep.

This is the foundation for the next lesson in the Azure path: connecting to Blob Storage from your application — where you’ll use the Azure SDK for Python (or your language of choice) to upload and download data programmatically, using managed identity to avoid hard-coded keys.

Now go ahead and create a storage account in your own subscription — then give yourself a small challenge: upload a file with the CLI, and then learn how to access it with SAS. That hands-on experience will make the next lesson much smoother.