O cenário que você descreve (um servidor executando o apache e outro armazenando arquivos) não oferece nenhum backup real - sem dúvida, ele duplica a chance de falha (agora você tem duas máquinas e, se falhar, todo o sistema não funcionará ).
Se você está apenas começando com o EC2, a abordagem mais simples para obter uma funcionalidade semelhante seria ter seus dados armazenados em uma unidade EBS e ter uma instância personalizada salva como uma AMI. A partir daí, você poderia configurar o escalonamento automático para manter uma instância em todos os momentos - se uma instância falhar, outra pode ser colocada online com base na sua AMI e você pode usar um instantâneo (levemente desatualizado) ou mover o volume do EBS para tudo de volta e funcionando (o que pode ser automatizado).
Se você está apenas servindo arquivos estáticos, então você pode acabar com o EC2 completamente e simplesmente usar o S3 - ele irá fornecer a escalabilidade e redundância (interna) que você deseja. Se, no entanto, você estiver usando bancos de dados, não é uma boa idéia armazená-los no S3, pois eles incorrerão em uma perda significativa de desempenho.
Se você estiver realmente procurando uma configuração de failover, desejará que sua configuração funcione mesmo que uma instância falhe. Com duas instâncias, isso implicaria que ou a) cada uma é auto-suficiente, ou b) quando uma falha, outra instância equivalente será colocada online.
A diferença de potencial existente entre a configuração de failover descrita acima e um cluster de escalonamento automático está no grau de controle que você tem. Embora o Cloudwatch (e, portanto, o escalonamento automático) ofereça suporte a métricas personalizadas, outras soluções permitem maior versatilidade em sua implementação. Por exemplo (e puramente teórico), você pode configurar um cluster de 2 nós (por exemplo, no VPC da Amazon) e usar o Heartbeat / Corosync para monitorar o status de cada instância, com o Pacemaker gerenciando recursos (por exemplo, se o seu apache falhar em vez de toda a instância, alguma ação pode ser tomada). Os arquivos podem ser compartilhados entre as instâncias com um rsync simples (se não houver muita alteração) ou com um sistema de arquivos distribuído (por exemplo, Gluster). Uma instância seria eleita a "líder" e pode executar um balanceador de carga (por exemplo, nginx, HAProxy, etc) e enviar solicitações para uma instância ou outra. Esse design não é isento de problemas (e certamente requer um bom esforço de configuração), mas pode fornecer alguma ideia de uma arquitetura potencial.
Para responder à pergunta conforme solicitado (o que equivale essencialmente a como acessar arquivos remotos localmente). Você pode ir com:
- Uma abordagem de armazenamento compartilhado (arquivos armazenados no S3, que é montado localmente usando fusível)
- Um sistema de arquivos de rede (por exemplo, o Gluster - sistema de arquivos remoto acessível a instâncias em rede)
- Sistema de arquivos remoto acessado localmente (por exemplo, sshfs - abordagem baseada em fusível para acessando / montando o sistema de arquivos remotos em ssh / sftp)
Com praticamente qualquer abordagem escolhida, você precisará abrir as portas do grupo de segurança para permitir a comunicação entre as instâncias. Você pode restringir o acesso a essas portas apenas a outras instâncias do mesmo grupo de segurança.