El recorrido del equipo de desarrollo de AB180 en la gestión de costos de AWS: desde revisar la factura hasta una cultura FinOps

Resumido con Gemini.

--

Operando la solución de medición de rendimiento de marketing 'Airbridge', que procesa enormes volúmenes de datos, hemos construido una cultura sistemática de gestión de costos de AWS (FinOps). Compartimos la experiencia y el know-how obtenidos en ese proceso.

Cómo opera AB180 su gestión de costos:
Para 'gestionar' los costos, operamos el siguiente proceso.

• Dashboard basado en Google Sheets: construimos un dashboard usando Google Sheets, que permite procesar y compartir datos fácilmente. Mostramos no solo el estado de costos por etiqueta, sino también el volumen de recolección de datos que impacta directamente en el costo, para identificar de forma intuitiva las causas de las variaciones. Además, visualizamos el estado de cobertura del Savings Plan y simulamos de antemano los resultados al cambiar contratos para apoyar una toma de decisiones razonable.
• Revisión periódica y automatizada de costos: cada dos semanas, revisamos las variaciones de costos en una reunión breve de unos 30 minutos. Automatizamos al máximo las tareas repetitivas, como la generación de materiales para la reunión, las alertas en Slack y la redacción del acta, para mejorar la eficiencia. Si la variación de costos es grande, la persona responsable analiza y comparte la causa mediante comentarios en Google Sheets, asegurando la transparencia.
• Cálculo de costos estimados antes del desarrollo: al desarrollar nuevas funciones o cambiar la arquitectura, hicimos obligatorio calcular los costos estimados en el documento de 'Tech Spec'. Esto permite tomar mejores decisiones técnicas considerando el costo desde la etapa de desarrollo.

Proceso de maduración del sistema de gestión de costos:
El sistema actual no se construyó de la noche a la mañana. Evolucionó a través de las siguientes etapas.

• Phase 0 (revisión de la factura): al inicio, nos limitábamos a revisar la factura cada mes.
• Phase 1 (clasificación mínima): empezamos a clasificar los recursos de forma mínima usando la etiqueta Name.
• Phase 2 (maduración de la estrategia de etiquetas): establecimos una estrategia de etiquetas basada en políticas claras como Team y Service. Como distribuir una guía no era suficiente, conectamos esto con políticas de IAM para forzar la configuración de etiquetas y construimos un mecanismo que envía alertas automáticas con un bot de Slack cuando hay recursos sin etiquetas. Como resultado, logramos mantener el costo de recursos sin etiquetas por debajo del 1% del total.

Cinco lecciones obtenidas en este recorrido:

• La ingeniería adecuada al contexto es importante. En lugar de perseguir un sistema perfecto para controlar costos, es más sensato construir gradualmente un esquema de gestión de nivel 'adecuado' para el tamaño y la situación de la empresa.
• 'Controlar' costos y 'optimizarlos' son cosas distintas. El 'control', que aumenta la previsibilidad de los costos, y la 'optimización', que reduce el costo en sí, son claramente diferentes. Hay que decidir en qué enfocarse según la prioridad de cada situación.
• Hay que automatizar con decisión. Más allá de automatizar tareas simples y repetitivas, si se construye un entorno de autoservicio (Self-serve) donde los colegas puedan consultar directamente los datos e identificar problemas, la productividad se maximiza.
• Hay que crear 'mecanismos'. En vez de decir "pongamos bien las etiquetas", es más efectivo diseñar 'dispositivos (mecanismos)' que obliguen a seguir la política, como que no se otorguen permisos a un recurso si no tiene etiquetas.
• FinOps al final es 'cultura'. Lo más importante es esforzarse de forma constante y construir una cultura donde la gestión de costos no sea tarea de una persona encargada en particular, sino una responsabilidad de todas las personas que crean el producto.

[tujuc]

Oh, con poner хотя sea las etiquetas más básicas, parece que ya se puede avanzar bastante.. :)

Pero, ¿reducir costos usando cosas como RI o SP se considera algo básico también...? Definir más o menos qué tamaños vamos a usar en nuestra infraestructura sí es un tema que da bastante para pensar...

[dongho42]

Aunque también se menciona en el artículo, yo por mi cuenta hice un simulador de SP y, con base en la carga de trabajo de los últimos n días, calculaba cuánto SP adicional convenía comprar para minimizar la suma de "el costo actual + el costo que se reduciría por quedar cubierto + el costo que se desperdiciaría por volverse recurrente", y tomaba decisiones con eso.

[slave4salary]

Actualmente trabajo en AWS Korea.

Una de las capacitaciones más importantes que se escucha al ingresar a la empresa es pensar en cómo ayudar a los clientes a gastar menos en costos de nube, y como uno de los métodos más efectivos se recomiendan RI & SP.

[cocofather]

Por favor, bájennos la tarifa..

[toughrogrammer]

Aunque no conozcas RI, en el caso de SP sí puede aplicarse a varias cargas de trabajo, así que si hay un costo fijo que se va a mantener, vale bastante la pena considerarlo. Incluso nosotros llegamos a comprarlo tomando en cuenta hasta el momento estimado de optimización... jaja. Por ejemplo, si crees que en 9 meses la optimización ya estará lista y el costo de los servidores se reducirá a la mitad, aun así te conviene más comprar 1 año completo, así que lo comprábamos de esa manera.