Un BFF (Backend for Frontend) es una capa delgada entre el frontend y los servicios de backend. La pregunta que todo arquitecto enfrenta es ¿dónde ejecutamos ese BFF en AWS?, y la respuesta cambia radicalmente el costo, la operación y la latencia. Hay cinco escenarios principales, y la decisión correcta depende de una sola variable dominante: el patrón de tráfico (constante vs. intermitente).
⚠️ Nota sobre los precios
calculator.aws).Qué es un BFF y por qué su alojamiento importa
Un BFF no contiene la lógica de negocio pesada: su trabajo es orquestar, adaptar respuestas, ocultar el backend real y manejar preocupaciones transversales (autenticación, CORS, agregación de llamadas).
Donde ejecutes esa capa define tu factura y tu carga operativa. Antes de ver las opciones, interioriza el eje que separa el mundo serverless del mundo «siempre encendido».
La variable que decide todo: tráfico constante vs. intermitente
- Serverless (Lambda, Amplify SSR): cuestan casi $0 cuando nadie los usa y escalan solos. Pagas por request/cómputo consumido.
- Siempre encendido (App Runner, Fargate, EC2): pagas una capacidad base 24/7 aunque el tráfico sea cero, pero el costo por request a volumen alto puede ser menor.
El punto de cruce entre ambos mundos es el corazón de la decisión.
Escenario 1 — Lambda + API Gateway
El BFF es una función Lambda detrás de un API Gateway (o Function URL). Puro serverless.
Pros
- Costo ~$0 en reposo; escala a cero.
- Escalado automático sin configuración.
- Pago granular por invocación y por ms de cómputo.
Contras
- Cold starts: la primera invocación tras inactividad añade latencia (decenas a cientos de ms; más en runtimes pesados). Mitigable con provisioned concurrency (que reintroduce costo fijo).
- Límite de duración por request y de tamaño de payload.
- El frontend estático se aloja aparte (S3 + CloudFront).
✅ Cuándo elegirlo
Escenario 2 — Amplify Hosting (SSR)
Cuando el frontend es un framework con render en servidor (Next.js, Nuxt, etc.), el BFF suele vivir dentro del mismo framework (route handlers / server actions). Amplify Hosting ejecuta ese cómputo SSR de forma gestionada y sirve el frontend por su CDN.
Pros
- Frontend + BFF en un solo lugar, un solo deploy (git push → build → deploy).
- CDN, HTTPS y CI/CD incluidos sin configurar nada.
- Serverless: casi $0 en reposo para bajo tráfico.
Contras
- Menos control fino sobre el runtime que una Lambda propia.
- El cómputo SSR se encarece con tráfico muy alto y sostenido (modelo por request).
- Acoplas el ciclo de vida del BFF al del frontend.
✅ Cuándo elegirlo
Escenario 3 — AWS App Runner (contenedor gestionado)
Empaquetas el BFF en un contenedor y App Runner lo corre con HTTPS, autoescalado y despliegue desde imagen o repo. Es el punto intermedio entre serverless y Kubernetes.
Pros
- Sin cold starts molestos; proceso siempre listo.
- Soporta procesos largos y cualquier runtime (lo que corra en un contenedor).
- Mucho más simple que ECS/EKS: sin VPC, ALB ni task definitions a mano.
Contras
- Costo base fijo: pagas por la capacidad mínima aunque el tráfico sea cero.
- Menos «a cero» que Lambda (aunque puede escalar la capacidad según carga).
- Para un BFF liviano, puede ser sobredimensionado.
✅ Cuándo elegirlo
Escenario 4 — ECS Fargate / EKS
El contenedor en una orquestación completa. Fargate (sin gestionar nodos) o EKS (Kubernetes). Máximo control, máxima complejidad.
Pros
- Control total: redes, sidecars, service mesh, políticas de escalado finas.
- Ideal si ya tienes una plataforma de contenedores estandarizada.
- Mejor costo unitario a gran escala sostenida.
Contras
- Costo fijo del ALB + tareas corriendo 24/7.
- Carga operativa alta: VPC, security groups, task defs, escalado, observabilidad.
- Sobreingeniería para un simple BFF salvo que el resto del stack ya viva aquí.
✅ Cuándo elegirlo
Escenario 5 — Edge (Lambda@Edge / CloudFront Functions)
El BFF se ejecuta en los puntos de presencia del CDN, cerca del usuario. Para lógica muy ligera (reescritura de headers, auth en el borde, personalización mínima).
Pros
- Latencia mínima: ejecuta cerca del usuario.
- Serverless y escala global automática.
Contras
- Restricciones duras: límites estrictos de CPU/memoria/duración y de runtime.
- No apto para un BFF con lógica real; solo manipulaciones ligeras.
- Depuración y despliegue más complejos.
✅ Cuándo elegirlo
Comparación de costos por volumen de requests
Modelo de referencia para un BFF liviano (proxy/orquestación, ~50 ms de cómputo, 128–512 MB). Cifras ilustrativas en USD/mes, redondeadas a orden de magnitud.
| Requests/mes | Lambda + API GW | Amplify SSR | App Runner | Fargate + ALB |
|---|---|---|---|---|
| 100 K (muy bajo) | ~$0–1 | ~$0–5 | ~$5–25 (base) | ~$20–35 (base+ALB) |
| 1 M (bajo) | ~$1–4 | ~$5–15 | ~$10–30 | ~$25–40 |
| 10 M (medio) | ~$15–40 | ~$30–80 | ~$25–60 | ~$35–70 |
| 100 M (alto sostenido) | ~$150–400 | ~$300–700 | ~$120–300 | ~$100–250 |
Lectura de la tabla:
- A bajo volumen, serverless (Lambda, Amplify) gana claro: el costo base fijo de los contenedores pesa más que todo el tráfico.
- El punto de cruce aparece en el rango de decenas de millones de requests/mes: a partir de ahí, un contenedor «lleno» (App Runner, Fargate) empieza a ser más barato por request que el modelo por invocación.
- Amplify SSR cuesta algo más que Lambda pura porque empaqueta frontend + build + CDN + cómputo; pagas esa conveniencia.
Factores más allá del costo
El precio es solo un eje. Pondera también:
| Factor | Favorece serverless | Favorece contenedor |
|---|---|---|
| Operación | Equipo pequeño, sin SRE dedicado | Ya hay plataforma de contenedores |
| Latencia | Tolera cold starts | Respuesta constante sin warmup |
| Runtime | Lenguajes/paquetes estándar | Dependencias nativas o procesos especiales |
| Picos | Tráfico impredecible, estacional | Carga plana y predecible |
| Time-to-market | Prioridad: salir rápido | Prioridad: control fino |
Recomendación por etapa del proyecto
- MVP / PoC / producto nuevo → empieza serverless (Lambda + API GW, o Amplify SSR si tu frontend es SSR). Costo casi cero en reposo, cero operación, salida rápida.
- Crecimiento → mide el tráfico real. Mientras el reposo sea frecuente, sigue serverless.
- Escala alta y sostenida → cuando los números reales muestren que el costo serverless superó al de un contenedor lleno, migra a App Runner o Fargate. No antes.
✅ La regla de oro
Conclusión
No existe un «mejor lugar» universal para un BFF en AWS; existe el mejor lugar para tu patrón de tráfico y tu equipo. Para la gran mayoría de los proyectos —especialmente los que empiezan— serverless es la respuesta correcta por defecto: Lambda + API Gateway si el frontend es estático, o Amplify SSR si el frontend ya renderiza en servidor. El mundo de contenedores (App Runner, Fargate) entra en juego cuando el tráfico se vuelve alto, constante y predecible, o cuando tu organización ya vive en contenedores.
Decide con el eje tráfico-constante-vs-intermitente en mente, valida con la calculadora oficial, y recuerda que migrar de serverless a contenedor es mucho más fácil que justificar el costo fijo de un contenedor que pasa la mayor parte del tiempo ocioso.
💡 Las estimaciones son ilustrativas