El interior del cálculo de tarifas de AWS - Cómo se miden la facturación por segundo, por 100ms y por solicitud
Explicamos cómo se miden, agregan y facturan las diversas granularidades de cobro de AWS, como la facturación por segundo de EC2, por 1ms de Lambda y por solicitud de S3, desde el mecanismo del sistema de metering.
La evolución de la granularidad de facturación - De por hora a por 1ms
La granularidad de facturación de AWS ha evolucionado dramáticamente desde el lanzamiento del servicio. EC2 comenzó con facturación por hora en 2006, cambió a facturación por segundo en 2017 (con un mínimo de 60 segundos). Lambda comenzó con facturación por 100ms en 2014 y migró a facturación por 1ms en 2020. Esta evolución refleja la filosofía de AWS de "cobrar solo por lo que se usa". La facturación por hora significaba que incluso si se usaba una instancia por solo 1 minuto, se cobraba 1 hora completa. La facturación por segundo eliminó este desperdicio, beneficiando especialmente a cargas de trabajo con instancias de corta duración como procesamiento por lotes, CI/CD y auto scaling. La facturación por 1ms de Lambda es particularmente significativa para funciones de ejecución corta. Una función que se ejecuta en 3ms ahora se cobra por 3ms en lugar de 100ms, una reducción del 97% en el costo de cómputo para ese tipo de funciones.
El sistema de metering - Cómo se mide el uso
Detrás de la facturación de AWS existe un sistema de metering masivo que registra el uso de cada recurso en tiempo real. Este sistema procesa billones de eventos de uso diariamente en toda la infraestructura global de AWS. Para EC2, el sistema de metering registra el momento exacto en que una instancia pasa al estado "running" y cuando se detiene, calculando la duración en segundos. Para S3, cada solicitud PUT, GET, DELETE se cuenta individualmente, y el almacenamiento se mide en GB-mes (el promedio de almacenamiento durante el mes). Para Lambda, se registra la duración de cada invocación en milisegundos y la memoria asignada, calculando GB-segundo como la unidad de facturación. El sistema de metering debe ser extremadamente preciso y resiliente. Un error en el metering podría resultar en sobrecobro o subcobro a millones de clientes. AWS utiliza múltiples capas de validación y reconciliación para garantizar la precisión.
La complejidad de las tarifas de transferencia de datos - Por qué es difícil de entender
Las tarifas de transferencia de datos de AWS son notoriamente complejas. La transferencia de datos entrantes (ingress) es gratuita, pero la transferencia saliente (egress) se cobra con tarifas que varían según el destino, el volumen y el servicio. La transferencia entre AZ dentro de la misma región tiene un costo, la transferencia entre regiones tiene otro costo mayor, y la transferencia a Internet tiene su propia estructura de precios escalonada. Además, algunos servicios incluyen transferencia de datos en su precio (como CloudFront con ciertos orígenes), mientras que otros la cobran por separado. Esta complejidad existe porque AWS opera una red global masiva con diferentes costos de infraestructura en diferentes ubicaciones. El modelo de precios refleja los costos reales de mover datos a través de la infraestructura. Para los clientes, la mejor práctica es usar VPC Endpoints para el tráfico a servicios de AWS (eliminando costos de NAT Gateway), mantener el tráfico dentro de la misma AZ cuando sea posible, y usar CloudFront para la distribución de contenido a usuarios finales.
El pipeline detrás de escena hasta que llega la factura
Desde que se genera un evento de uso hasta que aparece en la factura del cliente, los datos pasan por un pipeline de múltiples etapas. Primero, el sistema de metering captura los eventos de uso en tiempo real. Segundo, estos eventos se agregan y normalizan en un formato estándar. Tercero, se aplican las tarifas correspondientes (que pueden variar según el tipo de instancia, la región, los descuentos por volumen, los Savings Plans y las Reserved Instances). Cuarto, se generan los registros de Cost and Usage Report (CUR) con el detalle línea por línea. Quinto, se calcula el total y se genera la factura mensual. Este pipeline tiene un retraso inherente. Los datos de uso pueden tardar hasta 24 horas en aparecer en Cost Explorer, y la factura final del mes se genera varios días después del cierre del período. AWS Budgets puede enviar alertas basadas en el uso estimado, pero las alertas se basan en datos con cierto retraso.
Medidas prácticas para prevenir facturas inesperadas
Para evitar sorpresas en la facturación, se recomiendan varias prácticas. Primero, configurar AWS Budgets con alertas al 50%, 80% y 100% del presupuesto mensual esperado. Segundo, habilitar Cost Anomaly Detection para recibir alertas automáticas cuando el gasto se desvía del patrón normal. Tercero, revisar Cost Explorer semanalmente para identificar tendencias. Cuarto, usar etiquetas (tags) de asignación de costos para rastrear el gasto por proyecto, equipo o entorno. Quinto, configurar SCPs (Service Control Policies) en AWS Organizations para prevenir el lanzamiento de tipos de instancia costosos en cuentas de desarrollo. Sexto, eliminar recursos no utilizados regularmente (EBS volumes huérfanos, Elastic IPs no asociadas, snapshots antiguos). La combinación de estas prácticas crea múltiples capas de protección contra gastos inesperados.