Reduciendo el coste de AWS en $150k al año simplemente apagando cosas

Artículo original ↗ Discusión en Hacker News ↗

La optimización de costes en la nube está emergiendo como una preocupación importante, ya que los ingenieros informan de recortes de decenas o cientos de miles de dólares simplemente auditando la infraestructura y apagando recursos de AWS no usados o sobredimensionados. Los participantes describen cómo la falta de visibilidad de costes, los incentivos desalineados y la cultura de gestión conducen a años de despilfarro, mientras que las herramientas, las prácticas de FinOps, el etiquetado y la automatización pueden reducir sistemáticamente el gasto. El hilo también aborda compensaciones más amplias, desde serverless frente a bare metal y el bloqueo con proveedor hasta si los empleados que generan grandes ahorros deberían compartir directamente las ganancias financieras.

Ahorros de coste observados y oportunidades fáciles

  • Muchos comentaristas informan de ahorros enormes, “vergonzosamente fáciles”, al apagar recursos no utilizados o ajustar el tamaño correctamente:
    • Reducir cuentas individuales de cientos de miles al mes a una fracción.
    • Encontrar canalizaciones de S3 abandonadas o bases de datos de prueba que cuestan cientos de miles o millones al año.
    • Detectar artefactos de CI como node_modules que se envían a S3 y se descargan por los clientes, añadiendo costes de transferencia anuales de seis cifras.
  • Culpables habituales: clústeres de prueba olvidados, logs con retención infinita, infraestructura de desarrollo/pruebas sobredimensionada, NAT gateways y viejas VMs/volúmenes EBS de los que nadie se hace cargo.

Incentivos, bonos y efectos perversos

  • Tema recurrente: los ingenieros que ahorran mucho dinero rara vez ven bonos proporcionales; a menudo reciben más reuniones o, en el mejor de los casos, un reconocimiento leve.
  • Algunos argumentan que esto desalienta la optimización de costes (“¿para qué molestarse?”), otros dicen “solo estás haciendo tu trabajo”.
  • Pagar un porcentaje del ahorro resulta atractivo, pero se ve propenso al abuso (“cultivo de cobra”: inflar y luego “optimizar”).

Visibilidad, FinOps y acceso a facturación

  • “No puedes optimizar lo que no puedes ver”: fuerte énfasis en paneles, etiquetado, informes semanales de costes y prácticas formales de FinOps.
  • Varios se quejan de que se bloquea a los desarrolladores el acceso a las consolas de facturación, lo que hace imposible notar picos accidentales de costes.
  • Cuando los costes y los descuentos privados se mantienen en secreto por la dirección, los ingenieros dejan de intentar optimizar.

Entornos de desarrollo/pruebas y automatización

  • Los entornos no productivos pueden costar más que producción si se dejan siempre activos o llenos de datos de prueba.
  • Estrategias populares: horarios de apagado automático, políticas de exclusión voluntaria respaldadas por etiquetas, bots que hacen cumplir duraciones de vida y herramientas que eliminan recursos no usados.
  • Algunos equipos van más allá con clústeres EKS “blue-green” o configuraciones serverless/Knative que escalan a cero.

Elecciones de plataforma cloud y arquitecturas

  • Debate sobre pasar de las grandes nubes a proveedores más baratos como Hetzner o bare metal:
    • Pro: posible ahorro de 10x si no necesitas servicios gestionados o SLA estrictos.
    • Contra: reimplementas tú mismo los servicios gestionados y pagas en tiempo de ingeniería y riesgo de fiabilidad.
  • Serverless puede reducir drásticamente los costes para cargas de trabajo con picos o de desarrollo, pero a menudo requiere una rearquitectura sustancial.

Cultura organizativa y prioridades

  • Muchos ven el despilfarro como producto de la cultura: entrega apresurada de funcionalidades, falta de revisiones de preparación para producción y compromisos cloud que atenúan los incentivos para recortar costes.
  • Para grandes empresas, incluso ahorros de varios millones pueden tratarse como un redondeo; para las pequeñas, es algo existencial.