Como montar um dashboard de postura do RDS entre contas com ajuda do Kiro

Deletion protection no Amazon RDS é um único parâmetro booleano, e qualquer pessoa com permissão de ModifyDBInstance pode desligá-lo sem fricção nenhuma. Em uma conta isso já é motivo de atenção. Em uma organização com centenas de contas, a pergunta "quais bancos estão sem essa proteção agora" simplesmente não tem resposta direta, porque não existe um lugar central que agregue esse estado.

O AWS Database Blog publicou uma arquitetura de referência para resolver exatamente isso: um dashboard único no Amazon CloudWatch que mostra, organização inteira, quais instâncias e clusters RDS/Aurora estão sem deletion protection, Multi-AZ ou backup configurado, quem desligou cada proteção e quando, e quais engines estão perto do fim do suporte padrão. O pedido veio de um time de infraestrutura de uma empresa global de serviços financeiros que já tinha visão equivalente para Amazon EKS e queria o mesmo para banco de dados.

A arquitetura: EventBridge como cano, não como produto

A solução não inventa um novo mecanismo de detecção. Ela aproveita cinco serviços que já avaliam seus bancos (AWS Trusted Advisor, AWS Security Hub CSPM, AWS CloudTrail, AWS Config e AWS Health) e que já publicam eventos no Amazon EventBridge. A peça que faltava era o cano: cada conta-membro encaminha esses eventos para um barramento customizado (rds-posture-bus) numa conta central, que grava tudo num log group do CloudWatch Logs, deriva métricas via metric filters e renderiza um dashboard de 12 widgets.

Não há função Lambda para manter nem banco próprio para operar. Cinco regras no barramento central escrevem eventos correspondentes no log group /rds-posture/events, nove metric filters alimentam a namespace RDSPosture, e dois alarmes monitoram duas dessas métricas. Para quem já mexeu com EventBridge entre contas, o ponto relevante é que o Amazon EventBridge não reencaminha um evento recebido de uma conta para uma terceira: cada conta-membro precisa apontar diretamente para o barramento central, inclusive cruzando região quando a conta-membro não está na região central.

Onde o Kiro entra, e onde ele não entra

O repositório no GitHub (aws-samples/sample-code-for-rds-posture-dashboard) traz templates CloudFormation, configurações Terraform funcionalmente idênticas e um harness em Python que faz deploy, seed, teste e verificação via AWS CLI. O post deixa claro que o Kiro não é o dashboard: ele é o agente que constrói e valida cada peça contra uma conta real, seguindo um "skill" que o repositório já ensina ao assistente: o layout dos arquivos, a ordem de deploy e as regras que mantêm a visão confiável.

Na prática, isso muda o fluxo de trabalho de quem for customizar o painel. Em vez de escrever manualmente um padrão de evento do EventBridge, uma sintaxe de metric filter ou uma query do Logs Insights, o desenvolvedor descreve a intenção para o assistente:

Run preflight in this account and report what blocks the AWS Trusted Advisor feed.
Add a widget that lists Amazon RDS instances whose backup retention dropped under 7 days, proving the Logs Insights query first.
Do the same deployment with Terraform and prove that the resources end up identical.

A regra que o próprio time definiu é curta e vale copiar para qualquer projeto que use agente de código em infraestrutura: provar cada padrão, filtro e query com comandos de teste da AWS CLI antes de fazer deploy, manter dimensões de baixa cardinalidade e alterar os dois toolchains (CloudFormation e Terraform) juntos, nunca um sem o outro. O passo de revisão no console continua sendo humano; o verify do harness só prova que as queries parseiam, não que cada widget desenha certo.

O padrão de evento que vale estudar de perto

A regra do CloudTrail que detecta deletion protection desligada é o trecho mais reaproveitável para quem lida com RDS no dia a dia. Ela usa três alternativas num único $or:

"$or": [
 { "eventName": ["ModifyDBInstance", "ModifyDBCluster"], "requestParameters": { "deletionProtection": [false] } },
 { "eventName": ["CreateDBInstance", "CreateDBCluster"], "requestParameters": { "deletionProtection": [false, { "exists": false }] } },
 { "eventName": ["DeleteDBInstance", "DeleteDBCluster"] }
]

A segunda alternativa é a que mais gente esquece: uma chamada CreateDBInstance que simplesmente omite deletionProtection também cria um banco desprotegido, e o padrão precisa casar com a chave ausente, não só com o valor false explícito. No teste da própria equipe, um modify-db-instance --no-deletion-protection numa instância descartável moveu o alarme de transição de OK para ALARM em 5 minutos, com o histórico do alarme como prova.

Dois alarmes, duas perguntas diferentes

O dashboard separa o alarme de transição do alarme de estado, e misturar os dois é o erro mais fácil de cometer:

• Alarme de transição: dispara no evento do CloudTrail quando alguém desliga deletion protection via ModifyDBInstance ou ModifyDBCluster. Serve para pager e on-call.
• Alarme de estado: dispara sempre que o AWS Security Hub CSPM importa um finding FAILED para os controles RDS.7 (clusters) ou RDS.8 (instâncias). Como o Security Hub reavalia esses controles a cada mudança e pelo menos uma vez a cada 24 horas, esse alarme volta para ALARM repetidamente enquanto o banco permanecer desprotegido.

Tratar o alarme de estado como lembrete recorrente, e só rotear o alarme de transição para resposta imediata, evita fadiga de alerta sem perder rastreabilidade.

O custo: métricas customizadas dominam a conta

No ambiente de teste da AWS, métricas customizadas do CloudWatch (US$ 0,30 por métrica/mês nas primeiras 10 mil) foram o item que mais pesou na fatura. Como as dimensões usadas são nome do check, ID do controle e status (nunca conta ou recurso), a estimativa é de 50 a 150 séries por deployment, entre US$ 15 e US$ 45 por mês, com pior caso em torno de US$ 90 por mês para cerca de 300 séries.

Entrega de evento entre contas custa US$ 1,00 por milhão de eventos (pago pela conta que envia), mais transferência de dados entre regiões, e o CloudWatch Logs cobra ingestão e armazenamento, algo da ordem de poucos GB por mês mesmo para centenas de contas.

Três detalhes que custaram tempo ao time que construiu isso

Quem for reproduzir a arquitetura deve prestar atenção a três comportamentos documentados pela própria AWS:

1. Eventos em regiões diferentes do esperado: AWS Trusted Advisor, por ser um serviço global, emite tudo em us-east-1. Já o AWS Health entrega cada evento na região do recurso afetado e copia para uma região de backup (us-west-2 cobre a maioria das demais). Se a região-membro coincidir com a de backup, o parâmetro ExcludeHealthBackupEvents precisa ir para true, ou a tabela mostra cada evento em duplicidade.
2. Regra do Security Hub duplicada: a região doméstica da conta delegada administradora já carrega findings de toda conta-membro, com agregação entre regiões. Ter a regra habilitada em todo lugar duplica eventos; o parâmetro EnableSecurityHubRule deve ficar false no stack set organizacional e só ligado no deploy próprio da conta administradora.
3. Atraso de propagação de regra nova: a própria documentação do EventBridge avisa que regras recém-criadas podem não casar imediatamente. No teste da AWS, a primeira injeção do Kiro, 1 segundo após o deploy, não gerou match nenhum; os mesmos eventos 4 minutos depois fluíram ponta a ponta. O comando inject-test-events do harness já espera e conta eventos no log group central por isso, para não confundir atraso de propagação com deploy quebrado.

Para quem serve, e quando não compensa

Esse desenho é para times que já operam RDS/Aurora em múltiplas contas AWS e precisam responder, em auditoria ou em janela de mudança, "quais bancos estão sem proteção agora". Ele não substitui o AWS Security Hub CSPM nem o AWS Config como inventário autoritativo: o próprio post é explícito em dizer que o dashboard avisa e alerta, mas não muda nada. Também não cobre recomendações do console do RDS nem rightsizing do AWS Compute Optimizer, que chegam por console e API, não por evento no EventBridge.

Para quem opera uma conta só, ou um punhado delas, a complexidade de barramento central, seed e harness provavelmente não compensa: abrir o Security Hub e o Trusted Advisor diretamente já resolve. O ganho real aparece a partir de dezenas de contas, quando nenhuma dessas consoles individuais dá visão agregada e o custo de métrica customizada (dezenas de dólares por mês) é trivial perto do risco de um DeleteDBInstance acidental numa produção sem proteção.

Fonte: AWS Database Blog