Cuándo EC2, cuándo ECS, cuándo Lambda: la cuenta que decide

La decisión entre EC2, ECS y Lambda es una división. El punto de cruce entre las tres opciones se despeja con cuatro números —memoria de la función, duración promedio, invocaciones por mes y precio por hora de la instancia contra la que comparás— y la aritmética es de sexto grado. Toda la parte difícil de la decisión está en medir esos cuatro números.

Los tres servicios corren el mismo código sobre el mismo hardware. Lo que los separa es el mecanismo que prende y apaga el entorno de ejecución, y quién paga los segundos ociosos. De ahí salen el arranque en frío, los límites de tiempo y el punto exacto donde una función deja de ser más barata que una instancia chica prendida siempre.

La factura del tercer mes va a resolver la discusión de todas formas. Conviene adelantarla, mientras todavía es una decisión y no un hecho consumado.

Todos los precios de acá son de us-east-1 (N. Virginia), en dólares y sin impuestos, verificados a la fecha del frontmatter. Varían por región y AWS los mueve. Cada bloque declara la arquitectura —x86 o arm64— porque las tarifas de Lambda y Fargate no son las mismas en las dos.

El punto de cruce se despeja con una división. Lo que cambia el resultado es qué números ponés arriba y abajo, y esos se miden.

El piso fijo de cada opción

Antes de la primera invocación, cada opción ya cuesta algo. Ese piso decide más arquitecturas que el precio unitario.

La t4g.small cuesta USD 0,0168 la hora. El gp3 cuesta USD 0,08 por GB-mes e incluye en ese precio 3.000 IOPS y 125 MB/s de línea base, así que 20 GB de disco de sistema son 1,60 y nada más. La IPv4 pública cuesta USD 0,005 por hora esté en uso o no, un cargo que rige desde el 1 de febrero de 2024 y que sigue apareciendo en arquitecturas dibujadas antes de esa fecha.

Fargate cobra USD 0,04048 por vCPU-hora y USD 0,004445 por GB-hora en x86, un 20% menos en arm64, y no cobra disco ni dirección: incluye 20 GB de almacenamiento efímero sin cargo y el task puede vivir en subnet privada. Eso es lo que hace legítimo comparar un task de 0,25 vCPU contra una EC2 con su volumen EBS encima.

El piso del cómputo es la parte chica del piso real. Una API pública mínima suma esto:

Las dos primeras cifras son cotas inferiores, no el costo real. El ALB cobra USD 0,0225 por hora —eso es el 16,43— más USD 0,008 por LCU-hora, y las LCU no están en la tabla. Una LCU es el máximo entre cuatro dimensiones: 25 conexiones nuevas por segundo, 3.000 conexiones activas por minuto, 1 GB por hora de bytes procesados hacia targets de EC2 o contenedor —0,4 GB por hora si el target es Lambda— y 1.000 evaluaciones de regla por segundo. Un servicio que sostiene 25 conexiones nuevas por segundo consume una LCU y suma USD 5,84 al mes. El NAT gateway cuesta USD 0,045 por hora de existencia más USD 0,045 por GB procesado: unos 33 dólares por estar prendido, 3,6 veces lo que cuesta el task que atiende el tráfico.

La puerta de entrada mueve el cruce más que el cómputo

Lambda no tiene piso, pero la puerta por la que entran las invocaciones sí tiene precio por unidad, y es más caro que el cómputo. El request fee de Lambda es USD 0,20 por millón. API Gateway cobra USD 1,00 por millón en HTTP APIs —los primeros 300 millones mensuales— y USD 3,50 por millón en REST APIs. Entre 5 y 17,5 veces el cargo de la función que va a ejecutar.

Con una función liviana, esa diferencia domina la cuenta entera. El perfil de 128 MB y 50 ms en x86 cuesta USD 0,30 por millón; agregarle un HTTP API lo lleva a 1,30 y un REST API a 3,80.

Poner un REST API adelante de una función liviana divide el punto de cruce por doce. La elección de la puerta de entrada es una decisión de costo de cómputo aunque no se parezca a una.

Todo a la misma unidad: el vCPU-hora

Hay una segunda lectura del mismo cruce que no depende del perfil de la función. Lambda asigna CPU en proporción a la memoria: a 1.769 MB tenés el equivalente a un vCPU completo. Con eso, las tres opciones se pueden llevar a la misma unidad.

La tarifa de vCPU sola en Fargate es 0,0405 en x86 y 0,0324 en arm64; el resto de esas filas es la memoria del task.

El múltiplo que importa es 0,1036 dividido 0,0363: Lambda cuesta 2,86 veces el vCPU-hora de una instancia dedicada on-demand. Y el inverso de ese múltiplo, 0,35, es la regla de decisión. Lambda gana mientras la utilización sostenida que le darías al servidor quede por debajo del 35%. Arriba de ese número estás pagando un premium de 2,86x sobre horas que igual ibas a usar.

Las dos lecturas —el cruce por perfil y el umbral de utilización— tienen que dar lo mismo. Cuando no dan lo mismo, la diferencia es el request fee, la puerta de entrada y la plomería, que la segunda lectura ignora a propósito.

El punto de cruce, hecho a mano

Lambda en us-east-1 cobra USD 0,20 por millón de requests, y por GB-segundo cobra USD 0,0000166667 en x86 y USD 0,0000133334 en arm64. La memoria se factura en GB de 1.024 MB.

Del free tier de 1 millón de requests y 400.000 GB-segundos mensuales conviene desconfiar por dos motivos. Es por cuenta y no por función, así que lo comparten todas las funciones y una sola con volumen lo consume entero. Y desde julio de 2025 las cuentas nuevas entran bajo el esquema de créditos, no bajo el free tier perpetuo: si tenés esa franquicia o no depende de bajo qué esquema quedó tu cuenta. La cuenta que sigue lo ignora.

costo_invocacion = memoria_GB × duración_s × precio_GB_segundo + 0,0000002

invocaciones_de_cruce = costo_mensual_del_servidor / costo_invocacion

Contra los USD 12,26 de la t4g.small pelada y contra los USD 17,51 que cuesta de verdad con disco y dirección, en x86:

El cruce se mueve dos órdenes de magnitud según el perfil. Una función liviana le gana a la instancia hasta casi 58 millones de invocaciones por mes. Una de 2 GB que tarda un segundo pierde a partir de medio millón, unas 17.000 por día. La columna que vale es la de 17,51: una EC2 alcanzable desde internet paga la dirección y el disco, y comparar contra el precio pelado deja cada cruce un 30% abajo.

Pasar a arm64 corre cada fila hacia arriba, pero no un 20% parejo. El 20% baja solo el término de GB-segundo; el cargo de USD 0,20 por millón de requests no cambia con la arquitectura. El corrimiento real depende de cuánto pesa cada término:

El techo del corrimiento es exactamente 25%, que es lo que da 1 / 0,8, y se alcanza recién cuando el request fee es despreciable. En el perfil liviano, donde el request fee es dos tercios del costo, arm64 mueve el cruce apenas 7%.

Hay además un techo que no depende de la duración. Aun con tiempo de ejecución cero, el cargo de USD 0,20 por millón alcanza los USD 17,51 en 87,6 millones de invocaciones mensuales, unos 33 req/s sostenidos —61,3 millones y 23 req/s contra la instancia pelada—. Por encima de ese volumen ninguna función, por rápida que sea y en cualquier arquitectura, le gana a una t4g.small prendida todo el mes en costo de cómputo.

La trampa de comparar contra una instancia burstable

La t4g.small es la vara habitual porque es barata, y es barata porque es burstable. Tiene 2 vCPU y una línea base del 20% por vCPU: gana 24 créditos de CPU por hora y acumula hasta 576. Por debajo de esa línea el precio publicado es el precio final.

Arriba de la línea, T4g arranca en unlimited mode por defecto y cobra el excedente a USD 0,04 por vCPU-hora. Una t4g.small sostenida al 100% de sus dos vCPU paga 1,6 vCPU-hora de excedente por hora: USD 46,72 extra al mes, que llevan el total a unos 59 dólares. Casi exactamente lo que cuesta una m7g.large de 2 vCPU dedicadas y 8 GiB, USD 59,57.

La misma trampa se ve en la unidad normalizada. Los USD 17,51 de la t4g.small compran 1.460 vCPU-horas nominales, pero solo 292 sostenibles sin cargo extra: 0,4 vCPU × 730 horas. Eso son USD 0,060 por vCPU-hora realmente sostenible, un 65% más caro que los 0,0363 de la c7g.large. Contra esa vara, el premium de Lambda cae de 2,86x a 1,7x y el umbral de utilización sube del 35% al 58%.

La consecuencia para la decisión es directa: si la carga es sostenida, el punto de cruce hay que recalcularlo contra el precio de una instancia no burstable. Contra c7g.large a USD 52,93 mensuales, el perfil de 512 MB y 200 ms en x86 cruza recién en 28 millones de invocaciones.

La fase de init también se factura

El punto de cruce usa memoria y duración como insumos. El mecanismo que genera esos dos números es el ciclo de vida del entorno de ejecución, y tiene tres detalles que cambian lo que la métrica te muestra.

La fase Init se factura. Todo lo que corre fuera del handler —importar dependencias, abrir el pool de conexiones, leer parámetros— entra en la duración cobrada. Y tiene un límite duro de 10 segundos: si el init se pasa, Lambda lo reintenta durante la primera invocación, esta vez con el timeout configurado de la función. Ese límite de 10 segundos no aplica bajo provisioned concurrency, SnapStart ni Managed Instances, donde el init puede correr hasta el máximo entre 130 segundos y el timeout configurado, o sea hasta 15 minutos.

El /tmp sobrevive entre invocaciones del mismo entorno y no se limpia, ni siquiera después de un reset por error. Es cache gratis y es fuga de datos entre requests, según cómo lo uses.

Los callbacks en background no mueren cuando devolvés la respuesta: quedan congelados y se reanudan cuando el entorno se reusa, en el contexto de otra invocación. Un setTimeout que parecía inofensivo aparece minutos después en los logs de un request ajeno.

El costo de todo esto es más chico de lo que la discusión sugiere. La documentación de AWS mide los arranques en frío por debajo del 1% de las invocaciones, con duraciones de menos de 100 ms a más de un segundo según runtime y paquete. La pregunta relevante no es cuántos hay sino cuánto vale sacarlos.

Qué cuesta la latencia predecible

Provisioned concurrency mantiene entornos inicializados. En x86 cobra USD 0,0000041667 por GB-segundo de concurrencia aprovisionada, más la duración a USD 0,0000097222 por GB-segundo en lugar de los 0,0000166667 habituales. Un solo entorno de 512 MB caliente todo el mes cuesta USD 5,48 antes de atender un request; diez entornos, USD 54,75.

De esas tres tarifas sale el umbral de decisión. El descuento por GB-segundo de duración es 0,0000166667 menos 0,0000097222, o sea 0,0000069445. El equilibrio se da cuando ese descuento, multiplicado por la fracción del tiempo que el entorno está ocupado, iguala el cargo fijo de la concurrencia:

0,0000041667 = u × (0,0000166667 − 0,0000097222)
u = 0,60

Provisioned concurrency se paga sola recién arriba del 60% de ocupación del entorno. Debajo de eso estás pagando por tener la máquina prendida, que es exactamente el modelo de facturación del que Lambda te iba a sacar. Las tres tarifas son de x86; en arm64 los tres números bajan pero el umbral queda en el mismo orden.

SnapStart cachea un snapshot del entorno ya inicializado y cobra con otra forma. Para Java no tiene cargo adicional. Para los runtimes no-Java cuesta USD 0,0000015046 por GB-segundo de snapshot cacheado —un 36% de lo que cuesta el GB-segundo de provisioned concurrency— más USD 0,00013980 por cada GB restaurado. El cargo grande escala con la cantidad de arranques en frío, no con el reloj, y por eso es la primera palanca a probar.

La regla que sale de estos precios: si la solución al arranque en frío es dejar entornos prendidos las 24 horas, el modelo de facturación pasó a ser el de un servidor, con menos control sobre el servidor.

Los límites que deciden por vos

Antes de calcular nada conviene descartar. Estos son límites duros de Lambda, no ajustables:

• Timeout máximo de 900 segundos, 15 minutos.
• Memoria de 128 MB a 10.240 MB. La CPU se asigna en proporción: a 1.769 MB tenés el equivalente a un vCPU.
• Payload de 6 MB por invocación sincrónica y 1 MB asincrónica.
• Paquete .zip de 250 MB descomprimido, o imagen de contenedor de hasta 10 GB.
• /tmp entre 512 MB y 10.240 MB.
• 1.000 ejecuciones concurrentes por región por defecto, ampliable, y un escalado de hasta 1.000 entornos cada 10 segundos por función.

Fargate va de 0,25 a 16 vCPU con memoria de hasta 120 GB, en combinaciones fijas: 0,25 vCPU admite 0,5, 1 o 2 GB, y nada más. No hay GPU en Fargate.

Si el job tarda 20 minutos, si necesita GPU, si el artefacto pasa de 10 GB o si el proceso mantiene estado en disco entre corridas, la decisión ya está tomada y no hace falta la planilla.

Descuentos: el folleto y la cuenta

Los porcentajes que publica AWS son máximos: hasta 90% en spot, hasta 72% en EC2 Instance Savings Plans y en reserved instances standard, hasta 66% en Compute Savings Plans y en reserved instances convertibles. Para reserved instances AWS publica además el promedio realista en su propia página de precios: 40% a un año y 60% a tres para standard, 31% y 54% para convertible.

Sobre una instancia concreta el folleto se vuelve una tabla. Estos son los precios efectivos de la t4g.small de us-east-1, consultados el 2026-08-10 con los comandos que están abajo:

# tarifas efectivas de Savings Plans para una instancia concreta
aws savingsplans describe-savings-plans-offering-rates \
  --service-codes AmazonEC2 \
  --filters name=instanceType,values=t4g.small \
            name=region,values=us-east-1 \
            name=tenancy,values=shared \
            name=productDescription,values=Linux/UNIX \
  --query 'searchResults[].[savingsPlanOffering.planType,
                            savingsPlanOffering.durationSeconds,
                            savingsPlanOffering.paymentOption, rate]' \
  --output table

# spot: ventana de 30 días, con la AZ al lado de cada precio
aws ec2 describe-spot-price-history --region us-east-1 \
  --instance-types t4g.small --product-descriptions Linux/UNIX \
  --start-time 2026-07-11T00:00:00Z --end-time 2026-08-10T00:00:00Z \
  --query 'SpotPriceHistory[].[AvailabilityZone,SpotPrice,Timestamp]' \
  --output text

Dos cosas que la tabla dice y el folleto no. La primera: en esta instancia el EC2 Instance Savings Plan a tres años rinde 63% sin ningún riesgo de interrupción, más que el 54% que dio spot en esa ventana. El 90% de spot existe, pero en otras familias y en otros momentos; sobre una burstable chica no aparece. Y spot no es un número sino una distribución que se mueve por AZ y por hora, así que la fila de spot caduca antes que las otras.

La segunda: el Compute Savings Plan rinde menos que el EC2 Instance SP —28% contra 42% al año— y es el único instrumento que cubre EC2, Fargate y Lambda al mismo tiempo. Si la arquitectura todavía se puede mover entre los tres servicios, esos catorce puntos son el precio de no quedar clavado a una familia de instancias durante tres años. Fargate Spot descuenta hasta 70% sobre el precio de Fargate, con el mismo aviso de dos minutos.

Los porcentajes se mueven por familia. El diagrama muestra la forma del trade-off; la tabla, el caso concreto de una instancia.

Cómo se interrumpe una spot

"Dos minutos de aviso" es un resumen. El mecanismo es más específico y determina si spot te sirve.

Cuando EC2 necesita la capacidad, marca la instancia y publica un evento de EventBridge llamado EC2 Spot Instance Interruption Warning. Al mismo tiempo, el endpoint de metadatos /latest/meta-data/spot/instance-action deja de devolver 404 y empieza a devolver la acción y la hora. AWS recomienda consultarlo cada 5 segundos: si consultás más espaciado, te comés parte de la ventana.

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# 404 mientras no pasa nada; JSON con action y time cuando está marcada
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/spot/instance-action

Dos matices que cambian el diseño. Si la instancia está configurada para hibernar, recibís el aviso pero no los dos minutos: la hibernación empieza de inmediato. Y fijar un precio máximo no te protege de nada: aumenta la frecuencia de interrupción, porque cuando el precio spot supera tu máximo la instancia se corta además de por falta de capacidad.

Spot sirve para cualquier carga cuyo trabajo perdido en dos minutos sea aceptable: batch, CI, transcodificación, réplicas de lectura detrás de un balanceador. Deja de servir en el nodo con estado sin replicar.

El Fargate tax, medido

ECS no cobra por sí mismo: el control plane es gratis y pagás lo que corre abajo. La decisión de costo está en el launch type.

Fargate en x86 cuesta 36% más que la EC2 dedicada equivalente, y el porcentaje es el mismo en el task chico que en el del doble: el premium no se diluye creciendo. En arm64 la diferencia baja a 9%, y contra ese 9% hay que poner lo que dejás de operar: AMIs, parches, auto scaling group de la flota, bin packing. Nueve por ciento por no tener hosts es barato. Treinta y seis por ciento y encima en x86 es un default que nadie eligió.

Con ECS sobre EC2 el desperdicio tiene otra forma: la diferencia entre lo que reservan las task definitions y la capacidad real de la flota. Esa fracción ociosa ya está paga.

Dos casos públicos que marcan el rango

El equipo de monitoreo de audio y video de Prime Video pasó de una orquestación de Step Functions con Lambda a un servicio único sobre ECS y EC2, y reportó una reducción de costos cercana al 90%. La causa no fue el precio del cómputo sino el costo de mover datos entre componentes y de orquestar transiciones que dentro de un mismo proceso son llamadas a función.

AUDI bajó más de 60% el costo de cómputo del backend de su configurador de autos sin cambiar de modelo de ejecución: siguió con contenedores sobre EC2 y cambió el aprovisionamiento y el modelo de compra, con Karpenter y spot.

Los dos casos apuntan al mismo lugar. El ahorro grande casi nunca viene de la fila de la tabla que estabas mirando.

El árbol de decisión

Descartá por límite duro. Más de 15 minutos, GPU, estado en disco local, artefacto de más de 10 GB: EC2 o ECS sobre EC2. Fin.

Calculá el piso. Si el volumen es bajo o esporádico y no hay ALB ni NAT en el diagrama, Lambda gana por no tener piso, sin importar el precio por invocación.

Sumá la puerta de entrada. Un REST API adelante de una función liviana divide el cruce por doce. Ese cargo entra en la división, no al lado.

Hacé la división. Con memoria, duración y volumen medidos, el cruce sale en una línea. Si estás a menos de 3x del cruce, la decisión es indiferente en costo y hay que elegir por otra cosa.

Elegí la instancia de comparación correcta. Burstable contra carga sostenida no compara nada. Con la CPU real medida, la vara es una instancia dedicada.

Comprometete al final, no al principio. El descuento por compromiso es la última optimización, después de saber qué vas a correr. Un savings plan de tres años sobre una arquitectura que todavía se discute es prepagar un error.

AWS ya escribió que el cruce existe

Lambda Managed Instances es la respuesta del proveedor a esta misma cuenta. Factura el precio on-demand de la instancia EC2 que corre abajo más un management fee del 15%, admite Savings Plans y reserved instances como cualquier EC2, y no tiene arranque en frío porque no escala a cero.

Leído en la unidad normalizada, ese 15% sobre los 0,0363 de una c7g.large da unos 0,0417 por vCPU-hora, contra los 0,1036 de Lambda on-demand. Menos de la mitad, a cambio de pagar las horas ociosas.

Es el punto de cruce escrito en una página de precios de AWS: arriba de cierta utilización sostenida, el modelo por invocación deja de convenir, y el proveedor prefiere venderte el modelo por hora antes que perder la carga.

Herramientas para hacer la cuenta

El AWS CLI desde CloudShell resuelve las consultas puntuales sin instalar nada:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --output table

Nada de esto funciona sin tagging. Con Environment, Service y Owner en cada recurso, la factura tiene dueño. Sin eso devuelve un número grande y anónimo, y el número anónimo no se optimiza nunca.

Lo que queda del lado de la decisión

Las tres opciones corren el mismo código sobre el mismo hardware. Lo que comprás en cada una es un reparto distinto de trabajo operativo y una forma distinta de que te cobren el tiempo ocioso. Eso es todo, y eso se calcula.

La cuenta tarda diez minutos. La arquitectura que sale de no hacerla dura años.