La única diferencia que decide tu migración
Azure Blob Storage tiene su propia API, con sus propios SDK, su propia autenticación y sus propios conceptos — contenedores en lugar de buckets, blobs en lugar de objetos. Nuestro almacenamiento de objetos habla la API de S3, que es la interfaz que ya implementa casi cualquier otra herramienta del ecosistema.
Ese es el trabajo real de una migración, y vale la pena ser franco al respecto: si tu aplicación habla con Blob a través del SDK de Azure, vas a cambiar esa capa. Si habla con Blob a través de una capa de compatibilidad, o si todavía estás eligiendo, simplemente estás escogiendo la interfaz con más herramientas alrededor — aws-cli, mc, rclone, boto3, s3cmd y todas las herramientas de backup a las que alguna vez le creció un destino S3.
Todo lo demás — las expectativas de durabilidad, los objetos públicos o privados, los hábitos de ciclo de vida — se traslada conceptualmente. La API es la decisión.
Dónde residen los datos es cosa tuya
Azure te pide que elijas una región, y dependiendo de cuál elijas, los datos pueden acabar fuera de la jurisdicción que le importa a tu equipo legal. La pregunta es la misma aquí, y también la respuesta: tú eliges el país o la región en la que se almacenan tus datos. Operamos nodos de almacenamiento en Turquía, en Europa y en Estados Unidos, y tus buckets se ubican donde los necesites en lugar de allí donde resultó estar nuestro primer centro de datos.
Esa elección suele estar impulsada por dos necesidades distintas, y tiran en direcciones opuestas. El cumplimiento normativo quiere los datos en una jurisdicción específica — para una empresa turca que responde ante la KVKK, "en Turquía" es una respuesta mucho más corta que un párrafo sobre mecanismos de transferencia. La latencia quiere los datos cerca de quienes los leen. No tienes que resolver las dos cosas en la capa de almacenamiento: pon los objetos donde lo exija el cumplimiento normativo, y luego deja que el CDN sirva los públicos desde el edge más cercano al visitante.
Si tienes un requisito de jurisdicción, dínoslo antes de empezar a subir archivos — ubicar un bucket en la región correcta desde el primer día no cuesta nada, y mover terabytes más tarde no es gratis.
Un CDN delante del bucket, desde el mismo panel
En Azure, la cuenta de almacenamiento y el perfil de CDN son productos separados que conectas tú. Aquí el bucket y el CDN son la misma cuenta: apuntas un hostname al bucket, defines reglas de caché para las rutas que las merezcan, y purgas exactamente igual que purgarías cualquier otro origen — desde el panel, la API o la CLI.
Eso importa sobre todo en los casos aburridos. Una imagen de producto que cambia se purga por ruta. Una carpeta entera se purga por prefijo. La clave de caché es la misma que ya definen tus reglas de entrega, así que no hay un segundo modelo mental para "el CDN de almacenamiento".
Precios que puedes leer sin calculadora
Las facturas de almacenamiento en la nube tienden a llegar en piezas: almacenamiento, luego salida de datos, luego operaciones, luego una línea aparte para el CDN por delante. Las piezas son individualmente pequeñas y, juntas, sorprendentes.
Aquí el almacenamiento y la entrega tiran de un solo pool mensual — el tráfico que sirves y el almacenamiento que mantienes se cuentan juntos contra el plan que compraste, y el precio está en lira turca en una factura turca. No vamos a publicar una tabla comparativa contra las tarifas actuales de Azure, porque esas tarifas cambian y una tabla desactualizada en la página de un proveedor es peor que ninguna. Revisa tu propia factura de Azure de este mes, y luego mira la página de planes aquí; esa comparación es la única que vale la pena confiar.
Lo que tiene Azure que nosotros no
Una página de comparación honesta tiene que incluir esta parte.
Azure te da docenas de regiones por todo el mundo y nosotros no; ofrecemos almacenamiento en Turquía, Europa y Estados Unidos, lo cual cubre la mayoría de los requisitos y no todos. Azure tiene niveles de archivo y frío con su propia economía; nuestro almacenamiento es de un solo nivel. Azure se sitúa dentro de un ecosistema donde el almacenamiento blob es una pieza básica para docenas de otros servicios de Azure; si tu arquitectura se apoya en ellos, irte significa desmontar más que solo el almacenamiento.
El caso para cambiarte es específico y no universal: quieres la API de S3, quieres elegir la jurisdicción y conseguir una factura turca por ello, quieres el CDN y el bucket gestionados juntos, y no necesitas el ecosistema circundante. Si ese no es tu caso, quedarte en Azure es una respuesta razonable y preferimos decírtelo a venderte una migración.
Preguntas frecuentes sobre la alternativa a Azure Blob
¿Vuestro almacenamiento es compatible en API con Azure Blob?
No, y ningún proveedor compatible con S3 lo es. Blob tiene su propia API. La nuestra implementa la API de S3, así que el trabajo de migración está en la capa de tu aplicación que habla con el almacenamiento. Las herramientas que ya hablan S3 — aws-cli, rclone, mc, boto3 — funcionan sin cambios.
¿Cómo traslado los datos que ya tengo?
rclone es el camino habitual: habla tanto Azure Blob como S3, así que un único trabajo de copia traslada un contenedor a un bucket. Para conjuntos grandes, ejecútalo desde una máquina con buena conectividad a ambos extremos y verifica después con una pasada de checksum.
¿Puedo mantener mi dominio en los archivos?
Sí. Apunta un hostname al bucket a través del CDN y las URL públicas se quedan en tu propio dominio con SSL automático, en lugar de en un dominio de almacenamiento propiedad del proveedor.
¿Dónde se almacenan los datos, físicamente?
Donde tú elijas. Tenemos almacenamiento en Turquía, en Europa y en Estados Unidos, y un bucket se ubica en la región que pidas. Para una empresa turca eso normalmente significa Turquía, porque convierte una pregunta de la KVKK en una ubicación en lugar de una explicación — pero si tus usuarios o tus auditores están en otro sitio, dilo cuando configures la cuenta.
¿Qué pasa con los costes de salida de datos?
El tráfico que sirves cuenta contra el mismo pool mensual que el resto de tu entrega, en lugar de llegar como una línea de salida de datos aparte. Si la mayoría de tus objetos son públicos y están cacheados en el edge, la petición al origen ocurre una vez y el tráfico repetido se sirve desde el edge.