Ciclo de vida: automatizar qué conservas y durante cuánto tiempo

El problema: no todos los archivos se utilizan igual con el tiempo

Hasta ahora has decidido cuándo subir, copiar y borrar cada archivo. Imagina que una asociación genera miles de informes: durante el primer mes los consulta casi a diario; después solo los abre de forma excepcional y, cuando cumplen noventa días, ya no los necesita. Revisarlos uno a uno sería una tarea repetitiva y fácil de olvidar.

S3 Lifecycle, o ciclo de vida, permite dejar esas decisiones programadas en el bucket. Tú defines una regla y S3 realiza las acciones sobre los objetos que cumplen sus condiciones. Por ejemplo: «para los informes de archivo/, cambiar de clase al cumplir treinta días y eliminar al cumplir noventa».

En esta página vas a diseñar esa regla y comprobar qué significaría, trabajando individualmente con un editor y tu bitácora. No necesitas un bucket ni activar Learner Lab. No aplicarás la regla: sus plazos son de meses y el borrado tendría consecuencias reales. Al terminar tendrás un diseño que sabrás explicar, además de su representación en JSON.

Cambiar de clase y eliminar son dos decisiones diferentes

Un objeto tiene una clase de almacenamiento. Has utilizado S3 Standard: permite mantener datos de uso frecuente disponibles para su lectura. Hay otras clases con condiciones de acceso y facturación diferentes.

En este ejemplo estudiarás S3 Standard-IA. Las letras IA significan Infrequent Access, acceso poco frecuente. El objeto continúa disponible para una lectura normal, sin solicitar previamente una restauración, pero su recuperación tiene cargos específicos. Un menor precio de almacenamiento por GB no garantiza que el coste total sea menor.

Una regla puede incluir estas dos acciones:

Acción	Qué hace	Qué ocurre con tu documento
Transición	Cambia la clase de almacenamiento.	Sigue en el mismo bucket y con la misma clave. No crea una copia de seguridad.
Expiración	Programa su eliminación al alcanzar la antigüedad indicada.	En el caso sin versionado que estudiaremos, S3 elimina el objeto de forma permanente.

Por ejemplo, pasar archivo/informe.pdf de Standard a Standard-IA no lo mueve a otro bucket llamado «IA» ni cambia su dirección. Cambian las condiciones de almacenamiento, no su nombre. Expirarlo sí afecta a su conservación. Acciones de Lifecycle en AWS.

No confundas Standard-IA con todas las clases Glacier. Glacier Instant Retrieval permite acceso inmediato; Glacier Flexible Retrieval y Deep Archive requieren solicitar una restauración y esperar antes de acceder al contenido. No utilizaremos esas clases en el diseño principal. Clases de almacenamiento.

Nuestro caso: una regla para los informes de la asociación

Antes de abrir un formulario, escribe qué necesita la organización. En este caso los requisitos ya están decididos:

Decisión	Requisito del caso
Datos	Informes ficticios de entre 1 y 5 MB, cargados inicialmente en S3 Standard.
Alcance	Solo objetos cuya clave empiece exactamente por archivo/.
Primer periodo	Consulta frecuente durante los primeros treinta días.
Segundo periodo	Consulta excepcional desde el día treinta.
Conservación	Al cumplir noventa días dejan de ser necesarios.
Bucket supuesto	Propósito general, sin versionado, sin Object Lock ni retención.

Seguiremos un único objeto: archivo/informe.pdf, de 2 MB. Su tamaño es un dato del escenario, no necesitas crear ni subir ese PDF.

La regla tendrá un nombre reconocible, archivo-a-ia-y-expiracion. Un nombre sirve para identificarla; no selecciona objetos. La selección corresponde al filtro.

Primer paso: decidir a qué objetos afecta

Piensa en el prefijo como el comienzo exacto de la clave. Si el filtro es archivo/, S3 selecciona las claves que empiezan por esos caracteres, incluida la barra. No necesita una carpeta real ni busca la palabra «archivo» en cualquier posición.

Lee el diagrama desde las claves de la izquierda hacia el filtro y sus dos ramas: primero identificas los objetos del alcance; después interpretas su antigüedad y las acciones previstas. El esquema resume la regla, no representa un programa que tengas que ejecutar ni todos los detalles del planificador de AWS.

Ejemplo resuelto: archivo/2026/resumen.pdf sí coincide, porque comienza por archivo/. archivo-antiguo/resumen.pdf no coincide: después de «archivo» hay un guion en lugar de una barra. Un filtro demasiado amplio podría seleccionar datos que no querías eliminar.

Segundo paso: entender desde cuándo se cuentan los días

En esta regla, los días se cuentan desde la creación del objeto, no desde la fecha en que preparas la regla ni desde su última lectura. Para un objeto sustituido por una nueva carga con la misma clave, sin versionado, la nueva creación tiene su propio punto de partida. No lo sobrescribas para «probar» un vencimiento: estarías cambiando el objeto que estudias.

Descargar o consultar el informe no reinicia el contador. Si lo lees el día 29, la transición sigue prevista para cuando alcance treinta días de antigüedad. Para reglas sobre versiones no actuales existen otros parámetros; no son los de este ejemplo. Elementos y cómputo de las reglas.

El diagrama representa umbrales de antigüedad, no una cuenta atrás que puedas observar al segundo. AWS calcula los vencimientos basados en días y redondea a la siguiente medianoche UTC; las acciones se procesan de forma asíncrona y pueden aparecer después. No se garantiza su finalización a una hora exacta. Plazos y ejecución de Lifecycle.

El recorrido del caso se interpreta así:

Antigüedad aproximada	Qué prevé el diseño
Día 0	Cargas el informe en Standard.
Día 15	Todavía no ha alcanzado el umbral de transición.
Día 30	Cumple el umbral para pasar a Standard-IA.
Día 45	Una vez realizada la transición, puedes leerlo desde Standard-IA; considera su coste de recuperación.
Día 90	Cumple el umbral de expiración. S3 programa su eliminación.

No son treinta días más otros noventa. La expiración se fija a los noventa desde el origen: el intervalo previsto en Standard-IA es de unos sesenta días.

La regla también afecta a objetos que ya existan cuando se aplica. Si archivo/viejo.pdf lleva cien días almacenado, no recibe otros noventa de cortesía: ya cumple el umbral de expiración. Por eso hay que inventariar los objetos antes de activar una regla real.

Tercer paso: traducir las decisiones a JSON

Descarga el JSON de diseño y ábrelo en tu editor. Contiene el mismo caso que acabas de interpretar:

{
  "Rules": [
    {
      "ID": "archivo-a-ia-y-expiracion",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "archivo/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        }
      ],
      "Expiration": {
        "Days": 90
      }
    }
  ]
}

Léelo por partes, relacionándolo con los requisitos:

1. Rules contiene la lista de reglas. Aquí solo hay una.
2. ID es su identificador. Permite reconocerla cuando revisas la configuración.
3. Status: Enabled indica que estaría habilitada si se aplicara. Tener este texto en tu equipo no configura AWS. Disabled representa una regla deshabilitada.
4. Filter → Prefix decide qué objetos selecciona: los que empiezan por archivo/.
5. Transitions contiene el cambio de clase: Days: 30 y StorageClass: STANDARD_IA van juntos.
6. Expiration → Days: 90 define otro umbral desde la creación: el de eliminación.

Hay dos campos llamados Days, dentro de acciones diferentes. Antes de cambiar un número, identifica qué acción estás modificando. El JSON no admite comentarios: conserva tus explicaciones en la bitácora.

No ejecutes put-bucket-lifecycle-configuration ni apliques este archivo. Diseñar, guardar una regla en AWS y observar su ejecución son tres resultados distintos; en esta página realizas el primero.

Cómo reconocerías estas decisiones en la consola

Esta tabla es tu guía para trasladar el diseño a la interfaz cuando llegue el momento de configurarlo. Ahora complétala o consúltala sin crear un bucket ni guardar una regla.

En un bucket de propósito general, la ruta de referencia es Management / Administración → Lifecycle rules / Reglas de ciclo de vida → Create lifecycle rule / Crear regla. Las etiquetas pueden variar según el idioma.

Campo del formulario	Valor que correspondería al caso
Nombre de regla	archivo-a-ia-y-expiracion
Alcance	Limitar a un subconjunto de objetos; no elegir todo el bucket.
Filtro por prefijo	archivo/, sin nombre de bucket ni s3://.
Acción de transición de versiones actuales	S3 Standard-IA, a los 30 días desde la creación.
Acción de expiración de versiones actuales	90 días desde la creación.
Acciones sobre versiones no actuales	Ninguna en este diseño sin versionado.

No pegues este JSON en Bucket policy: ese editor configura permisos de acceso, no el ciclo de vida. Tampoco necesitas publicar el bucket o desactivar BPA para que una regla Lifecycle funcione. Configuración en la consola de AWS.

Qué debes comprobar antes de recomendar la regla

El día de transición y la duración mínima facturable son conceptos diferentes. En nuestro diseño elegimos el día treinta por el uso previsto de los informes. Standard-IA tiene una duración mínima facturable de treinta días una vez almacenado el objeto en esa clase: eliminarlo antes puede generar el cobro del tiempo restante, aunque ya no esté almacenado. El diseño deja unos sesenta días entre ambos umbrales, pero sigue siendo necesario calcular el coste. Condiciones de Standard-IA.

Las configuraciones nuevas de Lifecycle no transicionan por defecto objetos menores de 128 KB. Una regla puede coincidir por prefijo con un TXT diminuto sin que se realice su transición. Ese límite de transición no lo protege frente a una expiración que le corresponda. Por eso no utilizamos el pequeño aviso.txt de otras prácticas para demostrar este cambio. Restricciones de transición.

Para decidir si conviene Standard-IA, tendrías que conocer la cantidad y tamaño de informes, cuánto tiempo se conservan y cuánto se descarga. Compara almacenamiento, solicitudes de transición y acceso, recuperación y las transferencias que correspondan; revisa también posibles cargos por eliminación anticipada. No hace falta memorizar tarifas. Precios de S3.

Si vuelven a consultar intensamente los informes desde el día 40, la regla no los devuelve automáticamente a Standard por detectar esas lecturas. Cambió el requisito de uso y necesitas revisar la decisión de almacenamiento.

Qué cambia si el bucket tiene versionado

La interpretación anterior supone que no hay versionado. En ese caso, expirar el objeto lo elimina permanentemente: Lifecycle no guarda una copia para recuperarlo después.

En un bucket con versionado habilitado, expirar una versión actual normalmente añade un marcador de borrado; el contenido puede conservarse como versión no actual. Es el mecanismo que ya has estudiado al recuperar un objeto aparentemente borrado. Eliminar versiones no actuales requiere una acción específica, como NoncurrentVersionExpiration, que este JSON no contiene. Expiración y versiones.

Por tanto, «expirar a noventa días» no permite afirmar que hayas eliminado todo el historial ni su coste en un bucket versionado. Tampoco convierte Lifecycle en una copia de seguridad. Object Lock y otros requisitos de retención necesitan un diseño específico y quedan fuera del caso.

Ahora adapta el diseño y comprueba que lo entiendes

La asociación cambia un requisito: conservar los informes 180 días, manteniendo el paso a Standard-IA al día 30.

1. Guarda una copia local del JSON con el nombre ciclo-vida-180.json y modifica solo el valor que corresponde a la nueva conservación.
2. Dibuja su recorrido con los umbrales 0, 30 y 180. Indica desde dónde se cuentan y cuánto dura aproximadamente el segundo periodo.
3. Clasifica las siguientes claves. Supón que cada objeto mide 2 MB; debes comprobar el prefijo, no el tamaño.

Clave	¿La selecciona el filtro archivo/?	Motivo
archivo/informe.txt
archivo/2026/resumen.txt
archivos/informe.txt
borradores/informe.txt

4. Explica qué ocurriría con el contador si alguien descarga el informe el día 29. Después explica qué revisarías si las consultas se vuelven frecuentes desde el día 40.
5. Un compañero afirma: «mi archivo/aviso.txt de 1 KB no cambia de clase; por tanto, tampoco lo borrará la regla». Explica por qué su conclusión no es válida.

A entregar y cierre

Añade a tu bitácora la línea temporal del diseño adaptado, la tabla de claves y las respuestas breves a las dos situaciones. Adjunta ciclo-vida-180.json e indica al menos dos componentes de coste que consultarías antes de recomendarlo. Señala expresamente «diseño no aplicado» y explica en una frase por qué el caso sin versionado no permite deducir qué ocurriría con todo el historial de un bucket versionado.

No se han creado recursos en esta actividad. Si consultaste un formulario sobre un recurso propio ya existente, sal sin guardar y comprueba que no añadiste una regla accidental. La limpieza de los buckets de otras prácticas sigue correspondiendo a sus respectivos bloques.

Lectura complementaria: ¿Qué es una política de ciclo de vida de S3?, de Everpure. Úsala como introducción; cuando menciona «inactividad», recuerda que los campos Days de nuestra regla usan la antigüedad del objeto, no su última lectura. Las condiciones técnicas de este bloque se contrastan con las referencias oficiales de AWS enlazadas en cada apartado.