Observabilidad y costos: la factura de AWS como documento de diseño

La factura de AWS es un documento de diseño. Cada línea nombra un recurso que existe ahora mismo, una decisión que alguien tomó alguna vez y una unidad de cobro que casi nadie eligió a conciencia. Leerla al revés —de la línea al recurso, del recurso a la decisión— te devuelve la arquitectura que tenés corriendo de verdad.

Un diagrama miente por omisión. Se dibuja una vez, se aprueba y queda desactualizado la semana siguiente. La factura cobra todo lo que existe, incluido lo que nadie recuerda haber creado.

La factura es el único diagrama de tu arquitectura que se actualiza solo, todos los días, sin que nadie lo mantenga.

Los precios de este artículo son de us-east-1 (N. Virginia), en dólares y sin impuestos, verificados a la fecha del frontmatter. AWS los mueve seguido: verificá contra la Pricing Calculator antes de decidir con plata real.

Las tres capas donde vive el dato

La consola de Billing te da el total y el desglose por servicio. Sirve para el susto, no para el diagnóstico.

Cost Explorer es la primera herramienta real. Agrupá por usage type antes que por servicio: "EC2 — Other" no dice nada, pero NatGateway-Hours contra NatGateway-Bytes te separa el costo de tener el NAT prendido del costo de pasarle tráfico. Son dos problemas distintos con dos soluciones distintas. La consola es gratis. Cada llamada a la API cuesta USD 0,01 —y la paginación cuenta por página—, así que un script que la consulta en un loop es en sí mismo una línea de factura.

La granularidad horaria y a nivel de recurso se cobra aparte, y el cargo es diario: USD 0,00000033 por usage record por día, calculado sobre los registros de los últimos 14 días. La equivalencia que publica AWS es alrededor de un centavo por cada mil registros al mes. No es un pago único por activar la opción: mientras la tengas prendida, corre todos los días.

La tercera capa es el Cost and Usage Report. Hoy se configura desde Data Exports como CUR 2.0, con un esquema fijo de columnas que no cambia mes a mes —a diferencia del CUR viejo, donde las columnas variaban según qué servicios usaste. Lo exportás a S3 en Parquet y lo consultás con Athena a USD 5 por TB escaneado; el propio export te puede entregar el CloudFormation y el SQL para crear la tabla. La columna que justifica todo el ejercicio es line_item_resource_id: es el ARN concreto que generó el cargo. Ahí termina el trabajo de detective.

select
  line_item_resource_id,
  line_item_usage_type,
  sum(line_item_unblended_cost) as costo
from cur2
where line_item_usage_start_date >= date '2026-07-01'
  and line_item_product_code = 'AmazonEC2'
group by 1, 2
order by costo desc
limit 30;

Estimar antes de construir

Toda la aritmética de la nube arranca en un número: 730. Es el promedio de horas que tiene un mes. Cualquier cosa que se cobre por hora, multiplicala por 730 y ya sabés el piso mensual sin tráfico.

Esa tabla ya es una decisión de arquitectura. Un NAT gateway por AZ para alta disponibilidad son USD 65,70 mensuales antes del primer byte.

La Pricing Calculator sirve para la estimación formal, la que va al presupuesto anual. Para el día a día, Infracost es más útil porque corre sobre el terraform plan dentro del pipeline y te dice el delta mensual de un pull request antes de mergearlo.

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > plan.json
infracost breakdown --path plan.json --format table

El costo pasa a ser parte del code review. Un PR que agrega un NAT gateway deja de ser "un recurso más" y pasa a ser "USD 32,85 al mes", que es una conversación distinta.

Con esa invocación sola, Infracost estima únicamente lo que se cobra por existir: la hora del NAT, la hora del ALB, el GB-mes del volumen. Todo lo que se cobra por uso —invocaciones de Lambda, GB procesados por el NAT, requests a S3, GB ingeridos por CloudWatch— sale de un archivo de supuestos que escribís vos.

# infracost-usage.yml
version: 0.1
resource_usage:
  aws_lambda_function.conciliacion:
    monthly_requests: 12000000
    request_duration_ms: 180
  aws_nat_gateway.egress_prod:
    monthly_data_processed_gb: 900
  aws_cloudwatch_log_group.api:
    monthly_data_ingested_gb: 300
    storage_gb: 900
    monthly_data_scanned_gb: 40

infracost breakdown --path plan.json --usage-file infracost-usage.yml

Ese archivo es el documento de presupuesto real del sistema. Cada línea es una hipótesis escrita en un número, y cada hipótesis es verificable contra la factura del primer mes. Si pusiste 900 GB por el NAT y la línea NatGateway-Bytes dice 3.100, no fallaron los precios: falló el modelo de tráfico, y ahora sabés dónde.

El punto de cruce del tráfico privado

Sacar tráfico de una subred privada hacia un servicio de AWS tiene tres caminos con tres estructuras de cobro distintas, y la elección entre ellos es aritmética.

El gateway endpoint es la decisión trivial: no cobra hora ni GB, así que cualquier volumen de tráfico a S3 o DynamoDB que hoy pase por el NAT está pagando USD 0,045 por GB de más. Si S3 era la única razón por la que existe ese NAT, el rediseño se lleva además los USD 32,85 por AZ.

El interface endpoint sí tiene punto de cruce. Contra un NAT que ya existe por otros motivos, el ahorro es de USD 0,035 por GB y el costo fijo es de USD 7,30 por AZ. En una VPC de dos AZ eso son USD 14,60 mensuales, que se recuperan a partir de unos 420 GB por mes hacia ese servicio. Por debajo de ese volumen la diferencia es de centavos y la decisión se toma por aislamiento de red, no por costo.

La topología y el presupuesto son la misma conversación. Lo que cambia es qué columna mirás primero.

Tagging: la contabilidad se decide al crear el recurso

Sin tags, la factura te dice cuánto gastaste. Con tags, te dice quién. Esa es toda la diferencia entre un número y una decisión.

El detalle que importa es cuándo hay que poner el tag. Los cost allocation tags se activan en la consola de Billing, tardan hasta 24 horas en aparecer para activación y hasta otras 24 en activarse. Desde marzo de 2024 se pueden aplicar retroactivamente hasta 12 meses con el backfill —StartCostAllocationTagBackfill, una sola solicitud cada 24 horas—, pero el backfill solo funciona si el tag ya estaba puesto sobre el recurso en ese período. La activación se arregla después; el tag en el recurso, no.

Por eso el tagging se implementa en el provider, no a mano:

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Project     = "pagos"
      Environment = "prod"
      Owner       = "plataforma"
      CostCenter  = "cc-1042"
      ManagedBy   = "terraform"
    }
  }
}

Cinco claves alcanzan y sobran. Environment separa prod de lo que se puede apagar, Owner da a quién escribirle, CostCenter conecta con la contabilidad de la empresa y ManagedBy delata lo que se creó a mano en la consola —que es, casi siempre, lo que después nadie borra.

Sobre eso hay dos mecanismos de gobierno que suenan parecido y hacen cosas distintas. Una tag policy de Organizations define el vocabulario: qué claves son obligatorias, con qué capitalización y con qué valores permitidos, y reporta el incumplimiento en el informe de la organización. Una SCP con condición sobre aws:RequestTag deniega la llamada de creación cuando el tag no viene. La tag policy avisa; la SCP frena.

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

AWS Config con la regla required-tags cubre el tercer caso: lo que ya existe y se creó antes de que hubiera política.

Los tres horizontes del lag

Los mecanismos de control de costo no se acumulan por redundancia. Cada uno mira una ventana de tiempo distinta, y ninguno cubre la del otro.

La métrica sabe que algo cambió pero no sabe cuánto cuesta. La factura sabe cuánto cuesta pero llega un día tarde. Budgets queda en el medio y por eso es el que dispara el aviso a una persona. Entre el minuto y el día hay una diferencia de tres órdenes de magnitud en la cuenta de un incidente de tráfico: un NAT procesando de más cuesta USD 0,045 por GB desde el primer minuto, y nadie va a mirar Cost Explorer a las tres de la mañana.

Contra eso, la alarma más barata de todo el artículo es una sobre BytesOutToDestination del NAT gateway: USD 0,10 al mes, y avisa el mismo día.

Poner límites antes de necesitarlos

AWS Budgets es gratis mientras solo notifique. Los budgets con acciones tienen los primeros dos sin cargo y después USD 0,10 por día cada uno; cada reporte entregado cuesta USD 0,01.

Tres capas cubren casi todo:

Un budget mensual global con dos alertas —una al 80% del gasto real y otra al 100% del forecast—. La del forecast es la que avisa temprano, porque dispara cuando la proyección cruza el umbral, no cuando ya lo cruzaste.

Un budget por tag Owner o CostCenter, para que la alerta llegue al equipo que puede hacer algo, no a una casilla compartida.

Cost Anomaly Detection encima de todo. Es gratis, entrena un baseline con tu propio historial y analiza los datos hasta tres veces por día. Detecta lo que ningún umbral fijo detecta: el servicio que pasó de USD 4 a USD 400 mientras el total mensual sigue dentro del presupuesto.

En cuentas de sandbox conviene ir un paso más: un budget con acción que adjunta una policy de deny cuando se cruza el techo. Budgets notifica por defecto; frenar es una configuración explícita.

La observabilidad también está en la factura

CloudWatch es un servicio de monitoreo que se cobra como cualquier otro, y su factura crece por el mismo mecanismo que la hace útil: cardinalidad.

Una métrica custom en CloudWatch es la combinación única de namespace, nombre y valores de dimensiones. Cada combinación cuenta como una métrica separada. Agregar una dimensión customer_id a una sola métrica en una base de 5.000 clientes no genera una métrica: genera 5.000, que son USD 1.500 por mes. Si esa métrica ya tenía una dimensión endpoint con tres valores, las dimensiones se multiplican entre sí y son 15.000 series, que cruzan el primer tier y terminan en USD 3.500 mensuales por una línea de código que parecía inocente.

El resto del servicio se lee de la misma tabla.

Dos filas de esa tabla se leen mal si se leen rápido. El millón de requests gratis aplica a PutMetricData y no cubre GetMetricData, GetMetricWidgetImage ni GetInsightRuleReport: esas tres se cobran desde la primera llamada. Ese es el motivo exacto por el cual un dashboard de terceros que hace polling cada quince segundos aparece en la factura sin que nadie haya creado un recurso nuevo. Y el storage de logs se factura sobre el dato comprimido, mientras que la ingesta se cobra sobre el dato crudo: proyectar la acumulación multiplicando GB ingeridos por USD 0,03 da un número más alto que el real, y presentarlo así a finanzas te quema el argumento.

La forma barata de publicar métricas es Embedded Metric Format, que mete las métricas dentro del log y evita la llamada por punto. Logs Insights cobra por GB escaneado, no por consulta: una query mal acotada sobre 200 GB cuesta USD 1, así que el problema no es el peso de una query sino el tiempo que tarda en volver y la cantidad de queries que el equipo repite durante un incidente. La disciplina de acotar el rango es de latencia, y el ahorro viene de regalo.

Standard contra Infrequent Access

La clase del log group cambia una sola tarifa, y esa asimetría es la parte que más se confunde.

La clase IA cuesta la mitad solo en ingesta. El storage y las queries valen exactamente lo mismo en las dos. Y la clase se define al crear el log group y no se puede cambiar después, así que no es una tarea de mantenimiento que alguien va a hacer el trimestre que viene: es un atributo del recurso en Terraform, y llega tarde el día que el log group ya existe.

El criterio práctico es qué hacés con esos logs. Un log de debug que solo se abre cuando hay incidente va a IA. Un log del que salen metric filters o que alimenta un subscription filter hacia otro sistema va a Standard, porque en IA esas features no existen.

La retención por defecto y la de las métricas

Un log group nuevo se crea con retención Never Expire. Esos GB se acumulan a USD 0,03 el GB-mes comprimido para siempre, sobre datos que en la práctica nadie consulta después de la primera semana.

Vale la pena contrastarlo con la retención de las métricas, que CloudWatch define sola: los data points de 1 minuto duran 15 días, los de 5 minutos 63 días y los de 1 hora 455 días. Guardar logs crudos por dos años cuando la métrica agregada ya se resumió sola es pagar por un detalle que no vas a poder correlacionar con nada.

La alarma como máquina de estados

Una alarma de CloudWatch tiene tres estados: OK, ALARM e INSUFFICIENT_DATA. El tercero es el que rompe guardias, porque una alarma que nunca sale de ahí se ve igual que una alarma sana en la lista.

El caso típico: alarma con período de 60 segundos sobre CPUUtilization de una instancia EC2 en basic monitoring. Basic monitoring publica cada 5 minutos, así que cuatro de cada cinco períodos no tienen ningún data point. La alarma pasa la vida en INSUFFICIENT_DATA y no dispara nunca. No hay error de configuración visible: el período es válido, la métrica existe, la instancia está corriendo.

Hay dos salidas y las dos cuestan. Poner el período en 300 segundos alinea la alarma con la frecuencia de publicación y no cuesta nada, a costa de detectar hasta cinco minutos más tarde. Activar detailed monitoring lleva la publicación a 1 minuto por USD 2,10 por instancia-mes. Elegí en función de cuánto tarda tu autoscaling en reaccionar; si el grupo tarda tres minutos en levantar una instancia, medir cada cinco no sirve.

El tercer parámetro es TreatMissingData. Por defecto los períodos sin datos se ignoran, lo cual está bien para una métrica que solo se publica cuando hay actividad y está mal para una que debería publicarse siempre. Una alarma de "dejaron de llegar transacciones" necesita breaching, no el default.

El checklist de fugas

Estos cinco patrones son los que aparecen en cualquier cuenta que lleve más de un año viva. Todos se detectan con la CLI en CloudShell, sin instalar nada.

Volúmenes EBS huérfanos. Terminar una instancia no borra siempre su volumen: si DeleteOnTermination estaba en false, el disco queda en estado available cobrando GB-mes.

aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].{id:VolumeId,gb:Size,az:AvailabilityZone,creado:CreateTime}' \
  --output table

IPs elásticas sin asociar. Desde febrero de 2024 toda IPv4 pública se cobra USD 0,005 la hora esté en uso o no, así que la EIP olvidada ya no es gratis.

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table

Snapshots viejos. Son incrementales, pero se acumulan: una política de backup diaria sin expiración deja cientos. El snapshot archive tier baja a USD 0,0125 por GB-mes con mínimo de 90 días de retención, y sirve para lo que hay que conservar por compliance pero no se va a restaurar.

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-08-01`].[SnapshotId,VolumeSize,StartTime]' \
  --output table

NAT gateways olvidados. USD 32,85 al mes cada uno más el tráfico, típicamente en la VPC de un ambiente que se dejó de usar.

aws ec2 describe-nat-gateways --filter Name=state,Values=available \
  --query 'NatGateways[].[NatGatewayId,VpcId,SubnetId]' --output table

Log groups sin retención. El que más crece con el tiempo y el único de los cinco que se arregla con un comando en vez de con una decisión.

aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].[logGroupName,storedBytes]' --output table

La remediación es la misma consulta encadenada a put-retention-policy. Antes de correrla, mirá la lista: hay log groups de auditoría que tienen que quedarse.

aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].logGroupName' --output text \
| tr '\t' '\n' \
| xargs -I{} aws logs put-retention-policy --log-group-name {} --retention-in-days 30

En el momento en que la retención queda aplicada, los eventos que la superan dejan de facturar storage. El borrado físico puede tardar hasta 72 horas, así que storedBytes sigue mostrando el número viejo por un par de días. Eso confunde a cualquiera que revise al día siguiente y concluya que el comando no funcionó.

Para hacer esto sobre varias cuentas y regiones a la vez, Steampipe expone AWS como tablas SQL y convierte el barrido en una query. Conviene que devuelva dólares y no gigabytes: un reporte en dólares se pega en el canal del equipo y se entiende sin conversión.

select
  account_id,
  region,
  volume_id,
  size as gb,
  round((size * 0.08)::numeric, 2) as usd_mes,
  create_time
from aws_ebs_volume
where state = 'available'
order by usd_mes desc;

En cuentas de sandbox, aws-nuke borra todo lo que no esté en una lista de excepciones. Es una herramienta con filo: se configura con el account ID explícito justamente para que sea difícil apuntarla a producción por accidente.

Ahora bien, los cinco patrones son recursos olvidados, y ese es el tipo de fuga barata de encontrar. La cara le suele salir por otro lado. CrescoNet publicó su caso con AWS: sobre una plataforma de 4.500 millones de lecturas de medidores por día, bajó más de 40% la factura y el grueso vino de patrones de acceso, no de recursos huérfanos —27 veces menos costo de requests en S3 al compactar archivos chicos con Apache Iceberg, 66% menos storage en DynamoDB con TTL, 20 veces menos en SQS con batching. Ninguna de esas cinco líneas de CLI habría encontrado nada de eso.

Cuándo sí, cuándo no y qué se rompe

Cada renglón de gasto compra algo. La pregunta útil no es cuánto cuesta sino qué perdés cuando lo sacás.

Las herramientas

Todas gratis, y ninguna reemplaza a la otra porque cada una mira una etapa distinta del ciclo.

Compute Optimizer y Trusted Advisor completan el cuadro desde adentro de la consola. Compute Optimizer es gratis y necesita 14 días de historial para recomendar rightsizing; los checks de costo de Trusted Advisor requieren plan de soporte Business o superior.

El ritual

Semanal: abrir Cost Explorer agrupado por usage type sobre los últimos 14 días y mirar solo lo que cambió de pendiente. Mensual: correr el checklist de fugas y revisar las recomendaciones de Compute Optimizer y de Trusted Advisor. Trimestral: revisar la cobertura de Savings Plans y reserved instances contra el uso que ya demostraste sostener durante un año.

Todo esto es lectura de arquitectura con unidades monetarias. El día que la factura muestra USD 200 mensuales de NAT gateway en un ambiente de staging, lo que estás leyendo es un plano: staging tiene subredes privadas con salida a internet que nadie diseñó, alguien copió el módulo de prod y el pipeline de imágenes está bajando containers por el camino caro. La línea de la factura fue el síntoma. El diseño era el problema — y estaba escrito ahí, en dólares, todos los meses, esperando que alguien lo leyera.