Moodle na AWS vs Hospedagem Gerenciada: Custo Real

Colocar o Moodle na AWS parece uma decisão de infraestrutura, mas é, antes de tudo, uma decisão de responsabilidade. A fatura do EC2 é a parte fácil de comparar — e quase nunca é a maior parte da conta. Este artigo abre os dois modelos com números publicados: o que a AWS cobra, o que ela explicitamente não faz por você e em que ponto a hospedagem gerenciada fica mais barata na conta inteira.

TL;DR

• A AWS não hospeda seu Moodle. Ela aluga máquina. Pelo modelo de responsabilidade compartilhada, o sistema operacional convidado, os patches de segurança e a aplicação são responsabilidade do cliente.
• A fatura visível engana. Uma t3.medium em São Paulo custa US$ 0,0672/hora, mas egress a US$ 0,15/GB, NAT Gateway a US$ 0,045/hora e suporte com mínimo de US$ 100/mês costumam somar mais que a instância.
• O calendário do Moodle não espera. O suporte geral do Moodle 5.1 termina em 5 de outubro de 2026 — a mesma data em que sai o Moodle 5.3, a próxima LTS.
• A pergunta certa não é "quanto custa o servidor", é "quem acorda às 3h da manhã".

O que entra na conta quando você sobe Moodle na AWS

A conversa sobre custo de Moodle na AWS quase sempre começa errada. Alguém abre a calculadora, escolhe uma instância, vê um número de dois dígitos em dólar e conclui que "é barato". Esse número é o piso, não o preço.

A parte visível da fatura

• EC2 (computação). Na região South America (São Paulo), a t3.medium — 2 vCPU e 4 GiB — sai a US$ 0,0672/hora sob demanda, segundo levantamento de junho de 2026 sobre as tarifas públicas da AWS. A mesma instância custa US$ 0,042/hora em us-east-1. São Paulo é cara, e é onde a latência para o seu aluno faz sentido.
• EBS (disco). O volume gp3 fica em torno de US$ 0,08 por GB-mês em São Paulo, com 3.000 IOPS e 125 MB/s de baseline inclusos.
• Banco de dados. Ou você sobe um MariaDB na própria EC2 (mais barato, mais trabalho) ou usa RDS (mais caro, menos trabalho). O db.t3.medium parte de cerca de US$ 0,068/hora nas regiões mais baratas — e São Paulo é uma das mais caras do catálogo.

A parte que ninguém coloca na planilha

• Egress. Os primeiros 100 GB por mês são gratuitos e compartilhados entre regiões e serviços. Depois disso, São Paulo é a região mais cara do mundo para saída de dados: US$ 0,15/GB. Um Moodle servindo videoaula do próprio servidor estoura isso em dias.
• NAT Gateway. Fazendo a arquitetura "certa", com aplicação em subnet privada, você paga US$ 0,045/hora só para o gateway existir — cerca de US$ 32/mês, sem um byte trafegado — mais US$ 0,045 por GB processado. Não há free tier.
• Créditos de CPU. As t3 são burstable. No modo Unlimited (o padrão), quando a média de CPU em 24 horas passa do baseline, a AWS cobra US$ 0,05 por vCPU-hora excedente. Moodle com cron pesado e relatório de notas passa do baseline com facilidade.
• Suporte. O plano Business legado cobra por faixas do gasto (10%, 7%, 5%, 3%) com mínimo de US$ 100/mês, e será descontinuado em 1º de janeiro de 2027, junto com Developer e Enterprise On-Ramp. Sem plano pago, você não abre chamado técnico.
• Câmbio. A fatura é em dólar; seu orçamento acadêmico é em real. Essa diferença tem custo e tem variância.

Nada disso é armadilha da AWS. É o modelo dela: componentes granulares, cobrados um a um, montados por você. O erro está em comparar esse modelo com um serviço gerenciado como se fossem a mesma coisa.

O que o Moodle exige do servidor em 2026

Versões, PHP e um calendário que não espera

O Moodle 5.1, de 6 de outubro de 2025, exige PHP 8.2 no mínimo (com suporte a 8.2.x, 8.3.x e 8.4.x), extensão sodium, max_input_vars ≥ 5.000 e PHP de 64 bits. No banco: PostgreSQL 15+, MySQL 8.4+, MariaDB 10.11+ ou SQL Server 2017+. O caminho de upgrade só parte de instalações 4.2.3 ou superiores — quem está muito atrás precisa de saltos intermediários.

O calendário oficial, publicado pelo Moodle Developer Resources, é o dado que mais pesa numa decisão de hospedagem:

Versão	Lançamento	Fim do suporte geral	Fim do suporte de segurança
Moodle 5.2	20/04/2026	19/04/2027	04/10/2027
Moodle 5.1	06/10/2025	05/10/2026	19/04/2027
Moodle 5.0	14/04/2025	20/04/2026	05/10/2026
Moodle 4.5 (LTS)	07/10/2024	06/10/2025	04/10/2027

A cadência é fixa: versão maior a cada seis meses (abril e outubro), correções menores a cada dois. A próxima LTS é o Moodle 5.3, previsto para 5 de outubro de 2026 — o mesmo dia em que o 5.1 sai do suporte geral. Traduzindo para a operação: se você subiu Moodle na AWS e não tem alguém responsável por planejar upgrade duas vezes por ano, o ambiente envelhece sozinho. A documentação de segurança do Moodle é direta: quanto mais antiga a versão, mais vulnerabilidades ela provavelmente contém. Destrinchei esse ciclo em Moodle UFBA: versão, LTS e upgrade do AVA em 2026.

RAM, cron e o pico da segunda-feira

A documentação oficial usa uma regra de bolso conservadora: 10 a 20 usuários simultâneos por GB de RAM. E "simultâneo" ali não é gente logada — são processos do servidor web vivos na memória na mesma janela de poucos segundos. Uma instituição com 800 matriculados pode ter 120 simultâneos numa entrega de atividade e 8 numa terça à tarde.

Por isso dimensionar Moodle na AWS é traiçoeiro: o gráfico de acesso não é reta, é serra. Tem pico previsível (abertura de semestre, semana de provas) e imprevisível (professor que libera um quiz para 400 alunos de uma vez). Uma t3.medium de 4 GiB aguenta o dia comum e cai na terça de prova — e o autoscaling que resolveria isso é mais um componente para desenhar, testar e pagar. Analisei esse padrão em Moodle UTFPR: o que o pico do 2026/2 ensina sobre EAD. Somem-se os itens que raramente entram no plano inicial: cron a cada minuto em worker isolado, cache MUC em Redis, sessões fora do disco local e um lugar seguro para o moodledata crescer.

Onde termina a responsabilidade da AWS e começa a sua

Este é o ponto que decide a comparação, e é documentado pela própria Amazon. A AWS responde pela segurança da nuvem: instalações físicas, hardware, hipervisor, sistema operacional do host. O cliente responde pela segurança na nuvem:

• Sistema operacional convidado, incluindo atualizações e patches de segurança
• Todo software de aplicação instalado por você — PHP, servidor web, banco e o próprio Moodle
• Configuração do firewall (security groups)
• Identidade, criptografia, retenção de logs e desenho da rede

Quando sai um alerta de segurança do Moodle numa sexta à noite, a AWS não aplica o patch. Quando o moodledata enche o disco às 2h do dia da prova, a AWS não expande o volume. Quando o cron para e as notas deixam de sincronizar, a AWS não abre chamado — você abre, e só com plano pago.

Contratar AWS é contratar capacidade. Contratar hospedagem gerenciada de Moodle é contratar desfecho. São produtos diferentes vendidos na mesma linha do orçamento, e é por isso que a comparação sai torta.

Moodle na AWS vs hospedagem gerenciada: o comparativo linha a linha

Dimensão	Moodle na AWS (self-managed)	Hospedagem gerenciada
Provisionamento	Você desenha VPC, subnets, security groups, EC2, EBS, banco e backup	Ambiente entregue pronto e afinado para Moodle
Patch de SO e PHP	Do cliente, por contrato	Do fornecedor, incluso
Upgrade de versão	Do cliente (2 janelas por ano, no mínimo)	Do fornecedor, com staging antes de produção
Tuning de Moodle	Você pesquisa OPcache, MUC, pool PHP-FPM, índices	Já configurado para o padrão de IO/CPU do Moodle
Monitoramento	CloudWatch cru; dashboards e alertas por sua conta	Métricas, alertas e resposta a incidente inclusos
Backup e restore	Snapshot configurado por você; restore raramente ensaiado	Rotina com PITR e restore validado
Suporte	Plano pago à parte, sobre infraestrutura — não sobre Moodle	Sobre o Moodle, em português, no horário do Brasil
Custo	Variável, em dólar, granular	Previsível, em real, por contrato
Onde é imbatível	Escala grande, arquitetura própria, equipe de SRE existente	Instituições sem sysadmin dedicado a EAD

A linha que mais importa é a penúltima. O suporte da AWS resolve problema de AWS. Se o Moodle está lento porque a tabela mdl_logstore_standard_log passou de 40 milhões de linhas, isso não é chamado de infraestrutura — é conhecimento de Moodle, e nenhum plano da Amazon cobre.

Simulação de custo mensal para 800 alunos

Estimativa construída a partir das tarifas publicadas acima, para aplicação separada do banco, 150 GB de disco no total e 300 GB de saída no mês. Em dólar, sem impostos e sem câmbio.

Item	Base de cálculo	USD/mês
EC2 aplicação (8 GiB, 730 h)	2× a tarifa da t3.medium em São Paulo	~98
EC2 banco (t3.medium, 730 h)	US$ 0,0672/h	~49
EBS gp3 — 150 GB	US$ 0,08/GB-mês	12
Egress — 300 GB (100 GB gratuitos)	200 GB × US$ 0,15	30
NAT Gateway (1 unidade, 730 h)	US$ 0,045/h + processamento	~33
Snapshots e backup offsite	estimativa conservadora	~10
Subtotal de infraestrutura		~232
Suporte AWS (Business, mínimo)	US$ 100/mês	100
Total		~332

Falta a linha mais cara, que não aparece na fatura: as horas de gente. Manter esse ambiente exige, na nossa experiência operando EAD, de 6 a 20 horas técnicas por mês em rotina — patch, monitoramento, backup testado, ajuste de índice — fora as janelas de upgrade semestral. A qualquer custo-hora de profissional sênior no Brasil, essa linha sozinha supera todo o subtotal de infraestrutura.

O relatório Flexera de 2026, com 753 tomadores de decisão de cloud, estima 29% de desperdício sobre o gasto global em IaaS e PaaS — o primeiro aumento em cinco anos. Volume órfão, snapshot esquecido e instância superdimensionada não são exceção: são a média do mercado. É por essa distância entre a fatura estimada e a real que nossa hospedagem gerenciada de Moodle trabalha com valor fechado em real. O risco de dimensionamento fica do nosso lado.

Quando colocar o Moodle na AWS é a decisão certa

Não vou fingir que a resposta é sempre "gerenciado". Há cenários em que Moodle na AWS é tecnicamente superior:

• Já existe time de infraestrutura. Com SRE, plantão e cultura de IaC na casa, o Moodle vira só mais um workload — e a elasticidade da AWS não tem equivalente em plano fechado.
• Escala real e volátil. Acima de alguns milhares de simultâneos com picos sazonais bruscos, autoscaling e balanceamento pagam o próprio trabalho.
• Exigência corporativa de nuvem própria. Matrizes internacionais costumam impor que tudo rode na conta AWS do grupo, com tagging e billing centralizados. Aqui não há debate.
• Integração profunda com o ecossistema AWS. Se os dados acadêmicos já vivem em RDS, S3 e Redshift, aproximar o LMS reduz latência e egress.

Nesses casos, o custo é justificado por uma capacidade que você usa de fato.

Quando Moodle na AWS é a decisão errada

• Não existe sysadmin dedicado. Se a mesma pessoa cuida do Moodle, do e-mail, do Wi-Fi e do sistema acadêmico, o ambiente vai passar meses sem patch. É estatística, não pessimismo.
• A demanda é previsível. 800 alunos com pico duas vezes por semestre não precisam de elasticidade; precisam de estabilidade.
• O orçamento precisa ser previsível. Fatura em dólar, variável, com linha de egress imprevisível é um problema administrativo antes de ser técnico.
• Ninguém testou um restore. Ter snapshot não é ter backup — backup é o que você já restaurou. A versão dolorosa disso está em Moodle UFOP: exclusão de conteúdos e como salvar o backup.
• A dor real é de Moodle, não de servidor. Plugin quebrado, tema desatualizado ou integração travada com o SGA não se resolve trocando de nuvem.

Cinco armadilhas que mais vemos em Moodle na AWS

1. Servir vídeo do próprio EC2. Caminho mais rápido para uma fatura de egress de três dígitos. Vídeo vai para storage de objetos com CDN na frente, não para o disco da aplicação.
2. moodledata no volume raiz. O diretório cresce sem parar com envios, cache e arquivos de curso. Quando enche o volume do sistema, o Moodle não fica lento: ele para.
3. Instância burstable sem alarme de crédito. O ambiente não cai, a degradação não é óbvia, e a cobrança por vCPU-hora excedente aparece só no fechamento do mês.
4. Cron do Moodle no crontab do sistema, sem isolamento. Compete por CPU com as requisições dos alunos exatamente no pico e ainda pode rodar em duplicidade após um reboot.
5. Backup sem teste de restauração. Snapshot diário no console dá uma sensação de segurança que só é desmentida no pior dia possível. Restore precisa ser ensaiado em calendário.

Nenhuma delas é culpa da AWS. Todas são consequência de operar uma aplicação complexa sem alguém cuja função seja operá-la.

Como a Agathas Web resolve isso

Trabalho com Moodle desde 2008 e a Agathas Web sustenta ambientes de EAD em produção há mais de 15 anos — instituições públicas, escolas técnicas e treinamento corporativo. Nossa hospedagem gerenciada de Moodle existe para tirar da instituição exatamente as linhas de responsabilidade que a AWS deixa com o cliente.

O que está incluso:

• Stack desenhada para Moodle, não hospedagem genérica: PHP-FPM com pool dedicado por instância, OPcache afinado, Redis para sessões, cache e MUC, MariaDB 10.11+ com binlog para point-in-time recovery e cron do Moodle isolado em worker próprio.
• Backup incremental de binlog a cada 15 minutos e cópia offsite criptografada em AES-256, com restore ensaiado — não presumido.
• Monitoramento ativo com Grafana e Prometheus, Sentry para erros de aplicação e verificação externa independente da nossa própria infraestrutura. O alerta chega à equipe técnica antes da reclamação do aluno.
• Atualização de versão executada em staging antes de tocar produção, inclusive nas duas janelas anuais do calendário oficial, com plugins e tema institucional validados.
• Segurança operacional: WAF e proteção DDoS na borda, SSL com renovação automática, fail2ban e rate limit em rotas críticas, hardening do SO e auditoria de logs.
• Suporte sênior em português, no horário do Brasil, com SLA por severidade em contrato — feito pela mesma equipe que escreve o código e desenha a arquitetura, não por nível 1 lendo roteiro.
• Migração assistida a partir do fornecedor atual, inclusive de uma conta AWS existente, com garantia de paridade: usuários, cursos, notas, certificados, fóruns e tarefas. Você valida em homologação e aprova por escrito antes do cut-over.
• Portabilidade: se um dia quiser sair, entregamos o backup completo. Não trabalhamos com prisão técnica.

Como se contrata: o ponto de partida é um diagnóstico do ambiente atual — versão do Moodle, alunos e simultâneos no pico, plugins críticos, integrações e volume do moodledata. A partir dele fechamos escopo e valor mensal em real, com migração em janela acordada. O formulário e o canal direto de WhatsApp estão na página do produto.

Uma observação honesta: se você já roda Moodle na AWS com equipe própria e está satisfeito, não há motivo para trocar. Nosso caso é para quem descobriu que comprou capacidade quando precisava de operação.

Conclusão: como decidir em uma tarde

Responda a três perguntas por escrito.

Primeira: existe hoje alguém cuja responsabilidade formal inclua aplicar patch de segurança do Moodle e do sistema operacional dentro de uma semana do anúncio? Se a resposta é "mais ou menos", o modelo self-managed já é mais risco do que economia.

Segunda: quando foi a última restauração de backup testada, não apenas configurada? Sem data, esse é o item mais urgente da lista — independentemente de onde o ambiente esteja.

Terceira: seu Moodle estará na 5.3 LTS até o primeiro semestre de 2027? Sabendo que ela chega em 5 de outubro de 2026 e que o 5.1 sai do suporte geral no mesmo dia, quem executa esse upgrade e em que janela?

Se as três respostas forem sólidas, a AWS é uma excelente casa para o seu Moodle. Se alguma travou, o próximo passo é conversar sobre a hospedagem gerenciada de Moodle: meia hora de conversa resolve se faz sentido, e o diagnóstico do ambiente atual vem antes de qualquer proposta.