Lambda@Edge se basa principalmente en eventos para solicitudes, sí, la latencia se reduce, pero está diseñado para usarse con un origen. Incluso si tiene la función Lambda@Edge, su distribución de CloudFront aún necesitaría llegar al origen.

Cuando el origen es una puerta de enlace API (con o sin Lambda), hay tantos beneficios como:

• Compatibilidad integrada con la especificación OpenAPI
• Enrutamiento incorporado
• Compatibilidad con implementaciones canarias
• Autenticación y autorización integradas, con soporte para limitación por usuario de API
• Compatibilidad integrada para la validación del esquema del modelo
• Soporte para administrar su API como infraestructura como código: CloudFormation , Terraform , SAM
• Cada solicitud se puede desarrollar por separado, solo puede tener 1 función Lambda@Edge por evento, por lo que es posible que vea colisiones en un equipo (sin mencionar funciones muy grandes).

Si Lambda@Edge tuviera que hacer todo esto, entonces tendría que diseñar, desarrollar y mantener estas funciones.

El precio al que se refiere es para la API REST, tenga en cuenta que hay 3 tipos de API, la más barata es la API HTTP, que cuesta $1.00 por millón de solicitudes.

Lambda@Edge tiene muchas limitaciones en comparación con lambda normal. Por ejemplo:

• es solo para node.js y python,
• sin capas lambda!
• sin rayos X AWS!
• tiempo de espera máximo 30 segundos,
• y muchos más.

Por lo tanto, en muchos casos sería difícil migrar a Lambda@Edge y renunciar a todos estos beneficios de lambda regular.