Solución 1:
Amazon Linux es una distribución móvil, como Fedora o Debian Testing (más o menos). En mi opinión, no es adecuado para ningún producto de producción. Me sorprende que más personas no se den cuenta de esto. Esto significa que si lanzó su instancia de Amazon Linux, digamos, hace 450 días y realiza una actualización hoy, obtendrá actualizaciones de una versión completamente diferente. Una vez que se realiza una nueva versión, no tiene tiempo de búfer, inmediatamente comienza a extraer actualizaciones de la nueva versión. Como puede imaginar, esto puede generar una cascada de dependencias y tiene una tendencia a romper las cosas. Por esta razón, es inherentemente inmanejable. No puede incluir algo como esto en una política de actualización sin que sea un desastre absoluto. No use Amazon Linux para nada serio.
Ubuntu LTS es una buena elección, al igual que Debian Stable o CentOS. Todos ellos le brindan muchos años de actualizaciones de la misma versión.
Amazon Linux tampoco tiene ningún sistema de seguimiento de errores , los usuarios deben publicar preguntas en los foros de desarrolladores de AWS para presentar un error en un paquete. Tampoco hay forma de buscar errores. Esto debería ser un problema espectacular para casi todos.
Amazon Linux hace que sea muy difícil recuperar los paquetes fuente, innecesariamente.
Solución 2:
Desde que se escribió esta pregunta, Amazon se renovó por completo para Amazon Linux AMI 2011.09 , con todo el arranque para CloudFormation y las herramientas de Amazon.
Además, incluye Nginx y PHP-FPM en el yum repos si lo que busca es rápido y ligero.
Manténgase al día con los últimos lanzamientos aquí:http://aws.amazon.com/amazon-linux-ami/latest-release-notes/
También esté atento a las actualizaciones de seguridad :http://aws.amazon.com/amazon-linux-ami/security-bulletins/
Por lo general, tendrá menos de qué preocuparse, ya que la AMI base es un servidor básico con solo las herramientas necesarias para iniciar los servicios que realmente necesita.
Solución 3:
Yo estaba en una situación similar; servidor dedicado completamente administrado, LAMP, CentOS. Entonces decidimos pasar a EC2. Además, tenía muy poca experiencia en administración de sistemas o Linux. Tengo casi cero experiencia con Ubuntu, por lo que realmente no puedo hablar sobre cuál es el llamado mejor sistema operativo.
Probé un montón de AMI preconstruidas con instalaciones mínimas de SO de Rightscale, Alestic, Scalr y Amazon. Terminé construyendo todas mis propias AMI sobre Amazon Linux, primero usando la versión 2010.11.01, ahora he migrado todas mis AMI personalizadas a Amazon Linux versión 2011.03.01.
La decisión de optar por una AMI de Amazon Linux frente a los otros proveedores de AMI no fue fácil. Jugué y probé diferentes configuraciones durante casi un mes antes de tomar mi decisión final. Al final, como quería usar CentOS, básicamente se redujo a una cosa. Pensé quién mejor para saber qué dependencias relacionadas con el hardware debían incluirse en el sistema operativo que las personas que diseñaron, crearon y mantuvieron EC2. Nada contra Rightscale, Scalr o Alestic.
Seis meses después, aunque tuve algunos baches en el camino, Linux de Amazon se ha mantenido bastante estable. Sin embargo, decidí compilar parte del software que usamos desde la fuente (es decir, php 5.3, MySQL 5.5, etc.) porque tuve problemas con los paquetes prediseñados que Amazon mantenía en su repositorio de paquetes.
Solución 4:
Si ya está familiarizado con RHEL/CentOS, me quedaría con eso. No existe una distribución "mejor" para un servidor de aplicaciones web. Todo se reduce a las herramientas y convenciones con las que está más familiarizado.
Solución 5:
Aunque a Ubuntu le va mejor en estos puntos de referencia, las pruebas mismas contribuyen a que Ubuntu gane, y las diferencias no parecen ser grandes de todos modos.
Hace poco elegí Amazon Linux en gran parte debido a las actualizaciones automáticas y también al error de la AMI de Ubuntu informado por Steven y Ethan en la versión de Quora de esta pregunta.