# Docker com alta disponibilidade na AWS: o que mudar na aplicação > Para escalar uma aplicação em container para várias instâncias, tire o banco do servidor e os arquivos do volume. Veja os caminhos na AWS. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Containers - URL: https://pages.formacaoaws.com.br/blog/docker-alta-disponibilidade-na-aws/ - Aula de origem: "O que fazer para sua aplicação com Docker ser Altamente Disponível" (https://www.youtube.com/watch?v=FENB-3LJP9U) Colocar a aplicação em Docker não a deixa altamente disponível. Para rodar em várias instâncias, ela precisa de duas mudanças: o banco de dados sai de dentro do servidor e os arquivos saem do volume local. Aqui estão as duas, com os caminhos que a AWS oferece para cada uma. Publiquei o vídeo em 12 de agosto de 2021, como continuação da introdução ao Docker, e parto do princípio de que sua aplicação já roda em container. Se não for o caso, comece por [o que é Docker](https://pages.formacaoaws.com.br/blog/o-que-e-docker/). ## O ponto de partida: tudo dentro de um servidor O cenário é o mais comum de quem acabou de adotar container. Há um servidor, que pode ser uma instância EC2, e dentro dele a aplicação web em container e o banco de dados, também em container. O que escala é a parte web. É nela que você quer ter três, quatro ou N cópias. Só que, do jeito que está, cada cópia levaria junto o banco e os arquivos, e aí nada funciona. Por isso são duas separações. ![Um servidor com a aplicação web (W) e o banco de dados (D) lado a lado, dentro dele](https://pages.formacaoaws.com.br/blog/assets/posts/docker-alta-disponibilidade-na-aws/ponto-de-partida.svg) ## Passo 1: tire o banco de dentro do servidor O banco não pode ficar no mesmo lugar da aplicação que vai se multiplicar. Na AWS você tem dois caminhos: - **Uma instância EC2 separada**, só com o banco. - **Um serviço de banco gerenciado, como o Amazon RDS.** O RDS tem requisitos e configurações que dão alta disponibilidade ao banco, e o Amazon Aurora também ajuda nisso. ![A aplicação web (W) sozinha no servidor e o banco fora dele, no Amazon RDS](https://pages.formacaoaws.com.br/blog/assets/posts/docker-alta-disponibilidade-na-aws/banco-fora.svg) Com isso, o primeiro problema está resolvido. Os dados do banco deixam de pertencer a um servidor específico. ## Passo 2: entenda por que o volume local não escala A aplicação web costuma guardar conteúdo: arquivos de clientes, fotos. Se esses arquivos ficam dentro do container e ele para, você perde tudo. A solução óbvia é criar um **volume** ligado ao container. Os arquivos passam a ser escritos na instância EC2 e o container pode morrer sem levar as informações. Para uma instância só, resolve. O problema aparece quando você escala. Com três instâncias EC2, cada uma tem o seu volume. Um arquivo escrito numa delas fica disponível só ali. O tráfego é roteado para qualquer uma das três: se cair na instância que tem o arquivo, a aplicação o encontra. Se cair em outra, não encontra. Replicar esses arquivos o tempo todo entre os volumes para fazer isso funcionar não faz sentido. Essa estrutura tem um problema de desenho. > **Importante:** volume em cada instância protege contra a morte do container, mas não serve para escalar. Cada instância enxerga só os arquivos que ela mesma escreveu. ## Passo 3: grave os arquivos fora da instância A saída é remover os volumes de dentro das instâncias e fazer com que os arquivos sejam escritos fora delas. Existem outros caminhos, mas a aula mostra dois: 1. **Amazon S3.** 2. **Uma estrutura de armazenamento elástica.** Os arquivos são escritos simultaneamente e ficam num ponto central de comunicação com todos os containers. À medida que novos containers entram, eles conversam automaticamente com essa estrutura. ![Três servidores, cada um com a aplicação web (W), gravando os arquivos no S3](https://pages.formacaoaws.com.br/blog/assets/posts/docker-alta-disponibilidade-na-aws/arquivos-no-s3.svg) **Fluxo:** Tráfego (roteado entre as instâncias) → Instâncias EC2 (aplicação web em container) → Arquivos (S3 ou armazenamento elástico) → Banco (RDS, fora do servidor) Com o banco separado e os arquivos separados, a aplicação pode escalar para 3, 4 ou N instâncias. A partir daí, ela entra no cenário de alta disponibilidade. ## Passo 4: escolha entre S3 e armazenamento elástico A escolha depende do que você precisa mudar na aplicação. Imagine uma aplicação em PHP, com uma lógica que recebe o upload da foto do cliente e grava num caminho como `/usr/fotos`. Com o S3, você precisa reescrever essa lógica. Em vez de gravar nesse caminho, a aplicação passa a gravar no S3. Isso implica usar o SDK, trabalhar com credenciais e permissões e migrar os arquivos que já existem. Para uma aplicação que já está pronta, isso dificulta bastante a ida para a nuvem. Com o armazenamento elástico, o caminho `/usr/fotos` continua o mesmo. A forma de escrever os arquivos não muda e você não precisa redesenhar nada. Esse é o grande diferencial dele: levar a aplicação para a AWS do jeito que ela está. ## Onde isso se encaixa no resto do caminho Este é o passo seguinte a rodar a aplicação em container. Para ver como subir o container no serviço de containers da AWS, leia [primeiro container em produção no ECS](https://pages.formacaoaws.com.br/blog/primeiro-container-em-producao-no-ecs/). Para um caso real de aplicação que saiu de um servidor único e foi para banco gerenciado, arquivos no S3 e containers em duas zonas, leia [como sair da VPS e migrar para a AWS](https://pages.formacaoaws.com.br/blog/como-sair-da-vps-e-migrar-para-a-aws/). ## Checklist - Confirme que a aplicação já roda em container com Docker. - Tire o banco de dentro do servidor: EC2 separada ou RDS, com as configurações de alta disponibilidade. - Identifique o que a aplicação grava no disco: fotos, arquivos de clientes. - Não conte com volume por instância para escalar. - Escolha onde gravar os arquivos fora da instância: S3 ou armazenamento elástico. - Se escolher o S3, reserve tempo para reescrever a lógica de upload, com SDK, credenciais e permissões. - Só então aumente o número de instâncias. Se a sua aplicação grava arquivos em disco e você não sabe qual dos dois caminhos pesa menos, essa conversa vale antes de escalar.