Resposta curta: Não desconte o t1.micro - é uma instância com capacidade e pode executar um site PHP - mas se você não conseguir fazer funcionar com um t1.micro, obtenha uma instância maior (como oposta a múltiplas t1.micros).
Long Answer: A instância t1.micro é bastante capaz de gerar conteúdo dinâmico - e pode ser executada de forma bastante suave, servindo vários sites pequenos. Para uma configuração bem otimizada (digamos Wordpress com cache), eu diria que o t1.micro deve lidar com pelo menos 50k acessos / mês, se não mais. Uma das principais idéias, porém, é que as coisas estão bem otimizadas - uma instalação padrão do Apache derrubará um t1.micro razoavelmente rápido - já que cada requisição gera um novo processo - com toda a sobrecarga associada.
Além disso, o t1.micro não tem espaço de troca por padrão (pode ser útil configurar um volume de 1 GB do EBS para usar como espaço de troca - mais como uma medida de segurança do que para realmente usá-lo. muito, então algo precisa mudar.
Se você for executar várias instâncias, desaconselhamos várias instâncias de t1.micro. O desempenho por dólar é muito melhor nas instâncias maiores (memória, E / S e CPU). Um dos outros pontos sobre o t1.micro é que, enquanto você pode 'explodir' CPU adicional, os ciclos também podem ser 'roubados'. Definitivamente vá com uma instância de 32 bits se você estiver indo para a rota t1.micro - a sobrecarga adicionada de registradores de 64 bits simplesmente levará a instância a ficar sem memória mais fácil, sem qualquer ganho de desempenho tangível.
Se possível, eu recomendaria usar o php-fpm em vez de mod_php - embora um pouco mais lento, é capaz de suportar um volume muito maior de tráfego com menos carga na instância. Além disso, se possível, descarregue a entrega de conteúdo estático. Para o último, você pode usar um CDN como o Cloudfront (ou até mesmo usar o S3) - a ideia é que esses pedidos não consomem a largura de banda, o disco de E / S ou o poder de processamento (ou memória) da instância. Como alternativa, você pode usar um servidor front-end leve (por exemplo, nginx) para manipular conteúdo estático e, em seguida, fazer proxy de solicitações dinâmicas para o apache (se você não puder alternar totalmente para usar esse servidor front-end) - isso aumenta a complexidade setup - mas especialmente se suas páginas são armazenadas em cache (ou seja, versões estáticas geradas sempre que a página é alterada), o ganho de desempenho pode ser substancial. Também pode ser aconselhável armazenar em cache o conteúdo dinâmico com um servidor front-end (a duração dependerá da popularidade do site) - para evitar o processamento desnecessário de solicitações dinâmicas.
Uma sugestão final - que pode não ser possível - considere o uso do Linux da Amazon como seu sistema operacional em vez do Ubuntu. Eu descobri que ele é extremamente leve e eficiente em um t1.micro - ele vem com o mínimo de pacotes instalados e tem uma pegada muito pequena.
Executar um site dyanmic em um t1.micro certamente é possível - eu executei vários sites pequenos (Wordpress / Drupal / Joomla) em um único t1.micro - ambos usando nginx / apache / php-fcgi e verniz / nginx / php-fpm - incluindo um servidor de e-mail (postfix), imap (dovecot), banco de dados (mysql) e servidor ftp (pure-ftp / vsftp) - com desempenho decente (carregamento de sites do Wordpress em 1-2s), baixo médias de carga (normalmente abaixo de 0,1, a pedido a cada 15s) e cerca de 150-200MB de memória usada). Não seria minha escolha por desempenho, mas é a solução menos onerosa para um site que simplesmente precisa estar on-line de maneira confiável, sem esperar muito tráfego.
Eu diria que o t1.micro é uma plataforma muito boa para trabalhar em suas habilidades de otimização - ele permite que você veja o quanto você pode obter o mínimo possível e quais otimizações serão mais caras do que valem. Se, no entanto, o seu site for simplesmente muito grande para um único t1.micro, use uma instância maior e não instâncias t1.micro adicionais (a menos que sua finalidade específica seja failover - mas as chances são nesse estágio de que você usará instâncias maiores de qualquer maneira). . Não faça o balanceamento de carga de instâncias t1.micro - há muito pouco a ganhar com essa abordagem - uma instância maior servirá melhor a você. No entanto, você definitivamente quer descobrir por que essas instâncias estão morrendo - eu apostaria que é um problema de memória, em vez de uma CPU. Você definitivamente quer tentar lançar uma cópia do seu site, e executar ab (ou seige , etc) sobre ele e ver o que o servidor pode suportar - e se é ou não o design do aplicativo (que você provavelmente não pode mudar) ou a configuração do servidor.
(A menos que você esteja usando instâncias spot, você pode atualizar o tipo de instância com bastante facilidade - basta parar (não terminar) e usar ec2-modify-instance-attribute para alterar o tipo, antes de reiniciar).