El descuento que no estabas cobrando: por qué Spot y Graviton son tan baratos

La factura de AWS superó el presupuesto dos meses seguidos. El gasto real superó el límite fijado por un porcentaje de un solo dígito. No era una cifra enorme en términos absolutos, pero la tendencia iba hacia arriba. Empecé a revisar los recursos uno por uno buscando qué más recortar, y la conclusión fue inesperada: casi no había nada que recortar. La palanca real no estaba en "cuánto se usa" sino en "cómo se compra". Lo que aprendí en el proceso es que cada cifra de la factura tiene una razón de ser, y solo conociendo esa razón se puede decidir qué apagar y qué dejar tal cual.

Los recursos ya estaban bien ajustados

Primero revisé el volumen de uso. Y esa parte ya estaba muy trabajada. El NAT gateway se había eliminado a favor de subredes públicas, los logs se retenían solo 7 días, el trazado usaba muestreo del 1%, y el dashboard de observabilidad estaba comprimido dentro del nivel gratuito. La base de datos y Redis ya corrían en instancias ARM más baratas, S3 tenía tiering automático, y el bastion solo se levantaba cuando hacía falta. A nivel de recursos, prácticamente ya se había exprimido todo lo exprimible.

Desglosando la factura de junio en proporciones: lo más grande era, con diferencia, la base de datos (RDS), que por sí sola representaba cerca del 40% del total; luego el cómputo (ECS Fargate), con cerca de un 17%; el balanceador de carga y el WAF, cada uno alrededor de un 10%; y la IP pública, la caché (ElastiCache) y S3 cerraban la lista con porcentajes de un solo dígito. Reducir aún más el tamaño de las instancias habría sido un retroceso: la base de datos ya se había ampliado una vez por falta de memoria, y el WAF estaba puesto a propósito para validar reglas antes del despliegue a producción. La palanca que quedaba no eran los recursos, sino la forma de pago: usar exactamente los mismos recursos, pero comprarlos más barato.

Por qué Spot es barato

Lo primero que salté a la vista fue que todo el cómputo se estaba comprando a precio on-demand estándar. AWS tiene una vía mucho más barata para vender el mismo servidor: Fargate Spot. Cuesta cerca de un 70% menos que on-demand.

Ese precio tan bajo tiene una razón. AWS construye sus centros de datos pensando en la demanda pico. En condiciones normales, sobra capacidad de servidor. Dejar esa capacidad ociosa genera cero ingresos, así que AWS la vende a precio de saldo con una condición: "si llega un cliente que paga precio completo, cedes el puesto en 2 minutos". Es el mismo principio que las aerolíneas al malvender asientos vacíos justo antes de despegar: si de todos modos el avión despega vacío, el ingreso es cero, así que conviene venderlo aunque sea con condiciones.

La cuestión clave es si puedes asumir esa condición: "si te piden que cedas el puesto, lo cedes". En producción resulta incómodo: si hay usuarios conectados y la tarea se recupera a los 2 minutos, el servicio se tambalea, aunque sea brevemente. Pero staging es distinto: no hay usuarios reales, y si se cae unos minutos, en el peor de los casos incomoda un momento a alguien de QA. Por eso migré la API de staging a Spot. El rendimiento es exactamente el mismo que on-demand, porque corre en el mismo hardware, con el mismo vCPU y la misma memoria. Lo único que cambia es la condición de disponibilidad -"puede ser recuperada"- y esa era precisamente la condición que staging podía asumir sin problema. Tras aplicarlo, las tareas de staging empezaron a correr con normalidad sobre Spot.

Por qué Graviton es barato

El segundo punto fue el chip del cómputo. La base de datos y Redis ya usaban instancias ARM, pero justo Fargate, donde corre la aplicación, seguía en x86. Migrando a Graviton, el chip ARM diseñado por la propia AWS, se obtiene el mismo rendimiento por cerca de un 20% menos.

La razón de este precio es distinta a la de Spot. Con una instancia normal, AWS le compra la CPU a Intel o AMD, así que lo que pagamos incluye el margen del fabricante del chip. Graviton es un chip diseñado directamente por AWS, así que ese margen intermedio desaparece. Además, la arquitectura ARM consume menos energía y genera menos calor para el mismo cómputo, lo que también reduce los costos de electricidad y refrigeración del centro de datos. Para AWS, el costo de origen es menor, así que vender un 20% más barato sigue siendo rentable, y además es una estrategia para atraer clientes hacia su propio ecosistema de chips.

Aquí está la diferencia importante. El descuento de Spot viene con la condición de "asumir la recuperación", pero el descuento de Graviton no tiene ninguna condición: simplemente es un chip más barato. Por eso Spot solo puede usarse en staging, mientras que Graviton se aplica igual hasta en producción. El rendimiento tampoco es motivo de preocupación: Node.js ofrece en Graviton un rendimiento por vCPU igual o incluso mejor que en x86. El único punto a observar es el cold start: al arrancar la app por primera vez, es sensible a la velocidad de un solo núcleo, y ahí Graviton puede ser algo más lento que un x86 reciente, añadiendo unos segundos al arranque. Por eso primero lo desplegué en staging para medir el tiempo de arranque, y solo después lo promoví a producción. La única verificación previa necesaria es confirmar que los módulos nativos se compilen para arm64.

Resumiendo la naturaleza de los dos descuentos: Spot es un descuento que se recibe a cambio de asumir una molestia, y por eso viene con condiciones (de ahí que sea solo para staging); Graviton es un descuento que se recibe al compartir la ventaja de costo del chip propio de AWS, y por eso no tiene condiciones (de ahí que llegue hasta producción). Con el mismo rendimiento, no había motivo para seguir pagando el precio completo de x86. En realidad, esta optimización no fue tanto ahorrar algo nuevo como empezar por fin a cobrar un descuento que ya estaba disponible.

También hay costos que no se deben apagar

Pero al revisar la factura también aparece la trampa contraria: partidas que parecen desperdicio pero en realidad son un seguro.

Ese fue el caso de RDS Proxy. Tenía un costo fijo mensual, y a primera vista parecía candidato a recorte. Una de las funciones de Proxy es manejar sin downtime la rotación automática de secretos, y esa rotación estaba desactivada. Así que la pregunta parecía obvia: si no se usa la rotación, ¿para qué mantener el Proxy?

Esa lectura era errónea. El propósito original de Proxy no era la rotación, sino frenar los picos de conexiones. Cuando un despliegue o un escalado horizontal aumenta de golpe el número de tareas, las conexiones hacia la base de datos también se disparan, y la base de datos tiene un límite de conexiones simultáneas que puede aceptar. Proxy agrupa y multiplexa esas conexiones antes de que lleguen a la base de datos, para no superar ese límite. Y precisamente esta base de datos era la misma instancia que ya se había ampliado una vez por falta de memoria, donde cada conexión adicional consume memoria. Es decir, ese costo fijo no era desperdicio: era la prima del seguro que evita que la base de datos colapse por una avalancha de conexiones cada vez que hay un despliegue. Apagarlo no habría sido ahorrar, sino retirar esa protección.

El origen del malentendido fue un comentario en el código. El comentario que explicaba ese Proxy estaba redactado casi por completo desde la perspectiva de la rotación, así que era fácil pensar "si la rotación está apagada, el Proxy también es innecesario". Por eso, en vez de quitar el Proxy de la lista de recortes, añadí una línea al comentario: "el propósito principal es contener los picos de conexiones; la rotación es una función secundaria". Para que quien revise la factura la próxima vez no cometa el mismo error de interpretación.

Cada cifra de la factura tiene una razón

Cuando alguien dice que hay que bajar el costo de la nube, la primera reacción es preguntarse qué apagar: reducir instancias, desactivar funciones, borrar recursos. Pero lo que aprendí esta vez fue justo lo contrario. Antes de recortar, la pregunta que hay que hacerse es "¿por qué está aquí esta cifra?".

Algunas cifras son descuentos que no se estaban cobrando. Como con Spot y Graviton, existía una vía para comprar el mismo recurso más barato, y simplemente se estaba pagando el precio completo. Cada uno de estos descuentos tiene su propia razón de ser barato, y conocer esa razón -si implica asumir una recuperación, o si es simplemente una ventaja de costo sin condiciones- determina dónde se puede aplicar con seguridad. Otras cifras, al contrario, son seguros que no se deben apagar. Aunque parezcan desperdicio, si están evitando un incidente concreto, esa línea de la factura no es un gasto: es una defensa.

Al final, leer la factura no consiste en hacer las cifras más pequeñas, sino en conocer la razón de cada una. Conociendo la razón, se puede quedarse con los descuentos cuya condición se puede asumir, y conservar los costos que evitan un incidente. Eso fue exactamente todo lo que hicimos: no ahorramos algo nuevo, solo distinguimos entre el descuento que había que cobrar y el seguro que había que conservar.