Cómo reducir costes de almacenamiento cloud

La factura de almacenamiento cloud rara vez sorprende por el almacenamiento en sí. Sorprende por todo lo demás: el egress que pagas cada vez que sacas datos, las peticiones que se cuentan de millón en millón, las penalizaciones por borrar antes de tiempo y los gigas olvidados que nadie audita. En esta guía desmenuzamos dónde se va de verdad el dinero al reducir costes de almacenamiento cloud y qué palancas concretas mueven la aguja, con ejemplos, comandos reales y un cálculo mensual completo.

Dónde se va el dinero de verdad

El precio por TB almacenado es la parte fácil de comparar y, paradójicamente, casi nunca es donde se infla la factura. Antes de optimizar nada, conviene entender las cinco partidas que de verdad descuadran un presupuesto de almacenamiento de objetos.

1. Egress y transferencia de salida

En la mayoría de hyperscalers, sacar datos cuesta varias veces lo que guardarlos un mes. Una restauración completa, un pipeline de analítica que relee tu bucket cada noche o un CDN mal configurado pueden generar decenas de TB de transferencia. A 0,09 €/GB —tarifa típica de salida a Internet en un gran proveedor— mover 20 TB en una restauración son más de 1.800 € en una sola operación, por encima de lo que pagarías por almacenar esos datos durante meses.

El egress es traicionero porque no aparece hasta que pasa algo: una migración, un incidente o un cambio de arquitectura. Audita cuántos GB de salida generas al mes y a qué destinos van. Si recuperas backups con frecuencia, el egress puede ser tu mayor coste oculto.

2. Coste por peticiones (PUT, GET, LIST)

Cada operación contra la API S3 puede facturarse por separado. Las cargas con muchos ficheros pequeños —logs, miniaturas, backups incrementales, sincronizaciones de rclone— generan millones de operaciones. Un LIST recursivo sobre un bucket con cientos de miles de objetos, ejecutado en cada despliegue, suma peticiones a un ritmo que sorprende. Cuando el proveedor cobra por cada PUT, GET y LIST, los datasets con muchos objetos pequeños penalizan mucho más que el espacio que ocupan.

3. Recuperación de clases frías

Las clases de archivo profundo (tipo Glacier) tienen un precio por TB muy bajo, pero esconden dos costes: la tarifa de recuperación por GB y la latencia de horas hasta que el dato está disponible. Si necesitas restaurar rápido o restauras a menudo, el ahorro nominal se evapora. La clase fría solo compensa para datos que de verdad casi nunca tocas y cuya recuperación puedes planificar.

4. Retención mínima

Muchos planes de almacenamiento frío aplican una retención mínima facturable de 30, 60 o 90 días. Si subes un objeto y lo borras a la semana, pagas igualmente el periodo completo. Para datos con rotación rápida —temporales, cachés, builds—, esa penalización por borrado temprano puede duplicar el coste real frente al precio anunciado.

5. Duplicidad de copias

La causa de sobrecoste más común y menos vigilada: copias redundantes que nadie ha contado. El mismo dataset replicado en tres regiones "por si acaso", snapshots que nunca expiran, versiones antiguas acumuladas por el versionado, backups full diarios cuando bastarían incrementales. Multiplicar copias multiplica la factura de forma lineal, y casi siempre hay una o dos copias que no aportan nada.

Estrategias para recortar la factura

Con el mapa de costes claro, estas son las palancas que más ahorro generan por unidad de esfuerzo.

Automatiza el ciclo de vida y la expiración

Las reglas de lifecycle son la herramienta de ahorro más infravalorada. Permiten expirar automáticamente datos temporales, limpiar versiones no actuales y abortar cargas multipart incompletas que ocupan espacio fantasma. Una política bien definida trabaja sola y evita que la basura se acumule durante meses.

{
  "Rules": [
    {
      "ID": "expira-temporales",
      "Filter": { "Prefix": "tmp/" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 }
    },
    {
      "ID": "limpia-versiones-antiguas",
      "Filter": { "Prefix": "" },
      "Status": "Enabled",
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Aplícala con la AWS CLI apuntando al endpoint de OtterStorage:

aws s3api put-bucket-lifecycle-configuration \
  --endpoint-url https://s3.otterstorage.io \
  --bucket backups-produccion \
  --lifecycle-configuration file://lifecycle.json

Tienes el detalle completo de filtros, prefijos y expiraciones en la guía de reglas de lifecycle.

Elige la tecnología de disco por tipo de dato

No todo merece el disco más rápido. En lugar de "clases" opacas con tarifas de recuperación, OtterStorage te deja elegir directamente la tecnología según el rendimiento que necesita cada dato:

• HDD a 8 €/TB y mes: backups, archivos fríos, copias de retención larga, datos que casi no relees.
• SSD a 16 €/TB y mes: datos calientes de acceso frecuente, assets servidos a usuarios, datasets de trabajo.
• NVMe a 45 €/TB y mes: cargas que exigen máxima velocidad de lectura, índices, datos de baja latencia.

Pagar 8 €/TB por lo que apenas tocas y reservar SSD o NVMe para lo que sí lo merece es la palanca más simple y de mayor impacto. Como no hay tarifa de recuperación ni latencia de archivo, mover algo a HDD no te castiga cuando necesitas leerlo. Revisa los detalles en la página de precios.

Deduplica antes de subir

La deduplicación en origen evita que pagues por almacenar el mismo bloque mil veces. Herramientas como Restic trocean los datos, calculan hashes y solo suben los bloques nuevos: dos backups consecutivos de una máquina que apenas ha cambiado ocupan casi lo mismo que uno. Aplicado a flotas de servidores o backups diarios, la deduplicación puede recortar el espacio facturado entre un 60 % y un 90 %.

export RESTIC_REPOSITORY="s3:https://s3.otterstorage.io/backups-produccion"
export AWS_ACCESS_KEY_ID="AKIAOTTER..."
export AWS_SECRET_ACCESS_KEY="..."

restic backup /var/lib/postgresql --tag diario
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

El forget --prune es clave: elimina snapshots viejos y libera de verdad los bloques que ya no referencia ninguno.

Evita las penalizaciones por borrado

Antes de mover datos de rotación rápida a una clase fría, comprueba la retención mínima. En un proveedor con 90 días de mínimo, borrar a los 10 días sigue costando los 90. La regla práctica: la clase fría es para datos que vivirán más que su periodo de retención mínima; para todo lo demás, sale más barato un HDD plano sin penalizaciones. En OtterStorage no hay coste por borrado ni retención mínima, así que borrar pronto nunca penaliza.

Vigila el versionado y los borrados fantasma

Con versionado activo, borrar un objeto no libera espacio: crea un marcador de borrado y conserva todas las versiones anteriores, que siguen contando para la factura. Sin una regla NoncurrentVersionExpiration, un bucket versionado crece indefinidamente aunque "borres" cosas. Lo mismo ocurre con el Object Lock: un objeto retenido en modo Compliance no se puede borrar hasta que venza, así que dimensiona bien los plazos de retención para no pagar por inmutabilidad que ya no necesitas.

Comparativa de modelos de coste

El precio por TB solo cuenta una parte de la historia. Lo que diferencia una factura predecible de una sorpresa es qué se cobra además del almacenamiento. Esta tabla resume los modelos de coste de los principales proveedores de almacenamiento de objetos compatible con S3.

Las cifras de terceros son orientativas y varían por región y plan; consúltalas siempre en su web. El punto relevante es el modelo: en OtterStorage no se facturan peticiones ni borrados, no hay retención mínima y no hay penalización por mover datos a HDD. Eso elimina de un plumazo tres de las cinco partidas que descuadran las facturas, y con descuento del 15 % en el pago anual y sin permanencia.

Ejemplo de cálculo mensual

Pongamos un caso realista: una empresa con 10 TB de datos calientes servidos a usuarios y 40 TB de backups de retención larga. Genera unos 50 millones de peticiones al mes (muchos ficheros pequeños) y borra y rota datos con frecuencia.

Con un modelo que cobra peticiones y penaliza borrados

• 10 TB calientes en clase estándar: ~210 €
• 40 TB en clase fría con recuperación: ~200 € + tarifas de recuperación al restaurar
• 50 M de peticiones: ~150 €-250 € según el reparto PUT/GET/LIST
• Penalizaciones por borrado temprano sobre datos rotados: variable, a menudo cientos de €
• Egress de las restauraciones del mes: el comodín que dispara la factura

El total real fácilmente supera los 700-900 €/mes, y eso sin una restauración grande de por medio.

Con OtterStorage

• 10 TB en SSD (datos calientes): 10 × 16 € = 160 €
• 40 TB en HDD (backups): 40 × 8 € = 320 €
• 50 M de peticiones: 0 €
• Borrados y rotación de datos: 0 €, sin retención mínima

Total: 480 €/mes. Con el 15 % de descuento anual, se queda en 408 €/mes equivalentes. Y, sobre todo, es una cifra predecible: no hay sorpresas por una restauración, un LIST recursivo o un script que borra demasiado pronto. La diferencia frente al primer escenario no está tanto en el precio por TB como en todo lo que no se factura.

Plan de acción en seis pasos

• Mide antes de optimizar: usa métricas por bucket para ver qué crece y qué nadie toca.
• Aplica lifecycle para expirar temporales, versiones antiguas y multipart incompletos.
• Clasifica por disco: HDD para frío, SSD para caliente, NVMe solo donde la latencia mande.
• Deduplica en origen con Restic u otra herramienta de bloques con hash.
• Cuenta tus copias y elimina la redundancia que no aporta valor de recuperación.
• Elige un modelo sin sorpresas: sin coste por peticiones, sin penalización por borrar, sin retención mínima.

Si vienes de otro proveedor, OtterBridge facilita la migración asistida sin parar tus copias, y puedes blindar la inmutabilidad de tus backups con OtterVault. La regla de oro sigue siendo simple: storage barato + egress y peticiones sin sorpresas + lifecycle automático = factura predecible.

Preguntas frecuentes

— Equipo OtterStorage