Guia

Rollback automático para uma implantação ECS Fargate com falha, sem scripts personalizados.

→Habilite o disjuntor de implantação do ECS com rollback no serviço ECS.

Por quê: Recurso nativo do ECS que faz rollback automaticamente se as novas tarefas falharem ao estabilizar. Menor sobrecarga operacional em comparação com sondagem personalizada do CodeBuild ou configurações complexas do CodeDeploy.

Referência↗

Implante em uma região primária, valide com testes automatizados e, em seguida, implante em outras regiões em paralelo.

→Use um único CodePipeline com estágios sequenciais: (1) Implantação na Região A, (2) um estágio de teste CodeBuild que executa a validação, (3) um estágio de implantação paralela para as Regiões B e C.

Por quê: O CodeBuild atua como um portão programático automatizado. Um único pipeline é mais simples do que orquestrar múltiplos pipelines com Step Functions.

Um script de validação de longa execução em um hook de ciclo de vida do CodeDeploy causa sucesso prematuro da implantação.

→Aumente a propriedade `timeout` para o script de hook de ciclo de vida específico no arquivo `AppSpec.yml`.

Por quê: O timeout é configurado por hook no arquivo AppSpec, não no nível do grupo de implantação. Isso garante que o script de validação tenha tempo suficiente para ser concluído.

Acelerar builds lentas de imagens Docker do CodeBuild causadas pelo re-download de dependências e camadas de imagem a cada execução.

→Na configuração do projeto CodeBuild, habilite `LOCAL_DOCKER_LAYER_CACHE` e configure um cache S3 para diretórios de dependência (por exemplo, `.m2`, `node_modules`).

Por quê: Aborda diretamente ambas as causas de lentidão. O cache de camadas Docker reutiliza camadas de imagem inalteradas; o cache S3 reutiliza dependências de aplicativos baixadas.

Implementar uma implantação canário para uma função Lambda com rollback automatizado e baseado em métricas.

→Use o AWS SAM com `DeploymentPreference` (por exemplo, tipo `Canary10Percent5Minutes`). Adicione um alarme do CloudWatch na métrica `Errors` como um gatilho de rollback.

Por quê: O SAM se integra nativamente ao CodeDeploy para Lambda, automatizando a mudança de tráfego de alias, monitoramento e rollback sem scripts personalizados.

Referência↗

Configurar o IAM para um CodePipeline na Conta A para implantar recursos na Conta B.

→A função do pipeline (Conta A) assume uma função de ação (Conta B). A função de ação em B confia na função do pipeline e tem permissões de implantação. O bucket de artefatos S3 e a chave KMS em A devem ter políticas de recurso concedendo acesso à função de ação em B.

Por quê: Este é o padrão de acesso seguro e padrão entre contas: assunção de função para ações, políticas baseadas em recursos para acesso a dados.

Implementar um fluxo de trabalho GitOps para EKS onde o estado do cluster é automaticamente e continuamente reconciliado com um repositório Git.

→Implante um controlador GitOps (por exemplo, Flux, ArgoCD) no cluster EKS. Configure-o para monitorar o repositório Git e aplicar/reconciliar as mudanças.

Por quê: Este é o padrão GitOps "pull-based" padrão. O controlador no cluster lida com a reconciliação contínua e a detecção de drift, que é o princípio central do GitOps.

Permitir que um projeto CodeBuild em uma conta de ferramentas central implante manifestos Kubernetes em clusters EKS em contas de workload separadas.

→Em cada conta de workload, crie uma função IAM entre contas confiada pela função do CodeBuild. Mapeie esta nova função para um grupo RBAC do Kubernetes no ConfigMap `aws-auth` do cluster EKS. O script do CodeBuild assume a função antes de executar `kubectl`.

Por quê: Este é o padrão seguro e padrão para acesso EKS entre contas. Ele segue o princípio do menor privilégio, criando uma função dedicada e confiável para essa finalidade.

Realizar uma migração de esquema complexa para RDS PostgreSQL ou MySQL com tempo de inatividade zero ou próximo de zero.

→Use o recurso Amazon RDS Blue/Green Deployments. Crie um ambiente de staging (verde) sincronizado, aplique as alterações de esquema nele e, em seguida, faça o switchover para promovê-lo à produção.

Por quê: Este é o serviço gerenciado e construído especificamente para atualizações seguras e com tempo de inatividade zero do RDS. Ele lida com clonagem, sincronização e um switchover rápido (< 1 min) com salvaguardas integradas.

Implantar uma nova versão de uma aplicação de página única (SPA) no S3/CloudFront e garantir que os usuários recebam a nova versão imediatamente com custos mínimos de invalidação de cache.

→Use hash baseado em conteúdo para nomes de arquivos de ativos (por exemplo, `app.a1b2c3d4.js`). Após implantar novos ativos, invalide apenas o arquivo `index.html` na distribuição do CloudFront.

Por quê: Nomes de arquivos com hash são únicos, então o CloudFront os trata como novos objetos e os busca da origem, ignorando o cache. Apenas o arquivo de ponto de entrada único (`index.html`) precisa de invalidação, o que é significativamente mais barato do que uma invalidação curinga (`/*`).

Implementar um pipeline CI/CD para uma aplicação AWS CDK que se atualiza automaticamente quando a própria definição do pipeline muda.

→Use o construto CDK Pipelines (`pipelines.CodePipeline`). Este construto cria um pipeline que inclui um estágio `SelfMutate` por padrão.

Por quê: CDK Pipelines é um construto de alto nível construído especificamente para este padrão. O estágio `SelfMutate` garante que o pipeline sempre reflita a definição mais recente do código antes de implantar as alterações da aplicação.

Implantar uma nova versão da aplicação que requer uma mudança de esquema de banco de dados retrocompatível (por exemplo, adição de novas colunas) com tempo de inatividade zero.

→Implemente um padrão de "expandir e contrair" (ou "alteração paralela"). Primeiro, implante as alterações aditivas e retrocompatíveis no esquema do banco de dados. Segundo, implante a nova versão da aplicação que usa o novo esquema. Ambas as versões, antiga e nova, podem coexistir com o banco de dados atualizado.

Por quê: Este padrão desacopla as implantações do banco de dados e da aplicação, garantindo que o estado do banco de dados seja sempre compatível com as versões antiga e nova da aplicação, permitindo assim implantações com tempo de inatividade zero.

Lançar gradualmente um novo recurso para segmentos de usuários específicos e medir o impacto nas métricas de negócio (por exemplo, taxa de conversão) usando testes A/B.

→Use o Amazon CloudWatch Evidently. Crie um recurso com múltiplas variações, um lançamento para controlar a porcentagem de rollout e um experimento para medir o impacto estatístico nas métricas definidas.

Por quê: O Evidently é um serviço construído especificamente para feature flagging e experimentação A/B, fornecendo não apenas o mecanismo de rollout, mas também o motor de análise estatística para medir o impacto.

Impor tags obrigatórias em todas as instâncias EC2 no momento do lançamento em uma AWS Organization.

→Use uma Service Control Policy (SCP) que nega `ec2:RunInstances`, a menos que as chaves de tag necessárias estejam presentes na solicitação.

Por quê: Controle preventivo que impede a criação de recursos não conformes. Aplica-se a todas as contas e não pode ser substituído por políticas IAM locais.

Referência↗

Gerenciar e rotacionar segredos (por exemplo, credenciais de banco de dados) usados por aplicativos em múltiplas contas sem tempo de inatividade.

→Use o AWS Secrets Manager com rotação automática habilitada. Conceda acesso entre contas usando políticas baseadas em recursos no segredo.

Por quê: O Secrets Manager suporta estratégias de rotação com zero tempo de inatividade (alternando usuários) e fornece compartilhamento seguro e nativo entre contas.

Implantar automaticamente recursos de segurança base em novas contas criadas através do Control Tower Account Factory.

→Use o evento de ciclo de vida `CreateManagedAccount` do Control Tower via EventBridge para acionar uma função Lambda que implanta um CloudFormation StackSet. Alternativamente, use Customizations for AWS Control Tower (CfCT).

Por quê: A automação orientada a eventos é o padrão escalável para estender as baselines do Control Tower sem intervenção manual após a criação da conta.

Habilitar o acesso do SSM Session Manager a instâncias EC2 em uma sub-rede privada sem acesso à internet.

→Crie endpoints de interface VPC (alimentados por PrivateLink) para os serviços `ssm`, `ssmmessages` e `ec2messages` na VPC.

Por quê: Os endpoints da VPC permitem que o agente SSM se comunique com o serviço inteiramente dentro da rede AWS, fornecendo o padrão de acesso mais seguro sem a necessidade de um NAT ou internet gateway.

Centralizar logs com retenção de longo prazo e protegê-los contra exclusão ou modificação, mesmo por administradores.

→Armazene logs em um bucket S3 com S3 Object Lock no modo de conformidade. Habilite a validação de integridade de arquivo de log do CloudTrail.

Por quê: O Object Lock (modo de conformidade) oferece proteção WORM que nem mesmo a conta root pode ignorar. A validação de integridade do arquivo de log fornece uma verificação criptográfica contra adulteração após a entrega.

Fornecer aos desenvolvedores uma maneira de autoatendimento para provisionar padrões de infraestrutura pré-aprovados sem conceder-lhes permissões completas de serviço AWS.

→Use o AWS Service Catalog. Crie um portfólio de produtos aprovados (definidos por modelos CloudFormation). Use restrições de lançamento para que o Service Catalog provisione recursos usando uma função IAM privilegiada gerenciada pela equipe da plataforma.

Por quê: O Service Catalog é o serviço AWS construído especificamente para criar catálogos curados de serviços de TI. As restrições de lançamento são o recurso chave de governança, permitindo que os desenvolvedores provisionem infraestrutura complexa sem terem as permissões subjacentes.

Fornecer segredos únicos de forma segura para diferentes microsserviços rodando como tarefas ECS, garantindo que cada serviço possa acessar apenas seus próprios segredos.

→Crie segredos separados do AWS Secrets Manager para cada serviço. Na definição da tarefa ECS, referencie os ARNs dos segredos na propriedade `secrets` da definição do contêiner. Limite a política da função IAM de execução da tarefa para permitir apenas `secretsmanager:GetSecretValue` no ARN do segredo específico desse serviço.

Por quê: Isso impõe o princípio do menor privilégio em múltiplas camadas: o próprio segredo, a política IAM e a definição da tarefa ECS. Os segredos são injetados com segurança em tempo de execução.

Permitir que um fluxo de trabalho do GitHub Actions acesse o AWS de forma segura sem armazenar credenciais de longa duração.

→Configure um provedor de identidade IAM OIDC para o GitHub. Crie uma função IAM com uma política de confiança que restringe o principal federado à organização, repositório e branch específicos do GitHub. Use a ação `aws-actions/configure-aws-credentials` com OIDC para assumir a função.

Por quê: A federação OIDC é o método mais seguro, fornecendo credenciais de curta duração restritas a uma execução de fluxo de trabalho específica, eliminando o risco de exposição de credenciais de longa duração.

Monitorar continuamente todas as políticas IAM em uma AWS Organization para identificar e ser alertado sobre recursos compartilhados com entidades externas.

→Habilite o IAM Access Analyzer no nível da organização, definindo a organização como a zona de confiança. Use o EventBridge para capturar novas descobertas e acionar notificações.

Por quê: O IAM Access Analyzer foi construído especificamente para usar raciocínio automatizado para encontrar recursos compartilhados externamente. Executá-lo no nível da organização fornece uma visão contínua e centralizada sem scripts personalizados.

Reduzir o raio de impacto de atualizações falhas do CloudFormation em uma arquitetura de stack monolítica ou aninhada.

→Decomponha a arquitetura em stacks independentes usando referências entre stacks (CloudFormation Exports/Fn::ImportValue).

Por quê: Uma falha em uma stack (por exemplo, banco de dados) não acionará um rollback de outras stacks atualizadas com sucesso (por exemplo, rede), isolando domínios de falha.

Gerenciar centralizadamente o patching entre contas com diferentes agendamentos para ambientes de produção e não produção.

→Use o AWS Systems Manager Patch Manager com baselines de patch personalizadas, janelas de manutenção separadas para cada ambiente e o Systems Manager Explorer para relatórios de conformidade centralizados.

Por quê: Suporta nativamente todos os requisitos: definições de patch personalizadas, agendamento flexível via janelas de manutenção e visibilidade entre contas via Explorer.

Visualizar as mudanças de infraestrutura em todas as contas de destino antes de executar uma atualização do CloudFormation StackSet.

→Crie e revise um conjunto de mudanças do CloudFormation para a operação do StackSet antes da execução.

Por quê: Os conjuntos de mudanças são o mecanismo nativo do CloudFormation para visualizar as alterações exatas de recursos (adicionar, modificar, excluir) que uma atualização realizará.

Garantir que o CloudFormation espere o script UserData de uma instância EC2 ser concluído com sucesso antes de prosseguir com a criação da stack.

→Adicione uma `CreationPolicy` com `ResourceSignal` ao recurso da instância EC2. Chame o script auxiliar `cfn-signal` do UserData após a conclusão bem-sucedida.

Por quê: Este é o mecanismo nativo do CloudFormation para coordenar com scripts de configuração em um recurso. A falha em sinalizar dentro do timeout aciona automaticamente um rollback da stack.

Detectar quando alterações manuais e fora de banda fazem com que os recursos implantados difiram de sua definição no modelo do CloudFormation.

→Execute a detecção de drift do CloudFormation na stack periodicamente. Para detecção contínua, use a regra do AWS Config `cloudformation-stack-drift-detection-check`.

Por quê: A detecção de drift é o recurso nativo para comparar o modelo de uma stack com o estado real de seus recursos. Usar a regra do Config automatiza essa verificação.

Proteger recursos com estado (por exemplo, um bucket S3 ou banco de dados RDS) contra exclusão ou substituição acidental via operações de stack do CloudFormation.

→No recurso, defina `DeletionPolicy: Retain` (ou `Snapshot` para RDS). Na stack, habilite `TerminationProtection`. Aplique uma `StackPolicy` que nega as ações `Update:Replace` e `Update:Delete` no recurso crítico.

Por quê: Fornece defesa em profundidade: Termination Protection impede a exclusão da stack, DeletionPolicy preserva o recurso se a stack for excluída, e a Stack Policy impede atualizações destrutivas.

Migrar um CloudFormation StackSet de um modelo complexo de função IAM autogerenciada para um modelo de permissões mais simples para uma AWS Organization.

→Atualize o StackSet para usar permissões gerenciadas por serviço.

Por quê: As permissões gerenciadas por serviço aproveitam o acesso confiável do Organizations, eliminando a necessidade de criar e gerenciar funções IAM em cada conta de destino. Também permite a implantação automática em novas contas adicionadas a OUs direcionadas.

Um recurso personalizado do CloudFormation precisa gerenciar uma tarefa que leva mais tempo do que o timeout de 15 minutos da função Lambda.

→Acione uma máquina de estado do AWS Step Functions a partir da função Lambda do recurso personalizado. A máquina de estado lida com a tarefa de longa duração usando estados de Espera ou o padrão Task Token e envia a resposta de volta para a URL pré-assinada do S3 do CloudFormation.

Por quê: O Step Functions foi projetado para orquestrar fluxos de trabalho de longa duração e múltiplas etapas, contornando efetivamente a limitação de timeout do Lambda, enquanto mantém a integração com o CloudFormation.

Impor centralmente uma política (por exemplo, todos os buckets S3 devem ter versionamento) em toda uma aplicação AWS CDK, independentemente de como os desenvolvedores definem seus recursos.

→Crie um CDK Aspect que implemente a interface `IAspect`. O Aspect visita todos os construtos na árvore da aplicação, encontra todos os construtos de bucket S3 e aplica a configuração necessária ou adiciona um erro de validação se estiver faltando.

Por quê: Aspects são o padrão oficial do CDK para aplicar preocupações transversais e implementar validações de política como código centralmente, sem modificar construtos individuais.

Impedir que operações automatizadas, como patching via SSM Maintenance Windows, sejam executadas durante períodos específicos e variáveis (por exemplo, um bloqueio financeiro trimestral).

→Use o SSM Change Calendar para definir eventos que marquem os períodos de bloqueio como "fechados". Associe o Change Calendar à Janela de Manutenção.

Por quê: O Change Calendar atua como um portão para automações. Ele bloqueia automaticamente a execução durante períodos "fechados" sem exigir alterações manuais no agendamento da Janela de Manutenção, tornando-o altamente eficiente para gerenciar períodos de bloqueio dinâmicos.

Gerenciar centralizadamente a instalação e o versionamento de um pacote de software personalizado (por exemplo, um agente de monitoramento) em uma frota de instâncias EC2.

→Empacote o software usando o SSM Distributor. Use o SSM State Manager para criar uma associação que aplique o pacote do Distributor a todas as instâncias de destino.

Por quê: O Distributor gerencia o ciclo de vida do pacote (incluindo versões). O State Manager garante que o estado desejado (por exemplo, "versão 1.2 do agente está instalada") seja continuamente imposto, remediando automaticamente o drift e configurando novas instâncias.

Recuperação de desastres com RPO baixo (< 1 min) e RTO (< 5 min) para um banco de dados Aurora e camada de aplicação em várias regiões.

→Use um Aurora Global Database para replicação de banco de dados em sub-segundos. Para a camada de aplicativo, use um "warm standby" com um grupo de Auto Scaling configurado para capacidade desejada 0, para ser escalado por automação em caso de failover.

Por quê: O Aurora Global Database fornece RPO em sub-segundos e RTO < 1 minuto. A camada de aplicativo "warm standby" é econômica enquanto ainda atende a um RTO rápido.

Reduzir o tempo de scale-out do grupo de Auto Scaling para instâncias que possuem longos tempos de bootstrap/inicialização.

→Crie uma "AMI dourada" pré-configurada com dependências instaladas. Configure um warm pool no grupo de Auto Scaling para manter as instâncias pré-inicializadas.

Por quê: Uma AMI dourada minimiza o tempo de bootstrap. Um warm pool minimiza o tempo de lançamento (iniciar versus lançar). Juntos, eles reduzem drasticamente o tempo para uma nova instância ficar pronta para servir tráfego.

Um serviço ECS escala o número de suas tarefas, mas não consegue alocar novas tarefas porque o cluster EC2 subjacente está sem capacidade.

→Habilite o Auto Scaling do Cluster ECS associando um provedor de capacidade ao grupo de Auto Scaling do EC2 e ao cluster ECS.

Por quê: Provedores de capacidade vinculam o escalonamento do serviço ECS ao escalonamento da instância EC2. Quando as tarefas falham ao serem alocadas devido a recursos insuficientes do cluster, o provedor de capacidade escala automaticamente o ASG do EC2.

Escalar dinamicamente uma frota de instâncias de worker EC2 com base no número de mensagens em uma fila SQS.

→Use uma política de Auto Scaling de rastreamento de destino baseada na métrica personalizada: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (ou seja, backlog por instância).

Por quê: Este é o padrão recomendado para escalonamento baseado em SQS. Ele mantém workers suficientes para processar o backlog dentro de um tempo alvo, escalando eficientemente com a profundidade da fila.

Criar snapshots consistentes com a aplicação (não apenas crash-consistent) de volumes EBS para aplicações com estado.

→Use o AWS Backup com um plano de backup. No plano, use o Systems Manager Run Command para executar scripts pré-snapshot para "quiescer" a aplicação (ou habilitar VSS para Windows).

Por quê: O AWS Backup orquestra todo o processo. Quiescer a aplicação (liberar buffers de I/O para o disco) antes do snapshot garante a integridade dos dados e um estado de aplicação recuperável.

Garantir que eventos críticos de uma regra EventBridge não sejam perdidos quando um serviço de destino (por exemplo, Lambda) estiver temporariamente indisponível ou limitado (throttled).

→No alvo da regra EventBridge, configure uma Retry Policy (por exemplo, idade máxima de 24 horas) e uma Dead-Letter Queue (DLQ) usando uma fila SQS.

Por quê: A política de repetição lida com falhas transitórias automaticamente. A DLQ atua como uma rede de segurança final, capturando eventos que esgotam todas as tentativas para que possam ser reprocessados posteriormente, prevenindo a perda de dados.

Acionar alertas em tempo real sobre padrões de log específicos e incluir informações contextuais (por exemplo, linhas de log circundantes) na notificação.

→Use um filtro de assinatura do CloudWatch Logs para transmitir eventos de log correspondentes para uma função Lambda. A função Lambda formata e envia uma notificação detalhada (por exemplo, para SNS ou Chime).

Por quê: Os filtros de assinatura fornecem streaming de eventos em tempo real. O Lambda permite lógica personalizada para extrair e formatar contexto, o que filtros de métrica simples não conseguem fazer.

Identificar gargalos de latência em uma aplicação distribuída baseada em microsserviços.

→Habilite o rastreamento AWS X-Ray em pontos de entrada (por exemplo, API Gateway, ALB) e computação (por exemplo, Lambda, ECS). Use o SDK do X-Ray para chamadas downstream. Analise o mapa de serviço e os rastreamentos.

Por quê: O X-Ray é o serviço AWS construído especificamente para rastreamento distribuído. O mapa de serviço visualiza a cadeia de chamadas e destaca os serviços com alta latência e taxas de erro.

Criar um único alarme de alto nível que representa a saúde combinada de uma aplicação multi-camadas para reduzir o ruído de alertas.

→Crie alarmes CloudWatch individuais para cada camada (por exemplo, taxa de 5xx do ALB, CPU do aplicativo, conexões RDS). Em seguida, combine-os usando um alarme composto do CloudWatch com lógica OR.

Por quê: Alarmes compostos são projetados para reduzir o ruído de alarmes criando um único alarme lógico baseado no estado de múltiplos alarmes subjacentes.

Analisar petabytes de logs com consultas SQL complexas (incluindo junções) e retê-los por anos de forma econômica.

→Transmita logs para o Amazon S3 via Kinesis Data Firehose. Catalogue os dados com o AWS Glue. Consulte com o Amazon Athena. Use políticas de ciclo de vida do S3 para fazer a transição dos dados para Glacier/Deep Archive para retenção de longo prazo.

Por quê: Esta é a arquitetura padrão de data lake serverless. O Athena oferece recursos SQL poderosos em dados S3, e S3/Glacier oferece o armazenamento de longo prazo mais econômico.

Monitorar uma métrica com padrões cíclicos previsíveis (por exemplo, picos diários/semanais) e acionar um alarme apenas em desvios genuínos do padrão.

→Configure a Detecção de Anomalias do CloudWatch na métrica. Crie um alarme que é acionado quando o valor da métrica sai da faixa esperada pelo modelo.

Por quê: A Detecção de Anomalias usa aprendizado de máquina para aprender os padrões normais da métrica, criando uma faixa de limite dinâmico que se adapta aos ciclos. Isso reduz falsos positivos de picos previsíveis e melhora a relação sinal-ruído.

Obter visibilidade abrangente das métricas de CPU, memória, disco e rede em nível de contêiner para workloads em EKS ou ECS sem instalar e gerenciar ferramentas de terceiros.

→Habilite o Amazon CloudWatch Container Insights para o cluster EKS/ECS.

Por quê: O Container Insights é um serviço totalmente gerenciado que coleta, agrega e visualiza automaticamente métricas detalhadas de desempenho para workloads conteinerizadas, proporcionando visibilidade profunda com sobrecarga operacional mínima.

Monitorar a disponibilidade e o desempenho de uma aplicação voltada para a internet da perspectiva dos usuários finais, identificando problemas de rede em nível de ISP e geográfico.

→Habilite o Amazon CloudWatch Internet Monitor para a aplicação.

Por quê: O Internet Monitor aproveita os dados da rede global da AWS para fornecer visibilidade sobre o "clima da internet" que afeta seus usuários finais, ajudando a diagnosticar problemas fora do seu ambiente AWS.

Medir a experiência real do usuário de uma aplicação web coletando tempos de carregamento de página, erros de JavaScript e outras métricas de desempenho do lado do cliente.

→Integre o snippet JavaScript do CloudWatch RUM (Real User Monitoring) na aplicação web.

Por quê: O RUM é um serviço gerenciado que coleta dados de desempenho e erro do lado do cliente diretamente dos navegadores dos usuários, fornecendo uma visão real da experiência do usuário sem testes sintéticos.

Emitir métricas de aplicação personalizadas de uma função AWS Lambda com alta resolução e dimensões, sem adicionar a latência e o custo de chamadas diretas à API do CloudWatch.

→Use o CloudWatch Embedded Metric Format (EMF) escrevendo JSON especialmente estruturado para a saída padrão. Uma biblioteca cliente pode simplificar isso.

Por quê: O CloudWatch Logs extrai métricas automaticamente e assincronamente de entradas de log EMF, sem incorrer em latência adicional na função Lambda e reduzindo o custo ao evitar chamadas à API PutMetricData.

Corrigir automaticamente volumes EBS não criptografados detectados pelo AWS Config, garantindo a consistência dos dados durante o processo.

→Use a auto-remediação do AWS Config com um documento de Automação do Systems Manager. O runbook para a instância, cria uma cópia criptografada do volume, troca os volumes e reinicia a instância.

Por quê: A automação do SSM fornece um fluxo de trabalho robusto, multi-etapas e auditável. Parar a instância é fundamental para garantir um snapshot consistente dos dados antes de criar a cópia criptografada.

Executar experimentos controlados de engenharia do caos (por exemplo, injetar latência de rede) com condições de parada automáticas para prevenir impacto na produção.

→Use o AWS Fault Injection Simulator (FIS) com um modelo de experimento. Defina condições de parada com base em alarmes do CloudWatch que monitoram as principais métricas da aplicação.

Por quê: O FIS é o serviço AWS construído especificamente para engenharia do caos, fornecendo salvaguardas de segurança (condições de parada) e um catálogo de ações controladas de injeção de falhas.

Uma stack do CloudFormation está presa no estado `UPDATE_ROLLBACK_FAILED` porque um recurso foi excluído ou alterado durante uma atualização falha, impedindo um rollback limpo.

→Use a ação de API `ContinueUpdateRollback`, especificando o ID lógico do recurso problemático no parâmetro `ResourcesToSkip`.

Por quê: Este é o procedimento de recuperação padrão para forçar o rollback a ser concluído, instruindo o CloudFormation a ignorar o recurso que ele não pode mais gerenciar, retornando a stack a um estado estável.

Receber notificações em minutos sobre a ocorrência de eventos críticos de segurança, como login de conta root, alterações de política IAM ou modificações em grupos de segurança.

→Crie regras do Amazon EventBridge que correspondam a padrões específicos de eventos de gerenciamento do CloudTrail e as direcione para um tópico SNS para notificação.

Por quê: O EventBridge recebe eventos de gerenciamento do CloudTrail quase em tempo real, proporcionando a menor latência para alertas de segurança orientados a eventos em comparação com métodos de polling ou baseados em logs.

Uma função Lambda de alto tráfego está sendo limitada (throttled) e também esgotando as conexões do banco de dados RDS quando escala.

→Solicite um aumento do limite de execução concorrente do Lambda. Implemente o Amazon RDS Proxy entre as funções Lambda e o banco de dados RDS.

Por quê: O aumento da concorrência resolve o throttling. O RDS Proxy é essencial para aplicações serverless, pois ele agrupa e reutiliza conexões de banco de dados, evitando que o banco de dados seja sobrecarregado por um grande número de conexões efêmeras.

Implementar failover DNS automatizado entre regiões e acionar um runbook de recuperação automatizado para a região com falha.

→Use o roteamento de failover do Route 53 com verificações de saúde associadas. Crie uma regra do EventBridge que capture o evento de mudança de status da verificação de saúde do Route 53 e acione um runbook de automação do Systems Manager.

Por quê: Esta arquitetura combina o failover de tráfego automatizado (Route 53) com resposta a incidentes automatizada e orientada a eventos (EventBridge + Automação SSM) para um padrão completo de resiliência.

Prevenir que um banco de dados RDS fique sem armazenamento e cause uma interrupção da aplicação.

→Habilite o RDS Storage Autoscaling definindo um limite máximo de armazenamento. Como controle secundário, crie um alarme do CloudWatch na métrica `FreeStorageSpace`.

Por quê: O Storage Autoscaling é um recurso gerenciado e proativo que aumenta automaticamente o armazenamento alocado. O alarme do CloudWatch fornece uma rede de segurança para monitoramento e alerta.

Necessidade de reprocessar um lote de eventos que foram processados incorretamente devido a um bug temporário em um consumidor.

→Configure um EventBridge Archive no barramento de eventos antecipadamente. Após a correção do bug, crie um Replay para reenviar eventos da janela de tempo específica do incidente.

Por quê: Archive e Replay é o recurso nativo do EventBridge para armazenar e reprocessar eventos históricos, crucial para a recuperação de falhas de processamento transitórias.

Automatizar todo o processo de resposta a incidentes: criar um incidente, engajar a equipe de plantão, abrir um canal de chat e executar um runbook de remediação quando um alarme crítico é acionado.

→Crie um plano de resposta do SSM Incident Manager que define todas as etapas de engajamento e remediação. Configure o alarme do CloudWatch para acionar este plano de resposta como sua ação.

Por quê: Planos de resposta fornecem uma configuração única e coesa para orquestrar todos os aspectos da resposta a incidentes, reduzindo o esforço manual e garantindo procedimentos consistentes.