Como foi mencionado, a hospedagem estática do S3 é um bom caminho a percorrer, mas requer um registro Alias hospedado no Route 53 ... e não suporta TLS.
O TLS (para navegadores compatíveis com SNI) para sites hospedados em um bucket do S3 pode ser fornecido usando o CloudFront na frente do S3, que funciona perfeitamente, mas também requer um Alias no Route 53.
Observe que um alias não é um tipo de registro DNS. Um Alias é uma diretiva de configuração interna nos servidores de DNS do Route 53 que diz "quando recebemos uma solicitação para este registro aqui, vamos internamente (no banco de dados do Route 53) procurar e retornar o mesmo Como resultado, teríamos retornado se tivéssemos realmente recebido um pedido de outro registro diferente. " No final, ele oferece uma funcionalidade que parece similar a um CNAME, mas em vez de dizer ao resolver para tratar um nome de host como equivalente a outro, e ir procurar o outro registro para obter mais informações, Route 53 faz essa etapa de pesquisa internamente, deixando o resolvedor sem saber o mecanismo real usado para satisfazer a solicitação ... e esse mecanismo de pesquisa interno (não externo) é o motivo pelo qual os registros do Alias funcionam conforme desejado no apex da zona, quando CNAMEs não.
A menos que você tenha um mecanismo DNS que possa se adaptar a endereços IP dinâmicos, como exigem sites de hospedagem no S3 e no CloudFront, não há uma maneira sólida de eliminar o SPOF, embora alguns outros provedores de DNS suportem um recurso semelhante aos registros Alias do Route 53 . CloudFlare, por exemplo, chama de "CNAME Flattening", onde o servidor DNS, quando recebe uma consulta para o seu A-Record, faz uma pesquisa no verso para um diferente A-Record ( em um domínio diferente, como s3.amazonaws.com ou cloudfront.net) e, em seguida, retorna essa resposta ao solicitante. Isso realiza o mesmo resultado líquido de um Alias. Ele não é realmente "interno" para o servidor DNS de terceiros, mas como a segunda solicitação é enviada pela parte de trás, o resolvedor do cliente não vê nada incomum no comportamento.
Em janeiro de 2015, AWS anunciou a recuperação automática de instâncias do EC2 , que desmontará e reconstruirá uma instância que falhará nas verificações de disponibilidade do Cloudwatch, criando uma nova instância com o mesmo "tudo" - ID da instância, volumes EBS, IP elástico, etc., e esse recurso funciona com várias classes de instância , incluindo a classe t2.
Ou, como último recurso, você poderia parcialmente aliviar o SPOF provisionando mais de uma dessas máquinas de redirecionamento e provisionando vários registros A no ápice da sua região para balanceamento de carga "round-robin". " Isso reduziria, mas não eliminaria, o impacto de uma indisponibilidade de uma das máquinas, embora a viabilidade de tal solução seja altamente dependente do comportamento do navegador. Não seria considerada uma solução de "alta disponibilidade", mas seria (talvez) melhor que nada.
In order to avoid another redirect I'd like to do TLS there if possible.
Se eu entendi este comentário corretamente, então, você realmente tem para fazer o TLS lá. Se eu apontar meu navegador para https://example.com , esse ponto de extremidade terá que falar TLS e ter um certificado válido para o nome do host, ou o link será efetivamente quebrado - um servidor não poderá redirecionar se Não é possível negociar o TLS de maneira a manter o navegador feliz.