AWS Glue 6.0: convierte una partida olvidada en un 30 % de ahorro
Una auditoría breve separa los trabajos que conservan la tarifa antigua de los que pueden migrar a un runtime más económico.
La lista de trabajos de Glue puede contener definiciones que nunca especifican un runtime. Si un trabajo no indica un runtime de Glue, se asigna 5.1 por defecto y continúa con la tarifa anterior. AWS Glue 6.0 alcanzó la disponibilidad general el 21 de agosto de 2026 y conlleva una reducción de precio del 30 %.
La auditoría es una verificación de versión, no un recorrido por funciones. Necesitas los trabajos que pueden migrar, los medidores que realmente bajan y las trampas de compatibilidad que pueden convertir un ahorro en un pipeline fallido.
La mayoría de los equipos tienen una mezcla de trabajos creados antes del runtime actual y trabajos añadidos después. Los trabajos más antiguos son los que con mayor probabilidad carecen de un runtime explícito, así que muestreéalos primero cuando la lista sea larga. Una lista corta se puede revisar de principio a fin; una larga necesita una muestra que aún represente la carga de producción.
El runtime por defecto mantiene la factura antigua
El modelo de precios de AWS Glue separa los cargos por hora, facturados por segundo, para crawlers y trabajos ETL de un cargo mensual simplificado por almacenamiento y acceso al Data Catalog. En US East (N. Virginia), la tarifa DPU-hora reportada para la carga de trabajo aplicable es de $0.308, frente a $0.44 anteriormente. Use esa tarifa al recalcular la estimación y mantenga separadas las partidas que no corresponden a la carga de trabajo.
Para trabajos en otra región, obtenga la tarifa DPU-hora regional para la misma carga de trabajo y haga el mismo cálculo. Si la tarifa regional no es evidente, use el mismo tipo de carga de trabajo y el mismo período de facturación antes de comparar la factura. Así se mantiene la estimación vinculada a la carga de trabajo que cambió de precio. Compare lo comparable y deje que la factura muestre qué partidas se movieron realmente.
El cambio de tarifa es la prueba de compatibilidad
La pila del runtime es Apache Spark 4.1, Python 3.13 y Scala 2.13. Pruebe la parte de Spark antes de cambiar la versión, usando un trabajo que toque sus tablas más importantes en lugar de un script trivial.
Cuando el trabajo lee tablas Iceberg, verifique la ruta entre motores antes de declarar la migración segura. Las tablas Iceberg creadas en AWS Glue 6.0 no pueden ser leídas por Athena SQL, por lo que la compatibilidad entre motores requiere Iceberg v2.
Las tablas pueden funcionar en el trabajo que las escribió y fallar en el motor de consultas que las lee después. Esa restricción es fácil de pasar por alto cuando el ahorro parece limpio, así que la prueba debe ser aburrida: elija un trabajo que ya se ejecuta en producción, ejecútelo en el nuevo runtime y compare la salida. La comparación debe ser lo suficientemente cercana para confiar, no tan perfecta como para retrasar la auditoría para siempre.
Si la salida coincide, tiene evidencia. Si no, tiene una razón para esperar. Una migración fallida es peor que un descuento perdido, porque un pipeline fallido cuesta tiempo, y ese tiempo suele recaer en la persona que gestiona los datos.
El checklist hace que el recorte sea real
Cada elemento es una verificación rápida. Los cuatro pasos van de la lista de trabajos a la factura y a la prueba de producción.
- Revise la lista de trabajos en busca de definiciones que no indiquen un runtime.
- Recalcule un mes de DPU-horas con la tarifa 6.0 de US East (N. Virginia).
- Marque el medidor de Spark con descuento por separado de los medidores de catálogo y crawler.
- Verifique un trabajo por compatibilidad con Spark 4.1 e Iceberg antes de cambiar la versión.
El inventario salva la auditoría al detectar trabajos que carecen de un runtime explícito. El recálculo convierte el titular en un número que puede defender: cuente las horas de carga de trabajo, aplique la nueva tarifa y vea si el ahorro sobrevive a su mezcla real.
La verificación de medidores evita exagerar. Las partidas de catálogo y crawler se mantienen separadas en la estimación, por lo que la factura puede mejorar sin coincidir con el titular. Esto mantiene el número defendible en una revisión de presupuesto.
La compatibilidad es el freno. Un trabajo puede ahorrar dinero en papel y aun así fallar porque el runtime cambió debajo de él.
Mantenga la lista junto a las definiciones de trabajo. Cuando se cree un trabajo nuevo, haga el runtime explícito desde el inicio. Eso evita que la próxima auditoría se convierta en arqueología.
Haga la auditoría antes de cambiar la versión, no después de que llegue la factura. Deje los trabajos sin runtime explícito en el runtime antiguo hasta que tenga una razón para migrarlos.
