Resumo

  • A capacidade de armazenamento já alocada a uma instância RDS não pode ser reduzida na própria instância. Limpar dados pode liberar espaço sem diminuir a base de cobrança desse armazenamento.
  • Em configurações compatíveis, uma implantação azul/verde permite mudar para um ambiente menor. Replicação, troca de produção e retenção do banco antigo entram no custo da economia.

A despesa recebeu autonomia

É fácil aprovar uma automação que evita um banco de dados cheio. A aplicação continua funcionando, a equipe ganha tempo e ninguém precisa decidir, no meio de uma emergência, quanto espaço acrescentar. O orçamento acompanha a decisão. A parte menos automática vem quando o movimento passa e a empresa descobre que continua pagando pela folga.

O Amazon RDS aumenta o armazenamento alocado quando as condições da expansão automática são atendidas. A documentação deixa claro que essa capacidade não diminui depois na mesma instância. Desligar a expansão impede novas ampliações automáticas; não desfaz as anteriores. Uma modificação manual da instância também não permite reduzir a alocação já existente.

A lógica comercial aparece na página de preços do RDS for MySQL: o armazenamento é cobrado pela capacidade provisionada, com ajuste proporcional quando ela muda durante o mês. O espaço ocupado é outra medida. Mesmo uma limpeza que efetivamente libere blocos no sistema de arquivos pode deixar intacta a capacidade que a empresa continua comprando.

A automação entregou disponibilidade. A empresa ainda precisa decidir o que fazer com o tamanho que sobrou. Esse intervalo merece mais atenção do que recebe, porque uma despesa criada por uma boa decisão operacional pode durar muito além do motivo que a justificou.

A redução tem obra

Há uma saída para configurações compatíveis: criar um ambiente verde com menos armazenamento e transferir a produção para ele por meio de uma implantação azul/verde. O banco atual é a origem azul; o novo é preparado e sincronizado antes da troca. AWS também descreve a alternativa de criar uma instância menor, migrar os dados manualmente e mudar os pontos de conexão.

A unidade antiga permanece do mesmo tamanho. Quem fica menor é a substituta. Para quem vê apenas o orçamento, a diferença pode parecer burocrática. Para quem responde pelos dados, ela contém quase todo o trabalho.

As regras de criação exigem que o destino de uma redução tenha pelo menos 20% a mais de capacidade do que o uso atual. Um exemplo aritmético: 500 GiB alocados, com 50% ocupados, representam uso de 250 GiB. Aplicando o fator de 1,2 da documentação, chega-se a um mínimo calculado de 300 GiB. A configuração precisa permitir o alvo, e o crescimento durante a preparação pede margem adicional.

A redução aciona uma atualização da configuração de armazenamento. É um processo intenso em entrada e saída, capaz de alongar a criação do ambiente. O tamanho menor no formulário é uma escolha de projeto, não a conclusão da mudança.

O exemplo aqui é uma instância elegível do RDS for MySQL. A matriz de suporte inclui versões determinadas de MariaDB e PostgreSQL, além de MySQL. Db2, SQL Server e Oracle ficam fora desse recurso. O caminho de redução depende do mecanismo e da configuração utilizados.

O nome muda de dono, a história fica

A troca controlada verifica a saúde e o atraso da replicação, entre outras condições. O RDS interrompe novas gravações, derruba conexões, espera a sincronização e troca nomes de instâncias e pontos de conexão. Depois libera o acesso e as gravações na nova produção. Promover a instância verde isoladamente é uma operação diferente, que quebra a relação de replicação da implantação.

O aplicativo pode voltar a encontrar o nome que já conhece. A identidade permanente do recurso, porém, é a do novo banco. Há uma consequência concreta para recuperação: segundo as limitações e considerações, o histórico de restauração para um instante específico da instância antiga não passa à nova. O histórico desta começa quando o ambiente verde foi criado. A antiga instância azul mantém seu próprio histórico e os backups automáticos até ser excluída.

Se a empresa precisa continuar voltando a momentos anteriores, manter o banco antigo pode ser necessário por algum tempo. A AWS informa que uma instância azul retida em execução continua cobrando computação e armazenamento. A redução do tamanho da produção, portanto, pode coexistir com uma fase de despesa total maior.

É uma economia que precisa financiar a própria transição. O prazo para desligar a segunda estrutura depende do que ela ainda protege, e não apenas da vontade de encerrar o projeto.

Excluir a implantação não esvazia a fatura

A documentação de exclusão informa que remover a implantação azul/verde não afeta o ambiente azul. A organização da mudança e os recursos que cobram são coisas distintas. Parar uma instância MySQL também conserva custos de armazenamento.

É por isso que o inventário final precisa dizer quais recursos ficaram, com qual finalidade e por quanto tempo. Sem preços efetivos, duração da coexistência, necessidade de recuperação e trabalho de migração, falta o que permite calcular a economia líquida. O que já se sabe é suficiente para rejeitar uma conta preguiçosa: ocupação menor multiplicada por uma tarifa não mede, sozinha, a redução da despesa provisionada.

O RDS oferece um mecanismo rápido para comprar mais espaço em resposta a uma necessidade. Devolver o excesso econômico exige outro tipo de execução. A elasticidade só chega ao orçamento quando alguém termina a mudança.