¿Cómo decides las clases de almacenamiento de objetos y las reglas de ciclo de vida?

Ajusta la clase al patrón de acceso y a la tolerancia de recuperación. El acceso frecuente se queda en estándar; los patrones impredecibles encajan con el tiering inteligente, que mueve objetos de forma automática por una pequeña tarifa de monitorización. Las clases de acceso poco frecuente son más baratas de almacenar pero cobran por recuperación y tienen duraciones mínimas, y las clases de archivo son las más baratas con retrasos de recuperación. Usa reglas de ciclo de vida para transicionar y expirar, incluidas las versiones antiguas, y comprueba antes el número de objetos.

Miro con qué frecuencia se leen los datos y cuánto puede esperar quien los lee. Los datos calientes se quedan en estándar. Si nadie sabe decirme el patrón de acceso, el tiering inteligente es la respuesta honesta, porque mueve los objetos por ti y la tarifa de monitorización es pequeña comparada con equivocarse en la conjetura. Los datos que sé que se leen rara vez van a una clase de acceso poco frecuente, pero solo si van a vivir más allá de la duración mínima, porque si no el cargo por borrado anticipado se come el ahorro. Las clases de archivo son para retención de cumplimiento donde un retraso de recuperación de minutos u horas es aceptable. La trampa que compruebo antes de escribir cualquier regla de ciclo de vida es el número de objetos, porque las transiciones se cobran por objeto, así que un bucket con doscientos millones de ficheros de log diminutos puede costar más moverlo de lo que ahorra; esos habría que agregarlos. Y las mayores victorias normalmente no son la clase en absoluto. Activar la expiración de versiones no actuales en un bucket con versionado, y abortar las subidas multiparte incompletas después de una semana, me han reducido a la mitad la factura de un bucket cada una sin tocar ni un solo objeto vivo.