--- title: "S3 ya no es (solo) Amazon: alternativas, precios y el coste de recuperar" description: "La API de S3 sobrevivió a la despedida de MinIO. Ceph, SeaweedFS y Garage toman el relevo, y la factura real se esconde en el precio de recuperar datos." date: 2026-09-27 locale: es summary: "La API de S3 lleva congelada desde 2006 y es el idioma común del storage. MinIO, la referencia self-hosted, quedó archivada en 2026; el relevo lo toman Ceph RGW (madurez), SeaweedFS (el subconjunto S3 más amplio) y Garage (ligero y geodistribuido). En la factura, la trampa está en recuperar: un TB de Deep Archive cuesta más de 100 dólares de vuelta, mientras R2 y B2 no cobran salida a internet." url: https://escribano.dev/es/blog/018-s3-compatible-object-storage/ --- Abre la documentación de cualquier herramienta que toque almacenamiento: rclone, restic, Kopia, Duplicati, Cyberduck, PhotoPrism, Forgejo. En todas aparece la misma expresión, *S3-compatible*, en la página de configuración. Lo mismo en la web de cualquier proveedor de object storage que haya surgido en la última década. Hay una API que se convirtió en el idioma por defecto del sector, y la forma en que llegó ahí dice mucho de cómo se ganan los estándares. La pregunta de trivial suele formularse al revés: ¿cuál fue el primer servicio de AWS? La respuesta instintiva es S3 y falla. Amazon SQS abrió beta a finales de 2004, año y medio antes. S3 se lanzó el 14 de marzo de 2006, fue el primero en alcanzar disponibilidad general y EC2 llegó más adelante ese mismo año. S3 fue el segundo servicio en existir y el que bautizó a todos los demás. ## Una API congelada en el tiempo El anuncio original ocupaba un párrafo: *storage for the Internet*. El sistema arrancó con aproximadamente un petabyte de capacidad repartido en unos 400 nodos de almacenamiento, con objetos limitados a 5 GB y un precio de 15 centavos por gigabyte al mes. La consola web no existió hasta 2010: durante los primeros años, usar S3 significaba escribir código o instalar una herramienta de terceros. Veinte años después, la versión de la API que figura en la documentación sigue siendo `2006-03-01`. En el post de aniversario, AWS lo subraya: el código que escribiste contra S3 en 2006 funciona hoy sin cambios. El servicio creció por adición (objetos de hasta 50 TB, clases de almacenamiento, más de 500 billones de objetos) mientras el vocabulario básico se quedaba quieto. Esa quietud es la que hizo posible todo lo demás. ## Protocolo y producto comparten nombre Cuando alguien dice S3 puede estar nombrando dos cosas. El producto: la plataforma de AWS, con sus funciones exclusivas (lifecycle hacia capas frías, replicación, notificaciones de eventos, Object Lock, integración fina con IAM). El protocolo: el vocabulario HTTP que habla cualquier cliente (buckets, objetos, PUT/GET/DELETE, subidas multiparte, firma SigV4). El *S3-compatible* de las webs significa, en la práctica, hablar el protocolo con más o menos producto encima. Ahí está el detalle que conviene mirar antes de elegir: los clientes que usan el núcleo del vocabulario funcionan contra casi cualquier backend, mientras que los que dependen de funciones del producto solo funcionan contra AWS y contra los pocos proveedores que las replican. Algunos ejemplos de esa periferia que se cae fuera: * Backblaze B2 reduce las ACL a dos valores (privado o público) a nivel de bucket, no soporta tagging de objetos ni configuración de websites. * Hetzner mantiene el subconjunto más conservador: sin replicación, sin website, cifrado solo con SSE-C. * Cloudflare R2 deja fuera las notificaciones estilo Lambda y compensa con extensiones propias (buckets públicos, bindings de Workers). Un cliente como rclone (o restic, que solo necesita PUT, GET y LIST con su formato encima) apenas toca el núcleo. Por eso funciona en todas partes. Un script que se apoya en replicación o en event notifications ya está jugando en la cancha de AWS, aunque el endpoint sea otro. ## MinIO: la referencia se detuvo Durante una década, si querías hablar S3 sin nube, la respuesta era una: MinIO. Un binario en Go que exponía la API completa sobre discos propios. La referencia para pruebas, desarrollo y homelabs, y la demostración de que el protocolo podía ejecutarse sin AWS de por medio. Esa referencia envejeció de golpe. El proyecto pasó a AGPLv3 en 2021, con aviso explícito de lo que implicaba ofrecer el servicio en red con código modificado. En diciembre de 2025 entró en modo mantenimiento: sin características nuevas, sin pull requests, seguridad crítica evaluada caso a caso. En abril de 2026 el repositorio quedó archivado y en solo lectura. La edición comunitaria se distribuye solo como código fuente (via `go install`), las imágenes Docker oficiales se retiraron y la compañía redirige a AIStor, su producto comercial en ediciones Free y Enterprise. Existe un fork mantenido por Chainguard, también en modo mantenimiento, y el propio README de SeaweedFS recomienda RustFS (una reescritura en Rust con licencia Apache 2.0 y formato en disco compatible byte a byte) para quien necesite migrar una instalación MinIO tal cual. La lección pesa más que el proyecto. La comunidad trató a MinIO como la piedra del ecosistema S3-compatible, y la piedra resultó ser un producto con dueño que, llegado el momento, reservó el camino comercial para sí. La API sobrevivió. Los binarios, ya se ve. ## El relevo: Ceph, SeaweedFS y Garage El hueco lo cubren proyectos con perfiles distintos y años de rodaje a sus espaldas. Con una advertencia previa: *S3-compatible* es un espectro, no un sello binario. Ninguno de los tres implementa la API completa, y cada uno publica el suyo. Garage mantiene una página pública de compatibilidad, endpoint por endpoint, donde todo lo no implementado responde con un honesto `501 Not Implemented`. El veterano es Ceph RGW, la puerta de objetos de Ceph: una década y media de producción en OpenStack y plataformas similares, respaldo de la Ceph Foundation, Red Hat e IBM, con Object Lock, cifrado, IAM y multisitio. Su documentación habla de un subconjunto amplio de la API de Amazon. El precio de tanta madurez es la operación: un clúster RADOS con sus OSD exige una escala de mantenimiento que está lejos de una Raspberry Pi. SeaweedFS ocupa el centro. Go, Apache 2.0, 34.000 estrellas, ritmo de versiones semanal y el subconjunto S3 más completo del grupo: el gateway implementa 73 operaciones de bucket y objeto, IAM, STS, versionado, Object Lock con retención y legal hold, lifecycle, tagging y CORS, con una suite de compatibilidad en CI. Su nota honesta está en el propio README: MinIO seguía de cerca la API de AWS y SeaweedFS sigue avanzando hacia ese nivel. La arquitectura pide más piezas que un solo binario (master, volume, filer y gateway), aunque `weed mini` arranca todo en un comando para montajes pequeños. Garage apuesta por lo contrario. Rust, AGPL, un binario ligero sin dependencias externas, diseñado para clústeres geodistribuidos pequeños: tres nodos en tres casas distintas replicando datos sobre Internet. Deuxfleurs lo lleva en producción desde su primera versión en 2020. El subconjunto S3 es el más conservador del trío: sin versionado (en camino), sin Object Lock, lifecycle parcial y cifrado solo con SSE-C. Para restic, rclone o servir webs estáticas sobra; para una plataforma que dependa del versionado, corta. | Proyecto | Licencia | Fortaleza | Aviso | |----------|----------|-----------|-------| | Ceph RGW | LGPL2.1 | Madurez y multisitio a gran escala | Operación exigente | | SeaweedFS | Apache 2.0 | El subconjunto S3 más amplio | Más piezas que mantener | | Garage | AGPL | Ligero y geodistribuido | Sin versionado ni Object Lock | | RustFS | Apache 2.0 | Caída directa desde MinIO | 1.0 GA (septiembre 2026) | En la órbita cercana quedan dos opciones recientes: RustFS, que alcanzó su 1.0 GA el 16 de septiembre de 2026 después de más de un año de iteración pública, y VersityGW, un gateway sin estado en Go (Apache 2.0) que expone S3 sobre un sistema de ficheros POSIX, Azure u otro backend S3, con pruebas de conformidad contra los SDK oficiales de AWS. ## Las facturas: almacenar barato, recuperar caro B2 y R2 compiten con AWS por otro eje: el precio, y en concreto por la línea de la factura que aparece cuando pides los datos de vuelta. AWS publica el almacenamiento por clases, y ahí está la primera trampa. La clase Standard no cobra recuperación (los 0,023 dólares por GB y mes, unos 23 dólares por TB, son el coste de guardar). Las clases que abaratan el almacenamiento meten un peaje en la puerta de salida: | Clase de AWS | Almacenar ($/GB·mes) | Recuperar ($/GB) | Estancia mínima | |--------------|----------------------|------------------|-----------------| | S3 Standard | 0,023 | gratis | ninguna | | Standard-IA | 0,0125 | 0,01 | 30 días | | One Zone-IA | 0,01 | 0,01 | 30 días | | Glacier Instant Retrieval | 0,004 | 0,03 | 90 días | | Glacier Flexible | 0,0036 | 0,01 (bulk: gratis) | 90 días | | Glacier Deep Archive | 0,00099 | 0,02 (bulk: 0,0025) | 180 días | La letra pequeña acompaña: estancia mínima facturada si retiras antes de tiempo, tamaño mínimo facturable de 128 KB en las clases IA (mil millones de ficheros de 4 KB se cobran como si pesaran 128 GB), tarifas por petición encima, y un archivo restaurado de Glacier que factura como copia temporal en Standard mientras lo descargas. A eso se suma el tráfico hacia Internet: 0,09 dólares por GB en AWS (los primeros 100 GB al mes van gratis), en B2 gratis hasta un límite de tres veces el volumen medio almacenado al mes (después, 0,01 dólares por GB) y en R2 gratis sin condiciones. El ejemplo que hace visible la diferencia: restaurar un TB guardado en Deep Archive por la vía estándar cuesta unos 20 dólares de recuperación, la copia temporal en Standard (menos de un dólar al día), las peticiones y unos 85 más de salida hacia Internet si el destino final es tu casa. Más de cien dólares por traer de vuelta lo que cuesta cerca de un dólar al mes guardar. El mismo TB desde B2 entra gratis dentro de la regla del 3x (unos 10 dólares por encima) y desde R2 no paga salida; 10 dólares solo si estaba en su clase Infrequent Access, la única de las tres que mantiene un peaje de recuperación, anunciado y contenido. Comparativa directa (por TB y mes, tarifas publicadas): | | AWS S3 (Standard) | B2 | R2 (Standard) | |---|-------------------|----|---------------| | Almacenar | ≈ 23,5 $ | 6,95 $ | ≈ 15 $ | | Salida a Internet | 0,09 $/GB | gratis hasta 3x, luego 0,01 $/GB | gratis | | Capas frías con peaje | 0,01 a 0,03 $/GB | sin capas frías | solo IA: 0,01 $/GB | | Peticiones | 0,005 $/1k escrituras, 0,0004 $/1k lecturas | gratis (clase D a 0,004 $/10k tras 2.500/día) | 4,50 $/M escritura, 0,36 $/M lectura | Y el paquete plano europeo queda fuera de la comparación por estructura: Hetzner Object Storage vende una cuota base con almacenamiento y tráfico incluidos, datos en Falkenstein, Nuremberg y Helsinki, a cambio del subconjunto S3 más conservador del mercado (sin replicación, sin website, solo SSE-C), pensado para backups y servidores de ficheros. El catálogo real es más largo (Wasabi, DigitalOcean Spaces, Ceph RGW para quien quiera montarse el suyo), pero entre estos cubres el abanico de modelos: archivado barato, egreso cero, paquete europeo y autohospedado. ## El mismo binario, otro endpoint La promesa práctica del estándar se ve en una línea: ```bash aws s3 ls s3://mi-bucket --endpoint-url https://.r2.cloudflarestorage.com ``` El mismo CLI que usa contra AWS funciona contra R2, B2 o Hetzner añadiendo un flag. Con rclone el cambio es similar: al configurar un *remote* de tipo `s3` solo cambian endpoint, región y claves; el resto del pipeline (scripts, cifrado, cron) queda intacto. El esfuerzo de aprender una herramienta se paga en todos los backends a la vez, que es exactamente lo que un estándar promete. ## Piedra, papel y tijeras El [marco RPS](/blog/002-rps-principle/) ordena las opciones por el nivel de complejidad que estás dispuesto a mantener: | | Enfoque | |--|---------| | **Piedra** | Un bucket en B2 o en R2, restic o rclone, las claves en el gestor de contraseñas. Una copia remota que se puede restaurar. O Garage en un nodo propio si los datos pueden vivir en casa. | | **Papel** | Dos proveedores con la misma herramienta, scripts parametrizados por endpoint y restauraciones probadas de vez en cuando. O SeaweedFS en tres nodos para llevar el almacenamiento a tu hardware sin perder vocabulario. | | **Tijeras** | Ceph RGW con multisitio, lifecycle hacia capas frías, CDN delante del bucket y automatización completa del ciclo de vida. | El eje puente/ancla (que [ya analicé con el cloud-first](/blog/004-cloud-first-problem/)) encaja aquí con claridad. Hablar S3 es el puente: cambiar de proveedor se reduce a cambiar endpoint y claves, en cualquier dirección. El ancla aparece en tres sitios. Acoplarte a funciones del producto que solo AWS tiene (replicación con configuración fina, Object Lock, IAM) te ata al proveedor. Encadenar la arquitectura a la factura de egreso del hyperscaler te ata a la plataforma, y es justo el ancla que R2 convirtió en argumento comercial. Y el peaje de recuperación de las capas frías es el ancla silenciosa de la factura: te ata a las condiciones del proveedor en el peor momento posible, el día que necesitas los datos. La [soberanía digital](/blog/005-digital-sovereignty/) tiene aquí una versión práctica: los datos en Garage o Hetzner pesan distinto que en un bucket de AWS, con el mismo vocabulario por medio. ## El lenguaje común La historia tiene una ironía agradable. Amazon convirtió su API en el estándar de facto y, durante años, eso funcionó como puerta de entrada a una plataforma enorme. MinIO montó su posición sobre la parte libre de ese estándar y, al girar hacia el producto comercial, dejó el hueco que hoy ocupan Garage, SeaweedFS y Ceph. El protocolo sobrevivió a los dos: al congelar el vocabulario y crecer alrededor, quedó libre de copiarse, y cada proveedor lo habla con su propio acento. Los datos pueden vivir en tres casas distintas (Garage), en un clúster serio (SeaweedFS, Ceph), en un archivador barato (B2) o detrás de una red que no cobra por la salida (R2), y las herramientas siguen siendo las mismas. La elección se descompone en dos preguntas: con qué protocolo hablan tus herramientas (S3, casi seguro) y cuánto te costará traer los datos de vuelta el día que los necesites. La primera decide con qué backends puedes trabajar. La segunda decide cuánto te cuesta cambiar de idea. *Nota: mientras este post estaba en revisión, RustFS alcanzó su versión 1.0 GA (16 de septiembre de 2026). Gracias a Lorenzo de [atareao.es](https://atareao.es/) por el aviso.*