Uma CLI de operação AWS sem nenhum delete: a matriz de risco que uso pra desenhar ferramenta interna

O problema que a ferramenta tenta resolver #

Ferramenta de operação em produção tem um jeito clássico de causar incidente: o operador sabe o comando certo, mas erra o profile, a região, ou o recurso — e só percebe depois que já rodou. Quanto mais poder a CLI dá, maior o raio de explosão de um erro de dedo.

A resposta não foi “documentar com cuidado”. Foi remover a classe de erro inteira de certas categorias: a ferramenta simplesmente não tem comando de delete, purge ou remove em nenhum dos módulos nativos. Se o plano é apagar algo, isso acontece fora dela, de propósito.

A matriz de impacto #

Toda ação do menu carrega uma classificação visível antes de rodar:

A interface principal não repete “READ-ONLY” em cada item — isso seria ruído. O impacto aparece no preview de cada ação, e a matriz completa fica documentada à parte. A maioria dos módulos (EC2, VPC, ELB, CloudWatch, RDS, SQS, SNS, EventBridge, CloudTrail) é 100% READ-ONLY — dá pra investigar qualquer incidente sem risco de alterar nada sem querer.

Onde a confirmação de verdade importa #

Toda ação com impacto real mostra um resumo legível — profile, região, recurso, o que vai mudar — antes do prompt [s/N]. Alguns exemplos de como isso se traduz em decisão de design:

• Force new deployment (ECS): mostra que vai reciclar as tasks do service e pode causar indisponibilidade se não houver capacidade ou health check adequado — não só “confirma?”, mas o efeito real esperado.
• Revelar secret (Secrets Manager/SSM): aviso duplo antes da confirmação — nunca grava tela nem log, e sugere limpar o scrollback do terminal depois.
• Scan de tabela DynamoDB: exige confirmação mesmo sendo leitura, porque scan sem filtro consome capacidade proporcional ao tamanho da tabela — o risco aqui não é destruir dado, é gerar custo/throttle.

Validação antes de qualquer chamada de escrita #

O módulo de DNS (Route53/ACM) valida localmente antes de tocar na AWS: IPv4 fora de faixa (287.68.70.10 é recusado sem nem chamar a API), CNAME apontando pro apex da zona, conflito de tipo no mesmo nome. Toda criação usa Action=CREATE — nunca DELETE, e só oferece UPSERT quando já existe o mesmo nome/tipo, sempre com confirmação explícita.

O provisionamento de infraestrutura (SPA em S3+CloudFront+ACM, por exemplo) segue o mesmo princípio: descobre o que já existe antes de qualquer write, é idempotente, e mostra o plano completo num preview antes de executar a primeira chamada.

Credencial nunca em texto plano quando dá pra evitar #

Perfis novos preferem aws-vault — a credencial fica no keychain do sistema operacional, nunca em arquivo. O modo texto plano existe só como fallback, com o arquivo protegido em 600. A mesma filosofia se repete em qualquer lugar que lida com segredo: nunca reaproveitar valor sensível pra além do necessário, sempre com aviso explícito antes de mostrar algo sensível na tela.

Tecnologias #

Bash · AWS CLI · fzf · jq · aws-vault