Reglas de ciclo de vida: expirar y limpiar archivos automáticamente

Toda app que recibe archivos acumula basura: miniaturas temporales, exportaciones que el usuario descarga una sola vez, logs, adjuntos de borradores abandonados. Si nadie los borra, el storage crece y la factura también. Un cron que liste y elimine objetos funciona, pero es más código que mantener y un punto más que puede fallar.

Las reglas de ciclo de vida (lifecycle rules) resuelven esto dentro del propio storage. Declaras la política una vez y se aplica a todos los objetos que coinciden con el filtro, existentes y nuevos. Los ejemplos de abajo usan la API de Amazon S3, el estándar de facto que también aceptan varios storages compatibles.

¿Qué es una regla de ciclo de vida?#

Es una instrucción con tres partes: un filtro que elige los objetos, una acción y un plazo. La acción más común es la caducidad (borrar). Los storages con clases de almacenamiento también ofrecen la transición (mover a una clase más barata).

En S3, cada regla tiene un ID (hasta 255 caracteres), un estado (Enabled o Disabled) y un filtro por prefijo de clave, por etiquetas, por tamaño del objeto o por una combinación. Un filtro vacío alcanza el bucket entero. El prefijo es lo que conoces como "carpeta": tmp/, exports/, logs/.

¿Cuándo se ejecuta la regla?#

No hay una hora exacta. En S3, el plazo en días se suma a la fecha de creación del objeto (que es la fecha de su última modificación) y el resultado se redondea a la siguiente medianoche UTC. Un archivo creado el 15/01 a las 10:30 UTC con una regla de 3 días queda elegible el 19/01 a las 00:00 UTC. La eliminación en sí ocurre después, de forma asíncrona.

En la práctica, usa la caducidad para limpiar, no como medida de seguridad. Si un enlace tiene que dejar de funcionar en 10 minutos, usa un enlace temporal firmado con validez corta y deja la regla de ciclo de vida solo para la limpieza.

¿Cómo crear una regla de caducidad con boto3?#

Instala con pip install boto3 y lee las credenciales y el endpoint de variables de entorno. El ejemplo hace caducar todo lo que está en tmp/ después de 7 días y aborta las subidas multipart detenidas desde hace 3 días.

import os

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    region_name="us-east-1",
    endpoint_url=os.environ.get("S3_ENDPOINT"),  # omítelo en AWS; defínelo en un storage compatible
    aws_access_key_id=os.environ["S3_ACCESS_KEY"],
    aws_secret_access_key=os.environ["S3_SECRET_KEY"],
    config=Config(signature_version="s3v4"),
)

s3.put_bucket_lifecycle_configuration(
    Bucket=os.environ["S3_BUCKET"],
    LifecycleConfiguration={
        "Rules": [
            {
                "ID": "caduca-tmp-en-7-dias",
                "Status": "Enabled",
                "Filter": {"Prefix": "tmp/"},
                "Expiration": {"Days": 7},
            },
            {
                "ID": "aborta-multipart-detenido",
                "Status": "Enabled",
                "Filter": {"Prefix": ""},
                "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 3},
            },
        ]
    },
)

Atención: put_bucket_lifecycle_configuration reemplaza la configuración entera. Para añadir una regla, lee las actuales con get_bucket_lifecycle_configuration, agrega la nueva y envía la lista completa. Si envías solo la nueva, las otras desaparecen.

Lo mismo con la AWS CLI, usando un archivo lifecycle.json con el contenido {"Rules": [...]}:

aws s3api put-bucket-lifecycle-configuration \
  --bucket "$S3_BUCKET" \
  --endpoint-url "$S3_ENDPOINT" \
  --lifecycle-configuration file://lifecycle.json

¿Y el versionado y las subidas incompletas?#

Hay dos casos en los que mucha gente tropieza.

Bucket con versionado. La acción Expiration solo afecta a la versión actual: crea un marcador de eliminación y la versión antigua pasa a ser "no actual", que sigue ocupando espacio. Para borrarla del todo, añade NoncurrentVersionExpiration con NoncurrentDays. Ese plazo es tu ventana de recuperación ante borrados accidentales. Puedes usar NewerNoncurrentVersions (de 1 a 100) para conservar las últimas N versiones, pero entonces la regla debe incluir el elemento Filter.

Subidas multipart abandonadas. Una regla de caducidad no elimina las partes de una subida que nunca terminó, y esas partes siguen ocupando espacio. La acción AbortIncompleteMultipartUpload lo resuelve, como en el ejemplo de arriba, pero no se puede usar en reglas con filtro por etiquetas. Encontrarás más detalles en cómo subir archivos grandes.

¿Cómo comprobar que la regla funciona?#

1. Vuelve a leer la configuración: s3.get_bucket_lifecycle_configuration(Bucket=...) debe devolver las reglas con Status: Enabled.
2. Antes de activarla en producción, lista el prefijo con list_objects_v2(Prefix="tmp/"): es exactamente el conjunto que la regla alcanzaría.
3. Sube un objeto de prueba a tmp/, espera a que pase el plazo (usa 1 día en un bucket de prueba) y confirma que desapareció.
4. Confirma que una carpeta sin regla, como invoices/, no se vio afectada.

¿Cuáles son los errores más comunes?#

• Filtro vacío por error. Filter: {"Prefix": ""} alcanza el bucket entero. En una regla de caducidad, eso borra todo objeto que pase del plazo.
• Olvidar la barra final. tmp también coincide con tmp-final/. Usa tmp/.
• Regla por fecha. Una acción con Date no se ejecuta una sola vez: sigue aplicándose a los objetos nuevos mientras la regla esté activa. Prefiere Days.
• Reemplazar la configuración sin leer la anterior. Revisa el aviso de arriba.
• Usar caducidad donde necesitas retención. Para las copias de una base de datos, define el plazo a propósito, como en backups en object storage.

Cómo hacerlo en Square Cloud#

En el Blob Storage de Square Cloud, la regla del ejemplo (borrar lo que está en tmp/ después de 7 días) no pasa por la API de ciclo de vida de S3: se convierte en una regla de carpeta "borrar después de N días" que defines en el panel. El conteo parte de la última escritura de cada archivo, y los plazos de menos de 7 días solo existen en Enterprise; en los demás planes, los 7 días del ejemplo ya son el mínimo. El endpoint S3 (https://s3-blob.squarecloud.app, región auto) cubre las operaciones de objeto: List, Head, Get, Put, Copy, Delete, multipart y URL prefirmadas.

La misma carpeta admite otras reglas que completan la limpieza: visibilidad, caché, tamaño máximo y extensiones permitidas. En cada objeto, además, defines la caducidad y el Cache-Control. Y vale el consejo de la sección sobre cuándo se ejecuta la regla: para un enlace que debe dejar de funcionar pronto, usa una URL prefirmada o el enlace temporal del panel, de hasta 24 horas, y deja la regla de carpeta solo para la limpieza.

No hay tarifa de salida ni de entrada, y la cuota incluida va de 5 GB a 250 GB según el plan; borrar lo temporal es lo que te mantiene dentro de ella. Para empezar, define en el panel la regla de 7 días en la carpeta tmp/. Conoce el Blob Storage y compara las cuotas en Precios.