Graviton es esa rara palanca de coste que no exige un debate de arquitectura. No estás consolidando servicios, ni renegociando un contrato, ni discutiendo sobre multirregión. Estás cambiando una arquitectura de procesador, y si tu imagen compila, la factura baja.
El titular es en torno a un 20 por ciento menos por hora para el mismo tamaño de instancia, y a menudo más por unidad de trabajo, porque las generaciones nuevas además rinden mejor en la mayoría de cargas web y JVM. Pero la migración tiene una forma, y los equipos que se saltan el orden de abajo tardan un mes en lugar de una semana.
El orden que funciona
Empieza por los servicios gestionados. RDS, ElastiCache, OpenSearch y MemoryDB pasan a Graviton con un cambio de clase de instancia y una ventana de mantenimiento. No hay ninguna build que tocar, porque no eres tú quien ejecuta el binario. Esto es dinero gratis y debería hacerse antes de que nadie toque un Dockerfile.
Después, todo lo interpretado. Los servicios en Python, Node, Ruby y PHP suelen correr en ARM sin ningún cambio de código. Lo que se rompe no es tu código, es una dependencia nativa sin rueda compilada para aarch64. pip install se pondrá a compilar desde fuente en silencio, tu build pasa de dos a catorce minutos y alguien culpa a Graviton.
Luego la JVM y Go. Ambos son excelentes en ARM. Go necesita GOARCH=arm64 y nada más. La JVM necesita una versión reciente; Java 17 en adelante está bien afinado para Graviton, Java 8 no.
Al final, lo que lleve un agente de proveedor o una extensión en C que no controlas. Agentes de APM, agentes de seguridad, binarios con licencia. Comprueba el soporte de ARM del proveedor antes de planificar la migración, no durante.
Las cuatro cosas que muerden
Las imágenes multiarquitectura no son opcionales. Construye con docker buildx build --platform linux/amd64,linux/arm64 y publica una lista de manifiestos. Si no, el día que necesites volver a capacidad x86 —por escasez de spot, por ejemplo— no tendrás imagen. Construir imágenes ARM en runners x86 con emulación QEMU funciona pero es lento; los runners ARM nativos en CI reducen el tiempo de build a menos de la mitad.
Los grupos de nodos mixtos necesitan taints o te mentirán. En EKS, un grupo de autoescalado con las dos arquitecturas y una imagen de una sola produce pods atascados en CrashLoopBackOff con un exec format error. O pones selectores kubernetes.io/arch en todas las cargas, o mantienes las arquitecturas en grupos separados durante la transición. Preferimos grupos separados: convierte la vuelta atrás en una sola operación de escalado.
Lambda es la victoria más fácil y la más olvidada. Cambiar la arquitectura de una función a arm64 es una línea en Terraform, da alrededor de un 20 por ciento de descuento sobre el precio por milisegundo y normalmente corre más rápido. Lo que lleve una capa nativa empaquetada exige recompilar la capa; el resto es inmediato.
Mide por unidad de trabajo, no por hora. La instancia es más barata, pero lo que te importa es el coste por mil peticiones. Lanza un perfil de carga real contra las dos arquitecturas con la misma política de autoescalado y compara el p99 y el número de instancias. Hemos visto casos en que la instancia ARM era un 20 por ciento más barata y necesitaba un 15 por ciento menos de instancias, y casos en que una JVM mal afinada se comió toda la ganancia.
Qué esperar en la factura
En un entorno típico donde el cómputo es del 40 al 60 por ciento de la factura, mover los dos tercios compatibles a Graviton deja entre un 8 y un 15 por ciento de rebaja total. Se acumula con los Savings Plans, que es justo el motivo de secuenciarlo antes de comprometerte: compra un Compute Savings Plan contra la base posterior a la migración, no la actual. Ese es el paso cinco de las cinco capas de la factura de AWS, y hacerlo en el orden equivocado te fija el precio alto durante un año.
Planifica una semana por familia grande de cargas, prueba de carga incluida. Casi toda esa semana es trabajo de CI.
Qué hacer esta semana
Lista tus instancias de RDS y ElastiCache y mira qué clases tienen equivalente Graviton. Ese cambio es una ventana de mantenimiento, no necesita código y suele ser el primer cinco por ciento. Mientras la ventana está programada, pasa tus funciones Lambda a arm64 en staging y vigila la métrica de duración.