Todas las cosas que mencionó, como el equilibrio de carga, la supervisión y el escalado automático, son definitivamente ventajas.
Sin embargo, debe pensarlo de esta manera: en una verdadera plataforma como servicio (PAAS), el objetivo es separar la aplicación de la plataforma. Como desarrollador, solo te preocupas por tu aplicación. La plataforma se le "alquila". Las "instancias" de la plataforma se actualizan, administran, escalan, equilibran, etc. automáticamente para usted. Simplemente sube tu archivo WAR y simplemente funciona (al menos en teoría).
EC2 por sí solo no es PAAS. Es más como IAAS ( Infraestructura como servicio ). Aún debe cuidar las instancias del servidor, instalar software en ellas, mantenerlas actualizadas, etc.
Elastic Beanstalk es un sistema PAAS. También lo son App Engine y Azure, entre muchos otros.
En un verdadero sistema PAAS, el DBMS es un componente separado de los servidores de aplicaciones web. La razón es obvia: el DBMS no se puede instalar en las instancias que se están utilizando para el servidor de aplicaciones porque, a medida que las instancias se crean y destruyen en función de su tráfico, ¡el DBMS se perderá! Tener el DBMS y el servidor de aplicaciones en la misma máquina / instancia generalmente no es una buena idea de todos modos.
En un sistema PAAS, el DBMS es un servicio separado. Para Amazon, sería Amazon RDS . Al igual que con Elastic Beanstalk, donde no tiene que preocuparse por el servidor de aplicaciones y simplemente carga su archivo WAR, con RDS, no tiene que preocuparse por el DBMS y simplemente implementa su (s) base de datos (s).
Elastic Beanstalk y RDS funcionan muy bien juntos, especialmente cuando se implementan en la misma zona de disponibilidad, donde la latencia sería muy baja.
Finalmente, usar Elastic Beanstalk no cuesta nada más que los recursos implementados (instancias EC2 y el balanceador de carga). Sin embargo, RDS no es barato y definitivamente sería más caro que usar una sola instancia EC2 tanto para el servidor de aplicaciones como para el DBMS.