Plantilla de Estimación de Costos Serverless

Resumen

Nadie recibe una factura sorpresa de AWS porque Lambda sea caro. La recibe porque nunca hizo los números. Esta plantilla te da una forma repetible de estimar el costo de un workload serverless antes de desplegarlo, y de contrastar la estimación con la factura real cada mes. Ejecútala junto a la checklist de deployment de funciones serverless para que el costo entre en la misma revisión que los criterios de lanzamiento.

La facturación serverless tiene cuatro piezas móviles: invocaciones, duración de ejecución, memoria asignada y transferencia de datos. Cada proveedor las pondera distinto, y cada uno esconde un segundo nivel de cargos (logs, tracing, requests de colas, NAT) que no aparece en el precio de portada. Una estimación que solo cubre invocaciones y GB-segundos queda 20-40% por debajo de la realidad en un workload real.

---

1. Referencia del Modelo de Precios

Los precios de abajo corresponden a us-east-1 / regiones equivalentes a mediados de 2026. Verifícalos en las páginas oficiales antes de presentar una estimación a finanzas: los proveedores ajustan estos números sin avisar.

1.1 Precios de AWS Lambda

Componente	Nivel gratuito	Precio tras nivel gratuito
Requests	1M/mes gratis	$0.20 por 1M requests
Cómputo (GB-segundo)	400K/mes gratis	$0.0000166667 por GB-segundo (x86) / $0.0000133334 (arm64)
PC capacidad (GB-seg.)	Ninguno	$0.0000041667 por GB-segundo (x86)
PC duración (GB-seg.)	Ninguno	$0.0000097222 por GB-segundo (x86)
Transferencia (entrada)	Siempre gratis	$0.00 por GB
Transferencia (salida)	100GB/mes gratis	$0.09 por GB

La concurrencia provisionada no tiene nivel gratuito: una vez habilitada, los requests y la duración de la función se facturan a tarifa completa, y la capacidad reservada se factura las 24 horas aunque no atienda tráfico.

1.2 Precios de Azure Functions

Componente	Nivel gratuito	Precio tras nivel gratuito
Ejecuciones	1M/mes gratis	$0.20 por 1M ejecuciones
GB-segundos	400K/mes gratis	$0.000016 por GB-segundo
Plan Premium (vCPU)	Ninguno	$0.192/hora por vCPU
Plan Premium (memoria)	Ninguno	$0.0139/hora por GB

1.3 Precios de GCP Cloud Functions (gen2)

Las funciones gen2 facturan con el modelo de Cloud Run: vCPU-segundos y GiB-segundos, en lugar del antiguo pricing por GHz-segundo de gen1.

Componente	Nivel gratuito	Precio tras nivel gratuito
Invocaciones	2M/mes gratis	$0.40 por 1M invocaciones
vCPU-segundos	180K/mes gratis	$0.0000240 por vCPU-segundo
GiB-segundos	360K/mes gratis	$0.0000025 por GiB-segundo
Transferencia (salida)	1GB/mes gratis	$0.12 por GB (premium tier)

---

2. Fórmula de Cálculo de Costos

2.1 Costo de Cómputo de Lambda

Costo mensual de cómputo = (invocaciones × duración_segundos × memoria_GB) × precio_por_GB_segundo

Ejemplo:
  Invocaciones: 10M/mes
  Duración: 200ms promedio (0.2 segundos)
  Memoria: 512MB (0.5 GB)

  GB-segundos = 10,000,000 × 0.2 × 0.5 = 1,000,000 GB-segundos
  Facturable = 1,000,000 - 400,000 nivel gratuito = 600,000 GB-segundos
  Costo = 600,000 × $0.0000166667 = $10.00/mes

El nivel gratuito es por cuenta, no por función. Al estimar varias funciones, descuéntalo una sola vez contra el workload mayor (o sáltalo para un número conservador); restar 400K GB-segundos a cada función subestima la factura.

2.2 Costo por Request de Lambda

Costo mensual por requests = (invocaciones - nivel_gratuito) × precio_por_millón / 1,000,000

Ejemplo:
  Invocaciones: 10M/mes
  Nivel gratuito: 1M

  Facturable = 10,000,000 - 1,000,000 = 9,000,000
  Costo = 9 × $0.20 = $1.80/mes

2.3 Costo Total de Lambda

def estimate_lambda_cost(
    invocations: int,
    avg_duration_ms: float,
    memory_mb: int,
    provisioned_concurrency_gb_seconds: int = 0,
    data_transfer_out_gb: float = 0,
) -> dict:
    """Estima el costo mensual de AWS Lambda."""

    duration_s = avg_duration_ms / 1000
    memory_gb = memory_mb / 1024
    gb_seconds = invocations * duration_s * memory_gb

    # Con concurrencia provisionada el nivel gratuito no aplica
    # y la duración factura a la tarifa PC, más baja.
    has_pc = provisioned_concurrency_gb_seconds > 0
    duration_rate = 0.0000097222 if has_pc else 0.0000166667
    free_gb_seconds = 0 if has_pc else 400_000
    free_requests = 0 if has_pc else 1_000_000

    compute_cost = max(gb_seconds - free_gb_seconds, 0) * duration_rate
    request_cost = (max(invocations - free_requests, 0) / 1_000_000) * 0.20

    # Capacidad de concurrencia provisionada: se factura 24/7 por lo configurado
    pc_cost = provisioned_concurrency_gb_seconds * 0.0000041667

    # Costo de transferencia de datos
    free_tier_data = 100
    billable_data = max(data_transfer_out_gb - free_tier_data, 0)
    data_cost = billable_data * 0.09

    total = compute_cost + request_cost + pc_cost + data_cost

    return {
        "compute_cost": round(compute_cost, 2),
        "request_cost": round(request_cost, 2),
        "provisioned_concurrency_cost": round(pc_cost, 2),
        "data_transfer_cost": round(data_cost, 2),
        "total_monthly_cost": round(total, 2),
        "gb_seconds": int(gb_seconds),
    }

# Ejemplo de uso
cost = estimate_lambda_cost(
    invocations=10_000_000,
    avg_duration_ms=200,
    memory_mb=512,
)
print(f"Costo mensual total: ${cost['total_monthly_cost']}")

---

3. Plantilla de Estimación por Workload

3.1 Estimación por Función

Función: processOrder
──────────────────────────────────────────────────
Métrica                 | Valor          | Fuente
────────────────────────┼────────────────┼──────────────────
Invocaciones esperadas | 10M/mes        | Forecast de tráfico
Duración promedio      | 200ms          | Pruebas de carga
Memoria asignada       | 512MB          | Power Tuning
Duración p99           | 500ms          | Pruebas de carga
Transferencia saliente | 5GB/mes        | Tamaño de payload × invocaciones
Concurrencia provisionada| 10 concurrentes| Requisito de latencia

Costo mensual estimado (con PC: sin nivel gratuito, tarifa de duración PC):
  Cómputo:   $9.72   (1,000,000 GB-s × $0.0000097222)
  Requests:  $2.00   (10M × $0.20/1M, sin nivel gratuito con PC)
  PC:        $54.00  (10 × 0.5GB × 30 días × 24h × 3600s × $0.0000041667)
  Datos:     $0.00   (bajo el nivel gratuito de 100GB)
  Total:     $65.72/mes

La misma función sin concurrencia provisionada: $10.00 de cómputo + $1.80 de requests = $11.80/mes. La garantía de latencia cuesta $54/mes solo en capacidad reservada, y ese número tiene que estar en la estimación para que el trade-off sea explícito.

3.2 Estimación Multi-Función

workloads = [
    {"name": "processOrder", "invocations": 10_000_000, "duration_ms": 200, "memory_mb": 512},
    {"name": "sendEmail", "invocations": 5_000_000, "duration_ms": 100, "memory_mb": 256},
    {"name": "generateReport", "invocations": 100_000, "duration_ms": 5000, "memory_mb": 2048},
    {"name": "webhookHandler", "invocations": 50_000_000, "duration_ms": 50, "memory_mb": 128},
]

total_cost = 0
for w in workloads:
    cost = estimate_lambda_cost(w["invocations"], w["duration_ms"], w["memory_mb"])
    print(f"{w['name']}: ${cost['total_monthly_cost']}/mes")
    total_cost += cost["total_monthly_cost"]

print(f"\nCosto mensual total: ${total_cost:.2f}")

3.3 Ejemplo de Workload Event-Driven

No todos los workloads están dominados por invocaciones. Un pipeline event-driven disparado por eventos de S3 muestra un perfil de costo distinto, donde la capa de orquestación pesa más que el cómputo:

Métrica	Valor	Fuente
Eventos de S3	500K/mes	Forecast de tráfico
Invocaciones Lambda	500K/mes (una por evento)	Mapeo del trigger
Duración media	3s	Pruebas de carga
Memoria	1024MB	Power Tuning
Transiciones de Step Functions	6 por documento	Definición del workflow
Mensajes SQS	500K/mes, en batches de 10	Buffer antes de procesar

Cómputo Lambda:    500K × 3s × 1GB = 1.5M GB-s − 400K nivel gratuito = 1.1M × $0.0000166667 = $18.33
Requests Lambda:   500K (bajo el nivel gratuito de 1M)                                        = $0.00
Step Functions:    500K docs × 6 transiciones = 3M transiciones × $0.025/1K                   = $75.00
Requests SQS:      50K batches × ~3 llamadas API = 150K requests × $0.40/1M                   = $0.06
Total: ≈ $93.40/mes

Step Functions cuesta 4x el cómputo de Lambda aquí. Una estimación que solo pusiera precio a la función reportaría $18/mes y fallaría en el 80% de la factura. Rellena la tabla de costos ocultos de la sección 4 antes de fiarte de la matemática de la función.

---

4. Costos Ocultos

Los cargos de abajo suelen representar un tercio de la factura serverless. Estímalos explícitamente. Una función “barata” con logging verboso puede costar más en ingesta de CloudWatch que en cómputo.

4.1 Costos de API Gateway

Componente	Nivel gratuito	Precio
Requests (HTTP API)	300M/mes	$1.00 por 1M
Requests (REST API)	1M/mes (12m)	$3.50 por 1M
Transferencia saliente	100GB/mes	$0.09 por GB
Conexiones WebSocket	1M/mes (12m)	$0.80 por 1M

4.2 Costos de Step Functions

Tipo	Nivel gratuito	Precio
Workflow Standard	4K/mes (12m)	$0.025 por 1,000 transiciones
Workflow Express	4K/mes (12m)	$1.00 por 1M invocaciones + $0.03 por 1K GB-segundos

4.3 Costos Ocultos Frecuentes

Costo oculto	Impacto	Mitigación
Ingesta de CloudWatch Logs	$0.50 por GB	Retención de logs, sampling
Storage de CloudWatch Logs	$0.03 por GB	TTL en los log groups
X-Ray tracing	$0.50 por 1M	Muestrear trazas (no 100%)
Requests de SQS	$0.40 por 1M	Agrupar mensajes en batches
Requests PUT/GET de S3	$0.005 por 1K	Agrupar operaciones de S3
Secrets Manager	$0.40 por secreto	Usar SSM Parameter Store (gratis)
Unidades R/W de DynamoDB	Por request	Usar capacidad on-demand
NAT Gateway	$0.045 por GB	VPC endpoints donde se pueda

---

5. Estrategias de Optimización de Costos

5.1 Ajuste de Memoria

Memoria	Cuota de CPU	Costo por 1M invocaciones (200ms)
128MB	1/10 vCPU	$0.21
256MB	1/5 vCPU	$0.43
512MB	2/5 vCPU	$0.85
1024MB	1 vCPU	$1.71
2048MB	2 vCPU	$3.41

El óptimo es la memoria donde costo × duración sea mínimo: más memoria significa ejecución más rápida y menos GB-segundos por invocación.

La configuración más barata en papel rara vez es la más barata en producción. Una función de 128MB que tarda 2 segundos suele costar más que una de 1GB que termina en 300ms. Ejecuta AWS Lambda Power Tuning con payloads reales antes de fijar la estimación.

5.2 Checklist de Optimización

• Perfilar la memoria con AWS Lambda Power Tuning usando payloads reales, no sintéticos
• Reservar la concurrencia provisionada para las pocas funciones con SLA de latencia estricto
• Agrupar mensajes de SQS en batches para reducir el conteo de invocaciones
• Filtrar eventos en EventBridge para que los handlers no disparen con ruido
• Limitar la retención de logs a 7-30 días y quitar DEBUG en producción
• Mover la config no-secreta a SSM Parameter Store en lugar de Secrets Manager
• Añadir VPC endpoints donde el egress de NAT Gateway sea el driver de costo
• Quitar dev dependencies y fixtures de test del paquete de despliegue
• Compartir dependencias comunes mediante Lambda Layers
• Conciliar la estimación con Cost Explorer cada mes

Adopción de la Plantilla

• Estima antes del primer deploy, no después de la primera factura. Corre los números en la design review para que el costo sea un input de las decisiones de arquitectura (tamaño de memoria, sync vs async, polling vs eventos) y no una sorpresa.
• Aliméntala con datos reales. Los forecasts de tráfico y las duraciones de load tests ganan a las suposiciones. Si no tienes ninguno, modela tres escenarios (esperado, 3x, 10x) y presupuesta por el del medio.
• Concilia mensualmente. Saca el costo real por función de Cost Explorer, compáralo con la estimación y actualiza los inputs cuando el desvío supere ~15%. La plantilla solo se mantiene honesta si alguien es dueño de ese ciclo. La guía de optimización de costos cloud cubre el etiquetado y chargeback que hace posible los números reales por función.
• Versiona la estimación junto al código. Incluye la plantilla rellenada en el mismo commit que la definición de infraestructura, para que las suposiciones de costo se vean en review y los números obsoletos salten en los diffs.

Archivos complementarios: el repo companion de serverless-cost-estimation-template tiene esta hoja de estimación como archivo Markdown independiente más una calculadora estimate-costs.py que estima una función por flags CLI o una lista completa de workloads desde JSON, con tarifas x86 y arm64.

Validar la Estimación

Una estimación que nadie revisa se convierte en ficción en un trimestre. Mantén el ciclo lo bastante pequeño para que alguien lo ejecute de verdad:

1. Saca los números reales por función. En Cost Explorer, filtra por servicio y agrupa por recurso. Solo funciona si las funciones llevan tags de cost-allocation: habilítalos antes del lanzamiento o los números por función serán estimaciones por sí mismos.
2. Calcula el desvío. desvío = (real − estimación) / estimación. Dentro de ±15% el modelo está bien; más allá, busca qué input se movió.
3. Localiza la brecha. Si el cómputo se desvió, se movieron las invocaciones o la duración: compara p50/p99 en CloudWatch contra los números del load test. Si la brecha está fuera de Lambda, la tabla de costos ocultos de la sección 4 es el lugar donde mirar.
4. Actualiza inputs, no la tarifa. Los precios del proveedor rara vez se mueven a mitad de trimestre; tu forma de tráfico sí. Corrige primero el forecast y luego los precios unitarios.
5. Registra cada ronda. El log de validación de la hoja guarda cada comparación mensual, así la siguiente estimación arranca de inputs medidos y no de la suposición original.

Ejemplo trabajado: la plantilla estimó $65.72/mes para processOrder; la factura muestra $84.10 (+28% de desvío). CloudWatch muestra que la duración p99 se duplicó tras la lentitud de una API downstream. Actualiza el input de duración, re-ejecuta la calculadora y la nueva estimación cae dentro del 5% de la siguiente factura. El modelo estaba bien; el input quedó obsoleto.

Solución de Problemas

• La factura real supera la estimación en 30%+: revisa primero la tabla de costos ocultos. La ingesta de CloudWatch Logs y el egress de NAT Gateway son los sospechosos habituales, seguidos de tormentas de reintentos que multiplican invocaciones.
• La estimación se desvía cada mes: tus inputs quedaron obsoletos. El tráfico crece, las duraciones suben a medida que los payloads engordan y los niveles gratuitos se consumen con servicios nuevos. Re-ejecuta load tests trimestralmente y refresca los números.
• El costo real de una función no coincide con el calculado: probablemente la duración está sesgada. Mira p50 vs p99: una función que promedia 200ms pero pica a 5s en cold starts o timeouts downstream factura muchos más GB-segundos de lo que sugiere el promedio.
• La concurrencia provisionada cuesta más de lo esperado: se factura las 24 horas, no por invocación. Diez unidades de PC en una función de 512MB son ~$54/mes en capacidad reservada aunque la función nunca se ejecute, y el nivel gratuito deja de aplicar a esa función por completo. Audita las asignaciones de PC mensualmente.
• Pico de costo sin cambio de tráfico: busca bucles de reintento, una expresión cron que dispara más seguido de lo previsto, o un event source mapping que re-dispara ante fallos parciales de batch.
• La estimación era correcta pero la factura igual sorprende: estimaste la función, no el sistema. Añade API Gateway, transiciones de Step Functions, costos por request de DynamoDB/S3 y transferencia cross-AZ al modelo.

Véase También

• Runbook de Cold Start Serverless
• AWS Lambda en Producción
• Guía: Optimización de Costos Cloud
• Minimizar la Latencia de Cold Start en Funciones Serverless
• Construir Arquitecturas Serverless Event-Driven

Referencias

• Precios de AWS Lambda: tarifas oficiales por GB-segundo y por request
• Precios de Azure Functions: tarifas de planes consumption y premium
• Precios de Cloud Functions: modelos gen1 (GHz-segundo) y gen2 (vCPU/GiB-segundo)
• AWS Cost Anomaly Detection: alertas ante gasto inesperado