Optimización de costos en S3 en la práctica: del desglose de la facturación a 7 medidas accionables

Muchos equipos al revisar su factura de S3 solo se fijan en cuántos TB tienen almacenados, pero los costos reales de S3 suelen ser el resultado de la suma de cuatro categorías de cargos: capacidad de almacenamiento, número de peticiones, transferencia de datos y funciones de administración. La optimización también debe abordarse desglosando estas cuatro dimensiones, en lugar de simplemente migrar todos los buckets a clases de almacenamiento más frías.

Los siguientes precios se basan en us-east-1 a modo de ejemplo (los precios reales dependen de la región de AWS correspondiente): los primeros 50 TB de S3 Standard cuestan aproximadamente $0.023/GB-month; Standard-IA cuesta alrededor de $0.0125/GB-month; Glacier Instant Retrieval ronda los $0.004/GB-month; y Glacier Deep Archive está en torno a los $0.00099/GB-month. Aunque Deep Archive parece mucho más barato, tiene un tiempo mínimo de almacenamiento, tiempos de recuperación y tarifas de recuperación que impiden migrar de manera ciega.

1. Primero, identifique el origen de la facturación

Se recomienda desglosar primero los costos en Cost Explorer mediante la opción Usage type:

• TimedStorage-ByteHrs: Capacidad de almacenamiento de objetos.
• Requests-Tier1/Tier2: Peticiones como PUT, LIST, GET, etc.
• DataTransfer-Out-Bytes: Transferencia a internet o entre regiones.
• Monitoring-Automation, Inventory, StorageLens: Funciones de administración y análisis.

Un error común es pensar que el costo de almacenamiento es bajo, pero tener muchas peticiones LIST/GET, o que las subredes privadas accedan a S3 a través de una NAT Gateway, lo que dispara la factura de red. La optimización de S3 no debe limitarse únicamente a revisar el bucket size.

2. Intelligent-Tiering y reglas de ciclo de vida

Si los patrones de acceso a los objetos son inestables, S3 Intelligent-Tiering es un buen punto de partida de bajo riesgo. Este servicio mueve automáticamente los objetos entre niveles como Frequent, Infrequent y Archive Instant. No hay tarifas de recuperación al moverse entre estos niveles automáticos, pero se cobra un cargo de monitoreo y automatización, cuyo precio típico es de $0.0025/1,000 objects-month. Si los objetos son pequeños y muy numerosos, es posible que esta tarifa de administración no valga la pena.

Las reglas de ciclo de vida son ideales para datos con patrones de acceso definidos, como logs, copias de seguridad y muestras de entrenamiento:

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

Tenga en cuenta el tiempo mínimo de almacenamiento: por lo general, Standard-IA requiere 30 días, Glacier Instant Retrieval / Flexible Retrieval requieren 90 días, y Deep Archive requiere 180 días. No conviene mover prematuramente a clases frías los objetos con ciclos de vida cortos.

3. Glacier IR y Deep Archive: solo para datos “realmente fríos”

Glacier Instant Retrieval es adecuado para archivos de “baja frecuencia pero que requieren acceso en milisegundos”, como consultas de cumplimiento normativo o informes históricos. Deep Archive es ideal para datos que casi nunca se leerán y que pueden esperar varias horas para su restauración, como copias de seguridad de varios años.

El criterio de evaluación puede ser muy sencillo: si hay una alta probabilidad de que un objeto no se lea en 6 meses, vale la pena considerar Deep Archive; si el equipo de negocio no puede tolerar la espera de restauración, no fuerce la migración solo para mejorar la apariencia de la factura.

4. Limpieza de versiones anteriores y de Multipart Upload incompletas

Al habilitar Versioning, la eliminación de un objeto solo genera un delete marker, por lo que las versiones anteriores se siguen facturando. Muchos de los “costos fantasma” de los buckets provienen de estas versiones históricas.

Primero puede verificar las versiones:

aws s3api list-object-versions --bucket my-bucket --prefix app/

Luego, use el ciclo de vida para limpiar las versiones que no sean la actual:

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Es fácil pasar por alto AbortIncompleteMultipartUpload. Si la subida de un archivo grande falla, las partes fragmentadas pueden permanecer en S3 de forma indefinida y seguir generando costos.

5. Optimización de peticiones: LIST es más caro de lo que cree

En S3 Standard, el precio habitual para peticiones como PUT/COPY/POST/LIST es de aproximadamente $0.005/1,000 requests, mientras que para GET suele ser de unos $0.0004/1,000 requests. Aunque los precios unitarios parecen bajos, cuando la cantidad de objetos alcanza los cientos de millones, las operaciones de escaneo mediante LIST resultan muy costosas y ralentizan el sistema.

Recomendaciones prácticas:

• Evite utilizar ListObjectsV2 como si fuera una consulta de base de datos.
• Diseñe las claves (keys) de los objetos incluyendo fecha, cliente o prefijos de negocio para reducir escaneos innecesarios.
• Utilice S3 Inventory en lugar de realizar operaciones LIST completas.
• Agrupe o use caché para objetos pequeños con accesos frecuentes para mitigar las avalanchas de peticiones GET.

6. Uso de VPC Endpoint para evitar el desvío por NAT Gateway

Cuando instancias de EC2, ECS o funciones Lambda en subredes privadas acceden a S3, si el enrutamiento pasa por una NAT Gateway, se generarán cargos por procesamiento de datos de NAT. En us-east-1, el precio habitual de una NAT Gateway es de aproximadamente $0.045/hour más $0.045/GB processed; para 1 TB al mes, solo el costo de procesamiento de NAT rondaría los $45.

Al acceder a S3 y DynamoDB, priorice la configuración de un Gateway VPC Endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Por lo general, Gateway Endpoint no cobra una tarifa por hora y ayuda a reducir el tráfico que pasa a través de la NAT. Después de realizar el cambio, verifique la tabla de rutas (route table) para confirmar que la lista de prefijos (prefix list) de S3 apunte hacia el endpoint.

7. Compresión: compresión en el lado de la aplicación frente a pasarela transparente

La compresión es la optimización de capacidad más directa, pero depende del tipo de datos. Los archivos Parquet, ORC, logs en formato gzip, imágenes y videos por lo general ya están comprimidos, por lo que el beneficio es limitado. En cambio, JSON, CSV, logs de texto, objetos sin comprimir y algunos archivos de copia de seguridad pueden ofrecer beneficios significativos.

La ventaja de la compresión en el lado de la aplicación es que la arquitectura es simple y no requiere pasarelas adicionales; la desventaja es que exige modificar el código, gestionar la compatibilidad y migrar los datos históricos. Otra alternativa es utilizar una pasarela de compresión transparente: permite que la aplicación siga utilizando la API de S3 dirigiendo el cliente hacia la pasarela, la cual se encarga de comprimir los datos antes de escribirlos en S3.

S4 (Squished S3) pertenece a esta última categoría. Consiste en una AMI de EC2 que incluye el códec para GPU NVIDIA nvCOMP, y se ejecuta en instancias de GPU como g4dn/g5/g6. Una vez que el cliente de S3 apunta a la pasarela transparente, la cantidad de bytes almacenados en S3 para datos comprimibles suele reducirse entre un 50% y un 80% sin necesidad de modificar el código de la aplicación. No es adecuada para todos los escenarios: si los datos ya están comprimidos, si los objetos son muy pequeños o si las peticiones son sumamente elevadas pero el volumen no es tan grande, es posible que el beneficio no sea significativo. Los escenarios ideales para su evaluación son aquellos en los que S3 contiene grandes volúmenes de datos de texto o semiestructurados, donde el costo de la capacidad es el problema principal y se prefiere evitar cambios en la aplicación.

Puede comenzar utilizando la calculadora de costos de S4 para obtener una estimación rápida; no requiere que suba el archivo CSV de su factura y permite realizar pruebas utilizando datos de ejemplo.

Conclusión: primero medir, luego ajustar la estrategia

Secuencia recomendada para la implementación:

1. Utilice Cost Explorer para identificar los principales usage type de S3.
2. Utilice S3 Storage Lens para examinar la distribución de buckets, prefijos, versiones y tamaños de objetos.
3. Primero limpie las versiones anteriores y las subidas multipart incompletas.
4. A continuación, implemente el ciclo de vida, Endpoint y la optimización de peticiones.
5. Por último, evalúe la compresión o arquitecturas alternativas.

La reducción de costos en S3 no se limita a “moverlo todo a clases frías”. El enfoque realmente efectivo consiste en analizar de manera conjunta los patrones de acceso a los datos, el tamaño de los objetos, las rutas de las peticiones y los períodos de retención.

Divulgación: El autor de este artículo pertenece a abyo software (los creadores de S4, un producto de optimización de costos disponible en AWS Marketplace).