Azure Blob Storage: acceso público y SAS paso a paso

Actualizado el 17/07/2026 — Este artículo fue actualizado con información reciente, casos de uso latinoamericanos, secciones nuevas sobre ciclo de vida de blobs, compliance y expansión de ejemplos de integración.

Azure Blob Storage es el servicio de almacenamiento de objetos de Microsoft Azure diseñado para guardar datos no estructurados —imágenes, videos, backups, logs, datasets— a escala masiva. En julio de 2026, sigue siendo el standard en proyectos cloud que necesitan storage vía HTTP con control granular de permisos, especialmente en empresas latinoamericanas que ya usan el ecosistema Microsoft. Si buscás una alternativa a AWS S3 o Google Cloud Storage dentro del universo Azure, Blob Storage es donde empezar.

¿Qué es Azure Blob Storage exactamente?

Azure Blob Storage es un servicio administrado de Microsoft que almacena cualquier archivo no estructurado en contenedores, con redundancia configurable y acceso vía HTTPS desde cualquier dispositivo conectado a Internet. No requiere servidor; Microsoft administra la infraestructura, failover y escalabilidad automática. Funciona como un repositorio para imágenes, PDFs, videos, backups de bases de datos, archivos de auditoría y datasets de machine learning. Se integra con otros servicios Azure (Functions, Logic Apps, Data Factory, Cognitive Services) vía APIs REST y SDKs en .NET, Python, Node.js y Go. El almacenamiento se factura por GB usado, transacciones (lectura/escritura) y egress (datos salientes fuera de la región). El control de acceso usa Storage Account Keys (acceso total), Shared Access Signatures o SAS (acceso delegado temporal con permisos específicos) o integración con Azure AD (basado en identidad del usuario). SLAs van de 99.9% para LRS hasta 99.99% para Geo-Redundant, garantizando disponibilidad incluso si un datacenter cae.

¿Cuál es la diferencia entre Blob Storage y otros tipos de almacenamiento en Azure?

Dentro de Azure, hay varias categorías de almacenamiento dentro de una misma Storage Account. El Storage Account es el contenedor que agrupa Blob Storage (objetos), File Shares (carpetas de red vía SMB/NFS), Queues (colas de mensajes asincronos) y Tables (base de datos NoSQL). Para el 95% de los casos —imágenes, backups, assets web, logs— es Blob Storage.

Blob Storage organiza los datos en tres niveles jerárquicos:

• Storage Account: el namespace único globalmente, el “proyecto” donde vive todo. Tiene nombre único en todo Azure, se crea en una región específica y está asociado a un grupo de recursos (Resource Group). Una organización puede tener varias Storage Accounts, una por proyecto o por línea de negocio.
• Contenedor: equivalente a un bucket en AWS S3 o carpeta lógica. Es donde agrupás archivos relacionados. Un Storage Account puede tener hasta 500 contenedores; el nombre solo acepta minúsculas, números y guiones.
• Blob (objeto): el archivo en sí. Puede ser de 0 bytes a 4.75 TB (los bloques individuales tienen límites de 4 MB cada uno, pero se suben en paralelo). Cada blob tiene una URL única y metadatos (timestamp, ETag, propiedades personalizadas).

“Blob” viene de Binary Large Object. Azure no asume esquema: imágenes JPEG, PDFs, archivos .zip, backups de SQL Server, modelos de ML en .pkl, CSVs, JSON, todo entra sin conversión.

Crear una Storage Account paso a paso

El punto de partida es la Storage Account. Esta es el namespace único que agrupa todos tus servicios de almacenamiento y es donde se aplican políticas de acceso, redundancia y facturación.

Para crearla, vas al Portal Azure (https://portal.azure.com), buscás “Storage accounts” en la barra superior y hacés clic en “Create”. Los campos que importan de verdad:

• Subscription: seleccioná la suscripción de Azure donde se facturará el servicio. Si trabajás en una organización, pedile a tu admin que te agregue con el rol de Storage Account Contributor.
• Resource Group: un contenedor lógico para agrupar recursos relacionados (Storage Account, VMs, Databases, etc. de un proyecto). Si después querés borrar todo el proyecto de una vez, borrás el grupo. Si no existe, creá uno con un nombre descriptivo como rg-donweb-backup-2026.
• Storage Account Name: debe ser único a nivel global entre todos los clientes de Azure. Solo minúsculas y números, entre 3 y 24 caracteres. No espacios, no guiones, no mayúsculas. Ejemplo: donwebarchivos2026. Probá antes de confirmar; si alguien ya usó ese nombre, no te dejará.
• Region: elegí la más cercana a tus usuarios finales. Para Argentina, Uruguay, Paraguay: Brazil South (São Paulo). Para México: Canadá Central. Para Chile: Chile Central (si existe) o US East. Cuanto más cerca, menor latencia en descargas y uploads, menor egress intrarregional.
• Performance: Standard para prácticamente todos los casos (Blob Storage típico). Premium solo para discos de VMs o aplicaciones que necesitan latencia ultrabaja (no es el caso para archivos).
• Account kind: elegí “StorageV2 (general purpose v2)” si es la primera vez; soporta todas las características y precios competitivos. No uses “Storage (general purpose v1)” porque está deprecado.
• Redundancy: LRS (Locally Redundant Storage) replica los datos 3 veces dentro del mismo datacenter. GRS (Geo-Redundant) los replica automáticamente en una región secundaria. ZRS (Zone-Redundant) spread entre 3 zonas de disponibilidad de la misma región. LRS es lo más barato (~$0.024/GB en US); GRS es aproximadamente 2x. Para backups críticos, ZRS es un buen equilibrio.
• Access tier: Hot (acceso frecuente) o Cool (acceso poco frecuente, datos históricos). Lo cambias después, así que dejá Hot por ahora.
• Allow Blob Public Access: dejalo habilitado si querés poder tener contenedores con acceso anónimo después. Si lo deshabilitás aquí, nunca habrá blobs públicos en esta cuenta, sin importar cómo configures cada contenedor.

Al crear, vas a “Review + create”, revisas que todo esté bien, y hacés clic en “Create”. El deployment tarda 30 segundos a 2 minutos. Verás un botón “Go to resource” cuando termine.

Tipos de blobs y cuándo usar cada uno

Hay tres tipos de blobs según la arquitectura interna de Azure. Para el 90% de los casos vas a usar uno solo:

• Block blobs: el tipo estándar. Se suben en bloques paralelos de hasta 4 MB cada uno (total hasta 50,000 bloques = 4.75 TB). Súper eficientes para imágenes, videos, PDFs, backups, cualquier cosa que se carga y se deja ahí. Cuando subís un archivo desde el Portal o un SDK sin especificar tipo, automáticamente es Block blob.
• Append blobs: optimizados para operaciones de append (agregar datos al final sin reescribir). Caso de uso: logs continuos que se escriben 24/7, un proceso escribiendo mientras otro lee. En Argentina, organismos reguladores y bancos los usan para audit logs porque garantizan escritura inmutable al final.
• Page blobs: para lectura/escritura aleatoria a nivel de página (512 bytes). Internamente los discos de VMs de Azure los usan. Rara vez los vas a usar manualmente.

Crear un contenedor y subir archivos

Dentro de una Storage Account, los blobs se organizan en contenedores para separar lógicamente diferentes tipos de datos. Para crear uno, entrás a la Storage Account desde el Portal, hacés clic en “Containers” en el menú lateral izquierdo y después en “+ Container”.

Ponele un nombre descriptivo: documentos-clientes, backups-sql, assets-web, logs-aplicacion. Solo minúsculas, números y guiones. El nombre no tiene que ser único globalmente, solo dentro de tu Storage Account.

Lo más importante es el nivel de acceso público. Esto determina quién puede acceder a los blobs sin autenticación:

Después de crear el contenedor, tenés varias opciones para subir archivos:

• Portal Azure (botón Upload): rápido para uno o dos archivos, no técnico, sin línea de comandos necesaria.
• Azure Storage Explorer: cliente de escritorio (Windows, Mac, Linux) con interfaz gráfica. Podés arrastrar archivos, ver previsualizaciones, subir carpetas enteras con metadatos.
• AzCopy: herramienta de línea de comandos, ideal para migraciones masivas. Soporta paralelización automática, reintentos, sincronización bidireccional, throttling.
• Azure CLI: az storage blob upload --file archivo.zip --container-name mi-contenedor --account-name mystg. Scriptable, automatizable.
• SDK (Python, .NET, Node.js, Go): para integración desde tu código. Control total, monitoreo de progreso, manejo de errores de red.

Acceso público permanente vs tokens SAS: cuál usar y cuándo

Hay dos formas de compartir un archivo sin credenciales. Elegir bien entre ellas es crítico para seguridad.

Acceso público permanente: si configuraste el nivel “Blob” en el contenedor, cualquier persona con la URL del archivo puede accederlo sin autenticación. La URL tiene este formato:

https://mistarage.blob.core.windows.net/documentos-clientes/informe-2026.pdf

Usalo para: assets de un sitio web (imágenes, CSS, JS), archivos de descarga pública (whitepapers, PDFs de términos), datasets abiertos para research, contenido que querés que indexen buscadores y que esté disponible indefinidamente.

NO lo uses para: datos de usuarios, configuraciones de la aplicación, backups, cualquier cosa temporal, cualquier cosa que no querés que buscadores indexen, información que vaya a expirar algún día.

Problema del acceso público: es permanente mientras esté activo. No expira, no se puede revocar por archivo individual (solo por contenedor completo). Si después querés que un archivo deje de estar accesible, tenés que cambiar el nivel de acceso del contenedor a “Private” (afecta TODOS los blobs del contenedor) o elevar a Private el archivo individual.

Tokens SAS (Shared Access Signature): una URL firmada que da acceso delegado a recursos específicos con permisos y expiración configurables. Para archivos que querés compartir por tiempo limitado — un informe confidencial a un cliente, datos de una investigación temporal, descargas únicas — SAS es lo correcto.

Generar y configurar SAS (Shared Access Signature)

Un Shared Access Signature es una URL firmada criptográficamente que autoriza acceso delegado a un recurso específico de storage. Azure soporta tres tipos; dos importan:

• User Delegation SAS: firmado con credenciales de Azure AD (el usuario logueado). El más seguro, recomendado para producción. No se ve afectado si rotás las claves de la Storage Account. Limitado a 7 días máximo de duración.
• Service SAS: firmado con la clave de la Storage Account, acceso a un solo servicio (solo Blob, o solo Queue, etc.). Si rotás la clave, todos los Service SAS basados en ella expiran inmediatamente. Válido por cualquier duración.
• Account SAS: firmado con la clave de la Storage Account, acceso a múltiples servicios. Tiene los mismos riesgos que Service SAS al rotar claves.

Para generar un SAS desde el Portal: seleccionás el blob que querés compartir, hacés clic derecho (o el menú “…”), elegís “Generate SAS” y configurás:

• Signing method: Account key (la clave de la Storage Account) o User delegation key (basado en Azure AD). Para producción o datos semifrivados, User delegation es más seguro.
• Permissions: Read, Write, Delete, List, Add, Create. Marcá SOLO los que realmente necesitás. Ejemplo: cliente que descarga un informe solo necesita Read. Empleado que carga backups necesita Write.
• Start and expiry date/time: pon hora de inicio unos 5 minutos ANTES de la actual para evitar problemas de desfase de reloj entre servidores. Expiración: ajustala a lo que realmente necesitás. Una hora para una descarga puntual, máximo 24 horas para un cliente que descargará varias veces en el día, 7 días como máximo para User Delegation.
• Allowed protocols: HTTPS only. NUNCA HTTP solo. Un SAS sobre HTTP expone la firma en texto plano en los logs de tu router/proxy.
• Allowed IP addresses (opcional pero recomendado): si sabés de qué IP se va a acceder (office del cliente, rango de proveedores), limitá el acceso a eso. Formato: 192.168.1.1-192.168.1.5 o 192.168.1.0/24 para subredes.

La URL resultante se ve así:

https://mistarage.blob.core.windows.net/documentos-clientes/informe.pdf?sv=2023-11-03&st=2026-07-17T14:00:00Z&se=2026-07-17T18:00:00Z&sr=b&sp=r&sig=AbCdEf1234567890XyZ

Los parámetros más importantes:

• sv: versión de la API de storage (2023-11-03 es reciente en julio 2026). No edites esto manualmente; Azure lo genera.
• st: fecha/hora de inicio en UTC. Si accedés antes, falla con 403. Notar el formato: 2026-07-17T14:00:00Z.
• se: fecha/hora de expiración en UTC. Pasada esta hora, falla con 403 sin mensajes amigables.
• sr: tipo de recurso (b = blob individual, c = contenedor).
• sp: permisos (r = read, w = write, d = delete, l = list, a = add, c = create).
• sig: firma criptográfica HMAC-SHA256 basada en la clave y los otros parámetros. Si alguien modifica cualquier parámetro, la firma no coincide y el acceso se rechaza.

La belleza del SAS es que vos generás la URL, se la mandás al cliente o la publicás en un email, y después podés revocar acceso sin tocar el archivo. Simplemente esperás a que expire.

Casos de uso reales en empresas latinoamericanas

Estos son ejemplos concretos de cómo usan Blob Storage empresas en Argentina, Uruguay, Paraguay y Chile (datos de migraciones 2025-2026):

• Respaldos automatizados de bases de datos SQL: una empresa fintech en Buenos Aires hace backup diario de su SQL Server a Blob Storage con GZIP compression. Retiene 30 días con LRS. Costo mensual: ~$15 USD. Si necesita restaurar, el archivo está listo en la nube sin depender de un servidor on-premise que se puede romper.
• Archivos de auditoría para cumplimiento normativo: organismos reguladores en Argentina exigen mantener registros de auditoría por 7 años (BCRA, AFIP, UIF). Esto suma terabytes. Guardarlos en Blob Storage con Append blobs y archive tier evita que dejes un servidor viejo corriendo 24/7.
• Distribución de contenido a usuarios finales: plataforma de e-learning en Santiago usa Blob Storage para alojar videos de cursos. Cada usuario descarga desde una URL con SAS de 24 horas. Permite acceso temporal sin crear cuentas complicadas, y el video se puede ver aunque caiga el servidor de la app (la URL sigue válida).
• Catálogo de imágenes de productos para ecommerce: tienda online en Córdoba sube fotos de productos, el sitio web las muestra desde URLs de Blob Storage público. Cuando descuentan un producto, privatizan el contenedor y el inventario desaparece de la web automáticamente (sin borrar el blob).
• Exportaciones de datos para clientes: software de facturación guarda reportes en Blob Storage, genera un SAS de 72 horas, lo envía por email. El cliente descarga, el SAS expira automáticamente. Si alguien roba el email, el link no sirve después de 3 días.

Integración desde código: ejemplos funcionales

Si estás desarrollando una app, vas a querer conectarte a Blob Storage desde código. Acá hay ejemplos en los lenguajes más usados:

Python (con SDK azure-storage-blob)

from azure.storage.blob import BlobServiceClient, generate_blob_sas, BlobSasPermissions
from datetime import datetime, timedelta

connection_string = "DefaultEndpointsProtocol=https;AccountName=mistarage;AccountKey=...;EndpointSuffix=core.windows.net"
blob_service_client = BlobServiceClient.from_connection_string(connection_string)
container_client = blob_service_client.get_container_client("documentos")

with open("informe.pdf", "rb") as data:
container_client.upload_blob(name="informe.pdf", data=data, overwrite=True)

sas_token = generate_blob_sas(
account_name="mistarage",
container_name="documentos",
blob_name="informe.pdf",
account_key="...",
permission=BlobSasPermissions(read=True),
expiry=datetime.utcnow() + timedelta(hours=4)
)

url = f"https://mistarage.blob.core.windows.net/documentos/informe.pdf?{sas_token}"
print(url)

Node.js (con SDK @azure/storage-blob)

const { BlobServiceClient, generateBlobSASQueryParameters, BlobSASPermissions } = require("@azure/storage-blob");

const connectionString = "DefaultEndpointsProtocol=...";
const blobServiceClient = BlobServiceClient.fromConnectionString(connectionString);
const containerClient = blobServiceClient.getContainerClient("documentos");

const blockBlobClient = containerClient.getBlockBlobClient("informe.pdf");
await blockBlobClient.uploadFile("./informe.pdf");

const sasUrl = blockBlobClient.generateSasUrl({
permissions: BlobSASPermissions.parse("r"),
expiresOn: new Date(Date.now() + 4 * 60 * 60 * 1000)
});
console.log(sasUrl);

La idea en ambos casos es idéntica: conectarte con credenciales, subir el archivo, generar el SAS con expiración, y devolver la URL firmada al cliente. El SDK maneja la firma automáticamente; vos solo especificás permisos y duración.

CORS: cómo acceder a Blob Storage desde una aplicación web

Si tu front-end (una SPA en React, Vue, Svelte) necesita acceder directamente a Blob Storage para subir fotos, PDFs o archivos sin pasar por tu backend, tenés que habilitar CORS (Cross-Origin Resource Sharing).

Sin CORS, el navegador va a bloquear la solicitud con un error Access-Control-Allow-Origin que confunde a todo el mundo.

Para habilitar CORS en tu Storage Account, vas al Portal, entrás a la Storage Account, buscás “CORS” (debajo de “Settings” o “Resource Sharing (CORS)”), hacés clic en “Blob service” y agregás una regla:

• Allowed origins: https://tu-dominio.com para producción, o * para desarrollo (NUNCA * en producción). Si tenés múltiples dominios, agregá varias reglas, una por dominio.
• Allowed methods: GET, PUT, OPTIONS, DELETE, POST (dependiendo de qué haga tu app).
• Allowed headers: * o específicamente Content-Type, x-ms-blob-type (el header x-ms-blob-type es obligatorio para block blobs desde navegador).
• Exposed headers: * o ETag, x-ms-request-id (para que JavaScript pueda leerlos).
• Max age: 3600 (segundos que el navegador cachea la política, OK para la mayoría).

Después, desde tu app JavaScript:

const uploadFile = async (file) => {
const sasUrl = "https://mistarage.blob.core.windows.net/uploads/foto.jpg?sv=...&sp=w";
const response = await fetch(sasUrl, {
method: "PUT",
headers: {
"x-ms-blob-type": "BlockBlob",
"Content-Type": file.type
},
body: file
});
if (response.ok) console.log("Archivo subido correctamente");
else console.error("Error:", response.status);
};

Fijate que: (1) usás un SAS con permiso de escritura (sp=w), (2) el header x-ms-blob-type: BlockBlob es obligatorio, (3) el Content-Type debe coincidir con el tipo de archivo.

Ciclo de vida y retención de blobs

En la práctica, no todos los blobs son iguales desde el punto de vista de acceso. Los datos nuevos se acceden frecuentemente; los viejos casi nunca. Azure permite automatizar esto con políticas de ciclo de vida que mueven blobs entre tiers según edad.

Tiers de almacenamiento:

• Hot: para acceso frecuente. Costo de almacenamiento más alto (~$0.024/GB), operaciones más baratas.
• Cool: para acceso ocasional (menos de 30 días). Costo de almacenamiento más bajo (~$0.013/GB), pero hay cargo por acceso. Ideal para backups, logs históricos.
• Archive: para acceso rarísimo (rara vez antes de 90 días). Costo bajísimo (~$0.004/GB), pero requiere “rehidratación” (esperar horas) antes de poder acceder. Ideal para cumplimiento normativo (guarda por 7 años sin costo).

Para automatizar transiciones, vas a Storage Account → “Lifecycle Management” y creás reglas. Ejemplo:

• Blobs con edad > 30 días: mover a Cool.
• Blobs con edad > 90 días: mover a Archive.
• Blobs con edad > 2555 días (7 años): deletear automáticamente.

Esto te ahorra dinero sin perder datos. Una empresa típica ahorra 60-70% de costos de almacenamiento moviendo datos viejos a Archive.

Monitoreo, logs y diagnóstico

Cuando algo falla — un error 403, una transacción lenta, un acceso sospechoso — necesitás ver qué pasó. Azure Storage tiene logs de diagnóstico detallados.

Para habilitarlos, vas a Storage Account → “Monitoring” → “Diagnostic settings”, hacés clic en “Add diagnostic setting” y configurás:

• Marcá “StorageRead”, “StorageWrite”, “StorageDelete” (o todos si querés máxima visibilidad).
• Eligí dónde guardar los logs: Log Analytics Workspace (recomendado para análisis, queries KQL), Storage Account (logs en archivos), Event Hub (para procesamiento real-time).

Una vez habilitados, podés ver logs detallados de cada operación: quién accedió, desde qué IP, a qué blob, si fue exitoso o falló, latencia, bytes transferidos.

Ejemplo de query en Log Analytics para encontrar todos los errores 403 de las últimas 24 horas:

StorageBlobLogs
| where TimeGenerated > ago(24h)
| where StatusCode == 403
| project TimeGenerated, CallerIpAddress, ResourceId, OperationName, StatusCode, StatusText
| sort by TimeGenerated desc

Precios y cálculo de costos

Los costos de Blob Storage dependen de tres factores: capacidad de almacenamiento, transacciones (operaciones) y egress (datos salientes).

Con GRS (Geo-Redundant), todos estos precios se multiplican por ~2. Con Cool tier, el almacenamiento baja a ~$0.013/GB pero hay cargo por acceso.

Un caso típico: empresa guarda 500 GB de backups diarios, retiene 30 días, 50 usuarios descargan reportes daily. Cálculo: (500 GB × $0.024) + (30 días × 50 descargas × 10 MB × $0.12/GB egress). Estimado: ~$85-120 USD/mes con LRS en Brazil South.

Tip de ahorro: si tenés datos que se acceden casi nunca (archivos históricos, logs de años atrás), movelos a Cool o Archive automáticamente con Lifecycle Management. Ahorras 40-80% sin perder acceso a los datos.

Seguridad: lo que tenés que saber antes de salir a producción

Ponele que generaste un SAS de 24 horas y lo mandás a un cliente para que descargue un informe. El cliente lo guarda en un Slack interno, alguien lo ve, copia la URL, y de repente tenés 50 personas descargando ese archivo usando el mismo link. Sí, pasa todo el tiempo.

Para evitar sorpresas desagradables:

• HTTPS siempre, sin excepciones: configurá el parámetro de protocolo a “HTTPS only”. Un SAS sobre HTTP expone la firma en texto plano en logs de routers, proxies, y capturas de red. Cualquiera que lea el log ve el SAS.
• Duración mínima necesaria: una descarga puntual = 1 hora. Un proceso batch que corre durante el día = hasta 24 horas máximo. User Delegation SAS está limitado a 7 días. Después de 7 días, es viejo; no lo reutilices.
• User Delegation SAS sobre Account/Service SAS: la clave de cuenta tiene acceso total a toda la Storage Account. Si alguien la roba, la rotás y todos los SAS basados en esa clave caducan al instante (no es lo que querés). Con User Delegation (basado en Azure AD), podés revocar acceso granularmente. Es más tedioso de configurar pero mucho más seguro en empresas grandes.
• Restringí por IP cuando puedas: si sabés de qué rango de IPs se va a acceder (oficina del cliente, datacenter de un proveedor), limitá el SAS a eso con el parámetro sip. Alguien que robe el SAS pero accede desde otra IP obtiene 403.
• No hardcodees SAS en código fuente: usá Azure Key Vault o variables de entorno. Un .env público en GitHub es un desastre de seguridad. GitHub scans estos repos automáticamente; si lo ven, van a notificar a Microsoft y tu cuenta puede quedar comprometida.
• Rotá las claves de la Storage Account cada 90 días: Microsoft lo recomienda. Procedure: generás una clave nueva, cambias todo lo que usa la vieja a la nueva, después deshabilitás la vieja. Esto limita la ventana de exposición si alguien la roba.
• Habilitá logging y monitoreá accesos anómalos: si ves 10,000 requests desde una IP desconocida a un blob que casi nunca se toca, eso es un rojo. Deshabilita el SAS, investigá, rotá claves si es necesario.
• Usá Managed Identity en lugar de connection strings: si tu app corre en una VM o App Service de Azure, asignale una Managed Identity y dale permiso al Storage Account sin credentials. No hay keys para robar.

Errores comunes y cómo diagnosticarlos

El error más frecuente es 403 Forbidden. Tiene varios orígenes; acá van los más comunes y cómo identificarlos:

• SAS expirado: el parámetro se en la URL es una fecha/hora UTC. Revisá la hora actual del servidor: en Linux/Mac date -u, en PowerShell Get-Date -AsUTC. Si la actual es posterior a se, está expirado. Generá uno nuevo.
• Protocolo incorrecto: si generaste el SAS con “HTTPS only” (recomendado) y alguien accede vía HTTP, falla con 403 genérico (no un error más descriptivo). Revisá la URL: debe ser https://, nunca http://.
• Tipo de recurso mal configurado: el parámetro sr define el tipo. sr=b = blob específico, sr=c = contenedor. Si generaste un SAS con sr=c e intentás acceder a un blob específico, falla.
• Desfase de tiempo entre servidores: si pusiste el inicio del SAS para “ahora” pero hay una diferencia de reloj entre tu máquina y Azure, el SAS puede aún no ser válido (parámetro st es futuro). Solución: pon el inicio 10 minutos en el pasado al generar.
• Acceso público deshabilitado a nivel de cuenta: el switch de “Allow Blob Public Access” está en Off a nivel de Storage Account. Así, ningún contenedor puede tener acceso público, aunque lo hayas configurado. Habilitalo si necesitás acceso anónimo.
• Permisos insuficientes en el SAS: el parámetro sp listá los permisos. sp=r = lectura. Si intentás escribir con un SAS de lectura, falla con 403. Regenerá con los permisos correctos (sp=w, sp=d, etc.).

La forma más rápida de diagnosticar en producción: habilitá logs de diagnóstico (si no están), y revisá las entradas con status 403 en las últimas 2 horas. Los logs van a incluir el motivo exacto (SAS signature invalid, Date/time issue, etc.).

Errores frecuentes que comete casi todo el mundo

• Nombre de Storage Account con mayúsculas o caracteres especiales: Azure rechaza cualquier cosa que no sea minúsculas y números. Si venís de AWS S3, donde aceptan guiones, el cambio tarda. No es mi-storage, es mistorage.
• Generar SAS a nivel de contenedor cuando necesitás acceso a un blob específico: sr=c (contenedor) vs sr=b (blob individual) son SAS distintos. Si usás el del contenedor para acceder a un blob sin la ruta correcta, no funciona. Siempre especificá sr=b para blobs específicos.
• Usar acceso público en lugar de SAS para “simplificar”: el acceso público no expira, no se puede revocar por blob individual (solo por contenedor), y si habilitás “Container” level, exponés el listado completo de archivos. Para datos temporales, SAS siempre.
• Olvidar que rotar claves invalida Service SAS: si rotás la clave 1 (recomendado cada 90 días), todos los Service SAS y Account SAS basados en esa clave expiran. User Delegation SAS no se ve afectado.
• Hardcodear la Storage Account Key en el código: si pusiste la clave en un archivo .env y ese archivo está en GitHub, alguien puede tener acceso total. Usá Key Vault, variables de entorno secretas, o Managed Identity.
• No habilitar CORS cuando la app lo necesita: si una SPA intenta escribir directamente a Blob Storage, sin CORS el navegador bloquea con un error confuso. Habilitá CORS para tu dominio.
• Confundir “Azure Storage” con “Blob Storage”: Azure Storage es el umbrella term que incluye Blob, File Shares, Queues, Tables. Blob Storage es solo la parte de objetos. Especificá “Blob Storage” cuando busques documentación de objetos binarios.

Comparación rápida: Blob Storage vs AWS S3 vs Google Cloud Storage

Si estás evaluando proveedores cloud para storage de objetos, acá hay un comparativo rápido de funcionalidad:

En resumen: Blob Storage es lo indicado si usás Azure AD, .NET o workloads Microsoft. S3 es el estándar de facto con mayor portabilidad. Google Cloud Storage es competitivo si ya usás Google Cloud (BigQuery, Dataflow, etc.).

La mayoría de empresas elige en función de qué otros servicios cloud ya usan. Si estás en Azure por compute (VMs, App Service), Blob Storage es lo natural. Si estás en AWS, S3. No hay razón técnica absoluta que determine uno sobre otro para casos típicos.

Preguntas frecuentes finales

• ¿Puedo tener múltiples Storage Accounts? Sí. Una por proyecto, por línea de negocio, o por requisito de segregación es común. Cada una tiene sus propios costos, logs, políticas de acceso.
• ¿Cuál es la latencia típica desde Latinoamérica? Con Brazil South: 50-100ms desde Argentina/Brasil. Con US East: 150-200ms desde LATAM. TTFB típica después del primer request es 10-50ms una vez que la conexión está warm.
• ¿El acceso público indexa Google/buscadores? Sí, si el blob es accesible vía HTTP público, Google va a encontrarlo y indexarlo. Si no querés eso, usá SAS o Private. Azure robots.txt no funciona en Blob Storage (no es un sitio web).
• ¿Qué pasa si excedo mis cuotas? Azure tiene límites blandos (contactás support para aumentar) y duros (no podés violar). Ej: 5 petabytes de data por Storage Account es el máximo. En la práctica, nunca lo vas a tocar.
• ¿Puedo usar Blob Storage con CDN? Sí, Azure CDN (pagado aparte) puede servir blobs como origen. Cloudflare también funciona. Esto reduce latencia para usuarios lejanos.
• ¿Cuántos blobs puedo tener en un contenedor? Teóricamente ilimitado. En la práctica, después de millones, la navegación en el Portal se ralentiza. Usa una estructura de carpetas virtuales (prefijos de ruta) para organizar.
• ¿El SAS se puede revocar antes de expirar? Solo si cambias la política de firma (rotás claves en Account/Service SAS). Para User Delegation, tienes que esperar a que expire. Planificá duraciones cortas.