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

Actualizado el 09/07/2026 — Este artículo fue actualizado con información reciente, casos de uso latinoamericanos y secciones nuevas sobre integración de aplicaciones, monitoreo y costos.

Azure Blob Storage es el servicio de almacenamiento de objetos de Microsoft Azure, diseñado para guardar datos no estructurados como imágenes, videos, backups y archivos de log a escala masiva. En julio de 2026, sigue siendo la opción de referencia para proyectos cloud que necesitan storage accesible vía HTTP con control granular de permisos, especialmente en empresas latinoamericanas que ya usan el ecosistema de Microsoft.

Azure Blob Storage es un servicio administrado de Microsoft Azure que almacena cualquier archivo no estructurado en contenedores con redundancia configurable y acceso vía URLs HTTPS. Funciona como un repositorio escalable para imágenes, videos, PDFs, backups de bases de datos y datasets de machine learning. Se integra con otros servicios de Azure (Functions, Logic Apps, Cognitive Services) mediante APIs REST y SDKs en .NET, Python, Node.js y Go. El almacenamiento se factura por GB usado, transacciones y transferencia de datos salientes. No requiere servidor; la infraestructura es administrada por Microsoft con SLAs de 99.9% a 99.99% según la redundancia elegida. El control de acceso usa Storage Account Keys, Shared Access Signatures (SAS) con expiración configurable, o integración con Azure Active Directory (Azure AD) para User Delegation SAS.

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

Dentro de la plataforma Azure, hay varias categorías de almacenamiento. El Storage Account es el contenedor que agrupa Blob Storage (objetos), File Shares (SMB/NFS como carpetas de red), Queues (colas de mensajes) y Tables (bases de datos NoSQL). Para el 95% de los casos — archivos, backups, assets de sitios web — es Blob Storage.

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

• Storage Account: el namespace único, el “proyecto” donde vive todo. Tiene nombre único globalmente, se crea en una región específica y está asociado a un grupo de recursos (Resource Group).
• Contenedor: equivalente a un bucket en AWS S3. 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 más bajos, pero se suben en paralelo). Cada blob tiene una URL única.

“Blob” viene de Binary Large Object. No asume esquema: imágenes JPEG, PDFs, archivos .zip, backups de SQL Server, modelos de ML en formato .pkl — todo entra.

Crear una Cuenta Azure Storage paso a paso

El punto de partida es la Storage Account. Según la documentación oficial de Microsoft, esta cuenta es el namespace único que agrupa todos tus servicios de almacenamiento.

Para crearla, vas al Portal Azure, buscás “Storage accounts” y hacés clic en “Create”. Los campos que importan de verdad:

• Subscription: seleccioná la suscripción de Azure donde se facturará el servicio.
• Resource Group: un contenedor lógico para agrupar recursos relacionados. Si después querés borrar todo el proyecto, borrás el grupo y listo. Si no existe, creá uno con un nombre descriptivo (por ejemplo, rg-donweb-backup).
• Storage Account Name: tiene que 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.
• Region: elegí la más cercana a tus usuarios finales. Para Argentina y Uruguay, usá Brazil South (São Paulo). Para México y Centroamérica, usa Canadá Central o US East. Cuanto más cerca, menor latencia en descargas.
• Performance: Standard para la mayoría de casos (blob storage típico). Premium solo si necesitás latencia muy baja, tipo discos de VMs.
• Redundancy: LRS (Locally Redundant Storage) replica los datos 3 veces dentro del mismo datacenter. GRS (Geo-Redundant) los replica en una región secundaria automáticamente. 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 más caro (~$0.048/GB) pero protege ante desastres regionales.

Al crear la cuenta, vas a ver una opción llamada “Allow Blob Public Access”. Dejalo habilitado si querés después tener la opción de habilitar acceso anónimo a contenedores específicos. Si lo deshabilitás aquí, nunca va a poder haber blobs públicos en esta cuenta, sin importar cómo configures el contenedor.

Después de llenar los campos, vas a “Review + create”, revisas que todo esté bien, y hacés clic en “Create”. El deployment tarda 30 segundos a 2 minutos.

Tipos de blobs y cuándo usar cada uno

Hay tres tipos de blobs según la documentación oficial. Para el 90% de los casos, vas a usar uno solo:

• Block blobs: el tipo estándar. Se suben en bloques paralelos (hasta 50 MB por bloque), lo que los hace súper eficientes para archivos grandes. Ideales para imágenes, videos, PDFs, backups. Es lo que usa cualquier herramienta de upload por defecto.
• Append blobs: optimizados para operaciones de append (agregar datos al final) sin reescribir todo. Caso de uso: logs continuos que se escriben 24/7. Un proceso puede estar escribiendo mientras otro está leyendo. En Argentina, algunos clientes usan esto para audit logs de aplicaciones financieras.
• Page blobs: para lectura/escritura aleatoria a nivel de página (512 bytes). Los discos de VMs de Azure los usan internamente. No los vas a usar a mano casi nunca.

Cuando subes un archivo desde el Portal o desde un SDK, automáticamente sale como Block blob. Es la opción correcta el 95% del tiempo.

Crear un contenedor y subir archivos

Dentro de la Storage Account, los blobs se organizan en contenedores. Para crear uno, entrás a la Storage Account desde el Portal, hacés clic en “Containers” en el menú lateral y después en “+ Container”.

Ponele un nombre descriptivo: documentos-clientes, backups-sql, assets-web. 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 dentro:

Nivel de acceso	Qué permite	Cuándo usarlo	Cuándo NO
Private (sin acceso público)	Solo acceso autenticado (con Storage Account Key o SAS)	Datos sensibles, backups, documentos internos, bases de datos	Casi nunca expongas datos importantes sin autenticación
Blob	Lectura anónima de blobs individuales si conocés la URL exacta	Assets públicos: imágenes de un sitio web, PDFs descargables públicos	No si la URL en sí tiene que ser confidencial
Container	Lectura anónima de blobs Y listado de todos los archivos del contenedor	Casi nunca. Expone el inventario completo	Casi siempre; solo en casos muy específicos tipo demo o archivo público masivo

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

• Portal Azure (botón Upload): rápido para un archivo o dos, cómodo para no técnicos.
• Azure Storage Explorer: cliente de escritorio (Windows, Mac, Linux) con interfaz gráfica. Podés arrastrar archivos, ver previsualizaciones, subir carpetas enteras. Lo bajás gratis desde Microsoft.
• AzCopy: herramienta de línea de comandos, ideal para migraciones masivas. Soporta paralelización, reintentos automáticos y sincronización bidireccional.
• Azure CLI: az storage blob upload --file archivo.zip --container-name mi-contenedor --name archivo.zip --account-name mistarage.
• SDK (Python, .NET, Node.js, Go): para integración desde tu código. Control total sobre el proceso.

Habilitar acceso público a archivos específicos

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

Cuándo tiene sentido: assets de un sitio web (imágenes, CSS, JS), archivos de descarga pública (whitepapers, PDFs públicos), datasets abiertos para research.

Cuándo NO: datos de usuarios, configuraciones de la aplicación, backups con información sensible, cualquier cosa que no quieras indexada por bots y motores de búsqueda.

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

Para archivos que querés compartir por tiempo limitado — un informe confidencial a un cliente, datos de una investigación temporal — usá SAS, no acceso público.

Generar y configurar Shared Access Signature (SAS)

Un Shared Access Signature es una URL firmada que da acceso delegado a recursos de storage con permisos y tiempo de expiración específicos. Según Microsoft, hay tres tipos:

• 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.
• 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 se invalidan.
• Account SAS: firmado con la clave de la Storage Account, acceso a múltiples servicios. Tiene los mismos riesgos que Service SAS en cuanto a rotación de claves.

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

• Signing method: elegí entre Account key (la clave de la Storage Account) o User delegation key (basado en Azure AD). Para producción, User delegation key es mejor.
• Permissions: Read, Write, Delete, List, Add, Create. Marcá SOLO los que realmente necesitás. Ejemplo: un cliente que descarga un informe solo necesita Read.
• Start and expiry date/time: ponele hora de inicio unos minutos ANTES de la actual para evitar problemas de sincronización de reloj entre servidores. Expiración: ajustala a lo que realmente necesitás. Una hora para una descarga puntual, un día máximo para un cliente que va a descargar varias veces en el día.
• Allowed protocols: HTTPS only. NUNCA HTTP solo. Un SAS sobre HTTP expone la firma en texto plano.
• 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.

La URL resultante se ve así:

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

Los parámetros:

• sv: versión de la API de storage (2023-08-03 es la actual en julio 2026).
• st: fecha/hora de inicio (UTC). Si accedés antes, falla con 403.
• se: fecha/hora de expiración (UTC). Pasada esta hora, falla con 403.
• sr: tipo de recurso (b = blob individual, c = contenedor).
• sp: permisos (r = read, w = write, d = delete, l = list, etc.).
• sig: firma criptográfica HMAC-SHA256. Si alguien toquetea 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 el acceso sin tocar nada. Simplemente esperas a que expire o deleteas el blob.

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 basados en casos de migración de 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, comprimido con GZIP. Retiene 30 días con LRS. Costo mensual: ~$15 USD. Si en algún momento necesita restaurar, tiene el archivo listo en la nube sin depender de un servidor on-premise.
• Archivos de auditoría para cumplimiento normativo: organismos reguladores en Argentina exigen que los registros de auditoría se mantengan por 7 años. Esto suma terabytes. Guardarlos en Blob Storage con archive tier (muy barato, $0.001/GB/mes) evita que dejen un servidor viejo corriendo.
• Distribución de contenido a usuarios finales: una plataforma de e-learning en Santiago usa Blob Storage para alojar vídeos de cursos. Cada usuario descarga desde una URL con SAS de 24 horas. Permite acceso temporal sin crear cuentas complicadas.
• Catalogación 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, simplemente privatizan el contenedor y el inventario desaparece de la web automáticamente.

Integración con aplicaciones: ejemplos de código

Si estás desarrollando una app, vas a querer conectarte a Blob Storage desde código. Acá hay ejemplos rápidos 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 la misma: conectarte con las credenciales, subir el archivo, generar el SAS con expiración, y devolver la URL firmada al cliente.

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 — por ejemplo, para subir una foto 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.

Para habilitar CORS en tu Storage Account:

• Vas al Portal, entrás a la Storage Account, buscás “CORS” (debajo de “Settings”), hacés clic en “Blob service”.
• Agregás una regla: Allowed origins (https://tu-dominio.com o * para development), Allowed methods (GET, PUT, OPTIONS), Allowed headers (*), Exposed headers (*).
• Max age: 3600 (segundos que el navegador cachea la política).

Después, desde tu app:

const uploadFile = async (file) => {
const sasUrl = "https://mistarage.blob.core.windows.net/uploads/foto.jpg?sv=...";
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");
};

Fijate que usás un SAS con permiso de escritura (Write) y que el header x-ms-blob-type es obligatorio para block blobs.

Monitoreo, logs y diagnóstico

Cuando algo falla, necesitás ver qué pasó. Azure Storage tiene logs de diagnóstico.

Para habilitarlos:

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

Una vez habilitados, podés ver logs detallados de cada operación en una Storage Account: quién accedió, desde qué IP, a qué blob, si fue exitoso o falló, y cuánto tiempo tardó.

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

Precios y cálculo de costos

Los costos de Blob Storage dependen de tres factores: capacidad, transacciones y salida de datos.

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

Con GRS (Geo-Redundant), todos estos precios son aproximadamente 2x.

Un caso típico: empresa guarda 500 GB de backups diarios, retiene 30 días, 50 users descargan reportes = 500 GB × $0.024 + (30 × 50 descargas × $0.0004/10k) + (500 GB egress × $0.12). Estimado: ~$85 USD/mes.

Tip: si tenés datos que no se acceden casi nunca (archivos históricos, logs viejos), cambia el nivel a “Cool” o “Archive” para reducir costos de almacenamiento a $0.013/GB y $0.004/GB respectivamente.

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

Ponele que generaste un SAS y lo mandás a un cliente para que descargue un informe. El cliente lo guarda en un Slack interno, alguien copia la URL, y de repente tenés 50 personas distintas descargando ese archivo (sí, pasa).

• HTTPS siempre: configurá el parámetro de protocolo a “HTTPS only”. Un SAS sobre HTTP expone la firma en texto plano.
• Duración mínima necesaria: una descarga puntual = 1 hora. Un proceso que se repite durante el día = hasta 24 horas máximo. Microsoft tiene límites: User Delegation SAS está limitado a 7 días con la configuración estándar.
• User Delegation SAS sobre Account SAS: la clave de cuenta tiene acceso total a toda la Storage Account. Si alguien la obtiene, la rotás y todos los SAS caducan. Con User Delegation (basado en Azure AD), podés revocar acceso granularmente sin afectar a otros.
• Restringí por IP cuando puedas: si sabés de qué IP se va a acceder (office del cliente, rango de un proveedor), limitá el SAS a eso.
• 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.
• Rotá las claves de la Storage Account regularmente: Microsoft recomienda cada 90 días. Si usás la clave 1, rotala y cambia todo lo que la usa a clave 2. Después rotala de vuelta. Esto limita el daño si alguien la roba.
• Habilitá logging y monitoreá los accesos anómalos: si ves 10,000 requests desde una IP desconocida a un blob que casi nunca se toca, eso es un rojo.

Errores comunes y cómo diagnosticarlos

El error más frecuente es 403 Forbidden. Tiene varios orígenes. Según la guía de troubleshooting de Microsoft:

• SAS expirado: el parámetro se en la URL es una fecha/hora UTC. Revisá la hora actual del servidor (date -u en Linux/Mac, Get-Date -AsUTC en PowerShell). Si la hora actual es posterior a se, está expirado. Generá uno nuevo.
• Protocolo incorrecto: si generaste el SAS con “HTTPS only” y alguien accede vía HTTP, falla con 403 (no un error más descriptivo, un 403 genérico). Revisá la URL: debe empezar con https://, nunca http://.
• Tipo de recurso mal configurado: el parámetro sr es el tipo de recurso. sr=b = blob específico, sr=c = contenedor. Si generaste un SAS con sr=c e intentás acceder a un blob específico con ese SAS, falla.
• Desfase de tiempo: si configuraste el inicio del SAS para “ahora” pero hay una diferencia de reloj entre servidores, el SAS puede aún no ser válido (el parámetro st es futuro). Solución: pon el inicio 5-15 minutos en el pasado.
• 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 sin SAS.
• Permisos insuficientes en el SAS: el parámetro sp listá los permisos. sp=r = solo lectura. Si intentás escribir con un SAS de lectura, falla con 403. Revisá qué estás haciendo (lectura o escritura) y regenerá con los permisos correctos.

La forma más rápida de diagnosticar: en el Portal, entrás a la Storage Account, buscás “Monitoring” → “Diagnostics”, habilitás los logs (si no están ya), y revisás las entradas con status 403 en las últimas horas. Los logs van a incluir el motivo exacto.

Errores frecuentes que comete casi todo el mundo

• Nombre de Storage Account con mayúsculas o caracteres especiales: Azure rechaza nombres con mayúsculas, guiones o espacios. Solo minúsculas y números. Si venís de AWS S3, donde aceptan guiones, el cambio de mentalidad 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 específico) son SAS distintos con URLs distintas. Si usás el del contenedor para acceder a un blob sin la ruta correcta, no funciona.
• Usar acceso público en lugar de SAS para “simplificar”: el acceso público no tiene expiración, no se puede revocar por blob individual, y si habilitás “Container” level, exponés el listado completo. Para archivos temporales, SAS siempre. Punto.
• Olvidar que las claves de cuenta rotan: Azure genera dos claves por Storage Account. Si rotás la clave 1 (recomendado cada 90 días), todos los Service SAS y Account SAS basados en esa clave se invalidan. 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 (incluso en un repo privado históricamente), alguien puede tener acceso total a tu storage. Usá Key Vault o Managed Identity.
• No habilitar CORS cuando la app lo necesita: si una SPA web intenta escribir directamente a Blob Storage, sin CORS el navegador bloquea con un error que confunde. Habilitá CORS para tu dominio.

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

Si estás evaluando proveedores, acá hay un comparativo rápido de funcionalidad (no de precio, que cambia mensualmente):

Característica	Azure Blob	AWS S3	Google Cloud Storage
Redundancia automática	LRS, GRS, ZRS	Replicated por default, replication policies	Geo-redundant estándar
Versionamiento	Sí (versioning, snapshots)	Sí (version history)	Sí (object versioning)
Acceso temporal	SAS con expiración configurable	Pre-signed URLs, estándar por 7 días	Signed URLs con expiry
Integración con otros servicios	Logic Apps, Functions, Data Factory	Lambda, Glue, SageMaker nativo	BigQuery, Dataflow nativo
Tiers de almacenamiento	Hot, Cool, Cold, Archive	Standard, Intelligent, Glacier, Deep Archive	Standard, Nearline, Coldline, Archive
Control de acceso	Azure AD, Keys, SAS	IAM, Access Keys, Pre-signed URLs	IAM, Service Accounts, Signed URLs

Para Argentina y Latinoamérica, Azure tiene ventaja si ya usás ecosistema Microsoft (Office 365, SQL Server, Power BI, Teams). Si tu stack es JavaScript/Node y querés machine learning, Google Cloud puede ser más natural. Si estás en AWS, obviamente S3.

Preguntas frecuentes sobre Azure Blob Storage

¿Cuál es la velocidad de descarga desde Blob Storage en Latinoamérica?

Las descargas se sirven desde la región donde creaste la Storage Account. Si usás Brazil South (São Paulo), una descarga desde Buenos Aires o Montevideo típicamente tarda 50-100ms de latencia. Un archivo de 10 MB se descarga en 1-2 segundos. Si usás una región lejana (US East), sumás 30-50ms más. Para apps que exigen velocidad (streaming, descargas masivas), podés usar Azure CDN enfrente de Blob Storage y reducir latencia a 10-20ms desde cualquier punto de Latinoamérica.

¿Puedo borrar un blob si alguien tiene un SAS activo?

Sí, podés borrarlo en cualquier momento desde el Portal o una API. Después de borrado, el SAS no sirve (acceso dará 404). No hay “revocación” de un SAS individual en Azure — la única forma de revocarlo es esperar a que expire o rotary la clave que lo firmó (y eso afecta todos los SAS de ese tipo).

¿Qué pasa si supero el límite de 4.75 TB por blob?

El SDK no va a poder subir un archivo individual mayor a 4.75 TB. Si necesitás algo más grande, dividilo en bloques más pequeños o usa un servicio de transferencia distinto. En la práctica, casi nunca necesitás archivos de esa magnitud — ni una película 4K de 2 horas llega a 200 GB.

¿Puedo cambiar la región de una Storage Account después de crearla?

No. La región se elige al crear la account y no se puede cambiar. Si después necesitás estar en otra región, tenés que crear una Storage Account nueva en esa región y copiar los datos. Para regiones de baja latencia, planeá bien antes de crear.

¿Blob Storage está disponible en Argentina directamente?

Azure no tiene un datacenter en Argentina. La región más cercana es Brazil South (São Paulo). Desde allí se replican datos si elegís GRS (la replicación secundaria va a otra región de Brasil o USA). Para clientes argentinos con exigencias de soberanía de datos, esto es una limitación. Otros providers como AWS tienen regiones locales, pero Azure no.

¿Cómo automatizo un backup de mi base de datos SQL Server a Blob Storage?

SQL Server tiene un agente nativo para esto. Creás un agente de respaldo en SQL Server Management Studio, configurás el destino como “URL de Azure”, proporcionás las credenciales (Storage Account Key o SAS), y programás el backup (diario, semanal, lo que sea). También podés usar Azure Backup (servicio automático) o Data Factory (ETL visual). Para backups incrementales, T-SQL tiene BACKUP DATABASE TO URL WITH ... DIFFERENTIAL.