Cómo crear un Storage Account en Azure con Bicep
Un Storage Account es la base de casi todo lo que haces con datos en Azure: guardar archivos, blobs, tablas y colas. Crear un Storage Account en Azure con Bicep te permite describir esa infraestructura como código, guardarla en Git y recrearla igual en cualquier entorno, sin clics manuales en el portal. Esta guía te muestra cómo hacerlo, paso a paso, con la Azure CLI.
Requisitos previos
- Una suscripción de Azure activa y permisos para crear recursos.
- La Azure CLI instalada — Bicep ya viene incluido.
- Un editor de texto; VS Code con la extensión Bicep ayuda con sugerencias y validación.
- El nombre de un resource group donde crearás el Storage Account.
Paso 1: Confirmar que Bicep está disponible
Antes de escribir código, comprueba que la Azure CLI y Bicep están listos. Abre una terminal y ejecuta estos dos comandos:
az version
az bicep version
Si el segundo devuelve un número de versión, está todo listo. Si no, instala Bicep con az bicep install e inténtalo de nuevo.
Paso 2: Crear el archivo Bicep
Crea un archivo llamado storage.bicep. Empieza por los parámetros — los valores que puedes cambiar sin tocar el resto de la plantilla, lo que hace el archivo reutilizable:
@description('Nombre único del Storage Account (3-24 caracteres, solo minúsculas y números)')
param storageAccountName string
@description('Ubicación de los recursos')
param location string = resourceGroup().location
@allowed([
'Standard_LRS'
'Standard_GRS'
'Standard_ZRS'
])
param sku string = 'Standard_LRS'
El parámetro location usa por defecto la ubicación del resource group, y sku solo acepta los valores de la lista, evitando errores de escritura.
El nombre del Storage Account debe ser único en toda Azure y no puede contener mayúsculas ni símbolos. Un prefijo corto (p. ej. st) más el nombre del proyecto suele funcionar bien.
Paso 3: Definir el recurso Storage Account
Ahora añade el recurso al mismo archivo. La palabra storage justo después de resource es solo un nombre simbólico para referirte al recurso dentro de 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
Elegimos kind igual a StorageV2, el tipo más común, y reforzamos la seguridad: TLS 1.2 como mínimo, sin acceso público a blobs y solo tráfico HTTPS. El output al final devuelve la dirección del servicio de blobs en cuanto termine el despliegue.
Paso 4: Previsualizar con what-if
Antes de crear nada, mira lo que va a pasar. El modo what-if compara la plantilla con lo que ya existe en Azure y te muestra las diferencias:
az deployment group what-if --resource-group rg-tutorial --template-file storage.bicep --parameters storageAccountName=stbconceptsdemo01
Deberías ver una línea con el signo + que indica que se creará un recurso nuevo. Si aparece un error de nombre ya en uso, elige un nombre más único.
Paso 5: Hacer el despliegue
Si la previsualización es la esperada, ejecuta el despliegue real con el mismo comando, cambiando solo what-if por create:
az deployment group create --resource-group rg-tutorial --template-file storage.bicep --parameters storageAccountName=stbconceptsdemo01
Tras unos segundos el comando termina y muestra los outputs definidos, incluido el primaryBlobEndpoint.
Verificar el resultado
Para confirmar que el Storage Account está realmente activo, consulta su estado de aprovisionamiento:
az storage account show --name stbconceptsdemo01 --resource-group rg-tutorial --query "provisioningState" -o tsv
Si la respuesta es Succeeded, el recurso está creado. También puedes verlo en el portal de Azure, dentro del resource group que indicaste.
Conclusión
Con solo unas pocas líneas de Bicep has creado un Storage Account seguro y repetible, listo para guardar en Git y reutilizar en otros entornos. El siguiente paso natural es convertir esta plantilla en un módulo y llamarlo desde otros archivos, o añadir un contenedor de blobs en el mismo despliegue. ¿Qué otro recurso te gustaría describir como código a continuación?