Write Ahead {B}Log

Em muitos times, o início de um incidente de banco de dados segue sempre o mesmo roteiro. A aplicação começa a apresentar timeout, conexões passam a falhar, usuários percebem lentidão, dashboards ficam indisponíveis e rapidamente surge a mensagem: “o banco caiu”.

Nesse momento, normalmente começamos a investigação olhando aquilo que faz parte do dia a dia operacional de DBAs e DBREs: locks, queries lentas, consumo de CPU, quantidade de conexões, IOPS, replication lag ou espaço em disco.

Claro, todas essas análises são fundamentais. Mas existe um ponto importante que ambientes cloud modernos nos obrigam a entender: nem todo incidente de banco de dados começa no banco de dados.

Em ambientes AWS, especialmente utilizando Amazon RDS, boa parte dos incidentes críticos pode ter origem em mudanças de infraestrutura, rede, segurança ou operações administrativas realizadas fora do engine do banco. Uma alteração em um Security Group pode bloquear completamente o acesso da aplicação. Uma mudança de rota na VPC pode interromper comunicação entre ambientes. Uma modificação em parameter groups pode exigir reboot. Um patch automático pode gerar failover. Uma subnet mal configurada pode comprometer a alta disponibilidade de um ambiente Multi-AZ.

É justamente nesse ponto que o AWS CloudTrail se torna uma das ferramentas mais importantes para investigação de incidentes em bancos de dados na AWS. Mais do que um serviço de auditoria, o CloudTrail funciona como uma linha do tempo operacional da infraestrutura.

Ele registra chamadas de API realizadas nos serviços AWS e permite responder perguntas extremamente valiosas durante um incidente: quem executou determinada alteração, quando ela ocorreu, qual recurso foi impactado e qual operação foi realizada.

Por isso, durante uma investigação o CloudTrail frequentemente se torna tão importante quanto os próprios logs do banco para ajudar a identificar o que está errado.

O problema nem sempre está no banco

Uma das maiores mudanças de mentalidade para profissionais de banco de dados trabalhando em cloud é entender que o banco agora depende diretamente de diversos componentes de infraestrutura gerenciados dinamicamente.

No passado, em ambientes on-premise, um DBA costumava investigar principalmente o servidor do banco, storage, rede local e aplicação. Em cloud, o cenário é muito mais distribuído. O banco pode estar saudável internamente, mas indisponível externamente por conta de uma mudança em VPC, subnets, rotas, ACLs, políticas IAM ou grupos de segurança.

Esse tipo de situação é extremamente comum em ambientes compartilhados entre múltiplos times. Às vezes uma alteração feita para resolver um problema de rede em outro sistema acaba impactando indiretamente o banco de dados. Em outros casos, mudanças automatizadas via Terraform, pipelines CI/CD ou scripts operacionais podem provocar indisponibilidades temporárias sem que o time de banco perceba imediatamente a origem.

É exatamente por isso que investigar incidentes em RDS exige uma visão mais ampla do ambiente.

Security Groups

Um dos cenários mais clássicos acontece com mudanças em Security Groups. No CloudTrail, alterações desse tipo aparecem através de ações como:

AuthorizeSecurityGroupIngress

RevokeSecurityGroupIngress

Além disso, alterações em instâncias RDS também podem modificar os Security Groups associados através de eventos como:

ModifyDBInstance

ModifyDBCluster

O impacto pode ser imediato. Uma simples remoção da porta 5432 pode fazer toda a aplicação perder conectividade com o banco. Para quem está investigando o incidente, o comportamento inicial normalmente parece um problema no próprio RDS: timeout, falha de conexão e indisponibilidade generalizada. Mas internamente o banco continua funcionando perfeitamente.

Esse tipo de incidente costuma ser particularmente difícil porque métricas como CPU, memória e IOPS permanecem saudáveis. O banco está operacional, porém isolado da aplicação. Em ambientes críticos, já vi situações em que pequenas mudanças em regras de Security Group causaram indisponibilidade completa de APIs, aplicações internas e até replicas de leitura.

Nestes casos, o CloudTrail que permite reconstruir uma linha do tempo rapidamente.

Rotas e subnets

Outro grupo de eventos extremamente importante envolve alterações na infraestrutura de rede da VPC. As ações abaixo podem alterar completamente o caminho de comunicação entre aplicações e banco de dados.:

ReplaceRoute

DeleteRoute

ReplaceRouteTableAssociation

O evento ReplaceRouteTableAssociation merece atenção especial porque ele troca a associação entre uma subnet e uma route table. Isso significa que uma subnet inteira pode passar a utilizar um conjunto diferente de rotas quase instantaneamente. Dependendo da arquitetura, a aplicação pode perder acesso ao banco, o banco pode perder comunicação com outros serviços internos ou até ocorrer isolamento parcial entre Availability Zones.

Esse tipo de incidente normalmente é ainda mais difícil de diagnosticar porque o banco pode permanecer acessível a partir de alguns ambientes, mas não de outros. Às vezes apenas uma subnet específica perde comunicação. Em outras situações, o tráfego entre Availability Zones deixa de funcionar corretamente.

Em ambientes Multi-AZ isso pode gerar efeitos bastante perigosos. O mesmo vale para alterações relacionadas a DB Subnet Groups, registradas através de ações como:

ModifyDBSubnetGroup

Uma configuração inadequada de subnets pode impactar diretamente a capacidade do RDS realizar failover corretamente entre AZs. Em alguns casos, durante manutenção ou eventos de indisponibilidade, o banco pode não conseguir promover adequadamente a instância standby.

Esse é um ótimo exemplo de como um problema aparentemente “de banco” pode ter origem completamente fora do engine.

VPC Peering e Transit Gateway

Em ambientes corporativos maiores, é extremamente comum que aplicações e bancos estejam distribuídos entre múltiplas VPCs, contas AWS ou até regiões diferentes. Nessas arquiteturas, conectividade entre redes passa a depender diretamente de recursos como VPC Peering e AWS Transit Gateway. É aqui que alguns dos incidentes mais críticos podem acontecer:

DeleteVpcPeeringConnection

RejectVpcPeeringConnection

podem interromper instantaneamente toda a comunicação entre duas VPCs.

Na prática, isso significa que aplicações podem perder completamente acesso ao RDS sem que exista qualquer alteração no banco em si. Para o time de aplicação, o sintoma continua parecendo “o banco caiu”, mas internamente o RDS segue saudável e disponível dentro da própria VPC. O mesmo vale para eventos que removem anexos entre VPCs e o Transit Gateway:

DeleteTransitGatewayVpcAttachment

Em arquiteturas centralizadas utilizando Transit Gateway, esse tipo de alteração pode isolar ambientes inteiros. Dependendo da topologia da rede, um único attachment removido pode interromper comunicação entre aplicações, serviços compartilhados, ambientes de observabilidade, pipelines de dados e bancos de dados simultaneamente.

Esse é um dos melhores exemplos de como incidentes de banco em cloud muitas vezes são, na verdade, incidentes de conectividade distribuída. Nestes casos, investigar apenas métricas internas do RDS raramente é suficiente em ambientes complexos.

Reboots, failovers e operações administrativas

Durante incidentes, uma das primeiras coisas que costumo verificar é se houve alguma operação administrativa recente no RDS. No CloudTrail, isso aparece claramente através de eventos como:

RebootDBInstance

RebootDBCluster

FailoverDBCluster

ModifyDBInstance

ModifyDBCluster

Essas ações podem provocar indisponibilidade temporária, reconexões massivas de aplicações, troca de writer em clusters Aurora e até mudanças de comportamento inesperadas.

Um ponto importante é que nem toda alteração aplicada via ModifyDBInstance parece crítica à primeira vista. Muitas vezes alguém altera uma janela de manutenção, troca um parameter group, modifica storage ou muda configurações de rede sem imaginar o impacto operacional daquela alteração.

Dependendo da configuração, a modificação pode exigir reboot imediato ou aplicação durante a próxima maintenance window.

Aqui existe um detalhe importante para times de banco: nem sempre essas mudanças são percebidas diretamente pelos DBAs no momento em que acontecem. Em organizações grandes, múltiplos times podem possuir permissões para modificar recursos na AWS. Por isso, o CloudTrail acaba funcionando também como uma camada de governança operacional.

Parameter Groups

Poucas coisas são tão perigosas quanto alterações mal planejadas em parameter groups. Uma simples alteração de parâmetro pode modificar completamente o comportamento do banco. Dependendo do engine, isso pode impactar consumo de memória, paralelismo, checkpoints, WAL, replication, binlogs, cache ou quantidade de conexões. Eventos que merecem atenção especial em qualquer investigação.:

ModifyDBParameterGroup

ModifyDBClusterParameterGroup

ResetDBParameterGroup

Em PostgreSQL, por exemplo, mudanças relacionadas a WAL podem impactar replicação e recuperação. Em MySQL, alterações envolvendo binlogs podem aumentar consumo de storage rapidamente. Em ambientes de alta carga, parâmetros inadequados podem causar pressão de memória e degradação severa de performance.

Além disso, muitos parâmetros exigem reboot para aplicação. Isso significa que uma alteração aparentemente pequena pode acabar gerando indisponibilidade planejada, ou pior, uma indisponibilidade inesperada.

Maintenance e patching

Outro cenário extremamente comum envolve manutenção automática e aplicação de patches. Dependendo da configuração do ambiente, a AWS pode aplicar atualizações de sistema operacional, patches do engine, mudanças de infraestrutura subjacente ou correções críticas. No CloudTrail, isso aparece através de eventos como:

ApplyPendingMaintenanceAction

Esta ação pode causar reboots, failovers, pequenas indisponibilidades ou reconexões temporárias.

Muitas vezes o time recebe alerta de indisponibilidade e começa imediatamente a investigar queries lentas ou locks, quando na verdade o ambiente acabou de passar por uma manutenção planejada.

Por isso entender maintenance windows e políticas de Auto Minor Version Upgrade é fundamental.

Chaves de criptografia KMS

Um ponto menos óbvio mas extremamente importante envolve chaves KMS utilizadas por bancos criptografados. Eventos como:

DisableKey

ScheduleKeyDeletion

podem causar impactos severos em ambientes RDS criptografados. Dependendo do cenário, snapshots podem se tornar inacessíveis, restores podem falhar e operações do banco podem ser comprometidas.

Esse tipo de evento mostra como, em cloud, o funcionamento do banco depende de diversos serviços integrados da AWS. Hoje, investigar incidentes de banco exige entender também IAM, KMS, VPC e serviços de infraestrutura.

Construindo uma timeline de incidente

Uma das abordagens mais eficientes durante troubleshooting é montar uma timeline do incidente correlacionando múltiplas fontes de informação.

Normalmente começo verificando os eventos do próprio RDS, métricas do Amazon CloudWatch e comportamento da aplicação. Depois parto para o CloudTrail procurando alterações recentes no período da indisponibilidade.

Em muitos casos, eventos como ModifyDBInstance, RebootDBInstance, alterações em Security Groups ou mudanças de rota aparecem poucos minutos antes do início do incidente. Isso muda completamente a direção da investigação.

Ao invés de aprofundar imediatamente em análise de queries ou tuning, o foco passa a ser identificar qual mudança operacional provocou a indisponibilidade.

Essa capacidade de correlacionar infraestrutura e banco de dados é uma das habilidades mais importantes para profissionais que trabalham com bancos de dados gerenciados em cloud.

TL;DR : Actions do CloudTrail que podem indicar incidentes em RDS

A ideia não é decorar cada evento, mas entender que muitos incidentes de banco de dados em cloud têm origem em mudanças de infraestrutura, rede, segurança ou operações administrativas realizadas ao redor do banco.

Durante troubleshooting, essa visão ajuda a reduzir drasticamente o tempo de investigação e a construir uma timeline mais precisa do incidente.

Componente AWS	Evento do CloudTrail Principal	Sintoma na Aplicação	Comportamento Interno do RDS
Security Group	AuthorizeSecurityGroupIngress / RevokeSecurityGroupIngress	Connection Timeout imediato	Saudável (Métricas normais, CPU baixa)
Route Table	ReplaceRouteTableAssociation / CreateRoute	Perda de acesso em subnets específicas	Saudável, mas isolado da rede
VPC Peering / TGW	DeleteVpcPeeringConnection / DeleteTransitGatewayVpcAttachment	Erro de conexão entre contas/VPCs distintas	Saudável (Localmente acessível)
RDS Engine	ApplyPendingMaintenanceAction / ModifyDBInstance	Desconexão súbita ou lentidão pós-reboot	Estado: maintenance ou rebooting
AWS KMS	DisableKey / ScheduleKeyDeletion	Erro crítico de I/O na aplicação	Crash imediato / Estado: storage-error

O DBA precisa olhar além do banco

Talvez a principal conclusão seja que ambientes cloud mudaram profundamente a forma como investigamos incidentes. Hoje, indisponibilidade de banco nem sempre significa problema no banco.

Um RDS pode parecer fora do ar por conta de rede, segurança, IAM, manutenção, patching, failover, alterações de infraestrutura ou automações executadas por outros times.

Por isso, para DBAs e DBREs modernos, entender CloudTrail deixou de ser apenas uma habilidade de auditoria e passou a fazer parte da própria investigação operacional de incidentes.

No fim das contas, o banco continua sendo o coração da aplicação. Mas em cloud, esse coração depende diretamente de toda a infraestrutura ao redor dele.