¿Qué es el object storage? El almacenamiento compatible con S3, explicado

Objetos frente a archivos frente a bloques

El almacenamiento de bloques es un disco en bruto: rápido, conectado a una sola máquina y la unidad que quiere tu base de datos. El almacenamiento de archivos (NFS y compañía) es un árbol de carpetas compartido: familiar, pero el bloqueo y los metadatos se convierten en el cuello de botella a medida que crece. El object storage elimina el árbol por completo — cada objeto vive en un espacio de nombres plano dentro de un bucket, direccionado por una clave como "facturas/2026/08/1234.pdf". Esa clave parece una ruta, pero es solo un nombre; nada tiene que estar "dentro" de nada.

Esa única decisión de diseño es la razón por la que el object storage escala con tanta calma. No hay directorio que bloquear, ni sistema de archivos al que pasarle un fsck, ni volumen que redimensionar. Pagas por lo que almacenas, y el almacén crece de megabytes a terabytes sin ninguna migración. La contrapartida: los objetos se reemplazan enteros, no se editan en el sitio, y no hay semántica POSIX — que es exactamente por lo que es el hogar equivocado para una base de datos en producción y el hogar correcto para casi todo lo demás que tu aplicación sirve o archiva.

Qué significa realmente "compatible con S3"

Amazon S3 salió en 2006, y su API HTTP se convirtió en el estándar de facto del almacenamiento de objetos igual que SQL lo hizo para las bases de datos. Un servicio compatible con S3 implementa esa misma API, así que todo el ecosistema construido para S3 — AWS CLI, los SDKs de cada lenguaje, rclone, restic, el mc de MinIO, plugins de backup, desplegadores de sitios estáticos — funciona contra él sin cambios. Apuntas la herramienta a una URL de endpoint distinta y conservas tu memoria muscular.

Este es el significado práctico para ti: nada de vendor lock-in a nivel de herramientas. El código escrito contra la API de S3 se mueve entre proveedores cambiando dos líneas de configuración — el endpoint y las credenciales. También significa que puedes probar en local contra una implementación de S3 y desplegar contra otra sin tocar el código de la aplicación.

Buckets, claves y endpoints — las tres palabras que importan

Un bucket es el contenedor de nivel superior, y su nombre es único dentro del servicio — piénsalo como la "unidad" que creas por proyecto o por propósito (subidas, backups, assets). Un par de claves de acceso es la forma en que un programa se autentica: el access key ID lo identifica y la clave secreta firma cada petición. Trata la clave secreta como una contraseña — se muestra una sola vez al crearla, así que guárdala en tu gestor de secretos, no en el código.

El endpoint es la URL en la que vive la API de S3. En AWS tiene forma de región (s3.eu-central-1.amazonaws.com); en otros proveedores es la suya — en cdn.com.tr es s3.cdn.com.tr. Todas las herramientas de S3 aceptan sobrescribir el endpoint; ese único parámetro es el aspecto que tiene "compatible con S3" en la práctica.

El mismo AWS CLI que ya conoces — solo cambia el endpoint

# create a bucket
aws --endpoint-url https://s3.cdn.com.tr s3 mb s3://app-uploads

# upload and list
aws --endpoint-url https://s3.cdn.com.tr s3 cp ./photo.jpg s3://app-uploads/2026/photo.jpg
aws --endpoint-url https://s3.cdn.com.tr s3 ls s3://app-uploads/2026/

# sync a whole folder (deploys, backups)
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./public s3://app-uploads/site

Qué guardar dentro (y qué dejar fuera)

El object storage se gana su sitio allí donde los archivos se escriben una vez y se leen muchas: subidas de usuarios y contenido multimedia, imágenes y vídeo, artefactos de build y descargas de releases, archivos históricos de logs, volcados y copias de seguridad de bases de datos, y la mitad estática de tu web. También es el lugar natural para todo lo que debes conservar pero apenas tocas — el equivalente en almacenamiento a un almacén bien organizado.

Deja fuera todo lo que necesite ediciones en el sitio o bloqueo: archivos de bases de datos en producción, cachés calientes con expectativas de submilisegundo y archivos a los que un proceso añade datos de forma continua. Eso pertenece al almacenamiento de bloques o a una base de datos gestionada; el object storage recoge los artefactos duraderos que estos producen.

Por qué una CDN debe ir delante de los objetos públicos

Almacenar y entregar son trabajos distintos. El almacenamiento mantiene la copia canónica de forma duradera; una CDN responde la misma petición miles de veces desde ubicaciones edge cercanas a tus usuarios. Sirve un archivo popular directamente desde cualquier backend de almacenamiento y cada descarga viajará hasta el origen; pon un edge delante y el origen responderá aproximadamente una vez por archivo único mientras el edge absorbe la multitud.

En cdn.com.tr ambas cosas son partes de una misma plataforma: los buckets se pueden vincular a tus aplicaciones en contenedor, y el contenido público se sirve a través del mismo edge global que da servicio al resto de tu cuenta — un solo panel, una sola factura, sin sorpresas de tráfico de salida entre proveedores por tener el almacenamiento y la CDN separados.

Los errores que le cuestan dinero a la gente

Tres patrones explican la mayor parte del dolor con el object storage. Primero, el bucket público: dejar un bucket legible por todo el mundo cuando contiene datos privados. Por defecto, privado; haz públicos prefijos concretos solo cuando esa sea la intención. Segundo, servir archivos de alto tráfico directamente desde el almacenamiento en proveedores que facturan el tráfico de salida por gigabyte — esa factura crece con tu éxito; una caché edge delante la aplana. Tercero, credenciales en el código: una clave secreta filtrada es un token de acceso total a todo lo que hay en la cuenta. Usa claves separadas por propósito, guárdalas en variables de entorno o en un gestor de secretos, y rota cualquier clave de la que siquiera sospeches que se ha filtrado.