Optimización de Costos de AWS Lambda: Guía Práctica para 2026
Cómo reducir hasta un 40% la factura de AWS Lambda en 2026: migración a ARM/Graviton2, ajuste de memoria con Power Tuning, SnapStart, Savings Plans y control de CloudWatch Logs.
Para optimizar los costos de AWS Lambda en 2026 hay que actuar sobre tres palancas concretas: migrar las funciones a arquitectura ARM/Graviton2 (ahorro inmediato del 20 %), ajustar la memoria con AWS Lambda Power Tuning (típicamente reduce el gasto entre 15 % y 60 % sin tocar el código) y comprar un Compute Savings Plan cuando el consumo mensual estable supere aproximadamente 500 USD. Aplicando estas tres medidas más una limpieza agresiva de CloudWatch Logs he reducido facturas Lambda de siete cifras entre un 35 % y un 50 % en tres o cuatro sprints.
Lambda cobra por número de solicitudes (0,20 USD por millón) más duración facturada en GB-segundo, con precios escalonados a partir de diciembre de 2024.
La arquitectura ARM/Graviton2 cuesta un 20 % menos por GB-segundo que x86 y suele ejecutar el mismo código con igual o mejor rendimiento.
La memoria escala CPU proporcionalmente: menos memoria no siempre es más barato. AWS Lambda Power Tuning encuentra el punto óptimo entre coste y latencia.
SnapStart elimina hasta el 90 % del arranque en frío en Java, Python 3.12+ y .NET 8 sin coste adicional por invocación, solo se paga el almacenamiento del snapshot.
Los Compute Savings Plans cubren Lambda, EC2 y Fargate simultáneamente y ofrecen hasta un 17 % de descuento con compromiso de 1 año sin pago inicial.
Los CloudWatch Logs suelen representar entre el 15 % y el 40 % del gasto total de una carga Lambda; retención por defecto y filtros de log level son la primera limpieza.
Cómo funciona el precio de AWS Lambda en 2026
Antes de optimizar hay que entender la factura. AWS Lambda se cobra por dos componentes: solicitudes y duración. En la región us-east-1 el precio actual es 0,20 USD por cada millón de solicitudes y 0,0000166667 USD por GB-segundo en arquitectura x86 (Intel/AMD), o 0,0000133334 USD por GB-segundo en ARM/Graviton2. Además, cualquier memoria por encima de 512 MB de almacenamiento efímero (/tmp) suma 0,0000000308 USD por GB-segundo.
Desde diciembre de 2024 AWS introdujo precios escalonados por volumen: los primeros 6 000 millones de GB-segundo mensuales se facturan al precio estándar, entre 6 y 15 mil millones baja alrededor de un 20 %, y a partir de ahí el descuento supera el 30 %. Si tu carga es masiva (colas SQS con millones de mensajes al día, streams de Kinesis, etc.), revisa la factura porque el descuento aplica de forma automática. Aun así, sirve para dimensionar cuánto realmente ahorras al reducir invocaciones.
La duración se factura en incrementos de 1 milisegundo con un mínimo de 1 ms por invocación. Esto significa que una función que tarda 3 ms cuesta prácticamente lo mismo en tiempo de cómputo que una de 1 ms, pero pagas GB-segundo escalados por la memoria asignada. Consulta la tabla oficial de precios de AWS Lambda por región antes de hacer proyecciones: us-east-1 es referencia, pero en Sao Paulo o Tokio los GB-segundo pueden costar un 20 % más.
Cambia a ARM/Graviton2 y ahorra 20 % de forma inmediata
Honestamente, migrar una función Lambda de x86 a arquitectura ARM/Graviton2 es la palanca de mayor retorno con menor esfuerzo que existe hoy en AWS. El precio por GB-segundo baja de 0,0000166667 USD a 0,0000133334 USD, lo que equivale a un 20 % menos en la línea de duración. Si tus funciones usan runtimes gestionados (Node.js, Python, Ruby, Java, .NET, Go), el cambio suele ser tan simple como poner Architectures: [arm64] en la plantilla de despliegue. En Node.js y Python puros he portado cientos de funciones sin tocar una línea de código.
El caso incómodo son las dependencias nativas compiladas: bibliotecas como sharp (procesamiento de imágenes), lxml o binarios propietarios necesitan compilarse para arm64. Con SAM CLI y contenedores multi-arquitectura lo resuelves en el pipeline. Otro caso a validar: la latencia. Graviton2 suele ejecutar código Python/Node más rápido en un 15-25 %, lo que se traduce en menos GB-segundo facturados y ahorros compuestos con los ya del 20 % del precio.
Este es el error que veo en el 80 % de las cuentas: memoria asignada por "instinto" o dejada en el valor por defecto de 128 MB. Lambda escala la CPU de forma proporcional a la memoria: una función con 1024 MB dispone del doble de vCPU que una de 512 MB. Por eso, subir la memoria a menudo reduce el coste total porque la función termina en menos de la mitad del tiempo. He visto funciones que a 512 MB tardaban 3200 ms y a 1536 MB tardaban 900 ms. El resultado neto era un 40 % menos de gasto.
La herramienta oficial para encontrar el punto óptimo es AWS Lambda Power Tuning, una máquina de estados en Step Functions que ejecuta tu función con distintos valores de memoria (128, 256, 512, 1024, 1536, 3008 MB) y devuelve el punto óptimo por coste, por velocidad o balance. Instálala desde el Serverless Application Repository y ejecútala así:
El parámetro strategy acepta cost, speed o balanced. Para APIs con SLA de latencia usa balanced; para procesamiento asíncrono en background usa cost. Ejecuta la tuner cada 6 meses o cuando cambies el runtime. En mi equipo lo disparamos automáticamente desde el pipeline de CI cuando una función se despliega con cambios significativos en el package.json o requirements.txt.
SnapStart: reduce el arranque en frío y el coste asociado
El arranque en frío ha sido históricamente el talón de Aquiles de Lambda para Java y .NET. Lambda SnapStart resuelve buena parte del problema: AWS toma un snapshot cifrado de la memoria de la máquina virtual después de la fase de inicialización y lo restaura en milisegundos. Según la documentación oficial de SnapStart, la mejora de arranque en frío para Java 11+ suele ser de 10x, y para Python 3.12+ y .NET 8 (agregados en 2024-2025) es del orden de 2-5x.
El coste tiene dos componentes: almacenamiento del snapshot (0,0000015046 USD por GB-hora en us-east-1) y restauración (0,0001397998 USD por GB de datos restaurados por invocación). Suena caro, pero en la práctica compensa cuando el arranque en frío te obligaba a mantener concurrencia aprovisionada. Una función Java típica que consumía 2 vCPU-segundos en cold start baja a ~200 ms con SnapStart. Activarlo es un flag por versión publicada:
# CloudFormation / SAM
Resources:
OrderApiFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: java17
SnapStart:
ApplyOn: PublishedVersions
AutoPublishAlias: live
La concurrencia aprovisionada (Provisioned Concurrency) mantiene ejecuciones ya inicializadas y listas para responder en menos de 100 ms. Cuesta 0,0000041667 USD por GB-segundo configurado (es decir, pagas aunque no se invoquen), más 0,0000097222 USD por GB-segundo de uso. En términos prácticos, cada unidad de concurrencia aprovisionada a 1 GB durante un mes cuesta unos 11 USD, más el uso real.
El punto de equilibrio contra bajo demanda depende del patrón de tráfico. Regla mental que uso en las auditorías: si la utilización esperada supera el 60 % durante horas laborables, la concurrencia aprovisionada gana. Por debajo del 40 %, es dinero tirado. La estrategia óptima en producción es combinarla con Application Auto Scaling con un objetivo de ProvisionedConcurrencyUtilization del 70 %:
Para muchas APIs internas B2B con tráfico predecible en horario laboral, SnapStart más un mínimo de concurrencia aprovisionada durante ventanas críticas (por ejemplo, apertura de mercado 09:00–10:00) es más barato que provisionar 24/7.
Compute Savings Plans para Lambda: descuento y punto de equilibrio
Los Compute Savings Plans son el único descuento por compromiso disponible para AWS Lambda hoy; no existen Reserved Lambdas. Aplican un descuento sobre la duración (no sobre solicitudes) del 12 % con compromiso de 1 año sin pago inicial y hasta el 17 % con 3 años y pago total por adelantado. Y lo interesante: el mismo Savings Plan cubre EC2, Fargate y Lambda simultáneamente, por lo que es la palanca contable perfecta para equipos que están migrando cargas entre servicios de cómputo.
El punto de equilibrio típico: si tu gasto mensual estable en la línea de duración de Lambda supera 500 USD, un compromiso de 1 año prácticamente se paga solo. Antes de comprar, exporta 3 meses de Cost Explorer filtrado por Usage Type Group = Lambda GB-Second, elimina picos anómalos y toma el percentil 25 como línea base de compromiso. Comprometer por encima de esa cifra te expone a pagar por horas no usadas. Analizo este trade-off con más detalle en la guía Savings Plans vs Instancias Reservadas en AWS.
Controla los costos ocultos: CloudWatch Logs, capas y storage efímero
Este es el punto ciego más caro de casi todas las cuentas serverless que audito. Una función Lambda que cuesta 200 USD de cómputo suele generar entre 40 y 150 USD de CloudWatch Logs cuando el equipo dejó console.log de depuración en producción y retención infinita por defecto. Tres acciones que aplico siempre:
Establecer retención por defecto a 30 días (o 7 para funciones no críticas) con un evento de EventBridge que aplique la política a todo log group nuevo. Los logs de más de 30 días rara vez se consultan y se pagan a 0,03 USD/GB/mes indefinidamente.
Bajar el nivel de log en producción a WARN o ERROR mediante variables de entorno. Un LOG_LEVEL=INFO en una función que se invoca 10 millones de veces al mes puede generar 200 GB de logs, o sea 300 USD solo en ingestión (0,50 USD/GB) más almacenamiento.
Enviar logs a S3 vía Kinesis Firehose para retenciones largas obligatorias (auditoría, compliance). S3 Glacier Instant Retrieval cuesta 0,004 USD/GB/mes, es decir, casi 8x más barato que CloudWatch para almacenamiento a largo plazo.
El almacenamiento efímero (/tmp hasta 10 GB) se cobra por encima de 512 MB. Si asignas 5 GB "por si acaso" y tu función se ejecuta 50 millones de veces al mes con duración media de 800 ms, estás pagando unos 55 USD extra que rara vez se usan. Perfila el uso real antes de asignar más de 512 MB. Para funciones que necesitan compartir librerías pesadas, usa Lambda Layers debidamente etiquetadas para asignar el coste al equipo dueño en lugar de ocultarlo en Uncategorized.
Monitorea el gasto por función con Cost Explorer y CUR
Sin visibilidad por función es imposible priorizar la optimización. Lambda no expone costo por función de forma nativa en Cost Explorer, así que hay dos caminos: etiquetas y Cost and Usage Report (CUR). Etiqueta cada función con al menos Team, Service, Environment y activa las etiquetas como User-Defined Cost Allocation Tags en la consola de Billing. Después de 24 horas podrás filtrar Cost Explorer por esas dimensiones.
Para desglose fino por función (o por versión, o por región) exporta el CUR a S3 en formato Parquet y consúltalo con Athena. Esta query devuelve el top 10 de funciones por coste del mes en curso:
SELECT
resource_tags_user_service AS service,
line_item_resource_id AS function_arn,
SUM(line_item_unblended_cost) AS cost_usd,
SUM(line_item_usage_amount) AS gb_seconds
FROM cur.cost_and_usage
WHERE line_item_product_code = 'AWSLambda'
AND line_item_usage_type LIKE '%Lambda-GB-Second%'
AND year = '2026' AND month = '08'
GROUP BY 1, 2
ORDER BY cost_usd DESC
LIMIT 10;
Además, activa AWS Cost Anomaly Detection con un monitor específico para el servicio Lambda. Recibirás alertas cuando el gasto suba más de un umbral configurable (típicamente 20 % o 100 USD/día). Esto ha detectado en varios de mis clientes bucles infinitos por errores en filtros de SQS antes de que la factura mensual estallara. Para orquestaciones de contenedores el enfoque es distinto: revisa la guía dedicada de optimización de costos en Kubernetes, porque muchas de las mismas señales aplican con matices.
Preguntas Frecuentes
¿Es AWS Lambda más barato que EC2?
Depende del patrón de uso. Lambda es más barato para cargas esporádicas, event-driven o de baja utilización (menos del 40 % de un contenedor 24/7). Para cargas de alto throughput y CPU sostenido, EC2 o Fargate con Compute Savings Plans suele ser 3-5x más económico por vCPU-hora. La regla práctica: si tu función se invoca menos de 500 000 veces al mes o los picos son muy espaciados, Lambda gana.
¿Cuánta memoria debo asignar a mis funciones Lambda?
No existe un valor universal. Ejecuta AWS Lambda Power Tuning con estrategia balanced para funciones síncronas y cost para asíncronas. En mi experiencia, el 60 % de las funciones Node.js/Python están en el óptimo entre 512 MB y 1024 MB; menos memoria suele salir más caro porque duran más.
¿Qué es AWS Lambda SnapStart y cuánto cuesta?
SnapStart es una funcionalidad que toma un snapshot cifrado de la memoria tras la inicialización y lo restaura en milisegundos, eliminando hasta el 90 % del arranque en frío. Se paga el almacenamiento del snapshot (0,0000015046 USD por GB-hora) y la restauración por invocación (0,0001397998 USD por GB). Está disponible sin coste extra para Java 11+, Python 3.12+ y .NET 8.
¿Los Compute Savings Plans cubren AWS Lambda?
Sí. Los Compute Savings Plans cubren la duración de Lambda (no las solicitudes) con descuentos de hasta el 17 % con compromiso de 3 años. Aplican simultáneamente a EC2 y Fargate, por lo que son ideales cuando estás migrando cargas entre servicios de cómputo. Nunca comprometas más que el percentil 25 de tu consumo mensual estable.
¿Cómo veo el coste real por función Lambda?
Etiqueta cada función con Team, Service y Environment, activa las etiquetas como Cost Allocation Tags en Billing y filtra Cost Explorer por esas dimensiones. Para desglose fino por función o versión, exporta el Cost and Usage Report a S3 en Parquet y consulta con Athena filtrando por line_item_product_code = 'AWSLambda'.
Ahorra hasta 90% en EC2 con instancias Spot de AWS. Guía práctica con Terraform, Karpenter en EKS y las estrategias de diversificación que evitan interrupciones en producción.
Cuándo elegir Savings Plans o Reserved Instances en AWS: descuentos hasta 72 %, cobertura por servicio, cuándo combinar ambos y cómo calcular el ahorro real sin sobrecomprometer capital.
Los costos de transferencia de datos son el tercer gasto más alto en AWS y el más incomprendido. Guía 2026 con siete estrategias para reducir egreso, NAT Gateway, IPv4 e inter-AZ entre 60% y 85% usando Terraform.
