Uma conta AWS de médio porte muda de configuração dezenas de vezes por dia — uma regra de security group ajustada, um bucket S3 recriado, uma role IAM alterada às pressas para destravar um deploy. Sem uma trilha técnica dessas mudanças, a primeira vez que a empresa descobre um problema de configuração costuma ser durante um incidente ou uma auditoria, quando já é tarde para agir a tempo. O AWS Config e o AWS CloudTrail resolvem exatamente essa lacuna: juntos, formam a base técnica de auditoria contínua da AWS, registrando tanto o estado de cada recurso ao longo do tempo quanto cada chamada de API que mudou esse estado. Neste guia, você vai entender o que cada serviço faz, onde um começa e o outro termina, como estruturar os dois numa arquitetura multi-conta e que métricas acompanhar no dia a dia.
O Que É o AWS Config: Visibilidade Contínua da Configuração dos Recursos
O AWS Config é o serviço que mantém uma visão detalhada da configuração dos seus recursos AWS — como eles estão configurados agora, como estavam configurados no passado e como se relacionam entre si. Cada vez que um recurso monitorado (uma instância EC2, um volume EBS, um security group, uma VPC) é criado, alterado ou excluído, o Config gera um configuration item (CI): um registro estruturado do estado daquele recurso naquele momento exato.
Esse histórico de CIs é o que permite responder perguntas que um snapshot único do ambiente nunca responde: qual era a regra do security group X às 14h de terça-feira, antes do incidente começar? Quando esse bucket deixou de ter criptografia habilitada? Qual configuração o recurso tinha antes da última mudança, para reverter com segurança? O Config também mapeia relacionamentos entre recursos — por exemplo, quais instâncias EC2 usam determinado security group — o que ajuda a avaliar o impacto de uma mudança antes de aplicá-la, não só depois.
Managed Rules, Custom Rules e Remediação Automática
A parte prática do Config para governança contínua são as AWS Config rules: regras que representam a configuração ideal de um recurso, avaliadas automaticamente sempre que esse recurso é criado ou alterado. A AWS oferece um catálogo de managed rules pré-construídas e configuráveis — por exemplo, verificar se buckets S3 estão públicos, se volumes EBS estão criptografados, ou se instâncias EC2 têm um tipo aprovado. Quando o padrão do ambiente foge do catálogo pronto, é possível escrever custom rules com uma função Lambda, que recebe o evento de configuração e devolve um veredito de conformidade.
O terceiro elemento é a remediação: o Config pode disparar automaticamente um documento do AWS Systems Manager Automation sempre que um recurso é avaliado como não conforme — por exemplo, revogar uma regra de ingress liberada para 0.0.0.0/0 sem intervenção manual. Regras relacionadas podem ser agrupadas em conformance packs, um pacote único de regras e ações de remediação que pode ser implantado e monitorado como uma unidade só — e reaplicado igual em várias contas.
O Que É o AWS CloudTrail: a Trilha de Eventos de API da Sua Conta
Enquanto o Config mostra o estado de um recurso, o AWS CloudTrail mostra quem fez o quê: cada ação tomada por um usuário, role ou serviço da AWS é registrada como um evento, seja ela feita pelo console, pela CLI, por um SDK ou por uma chamada direta de API. O CloudTrail oferece três formas de acessar esses eventos:
Event history — um histórico navegável e pesquisável dos últimos 90 dias de eventos de gerenciamento por região, disponível automaticamente em toda conta AWS, sem custo para visualização.
Trails — capturam os eventos e os entregam de forma contínua a um bucket S3, com entrega opcional também para o CloudWatch Logs e o Amazon EventBridge. É o mecanismo para reter eventos além dos 90 dias do Event history e para alimentar ferramentas de SIEM ou de análise própria, como o Amazon Athena.
CloudTrail Lake — um data lake gerenciado que converte os eventos para o formato colunar Apache ORC e permite consultas SQL diretamente sobre eles, com retenção configurável de até 3.653 dias (cerca de 10 anos) na opção de um ano extensível, ou até 2.557 dias (cerca de 7 anos) na opção de retenção de sete anos.
Management Events vs Data Events: Onde Fica o Limite de Custo
Nem todo evento do CloudTrail tem o mesmo peso — e essa distinção é o ponto onde a maioria das empresas erra o dimensionamento de custo:
Management events registram operações de controle da própria infraestrutura — criar um bucket, alterar uma política do IAM, lançar uma instância EC2. Estão habilitados por padrão em toda trilha, e a primeira cópia entregue ao S3 não tem custo adicional do CloudTrail (apenas o armazenamento no S3).
Data events registram operações de acesso aos dados dentro do próprio recurso — uma leitura (GetObject) ou escrita (PutObject) num bucket S3, uma invocação de função Lambda. Ficam desabilitados por padrão porque o volume costuma ser ordens de grandeza maior que o de management events, e têm custo por evento registrado.
De acordo com a tabela de preços oficial do CloudTrail, cópias adicionais de management events custam US$ 2,00 por 100 mil eventos, enquanto data events e eventos de atividade de rede custam US$ 0,10 por 100 mil eventos. Na prática, isso significa habilitar data events de forma seletiva — só nos buckets e funções críticas — em vez de ligar para toda a conta de uma vez.
Config e CloudTrail Juntos: o Estado e o "Quem Fez o Quê"
Usados isoladamente, cada serviço responde só metade da pergunta de uma auditoria. O Config diz que a regra do security group mudou às 14h07 de terça-feira; o CloudTrail diz que foi o usuário joao.silva, autenticado via SSO, que chamou AuthorizeSecurityGroupIngress naquele exato minuto, de qual IP e com qual user agent. Cruzados, os dois formam uma trilha de auditoria completa — não só o que mudou, mas quem mudou e como.
| Critério | AWS Config | AWS CloudTrail |
|---|---|---|
| O que rastreia | Estado de configuração dos recursos ao longo do tempo | Chamadas de API (quem fez, quando, de onde) |
| Granularidade | Um configuration item por mudança de recurso | Um evento por chamada de API, incluindo leituras (se habilitado) |
| Pergunta que responde | "Como esse recurso estava configurado?" | "Quem fez essa mudança e como?" |
| Ativado por padrão | Não — precisa ser configurado por conta/região | Event history sim (90 dias); trails e data events não |
| Uso típico | Compliance contínuo, rightsizing de governança, rollback | Investigação de incidente, forense, alertas de atividade suspeita |
| Custo principal | Por configuration item e por avaliação de regra | Por evento além do Event history gratuito, sobretudo data events |
Modelos de Implementação: Conta Única vs Multi-Conta com AWS Organizations
Numa conta isolada, ativar Config e CloudTrail é uma tarefa direta: um recorder do Config, uma trilha do CloudTrail apontando para um bucket S3, e algumas managed rules relevantes já cobrem boa parte do terreno. O desafio real aparece quando a empresa opera dezenas de contas AWS, como costuma acontecer numa arquitetura de Landing Zone com AWS Organizations.
Nesse cenário, o padrão recomendado é centralizar: uma organization trail do CloudTrail, criada a partir da conta de gestão (ou de uma conta de segurança dedicada), captura os eventos de todas as contas-membro automaticamente — inclusive de contas novas, sem precisar configurar trilha uma a uma. O Config espelha essa lógica com organizational rules e aggregators, que consolidam o inventário de recursos e o status de conformidade de múltiplas contas e regiões num único painel. Isso evita o cenário mais comum de falha de auditoria: uma conta de desenvolvimento criada às pressas que nunca recebeu a mesma trilha de log das contas de produção.
Métricas, Alertas e Integração com CloudWatch e EventBridge
Ter o dado registrado não adianta se ninguém for notificado a tempo. A integração nativa do CloudTrail com o CloudWatch Logs e o Amazon EventBridge é o que transforma um log passivo em alerta ativo: um evento específico — como a criação de um usuário IAM com acesso de console fora do horário comercial, ou a desativação de uma trilha do CloudTrail (um sinal clássico de tentativa de encobrir rastro) — pode disparar uma regra do EventBridge que aciona uma notificação SNS, um workflow do Step Functions ou até uma remediação automática via Lambda.
Do lado do Config, o indicador mais direto para acompanhar é a taxa de conformidade por conjunto de regras — quantos recursos estão COMPLIANT versus NON_COMPLIANT em cada conformance pack — e a idade média de resolução de não conformidades, que mostra se a governança está reativa (alguém corrige quando lembra) ou realmente contínua (o desvio é fechado em horas, não em meses).
Casos de Uso por Porte de Empresa
Empresas em fase de crescimento, com uma ou poucas contas AWS — o ponto de partida costuma ser simplesmente ativar o Config com um conjunto enxuto de managed rules de segurança (criptografia, exposição pública, MFA) e uma trilha do CloudTrail com retenção de ao menos um ano, cobrindo o mínimo exigido por praticamente qualquer certificação ou cliente que peça evidência de auditoria.
Empresas de médio porte com múltiplas contas e times de engenharia distintos — o valor está em centralizar a visibilidade: organization trail, aggregator de Config, e alertas automáticos via EventBridge para os eventos de maior risco, sem depender de cada time lembrar de configurar isso na própria conta.
Empresas em setores regulados ou que atendem clientes com exigência contratual de compliance — CloudTrail Lake para consultas ad-hoc de longo prazo, conformance packs alinhados a frameworks como CIS AWS Foundations, e remediação automática ativa (não só alerta) para as regras mais críticas.
Tendências: IA na Auditoria Contínua de Nuvem
A quantidade de eventos gerados por uma conta AWS ativa é grande demais para revisão manual — e é aí que ferramentas de análise com machine learning vêm ganhando espaço, cruzando eventos do CloudTrail com padrões históricos de comportamento para sinalizar anomalias (um chamado de API incomum para aquele usuário, um pico de chamadas fora do padrão) muito mais rápido do que uma regra fixa conseguiria. O efeito prático é reduzir o tempo entre "a mudança suspeita aconteceu" e "alguém foi notificado" de dias para minutos — o mesmo movimento que já se vê em Zero Trust e IAM avançado na AWS, onde decisões de acesso passam a considerar contexto e comportamento, não só permissão estática.
Vale reforçar uma distinção importante: Config e CloudTrail são ferramentas de auditoria técnica de infraestrutura — elas mostram o que mudou na nuvem e quem mudou. Isso é diferente de conformidade legal de dados pessoais sob a LGPD, que trata de bases legais, consentimento e direitos do titular. Para uma empresa que precisa demonstrar conformidade com a LGPD, Config e CloudTrail entram como apoio técnico — evidenciando quem acessou ou alterou o ambiente onde dados pessoais são processados — mas não substituem o trabalho jurídico e de governança de dados que a LGPD exige.
Perguntas Frequentes sobre AWS Config e CloudTrail
Qual a diferença prática entre AWS Config e CloudTrail?
O Config rastreia o estado de configuração dos recursos ao longo do tempo — como cada recurso estava configurado em determinado momento. O CloudTrail rastreia as chamadas de API que causaram essas mudanças — quem fez, quando e de onde. Um mostra o resultado; o outro mostra a ação que levou a ele.
O AWS Config grava tudo automaticamente assim que a conta é criada?
Não. Diferente do Event history do CloudTrail, que já vem ativo, o AWS Config precisa ser configurado explicitamente por conta e região: é preciso ativar o recorder e escolher quais tipos de recurso serão monitorados antes de qualquer configuration item ser gerado.
Por quanto tempo o CloudTrail guarda o histórico de eventos?
O Event history gratuito cobre os últimos 90 dias de management events por região. Para reter por mais tempo, é necessário criar uma trilha (trail) apontando para um bucket S3, ou usar o CloudTrail Lake, que permite retenção configurável de até aproximadamente 10 anos, dependendo da opção de preço escolhida.
AWS Config e CloudTrail substituem uma ferramenta de SIEM?
Não diretamente. Eles são a fonte de dados — o CloudTrail gera os eventos, o Config gera o histórico de configuração — mas normalmente alimentam uma ferramenta de SIEM ou o próprio Security Hub da AWS para correlação, triagem e resposta a incidentes em maior escala.
Preciso ativar CloudTrail e Config em cada conta de uma AWS Organization separadamente?
Não é necessário nem recomendado. O caminho correto numa arquitetura multi-conta é criar uma organization trail no CloudTrail e usar organizational rules e aggregators no Config a partir da conta de gestão ou de uma conta de segurança dedicada — isso cobre automaticamente contas novas, sem depender de configuração manual em cada uma.
Habilitar data events no CloudTrail para toda a conta é uma boa prática?
Normalmente não, por causa do custo e do volume. A prática mais comum é habilitar data events seletivamente, apenas nos buckets S3 e funções Lambda que lidam com dados sensíveis ou críticos, em vez de ligar para todos os recursos de uma vez.
Config e CloudTrail atendem a exigências de auditoria de certificações como ISO 27001?
Ajudam a evidenciar boa parte dos controles técnicos de rastreabilidade e monitoramento de mudanças exigidos por frameworks desse tipo, mas fazem parte de um programa maior de gestão de segurança da informação — não substituem políticas, análise de risco e demais controles organizacionais que uma certificação exige.
AWS Config e CloudTrail Como Base Técnica da Conformidade Contínua na AWS
AWS Config e CloudTrail não competem entre si — se complementam para responder, a qualquer momento, duas perguntas que toda auditoria de infraestrutura eventualmente faz: como esse recurso estava configurado, e quem foi responsável pela mudança. Empresas que tratam isso como configuração padrão desde o início — não como algo para ativar depois de um incidente — chegam à auditoria (interna, de cliente ou de certificação) com a evidência já pronta, em vez de correndo atrás dela sob pressão de prazo.
Se sua empresa está estruturando ou revisando a governança técnica da conta AWS, vale avaliar isso junto com o restante da arquitetura de suporte em TI e da consultoria AWS especializada que sustentam a operação no dia a dia.
Artigos Relacionados
Para aprofundar em temas conectados a auditoria e governança na AWS:
- Landing Zone e AWS Organizations: Guia Avançado — a arquitetura multi-conta que sustenta organization trail e aggregators de Config em escala.
- Zero Trust e IAM Avançado na AWS — como decisões de acesso contextual se conectam à trilha de eventos que o CloudTrail registra.
- AWS Well-Architected Framework: o Guia Avançado — o pilar de Segurança do framework cobre boa parte do racional de auditoria contínua deste guia.
- Observabilidade na AWS: CloudWatch, X-Ray e Monitoramento Distribuído — a camada de métricas e alertas que transforma os eventos do CloudTrail em resposta em tempo real.
