Infraestrutura

    Como migrar o Moodle para a AWS sem downtime

    01 de maio de 2026 9 min de leitura

    Migrar o Moodle para a AWS é uma das decisões de infraestrutura que mais paga o próprio custo: ganho de performance, elasticidade real para picos de matrícula, SLA contratual e custos operacionais previsíveis. O problema é fazer isso sem interromper aulas, provas e prazos — especialmente em órgãos públicos e universidades corporativas com milhares de usuários ativos.

    Este guia consolida o que aplicamos em mais de 50 projetos de migração nos últimos 14 anos.

    Por que migrar para a AWS

    • Elasticidade: instâncias EC2 e RDS escalam horizontalmente em minutos. Períodos de prova ou abertura de matrícula deixam de ser "torcer para não cair".
    • Disponibilidade: Multi-AZ no RDS e EFS replicado garantem continuidade mesmo se uma zona inteira falhar.
    • Segurança: VPC, Security Groups, KMS, WAF, Shield e logs auditáveis no CloudTrail — pré-requisitos para LGPD e contratos públicos.
    • Custos previsíveis: Reserved Instances e Savings Plans reduzem 30–60% do OPEX em relação a hospedagens compartilhadas tradicionais.

    Antes de migrar: o checklist obrigatório

    1. Inventário de plugins: liste todos os plugins ativos com versão. Plugins desatualizados são a causa #1 de incidentes pós-migração.
    2. Auditoria de banco: tamanho do MySQL/MariaDB, tabelas mais pesadas, jobs de cron problemáticos.
    3. Mapeamento de moodledata: quanto pesa, em que diretórios, quantos arquivos pequenos. Isso define se o destino será EFS ou S3 (via plugin de object storage).
    4. Janela de manutenção: identificar o período de menor atividade. Em órgãos públicos, costuma ser madrugada de domingo.
    5. Plano de rollback: o que fazer se o cutover der errado nos primeiros 60 minutos. Sem rollback documentado, não migre.

    Arquitetura alvo recomendada

    Para Moodle em produção a partir de 2.000 usuários simultâneos:

    • EC2 Auto Scaling Group atrás de um Application Load Balancer.
    • RDS for MariaDB Multi-AZ com Read Replica para relatórios e BI.
    • EFS para moodledata (compartilhado entre instâncias EC2).
    • ElastiCache Redis para sessions, MUC e application cache do Moodle.
    • CloudFront + S3 para servir conteúdo estático e SCORM.
    • WAF na frente do ALB com regras OWASP Top 10.

    Estratégia de migração sem downtime

    A abordagem que funciona é a migração em 5 fases com replicação contínua:

    1. Provisionar o ambiente espelho na AWS

    Suba toda a arquitetura alvo já com a versão atual do Moodle, mas vazia. Valide o pipeline, monitoramento (CloudWatch + Grafana) e backups.

    2. Sincronizar moodledata

    Com o site original ainda no ar, copie os arquivos para o EFS usando rsync em duas passadas:

    • Primeira passada (dias antes do cutover) — leva horas, mas roda sem afetar produção.
    • Segunda passada incremental na janela de cutover — leva minutos.

    3. Replicar o banco

    Use AWS DMS com modo full load + CDC apontando para o RDS. A replicação contínua mantém o destino atualizado em tempo real, e a janela de cutover fica restrita à parada da aplicação por alguns minutos para drenar os últimos eventos.

    4. Cutover

    Na janela de manutenção:

    1. Coloque o Moodle origem em modo manutenção (maintenance_enabled).
    2. Aguarde a DMS confirmar lag zero.
    3. Rode a segunda passada do rsync no moodledata.
    4. Aponte o DNS (Route 53 com TTL baixo, configurado dias antes) para o ALB.
    5. Faça o smoke test: login admin, login aluno, upload de arquivo, abertura de SCORM, geração de certificado.
    6. Tire a manutenção.

    Com esse fluxo, o downtime real fica entre 10 e 30 minutos, mesmo com terabytes de moodledata.

    5. Monitoramento intensivo nas primeiras 72h

    Equipe de plantão acompanhando dashboards de CloudWatch, logs do PHP-FPM, taxa de erro do ALB e tempo de resposta. Qualquer anomalia, executa o plano de rollback.

    Erros que vimos repetidos em 14 anos

    • Subestimar o moodledata: descobrir no dia que tem 4 milhões de arquivos pequenos é receita para ultrapassar a janela.
    • Não testar o cron do Moodle: uma migração sem ajuste do cron derruba o sistema em horas.
    • Esquecer plugins de pagamento e SSO: configurações guardadas em config.php ou em URLs de callback precisam ser revistas.
    • Auto Scaling sem Redis para sessões: o usuário "perde a sessão" ao mudar de instância — péssima primeira impressão.

    Quando faz sentido contratar especialista

    Se você tem mais de 1.000 alunos ativos, integra com SSO, ou opera em órgão público com contratos rígidos, o custo de uma migração improvisada (incidente público + retrabalho) é maior que o de fazer com quem já fez. Nosso serviço de Moodle gerenciado na AWS entrega arquitetura, migração, suporte 24×7 e otimização contínua sob um único SLA.

    Quer um diagnóstico gratuito da sua arquitetura atual? Fale com nosso time pelo WhatsApp ou pelo formulário de contato.

    Leitura complementar

    Compartilhar: