Pro: implementación y despliegue rápidos

Las URL de la función AWS Lambda se configuran e implementan muy rápidamente y requieren menos configuración que las otras alternativas.

Cuando configuro el punto final, está casi instantáneamente disponible para su uso y solo requiere unos pocos valores de configuración.

AWS API Gateway tarda más en implementarse y requiere un conjunto de recursos más complejo para configurar. La API, los recursos, los métodos, la implementación, la etapa y los permisos de Lambda forman parte de la configuración.

AWS ALB requiere que se configuren recursos subyacentes adicionales y tiene un costo inicial para usarlo. Se necesita bastante para diseñar redes de AWS, pero como mínimo contienen una VPC, subredes, IGW y grupos de seguridad. Los ALB de AWS también requieren varios recursos diferentes para crear un sistema que funcione.

Pro: IAM para control de acceso

Las opciones para la autenticación de las URL de la función AWS Lambda son Ninguna o usar IAM. Cuando usa Ninguno, cualquier seguridad adicional debe estar dentro del código. Sin embargo, cuando usa IAM, puede hacer referencia a los recursos de IAM con una granularidad significativa.

Esto significa que si tanto usted como sus clientes utilizan AWS, existe un punto de integración sólido y simple para la seguridad simplemente consultando directamente sus recursos de IAM de AWS.

Pro: compatibilidad con alias de AWS Lambda

Los alias de AWS Lambda también son compatibles con las nuevas URL, lo que significa que puede mantener una URL pública consistente al reemplazar la infraestructura subyacente.

Esto no es tan práctico como si se hiciera con DNS, pero puede funcionar si no le importa el alias de AWS Lambda y el sistema de control de versiones.

Contra: No hay soporte de DNS personalizado

Como se mencionó anteriormente, el DNS no se puede usar para las URL de la función AWS Lambda, lo que puede ser un problema tanto para los lanzamientos como para la presentación del servicio a los clientes.

La falta de DNS personalizado es similar a la puerta de enlace API privada de AWS y puede causar problemas si utiliza la automatización de DNS para los procesos de lanzamiento.

Es posible solucionar el problema de DNS personalizado implementando AWS CloudFront y apuntando a la URL en el backend. Se trata del mismo esfuerzo que implementar AWS API Gateway, lo que anula los beneficios de usar la nueva característica.

Desventajas: Exposición de ID de cuenta de AWS

Según AWS, las nuevas URL exponen el ID de cuenta de AWS utilizado para el servicio que puede proporcionar información a cualquier actor malicioso.

Los ID de cuenta de AWS no se consideran una credencial por motivos de seguridad, pero probablemente se deba evitar publicar esta información siempre que sea posible.

Contra: controles de red limitados

Debido a la implementación de las URL de la función AWS Lambda, no hay forma de implementar controles de red basados en IP o cualquier nivel inferior a la autorización mencionada anteriormente.

Esta es una limitación que podría ser un problema dependiendo de su entorno. Para grandes empresas no es aceptable, pero si está ejecutando una puesta en marcha,  vale la pena sacrificarse por la velocidad de implementación.

Resumen

Siempre es bueno ver que se agregan más funciones a AWS Lambda y las soluciones sin servidor. Sin embargo, las nuevas URLs de la función AWS Lambda dejan mucho que desear en sus controles de acceso e implementación de DNS.

Con suerte, obtendremos DNS personalizado como una característica en un futuro cercano para que no tengamos que usar los alias de AWS y las URL proporcionadas por AWS.

Si le interesa, puede echar un vistazo a algunos de los otros artículos que he escrito recientemente sobre Laravel:

• Hoja de ruta para desarrolladores de Nodejs 2022
• Simulando el entorno de AWS localmente con AWS Localstack