# Design Doc: Jornada SRE com GenAI usando AWS Resilience Hub

Este documento propõe uma plataforma SRE baseada no AWS Resilience Hub com camada de GenAI para automatizar descoberta de dependências, análise de modos de falha e geração de runbooks em aplicações críticas. O objetivo é reduzir o risco operacional por meio de políticas de resiliência modulares e relatórios consolidados por organização, substituindo processos manuais propensos a lacunas. O design prioriza rastreabilidade, automação incremental e integração com pipelines CI/CD existentes.

- URL: https://fernando.moretes.com/studies/design-doc-resilience-hub-genai-sre-journey

- Markdown: https://fernando.moretes.com/studies/design-doc-resilience-hub-genai-sre-journey/study.md?lang=pt

- Type: Design Doc / RFC

- Company: SRE platform (cenário)

- Domain: Resiliência / SRE

- Date: 2026-06-03

- Tags: sre, aws-resilience-hub, genai, resiliency, failure-mode-analysis, runbooks, well-architected, operational-risk

- Reading time: 11 min

---

Equipes SRE em organizações com dezenas de aplicações críticas enfrentam um problema estrutural: a análise de resiliência é manual, pontual e raramente cobre a cadeia real de dependências. O AWS Resilience Hub, combinado com capacidades de GenAI, oferece uma rota concreta para automatizar esse ciclo — da descoberta ao runbook. Este RFC detalha como construir essa jornada de forma incremental, com trade-offs explícitos e critérios de sucesso mensuráveis.

## O Problema: Resiliência como Auditoria Pontual

Em ambientes financeiros e de missão crítica onde trabalhei, o padrão dominante de gestão de resiliência é o seguinte: uma vez por trimestre (ou antes de uma auditoria), alguém produz um documento de análise de impacto de negócio (BIA), mapeia dependências manualmente em uma planilha, e define RTOs/RPOs que frequentemente não refletem a arquitetura real em produção. Quando um incidente acontece, o runbook está desatualizado, a dependência crítica que ninguém documentou é exatamente a que falhou, e o post-mortem revela que o sistema nunca foi testado contra aquele modo de falha específico.

Esse padrão tem três causas raiz identificáveis. Primeiro, **descoberta de dependências é cara e manual**: mapear o que um serviço realmente consome — filas SQS, tabelas DynamoDB, endpoints de terceiros, funções Lambda encadeadas — requer acesso a múltiplas fontes de verdade (CloudFormation, Service Catalog, X-Ray, Config) que raramente são consultadas em conjunto. Segundo, **análise de modos de falha exige expertise escassa**: um engenheiro sênior precisa raciocinar sobre o que acontece quando cada componente falha, em que sequência, e com que impacto — trabalho que não escala para dezenas de aplicações. Terceiro, **políticas de resiliência são definidas por aplicação, sem visão organizacional**: cada squad define seus próprios thresholds de RTO/RPO sem referência a uma política corporativa, criando inconsistências que só aparecem durante incidentes reais.

O AWS Resilience Hub endereça os dois primeiros problemas com uma abordagem baseada em descoberta automática via CloudFormation, Terraform e AWS Service Catalog, análise de resiliência contra políticas definidas, e — mais recentemente — geração assistida por GenAI de recomendações e runbooks. Este documento propõe como estruturar essa adoção de forma que produza valor real, não apenas relatórios de conformidade.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Automatizar a descoberta de dependências para todas as aplicações críticas (Tier-1 e Tier-2) registradas no AWS Resilience Hub, com atualização contínua via pipeline CI/CD.
- ✅ OBJETIVO: Usar GenAI (Amazon Bedrock) para gerar análise de modos de falha (FMA) assistida, reduzindo o tempo de produção de análise por aplicação de dias para horas.
- ✅ OBJETIVO: Definir políticas de resiliência modulares por criticidade de negócio (Tier-1: RTO ≤ 1h / RPO ≤ 15min; Tier-2: RTO ≤ 4h / RPO ≤ 1h) aplicadas centralmente via AWS Organizations.
- ✅ OBJETIVO: Gerar runbooks operacionais versionados e linkados a alarmes CloudWatch específicos, substituindo documentação estática.
- ✅ OBJETIVO: Produzir relatórios de resiliência consolidados por unidade de negócio para consumo de liderança técnica e comitês de risco.
- ❌ NÃO-OBJETIVO: Substituir testes de caos (Chaos Engineering) — o Resilience Hub complementa, não substitui, ferramentas como AWS Fault Injection Service.

## Ficha Técnica do Cenário

- **Contexto:** Plataforma SRE corporativa — cenário composto baseado em padrões reais de organizações financeiras AWS
- **Escala estimada:** 50–150 aplicações críticas, 8–20 contas AWS, múltiplas regiões (us-east-1 primária, sa-east-1 secundária)
- **Ferramentas principais:** AWS Resilience Hub, Amazon Bedrock (Claude 3), AWS Organizations, CloudFormation, AWS Config, Amazon CloudWatch, AWS Systems Manager (SSM)
- **Fontes de descoberta:** CloudFormation stacks, Terraform state via S3, AWS Service Catalog, Resource Groups
- **Políticas de resiliência:** Tier-1 (RTO 1h / RPO 15min), Tier-2 (RTO 4h / RPO 1h), Tier-3 (RTO 24h / RPO 4h)
- **Modelo GenAI:** Amazon Bedrock com Claude 3 Sonnet (análise FMA e runbooks); Claude 3 Haiku (sumarização de relatórios)
- **Integração CI/CD:** AWS CodePipeline + CodeBuild com step de avaliação de resiliência como gate de deploy
- **Regulatório:** Alinhado a BACEN 4.557 (risco operacional), ISO 22301 (continuidade de negócio), SOC 2 Type II

## Design Proposto: Três Camadas de Automação

O design organiza a jornada SRE em três camadas funcionais que se alimentam sequencialmente, mas podem ser adotadas de forma incremental.

**Camada 1 — Descoberta e Modelagem Contínua**: O AWS Resilience Hub importa a definição de cada aplicação a partir de múltiplas fontes (CloudFormation stacks, Terraform state armazenado em S3, AWS Service Catalog portfolios). Essa importação não é um evento único — ela é acionada automaticamente via EventBridge sempre que um stack é atualizado em produção, garantindo que o modelo de resiliência reflita a arquitetura real. O resultado é um grafo de dependências versionado por aplicação, com componentes classificados por tipo (compute, storage, networking, database, messaging) e por criticidade derivada da política de resiliência associada.

Um ponto que frequentemente é subestimado: a **qualidade das tags** nos recursos AWS é o fator limitante desta camada. Sem tags consistentes de `Application`, `Tier`, e `Environment`, a descoberta automática produz grafos fragmentados que exigem curadoria manual. Por isso, o pré-requisito operacional desta fase é a implementação de uma política de tagging obrigatória via AWS Config Rules e Service Control Policies (SCPs) nas contas-alvo.

**Camada 2 — Análise Assistida por GenAI**: Após a descoberta, o Resilience Hub executa sua análise nativa de resiliência, comparando a arquitetura descoberta contra a política de RTO/RPO definida para aquele tier. O resultado é um conjunto de recomendações estruturadas (ex: "adicionar Multi-AZ ao RDS cluster X", "configurar DLQ na fila SQS Y"). Aqui entra a camada GenAI: um Lambda orquestrador invoca o Amazon Bedrock (Claude 3 Sonnet) com o payload da análise do Resilience Hub como contexto, solicitando três saídas específicas:

1. **Análise de Modos de Falha (FMA)**: Para cada componente crítico, o modelo raciocina sobre os cenários de falha mais prováveis, o impacto em cascata e a severidade estimada. O prompt é estruturado com o grafo de dependências, os thresholds da política e o histórico de incidentes (quando disponível via CloudWatch Logs Insights).

2. **Runbook Operacional**: Para cada recomendação de alta prioridade, o modelo gera um runbook no formato SSM Document, com passos de diagnóstico, comandos de remediação e critérios de escalação. O runbook é versionado no S3 e linkado ao alarme CloudWatch correspondente.

3. **Sumário Executivo**: Claude 3 Haiku (mais rápido e barato) gera um sumário em linguagem natural para consumo por líderes técnicos e comitês de risco, sem jargão de infraestrutura.

**Camada 3 — Governança e Feedback Loop**: Os resultados de todas as análises são agregados em um dashboard central (Amazon QuickSight) com visão por unidade de negócio, tier de criticidade e tendência temporal do score de resiliência. Um EventBridge Scheduler dispara reavaliações semanais automáticas para aplicações Tier-1. O feedback loop fecha quando os runbooks gerados são executados durante incidentes reais e os resultados são capturados via SSM Automation para refinamento futuro dos prompts.

## Arquitetura da Plataforma SRE com GenAI

Fluxo completo desde a descoberta de dependências até a geração de runbooks e relatórios organizacionais, mostrando as três camadas de automação e os pontos de integração com CI/CD e governança.

### 🔍 Camada 1 — Descoberta / Discovery Layer

- CloudFormation Stacks (ci)
- Terraform State (S3) (storage)
- Service Catalog Portfolios (ci)
- AWS Resilience Hub App Registry (compute)

### ⚙️ Camada 2 — Análise GenAI / GenAI Analysis Layer

- EventBridge Trigger (messaging)
- Lambda Orchestrator (compute)
- Amazon Bedrock Claude 3 Sonnet (ai)
- Amazon Bedrock Claude 3 Haiku (ai)
- FMA Output (S3 versioned) (storage)
- SSM Documents Runbooks (compute)

### 📊 Camada 3 — Governança / Governance Layer

- CloudWatch Alarms (security)
- Amazon QuickSight Dashboard (frontend)
- EventBridge Scheduler (weekly) (messaging)
- AWS Organizations Policy Hub (security)

### 🚀 CI/CD Integration

- CodePipeline Deploy Gate (ci)
- CodeBuild Resilience Check (ci)

### Fluxos

- cfn -> rh: importa stack
- tf -> rh: importa state
- sc -> rh: importa portfólio
- rh -> eb: análise concluída
- eb -> orch: aciona
- orch -> bedrock: FMA + runbook prompt
- orch -> haiku: sumário executivo
- bedrock -> fma: salva FMA
- bedrock -> ssm: cria runbook
- ssm -> cw: vincula alarme
- fma -> qs: alimenta dashboard
- haiku -> qs: sumário executivo
- sched -> rh: reavaliação semanal
- org -> rh: políticas tier
- pipe -> cb: gate de deploy
- cb -> rh: checa score

## Alternativas de Design Avaliadas

### AWS Resilience Hub + Bedrock (proposto)

**Pros**
- Descoberta automática integrada com CloudFormation/Terraform sem agente adicional
- GenAI contextualizada com o grafo de dependências real da aplicação
- Políticas de resiliência gerenciadas centralmente via Organizations
- Integração nativa com SSM para runbooks executáveis

**Cons**
- Custo de inferência Bedrock pode ser significativo para organizações com muitas aplicações (estimativa: $0.50–2.00 por análise completa com Sonnet)
- Qualidade da FMA gerada depende da qualidade das tags e da completude do grafo descoberto
- Resilience Hub não cobre recursos não-AWS nativamente

**Verdict:** Recomendado para organizações AWS-native com maturidade mínima de IaC (CloudFormation ou Terraform)

### Processo Manual com Templates de FMA

**Pros**
- Sem custo adicional de ferramentas
- Controle total sobre o conteúdo da análise

**Cons**
- Não escala além de 10–15 aplicações por engenheiro sênior por trimestre
- Grafos de dependência ficam desatualizados rapidamente em ambientes de deploy frequente
- Cobertura inconsistente entre squads e unidades de negócio

**Verdict:** Inadequado para organizações com mais de 20 aplicações críticas

### Solução de Terceiros (ex: Gremlin, Steadybit)

**Pros**
- Foco específico em chaos engineering com biblioteca de experimentos madura
- Multi-cloud por design

**Cons**
- Não integra com políticas de resiliência AWS Organizations nativamente
- Custo de licença elevado; sobreposição com AWS Fault Injection Service
- Não gera runbooks integrados com SSM

**Verdict:** Complementar ao design proposto para testes de caos, não substituto para análise de resiliência

### LLM Customizado com RAG sobre documentação interna

**Pros**
- Análises contextualizadas com histórico de incidentes e runbooks internos
- Potencial para recomendações mais precisas com dados proprietários

**Cons**
- Complexidade de engenharia muito maior; requer equipe de ML dedicada
- Time-to-value de 6–12 meses vs. semanas com Bedrock + Resilience Hub
- Manutenção contínua do pipeline RAG e curadoria do knowledge base

**Verdict:** Evolução natural do design proposto na Fase 3, não ponto de partida

## Considerações de Segurança e Governança de Dados

Em ambientes financeiros regulados, a introdução de GenAI em processos de análise de resiliência levanta questões legítimas que precisam ser endereçadas explicitamente no design, não tratadas como afterthought.

**Confidencialidade dos grafos de dependência**: O payload enviado ao Amazon Bedrock contém informações arquiteturais sensíveis — nomes de recursos, topologia de rede, configurações de banco de dados. É necessário garantir que: (1) o Bedrock está sendo invocado com endpoint VPC (Interface VPC Endpoint) para que o tráfego não transite pela internet pública; (2) os modelos Claude 3 via Bedrock não utilizam dados de clientes para treinamento por padrão (conforme documentação AWS) — mas isso deve ser verificado e documentado para fins de conformidade; (3) os outputs do modelo (FMAs e runbooks) são armazenados em S3 com criptografia SSE-KMS e acesso restrito por IAM roles específicas.

**Controle de acesso ao Resilience Hub**: As políticas de resiliência definidas no nível Organizations representam decisões de negócio críticas. O acesso de escrita ao Resilience Hub deve ser restrito a uma role de `ResiliencyPolicyAdmin` gerenciada pelo time de plataforma, com todas as mudanças auditadas via CloudTrail. Squads de produto têm acesso de leitura para consultar o score de suas aplicações, mas não podem modificar políticas ou thresholds.

**Validação dos outputs GenAI**: Este é o ponto mais crítico do design. Um runbook gerado incorretamente e executado durante um incidente pode piorar a situação. O processo de validação tem três etapas: (1) revisão humana obrigatória por um engenheiro SRE antes da publicação de qualquer runbook novo; (2) execução em ambiente de staging com AWS Fault Injection Service para validar que os passos de remediação produzem o efeito esperado; (3) versionamento explícito com status (`draft`, `reviewed`, `validated`, `deprecated`) — apenas runbooks com status `validated` são linkados a alarmes de produção.

**Custo de inferência como risco operacional**: Em uma organização com 100 aplicações Tier-1 e Tier-2, reavaliações semanais com Claude 3 Sonnet podem gerar custos de inferência na ordem de $200–800/mês (estimativa baseada em ~2000 tokens de input e ~1500 tokens de output por análise, a $0.003/1K input tokens e $0.015/1K output tokens para Sonnet). Esse custo é justificável, mas deve ser monitorado com AWS Cost Anomaly Detection e um budget alert específico para a workload de análise.

## Plano de Rollout em Fases

1. **Fase 0 — Pré-requisitos (Semanas 1–3)** — Auditoria e correção de tagging em todas as contas-alvo. Implementação de Config Rules obrigatórias para tags `Application`, `Tier`, `Environment`, `Owner`. Criação da estrutura de contas no Organizations com a conta de plataforma SRE centralizada. Definição e aprovação das políticas de resiliência por tier com stakeholders de negócio. Configuração de VPC Endpoints para Resilience Hub e Bedrock nas contas relevantes.

2. **Fase 1 — Piloto com 5 Aplicações Tier-1 (Semanas 4–7)** — Registro das 5 aplicações mais críticas no Resilience Hub. Execução manual das primeiras análises e validação dos grafos de dependência descobertos contra o conhecimento dos times de produto. Desenvolvimento e teste do Lambda orquestrador com integração Bedrock. Geração dos primeiros runbooks e revisão por engenheiros SRE sênior. Coleta de feedback qualitativo sobre qualidade e utilidade das FMAs geradas.

3. **Fase 2 — Expansão e Automação CI/CD (Semanas 8–12)** — Expansão para todas as aplicações Tier-1 e Tier-2 (estimativa: 30–60 aplicações). Implementação do gate de resiliência no CodePipeline: deploys que reduzem o score de resiliência abaixo do threshold da política requerem aprovação manual explícita. Configuração do EventBridge Scheduler para reavaliações automáticas semanais. Lançamento do dashboard QuickSight para liderança técnica. Treinamento dos squads de produto no processo de consulta e interpretação dos relatórios.

4. **Fase 3 — Maturidade e RAG (Semanas 13–20)** — Implementação de RAG (Retrieval-Augmented Generation) com Knowledge Base do Bedrock alimentado por histórico de post-mortems internos e runbooks validados. Integração com AWS Fault Injection Service para validação automatizada de runbooks em staging. Expansão para aplicações Tier-3. Relatórios automáticos mensais para comitês de risco com assinatura digital via KMS. Avaliação de cobertura multi-região e eventual extensão para workloads híbridas via AWS Systems Manager.

> **Riscos Críticos e Mitigações:** **RISCO 1 — Confiança excessiva nos outputs do GenAI**: O maior risco desta arquitetura não é técnico — é organizacional. Times sob pressão tendem a tratar recomendações geradas por IA como verdade absoluta, especialmente quando o modelo escreve com confiança. Mitigação: o processo de validação de runbooks (draft → reviewed → validated) é não-negociável e deve ser reforçado culturalmente, não apenas documentado. Considere um SLA explícito: nenhum runbook entra em produção sem revisão humana em menos de 48h.

**RISCO 2 — Deriva entre modelo e realidade**: O grafo de dependências no Resilience Hub reflete o estado do IaC, não necessariamente o estado real da infraestrutura se existirem recursos criados manualmente (ClickOps). Em organizações com maturidade de IaC parcial, isso cria uma falsa sensação de cobertura. Mitigação: AWS Config com regras de detecção de drift + alertas para recursos não gerenciados por IaC.

**RISCO 3 — O gate de CI/CD como bloqueador de deploy em crise**: Um gate de resiliência que bloqueia deploys pode ser contraproducente durante um incidente ativo onde a correção requer um deploy urgente. Mitigação: implementar um mecanismo de bypass com aprovação de dois engenheiros sênior + notificação automática para o CISO, auditado via CloudTrail.

**RISCO 4 — Custos de Bedrock em escala**: Análises frequentes de muitas aplicações podem gerar custos inesperados. Mitigação: implementar throttling no Lambda orquestrador, usar Haiku para análises de baixa prioridade, e configurar Cost Anomaly Detection com threshold de alerta em 150% do baseline mensal.

## Alinhamento com AWS Well-Architected Framework

- **security**: VPC Endpoints para Bedrock e Resilience Hub eliminam exposição à internet pública. IAM roles com least-privilege para acesso ao Resilience Hub. Outputs GenAI criptografados com SSE-KMS. CloudTrail habilitado para todas as operações administrativas no Resilience Hub e Organizations.
- **reliability**: Endereça diretamente o pilar de Confiabilidade: descoberta automática de dependências, definição de RTO/RPO por política, testes de resiliência integrados ao CI/CD e runbooks operacionais versionados. Alinhado às práticas REL-6 (gerenciar mudanças), REL-9 (testar procedimentos de recuperação) e REL-10 (recuperação automática de falhas).
- **performance**: Lambda orquestrador com concorrência reservada para análises Tier-1 garante latência previsível. Resultados de análise armazenados em S3 com cache para evitar reinvocações desnecessárias do Bedrock quando o grafo não mudou.
- **sustainability**: Uso de Haiku (modelo menor) para tarefas de sumarização reduz consumo computacional. Análises incrementais (apenas quando há mudança no grafo) evitam processamento desnecessário.

## Métricas de Sucesso e Targets

- **Cobertura de análise:** 100% das aplicações Tier-1 e Tier-2 com análise atualizada em ≤ 7 dias após qualquer mudança de stack
- **Tempo de produção de FMA:** Redução de 3–5 dias (manual) para < 4 horas (assistido por GenAI + revisão humana)
- **Score de resiliência Tier-1:** ≥ 85% das aplicações Tier-1 com score 'High' no Resilience Hub após 6 meses
- **Runbooks validados:** ≥ 1 runbook validado por aplicação Tier-1; 0 runbooks em status 'draft' linkados a alarmes de produção
- **MTTD de gaps de resiliência:** Redução de descoberta reativa (pós-incidente) para proativa (≤ 24h após deploy que introduz gap)
- **Custo de inferência:** < $1.000/mês para 100 aplicações com reavaliação semanal Tier-1 e mensal Tier-2 (estimativa)
- **Adoção pelos squads:** ≥ 80% dos squads de produto consultando o dashboard de resiliência mensalmente após 3 meses de operação

> **Minha Perspectiva Sênior:** Trabalhei em sistemas financeiros onde a análise de resiliência era tratada como exercício de conformidade — um documento produzido antes de uma auditoria e esquecido até a próxima. O problema fundamental não era falta de ferramentas; era que o custo de manter análises atualizadas era maior do que o custo percebido de não tê-las. O AWS Resilience Hub com GenAI muda essa equação de forma genuína, mas com uma ressalva importante que não vejo suficientemente discutida: **o valor real não está na geração automática de FMAs — está na descoberta contínua de dependências**.

A maioria dos incidentes sérios que investiguei não falhou porque alguém não sabia que o componente X era crítico. Falhou porque ninguém sabia que o componente X dependia do componente Y, que por sua vez dependia de um serviço de terceiros com SLA inferior ao necessário. O grafo de dependências do Resilience Hub, mantido atualizado via EventBridge, é o artefato mais valioso desta arquitetura — a FMA gerada pelo Bedrock é o segundo.

Se eu tivesse que priorizar uma única coisa para começar: invista as primeiras duas semanas exclusivamente em qualidade de tagging e cobertura de IaC. Uma análise de resiliência baseada em um grafo incompleto é pior do que não ter análise — ela cria confiança falsa. Só depois de ter a descoberta funcionando corretamente para 5 aplicações piloto é que eu adicionaria a camada GenAI.

Sobre a questão de confiar nos outputs do modelo: sou cético por princípio com qualquer sistema que gera recomendações operacionais sem validação humana estruturada. O processo draft → reviewed → validated não é burocracia — é o mecanismo que converte um texto gerado por modelo em um ativo operacional confiável. Remova essa etapa e você tem um sistema que parece sofisticado mas que pode fazer mais mal do que bem durante um incidente real.

## Veredicto

O design proposto é tecnicamente sólido e operacionalmente viável para organizações AWS-native com maturidade mínima de IaC. A combinação de AWS Resilience Hub para descoberta e análise estruturada com Amazon Bedrock para geração assistida de FMAs e runbooks resolve um problema real de escala que processos manuais não conseguem endereçar além de 20–30 aplicações críticas.

Os pré-requisitos não-negociáveis são dois: qualidade de tagging consistente nas contas AWS (sem isso, a descoberta é incompleta e o valor cai drasticamente) e um processo rigoroso de validação humana dos outputs GenAI antes de qualquer uso operacional. Esses dois elementos são mais importantes do que qualquer detalhe de implementação da arquitetura.

O rollout em fases é deliberadamente conservador — começar com 5 aplicações piloto antes de expandir não é timidez, é a única forma de calibrar a qualidade das análises geradas e construir confiança organizacional no processo. O gate de CI/CD é o artefato de maior impacto a longo prazo: ele institucionaliza a resiliência como critério de deploy, não como exercício periódico.

Para organizações em setores regulados (financeiro, saúde, infraestrutura crítica), este design também endereça requisitos de auditoria de forma mais rastreável do que processos manuais — os relatórios gerados automaticamente, com versionamento e assinatura KMS, são evidências de controle mais robustas do que planilhas atualizadas trimestralmente. O investimento em infraestrutura é modesto; o investimento em mudança de processo e cultura de validação é onde o esforço real reside.

## Referências

- [AWS Resilience Hub — Product Page](https://aws.amazon.com/resilience-hub/)
- [AWS News Blog — AWS Resilience Hub with Generative AI](https://aws.amazon.com/blogs/aws/)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [Amazon Bedrock — Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
- [AWS Fault Injection Service — Documentation](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
- [AWS Systems Manager — SSM Documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)
- [AWS Organizations — Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
- [AWS Config — Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)

## Fontes do caso

- [AWS News Blog — AWS Resilience Hub with generative AI](https://aws.amazon.com/blogs/aws/)
- [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/)
- [AWS Well-Architected — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)