Resumen

  • S3 conserva y cobra las partes enviadas hasta que se completa o se aborta la carga. Marcar un trabajo como fallido en la aplicación no cierra esa cuenta.
  • El plazo de siete días de la documentación es una configuración de ejemplo para los buckets de uso general. Los buckets de directorio no admiten esa misma política de ciclo de vida.

Hay gastos que sobreviven porque nadie los considera una decisión. Una carga grande hacia Amazon S3 se interrumpe, el equipo abre otro intento y la atención se desplaza al que puede acabar bien. El intento anterior conserva algo menos vistoso que una barra de progreso: partes almacenadas que siguen costando dinero.

La documentación de AWS describe un servicio sensato. Dividir una carga permite enviar partes por separado y repetir las que fallan. La operación final las reúne en un objeto. Mientras no se complete o se aborte la carga, las partes enviadas permanecen y generan cargos de almacenamiento. La carga iniciada carece de una caducidad inherente. Guía de cargas multiparte de S3.

El cliente compra así la posibilidad de continuar sin empezar de cero. Con un archivo grande y una conexión inestable, esa posibilidad tiene valor. Su precio pierde sentido cuando desaparece la intención de usarla y nadie comunica el cambio al sistema que guarda los fragmentos.

La decisión que se esconde en el reintento

Pensemos en una productora que envía material para una entrega cancelada. Es un ejemplo hipotético: el cliente ya no quiere la película y el equipo deja la transferencia. Las partes recibidas siguen perteneciendo a un intento que técnicamente podría completarse. La actividad comercial ha terminado; la reserva de trabajo realizado sigue abierta.

También puede ocurrir lo contrario. El proyecto continúa, pero una máquina en origen necesita volver a estar disponible. Conservar lo ya enviado ahorra repetir una parte del trabajo. La misma operación de almacenamiento sirve, según el caso, a una entrega viva o a una intención extinguida.

Por eso una política que llama «basura» a toda carga incompleta empieza con una mala clasificación. Una política que conserva todo para siempre se equivoca en sentido contrario. Entre ambas hace falta alguien que pueda explicar qué se espera y hasta cuándo merece la pena esperar. Una posibilidad sin propietario tiene una asombrosa capacidad para renovar su alquiler.

Siete días no vienen incluidos por haber leído el manual

Para buckets de uso general, AWS ofrece AbortIncompleteMultipartUpload: se fija un número de días desde el inicio y las cargas incompletas que cumplen ese plazo pasan a ser elegibles para el aborto. S3 las detiene y elimina sus partes. La regla alcanza las cargas existentes y futuras dentro de su ámbito, y no borra objetos terminados. Los siete días que muestra la guía son un ejemplo que hay que configurar. Regla para cargas incompletas.

Elegir ese plazo es decidir cuánta paciencia se financia. Acortarlo reduce la permanencia de intentos abandonados, pero puede destruir avances todavía aprovechables. Alargarlo protege más oportunidades de recuperación y paga más tiempo de almacenamiento. Una cifra común para todos los trabajos no elimina la disyuntiva: la impone sin distinguirlos.

AWS señala que eliminar partes incompletas no tiene cargos por eliminación anticipada. El coste de equivocarse al limpiarlas puede aparecer en otro lugar: repetir el envío, volver a coordinar personas o retrasar una entrega. Completar la carga tampoco convierte el material en gratuito; termina el almacenamiento separado de las partes y queda el objeto, con su coste correspondiente.

El final debe incluir lo que todavía está llegando

El aborto manual tiene un matiz revelador. Las partes cuyo envío ya estaba en marcha pueden terminar con éxito o fallar después. AWS advierte de que puede ser necesario abortar varias veces para liberar todo el almacenamiento y recomienda comprobar con ListParts que no quedan partes. Referencia de AbortMultipartUpload.

El interés empresarial del detalle es sencillo. Cerrar un trabajo y terminar de recibir sus efectos son tareas distintas. Si una persona cancela la actividad y otro proceso aún está enviando datos, alguien debe cerrar el conjunto. De lo contrario, todos podrán enseñar su tarea terminada y seguirán existiendo recursos sin una salida resuelta.

Además, el tipo de bucket cambia la herramienta disponible. Los buckets de directorio conservan y facturan partes incompletas, pero no admiten configuraciones S3 Lifecycle. Antes de borrar el bucket hay que completar o abortar todas sus cargas multiparte en curso. Guía de buckets de directorio. Copiar una promesa de limpieza de un tipo al otro deja a la promesa sin mecanismo.

Para atribuir una pérdida concreta faltan el inventario de partes, su utilidad pendiente y las facturas del cliente; una continuación todavía necesaria cambiaría esa valoración. Lo que ya puede exigirse es una decisión con nombre. Quien conserva la oportunidad de terminar debería saber qué espera obtener de ella.

Un trabajo a medias puede ser un activo. Un trabajo a medias al que nadie piensa volver puede ser un gasto sin defensor. S3 guardará ambos con la misma diligencia. La diferencia le corresponde al comprador.