Colocando um site na nuvem da Amazon: o que realmente acontece quando você entra no console
AWS é gigantesca e confusa de propósito. Se você quer hospedar algo lá, o primeiro erro que todo mundo comete é tentar escolher o serviço certo antes de saber o que está fazendo. O resultado é sempre o mesmo: uma conta com dez recursos criados, nenhum funcionando, e uma fatura no final do mês que faz perguntas difíceis. Vou explicar do jeito que funciona na prática. Não do jeito que o site deles descreve.
hospedagem amazonia para projetos que não são jogos de escala
A maioria das pessoas que chega aqui quer hospedar um site, uma API ou um sistema pequeno. Para isso, o caminho mais direto é o Amazon Lightsail. Ele custa entre 3,50 e 20 dólares por mês, vem com IP fixo, DNS integrado e uma interface que não exige três certificações para configurar. É o que eu uso para projetos de cliente que precisam subir rápido e sem dor de cabeça. Se o seu projeto cresce e você começa a precisar de balanceamento de carga, instâncias escaláveis automaticamente e serviços gerenciados, aí sim migra para EC2 com Auto Scaling e Load Balancer. Mas não pula essa etapa. Já vi gente começar no EC2 puro e gastar quatro horas apenas entendendo VPC, sub-redes públicas e privadas, security groups e NAT gateways antes de colocar qualquer coisa no ar.
O meu caso recente: precisei migrar um sistema legado que tinha arquivos gerados localmente em um diretório específico do servidor. A AWS não mantinha esse estado entre reinicializações porque eu estava usando uma instância EC2 padrão sem volume persistente configurado corretamente. O problema real era que o sistema escrevia logs e uploads em /var/www/uploads e, toda vez que o auto scaling criava uma nova instância, aquele diretório vinha vazio. A solução foi simples mas demorei dois dias para perceber: configurei um EBS volume attachado manualmente e fiz um script de mount no cloud-init que executa na inicialização. Assim, todo novo instance herda os dados. Levei uma manhã inteira para testar isso em ambiente de staging antes de aplicar em produção.
EC2: o básico que todo mundo esquece
EC2 é virtualização. Você aluga um servidor e instala o que quiser. A escolha de região importa mais do que muitos pensam. Se seus usuários estão no Brasil, use São Paulo (sa-east-1) ou São Paulo Norte (sa-east-2). A latência entre São Paulo e Frankfurt, por exemplo, é cerca de 180ms. Isso é perceptível em aplicações interativas. Security groups funcionam como firewalls em nível de instância. Por padrão, nenhuma porta entrada está aberta. Você precisa explicitamente liberar 80 para HTTP e 443 para HTTPS. Já deixei passar horas debugando porque esqueci de adicionar uma regra de entrada no security group depois de configurar corretamente o nginx no servidor. O servidor estava rodando, a aplicação respondendo, mas nada vinha de fora.
Tipos de instância seguem uma lógica que merece atenção. T2 e T3 são burstable, ideais para ambientes de desenvolvimento e tráfego baixo com picos ocasionais. Cada instância acumula créditos de burst que são consumidos quando a CPU sobe acima de 10% baseline. Se seu trabalho é constante, os créditos acabam e a instância throttla. nesse ponto, migrar para M5 ou C5 faz mais sentido do que aumentar o tamanho do T3 indefinidamente.
Armazenamento e dados persistentes
Volume EBS é armazenamento persistente vinculado a uma instância. Diferente do armazenamento de instância (ephemeral), dados em EBS sobrevivem a stop/start e até migração entre hardware. O custo é por GB provisionado por mês, independente do quanto você realmente usa. Um volume gp3 de 100GB custa cerca de 8 dólares mensais em sa-east-1, mesmo que você use apenas 20GB. S3 é o serviço de objeto mais usado na plataforma. Para hospedagem estática, você configura o bucket como website e coloca index.html e error.html. Custa centavos por mês para sites pequenos. A limitação é que S3 não roda backend — apenas arquivos estáticos e redirecionamentos. Para PHP, Node, Python com framework, você precisa de uma instância EC2 ou container gerenciado por ECS ou Elastic Beanstalk.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Custos: o lado que ninguém mostra no tutorial
A AWS cobra por praticamente tudo de forma independente. Instância, tráfego de saída, requisições API, storage, DNS, load balancer. Um Application Load Balancer custa cerca de 22 dólares fixos por mês mais 0,0225 dólares por LCUs e 0,008 dólares por_gb processados. Se você tem pouco tráfego, esse custo fixo pode ser maior do que a própria instância. O CloudWatch tier oferece 10 métricas personalizadas e 10 alarmes grátis por mês. Depois disso, cada métrica custa aproximadamente 0,30 dólares. Um monitoramento básico com disk usage, memory, CPU e network já chega em 4 métricas. Mais dois alarmes e você está no grátis. Qualquer coisa além disso começa a somar.
Configurei alertas de orçamento no AWS Budgets há anos. O valor padrão que recomendo é 80% da média dos três meses anteriores, com notificação por email. Isso evita surpresas. Sem isso, você descobre o estrago quando o cartão é cobrado.
RDS quando o banco começa a pesar
Instalar MySQL ou PostgreSQL dentro de uma instância EC2 funciona. Até o banco crescer, até precisar de backup automático, até o disco encher e você perceber que nunca configurou monitoramento de espaço. O RDS resolve isso. O MySQL db.t3.micro gratuito por 12 meses no tier free é suficiente para projetos pequenos. Após esse período, o custo sobe para cerca de 10 dólares mensais, mas você ganha multi-AZ option, backups automatizados, patches automáticos e monitoramento integrado. O problema prático do RDS é a configuração de rede. Ele precisa estar dentro de uma sub-rede privada para segurança adequada, e sua instância EC2 precisa acessar via VPC peering ou same VPC. Se você configurar errado o subgroup de banco, a instância simplesmente não consegue conectar e o erro mais comum nas mensagens de log é "Connection refused" ou "Host is not reachable", o que leva gente a culpar o firewall quando na verdade é o subnet group apontando para uma sub-rede errada.
O que eu faria diferente se começasse hoje
Não usaria CLI ou console manualmente. Ia começar com Infrastructure as Code desde o primeiro dia. Terraform ou CloudFormation reduzem o tempo de deploy de algo que leva horas para algo que leva minutos, e mais importante, tornam reproduzível. Um erro que cometi nos primeiros meses foi criar recursos manualmente em produção, esquecer quais portas estavam abertas em qual security group, e passar um final de semana inteiro tentando reconstruir a infraestrutura de memória quando precisei destruir e recriar tudo após uma falha de segurança. Usei mais de uma semana recuperando configurações que não haviam sido documentadas em lugar nenhum. Desde então, tudo no Terraform. O custo inicial de aprender a ferramenta compensa na terceira vez que você precisa reprovisionar um ambiente.
Alternativas que fazem sentido em alguns casos
Se o seu projeto é um site simples, WordPress ou similar, talvez Vercel, Netlify ou até hospedagem compartilhada tradicional seja mais barato e mais simples. A AWS brilha quando você precisa de controle, escalabilidade horizontal e serviços gerenciados. Não brilha em simplicidade. A curva de aprendizado é real e o tempo gasto entendendo a plataforma pode ser o dobro do tempo gasto desenvolvendo a aplicação em si. Para quem está começando e o orçamento é apertado, o EC2 free tier de 750 horas por mês durante 12 meses cobre uma t2.micro ou t3.micro rodando 24 horas por dia. Depois desse período, o custo sobe para cerca de 8 a 10 dólares mensais dependendo da região. O Lightsail a 3,50 dólares é ainda mais em conta para quem não precisa de serviços gerenciados.
O que define se vale a pena não é preço. É controle. Se você precisa controlar rede, instância, banco, cache e filas separadamente, a AWS entrega isso. Se precisa apenas colocar um site no ar e esquecê-lo, existem opções mais diretas.
