Cuándo una factura de AWS deja de ser un problema de costes y empieza a ser un problema de arquitectura

Una factura alta de AWS no siempre acusa a la arquitectura. A veces dice algo sano: hay más clientes, más tráfico y más uso real del producto. El coste sube porque el negocio también consume más infraestructura. Puede haber margen para optimizar, pero no necesariamente para rediseñar.

Otras veces el problema es más básico: recursos olvidados, entornos que nadie apaga, logs retenidos sin criterio, instancias sobredimensionadas o snapshots acumulados. Eso suele resolverse con una revisión ligera de costes, mejor visibilidad y responsables claros.

También hay una tercera situación: el coste no es un incidente ni una limpieza pendiente, sino una consecuencia directa de cómo está diseñada y operada la plataforma.

Ahí la pregunta cambia. Ya no es “qué recortamos este mes”, sino “qué decisiones técnicas hacen que este coste vuelva cada mes”.

Optimización puntual no es lo mismo que coste estructural

Conviene separar tres niveles que a menudo se mezclan:

• Limpieza básica: recursos que ya no se usan, entornos temporales que se quedaron vivos, tamaños elegidos por inercia, discos antiguos, snapshots olvidados o retenciones de logs que nadie revisó. Son problemas reales, pero normalmente no exigen replantear la arquitectura.
• Optimización FinOps ligera: entender qué servicios explican la factura, revisar tendencias, asignar responsables, detectar anomalías y decidir si ciertos compromisos de gasto tienen sentido. Para muchos equipos pequeños, esto basta para dejar de decidir a ciegas sin montar un programa FinOps completo.
• Coste recurrente de arquitectura: el diseño actual genera gasto de forma natural: por cómo circula el tráfico, cómo escalan los servicios, cómo se duplican entornos, cómo se almacenan datos, cómo se observan los sistemas o cómo se reparten responsabilidades.

La señal importante no es que la factura suba. Es que el mismo patrón vuelve aunque el equipo haga limpiezas puntuales.

Señales de que el coste apunta a arquitectura

Hay varias pistas útiles:

• Nadie puede explicar qué flujo de negocio justifica una parte relevante del gasto. El coste existe, vuelve cada mes, pero no está claro si responde a más usuarios, más datos útiles o simplemente a infraestructura que crece por diseño.
• La factura aumenta por componentes base más que por uso funcional claro: transferencia de datos, red, observabilidad, clusters, bases de datos, almacenamiento o entornos duplicados. No son problemas por definición, pero sí merecen una lectura arquitectónica, no solo contable.
• Cada nuevo cliente, feature o entorno replica recursos caros. Si añadir una parte pequeña del producto obliga a duplicar demasiada infraestructura, el problema no se arregla solo ajustando tamaños.
• El equipo toca límites, tamaños y configuraciones, pero nunca cuestiona el patrón que produce el coste. Se reduce una instancia, se cambia una retención, se ajusta un autoscaling, pero el diseño que empuja el gasto sigue igual.

Dónde suelen aparecer estos patrones en AWS

En AWS, muchos costes tienen una explicación técnica razonable. El objetivo no es señalar servicios como malos por defecto, sino entender qué decisiones los vuelven caros, opacos o difíciles de controlar.

Red y transferencia de datos

La red es uno de los lugares donde la arquitectura se convierte en factura. NAT Gateway, tráfico entre zonas de disponibilidad, tráfico entre regiones, acceso a endpoints públicos o rutas que obligan a pasar por componentes intermedios pueden tener impacto económico.

NAT Gateway no es un error. Pero su modelo de coste depende del tiempo de disponibilidad y del volumen de datos procesados, además de posibles cargos de transferencia. Por eso importa revisar qué tráfico pasa por ahí, si tenía que pasar por ahí y si la colocación de recursos está empujando tráfico innecesario.

La pregunta no es “¿eliminamos NAT Gateway?”. La pregunta es qué patrón de tráfico estamos pagando todos los meses y si responde a una decisión consciente.

Compute y contenedores

En contenedores pasa algo parecido. EKS, ECS, Fargate o EC2 no son decisiones buenas o malas en abstracto. Dependen del equipo, la carga, el modelo operativo y la complejidad que se puede asumir.

Con EKS, hay que considerar el coste del cluster y de los recursos asociados a los workloads. Con ECS, el modelo de ejecución —Fargate o EC2— cambia la lectura. En ambos casos, conviene mirar qué permanece encendido, cómo escala la carga y qué complejidad operativa se está pagando.

Un cluster infrautilizado no siempre es un error: puede responder a requisitos de disponibilidad, aislamiento o crecimiento previsto. Pero si nadie puede defender esa decisión con criterios técnicos y de negocio, la factura está avisando de algo.

Bases de datos

Las bases de datos mezclan coste, riesgo y prudencia. Instancias grandes, almacenamiento, IOPS, réplicas, Multi-AZ, backups y snapshots pueden estar justificados por disponibilidad, rendimiento o recuperación.

El problema aparece cuando esas decisiones se mantienen por inercia. Una base de datos dimensionada para un pico antiguo, réplicas sin función clara, almacenamiento sin ciclo de vida o backups que nadie ha probado pueden convertir una decisión prudente en coste estructural.

Aquí hay que ir con cuidado. Reducir coste en bases de datos sin entender carga, recuperación, disponibilidad y dependencias puede salir caro. La revisión debe separar necesidad real de configuración heredada.

Observabilidad

Más logs no siempre significan más visibilidad. A veces significan más ruido, más retención y más coste sin mejor capacidad de diagnóstico.

CloudWatch Logs y otros componentes de observabilidad se cobran por uso; el problema no es eso, sino producir y guardar señales sin decidir su valor operativo. Logs demasiado verbosos, retenciones indefinidas, métricas que nadie mira o trazas sin una pregunta concreta pueden convertirse en una factura recurrente difícil de defender.

Si la observabilidad no tiene criterio, el coste tampoco lo tendrá.

Entornos y duplicación

Desarrollo, staging, preproducción y producción pueden ser necesarios. Lo que no siempre es necesario es que todos repliquen la misma forma, tamaño y permanencia.

Muchos equipos duplican recursos porque es rápido y seguro. Tiene sentido al principio. Pero si no hay ciclo de vida, responsable claro o una política mínima de qué debe estar siempre encendido, los entornos dejan de ser una ayuda y se convierten en coste fijo.

La pregunta no es cuántos entornos tenemos. Es qué propósito cumple cada uno, cuánto necesita parecerse a producción y qué parte de su coste aporta confianza real al equipo.

Preguntas útiles antes de rediseñar

Antes de hablar de cambios grandes, merece la pena concretar:

• Qué parte del coste está ligada a crecimiento real del producto.
• Qué costes aparecen incluso cuando no hay más usuarios o tráfico.
• Qué decisiones se tomaron por rapidez y ahora se han vuelto permanentes.
• Qué componentes escalan juntos aunque no deberían.
• Qué gasto no tiene un responsable claro.
• Qué servicios explican la factura y a qué decisiones técnicas corresponden.
• Qué cambios serían reversibles y cuáles aumentan riesgo operativo.

Estas preguntas evitan dos errores: tratar todo como una limpieza menor o convertir cualquier factura alta en una excusa para rediseñar media plataforma.

Cuándo no hace falta rediseñar

No toda factura alta pide arquitectura.

Si el problema es falta de visibilidad mínima, primero hay que conseguirla. Si faltan etiquetas básicas, responsables, revisión de tendencias o una lectura clara de Cost Explorer, rediseñar puede ser prematuro.

Si el gasto viene de recursos olvidados o configuraciones claramente descuidadas, probablemente basta con limpieza, proceso y responsabilidad. No hace falta replantear una plataforma porque alguien dejó vivo un entorno temporal.

Si el coste sube porque el producto crece y la relación entre uso y negocio es razonable, el trabajo puede ser optimizar sin romper lo que funciona.

Y si todavía no se ha separado lo puntual de lo recurrente, conviene empezar por una revisión factual. La arquitectura se toca mejor cuando se sabe qué problema se está resolviendo.

Cómo plantear una revisión arquitectura-coste sin convertirla en un proyecto enorme

Una revisión útil no empieza con una lista infinita de buenas prácticas. Empieza por los servicios que explican la factura y los conecta con decisiones técnicas:

1. Identificar los grandes bloques de gasto y su tendencia, no para hacer una auditoría contable, sino para saber dónde mirar.
2. Mapear esos costes a flujos de producto, componentes técnicos y responsables. Si una parte de la factura no tiene dueño ni explicación, ya hay trabajo.
3. Separar mejoras rápidas de cambios estructurales. Apagar recursos olvidados no es lo mismo que cambiar un patrón de red, revisar una estrategia de contenedores o replantear cómo se generan logs.
4. Priorizar por recurrencia, riesgo y reversibilidad. Un cambio recurrente y de bajo riesgo suele ser mejor candidato que una reestructuración ambiciosa con impacto incierto.
5. Documentar la decisión: por qué existe un componente, qué coste se acepta, qué alternativa se descartó y cuándo habría que revisarlo.

Si el coste depende de memoria tribal, volverá a aparecer como sorpresa.

La factura como síntoma, no como enemigo

La factura de AWS no debería leerse solo como un problema financiero. También es una señal de arquitectura, operación y madurez del equipo.

A veces pide limpieza, más visibilidad o aceptar que el producto ha crecido. Otras veces pide revisar decisiones técnicas que eran razonables hace meses, pero que ahora generan coste recurrente.

FinOps y arquitectura no compiten. Se complementan. FinOps ayuda a ver dónde está el gasto y cómo evoluciona. La arquitectura ayuda a entender por qué existe y qué habría que cambiar para que tenga sentido.

El objetivo no es gastar lo mínimo. Es que el coste tenga una explicación técnica y de negocio defendible.

Si tu factura de AWS empieza a repetirse como síntoma y no como incidente aislado, una revisión de arquitectura y costes puede ayudar a separar mejoras rápidas de decisiones técnicas que merece la pena replantear.