How to create a Storage Account in Azure with Bicep

A Storage Account is the foundation of almost everything you do with data in Azure: storing files, blobs, tables and queues. Creating a Storage Account in Azure with Bicep lets you describe that infrastructure as code, keep it in Git and recreate it identically in any environment, with no manual clicks in the portal. This guide shows you how, step by step, with the Azure CLI.

Prerequisites

• An active Azure subscription with permission to create resources.
• The Azure CLI installed — Bicep is already included.
• A text editor; VS Code with the Bicep extension helps with suggestions and validation.
• The name of a resource group where you will create the Storage Account.

Step 1: Confirm that Bicep is available

Before writing any code, make sure the Azure CLI and Bicep are ready. Open a terminal and run these two commands:

az version
az bicep version

If the second one returns a version number, you are ready. Otherwise, install Bicep with az bicep install and try again.

Step 2: Create the Bicep file

Create a file called storage.bicep. Start with the parameters — the values you can change without touching the rest of the template, which makes the file reusable:

@description('Unique Storage Account name (3-24 characters, lowercase letters and numbers only)')
param storageAccountName string

@description('Location for the resources')
param location string = resourceGroup().location

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_ZRS'
])
param sku string = 'Standard_LRS'

The location parameter defaults to the resource group location, and sku only accepts the values in the list, preventing typos.

The Storage Account name must be unique across all of Azure and cannot contain uppercase letters or symbols. A short prefix (e.g. st) plus the project name usually works well.

Step 3: Define the Storage Account resource

Now add the resource to the same file. The word storage right after resource is just a symbolic name you use to refer to the resource inside Bicep:

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: sku
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}

output primaryBlobEndpoint string = storage.properties.primaryEndpoints.blob

We set kind to StorageV2, the most common type, and tightened security: TLS 1.2 minimum, no public blob access and HTTPS traffic only. The output at the end returns the blob service endpoint once the deployment finishes.

Step 4: Preview with what-if

Before creating anything, see what will happen. The what-if mode compares the template with what already exists in Azure and shows you the differences:

az deployment group what-if --resource-group rg-tutorial --template-file storage.bicep --parameters storageAccountName=stbconceptsdemo01

You should see a line with a + sign indicating that a new resource will be created. If you get a name-already-in-use error, pick a more unique name.

Step 5: Deploy

If the preview looks as expected, run the real deployment with the same command, just swapping what-if for create:

az deployment group create --resource-group rg-tutorial --template-file storage.bicep --parameters storageAccountName=stbconceptsdemo01

After a few seconds the command finishes and prints the defined outputs, including the primaryBlobEndpoint.

Verify the result

To confirm the Storage Account is really active, ask for its provisioning state:

az storage account show --name stbconceptsdemo01 --resource-group rg-tutorial --query "provisioningState" -o tsv

If the answer is Succeeded, the resource is created. You can also see it in the Azure portal, inside the resource group you specified.

Conclusion

With just a few lines of Bicep you created a secure, repeatable Storage Account, ready to store in Git and reuse across environments. The natural next step is to turn this template into a module and call it from other files, or add a blob container in the same deployment. Which resource would you like to describe as code next?