# Escalar aplicação web na AWS: os 4 requisitos antes de subir

> Sessão em memória, assets, container e arquivos em disco: veja o que impede uma aplicação web de escalar na AWS e como resolver cada um.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Migração, Containers
- URL: https://pages.formacaoaws.com.br/blog/escalar-aplicacao-web-na-aws/
- Aula de origem: "Como rodar e escalar uma aplicação WEB na AWS sem grandes mudanças" (https://www.youtube.com/watch?v=mUyOOe-NgQM)

Uma aplicação web só escala na AWS se quatro pontos estiverem resolvidos: onde fica a sessão do usuário, onde ficam os assets, se ela roda em container e onde ficam os arquivos que o usuário envia. O último é o que mais trava, e tem solução na própria nuvem.

Gravei esta aula em 31 de março de 2023. Os serviços citados continuam existindo, mas confira as telas e as opções na documentação oficial da AWS antes de configurar: [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/), [Amazon ECS](https://docs.aws.amazon.com/ecs/) e [Amazon EFS](https://docs.aws.amazon.com/efs/).

## O cenário: uma aplicação .NET em uma máquina

Parto de uma aplicação web em .NET Core rodando em Linux. Poderia ser Node, Java ou Rails, não muda o raciocínio. Deixo o banco de fora: ele se resolve com o RDS em Multi-AZ ou com o Aurora.

A aplicação tem três características que, à primeira vista, parecem impedir a ida para a nuvem. Ela autentica o usuário, guarda a autenticação em memória, recebe o upload de fotos que ficam na pasta `/fotos` e serve arquivos da pasta `/assets`.

![A aplicação .NET com autenticação e upload, gravando as fotos na pasta /fotos, no disco da própria máquina](https://pages.formacaoaws.com.br/blog/assets/posts/escalar-aplicacao-web-na-aws/aplicacao-no-servidor.svg)

Ao subir na AWS, a aplicação roda em duas EC2 atrás de um balanceador de carga. É aí que cada característica vira um problema, ou não.

## Requisito 1: tire a sessão da memória da máquina

Se a autenticação fica na memória e há duas máquinas, o usuário se autentica na máquina 1 e a próxima requisição cai na máquina 2. Ali a informação não existe e a autenticação é derrubada.

É o mais fácil dos quatro. Use o **Amazon ElastiCache**, integrado a uma biblioteca da tecnologia que você usa, e mande os dados de autenticação para lá. As duas máquinas passam a consultar o mesmo lugar.

## Requisito 2: deixe os assets onde estão

Os assets na máquina não impedem a aplicação de escalar. O deploy entrega o mesmo pacote para a máquina 1 e para a máquina 2, e os assets ficam iguais nas duas.

Depois você pode colocar um CDN na frente, para deixar essa informação em cache, ou redesenhar para levá-los ao S3. Mas isso é melhoria, não pré-requisito.

## Requisito 3: coloque a aplicação em container

Do jeito que está, a aplicação roda na nuvem. O que o container resolve é o mapeamento e o teste: o que roda na sua máquina fica compatível com o que roda na AWS, porque você já descreveu os requisitos para rodar a aplicação e gerou uma imagem dela.

A vantagem prática é poder usar o **Amazon ECS**: a imagem fica guardada no ECR e o ECS monta um cluster para a aplicação. Você ganha uma forma mais homogênea e melhor gerenciada de rodar e de escalar. O desafio existe, mas não é grande: a contenerização é só entender os requisitos da sua aplicação. Para o passo a passo, leia [primeiro container em produção no ECS](https://pages.formacaoaws.com.br/blog/primeiro-container-em-producao-no-ecs/) e [o que é Docker](https://pages.formacaoaws.com.br/blog/o-que-e-docker/).

## Requisito 4: arquivos enviados pelo usuário fora do disco da EC2

Este é o maior gargalo. O usuário se autentica na máquina 1, sobe a foto de perfil e ela é gravada em `/fotos` no disco dessa EC2. Na requisição seguinte ele cai na máquina 2, a pasta `/fotos` dela não tem a foto e o carregamento falha. Cada EC2 tem o seu disco.

O que costumam dizer é para reescrever o upload com o SDK da AWS e gravar no S3. Funciona, e é até a melhor forma. Mas nem sempre é a mais prática: o upload é só uma das operações, a leitura e outras também precisam mudar, e isso pode impedir a aplicação de ir para a nuvem. Quem diz que, por isso, ela não escala está errado. Esse requisito se resolve na nuvem.

O problema técnico é o disco estar dentro da máquina. A solução é um disco externo e elástico, presente na zona A e na zona B, com os dados replicados automaticamente entre as zonas e gerenciados pela AWS. Esse disco é o **Amazon EFS**.

Você monta o `/fotos` nele. Quando o usuário sobe a foto pela máquina da zona A, ela já está disponível quando a requisição cai na zona B. Ao adicionar mais uma instância ao cluster, o mapeamento do disco é feito automaticamente. Se quiser a comparação entre S3 e disco elástico, leia [Docker com alta disponibilidade na AWS](https://pages.formacaoaws.com.br/blog/docker-alta-disponibilidade-na-aws/).

![Duas EC2 em zonas diferentes dentro do cluster ECS, as duas gravando a pasta /fotos no mesmo disco elástico (EFS)](https://pages.formacaoaws.com.br/blog/assets/posts/escalar-aplicacao-web-na-aws/desenho-final.svg)

**Fluxo:** Sessão (em cache, fora da máquina) → Assets (no pacote do deploy) → Container (imagem no ECR, cluster no ECS) → Arquivos (disco elástico entre as zonas)

## O que mudou na aplicação

No fim, a aplicação que parecia inviável de levar para a nuvem foi do jeito que estava, com operações relativamente simples: a autenticação foi para o ElastiCache, os assets ficaram onde estavam, ela virou container e a pasta de fotos foi para o disco elástico.

O requisito mais importante, na minha opinião, é a contenerização. Dominando o processo, ela não é difícil, e vale conhecer o que impede uma aplicação de escalar antes de aceitar que ela não vai para a nuvem. Para ver essas ideias aplicadas em outro caso, 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 onde a aplicação guarda a autenticação do usuário.
- Se for em memória, mande esses dados para o ElastiCache.
- Verifique que os assets vão no pacote do deploy; CDN ou S3 ficam para depois.
- Mapeie o que a aplicação precisa para rodar e gere a imagem em container.
- Use o ECS para rodar a aplicação como cluster.
- Liste as pastas onde a aplicação grava arquivos do usuário.
- Mova essas pastas para o disco elástico (EFS), em vez do disco da EC2.
- Só então adicione mais instâncias ao cluster.

Se a sua aplicação grava arquivos em disco e você não tem certeza do que impede ela de escalar, vale conversar antes de reescrever qualquer coisa.