Řešení 1:
Amazon Linux je průběžná distribuce, jako je Fedora nebo Debian Testing (tak nějak). Podle mého názoru není vhodný pro žádný produkční produkt. Divím se, že si to neuvědomuje více lidí. To znamená, že pokud jste spustili instanci Amazon Linux, řekněme před 450 dny a provedli aktualizaci dnes, budete stahovat aktualizace ze zcela jiného vydání. Jakmile je vytvořeno nové vydání, nemáte čas vyrovnávací paměti, okamžitě začnete stahovat aktualizace z nového vydání. Jak si dokážete představit, může to vést k kaskádě závislostí a má tendenci věci rozbít. Z tohoto důvodu je ze své podstaty nezvládnutelný. Něco takového nemůžete zapracovat do zásad aktualizací, aniž by to byl absolutní nepořádek. Nepoužívejte Amazon Linux pro nic vážného.
Ubuntu LTS je dobrá volba, stejně jako Debian Stable nebo CentOS. To vše vám poskytne mnoho let aktualizací stejného vydání.
Amazon Linux také nemá žádný systém sledování chyb , uživatelé musí posílat otázky ve Fórech pro vývojáře AWS, aby mohli nahlásit chybu v balíčku! Neexistuje ani způsob, jak hledat chyby. To by měl být zásadní problém pro téměř každého.
Amazon Linux zbytečně velmi ztěžuje načítání zdrojových balíčků.
Řešení 2:
Od doby, kdy byla tato otázka napsána, Amazon kompletně přepracoval pro Amazon Linux AMI 2011.09 s veškerým bootstrappingem pro CloudFormation a také s nástroji Amazon.
Zahrnuje také Nginx a PHP-FPM v yum repos, pokud hledáte rychlé a lehké.
Držte krok s nejnovějšími vydáními zde:http://aws.amazon.com/amazon-linux-ami/latest-release-notes/
Sledujte také aktualizace zabezpečení :http://aws.amazon.com/amazon-linux-ami/security-bulletins/
Obvykle budete mít méně starostí, protože základní AMI je čistý server s pouze nástroji potřebnými k zavedení služeb, které skutečně potřebujete.
Řešení 3:
Byl jsem v podobné situaci; plně spravovaný dedikovaný server, LAMP, CentOS. Pak jsme se rozhodli přejít na EC2. Také jsem měl velmi málo zkušeností se správou systémů nebo linuxu. S Ubuntu mám téměř nulové zkušenosti, takže opravdu nemohu mluvit o tom, který je takzvaně lepší OS.
Vyzkoušel jsem spoustu předem sestavených AMI s minimálními instalacemi OS od Rightscale, Alestic, Scalr a Amazon. Nakonec jsem postavil všechna svá vlastní rozhraní AMI na Amazon Linux, nejprve pomocí verze 2010.11.01, nyní jsem všechna svá vlastní rozhraní AMI migroval na verzi Amazon Linux 2011.03.01.
Rozhodnutí použít Amazon Linux AMI vs. ostatní poskytovatelé AMI nebylo snadné. Hrál jsem si a testoval různá nastavení téměř měsíc, než jsem učinil své konečné rozhodnutí. Nakonec, protože jsem chtěl používat CentOS, v podstatě se to scvrklo na jednu věc. Usoudil jsem, že kdo lépe ví, jaké hardwarové závislosti je třeba zahrnout do operačního systému, než lidé, kteří navrhli, postavili a udržovali EC2. Nic proti Rightscale, Scalr nebo Alestic.
O šest měsíců později, i když jsem narazil na několik nerovností, byl Linux od Amazonu docela stabilní. Rozhodl jsem se však zkompilovat část softwaru, který používáme, ze zdroje (např. php 5.3, MySQL 5.5 atd.), protože jsem se dostal do problémů s předem sestavenými balíčky, které Amazon uchovával ve svém úložišti balíčků.
Řešení 4:
Pokud již znáte RHEL/CentOS, zůstal bych u toho. Pro server webových aplikací neexistuje žádné „nejlepší“ distro. Jde o to, jaké nástroje a konvence nejlépe znáte.
Řešení 5:
Ačkoli si Ubuntu v těchto benchmarkech vede lépe, samotné testy přispívají k vítězství Ubuntu a rozdíly se stejně nezdají být velké.
Nedávno jsem si vybral Amazon Linux z velké části kvůli automatickým aktualizacím a také kvůli chybě Ubuntu AMI, kterou Steven a Ethan nahlásili ve verzi Quora této otázky.