Cómo reviso los costes de AWS para equipos pequeños sin convertirlo en un proyecto de FinOps

La mayoría de equipos con los que trabajo tienen el mismo problema: saben que su factura de AWS es más alta de lo que debería, pero no tienen ni el tiempo ni el equipo necesarios para montar un programa de FinOps en condiciones. No son un banco. No tienen un equipo dedicado a costes. Lo que tienen es uno o dos ingenieros a los que les importa el tema, y un CTO que se pone nervioso con la factura al final de cada mes.

Así que este es el proceso que uso de verdad cuando hago una revisión de costes para un equipo pequeño. Es deliberadamente simple. El objetivo no es alcanzar una economía cloud perfecta, sino hacer los cambios con más impacto y con la menor fricción operativa posible.

Para quién es esto

Equipos de ingeniería de 3 a 30 personas en AWS que:

• nunca han hecho una revisión formal de costes
• están gastando entre 2.000 y 30.000 dólares al mes
• no tienen personal dedicado de FinOps, plataforma o SRE
• quieren dejar de malgastar dinero sin dedicarle semanas

Cuándo usar esta lista de comprobación

Úsala cuando:

• la factura de AWS ha crecido de forma visible pero las cargas no han cambiado mucho
• estás entrando en una ronda de financiación o en una revisión con el consejo y alguien pregunta por el gasto en cloud
• acabas de heredar una cuenta de AWS y no sabes qué está corriendo
• los costes han subido de forma inesperada y estás intentando averiguar por qué

No la uses como sustituto de una revisión de arquitectura. Si los costes vienen de un diseño defectuoso (un tipo de base de datos equivocado, transferencia de datos sobredimensionada, etc.), eso requiere otra conversación.

La lista de comprobación

1. Saca una línea base de costes por servicio

• Por qué importa: No puedes priorizar si no sabes de dónde sale realmente el dinero. La mayoría de equipos se sorprenden: normalmente los tres servicios principales explican el 70-80 % del gasto total.
• Qué revisar: Ve a AWS Cost Explorer → Group by Service → últimos 3 meses. Exporta o haz una captura. Anota qué servicios están creciendo.
• Error habitual: Mirar el total y saltarse el desglose por servicio. La cifra total sirve de bastante poco si no sabes qué la está empujando.

2. Revisa recursos ociosos u huérfanos

• Por qué importa: Todas las cuentas acumulan peso muerto: instancias EC2 paradas que se dejaron "temporalmente", volúmenes EBS sin adjuntar, instantáneas antiguas, balanceadores de carga olvidados. Todo eso cuesta dinero cada mes sin ninguna razón.
• Qué revisar:
  • Instancias EC2 con < 5 % de CPU durante 2+ semanas (usa CloudWatch o las recomendaciones de ajuste de tamaño de Cost Explorer)
  • Volúmenes EBS sin adjuntar (EC2 → Volumes → filtra por available)
  • Instantáneas de más de 90 días sin instancia asociada
  • Balanceadores de carga con cero conexiones activas
  • Instancias RDS en estado detenido (AWS las reinicia al cabo de 7 días igualmente; si se siguen parando, plantéate borrarlas)
• Error habitual: Olvidarse de las instantáneas de EBS. Se acumulan en silencio y pueden convertirse en cientos de dólares al mes en equipos que hacen instantáneas automáticas diarias sin una política de retención.

3. Evalúa el dimensionado del cómputo

• Por qué importa: El sobredimensionamiento de EC2 es la fuente más habitual de coste evitable en cuentas pequeñas. Los equipos dimensionan para el peor pico de tráfico y luego no vuelven a revisarlo.
• Qué revisar:
  • Métricas de CPU y memoria en CloudWatch para todas las instancias EC2 en ejecución
  • Busca instancias que estén de forma consistente por debajo del 20 % de CPU: son candidatas a reducir tamaño
  • Comprueba si alguna instancia puede pasar a una generación más nueva (por ejemplo, m5 → m7g puede dar una mejora del 20-40 % en rendimiento por dólar)
  • Para cargas en ECS/Fargate: revisa la asignación de CPU/memoria de las tareas frente al uso real
• Error habitual: Ajustar el tamaño de EC2 pero no de RDS. Es facilísimo sobredimensionar una base de datos "por si acaso" y olvidarse. Mira DatabaseConnections y CPUUtilization en CloudWatch: una db.r5.2xlarge funcionando al 5 % es dinero tirado.

4. Mira la transferencia de datos y los costes de NAT Gateway

• Por qué importa: Los cargos por transferencia de datos y NAT Gateway son invisibles hasta que dejan de serlo. He visto cuentas en las que NAT Gateway costaba más que EC2.
• Qué revisar:
  • Cost Explorer → Group by Usage Type → filtra por DataTransfer y NatGateway
  • Si NAT Gateway pesa bastante, averigua qué está haciendo llamadas salientes. Muchas veces son agentes, SDKs o herramientas de monitorización corriendo en subredes privadas y llamando continuamente a APIs externas.
  • Revisa la transferencia entre AZ: el tráfico entre zonas de disponibilidad no es gratis. Algunas arquitecturas crean saltos entre AZ que no hacen falta.
• Error habitual: Asumir que la transferencia de datos viene solo de S3 o CloudFront. La mayoría de costes inesperados de transferencia vienen de EC2 y del tráfico interno entre servicios.

5. Revisa el almacenamiento en S3 y los costes por peticiones

• Por qué importa: S3 es barato por GB, pero se dispara rápido en equipos que hacen muchas peticiones o guardan datos de acceso poco frecuente en la clase Standard.
• Qué revisar:
  • Qué buckets tienen más datos (usa S3 Storage Lens o aws s3api list-objects-v2 con un resumen)
  • Si hay buckets guardando registros, copias de seguridad o artefactos antiguos sin política de ciclo de vida
  • Si hay algo en S3 Standard que claramente está frío (registros de más de 30 días, artefactos de despliegue, copias de seguridad)
  • Revisa los costes de peticiones de S3 en Cost Explorer: los cargos de PUT y GET pueden ser sorprendentemente altos en cargas de pipelines de datos
• Error habitual: Guardar registros de aplicación o artefactos de CI/CD indefinidamente. Una política de ciclo de vida que expire objetos a los 30-90 días suele ser segura y reduce costes de forma apreciable con el tiempo.

6. Evalúa opciones de compromiso si el gasto es predecible

• Por qué importa: Si tu gasto en EC2 o Fargate es razonablemente predecible, los Savings Plans pueden recortar el coste de cómputo entre un 20 y un 40 % con muy poco esfuerzo.
• Qué revisar:
  • Ve a Cost Explorer → Savings Plans → Coverage report. Una cobertura baja con uso consistente es una oportunidad clara.
  • Los Compute Savings Plans son la opción más flexible para equipos pequeños: se aplican automáticamente a EC2, Fargate y Lambda.
  • Empieza con 1 año sin pago inicial. Compromete solo lo que tengas claro que vas a seguir usando.
• Error habitual: Confundir Savings Plans con Reserved Instances. Para equipos pequeños con cierta flexibilidad arquitectónica, Compute Savings Plans casi siempre son el mejor punto de partida.

7. Configura una alerta de presupuesto si todavía no la tienes

• Por qué importa: La revisión que estás haciendo ahora solo captura lo que ya ha pasado. Necesitas una señal cuando el gasto empiece a desviarse.
• Qué revisar:
  • AWS Budgets → crea un presupuesto mensual al 100 % de tu gasto esperado, con una alerta al 80 %.
  • Añade otra alerta al 120 % como señal de emergencia.
  • Asegúrate de que la alerta llega a un sitio que alguien vaya a leer de verdad (SNS → Slack, no solo email).
• Error habitual: Crear una alerta de presupuesto que envía correos a un buzón compartido que nadie vigila. Llévala a un canal de Slack que tenga un responsable.

Qué no conviene complicar de más

Hay varias trampas en las que veo caer a los equipos durante una revisión de costes:

Etiquetarlo todo antes de hacer nada más. El etiquetado es útil para tener visibilidad continua, pero en cuentas ya asentadas es un proyecto de meses. No dejes que bloquee el ahorro inmediato. Primero arregla los recursos ociosos y las instancias sobredimensionadas.

Optimizar lo que no toca. Si estás gastando 500 dólares al mes en instantáneas de EBS y 8.000 al mes en EC2, no te pases tres días afinando la retención de instantáneas antes de mirar el cómputo.

Comprar compromisos antes de entender la línea base. Reserved Instances y Savings Plans tienen sentido cuando ya entiendes qué parte del gasto es estable. Comprarlos en una cuenta que todavía no conoces bien es precipitarse: puedes acabar comprometiéndote con recursos que estás a punto de cambiar.

Convertir esto en un proyecto de plataforma. No necesitas una taxonomía de asignación de costes, una herramienta de FinOps ni un modelo de reparto interno de costes para bajar la factura. Haz la revisión, aplica los cambios y configura las alertas. Ya está.

Cierre

Si recorréis esta lista de comprobación con honestidad, la mayoría de equipos pequeños encuentran entre un 15 y un 30 % de despilfarro en la primera pasada, sobre todo por recursos ociosos, cómputo sobredimensionado y políticas de ciclo de vida que faltan.

El objetivo no es tener una factura perfecta. Es tener una factura sensata.

Si llegáis al final de esto y los costes siguen sin cuadrar, o habéis heredado una cuenta sin una propiedad clara, ahí suele merecer la pena traer una mirada externa. No para montar un programa de FinOps, sino para dedicar unos días a encontrar lo que el equipo interno no tiene tiempo de desenterrar.

Si eso os suena familiar, una revisión cloud gratuita con AstralDeploy está pensada exactamente para eso.