No dia 31 de julho de 2026, o Amazon RDS para MySQL 8.0 chegou ao fim do suporte padrão. Quem não migrou não recebeu aviso de bloqueio, não teve o banco desligado e provavelmente nem percebeu: no dia seguinte, 1º de agosto, a AWS simplesmente começou a cobrar uma taxa adicional por vCPU por hora, automaticamente, em toda instância que continuou rodando naquela versão. É uma das poucas cobranças da AWS que liga sozinha, sem ninguém clicar em nada — e é por isso que ela costuma aparecer na fatura antes de aparecer na reunião. Este guia mostra como funciona o RDS Extended Support, qual é o calendário real de cada versão, quanto custa ficar parado e quais são as quatro saídas possíveis — incluindo a hipótese, legítima, de pagar de propósito.
O Que É o RDS Extended Support e Por Que Ele Liga Sozinho
O RDS Extended Support é o mecanismo pelo qual a AWS continua fornecendo correções de segurança e patches de CVE para versões de banco que a comunidade já aposentou — mediante cobrança. Ele existe porque o MySQL e o PostgreSQL têm ciclos de vida definidos pelas suas comunidades, não pela AWS, e quando o projeto original para de publicar correções, alguém precisa assumir esse trabalho para quem ainda não migrou.
A parte que pega as equipes de surpresa é o mecanismo de adesão. Segundo a documentação da AWS, o RDS inscreve automaticamente os bancos elegíveis no Extended Support e começa a cobrar no dia seguinte à data de fim do suporte padrão. Não há uma tela de aceite, um e-mail de confirmação ou um botão para ligar. A ausência de ação é interpretada como escolha de permanecer na versão antiga — e essa escolha tem preço.
Vale separar dois conceitos que costumam ser confundidos: versão menor e versão maior. O Extended Support só existe para versões maiores (8.0, 5.7, PostgreSQL 13). Versões menores têm seus próprios prazos de suporte e, em geral, expiram antes da versão maior a que pertencem — o MySQL 8.0.28 saiu de suporte em março de 2024, enquanto a versão maior 8.0 só saiu em julho de 2026. Manter a versão menor atualizada não protege do prazo da versão maior.
O Calendário Real: Quando Cada Versão Sai do Suporte Padrão
Esta é a informação que deveria estar num calendário corporativo e quase nunca está. Os prazos abaixo vêm do calendário oficial de versões do RDS para MySQL e do calendário do RDS para PostgreSQL, consultados em agosto de 2026:
| Versão | Fim do suporte padrão | Início da cobrança | Preço dobra (ano 3) | Fim do Extended Support |
|---|---|---|---|---|
| MySQL 5.7 | 29/02/2024 | 01/03/2024 | 01/03/2026 (já dobrou) | 30/06/2029 |
| MySQL 8.0 | 31/07/2026 | 01/08/2026 | 01/08/2028 | 31/07/2029 |
| MySQL 8.4 | 31/07/2029 | 01/08/2029 | 01/08/2031 | 31/07/2032 |
| PostgreSQL 13 | 28/02/2026 | 01/03/2026 | 01/03/2028 | 28/02/2029 |
| PostgreSQL 14 | 28/02/2027 | 01/03/2027 | 01/03/2029 | 28/02/2030 |
| PostgreSQL 15 | 29/02/2028 | 01/03/2028 | 01/03/2030 | 28/02/2031 |
| PostgreSQL 16 | 28/02/2029 | 01/03/2029 | 01/03/2031 | 29/02/2032 |
| PostgreSQL 17 | 28/02/2030 | 01/03/2030 | 01/03/2032 | 28/02/2033 |
Duas leituras importantes. A primeira: quem está em MySQL 5.7 hoje paga o dobro desde março de 2026 — passou da faixa de anos 1-2 para a de ano 3, e provavelmente ninguém no time percebeu a mudança na fatura. A segunda: o próximo prazo relevante é PostgreSQL 14, em 28 de fevereiro de 2027. Faltam menos de sete meses, o que é pouco para um upgrade de versão maior que exige teste de aplicação — e é exatamente o tipo de prazo que se descobre tarde demais.
O PostgreSQL tem um padrão previsível: a comunidade dá cinco anos de suporte por versão maior, e a AWS costuma encerrar o suporte padrão no fim de fevereiro seguinte. Dá para planejar com anos de antecedência consultando a política de versionamento do PostgreSQL, em vez de esperar a cobrança avisar.
Quanto Custa Ficar Parado
A cobrança do Extended Support é calculada por vCPU por hora, e varia conforme o motor, a região e quantos anos se passaram desde o fim do suporte padrão. A própria documentação da AWS usa um exemplo concreto: para o MySQL 5.7 na região US East (Ohio), a cobrança foi de US$ 0,100 por vCPU-hora entre março de 2024 e fevereiro de 2026, passando a US$ 0,200 por vCPU-hora a partir de março de 2026 — o dobro, ao entrar no terceiro ano.
Não use esse número como estimativa para o Brasil: a região de São Paulo tem tabela própria, e o valor correto está na página de preços do RDS. O que vale generalizar é a mecânica: o custo é proporcional ao número de vCPUs, não ao tamanho do banco. Uma instância grande e ociosa paga tanto quanto uma instância grande e ocupada.
Há um detalhe que multiplica a conta e passa despercebido em quase toda estimativa inicial: a documentação afirma explicitamente que as cobranças de Extended Support se aplicam também às instâncias standby em implantações Multi-AZ. Ou seja, o ambiente que você montou para garantir alta disponibilidade — e que é a recomendação correta para produção — dobra o custo do Extended Support. Quem calculou o impacto olhando só para a instância primária subestimou pela metade.
Esse é o tipo de gasto que a prática de FinOps na AWS existe para capturar: não é desperdício por má configuração, é desperdício por inércia — e ele cresce sozinho enquanto ninguém decide nada.
As Quatro Saídas — e Quando Cada Uma Faz Sentido
Sair do Extended Support tem exatamente duas ações que interrompem a cobrança, segundo a AWS: atualizar para uma versão sob suporte padrão, ou excluir o banco. Tudo o mais é variação de estratégia sobre essas duas. Na prática, as empresas escolhem entre quatro caminhos:
| Caminho | Parada | Risco | Quando faz sentido |
|---|---|---|---|
| Upgrade in-place | Minutos a horas, dependendo do volume | Médio — reversão exige restaurar backup | Ambientes não críticos, janela de manutenção folgada |
| Blue/Green Deployments | Tipicamente menos de 1 minuto | Baixo — ambiente antigo permanece disponível | Produção com aplicação sensível a indisponibilidade |
| Migração para Aurora | Depende da estratégia adotada | Médio a alto — muda a plataforma, não só a versão | Quando o upgrade já era necessário e há ganho real em performance ou escala |
| Pagar o Extended Support | Nenhuma | Baixo no curto prazo, crescente no longo | Sistema legado com fim de vida já datado, ou congelamento por auditoria |
A quarta linha não é uma piada. Pagar o Extended Support de propósito é uma decisão defensável quando o sistema que usa aquele banco já tem data para ser desligado, quando há uma certificação em curso que proíbe mudança de ambiente, ou quando o custo do teste de regressão da aplicação é comprovadamente maior que a taxa. O problema nunca foi pagar — foi pagar sem ter decidido.
Um aviso sobre a opção de recusar o Extended Support: existe um parâmetro (--engine-lifecycle-support com o valor open-source-rds-extended-support-disabled na CLI) que impede o RDS de criar ou restaurar instâncias em versões fora do suporte padrão. Ele é uma trava preventiva, não um desconto — não remove a cobrança de uma instância que já está rodando, e vai fazer falhar a restauração de um backup antigo justamente no momento em que você mais precisa dele.
Blue/Green Deployments: o Upgrade com Menos de Um Minuto de Parada
Para quem precisa atualizar produção sem negociar uma janela de madrugada, os Blue/Green Deployments do RDS são a ferramenta certa. O mecanismo é direto: a AWS cria um ambiente de staging (verde) que é uma cópia completa da topologia de produção (azul) — incluindo réplicas de leitura, configuração de storage e Multi-AZ — e mantém os dois sincronizados por replicação.
Você aplica o upgrade de versão maior no ambiente verde, testa com calma, e quando estiver satisfeito executa a troca. A documentação afirma que a mudança tipicamente leva menos de um minuto, sem perda de dados e sem necessidade de alterar a aplicação: os nomes e endpoints de produção são transferidos para o ambiente novo, e o antigo é renomeado com o sufixo -old1. Como o ambiente azul não é excluído automaticamente, ele fica disponível para teste de regressão.
Três pontos que decidem se isso vai funcionar na sua casa:
- O recurso cobre RDS para MariaDB, MySQL e PostgreSQL — Aurora tem implementação própria, documentada à parte.
- Mantenha o ambiente verde somente leitura durante o teste. Escrever nele gera conflito de replicação e pode deixar dados espúrios em produção depois da troca.
- RDS Proxy e smart drivers reduzem ainda mais a parada, porque detectam a mudança de topologia e redirecionam conexões sem esperar a propagação de DNS.
Antes de qualquer troca, confirme que o backup e o ponto de restauração estão íntegros — o mesmo cuidado que vale para qualquer mudança estrutural, como discutimos no guia de backup e recuperação de dados.
O Erro Que Faz a Conta Voltar: Atualizar para uma Versão Que Também Vai Expirar
Este é o erro mais caro do processo, e a própria documentação da AWS o descreve com um exemplo. Uma empresa tira o banco do PostgreSQL 11, atualiza para o PostgreSQL 12 e considera o assunto resolvido. A cobrança realmente para. Mas o PostgreSQL 12 tinha data de fim de suporte padrão em 28 de fevereiro de 2025 — e no dia 1º de março de 2025 a cobrança recomeçou, agora na versão 12.
O padrão se repete com o MySQL: o caminho de upgrade suportado é 5.7 → 8.0 → 8.4. Quem saiu do 5.7 correndo em 2024 e parou no 8.0 voltou à mesma situação em 1º de agosto de 2026, dois anos depois. Só o 8.4 compra tempo real, até 2029.
A regra prática é simples e vale escrever no plano de projeto: ao planejar um upgrade, olhe primeiro o prazo da versão de destino, não o da versão de origem. Se o destino tem menos de dois ou três anos de suporte pela frente, você está comprando uma repetição do mesmo trabalho — e o custo do teste de aplicação vai ser pago duas vezes.
Como Descobrir Hoje Se Você Já Está Pagando
Não é preciso esperar a fatura fechar. Três verificações resolvem:
1. Liste as versões e seus prazos direto da API. O RDS expõe as datas de suporte por versão de motor, o que permite montar o inventário sem depender da documentação:
“ aws rds describe-db-engine-versions --engine mysql \ --query "*[].{Versao:EngineVersion,Suporte:SupportedEngineLifecycleSupport}" “
2. Procure a linha no Cost Explorer. A cobrança aparece como item próprio, separada do custo de instância. Se ela existe, você já está no Extended Support — e o valor mensal dá a urgência real do projeto de upgrade.
3. Cruze com o inventário de aplicações. A pergunta que importa não é "quais bancos estão em versão antiga", é "quais sistemas quebram se essa versão mudar". É a resposta a essa segunda pergunta que determina o prazo do projeto, e ela quase nunca está documentada — o que costuma ser o verdadeiro gargalo, mais que o upgrade em si.
Ambientes com observabilidade bem estruturada chegam nessa resposta em horas; ambientes sem ela levam semanas descobrindo dependências por tentativa e erro.
Ciclo de Vida de Banco de Dados Como Item de Governança, Não Como Emergência
A razão pela qual essa cobrança surpreende tanta gente é estrutural: em quase toda empresa de porte médio, o ciclo de vida do banco não pertence a ninguém. A infraestrutura acha que é do time de aplicação, o time de aplicação acha que é da infraestrutura, e o prazo passa.
O que resolve não é uma ferramenta, é um item de calendário. Três práticas que funcionam:
- Registrar a data de fim de suporte padrão de cada banco no inventário de ativos, junto com a versão — a mesma disciplina que se aplica a licenças e contratos.
- Tratar o upgrade de versão maior como projeto anual recorrente, com janela e orçamento previstos, em vez de evento excepcional.
- Revisar os prazos em toda avaliação de arquitetura. O pilar de excelência operacional do AWS Well-Architected Framework já pede exatamente isso, e é o momento natural para a pergunta aparecer antes da fatura.
Vale lembrar que versão fora de suporte não é só custo: é superfície de ataque. Enquanto o Extended Support estiver ativo, a AWS continua publicando correções de CVE — mas ele também tem data para acabar. Depois de 31 de julho de 2029, o MySQL 8.0 não recebe mais nada de ninguém.
Perguntas Frequentes sobre RDS Extended Support
O RDS desliga meu banco quando a versão sai de suporte?
Não. O banco continua funcionando normalmente, e é justamente isso que torna a situação perigosa — não há interrupção que force a equipe a agir. A AWS inscreve a instância no Extended Support automaticamente e passa a cobrar a taxa adicional a partir do dia seguinte à data de fim do suporte padrão.
Como faço para parar de ser cobrado pelo Extended Support?
Existem duas ações que interrompem a cobrança: atualizar para uma versão maior que esteja sob suporte padrão, ou excluir a instância. A cobrança para no momento em que uma dessas ações se completa. Atenção: se a versão de destino entrar em Extended Support no futuro, a cobrança recomeça naquela data.
A cobrança vale também para a instância standby do Multi-AZ?
Sim. A documentação da AWS é explícita: as cobranças de Extended Support se aplicam às instâncias standby em implantações Multi-AZ. Na prática, um ambiente Multi-AZ paga aproximadamente o dobro do que uma estimativa feita só sobre a instância primária indicaria.
Migrar para o Aurora resolve o problema de ciclo de vida?
Não elimina, apenas muda o calendário. O Aurora compatível com MySQL e com PostgreSQL também tem versões que saem de suporte padrão e entram em Extended Support, com a mesma lógica de cobrança. A migração para Aurora se justifica por performance, escala ou arquitetura — não como fuga do ciclo de vida de versões.
Qual é o próximo prazo que devo colocar no calendário?
Para quem usa PostgreSQL, a data mais próxima é 28 de fevereiro de 2027, fim do suporte padrão da versão 14. Para quem está em MySQL 8.0, o prazo já passou em 31 de julho de 2026 — a cobrança está ativa desde 1º de agosto, e o caminho de upgrade é para a versão 8.4, cujo suporte padrão vai até julho de 2029.
Dá para impedir que o RDS crie instâncias em versões fora de suporte?
Sim, usando o parâmetro --engine-lifecycle-support com o valor open-source-rds-extended-support-disabled na criação ou restauração. É uma trava de governança útil para evitar que alguém suba um ambiente novo já vencido — mas cuidado: ela também impede restaurar um backup antigo de uma versão fora de suporte, o que pode atrapalhar justamente numa recuperação de emergência.
O Ciclo de Vida de Versões É Previsível — o Custo de Ignorá-lo É Que Não É
Diferente de quase todo problema de infraestrutura, este vem com data marcada e publicada anos antes. O calendário do RDS está aberto, as datas do PostgreSQL 17 já estão definidas até 2033, e nada disso é surpresa técnica. O que transforma uma informação pública em custo inesperado é a ausência de um dono para a pergunta "quando esse banco precisa ser atualizado" — e essa é uma questão de governança de TI, não de banco de dados.
Empresas que tratam versão como item de inventário, com data e responsável, fazem esse upgrade como projeto planejado, com Blue/Green e menos de um minuto de parada. As que não tratam descobrem o prazo pela fatura, negociam janela às pressas e pagam duas vezes: a taxa acumulada e o projeto emergencial.
Artigos Relacionados
- FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — a cobrança do Extended Support é um caso clássico de custo por inércia, exatamente o tipo de desperdício que a prática de FinOps foi feita para encontrar antes da fatura.
- AWS Well-Architected Framework: o Guia Avançado — o pilar de excelência operacional é onde a pergunta sobre ciclo de vida de versões deveria aparecer na sua revisão de arquitetura.
- Disaster Recovery na AWS: Estratégias Multi-Região — antes de qualquer upgrade de versão maior, o ponto de restauração precisa estar validado; aqui está como estruturar isso de verdade.
- Amazon EC2 para Pequenas Empresas: o Guia Completo — para quem ainda opera banco de dados em instância própria, a comparação com o modelo gerenciado do RDS começa por aqui.
