TL;DR
Las últimas novedades de AWS (Amazon RDS Proxy, provisionamiento de concurrencia en AWS Lambda, discos EFS en Lambda…) permiten ejecutar, sin casi esfuerzo de migración, tus aplicaciones PHP en funciones AWS Lambda (sin servidor) en lugar de usar instancias AWS EC2 o contenedores. Es un buen momento para experimentar y desplegar alguna aplicación PHP existente en AWS Lambda para medir su rendimiento y estimar el coste de la nueva arquitectura. ¿Te animas?

Introducción
Este post no es una recomendación para que migres ya hoy mismo tus aplicaciones PHP Laravel a funciones AWS Lambda. Es una recomendación para experimentar con alguna aplicación ya existente de tu organización, analizando los pros/contras, ejecutarla en AWS Lambda sin casi esfuerzo a modo de prueba, medir su rendimiento, estimar el coste de la nueva arquitectura y finalmente, tomar una decisión sobre si conviene hacer la migración o no.


Fuente: Amazon

Ventajas a priori
Elasticidad. Si la demanda de uso de tu aplicación tiene fluctuaciones a lo largo del tiempo, por muy bien que hayas definido las reglas de autoescalado de las instancias EC2, AWS Lambda se ajustará más rápido a esas variaciones de la demanda.
Menos mantenimiento.

Incertidumbres (pendientes de medir en tu aplicación)
Rendimiento. En AWS Lambda podemos configurar el tiempo máximo de CPU y el espacio máximo de memoria, pero no conocemos qué recursos de CPU se asignan. En teoría, los recursos de CPU aumentan cuando se reserva más memoria, así que deberemos experimentar con diferentes configuraciones de memoria RAM. Además, no siempre la opción de menos memoria será la más barata (ver punto siguiente).
Coste. El modelo de pricing de AWS Lambda depende de 3 factores: nº de ejecuciones, tiempo de ejecución y memoria reservada. Por ejemplo, 10.000.000, de duración 1 segundo cada una, con reserva de 128MB de RAM, tiene un coste total de 16 dólares aprox. Puedes hacer cálculos aquí, para estimar el ahorro o sobrecoste con respecto a tu arquitectura actual.

Desventajas antiguas (ya se han resuelto)
Desventajas que han desaparecido en los últimos meses.
Cold start. Cold start es la penalización de rendimiento que se sufre cuando no hay instancias de la función Lambda disponibles, y AWS tiene que instanciar una nueva función Lambda. El tiempo de cold start varía según el tamaño de la aplicación, lo mejor es medirlo en tu propia aplicación. Para evitar que esto suceda constantemente, AWS mantiene «viva» durante unos minutos las instancias de funciones Lambda, antes de apagarlas, por si en ese tiempo llega alguna petición que pueda reaprovechar dicha instancia. Aún así, pueden llegar peticiones que no encuntren una instancia libre y sufran el cold start. Para reducir esto, existen 2 opciones: 1) realizar periódicamente invocaciones a nuestras funciones Lambda, para mantenerlas «vivas» o 2) usar «provisioned concurrence», una opción reciente de AWS Lambda que mantiene siempre vivas un nº de instancias definido por el usuario.
Límite de conexiones a base de datos. Si cada instancia de AWS Lambda utilizaba una conexión de base de datos diferente (conexión a bbdd relacional), corríamos el riesgo de agotarlas rápidamente. Esto ha quedado resuelto con Amazon RDS Proxy, que se encarga de reutilizar las conexiones para no agotarlas.
Espacio limitado. Nuestra aplicación debe ocupar descomprimida menos de 250MB. Además, en la carpeta /tmp de la función lambda caben 512MB (el contenido de dicha carpeta se reutiliza entre diferentes ejecuciones de la misma instancia de la función Lambda, pero no entre diferentes instancias de AWS lambda). Si necesitásemos más espacio, ahora podemos configurar Lambda para utilizar un disco EFS.
Mayor dependencia de la nube. En este post no estamos cambiando nada de nuestra aplicación que nos impida ejecutarla en otro proveedor de cloud o en on-premise.

Desventajas actuales
Configuraciones. Si tu aplicación necesita realizar configuraciones a nivel de Sistema Operativo o configuraciones en servidor de aplicaciones web PHP concreto, esta propuesta no sirve. En este ejemplo, se utiliza Bref (que usa para la ajecución de PHP FastCGI Process Manager, FPM).
Límites. Por defecto, el límite de concurrencia en AWS Lambda es de 1.000 funciones Lambda por cuenta y por región. Puede solicitarse ampliación hasta cientos de miles por región. Esto es más que suficiente para muchísimos proyectos, pero es un límite a tener en cuenta. Más info sobre escalado de AWS Lambda y burst limit aquí.
Tiempo máximo de ejecución en AWS Lambda es 15 minutos. A tener en cuenta si queremos usar job batching.
Cuello de botella en base de datos. En este post hemos hecho más escalable la aplicación PHP pero no la base de datos. Para una arquitectura totalmente Serverless, deberíamos realizar modificaciones en la base de datos. Algunas alternativas a estudiar son: uso de Aurora DB Cluster o Aurora Serverless.

Tutorial para migrar una aplicación LAMP (ejemplo con PHP Laravel) a AWS Lambda + API Gateway + S3 + Proxy RDS:
https://aws.amazon.com/blogs/compute/introducing-the-new-serverless-lamp-stack/

Conclusión
Para decidir el cambio a AWS Lambda de una aplicación PHP, hay revisar los pros y contras evidentes y además experimentar con la aplicación real para determinar el impacto en rendimiento y coste. Y el mejor momento para experimentar es ahora, ya que las últimas novedades como RDS Proxy, provisioned concurrence y EFS en AWS Lambda han eliminado las principales desventajas; y proyectos como Bref hacen que ejecutar una aplicación PHP (o PHP Laravel) en AWS Lambda no requiera cambios. Es el momento de experimentar.

Fuentes:
https://aws.amazon.com/blogs/compute/introducing-the-new-serverless-lamp-stack/
https://github.com/aws-samples/php-examples-for-aws-lambda
https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/
https://calculator.aws/
https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html