Cómo reduje los costes de infraestructura cloud un 75% en una startup FinTech financiada

La factura que inició la auditoría

Cuando me incorporé a Bridgewise en 2020, la empresa había crecido rápido. La Serie A había cerrado. El equipo de ingeniería estaba produciendo. Nadie había tenido tiempo de revisar la factura cloud de forma crítica.

Esa es la historia habitual en las startups financiadas. Sobredimensionas al principio porque las instancias son baratas en comparación con el tiempo de ingeniería, y luego dejas de revisar las decisiones una vez que el sistema funciona. La factura crece despacio, lo suficiente para no disparar ninguna alarma, hasta que alguien la examina con cuidado y se da cuenta de que lleva dos años acumulándose.

La examinamos con cuidado. Lo que encontramos no fue un gran error. Fueron cien pequeños errores que se habían ido acumulando en silencio.

Primer paso: descubrir dónde va el dinero realmente

Lo primero que hice fue extraer el informe del explorador de costes ordenado por servicio y luego por recurso individual. La mayoría de las auditorías de costes cloud fracasan porque la gente mira cifras agregadas en lugar de partidas individuales. 'El cómputo cuesta 40.000 dólares al mes' no dice nada útil. 'Este tipo de instancia específico en eu-west-1 cuesta 8.000 dólares al mes con un 12% de utilización media de CPU' dice exactamente qué hacer.

Hice una hoja de cálculo. Cada recurso que aparecía entre los treinta primeros por gasto mensual tenía una fila. Para cada uno: qué es, qué hace, cuál es su utilización media y cuándo fue la última vez que alguien revisó si su tamaño seguía siendo correcto.

La respuesta a la última pregunta, para la mayoría de ellos, era: en el lanzamiento.

Las tres categorías donde se escondía el dinero

Tras la auditoría, el desperdicio se concentraba en tres grupos. Casi todos los problemas de costes cloud que he visto desde entonces siguen el mismo patrón.

El primer grupo era el cómputo. Teníamos instancias aprovisionadas con tamaños que tenían sentido cuando estábamos estimando la carga durante el despliegue inicial. Dos años después, con datos de utilización reales, la mayoría funcionaban al 15-25% de CPU media. Ajustarlas al siguiente tamaño inferior —o en algunos casos dos tallas menos— recuperó una parte significativa de la factura total de inmediato. Sin cambios de código. Sin trabajo arquitectónico. Solo ajustar números en un archivo de configuración.

El segundo grupo eran los entornos. Teníamos entornos de desarrollo, staging y QA que funcionaban de forma continua, veinticuatro horas al día, siete días a la semana. Se usaban en horario laboral en una zona horaria. Una regla de programación que los detuviera a las 7 de la tarde y los reiniciara a las 8 de la mañana siguiente costó casi nada implementar y redujo el coste de cómputo de esos entornos aproximadamente un 60%.

El tercer grupo era la transferencia de datos y el almacenamiento. Este es el que más sorprende. Los proveedores cloud cobran por los datos que se mueven entre zonas de disponibilidad, entre regiones y hacia internet. Cuando los servicios se comunican entre zonas sin necesidad, o cuando los logs se envían por defecto a otra región, esos cargos se acumulan. Teníamos snapshots y volúmenes de almacenamiento que llevaban acumulándose durante toda la vida de la empresa sin ninguna política de retención. Limpiarlos y añadir reglas de ciclo de vida simples detuvo la sangría.

Lo que no hicimos

No recurrimos de inmediato a cambios arquitectónicos. Ese es el error que comete la mayoría de los equipos de ingeniería cuando deciden tomarse en serio los costes: saltar a 'deberíamos mover esto a serverless' o 'deberíamos reescribir esto con un motor de base de datos más barato' antes de haber agotado las correcciones simples.

Los cambios arquitectónicos son caros en tiempo de ingeniería e introducen riesgos. Ajustar el tamaño de una instancia lleva diez minutos y es totalmente reversible. Migrar una base de datos lleva meses y no lo es. El cálculo de valor esperado es obvio: haz primero las cosas baratas y reversibles. Reserva el trabajo arquitectónico para lo que queda después de haber recuperado ya la mayor parte de los ahorros.

En nuestro caso, tras el ajuste de tamaño, la programación de entornos y la limpieza del almacenamiento, ya habíamos recuperado la mayor parte de la reducción del 75%. El trabajo restante fueron cambios estructurales menores: consolidar algunos servicios que se habían desplegado de forma redundante y añadir etiquetas y grupos de asignación de costes para que la deriva futura fuera visible antes de que se acumulara.

La capa de gobernanza que evita que los ahorros se evaporen

La parte que la mayoría de los ingenieros omite es el trabajo de gobernanza. Puedes reducir costes un 75% y verlos volver a donde estaban en menos de un año si no pones estructura alrededor del problema.

Lo que implementamos fue sencillo: cada recurso requería una etiqueta de asignación de costes. Cualquier recurso sin etiqueta en un informe semanal se convertía en una acción obligatoria. Los horarios de entornos se aplicaban por automatización, no por personas que recordaran detener las cosas. Las políticas de ciclo de vida del almacenamiento se ejecutaban automáticamente.

No es complicado. Pero tiene que ser deliberado. La gobernanza de costes cloud no ocurre por defecto: los proveedores cobran por todo hasta que explícitamente les dices que no lo hagan, y lo ponen fácil para aprovisionar más y difícil para darse cuenta de lo que ya has olvidado.

Cómo se ve esto en la práctica para la mayoría de startups

Si estás en una startup y no has hecho una auditoría de costes cloud en los últimos doce meses, casi con certeza hay desperdicio significativo en la factura. El patrón es consistente: las empresas financiadas aprovisionan para el crecimiento, crecen y nunca vuelven a revisar las decisiones de aprovisionamiento que tenían sentido al principio.

Empieza con la utilización del cómputo. Extrae treinta días de métricas de CPU y memoria para cada instancia que estés pagando. Cualquier cosa con una media de CPU por debajo del 20% es candidata a ajuste de tamaño. Luego mira tus entornos: ¿cuántos están funcionando ahora mismo y cuántos se están usando realmente? Luego mira tu almacenamiento: ¿cuál es el snapshot más antiguo que estás pagando y realmente lo necesitas?

Esas tres preguntas te mostrarán dónde está el dinero. Las correcciones suelen ser sencillas una vez que sabes dónde buscar.

El 75% que recuperamos en Bridgewise no vino de una idea arquitectónica brillante. Vino de tratar la factura cloud como un tema de ingeniería de primer nivel y auditarla de la misma forma en que habríamos auditado consultas lentas a la base de datos o tasas de error elevadas: de forma sistemática, con datos reales, hasta entender qué estaba pasando realmente.