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

Actualizado el 26/07/2026 — Este artículo fue actualizado con información reciente, casos de uso latinoamericanos, secciones nuevas sobre ciclo de vida de blobs, compliance, CORS desde front-end, precios actualizados 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.

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. 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:

Nivel de acceso	Qué permite	Cuándo usarlo	Cuándo NO
Private (sin acceso público)	Solo acceso autenticado: Storage Account Key o SAS	Datos sensibles, backups, documentos internos, bases de datos, archivos de clientes	Casi nunca expongas datos importantes sin verificar identidad
Blob	Lectura anónima de blobs individuales si conocés la URL exacta. No listado de contenedor.	Assets públicos: imágenes de un sitio web, PDFs descargables públicos, archivos que querés compartir por link	Datos semifrivados o cuando la URL en sí tiene que ser confidencial
Container	Lectura anónima de blobs Y listado de todos los archivos del contenedor	Casos muy específicos: demo pública, archivo masivo de investigación abierta	99% del tiempo; expone el inventario completo, cualquiera puede ver qué hay

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:

Si querés profundizar en el tema, tenemos una guía completa sobre Azure Blob Storage setup.

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).

Componente	Precio (USD, Standard LRS, primeros 50 TB)	Ejemplo real
Almacenamiento	~$0.024 / GB / mes	1 TB = ~$24.58/mes
Operaciones de escritura	~$0.0055 / 10,000 ops	1M writes = ~$0.55
Operaciones de lectura	~$0.0004 / 10,000 ops	1M reads = ~$0.04
Egress (datos saliendo de la región)	~$0.12 / GB	100 GB egress = ~$12

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 necesitás usar Service SAS o rotar el SAS con User Delegation de nuevo.
• Revocación de SAS de emergencia: si un link SAS se filtró, podés regenerar la clave de la Storage Account (si usaste Service SAS) o rotar la User Delegation key (si usaste ese método). Esto invalida todos los SAS de ese tipo al instante.
• No exponer contenedores completos: nunca pongas un contenedor en nivel “Container” a menos que sea estrictamente necesario. Con nivel “Blob”, los archivos son accesibles solo si se conoce la URL exacta. Con nivel “Container”, cualquiera puede listar todos los archivos del contenedor.
• Restringir por IP: en el SAS, si sabés que el cliente accede desde una oficina con IP fija, poné esa IP en el campo “Allowed IP addresses”. Así, aunque el link se filtre, solo funciona desde esa IP.
• Usar Azure AD para producción: cuando sea posible, usá identidades administradas o Azure AD para autenticar aplicaciones (Managed Identity). Así evitás claves de cuenta y SAS por completo.

¿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.

Preguntas frecuentes sobre Azure Blob Storage

¿Cuál es la URL oficial de Azure Blob Storage?

La URL oficial para acceder al portal de Azure Blob Storage es https://portal.azure.com. Una vez logueado, buscás “Storage accounts” en la barra de búsqueda para acceder a tus cuentas de almacenamiento. No hay un sitio web separado para Blob Storage; es parte del ecosistema de Azure.

¿Cómo integrar Azure Blob Storage con una aplicación web?

Hay dos formas principales: (1) desde tu backend, usando los SDKs oficiales (Python, Node.js, .NET, etc.) para subir, descargar y generar SAS; (2) desde el front-end directamente, usando un token SAS con permisos limitados y CORS habilitado en la Storage Account. La segunda opción evita que el archivo pase por tu servidor, lo que reduce carga y latencia.

¿Cuánto cuesta Azure Blob Storage por mes?

Depende del volumen y el tier. Con LRS (Locally Redundant Storage), el almacenamiento cuesta ~$0.024/GB/mes. Por 100 GB, eso es ~$2.40/mes. Pero sumale las transacciones (lectura/escritura) y el egress (datos salientes). Un caso típico de 500 GB con 50 descargas diarias ronda los $85-120 USD/mes en Brazil South. Con Cool tier, los costos bajan un 40-50%.