Saltar al contenido
Volver a la lista de artículos
Infrastructure16分

Fastly vs Akamai vs AWS Lambda@Edge: un benchmark

Edge Platform Benchmark 2026: Fastly, Akamai, AWS Lambda@Edge, Cloudflare Workers

平井 翔大Infrastructure Solution Architect
2026-04-2316分
FastlyAkamaiAWSCloudflareLambda@EdgeWASMBenchmark

Por qué volver a comparar el edge compute ahora

Hasta 2024, la conclusión de muchas empresas japonesas era "con Cloudflare Workers es suficiente". Sin embargo, desde 2025, el runtime WASM de Fastly Compute se estabilizó, AWS renovó Lambda@Edge como CloudFront Functions 2.0, y Akamai amplió el límite de memoria de EdgeWorkers; las opciones volvieron a estar en paridad. En especial para las empresas japonesas con despliegues en el sudeste asiático (Singapur, Yakarta, Bangkok, Manila), la distribución de PoP de cada proveedor y el cumplimiento regulatorio tienen un peso estratégico determinante.

Este artículo compara cuatro plataformas en cinco ejes —cold start, memoria efectiva, costo por GB-segundo, distribución geográfica e integración WAF/gestión de bots— y presenta una matriz de selección por caso de uso. Los números se basan en información pública de abril de 2026 y en benchmarks internos de producción propios (mediciones de una hora / 1.000 req/s en tres regiones: Tokio, Singapur y Bombay).

Cold start y memoria efectiva

Cloudflare Workers usa aislados V8, por lo que el cold start es prácticamente indetectable (menor a 5ms en p99), aunque la memoria por aislado es fija en 128 MB. Fastly Compute usa un runtime basado en wasmtime para levantar WebAssembly, con cold start de 0,3ms en p50 y alrededor de 5ms en p99 —comparable a Workers—, pero con memoria expandible hasta 512 MB. AWS Lambda@Edge sigue basándose en Firecracker MicroVM: el cold start puede superar los 150ms en p50 y 600ms en p99, por lo que el calentamiento periódico es indispensable. Akamai EdgeWorkers usa V8 pero divide los límites de CPU y memoria por tier; en el tier Dynamic el tope es 256 MB y 200 ms.

La conclusión del benchmark es clara: para "rutas calientes que requieren respuesta de 1ms", Cloudflare o Fastly; para "lógica pesada que necesita más de 100ms de procesamiento", AWS Lambda@Edge. Akamai ocupa el punto intermedio y tiene como ventaja que las organizaciones con contratos Akamai CDN existentes pueden usarlo sin costo adicional.

``` # Latencia p99 para respuesta JSON simple en PoP de Tokio (medición interna, abril 2026) Cloudflare Workers : 4,8ms Fastly Compute (WASM) : 5,2ms Akamai EdgeWorkers : 12,1ms AWS Lambda@Edge (cold) : 612ms / (warm) 38ms ```

Costo por GB-segundo y modelo de facturación

Cloudflare Workers tiene un modelo propio que cobra solo por "CPU time" y no por "tiempo de ejecución × número de peticiones", de modo que el tiempo de espera en I/O no se factura. El plan Bundled incluye 5 millones de peticiones + 50ms de CPU time por 5 USD/mes; el plan Unbound ofrece 10M req + 30M CPU-ms por 5 USD. Fastly Compute usa un modelo de "cuota mensual por instancia core" desde 50 USD por instancia, con cargos adicionales por consumo solo si se supera el límite. AWS Lambda@Edge cobra por GB-segundo en intervalos de 1ms, con distintas tarifas para peticiones de origen y de visor (el lado del visor es tres veces más caro). Akamai EdgeWorkers es por contrato; el tier Dynamic ronda los 500 USD por hasta 500.000 ejecuciones mensuales, con cargos variables por exceso.

Simulando un precio efectivo unitario con "1M req / CPU promedio 10ms / payload 10KB", los rangos son: Cloudflare 0,5 USD, Fastly 0,4 USD (si entra dentro del contrato de instancia core), AWS Lambda@Edge 2,1 USD, Akamai alrededor de 3,0 USD. En precio unitario simple, Cloudflare y Fastly son ampliamente más baratos. Sin embargo, dado que AWS opera dentro de la zona de transferencia de datos gratuita con CloudFront, S3 y DynamoDB, puede haber escenarios donde el costo total se invierta.

Distribución geográfica y tráfico Japón × sudeste asiático

La cobertura de PoP para tráfico originado en Japón con destino al sudeste asiático es la siguiente. Cloudflare cubre las principales ciudades: Tokio, Osaka, Ho Chi Minh, Hanói, Yakarta, Manila, Bangkok, Singapur y Kuala Lumpur. Fastly es fuerte en Tokio, Osaka, Singapur y Hong Kong; en Indonesia y Vietnam el tráfico pasa por proveedores de interconexión, lo que añade alrededor de 20ms de RTT promedio. AWS Lambda@Edge sigue los PoP de CloudFront (Tokio, Osaka, Singapur, Yakarta, Manila, Bangkok), pero la ejecución de Lambda ocurre en los Regional Edge Caches más cercanos (11 ubicaciones como Tokio, Singapur y Bombay), no en los PoP directamente. Akamai tiene la mayor cantidad de PoP del planeta, pero los que pueden ejecutar EdgeWorkers son solo un subconjunto.

Si se necesita latencia baja de forma uniforme en todo el sudeste asiático, Cloudflare es la opción más sólida. Si el eje Japón-Singapur es suficiente, el rendimiento WASM de Fastly se luce. Si la integración con el stack AWS existente es prioritaria, Lambda@Edge. Para mantener un SLO de p95 menor a 80ms en sitios de e-commerce ASEAN, la combinación de Cloudflare + sharding con Durable Objects resultó la más rentable en tres proyectos propios.

Nivel de integración de WAF y gestión de bots

El edge compute ya no se evalúa solo por "ejecución de lógica": hay que analizarlo en conjunto con WAF, gestión de bots y protección DDoS. Cloudflare ofrece WAF (OWASP Core Rule Set + reglas propias), Bot Management y Turnstile desde el mismo panel de control que Workers, y dentro de Workers se puede acceder directamente a `cf.botManagement.score` para modificar el comportamiento de forma dinámica. Fastly tiene su propia Next-Gen WAF basada en Signal Sciences (adquirida en 2020), invocable desde dentro de Compute. AWS opera WAF + Shield a nivel CloudFront, y dentro de Lambda@Edge hay que escribir la inspección de `event.Records[0].cf.request.headers` manualmente. Akamai tiene el App & API Protector (antiguo Kona) más maduro del mercado, y sigue siendo la primera opción en la industria financiera.

En precisión de detección de bots, los cuatro migraron a modelos ML a partir de 2025, y la tasa de detección conforme a OWASP ATP (Automated Threat Protection) ronda el 95% en todos. La diferencia se da en el "flujo de recuperación ante falsos positivos" y la "integración con SOC": Akamai y Cloudflare ofrecen integración SIEM estándar (Splunk, Sentinel, Datadog), Fastly solo con Datadog, y AWS requiere conversión vía CloudWatch.

Matriz de selección: recomendación por caso de uso

A continuación se incluye un extracto de la matriz de selección que usamos en propuestas a clientes.

  • API de latencia ultra baja (respuesta de 1ms): Cloudflare Workers o Fastly Compute
  • Lógica de edge con estado (edición colaborativa, señalización): Cloudflare Workers + Durable Objects, sin alternativa
  • Integración densa con stack AWS existente (S3, DynamoDB, Cognito): AWS Lambda@Edge + CloudFront
  • Sectores regulados (finanzas, salud) con requisitos WAF/SOC: Akamai EdgeWorkers + App & API Protector
  • B2C masivo con cientos de millones de peticiones mensuales y prioridad en costo: Fastly Compute con instancia core mensual
  • SLO consistente en Japón + toda la región ASEAN (p95 80ms): Cloudflare Workers
  • Transformación de video e imagen en tiempo real (procesamiento CPU mayor a 100ms): AWS Lambda@Edge o Fastly Compute (512 MB de memoria)

Conclusión: el fin de la dependencia de un solo proveedor

En la arquitectura de edge de 2026, depender de una única plataforma se ha convertido en un riesgo tanto técnico como de continuidad del negocio. Ante la realidad de grandes apagones de Cloudflare (noviembre 2023, febrero 2025) y la incidencia recurrente de la región us-east-1 de AWS con impacto global, crece el número de grandes empresas que adoptan estrategias multi-edge como "Cloudflare como primario, Akamai para contenido estático y AWS para procesamiento por lotes". Unificar métricas con OpenTelemetry y gestionar la infraestructura como código con Terraform permite reducir el costo del vendor lock-in y asegurar disponibilidad.

La selección ya no es un problema de "elegir al más rápido", sino de "diseñar la combinación óptima por tipo de workload". Los números del benchmark se vuelven obsoletos, pero las diferencias filosóficas entre plataformas siguen siendo un criterio de decisión válido a largo plazo. La forma estándar para la era del edge es explicitar las características de tráfico propias, los requisitos regulatorios y los activos existentes, y revisarlos cada trimestre.

Resolvamos juntos sus desafíos técnicos.

KGA IT Solutions reúne equipos especializados en IA, nube y DevOps para entregar la solución ideal a sus retos.

Contáctanos