# Confiabilidade
**Topics**
+ [Fundamentos](a-foundations.md)
+ [Arquitetura da carga de trabalho](a-workload-architecture.md)
+ [Gerenciamento de alterações](a-change-management.md)
+ [Gerenciamento de falhas](a-failure-management.md)
# Fundamentos
**Topics**
+ [REL 1 Como você gerencia as cotas e restrições de serviço?](w2aac19b9b5b5.md)
+ [REL 2 Como você planeja sua topologia de rede?](w2aac19b9b5b7.md)
# REL 1 Como você gerencia as cotas e restrições de serviço?
Para arquiteturas de carga de trabalho baseadas na nuvem, há cotas de serviço, que também são conhecidas como limites de serviço. Essas cotas existem para evitar o aprovisionamento acidental de mais recursos do que o necessário e para limitar as taxas de solicitação nas operações de API para proteger os serviços contra abuso. Há também restrições de recursos, por exemplo, a taxa de envio de bits por um cabo de fibra óptica ou a quantidade de armazenamento em um disco físico.
**Topics**
+ [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Acomodar as cotas e as restrições fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Certificar-se de que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Conhecimento das cotas e restrições de serviço
Você está ciente das suas cotas padrão e das solicitações de aumento de cota referentes à sua arquitetura de carga de trabalho. Você também sabe quais restrições de recursos, como disco ou rede, podem gerar impactos.
O Service Quotas é um serviço da AWS que ajuda você a gerenciar as cotas de mais de 100 serviços da AWS em um único local. Além de pesquisar os valores de cotas, você também pode solicitar e acompanhar aumentos de cota no console do Service Quotas ou por meio do AWS SKD. O AWS Trusted Advisor oferece uma verificação de cotas de serviço que exibe o uso e as cotas para certos aspectos de alguns serviços. As cotas de serviço padrão por serviço também estão na documentação da AWS com base no respectivo serviço. Por exemplo, consulte [Cotas da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). Os limites de taxa para APIs limitadas são definidos no próprio API Gateway por meio da configuração de um plano de uso. Outros limites definidos como configuração em seus respectivos serviços incluem IOPS provisionadas, armazenamento do RDS alocado e alocações de volume do EBS. O Amazon Elastic Compute Cloud (Amazon EC2) tem seu próprio painel de limites de serviço, que pode ajudar você a gerenciar sua instância, o Amazon Elastic Block Store (Amazon EBS) e os limites de endereços IP elásticos. Se você tiver um caso de uso em que as cotas de serviço afetam a performance do seu aplicativo e elas não forem ajustadas às suas necessidades, entre em contato com o AWS Support para ver se há mitigações.
**Antipadrões comuns:**
+ Implantar uma workload sem levar em consideração as cotas de serviço referentes aos serviços da AWS usados.
+ Projetar uma workload sem investigar e acomodar as restrições de design dos serviços da AWS.
+ Implantar uma workload com uso significativo que substitui uma workload existente conhecida sem antes configurar as cotas necessárias ou entrar em contato com o AWS Support.
+ Planejar um evento para direcionar o tráfego para sua workload, mas não configurar as cotas necessárias ou entrar em contato com o AWS Support com antecedência.
**Benefícios do estabelecimento desta prática recomendada:** Saber as cotas de serviço, os limites de controle de utilização da API e as restrições de design permite que você os inclua no projeto, na implementação e na operação da carga de trabalho.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Analise as cotas de serviço da AWS na documentação publicada e no Service Quotas.
+ [AWS Service Quotas (anteriormente chamado de limites)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Examine o código da implantação para determinar todos os serviços necessários à sua workload.
+ Use o AWS Config para encontrar todos os serviços da AWS usados na sua Contas da AWS.
+ [Recursos da AWS Config compatíveis com o AWS, tipos e relacionamentos de recursos](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ Você também pode usar o AWS CloudFormation para determinar os recursos da AWS usados. Examine os recursos que foram criados no Console de gerenciamento da AWS ou por meio do comando list-stack-resources da CLI. Você também pode ver no próprio modelo os recursos configurados para implantação.
+ [Visualize dados e recursos da pilha do AWS CloudFormation no Console de gerenciamento da AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI para o CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ Determine as cotas de serviço aplicáveis. Use as informações acessíveis programaticamente por meio do Trusted Advisor e do Service Quotas.
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor em AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões
Se você estiver usando várias Contas da AWS ou Regiões da AWS, solicite as cotas adequadas em todos os ambientes nos quais suas workloads de produção são executadas.
Cotas de serviço são rastreadas por conta. A menos que especificado de outra forma, cada cota é específica da Região da AWS. Além dos ambientes de produção, gerencie também as cotas em todos os ambientes aplicáveis que não são de produção, para que os testes e o desenvolvimento não sejam dificultados.
**Antipadrões comuns:**
+ Permitir que a utilização de recursos em uma zona de isolamento cresça sem nenhum mecanismo para manter a capacidade das demais.
+ Configurar manualmente todas as cotas nas zonas de isolamento independentemente.
+ Não garantir que as implantações isoladas regionalmente sejam dimensionadas para acomodar o aumento do tráfego de outra região se uma implantação for perdida.
**Benefícios do estabelecimento dessa prática recomendada:** Ao assegurar o processamento da carga atual se uma zona de isolamento estiver indisponível, você ajuda a reduzir o número de erros ocorridos durante o failover, em vez de causar uma negação de serviço aos seus clientes.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Selecione as contas e as regiões relevantes conforme seus requisitos de serviço, de latência, regulatórios e de recuperação de desastres (DR).
+ Identifique as cotas de serviço de todas as contas, regiões e zonas de disponibilidade relevantes. O escopo dos limites é definido para conta e região.
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor em AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 Acomodar as cotas e as restrições fixas de serviço por meio da arquitetura
Tenha conhecimento das cotas de serviço e dos recursos físicos imutáveis e elabore um plano para evitar que eles afetem a confiabilidade.
Alguns exemplos incluem largura de banda de rede, tamanho da carga do AWS Lambda, taxa de intermitência de controle para o API Gateway e conexões simultâneas de usuários com um cluster do Amazon Redshift.
**Antipadrões comuns:**
+ Realizar benchmarking por um período muito curto, utilizando o limite de intermitência, mas esperando que o serviço seja executado nessa capacidade por períodos prolongados.
+ Escolher um design que usa um recurso de um serviço por usuário ou cliente, sem saber que há restrições que causarão falha nesse design à medida que você escala.
**Benefícios do estabelecimento dessa prática recomendada:** O acompanhamento de cotas fixas nos serviços da AWS e de restrições em outras partes da workload, como restrições de conectividade, de endereço IP e de serviços de terceiros, permite detectar quando você está propenso a uma determinada cota e resolvê-la antes que seja excedida.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Esteja ciente das cotas e restrições fixas de serviço e arquitete de forma correspondente.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor em AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 Monitorar e gerenciar cotas
Avalie seu uso potencial e aumente suas cotas adequadamente, permitindo o crescimento planejado do uso.
Para serviços compatíveis, você pode gerenciar suas cotas por meio da configuração de alarmes do CloudWatch para monitorar o uso e alertá-lo sobre as cotas prestes a serem atingidas. Esses alarmes podem ser acionados a partir de cotas de serviço ou do Service Quotas. Você também pode usar filtros de métrica no CloudWatch Logs para pesquisar e extrair padrões nos logs para determinar se o uso está se aproximando dos limites de cota.
**Antipadrões comuns:**
+ Configurar alarmes para quando o Service Quotas estiver sendo atingido, mas não tiver um processo de resposta a um alerta.
+ Configurar alarmes apenas para serviços compatíveis com o Service Quotas e não monitorar outros serviços.
**Benefícios do estabelecimento dessa prática recomendada:** O acompanhamento automático das cotas de serviço da AWS e o monitoramento do seu uso em relação a essas cotas permitirão que você veja quando estiver perto de atingir um limite. Você também pode usar esses dados de monitoramento para avaliar quando é possível reduzir cotas para economizar custos.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Monitore e gerencie cotas. Avalie seu uso potencial na AWS, aumente suas cotas de serviço regionais adequadamente e permita o crescimento planejado do uso.
+ Capture o consumo atual de recursos (por exemplo, buckets, instâncias). Use as operações de API de serviço, como a API DescribeInstances do Amazon EC2, para coletar o consumo atual de recursos.
+ Capture suas cotas atuais. Use a documentação do AWS Service Quotas, AWS Trusted Advisor e da AWS.
+ Use o AWS Service Quotas é um serviço da AWS que ajuda você a gerenciar as cotas de mais de 100 serviços da AWS em um único local.
+ Use os limites de serviço do Trusted Advisor para determinar seus limites de serviço atuais.
+ Use as operações de API de serviço para determinar as cotas de serviço atuais, quando houver suporte.
+ Mantenha um registro dos aumentos de cota que foram solicitados e seus status. Após a aprovação de um aumento de cota, certifique-se de atualizar os registros para refletir a alteração.
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor para Limites de serviço](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Limit Monitor em AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Monitoramento do Service Quotas com alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 Automatizar o gerenciamento de cotas
Implemente ferramentas para alertar você quando os limites estiverem perto de serem atingidos. Ao usar as APIs do AWS Service Quotas, você pode automatizar as solicitações de aumento de cota.
Se você integrar o Configuration Management Database (CMDB) ou sistema de emissão de tíquetes com o Service Quotas, poderá automatizar o acompanhamento de solicitações de aumento de cota e as cotas atuais. Além do AWS SDK, o Service Quotas oferece automação usando o AWS Command Line Interface (AWS CLI).
**Antipadrões comuns:**
+ Acompanhar as cotas e o uso em planilhas.
+ Executar relatórios sobre o uso diário, semanal ou mensal e comparar o uso com as cotas.
**Benefícios do estabelecimento dessa prática recomendada:** O acompanhamento automatizado das cotas de serviço da AWS e o monitoramento do seu uso em relação a essa cota permitem que você veja quando está perto de atingir um limite. Você pode configurar a automação para ajudá-lo a solicitar um aumento de cota quando necessário. Você pode considerar a redução de algumas cotas quando seu uso estiver na direção oposta para aproveitar os benefícios do risco reduzido (no caso de credenciais comprometidas) e da economia de custos.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Configure o monitoramento automatizado. Implemente ferramentas usando SDKs para alertar você quando os limites estiverem perto de serem atingidos.
+ Use o Service Quotas e aumente o serviço com uma solução automatizada de monitoramento de cotas, como o AWS Limit Monitor ou uma oferta do AWS Marketplace.
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Monitoramento de cotas na AWS: solução da AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Configure respostas acionadas com base nos limites de cota por meio do Amazon SNS e das APIs do AWS Service Quotas.
+ Teste a automação.
+ Configure os limites.
+ Integre-se a eventos de alteração do AWS Config, de pipelines de implantação, do Amazon EventBridge ou de terceiros.
+ Defina limites baixos fictícios de cota para testar as respostas.
+ Configure gatilhos para executar a ação adequada mediante notificações e entre em contato com o AWS Support quando necessário.
+ Acione manualmente os eventos de alteração.
+ Execute um dia de jogo para testar o processo de alteração de aumento de cota.
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Monitoramento de cotas na AWS: solução da AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 Certificar-se de que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover
Quando um recurso falha, ele ainda pode ser incluído nas cotas até ser encerrado com êxito. Certifique-se de que suas cotas compensem a sobreposição de todos os recursos que falharam com substituições antes do encerramento desses recursos. Você deve considerar uma falha na zona de disponibilidade ao calcular essa lacuna.
**Antipadrões comuns:**
+ Configurar cotas de serviço com base nas necessidades atuais sem considerar os cenários de failover.
**Benefícios do estabelecimento desta prática recomendada:** Quando os eventos potencialmente afetam a disponibilidade, a nuvem permite que você implemente estratégias para atenuar ou recuperar estes eventos. Essas estratégias geralmente incluem a criação de recursos adicionais para substituir os que falharam. Sua estratégia de cota deve acomodar os recursos adicionais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Certifique-se de que há uma lacuna suficiente entre a cota de serviço e o uso máximo para acomodar um failover.
+ Determine suas cotas de serviço, considerando os padrões de implantação, os requisitos de disponibilidade e o aumento do consumo.
+ Solicite aumentos de cota, se necessário. Planeje o tempo necessário para que as solicitações de aumento de cota sejam atendidas.
+ Determine os requisitos de confiabilidade (também conhecidos como número de noves).
+ Estabeleça os cenários de falha (por exemplo, perda de um componente, uma zona de disponibilidade ou uma região).
+ Estabeleça a metodologia de implantação (por exemplo, canário, azul/verde, vermelho/preto ou gradual).
+ Inclua um buffer adequado (por exemplo, 15%) do limite atual.
+ Planeje o aumento do consumo (por exemplo, monitore suas tendências de consumo).
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos CMDB que ajudam a acompanhar os limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [O que é o Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 Como você planeja sua topologia de rede?
Muitas vezes, as cargas de trabalho estão presentes em vários ambientes. Dentre eles estão vários ambientes de nuvem (acessíveis publicamente e privados) e possivelmente sua infraestrutura de datacenter existente. Os planos devem incluir considerações de rede, como conectividade dentro dos sistemas e entre eles, gerenciamento de endereços IP públicos e privados e resolução de nomes de domínio.
**Topics**
+ [REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Provisionar conectividade redundante entre as redes privadas na nuvem e nos ambientes on-premises](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferir topologias hub-and-spoke em vez da malha muitos para muitos](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Aplicar intervalos de endereços IP privados não sobrepostos a todos os espaços de endereços privados onde estão conectados](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload
Esses endpoints e o roteamento para eles devem ser altamente disponíveis. Para que isso seja possível, use DNS altamente disponível, Redes de entrega de conteúdo (CDNs), API Gateway, balanceamento de carga ou proxies reversos.
O Amazon Route 53, a AWS o Global Accelerator, o Amazon CloudFront, o Amazon API Gateway, e o Elastic Load Balancing (ELB) fornecem endpoints públicos altamente disponíveis. Você também pode optar por avaliar os dispositivos de software do AWS Marketplace para o balanceamento de carga e o uso de proxy.
Os consumidores do serviço que sua carga de trabalho fornece, sejam eles usuários finais ou outros serviços, fazem solicitações nesses endpoints de serviço. Vários recursos da AWS estão disponíveis para permitir que você forneça endpoints altamente disponíveis.
O Elastic Load Balancing oferece balanceamento de carga entre zonas de disponibilidade, executa o roteamento da Camada 4 (TCP) ou da Camada 7 (http/https), integra-se ao AWS WAF e ao AWS Auto Scaling para ajudar a criar uma infraestrutura de autorreparação e absorver aumentos no tráfego com a liberação simultânea de recursos quando o tráfego diminuir.
O Amazon Route 53 é um serviço de Sistema de Nomes de Domínio (DNS) escalável e altamente disponível que conecta as solicitações de usuários à infraestrutura em execução na AWS, como instâncias do Amazon EC2, balanceadores de carga do Elastic Load Balancing ou buckets do Amazon S3. Além disso, também pode ser usado para direcionar os usuários para a infraestrutura fora da AWS.
O AWS Global Accelerator é um serviço de camada de rede que você pode usar para direcionar o tráfego para endpoints ideais pela rede global da AWS.
Ataques de negação de serviço distribuída (DDoS) arriscam interromper o tráfego legítimo e reduzir a disponibilidade para os seus usuários. O AWS Shield fornece proteção automática contra esses ataques, sem custo adicional para endpoints de serviços da AWS na sua workload. Expanda esses recursos com dispositivos virtuais de Parceiros do APN e o AWS Marketplace para atender às suas necessidades.
**Antipadrões comuns:**
+ Usar endereços de Internet públicos em instâncias ou contêineres e gerenciar a conectividade com eles por meio de DNS.
+ Usar endereços Internet Protocol em vez de nomes de domínio para localizar serviços.
+ Fornecer conteúdo (páginas da web, ativos estáticos, arquivos de mídia) para uma grande área geográfica e não usar uma rede de entrega de conteúdo.
**Benefícios do estabelecimento dessa prática recomendada:** Com a implementação de serviços altamente disponíveis em sua carga de trabalho, você sabe que ela estará disponível aos seus usuários.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
Verifique se você tem conectividade altamente disponível para os usuários da workload. O Amazon Route 53, a AWS o Global Accelerator, o Amazon CloudFront, o Amazon API Gateway, e o Elastic Load Balancing (ELB) fornecem endpoints públicos altamente disponíveis. Você também pode optar por avaliar os dispositivos de software do AWS Marketplace para o balanceamento de carga e o uso de proxy.
+ Verifique se você tem uma conexão altamente disponível para seus usuários.
+ Verifique se você está usando um DNS altamente disponível para gerenciar os nomes de domínio dos endpoints da aplicação.
+ Se os usuários acessam seu aplicativo pela Internet, use as operações de API de serviço para confirmar o uso correto dos gateways da Internet. Confirme também se as entradas das tabelas de rotas para as sub-redes que hospedam os endpoints do seu aplicativo estão corretas.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Verifique se você está usando um proxy reverso ou um balanceador de carga altamente disponível na frente da aplicação.
+ Se os usuários acessam a aplicação por meio do ambiente on-premises, verifique se a conectividade entre a AWS e o ambiente é altamente disponível.
+ Use o Route 53 para gerenciar os nomes de domínio.
+ [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Use um provedor DNS de terceiros que atenda aos seus requisitos.
+ Use o Elastic Load Balancing.
+ [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Use um dispositivo do AWS Marketplace que atenda aos seus requisitos.
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recomendações de resiliência do AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Usar o Toolkit de resiliência do Direct Connect para começar](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC endpoints e serviços de VPC endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Trabalho com gateways Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 Provisionar conectividade redundante entre as redes privadas na nuvem e nos ambientes on-premises
Use várias conexões do AWS Direct Connect ou túneis VPN entre as redes privadas implantadas separadamente. Use vários locais do Direct Connect para alta disponibilidade. Se estiver usando várias Regiões da AWS, garanta a redundância em pelo menos duas delas. Você pode avaliar os appliances do AWS Marketplace que encerram as VPNs. Se você usa appliances do AWS Marketplace, implante instâncias redundantes em zonas de disponibilidade diferentes para alta disponibilidade.
O AWS Direct Connect é um serviço de nuvem que facilita a criação de uma conexão de rede dedicada entre seu ambiente on-premises e a AWS. Usando o Direct Connect Gateway, seu datacenter on-premises pode ser conectado a várias VPCs da AWS distribuídas em várias Regiões da AWS.
Essa redundância resolve possíveis falhas que afetam a resiliência da conectividade:
+ Como você será resiliente a falhas em sua topologia?
+ O que acontecerá se você configurar algo incorretamente e remover a conectividade?
+ Você será capaz de lidar com um aumento inesperado no tráfego ou uso de seus serviços?
+ Você conseguirá absorver uma tentativa de ataque de Negação de serviço distribuída (DDoS)?
Ao conectar sua VPC ao seu datacenter on-premises por meio de uma VPN, considere a resiliência e a largura de banda necessárias ao selecionar o fornecedor e o tamanho da instância em que precisa executar o dispositivo. Se você usar um dispositivo de VPN que não seja resiliente nesta implementação, precisará ter uma conexão redundante por meio de um segundo dispositivo. Para todos esses cenários, é preciso definir um tempo aceitável para recuperação e testar para garantir que você consiga cumprir esses requisitos.
Se você optar por conectar a VPC ao datacenter usando uma conexão Direct Connect e precisar que essa conexão seja altamente disponível, tenha conexões Direct Connect redundantes provenientes de cada datacenter. A conexão redundante deve usar uma segunda conexão Direct Connect de um local diferente do primeiro. Se você tiver vários datacenters, garanta que as conexões terminem em diferentes locais. Use a ferramenta de recomendações do [Toolkit de resiliência do Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) para ajudar a configurar isso.
Se você escolher fazer failover para a VPN pela Internet usando a Site-to-Site VPN, saiba que ela é compatível com um throughput de até 1,25 Gbps por túnel VPN, mas não é compatível com Múltiplos caminhos de mesmo custo (ECMP) para tráfego de saída no caso de vários túneis da AWS Managed VPN terminarem no mesmo VGW. Não recomendamos que você use o AWS Managed VPN como backup para conexões Direct Connect, a menos que possa tolerar velocidades inferiores a 1 Gbps durante o failover.
Você também pode usar endpoints da VPC para conectar sua VPC a serviços compatíveis da AWS e do endpoint da VPC alimentado pelo AWS PrivateLink sem passar pela Internet pública. Os endpoints são dispositivos virtuais. Eles são componentes de VPC altamente disponíveis, redundantes e escalados horizontalmente. Eles permitem a comunicação entre instâncias em sua VPC e serviços sem impor riscos de disponibilidade ou restrições de largura de banda ao tráfego de rede.
**Antipadrões comuns:**
+ Ter apenas um provedor de conectividade entre a rede local e a AWS.
+ Consumir os recursos de conectividade da conexão do AWS Direct Connect, mas ter apenas uma conexão.
+ Ter apenas um caminho para conectividade VPN.
**Benefícios do estabelecimento dessa prática recomendada:** Ao implementar conectividade redundante entre seu ambiente de nuvem e o ambiente corporativo ou on-premises, você pode garantir que os serviços dependentes entre os dois ambientes possam se comunicar de forma confiável.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Verifique se você tem conectividade altamente disponível entre a AWS e o ambiente on-premises. Use várias conexões do AWS Direct Connect ou túneis VPN entre as redes privadas implantadas separadamente. Use vários locais do Direct Connect para alta disponibilidade. Se estiver usando várias Regiões da AWS, garanta a redundância em pelo menos duas delas. Você pode avaliar os appliances do AWS Marketplace que encerram as VPNs. Se você usa appliances do AWS Marketplace, implante instâncias redundantes em zonas de disponibilidade diferentes para alta disponibilidade.
+ Verifique se você tem uma conexão redundante com seu ambiente on-premises. Você pode precisar de conexões redundantes para várias Regiões da AWS para atender às necessidades de disponibilidade.
+ [Recomendações de resiliência do AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Uso de conexões Site-to-Site VPN redundantes para fornecer failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ Use as operações de API de serviço para identificar o uso correto dos circuitos do Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Se houver apenas uma conexão Direct Connect ou se você não tiver nenhuma, configure túneis VPN redundantes para seus gateways privados virtuais.
+ [O que é a AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ Capture a conectividade atual (por exemplo, Direct Connect, gateways privados virtuais, dispositivos do AWS Marketplace).
+ Use as operações de API de serviço para consultar a configuração das conexões Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Use as operações de API de serviço para coletar gateways privados virtuais onde as tabelas de rotas os usam.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Use as operações de API de serviço para coletar aplicações do AWS Marketplace onde as tabelas de rotas as utilizam.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recomendações de resiliência do AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Uso de conexões Site-to-Site VPN redundantes para fornecer failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Usar o Toolkit de resiliência do Direct Connect para começar](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC endpoints e serviços de VPC endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [O que é a AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Trabalho com gateways Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade
Intervalos de endereços IP da Amazon VPC devem ser grandes o suficiente para acomodar os requisitos da workload, incluindo a futura expansão e alocação de endereços IP para sub-redes nas zonas de disponibilidade. Isso inclui load balancers, instâncias do EC2 e aplicativos baseados em contêiner.
Ao planejar sua topologia de rede, a primeira etapa é definir o espaço do endereço IP em si. Intervalos de endereços IP privados (seguindo as diretrizes RFC 1918) devem ser alocados para cada VPC. Atenda aos seguintes requisitos como parte desse processo:
+ Permitir espaço de endereço IP para mais de uma VPC por região.
+ Dentro de uma VPC, deixe espaço para várias sub-redes que abrangem várias zonas de disponibilidade.
+ Sempre deixe o espaço de bloco CIDR não utilizado em uma VPC para futura expansão.
+ Verifique se há espaço de endereço IP para atender às necessidades de qualquer frota transitória de instâncias do EC2 que você use, como frotas spot para machine learning, clusters do Amazon EMR ou clusters do Amazon Redshift.
+ Observe que os primeiros quatro endereços IP e o último endereço IP em cada bloco CIDR da sub-rede estão reservados e não estão disponíveis para seu uso.
+ Você deve planejar implantar grandes blocos CIDR de VPC. Observe que o bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar blocos CIDR não sobrepostos à VPC. Os CIDRs IPv4 da sub-rede não podem ser alterados, mas os CIDRs IPv6 podem. Lembre-se de que implantar a maior VPC possível (/16) resulta em mais de 65 mil endereços IP. Somente no espaço de endereço IP 10.x.x.x, você pode provisionar 255 dessas VPCs. Portanto, você deve errar por ser muito grande em vez de muito pequeno para facilitar o gerenciamento de suas VPCs.
**Antipadrões comuns:**
+ Criar VPCs pequenas.
+ Criar sub-redes pequenas e ter de adicionar sub-redes às configurações à medida que você cresce.
+ Estimar incorretamente quantos endereços IP um Elastic Load Balancer pode usar.
+ Implantar muitos load balancers de alto tráfego nas mesmas sub-redes.
**Benefícios do estabelecimento dessa prática recomendada:** Isso garante que você possa acomodar o crescimento das suas cargas de trabalho e continuar a fornecer disponibilidade à medida que elas se expandem.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Planeje sua rede para acomodar crescimento, conformidade regulamentar e integração com outras pessoas. O crescimento pode ser subestimado, a conformidade regulamentar pode mudar e as aquisições ou conexões de rede privada podem ser difíceis de implementar sem o planejamento adequado.
+ Selecione as Contas da AWS e regiões relevantes conforme seus requisitos de serviço, de latência, regulatórios e de recuperação de desastres (DR).
+ Identifique suas necessidades para implantações regionais de VPC.
+ Identifique o tamanho das VPCs.
+ Determine se você pretende implantar conectividade com várias VPCs.
+ [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Conectividade com várias VPCs de região única](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Determine se você precisa de rede segregada por requisitos regulamentares.
+ Faça VPCs o maior possível. O bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar outros blocos CIDR não sobrepostos à VPC. No entanto, isso pode fragmentar seus intervalos de endereços.
+ Faça VPCs o maior possível. O bloco CIDR inicial da VPC alocado para sua VPC não pode ser alterado ou excluído, mas você pode adicionar outros blocos CIDR não sobrepostos à VPC. No entanto, isso pode fragmentar seus intervalos de endereços.
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Conectividade com várias VPCs de região única](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 Preferir topologias hub-and-spoke em vez da malha muitos para muitos
Se mais de dois espaços de endereço de rede (por exemplo, VPCs e redes on-premises) estiverem conectados por meio do emparelhamento de VPC, do AWS Direct Connect ou da VPN, use um modelo hub-and-spoke, como o fornecido pelo AWS Transit Gateway.
Se você tiver apenas duas redes desse tipo, basta conectá-las uma à outra, mas à medida que o número de redes cresce, a complexidade dessas conexões de malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, permitindo o roteamento de tráfego em várias redes.
![\[Diagrama mostrando o não uso do AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[Diagrama mostrando o uso do AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**Antipadrões comuns:**
+ Usar o emparelhamento de VPC para conectar mais de duas VPCs.
+ Estabelecer várias sessões de BGP a cada VPC para fornecer conectividade que abrange as nuvens privadas virtuais (VPCs) distribuídas em diversas Regiões da AWS.
**Benefícios do estabelecimento dessa prática recomendada:** À medida que o número de redes cresce, a complexidade dessas conexões em malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, que permite o roteamento do tráfego entre várias redes.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Prefira topologias hub-and-spoke em vez da malha muitos para muitos. Se mais de dois espaços de endereço de rede (por exemplo, VPCs e redes on-premises) estiverem conectados por meio do emparelhamento de VPC, do AWS Direct Connect ou da VPN, use um modelo hub-and-spoke, como o fornecido pelo AWS Transit Gateway.
+ Para apenas duas redes desse tipo, você pode simplesmente conectá-las uma à outra. No entanto, à medida que o número de redes cresce, a complexidade dessas conexões em malha torna-se insustentável. O AWS Transit Gateway oferece um modelo hub-and-spoke fácil de manter, que permite o roteamento do tráfego entre várias redes.
+ [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [VPC endpoints e serviços de VPC endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [O que é um Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 Aplicar intervalos de endereços IP privados não sobrepostos a todos os espaços de endereços privados onde estão conectados
Os intervalos de endereços IP de cada uma das suas VPCs não devem se sobrepor quando emparelhados ou conectados por VPN. Você deve evitar conflitos de endereço IP da mesma forma entre uma VPC e ambientes no local ou com outros provedores de nuvem que você usa. Você também deve ter uma maneira de alocar intervalos de endereços IP privados quando necessário.
Um sistema de gerenciamento de endereços IP (IPAM) pode ajudar com isso. Vários IPAMs estão disponíveis no AWS Marketplace.
**Antipadrões comuns:**
+ Usar o mesmo intervalo de IPs na VPC que você tem no local ou na rede corporativa.
+ Não acompanhar os intervalos IPs das VPCs usadas para implantar suas cargas de trabalho.
**Benefícios do estabelecimento dessa prática recomendada:** O planejamento ativo da rede garantirá que você não tenha várias ocorrências do mesmo endereço IP nas redes interconectadas. Isso evita que problemas de roteamento ocorram em partes da carga de trabalho que usam os diferentes aplicativos.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Monitore e gerencie seu uso do CIDR. Avalie seu uso potencial na AWS, adicione intervalos de CIDR às VPCs existentes e crie VPCs para permitir um crescimento planejado no uso.
+ Capture o consumo atual do CIDR (por exemplo, VPCs, sub-redes etc.)
+ Use as operações de API de serviço para coletar o consumo atual do CIDR.
+ Capture o seu uso atual de sub-rede.
+ Use as operações de API de serviço para coletar sub-redes por VPC em cada região.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ Registre o uso atual.
+ Determine se você criou algum intervalos de IP sobrepostos.
+ Calcule a capacidade não utilizada.
+ Identifique intervalos de IP sobrepostos. Você pode migrar para um novo intervalo de endereços ou usar os dispositivos de tradução de rede e porta (NAT) do AWS Marketplace se precisar conectar os intervalos sobrepostos.
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar a planejar sua rede](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace para infraestrutura de rede](https://aws.amazon.com/marketplace/b/2649366011)
+ [Whitepaper sobre as opções de conectividade do Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [O que é o Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [O que é o IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# Arquitetura da carga de trabalho
**Topics**
+ [REL 3 Como você projeta sua arquitetura de serviços de carga de trabalho?](w2aac19b9b7b5.md)
+ [REL 4 Como você projeta interações em um sistema distribuído para evitar falhas?](w2aac19b9b7b7.md)
+ [REL 5 Como você projeta interações em um sistema distribuído para mitigar ou resistir a falhas?](w2aac19b9b7b9.md)
# REL 3 Como você projeta sua arquitetura de serviços de carga de trabalho?
Use uma Service-Oriented Architecture (SOA – Arquitetura orientada por serviços) ou uma arquitetura de microsserviços para criar cargas de trabalho altamente escaláveis e confiáveis. A SOA é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples.
**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Escolher como segmentar a workload
A segmentação de workloads é importante ao determinar os requisitos de resiliência de sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de serem implantadas como microsserviços.
**Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível.
Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para escalabilidade a partir das necessidades iniciais. Ao refatorar um monólito existente, você vai precisar considerar o quanto a aplicação vai oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada.
**Antipadrões comuns:**
+ O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito.
**Benefícios do estabelecimento desta prática:**
+ Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade.
+ Redução do impacto das interrupções do serviço.
+ Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte.
+ Responsabilidades bem definidas para as equipes que oferecem suporte à workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação de implementação
Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, você deve garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços.
Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência.
![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Etapas da implementação
+ Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se sua carga de trabalho aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais detalhes, consulte [Implementação de microsserviços na AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considere seguir o [*padrão* Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novas aplicações e serviços. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como um ponto de partida para refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas por serviços para fornecer descoberta confiável e acesso a serviços. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS.
+ Se você estiver migrando de um monólito para SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) pode ajudar a eliminar a lacuna como um barramento de serviço ao reprojetar aplicações herdadas na nuvem.
+ Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [De SQL para NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nível de esforço do plano de implementação:** Alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [O que é o AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemplos relacionados:**
+ [Workshop de modernização iterativa de aplicações](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Delivering Excellence with Microservices on AWS (Entregando excelência com microsserviços na AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos
A arquitetura orientada por serviços (SOA) cria serviços com funções bem delineadas que seguem as necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto controlado para maior limitação de modo que cada serviço execute apenas uma ação. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
Ao projetar uma arquitetura de microsserviços, é útil usar o Design orientado por domínio (DDD) para modelar o problema de negócios usando entidades. Por exemplo, para o site Amazon.com, entidades podem incluir pacote, entrega, programação, preço, desconto e moeda. Em seguida, o modelo é dividido em modelos menores usando o [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), onde entidades que compartilham recursos e atributos semelhantes são agrupadas. Portanto, usar o pacote, a entrega e a programação de exemplo da Amazon.com seria parte do contexto de envio, enquanto preço, desconto e moeda fazem parte do contexto de definição de preço. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços.
![\[Modelo de como limitar microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Projete a workload de acordo com os domínios de negócios e as respectivas funcionalidades. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
+ Execute a análise de domínio para mapear um Domain-Driven Design (DDD – Projeto orientado por domínio) para sua carga de trabalho. Em seguida, você pode escolher um tipo de arquitetura para atender às necessidades da sua workload.
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Decomponha os serviços nos menores componentes possíveis. Com a arquitetura de microsserviços, você pode separar sua carga de trabalho em componentes com a funcionalidade mínima para permitir escalabilidade e agilidade organizacionais.
+ Defina a API para a carga de trabalho e os respectivos objetivos, limites e outras considerações de uso do projeto.
+ Defina a API.
+ A definição da API deve permitir o crescimento e parâmetros adicionais.
+ Defina as disponibilidades projetadas.
+ Sua API pode ter vários objetivos de projeto para recursos diferentes.
+ Estabeleça limites
+ Use o teste para definir os limites de seus recursos de carga de trabalho.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornecer contratos de serviço por API
Os contratos de serviço são acordos documentados entre as equipes que envolvem a integração dos serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance. Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem suas aplicações para a API mais recente quando estiverem prontas. A implantação pode acontecer a qualquer momento, desde que o contrato não seja violado. A equipe do provedor de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API. Da mesma forma, o consumidor do serviço pode usar sua própria tecnologia.
Os microsserviços levam o conceito de arquitetura orientada a serviços (SOA) ao ponto de criar serviços com um conjunto mínimo de funcionalidades. Cada serviço publica uma API e projeta metas, limites e outras considerações para ele ser utilizado. Isso estabelece um *contrato* com chamadas a aplicações. Assim, três benefícios principais são alcançados:
+ O serviço tem um problema de negócios conciso a ser resolvido e uma equipe pequena responsável por ele. Isso possibilita melhor escalabilidade organizacional.
+ A equipe pode implantar a qualquer momento, desde que atenda aos requisitos de API e a outros requisitos do contrato.
+ A equipe pode usar qualquer pilha de tecnologia desejada, desde que atenda os requisitos de API e outros requisitos do contrato.
O Amazon API Gateway é um serviço totalmente gerenciado que permite aos desenvolvedores criar, publicar, manter, monitorar e proteger APIs em qualquer escala com facilidade. Ele administra todas as tarefas envolvidas no recebimento e processamento de até centenas de milhares de chamadas de API simultâneas, inclusive gerenciamento de tráfego, controle de autorização e acesso, monitoramento, e gerenciamento de versões de API. Usando o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo
## Orientações para a implementação
+ Forneça contratos de serviço por API. Contratos de serviço são contratos documentados entre equipes na integração de serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance.
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem seus aplicativos para a API mais recente quando estiverem prontos.
+ O Amazon API Gateway é um serviço totalmente gerenciado que facilita a criação de APIs em qualquer escala para os desenvolvedores. Ao usar o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
# REL 4 Como você projeta interações em um sistema distribuído para evitar falhas?
Os sistemas distribuídos dependem das redes de comunicação para interconectar componentes, como servidores ou serviços. Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a carga de trabalho. Essas melhores práticas evitam falhas e melhoram o Mean Time Between Failures (MTBF – Tempo médio entre falhas).
**Topics**
+ [REL04-BP01 Identificar qual tipo de sistema distribuído é necessário](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Fazer com que todas as respostas sejam idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar qual tipo de sistema distribuído é necessário
Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas, enquanto os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais. Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono. Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos.
Os [desafios mais difíceis com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) são para sistemas complexos distribuídos em tempo real, também conhecidos como serviços de solicitação/resposta. O que as dificulta é que as solicitações chegam de forma imprevisível e as respostas devem ser fornecidas rapidamente (por exemplo, o cliente está aguardando ativamente a resposta). Os exemplos incluem servidores Web front-end, pipeline de pedidos, transações de cartão de crédito, todas as APIs da AWS e telefonia.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Identifique qual tipo de sistema distribuído é necessário. Os desafios dos sistemas distribuídos envolviam latência, escalabilidade, conhecimento das APIs de rede, marshalling e unmarshalling de dados e complexidade de algoritmos, como Paxos. À medida que os sistemas crescem e se tornam mais distribuídos, o que antes eram casos de borda hipotéticos se tornam ocorrências regulares.
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas.
+ Os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais.
+ Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono.
+ Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementar dependências com acoplamento fraco
As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
Se as alterações em um componente forçarem outros componentes que dependem dele a serem também alterados, eles serão *fortemente* acoplados. *O baixo* acoplamento interrompe essa dependência para que os componentes dependentes só precisem saber a interface versionada e publicada. A implementação de um baixo acoplamento entre dependências isola uma falha em uma dependência para não afetar a outra.
O baixo acoplamento permite adicionar mais código ou recursos a um componente enquanto minimiza o risco para componentes que dependem dele. Além disso, a escalabilidade é melhorada pois você pode aumentar a escala verticalmente ou até mesmo alterar a implementação básica da dependência.
Para melhorar ainda mais a resiliência por meio do baixo acoplamento, torne as interações de componentes assíncronas sempre que possível. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e em que uma confirmação de que uma solicitação foi registrada será suficiente. Envolve um componente que gera eventos e outro que os consome. Os dois componentes não se integram por meio de interação direta ponto a ponto, mas geralmente por meio de uma camada de armazenamento durável intermediária, como uma fila do SQS ou uma plataforma de dados de streaming, como o Amazon Kinesis ou o AWS Step Functions.
![\[Diagrama mostrando dependências como sistemas de enfileiramento e balanceadores de carga de acoplamento fraco\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Filas do Amazon SQS e Elastic Load Balancers são apenas duas maneiras de adicionar uma camada intermediária para baixo acoplamento. Arquiteturas orientadas por eventos também podem ser criadas na Nuvem AWS usando o Amazon EventBridge, que pode abstrair clientes (produtores de eventos) dos serviços dos quais eles dependem (consumidores de eventos). O Amazon Simple Notification Service (Amazon SNS) é uma solução eficaz quando você precisa de mensagens de alto throughput, baseadas em push e de muitos para muitos. Usando tópicos do Amazon SNS, seus sistemas de editores podem enviar mensagens para um grande número de endpoints assinantes para processamento paralelo.
Embora as filas ofereçam várias vantagens, na maioria dos sistemas complexos em tempo real, as solicitações mais antigas do que um tempo limite (geralmente segundos) devem ser consideradas obsoletas (o cliente desistiu e não está mais esperando por uma resposta) e não processadas. Dessa forma, as solicitações mais recentes (e provavelmente ainda válidas) podem ser processadas.
**Antipadrões comuns:**
+ Implantar um singleton como parte de uma carga de trabalho.
+ Invocar diretamente as APIs entre níveis de carga de trabalho sem recurso de failover ou processamento assíncrono da solicitação.
**Benefícios do estabelecimento desta prática recomendada:** O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. A falha em um componente é isolada dos demais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Implemente dependências com acoplamento fraco. As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ O Amazon EventBridge permite criar arquiteturas orientadas por eventos, que são acopladas de maneira fraca e distribuídas.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Se as alterações em um componente forçarem outros componentes que dependem dele a serem também alterados, eles serão fortemente acoplados. O baixo acoplamento interrompe essa dependência para que os componentes dependentes precisem apenas reconhecer a interface versionada e publicada.
+ Sempre que possível, crie interações de componentes assíncronas. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e quando uma confirmação de que uma solicitação foi registrada é suficiente.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Recursos
**Documentos relacionados:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Fazer um trabalho constante
Os sistemas podem falhar quando há alterações grandes e rápidas na carga. Por exemplo, se a sua workload está realizando uma verificação de integridade que monitora a integridade de milhares de servidores, ela deve sempre enviar a carga útil com o mesmo tamanho (um snapshot completo do estado atual). Se houver uma falha em todos os servidores ou se não houver falha alguma, o sistema de verificação de integridade realizará um trabalho constante sem alterações grandes e rápidas.
Por exemplo, se o sistema de verificação de integridade estiver monitorando 100.000 servidores, a carga nele será nominal a uma taxa de falha do servidor normalmente leve. No entanto, se um evento importante deixar metade desses servidores com problemas de integridade, o sistema de verificação de integridade ficará sobrecarregado tentando atualizar os sistemas de notificação e comunicar o estado com seus clientes. Portanto, em vez disso, o sistema de verificação de integridade deve enviar o snapshot completo do estado atual a cada vez. Os estados da integridade de 100.000 servidores, cada um representado por um bit, seriam apenas uma carga útil de 12,5 KB. independentemente de nenhum servidor ou falhar, ou todos eles falharem, o sistema de verificação de integridade está realizando um trabalho constante, e alterações grandes e rápidas não são uma ameaça para a estabilidade do sistema. Na verdade, é assim que o Amazon Route 53 lida com as verificações de integridade de endpoints (como endereços IP) para determinar como os usuários finais são roteados para eles.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo
## Orientações para a implementação
+ Faça um trabalho constante para que os sistemas não falhem quando houver mudanças rápidas e grandes na carga.
+ Implemente dependências com acoplamento fraco. As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ Para o exemplo de um sistema de verificação de integridade que monitora 100 mil servidores, crie as workloads de modo que os tamanhos da carga útil permaneçam constantes, seja qual for o número de êxitos ou falhas.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Fazer com que todas as respostas sejam idempotentes
Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação. Um serviço idempotente facilita para um cliente implementar novas tentativas sem o receio de que uma solicitação seja processada erroneamente várias vezes. Para fazer isso, os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída.
Em um sistema distribuído, é fácil executar uma ação no máximo uma vez (o cliente faz apenas uma solicitação) ou pelo menos uma vez (continue solicitando até o cliente receber a confirmação do sucesso). Porém, é difícil garantir que uma ação seja idempotente, o que significa que ela é executada *exatamente* uma vez, de modo que fazer várias solicitações idênticas tenha o mesmo efeito de uma única solicitação. Usando tokens de idempotência em APIs, os serviços podem receber uma solicitação mutante uma vez ou mais sem a criação de registros duplicados nem efeitos colaterais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Faça com que todas as respostas sejam idempotentes. Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação.
+ Os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída.
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 Como você projeta interações em um sistema distribuído para mitigar ou resistir a falhas?
Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes (como servidores ou serviços). Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a carga de trabalho. Essas melhores práticas permitem que as cargas de trabalho resistam a tensões ou falhas, recuperem-se mais rapidamente delas e reduzam o impacto de tais prejuízos. Como resultado, o Mean Time To Recovery (MTTR – Tempo médio até a recuperação) é melhorado.
**Topics**
+ [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Controlar o fluxo de solicitações](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Criar serviços sem estado sempre que possível](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar medidas emergenciais](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis
Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
Considere um serviço B que é chamado pelo serviço A e, por sua vez, chama o serviço C.
![\[Diagrama mostrando que o serviço C falha quando chamado do serviço B. O serviço B retorna uma resposta degradada ao serviço A.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Quando o serviço B chama o serviço C, ele recebeu um erro ou tempo limite dele. O serviço B, sem uma resposta do serviço C (e os dados que ele contém), retorna o que pode. Esse pode ser o último bom valor armazenado em cache, ou o serviço B pode substituir uma resposta estática pré-determinada pelo que receberia do serviço C. Em seguida, ele pode retornar uma resposta degradada ao chamador, o serviço A. Sem essa resposta estática, a falha no serviço C seria feita em cascata por meio do serviço B para o serviço A, resultando em uma perda de disponibilidade.
De acordo com o fator multiplicativo na equação de disponibilidade para dependências rígidas (consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), qualquer queda na disponibilidade do C afeta gravemente a disponibilidade efetiva do B. Ao retornar a resposta estática, o serviço B atenua a falha em C e, embora degradada, faz com que a disponibilidade do serviço C pareça 100% (supondo que ela retorne de forma confiável a resposta estática sob condições de erro). Observe que a resposta estática é uma alternativa simples para retornar um erro e não é uma tentativa de recalcular a resposta usando meios diferentes. Essas tentativas em um mecanismo completamente diferente para tentar alcançar o mesmo resultado são chamadas de comportamento de fallback e são um antipadrão a ser evitado.
Outro exemplo de degradação tranquila é o *padrão de disjuntor*. Estratégias de repetição devem ser usadas quando a falha é transitória. Quando esse não for o caso, e a operação provavelmente falhar, o padrão do disjuntor impedirá que o cliente execute uma solicitação que provavelmente falhará. Quando as solicitações estão sendo processadas normalmente, o disjuntor está fechado e as solicitações passam. Quando o sistema remoto começa a retornar erros ou exibe alta latência, o disjuntor abre e a dependência é ignorada ou os resultados são substituídos por respostas mais simples, mas menos abrangentes (que podem ser simplesmente um cache de resposta). O sistema periodicamente tenta chamar a dependência para determinar se ela se recuperou. Quando isso acontece, o disjuntor é fechado.
![\[Diagrama mostrando o disjuntor em estados abertos e fechados.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Além dos estados fechado e aberto mostrados no diagrama, após um período configurável no estado aberto, o disjuntor pode fazer a transição para meio aberto. Nesse estado, ele tenta chamar o serviço periodicamente a uma taxa muito menor do que o normal. Esse teste é usado para verificar a integridade do serviço. Depois de vários êxitos no estado meio aberto, o disjuntor muda para fechado, e as solicitações normais são retomadas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Implemente uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis. Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
+ Ao retornar uma resposta estática, a workload atenua as falhas que ocorrem nas dependências dela.
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Detecte quando há probabilidade de falha na operação de repetição e impeça o cliente de fazer chamadas com falha com o padrão de disjuntor.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (resume “Circuit Breaker” do livro “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Controlar o fluxo de solicitações
O controle de utilização de solicitações é um padrão de atenuação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
Seus serviços devem ser projetados para processar uma capacidade conhecida de solicitações que cada nó ou célula pode processar. Esta capacidade pode ser estabelecida por meio de teste de carga. É preciso acompanhar a taxa de chegada das solicitações e, se ela ultrapassar esse limite, a resposta adequada será indicar que a solicitação foi limitada. Isso permite que o usuário tente outra vez, possivelmente para um nó ou célula diferente que talvez tenha capacidade disponível. O Amazon API Gateway fornece métodos para controle de solicitações. O Amazon SQS e o Amazon Kinesis podem armazenar solicitações em buffer, suavizar a taxa de solicitações e aliviar a necessidade de controle de utilização para solicitações que podem ser abordadas de forma assíncrona.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle o fluxo de solicitações. Esse é um padrão de mitigação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
+ Use o Amazon API Gateway
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controlar e limitar as chamadas de repetição
Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
Os componentes típicos em um sistema de software distribuído incluem servidores, load balancers, bancos de dados e servidores DNS. Em operação, e sujeito a falhas, qualquer um deles pode começar a gerar erros. A técnica padrão para lidar com erros é implementar novas tentativas no lado do cliente. Essa técnica aumenta a confiabilidade e a disponibilidade do aplicativo. No entanto, em grande escala (e se os clientes tentarem repetir a operação com falha assim que ocorrer um erro) a rede poderá ficar rapidamente saturada com solicitações novas e repetidas, cada uma competindo pela largura de banda da rede. Isso pode resultar em uma *tempestade de repetições,* o que reduzirá a disponibilidade do serviço. Esse padrão pode continuar até que ocorra uma falha completa do sistema.
Para evitar tais cenários, algoritmos de recuo, como o *recuo exponencial* comum, devem ser usados. Os algoritmos de recuo exponencial diminuem gradualmente a taxa na qual novas tentativas são realizadas, evitando assim congestionamentos de rede.
Muitos SDKs e bibliotecas de software, incluindo os da AWS, implementam uma versão desses algoritmos. No entanto, **nunca presuma que exista um algoritmo de recuo, sempre teste e verifique se esse é o caso.**
O recuo simples não é suficiente porque, em sistemas distribuídos, todos os clientes podem recuar simultaneamente, criando clusters de chamadas de repetição. Marc Brooker, em sua publicação de blog [, Recuo exponencial e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), explica como modificar a função wait() no recuo exponencial para impedir clusters de chamadas de repetição. A solução é adicionar *jitter* na função wait(). Para evitar tentar novamente por muito tempo, as implementações devem limitar o recuo a um valor máximo.
Por fim, é importante configurar um *número máximo de repetições* ou tempo decorrido, após o qual uma repetição simplesmente falhará. Os AWS SDKs implementam isso por padrão, o que pode ser configurado. Para serviços mais baixos na pilha, um limite máximo de repetição zero ou um pode limitar o risco, mas ainda ser eficaz à medida que novas tentativas forem delegadas a serviços mais altos na pilha.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle e limite as chamadas de repetição. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Os SDKs da Amazon implementam repetições e recuo exponencial por padrão. Implemente uma lógica semelhante em sua camada de dependência ao chamar seus próprios serviços dependentes. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Antecipar-se à falha e filas limitadas
Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
Essa melhor prática se aplica ao lado do servidor, ou receptor, da solicitação.
Esteja ciente de que as filas podem ser criadas em vários níveis de um sistema e podem impedir seriamente a capacidade de recuperação rápida à medida que solicitações antigas obsoletas (que não precisam mais de uma resposta) são processadas antes de solicitações mais recentes. Esteja ciente dos locais onde as filas existem. Elas geralmente se ocultam em fluxos de trabalho ou em trabalhos registrados em um banco de dados.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Antecipe-se à falha e limite filas. Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
+ Implemente antecipação à falha quando o serviço estiver sob pressão.
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Filas limitadas. Em um sistema baseado em fila, quando o processamento é interrompido, mas as mensagens continuam chegando, o débito de mensagens pode se acumular em uma lista grande de pendências, aumentando o tempo de processamento. Os resultados podem deixar de ser úteis por conta da demora na conclusão do trabalho, o que afeta principalmente a disponibilidade que o enfileiramento tinha que proteger.
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Recursos
**Documentos relacionados:**
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Definir tempos limite do cliente
Defina tempos limite adequados, verifique-os sistematicamente e não dependa de valores padrão, já que eles costumam ser muito altos.
Essa melhor prática se aplica ao lado do cliente, ou remetente, da solicitação.
Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
Para saber mais sobre como a Amazon usa tempos limite, repetições e recuo com tremulação, consulte a [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Recursos
**Documentos relacionados:**
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Criar serviços sem estado sempre que possível
Os serviços não devem exigir estado ou devem descarregar o estado de modo que não haja dependência entre solicitações de clientes diferentes em relação aos dados armazenados localmente no disco ou na memória. Isso permite que os servidores sejam substituídos quando necessário sem causar impacto na disponibilidade. O Amazon ElastiCache ou o Amazon DynamoDB são bons destinos para o estado descarregado.
![\[Nesta aplicação Web sem estado, o estado da sessão é descarregado para o Amazon ElastiCache.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Quando os usuários ou serviços interagem com um aplicativo, eles geralmente executam uma série de interações que formam uma sessão. Uma sessão são dados exclusivos para usuários que persistem entre solicitações enquanto usam o aplicativo. Um aplicativo sem estado é um aplicativo que não precisa de conhecimento de interações anteriores e não armazena informações da sessão.
Depois de projetados para serem sem estado, você pode usar serviços de computação com tecnologia sem servidor, como o AWS Lambda ou o AWS Fargate.
Além da substituição do servidor, outro benefício dos aplicativos sem estado é que eles podem escalar horizontalmente, pois qualquer um dos recursos de computação disponíveis (como instâncias do EC2 e funções do AWS Lambda) pode atender a qualquer solicitação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Crie aplicações sem estado. Os aplicativos sem estado permitem a escalabilidade horizontal e são tolerantes a falhas de um nó individual.
+ Remova o estado que realmente pode ser armazenado nos parâmetros de solicitação.
+ Depois de examinar se o estado é necessário, mova qualquer rastreamento de estado para um armazenamento em cache resiliente multizona ou armazenamento de dados, como o Amazon ElastiCache, o Amazon RDS, Amazon DynamoDB ou uma solução de dados distribuídos de terceiros. Armazene os estados que não puderam ser movidos para armazenamentos de dados resilientes.
+ Alguns dados (como cookies) podem ser inseridos em cabeçalhos ou parâmetros de consulta.
+ Faça a refatoração para remover o estado que pode ser inserido rapidamente nas solicitações.
+ Alguns dados talvez não sejam realmente necessários por solicitação e podem ser recuperados sob demanda.
+ Remova os dados que podem ser recuperados de forma assíncrona.
+ Escolha um armazenamento de dados que atenda aos requisitos de um estado necessário.
+ Considere um banco de dados NoSQL para dados não relacionais.
## Recursos
**Documentos relacionados:**
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementar medidas emergenciais
Medidas emergenciais são processos rápidos que podem atenuar o impacto da disponibilidade na workload.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Implemente medidas emergenciais. Trata-se de processos rápidos que podem atenuar o impacto da disponibilidade sobre a carga de trabalho. Eles podem ser operados na ausência de uma causa raiz. Uma medida emergencial ideal reduz a carga cognitiva dos resolvedores a zero ao fornecer critérios de ativação e de desativação totalmente determinísticos. Geralmente, as medidas são manuais, mas também podem ser automatizadas
+ Exemplos de medidas incluem
+ Bloquear todo tráfego de robô
+ Servir páginas estáticas em vez de dinâmicas
+ Reduzir a frequência de chamadas a uma dependência
+ Limitar as chamadas de dependências
+ Dicas para implementar e usar medidas emergenciais
+ Quando as medidas forem ativadas, faça MENOS, e não mais
+ Simplifique, evite comportamento bimodal
+ Teste suas medidas periodicamente
+ Veja a seguir exemplos de ações que NÃO são medidas emergenciais
+ Adicionar capacidade
+ Chamar proprietários de serviços de clientes que dependem do seu serviço e solicitar que eles reduzam as chamadas
+ Fazer uma alteração no código e lançá-lo
# Gerenciamento de alterações
**Topics**
+ [REL 6 Como você monitora recursos de carga de trabalho?](w2aac19b9b9b5.md)
+ [REL 7 Como você projeta sua carga de trabalho para se adaptar às mudanças na demanda?](w2aac19b9b9b7.md)
+ [REL 8 Como você implementa uma alteração?](w2aac19b9b9b9.md)
# REL 6 Como você monitora recursos de carga de trabalho?
Os logs e as métricas são uma ferramenta poderosa para saber a integridade das suas cargas de trabalho. Você pode configurar sua carga de trabalho para monitorar logs e métricas e enviar notificações quando os limites forem ultrapassados ou em caso de eventos importantes. O monitoramento permite que sua carga de trabalho reconheça quando os limites de baixa performance são ultrapassados ou quando há falhas, para que ela possa se recuperar automaticamente em resposta.
**Topics**
+ [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Enviar notificações (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatizar respostas (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Análises](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Realizar revisões regularmente](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio do seu sistema](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Monitorar todos os componentes da workload (geração)
monitore os componentes da carga de trabalho com o Amazon CloudWatch ou ferramentas de terceiros. Monitore os serviços da AWS com o painel do AWS Health.
Todos os componentes da carga de trabalho devem ser monitorados, incluindo front-end, lógica de negócios e níveis de armazenamento. Defina as principais métricas, descreva como extraí-las dos logs (se necessário) e defina limites de ativação para eventos de alarme correspondentes. Certifique-se de que as métricas sejam relevantes para os indicadores-chave de performance (KPIs) da workload e use métricas e logs para identificar os primeiros sinais de alerta de degradação do serviço. Por exemplo, uma métrica relacionada a resultados de negócios, como o número de pedidos processados com êxito por minuto, pode indicar problemas de workload mais rapidamente do que uma métrica técnica, como a utilização da CPU. Use o painel do AWS Health para uma visualização personalizada da performance e da disponibilidade dos serviços da AWS subjacentes aos recursos da AWS.
O monitoramento na nuvem oferece novas oportunidades. A maioria dos provedores de nuvem desenvolveu ganchos personalizáveis e pode entregar insights para ajudar você a monitorar várias camadas da workload. Serviços da AWS, como o Amazon CloudWatch, aplicam algoritmos estatísticos e de machine learning para analisar continuamente métricas de sistemas e de aplicações, determinam linhas de base normais e detectam anomalias com intervenção mínima do usuário. Os algoritmos de detecção de anomalias consideram a sazonalidade e as mudanças de tendência das métricas.
A AWS disponibiliza uma abundância de informações de monitoramento e de log para consumo, que podem ser usadas para definir métricas específicas de workload, processos de alteração sob demanda e adotar técnicas de machine learning, independentemente da experiência em ML.
Além disso, monitore todos os seus endpoints externos para garantir que eles sejam independentes de sua implementação de base. Este monitoramento ativo pode ser feito com transações sintéticas (às vezes chamadas de *canários de usuário*, mas que não devem ser confundido com implantações canário) que executam periodicamente um número de tarefas comuns que correspondem às ações realizadas pelos clientes da workload. Mantenha estas tarefas de curta duração e certifique-se de não sobrecarregar a workload durante o teste. O Amazon CloudWatch Synthetics permite [criar canários sintéticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para monitorar seus endpoints e APIs. Você também pode combinar os nós sintéticos do cliente canário com o console do AWS X-Ray para identificar quais canários sintéticos estão enfrentando problemas com erros, falhas ou taxas de controle de utilização para o período selecionado.
**Resultado desejado:**
Coletar e usar métricas críticas de todos os componentes da workload para garantir sua confiabilidade e a experiência ideal do usuário. Detectar que uma workload não está alcançando resultados de negócios permite que você declare rapidamente um desastre e se recupere de um incidente.
**Antipadrões comuns:**
+ Monitorar apenas as interfaces externas com sua carga de trabalho.
+ Não gerar métricas específicas de workload e confiar apenas nas métricas fornecidas pelos serviços da AWS usados pela sua workload.
+ Usar apenas métricas técnicas na workload e não monitorar nenhuma métrica relacionada a KPIs não técnicos para os quais a workload contribui.
+ Depender do tráfego de produção e de verificações de integridade simples para monitorar e avaliar o estado da workload.
**Benefícios do estabelecimento dessa prática recomendada:** O monitoramento em todos os níveis da workload permite prever e resolver problemas mais rapidamente nos componentes que a compõem.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
1. **Habilite o registro em log quando disponível.** Os dados de monitoramento devem ser obtidos de todos os componentes das workloads. Ative o registro em log adicional, como os logs de acesso do S3, e habilite sua workload para registrar dados específicos da workload. Colete métricas para médias de CPU, E/S de rede e E/S de disco de serviços como o Amazon ECS, o Amazon EKS, o Amazon EC2, o Elastic Load Balancing, o AWS Auto Scaling e o Amazon EMR. Perceber [Serviços da AWS que publicam métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) para uma lista dos serviços da AWS que publicam métricas do CloudWatch.
1. **Revise todas as métricas padrão e explore quaisquer lacunas na coleta de dados.** Cada serviço gera métricas padrão. A coleta de métricas padrão permite que você entenda melhor as dependências entre os componentes da workload e como a confiabilidade e a performance destes componentes a afetam. Você também pode criar e [publicar suas próprias métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para CloudWatch usando o AWS CLI ou uma API. Isso
1. **Avalie todas as métricas para decidir quais alertar para cada serviço da AWS na sua workload.** Você pode escolher selecionar um subconjunto de métricas que tenha um grande impacto na confiabilidade da workload. Focar em métricas e limites críticos permite refinar o número de alertas [de emergência](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) e pode ajudar a minimizar falso-positivos.
1. **Defina alertas e o processo de recuperação para a workload depois que o alerta for acionado.** A definição de alertas permite que você notifique, escalone e siga rapidamente as etapas necessárias para se recuperar de um incidente e atender ao seu objetivo de tempo de recuperação (RTO) prescrito. Você pode usar o [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) para invocar fluxos de trabalho automatizados e iniciar procedimentos de recuperação com base em limites definidos.
1. **Explore o uso de transações sintéticas para coletar dados relevantes sobre o estado das workloads.** O monitoramento sintético segue as mesmas rotas e realiza as mesmas ações que um cliente, possibilitado que você verifique continuamente a experiência do cliente, mesmo quando não há tráfego de clientes nas workloads. Ao usar [transações sintéticas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), você pode descobrir problemas antes que seus clientes o façam.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
**Documentos relacionados:**
+ [Conceitos básicos do painel do AWS Health: integridade da sua conta](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [Serviços da AWS que publicam métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Logs de acesso para o Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Logs de acesso para seu application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Acessar o Amazon CloudWatch Logs para o AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Registro em log de acesso ao servidor do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Habilite logs de acesso para o Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exportação de dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Instalação do agente do CloudWatch em uma instância do Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Guias do usuário:**
+ [Criação de uma trilha](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Monitoramento de métricas de memória e de disco para instâncias do Linux do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Uso do CloudWatch Logs com instâncias de contêiner](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Logs de fluxo da VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [O que é o Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Blogs relacionados:**
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Exemplos e workshops relacionados:**
+ [Laboratórios do AWS Well-Architected: excelência operacional: monitoramento de dependência](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Workshop de observabilidade](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Definir e calcular as métricas (agregação)
Armazene os dados de log e aplique filtros quando necessário para calcular métricas, como contagens de um evento de log específico ou latência calculada com base na data e hora dos eventos de log.
O Amazon CloudWatch e o Amazon S3 funcionam como camadas primárias de agregação e armazenamento. Para alguns serviços, como o AWS Auto Scaling e o Elastic Load Balancing, métricas padrão são fornecidas para carga de CPU ou latência média de solicitação em um cluster ou uma instância. Para serviços de streaming, como o VPC Flow Logs e o AWS CloudTrail, dados de evento são encaminhados ao CloudWatch Logs, e você precisa definir e aplicar filtros de métricas para extraí-las dos dados do evento. Isso fornece dados de séries temporais, que podem servir como entradas para alarmes do CloudWatch que você define para acionar alertas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Defina e calcule as métricas (agregação). Armazene os dados de log e aplique filtros quando necessário para calcular métricas como contagens de um evento de log específico ou latência calculada com base na data e hora dos eventos de log
+ Os filtros de métrica definem os termos e os padrões a serem procurados nos dados de log à medida que são enviados para o CloudWatch Logs. O CloudWatch Logs usa esses filtros para transformar dados de log em métricas numéricas do CloudWatch, que você pode representar graficamente ou para as quais pode definir um alarme.
+ [Pesquisa e filtragem de dados de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ Use um terceiro confiável para agregar logs.
+ Siga as instruções do terceiro. A maioria dos produtos de terceiros integra-se ao CloudWatch e ao Amazon S3.
+ Alguns serviços da AWS podem publicar logs diretamente no Amazon S3. Se seu principal requisito de logs for o armazenamento no Amazon S3, você poderá facilmente fazer com que o serviço que produz os logs os envie diretamente ao Amazon S3 sem configurar uma infraestrutura adicional.
+ [Envie logs diretamente ao Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## Recursos
**Documentos relacionados:**
+ [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [Pesquisa e filtragem de dados de log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Envie logs diretamente ao Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 Enviar notificações (processamento e emissão de alarmes em tempo real)
As organizações que precisam estar a par de tudo, recebem notificações quando ocorrem eventos importantes.
Os alertas também podem ser enviados para tópicos do Amazon Simple Notification Service (Amazon SNS) e, em seguida, publicados para qualquer número de assinantes. Por exemplo, o Amazon SNS pode encaminhar alertas a um alias de e-mail para que a equipe técnica possa responder.
**Antipadrões comuns:**
+ Configurar alarmes com um limite muito baixo, fazendo com que muitas notificações sejam enviadas.
+ Não arquivar alarmes para exploração futura.
**Benefícios do estabelecimento dessa prática recomendada:** As notificações sobre eventos (mesmo aqueles que podem ser respondidos e resolvidos automaticamente) permitem que você tenha um registro dos eventos e, possivelmente, resolva-os de maneira diferente no futuro.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Realize o processamento e a emissão de alarmes em tempo real. As organizações que precisam estar a par de tudo, recebem notificações quando ocorrem eventos importantes
+ Os painéis do Amazon CloudWatch são páginas iniciais personalizáveis no console do CloudWatch, que você pode usar para monitorar os recursos em uma única visualização, mesmo aqueles distribuídos por regiões diferentes.
+ [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Crie um alarme quando a métrica ultrapassar um limite.
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Uso de métricas do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 Automatizar respostas (processamento e emissão de alarmes em tempo real)
use a automação para executar uma ação quando um evento é detectado, por exemplo, para substituir componentes com falha.
Alertas podem acionar eventos do AWS Auto Scaling, para que os clusters possam reagir a alterações na demanda. Os alertas podem ser enviados ao Amazon Simple Queue Service (Amazon SQS), que pode servir como um ponto de integração para sistemas de tíquetes de terceiros. O AWS Lambda também pode assinar alertas, fornecendo aos usuários um modelo de tecnologia sem servidor assíncrono que reage a alterações dinamicamente. O AWS Config monitora e registra continuamente as configurações de recursos da AWS e pode acionar o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para corrigir problemas.
O Amazon DevOps Guru pode monitorar automaticamente recursos de aplicações em busca de comportamento anômalo e entregar recomendações direcionadas para acelerar os tempos de identificação e correção de problemas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Use o Amazon DevOps Guru para realizar ações automatizadas. O Amazon DevOps Guru pode monitorar automaticamente recursos de aplicações em busca de comportamento anômalo e entregar recomendações direcionadas para acelerar os tempos de identificação e correção de problemas.
+ [O que é o Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ Use o AWS Systems Manager para realizar ações automatizadas. O AWS Config monitora e registra continuamente as configurações de recursos da AWS e pode acionar o AWS Systems Manager Automation para corrigir problemas.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Crie e use documentos do Systems Manager Automation. Eles definem as ações que o Systems Manager realiza nas suas instâncias gerenciadas e em outros recursos da AWS quando ocorre um processo de automação.
+ [Trabalhar com documentos de automação (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ O Amazon CloudWatch envia eventos de mudança de estado de alarme para o Amazon EventBridge. Crie regras do EventBridge para automatizar respostas.
+ [Criar uma regra do EventBridge que seja acionada em um evento de um recurso da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ Crie e execute um plano para automatizar respostas.
+ Faça o inventário de todos os seus procedimentos de resposta de alerta. Você deve planejar suas respostas de alerta antes de classificar as tarefas.
+ Faça o inventário de todas as tarefas com ações específicas que devem ser executadas. A maioria dessas ações está documentada nos runbooks. Você também deve ter playbooks para alertas de eventos inesperados.
+ Examine os runbooks e os playbooks de todas as ações automatizáveis. Em geral, se for possível definir uma ação, ela provavelmente poderá ser automatizada.
+ Classifique primeiro as atividades demoradas ou propensas a erros. É mais vantajoso remover as fontes de erros e reduzir o tempo de resolução.
+ Estabeleça um plano para concluir a automação. Mantenha um plano ativo para automatizar e atualizar a automação.
+ Examine os requisitos manuais para criar oportunidades de automação. Desafie seu processo manual para criar oportunidades de automatização.
## Recursos
**Documentos relacionados:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Criar uma regra do EventBridge que seja acionada em um evento de um recurso da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [O que é o Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Trabalhar com documentos de automação (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 Análises
colete arquivos de log e históricos de métricas e analise-os para obter tendências mais abrangentes e informações sobre a carga de trabalho.
O Amazon CloudWatch Logs oferece suporte a uma [linguagem de consulta simples, mas poderosa](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) que você pode usar para analisar dados de log. O Amazon CloudWatch Logs também oferece suporte a assinaturas que permitem que os dados fluam perfeitamente ao Amazon S3, onde você pode usar o ou o Amazon Athena para consultar esses dados. Ele oferece suporte a consultas em uma grande variedade de formatos. Perceber [Formatos de dados e SerDes compatíveis](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) no guia do usuário do Amazon Athena para obter mais informações. Para análise de conjuntos enormes de arquivos de log, você pode executar um cluster do Amazon EMR para executar análises em escala de petabytes.
Existem várias ferramentas fornecidas por parceiros da AWS e por terceiros que permitem agregação, processamento, armazenamento e estudo analítico. Essas ferramentas incluem New Relic, Splunk, Loggly, Logstash, CloudHealth e Nagios. Porém, a geração fora dos registros do aplicativo e do sistema é única para cada provedor de nuvem e costuma ser única para cada serviço.
Uma parte do processo de monitoramento que costuma ser negligenciada é o gerenciamento de dados. Você precisa determinar os requisitos de retenção para monitorar os dados e então aplicar as políticas de ciclo de vida de acordo. O Amazon S3 oferece suporte ao gerenciamento de ciclo de vida no nível do bucket do S3. Esse gerenciamento de ciclo de vida pode ser aplicado de modo diferente a diferentes caminhos no bucket. Mais perto do fim do ciclo de vida, você pode fazer a transição dos dados ao Amazon Glacier para armazenamento de longo prazo e posterior expiração após o fim do período de retenção. A classe de armazenamento S3 Intelligent-Tiering foi projetada para otimizar custos movendo automaticamente dados para o nível de acesso mais econômico, sem impacto na performance ou sobrecarga operacional.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ O CloudWatch Logs Insights permite pesquisar e analisar dinamicamente seus dados de log no Amazon CloudWatch Logs.
+ [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Use o Amazon CloudWatch Logs para enviar logs para o Amazon S3, onde você pode usar o Amazon Athena para consultar dados.
+ [Como analiso meus logs de acesso ao servidor do Amazon S3 usando o Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Crie uma política de ciclo de vida do S3 para o bucket de logs de acesso ao seu servidor. Configure a política de ciclo de vida para remover periodicamente os arquivos de log. Esse procedimento reduz a quantidade de dados que o Athena analisa em cada consulta.
+ [Como faço para criar uma política de ciclo de vida de um bucket do S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Recursos
**Documentos relacionados:**
+ [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Como faço para criar uma política de ciclo de vida de um bucket do S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Como analiso meus logs de acesso ao servidor do Amazon S3 usando o Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Realizar revisões regularmente
Revise frequentemente a implementação do monitoramento da workload e atualize-a com base em eventos e alterações significativos.
O monitoramento eficaz é orientado pelas principais métricas de negócios. Certifique-se de que essas métricas sejam acomodadas em sua carga de trabalho à medida que as prioridades de negócios mudam.
Auditar seu monitoramento ajuda a garantir que você saiba quando um aplicativo está atingindo as respectivas metas de disponibilidade. A análise da causa raiz requer a capacidade de descobrir o que aconteceu quando ocorreram falhas. A AWS fornece serviços que permitem acompanhar o estado dos seus serviços durante um incidente:
+ **Amazon CloudWatch Logs:** você pode armazenar seus logs nesse serviço e inspecionar seu conteúdo.
+ **Amazon CloudWatch Logs Insights**: é um serviço totalmente gerenciado que permite analisar logs massivos em segundos. Ele oferece consultas e visualizações rápidas e interativas.
+ **AWS Config:** você pode ver qual infraestrutura da AWS estava em uso em diferentes momentos.
+ **AWS CloudTrail:** você pode ver quais APIs da AWS foram invocadas, a que horas e por qual entidade principal.
Na AWS, realizamos uma reunião semanal para [revisar a performance operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) e para compartilhar aprendizados entre as equipes. Como há tantas equipes na AWS, criamos [A roda](https://aws.amazon.com/blogs/opensource/the-wheel/) para escolher aleatoriamente uma carga de trabalho para revisão. Estabelecer um ritmo regular para análises de performance operacional e compartilhamento de conhecimento aprimora sua capacidade de obter uma performance superior de suas equipes operacionais.
**Antipadrões comuns:**
+ Coletar apenas as métricas padrão.
+ Definir uma estratégia de monitoramento e nunca revisá-la.
+ Não analisar o monitoramento quando alterações importantes são implantadas.
**Benefícios do estabelecimento dessa prática recomendada:** A revisão regular do monitoramento permite a antecipação de possíveis problemas, em vez de reagir a notificações quando um problema previsto realmente ocorrer.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Crie vários painéis para a workload. Você deve ter um painel superior com as principais métricas de negócios e as métricas técnicas identificadas como as mais relevantes à integridade projetada da carga de trabalho conforme a variação do uso. Você também deve ter painéis para vários níveis e dependências da aplicação que podem ser inspecionados.
+ [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Programe e realize revisões regulares dos painéis da workload. Realize uma inspeção regular dos painéis. Você pode ter graus diferentes de profundidade para a inspeção.
+ Inspecione as tendências nas métricas. Compare os valores das métricas com os valores históricos para ver se há tendências que possam indicar algo que precise de investigação. Exemplos disso incluem: aumento da latência, diminuição da função principal de negócios e aumento das respostas a falhas.
+ Verifique se há exceções ou anomalias nas suas métricas. As médias ou os valores medianos podem mascarar as exceções e as anomalias. Examine os valores mais altos e mais baixos durante o período e investigue as causas das pontuações extremas. À medida que você continua a eliminar essas causas, a redução da definição de extremo permite melhorar cada vez mais a consistência da performance da workload.
+ Procure mudanças bruscas no comportamento. Uma mudança imediata na quantidade ou na direção de uma métrica pode indicar que houve uma alteração na aplicação ou fatores externos aos quais você talvez precise adicionar outras métricas para acompanhar.
## Recursos
**Documentos relacionados:**
+ [Consultas de exemplo do Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de painéis do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 Monitorar o rastreamento completo das solicitações por meio do seu sistema
Use o AWS X-Ray ou ferramentas de terceiros para que os desenvolvedores possam analisar e depurar mais facilmente os sistemas distribuídos para entender a performance das aplicações e dos serviços subjacentes delas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Monitore o rastreamento completo das solicitações por meio do seu sistema. O AWS X-Ray é um serviço que coleta dados sobre as solicitações atendidas por sua aplicação e fornece ferramentas que você pode usar para visualizar, filtrar e obter insights desses dados para identificar problemas e oportunidades de otimização. Para qualquer solicitação rastreada para a sua aplicação, você pode ver informações detalhadas sobre a solicitação e a resposta e também sobre as chamadas que a aplicação faz para recursos downstream da AWS, microsserviços, bancos de dados e APIs da Web.
+ [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## Recursos
**Documentos relacionados:**
+ [Depuração com o Amazon CloudWatch Synthetics e o AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [A Amazon Builders’ Library: instrumentação de sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 Como você projeta sua carga de trabalho para se adaptar às mudanças na demanda?
Uma carga de trabalho escalável oferece elasticidade para adicionar ou remover recursos automaticamente para que atendam melhor à demanda atual a qualquer momento.
**Topics**
+ [REL07-BP01 Usar a automação ao obter ou escalar recursos](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obter recursos após a detecção de danos em uma workload](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obter recursos após a detecção de que mais recursos são necessários para uma workload](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Usar a automação ao obter ou escalar recursos
Ao substituir recursos danificados ou escalar sua workload, automatize o processo por meio dos serviços gerenciados pela AWS, como o Amazon S3 e o AWS Auto Scaling. Você também pode usar ferramentas de terceiros e os AWS SDKs para automatizar a escalabilidade.
Os serviços gerenciados pela AWS incluem o Amazon S3, o Amazon CloudFront, o AWS Auto Scaling, o AWS Lambda, o Amazon DynamoDB, o AWS Fargate e o Amazon Route 53.
O AWS Auto Scaling permite detectar e substituir instâncias danificadas. Ele também permite criar planos de escalabilidade para recursos, incluindo instâncias e frotas Spot do [Amazon EC2](https://aws.amazon.com/ec2/) , tarefas do [Amazon ECS](https://aws.amazon.com/ecs/) tabelas e índices do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) e réplicas do [Amazon Aurora](https://aws.amazon.com/aurora/) .
Ao escalar instâncias do EC2, certifique-se de usar várias zonas de disponibilidade (de preferência, pelo menos três) e adicione ou remova capacidade para manter o equilíbrio entre essas zonas de disponibilidade. Tarefas do ECS ou pods do Kubernetes (ao usar o Amazon Elastic Kubernetes Service) também devem ser distribuídos em várias zonas de disponibilidade.
Ao usar o AWS Lambda, as instâncias são escaladas automaticamente. Sempre que uma notificação de evento é recebida para sua função, o AWS Lambda localiza rapidamente a capacidade livre dentro de sua frota de computação e executa seu código até a simultaneidade alocada. Você precisa se certificar de que a simultaneidade necessária esteja configurada no Lambda específico e no seu Service Quotas.
O Amazon S3 escala automaticamente para lidar com altas taxas de solicitação. Por exemplo, seu aplicativo pode atingir pelo menos 3.500 solicitações PUT/COPY/POST/DELETE ou 5.500 solicitações GET/HEAD por segundo por prefixo em um bucket. Não há limites para o número de prefixos em um bucket. Você pode aumentar a performance de leitura ou gravação paralelizando as leituras. Por exemplo, se você criar 10 prefixos em um bucket do Amazon S3 para paralelizar leituras, poderá escalar sua performance de leitura para 55 mil solicitações de leitura por segundo.
Configure e use o Amazon CloudFront ou uma rede de entrega de conteúdo (CDN) confiável. Uma CDN pode fornecer tempos mais rápidos de resposta ao usuário final e atender às solicitações de conteúdo do cache, reduzindo a necessidade de escalar a workload.
**Antipadrões comuns:**
+ Implementar grupos de Auto Scaling para autorreparação, mas não implementar elasticidade.
+ Usar a escalabilidade automática para responder a grandes aumentos no tráfego.
+ Implantar aplicativos altamente com estado, eliminando a opção de elasticidade.
**Benefícios do estabelecimento dessa prática recomendada:** A automação elimina a possibilidade de erros manuais na implantação e no descomissionamento de recursos. A automação remove o risco de custos excedentes e de negação de serviço decorrentes da lentidão na resposta às necessidades de implantação ou de descomissionamento.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Configure e use o AWS Auto Scaling. Ele monitora seus aplicativos e ajusta automaticamente a capacidade para manter uma performance estável e previsível com o menor custo possível. Ao usar o AWS Auto Scaling, você pode configurar a escalabilidade da aplicação para vários recursos em diversos serviços.
+ [O que é o AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Configure o Auto Scaling nas instâncias do Amazon EC2 e frotas spot, nas tarefas do Amazon ECS, nas tabelas e índices do Amazon DynamoDB, nas réplicas do Amazon Aurora e nos dispositivos do AWS Marketplace, conforme aplicável.
+ [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ Use as operações de API de serviço para especificar alarmes, políticas de escalabilidade e tempos de aquecimento e de resfriamento.
+ Use o Elastic Load Balancing. Os load balancers podem distribuir a carga por caminho ou por conectividade de rede.
+ [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ O Application Load Balancers pode distribuir a carga por caminho.
+ [O que é um Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Configure um Application Load Balancer para distribuir o tráfego para diferentes workloads com base no caminho sob o nome de domínio.
+ É possível usar os Application Load Balancers para distribuir as cargas de maneira integrada ao AWS Auto Scaling para gerenciar a demanda.
+ [Uso de um balanceador de carga com um grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Os Network Load Balancers podem distribuir a carga por conexão.
+ [O que é um Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Configure um Network Load Balancer para distribuir o tráfego para cargas de trabalho diferentes por meio do TCP ou para ter um conjunto constante de endereços IP para a carga de trabalho.
+ É possível usar os Network Load Balancers para distribuir as cargas de maneira integrada ao AWS Auto Scaling para gerenciar a demanda.
+ Use um provedor DNS altamente disponível. Nomes DNS permitem que os usuários insiram nomes, em vez de endereço IP, para acessar suas workloads e distribuem essas informações a um escopo definido, em geral, globalmente para usuários da workload.
+ Use o Amazon Route 53 ou um provedor DNS confiável.
+ [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Use o Route 53 para gerenciar as distribuições e os balanceadores de carga do CloudFront.
+ Determine os domínios e subdomínios que serão gerenciados.
+ Crie conjuntos de registros adequados com os registros ALIAS ou CNAME.
+ [Trabalhando com registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ Use a rede global da AWS para otimizar o caminho dos usuários às aplicações. O AWS Global Accelerator monitora continuamente a integridade dos endpoints da aplicação e redireciona o tráfego para endpoints íntegros em menos de 30 segundos.
+ O AWS Global Accelerator é um serviço que melhora a disponibilidade e a performance das aplicações com usuários locais ou globais. Ele fornece endereços IP estáticos que atuam como um ponto de entrada fixo para os endpoints da aplicação em uma ou várias Regiões da AWS, como os Application Load Balancers, os Network Load Balancers ou as instâncias do Amazon EC2.
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Configure e use o Amazon CloudFront ou uma rede de entrega de conteúdo (CDN) confiável. Uma rede de entrega de conteúdo pode fornecer tempos mais rápidos de resposta ao usuário final e atender às solicitações de conteúdo que podem causar escalabilidade desnecessária das suas workloads.
+ [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ Configure as distribuições do Amazon CloudFront para suas workloads ou use uma CDN de terceiros.
+ Você pode limitar o acesso às workloads para que elas sejam acessíveis somente pelo CloudFront usando os intervalos de IPs para o CloudFront nos seus grupos de segurança ou suas políticas de acesso de endpoint.
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de computação automatizadas](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produtos que podem ser usados com Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Uso de um balanceador de carga com um grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [O que é o AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [O que é o Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [O que é o Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [O que é um Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [O que é um Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Trabalhando com registros](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 Obter recursos após a detecção de danos em uma workload
Escale recursos de modo reativo quando necessário, se a disponibilidade for afetada, para restaurar a disponibilidade da carga de trabalho.
Primeiro, você deve configurar as verificações de integridade e os critérios nessas verificações para indicar quando a disponibilidade é afetada pela falta de recursos. Em seguida, notifique o pessoal apropriado para escalar manualmente o recurso ou acione a automação para escalá-lo automaticamente.
A escala pode ser ajustada manualmente para sua workload. Por exemplo, é possível alterar o número de instâncias do EC2 em um grupo de Auto Scaling ou modificar o throughput de uma tabela do DynamoDB por meio do Console de gerenciamento da AWS ou do AWS CLI. No entanto, a automação deve ser usada sempre que possível (consulte **Use a automação ao obter ou escalar recursos**).
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Obtenha recursos após a detecção de danos em uma workload. Escale recursos de modo reativo quando necessário, se a disponibilidade for afetada, para restaurar a disponibilidade da carga de trabalho.
+ Use planos de escalabilidade, componente principal do AWS Auto Scaling, para configurar um conjunto de instruções para escalar seus recursos. Se você trabalha com o AWS CloudFormation ou adiciona tags aos recursos da AWS, poderá configurar planos de escalabilidade para diferentes conjuntos de recursos por aplicação. O AWS Auto Scaling fornece recomendações para estratégias de escalabilidade personalizadas para cada recurso. Depois que o plano de escalabilidade for criado, o AWS Auto Scaling combinará os métodos de escalabilidade dinâmica e preditiva para oferecer suporte à sua estratégia de escalabilidade.
+ [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ O Amazon EC2 Auto Scaling ajuda a garantir que você tenha o número correto de instâncias do Amazon EC2 disponíveis para processar a carga da aplicação. Você cria coleções de instâncias do EC2, chamadas de grupos de Auto Scaling. Você pode especificar o número mínimo de instâncias em cada grupo de Auto Scaling, e o Amazon EC2 Auto Scaling garante que o grupo nunca fique abaixo desse tamanho. Você pode especificar o número mínimo de instâncias em cada grupo de Auto Scaling, e o Amazon EC2 Auto Scaling garante que o grupo nunca fique abaixo desse tamanho.
+ [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ A escalabilidade automática do Amazon DynamoDB usa o serviço AWS Application Auto Scaling para ajustar dinamicamente a capacidade de throughput provisionado por você, em resposta aos padrões de tráfego reais. Isso permite que uma tabela ou um índice secundário global aumente sua capacidade provisionada de leitura e gravação para sustentar aumentos repentinos no tráfego, sem controle de utilização.
+ [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de computação automatizadas](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produtos que podem ser usados com Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Obter recursos após a detecção de que mais recursos são necessários para uma workload
Escale os recursos proativamente para atender à demanda e evitar impacto na disponibilidade.
Muitos serviços da AWS são escalados automaticamente para atender à demanda. Se estiver usando instâncias do Amazon EC2 ou clusters do Amazon ECS, você poderá configurar a escalabilidade automática deles para que ocorra com base nas métricas de uso que correspondam à demanda da workload. Para o Amazon EC2, a utilização média da CPU, a contagem de solicitações do load balancer ou a largura de banda da rede podem ser usadas para expandir (ou reduzir) instâncias do EC2. Para o Amazon ECS, a utilização média da CPU, a contagem de solicitações do balanceador de carga e a utilização da memória podem ser usadas para aumentar (ou reduzir) a escala horizontalmente de tarefas do ECS. Ao usar o Target Auto Scaling na AWS, o Autoscaler atua como um termostato doméstico, adicionando ou removendo recursos para manter o valor pretendido (por exemplo, 70% de utilização da CPU) que você especificar.
O AWS Auto Scaling também pode fazer o [Auto Scaling preditivo](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), que usa machine learning para analisar a carga de trabalho histórica de cada recurso e prevê regularmente a carga futura para os próximos dois dias.
A Lei de Little ajuda a calcular quantas instâncias de computação (instâncias do EC2, funções simultâneas do Lambda etc.) são necessárias.
*B* = *λW*
L = número de instâncias (ou simultaneidade média no sistema)
λ = taxa média na qual as solicitações chegam (requisição por segundo)
W = tempo médio que cada solicitação gasta no sistema (s)
Por exemplo, a 100 rps, se cada solicitação demorar 0,5 segundos para ser processada, você precisará de 50 instâncias para acompanhar a demanda.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Obtenha recursos após a detecção de que mais recursos são necessários para uma workload. Escale os recursos proativamente para atender à demanda e evitar impacto na disponibilidade.
+ Calcule quantos recursos de computação serão necessários (simultaneidade de computação) para processar uma determinada taxa de solicitações.
+ [Histórias sobre a Lei de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ Quando você tiver um padrão histórico de uso, configure a escalabilidade programada para a escalabilidade automática do Amazon EC2.
+ [Escalabilidade programada para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ Use a escalabilidade preditiva da AWS.
+ [Escalabilidade preditiva para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## Recursos
**Documentos relacionados:**
+ [AWS Auto Scaling: como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace: produtos que podem ser usados com Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gerenciamento da capacidade de throughput de modo automático com o DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Escalabilidade preditiva para o EC2 com Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Escalabilidade programada para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Histórias sobre a Lei de Little](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 Fazer o teste de carga da sua workload
Adote uma metodologia de teste de carga para avaliar se a ação de escalabilidade atende aos requisitos da carga de trabalho.
É importante realizar testes de carga sustentada. Os testes de carga devem descobrir o ponto de interrupção e testar a performance da workload. A AWS facilita a configuração de ambientes de teste temporários que modelam a escala de sua workload de produção. Na nuvem, você pode criar um ambiente de teste em escala de produção sob demanda, concluir seus testes e descomissionar os recursos. Como você paga somente pelo ambiente de teste quando está em execução, é possível simular seu ambiente ativo por uma fração do custo dos testes no local.
Os testes de carga em produção também devem ser considerados como parte dos dias de jogos em que o sistema de produção é destacado, durante horas de menor utilização do cliente, com todo o pessoal disponível para interpretar os resultados e resolver os problemas que surgirem.
**Antipadrões comuns:**
+ Executar testes de carga em implantações que não têm a mesma configuração da sua produção.
+ Executar testes de carga apenas em componentes individuais da carga de trabalho, e não nela toda.
+ Executar testes de carga com um subconjunto de solicitações, e não com um conjunto representativo de solicitações reais.
+ Executar testes de carga para um pequeno fator de segurança acima da carga esperada.
**Benefícios do estabelecimento dessa prática recomendada:** Você sabe quais componentes em sua arquitetura falham sob carga e pode identificar as métricas que devem ser observadas para indicar que você está se aproximando dessa carga a tempo de resolver o problema, evitando o impacto dessa falha.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Realize testes de carga para identificar qual aspecto da workload indica que é necessário adicionar ou remover capacidade. Os testes de carga devem ter tráfego representativo semelhante ao que você recebe na produção. Aumente a carga enquanto observa as métricas que você preparou para determinar aquelas que indicam quando é necessário adicionar ou remover recursos.
+ [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifique a combinação de solicitações. Você pode ter diversas combinações de solicitações, portanto, deve examinar vários períodos ao identificar a combinação de tráfego.
+ Implemente um direcionador de carga. Você pode usar um código personalizado, um código aberto ou um software comercial para implementar um direcionador de carga.
+ Faça o teste de carga inicialmente com uma pequena capacidade. Você vê alguns efeitos imediatos ao direcionar a carga para uma capacidade menor, possivelmente tão pequena quanto uma instância ou um contêiner.
+ Faça o teste de carga com uma capacidade maior. Os efeitos serão diferentes em uma carga distribuída, portanto, você deve testar o mais próximo possível de um ambiente de produto.
## Recursos
**Documentos relacionados:**
+ [Teste de carga distribuída na AWS: simular milhares de usuários conectados](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 Como você implementa uma alteração?
As alterações controladas são necessárias para implantar novas funcionalidades e garantir que as cargas de trabalho e o ambiente operacional executem softwares conhecidos e possam ser corrigidos ou substituídos de maneira previsível. Se essas alterações forem descontroladas, será difícil prever o efeito ou resolver problemas decorrentes delas.
**Topics**
+ [REL08-BP01 Usar runbooks para atividades padrão, como implantação](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrar testes funcionais como parte da sua implantação](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Integrar testes de resiliência como parte da sua implantação](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Implantar usando uma infraestrutura imutável](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Implantar alterações com automação](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Usar runbooks para atividades padrão, como implantação
Os runbooks são os procedimentos predefinidos para alcançar um resultado específico. Use-os para executar atividades padrão, sejam elas feitas manualmente ou automaticamente. Os exemplos incluem a implantação de uma workload, a aplicação de patches a ela ou a realização de modificações de DNS.
Por exemplo, coloque processos em vigor para [garantir a segurança de reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Garantir que você possa reverter uma implantação sem qualquer interrupção para seus clientes é essencial para tornar um serviço confiável.
Para procedimentos de runbooks, comece com um processo manual efetivo válido, implemente-o em código e acione-o para ser executado automaticamente quando adequado.
Mesmo para cargas de trabalho sofisticadas altamente automatizadas, os runbooks ainda são úteis para [organizar dias de jogos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) ou atender a requisitos rigorosos de relatórios e auditoria.
Observe que playbooks são usados em resposta a incidentes específicos, e runbooks são usados para alcançar resultados específicos. Muitas vezes, os runbooks são para atividades de rotina, enquanto os playbooks são usados para responder a eventos que não são rotineiras.
**Antipadrões comuns:**
+ Executar alterações não planejadas na configuração em produção.
+ Ignorar as etapas do seu plano para agilizar a implantação, resultando em falha na implantação.
+ Fazer alterações sem testar a inversão delas.
**Benefícios do estabelecimento desta prática recomendada:** O planejamento eficaz da alteração aumenta sua capacidade de executá-la com êxito, porque você está ciente de todos os sistemas afetados. A validação da alteração em ambientes de teste aumenta sua confiança.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Documente os procedimentos em runbooks para permitir respostas consistentes e rápidas a eventos bem conhecidos.
+ [AWS Well-Architected Framework: conceitos: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Use o princípio de infraestrutura como código para definir sua infraestrutura. Ao usar o AWS CloudFormation (ou um terceiro confiável) para definir a infraestrutura, você poderá usar o software de controle de versão para controlar as versões e acompanhar as alterações.
+ Use o AWS CloudFormation (ou um provedor confiável de terceiros) para definir sua infraestrutura.
+ [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Use bons princípios de design de software para criar modelos exclusivos e desacoplados.
+ Determine as permissões, os modelos e as partes responsáveis pela implementação.
+ [ Controle de acesso com o AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Use o controle de origem, como o AWS CodeCommit ou uma ferramenta confiável de terceiros, para controle de versão.
+ [O que é o AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de implantação automatizada](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: produtos que podem ser usados para automatizar suas implantações](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: conceitos: runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [O que é o AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [O que é o AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**Exemplos relacionados:**
+ [Automatização de operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 Integrar testes funcionais como parte da sua implantação
Os testes funcionais são executados como parte da implantação automatizada. Se os critérios de êxito não forem atendidos, o pipeline será interrompido ou revertido.
Esses testes são executados em um ambiente de pré-produção, que é preparado antes da produção no pipeline. Idealmente, isso é feito como parte de um pipeline de implantação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Integre testes funcionais como parte da sua implantação. Os testes funcionais são executados como parte da implantação automatizada. Se os critérios de êxito não forem atendidos, o pipeline será interrompido ou revertido.
+ Invoque o AWS CodeBuild durante a “ação de teste” dos pipelines de lançamento de software baseados no AWS CodePipeline. Esse recurso permite que você execute facilmente uma variedade de testes no código, como testes de unidade, análises de código estático e testes de integração.
+ [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ Use as soluções do AWS Marketplace para executar testes automatizados como parte do pipeline de entrega de software.
+ [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Recursos
**Documentos relacionados:**
+ [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Integrar testes de resiliência como parte da sua implantação
Os testes de resiliência (usando os [princípios da engenharia do caos](https://principlesofchaos.org/)) são executados como parte do pipeline de implantação automatizado em um ambiente de pré-produção.
Esses testes são preparados e executados no pipeline em um ambiente de pré-produção. Eles também devem ser executados em produção como parte de [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Integre testes de resiliência como parte da sua implantação. Use a engenharia do caos, a disciplina de experimentar em uma workload, para gerar confiança na capacidade da workload de resistir a condições conturbadas na produção.
+ Os testes de resiliência injetam falhas ou degradação de recursos para avaliar se a workload responde com a resiliência projetada.
+ [Laboratório do Well-Architected: nível 300: testes de resiliência do EC2 RDS e do S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Esses testes podem ser executados regularmente em ambientes de pré-produção nos pipelines de implantação automatizados.
+ Eles também devem ser executados em produção, como parte dos dias de jogo programados.
+ Ao adotar os princípios da engenharia do caos, proponha hipóteses de como a carga de trabalho será executada sob várias condições adversas e, em seguida, teste essas hipóteses por meio dos testes de resiliência.
+ [Princípios da engenharia do caos](https://principlesofchaos.org/)
## Recursos
**Documentos relacionados:**
+ [Princípios da engenharia do caos](https://principlesofchaos.org/)
+ [O que é o AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: testes de resiliência do EC2 RDS e do S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Implantar usando uma infraestrutura imutável
A infraestrutura imutável é um modelo que não requer atualizações, patches de segurança ou alterações de configuração nas workloads de produção. Quando uma alteração é necessária, a arquitetura é criada em uma nova infraestrutura e implantada na produção.
A implementação mais comum do paradigma de infraestrutura imutável é o ***servidor imutável***. Isso significa que, se um servidor precisar de uma atualização ou uma correção, novos servidores serão implantados em vez de atualizar os já em uso. Portanto, em vez de fazer login no servidor via SSH e atualizar a versão do software, cada alteração no aplicativo começa com um push de software para o repositório de código, por exemplo, git push. Como as alterações não são permitidas na infraestrutura imutável, você pode ter certeza sobre o estado do sistema implantado. As infraestruturas imutáveis são inerentemente mais consistentes, confiáveis e previsíveis, e simplificam muitos aspectos do desenvolvimento e operações de software.
Use uma implantação de canário ou azul/verde ao implantar aplicativos em infraestruturas imutáveis.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) é a prática de direcionar um pequeno número de seus clientes para a nova versão, geralmente em execução em uma única instância de serviço (o canário). Em seguida, você examina profundamente todas as alterações de comportamento ou erros gerados. Você poderá remover o tráfego da implantação canário se encontrar problemas críticos e enviar os usuários de volta para a versão anterior. Se a implantação for bem-sucedida, você poderá continuar implantando a uma velocidade desejada enquanto monitora as alterações em busca de erros até a implantação estar concluída. O AWS CodeDeploy pode ser configurado com uma configuração de implantação que permitirá uma implantação canário.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) é semelhante à implantação canário, com a diferença que um conjunto completo do aplicativo é implantado em paralelo. Você alterna as implantações entre as duas pilhas (azul e verde). Novamente, é possível enviar o tráfego para a nova versão e voltar para a versão antiga se houver problemas na implantação. Normalmente, todo o tráfego é alternado de uma só vez. No entanto, você também pode usar frações do tráfego para cada versão para aumentar a adoção da nova versão usando os recursos de roteamento de DNS ponderado do Amazon Route 53. O AWS CodeDeploy e o AWS Elastic Beanstalk podem ser definidos com uma configuração de implantação que permitirá uma implantação azul/verde.
![\[Diagrama mostrando a implantação azul/verde com o AWS Elastic Beanstalk e o Amazon Route 53\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Benefícios da infraestrutura imutável:
+ **Redução em desvios de configuração:** ao substituir frequentemente os servidores de uma configuração básica, conhecida e controlada por versão, a infraestrutura é **redefinida** para um estado conhecido, evitando desvios de configuração.
+ **Implantações simplificadas**: as implantações são simplificadas porque não precisam oferecer suporte a atualizações. As atualizações são apenas novas implantações.
+ **Implantações atômicas confiáveis:** as implantações são concluídas com êxito ou nada muda. Ele dá mais confiança no processo de implantação.
+ **Implantações mais seguras com processos rápidos de reversão e recuperação:** as implantações são mais seguras, pois a versão de trabalho anterior não é alterada. Você pode reverter para ele se forem detectados erros.
+ **Ambientes consistentes de teste e depuração:** como todos os servidores usam a mesma imagem, não há diferenças entre ambientes. Uma compilação é implantada em vários ambientes. Ele também evita ambientes inconsistentes e simplifica o teste e a depuração.
+ **Maior escalabilidade:** como os servidores usam uma imagem base, são consistentes e podem ser repetidos, a escalabilidade automática é trivial.
+ **Cadeia de ferramentas simplificada**: a cadeia de ferramentas é simplificada, pois você pode se livrar das ferramentas de gerenciamento de configuração gerenciando atualizações de software de produção. Não há ferramentas ou agentes adicionais instalados nos servidores. As alterações são feitas na imagem base, testadas e implementadas.
+ **Maior segurança:** ao negar todas as alterações nos servidores, você pode desabilitar o SSH nas instâncias e remover chaves. Isso reduz o vetor de ataque, melhorando a postura de segurança da sua organização.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Faça a implantação com uma infraestrutura imutável. A infraestrutura imutável é um modelo no qual não ocorrem atualizações, patches de segurança ou alterações de configuração *no local* em sistemas de produção. Se for necessária uma alteração, outra versão da arquitetura será criada e implantada na produção.
+ [Visão geral de uma implantação azul/verde](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Implantação gradual de aplicativos sem servidor](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infraestrutura imutável: confiabilidade, consistência e confiança por meio da imutabilidade](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## Recursos
**Documentos relacionados:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Implantação gradual de aplicativos sem servidor](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infraestrutura imutável: confiabilidade, consistência e confiança por meio da imutabilidade](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Visão geral de uma implantação azul/verde](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [A Amazon Builders’ Library: garanta a segurança da reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 Implantar alterações com automação
As implantações e a aplicação de patches são automatizadas para eliminar o impacto negativo.
As alterações nos sistemas de produção são uma das maiores áreas de risco para muitas organizações. Consideramos as implantações um problema de primeira classe a ser resolvido junto com os problemas de negócio que o software aborda. Atualmente, isso significa usar a automação nas operações sempre que for viável, incluindo testar e implantar alterações, adicionar ou remover capacidade e migrar dados. O AWS CodePipeline permite gerenciar as etapas necessárias para liberar a sua carga de trabalho. Isso inclui um estado de implantação usando o AWS CodeDeploy para automatizar a implantação do código do aplicativo em instâncias do Amazon EC2, instâncias on-premises, funções do Lambda sem servidor ou serviços do Amazon ECS.
**Recomendação**
Embora a sabedoria convencional sugira que você mantenha humanos no ciclo para os procedimentos operacionais mais difíceis, sugerimos automatizar esses procedimentos exatamente por isso.
**Antipadrões comuns:**
+ Executar as alterações manualmente.
+ Ignorar as etapas da sua automação por meio de fluxos de trabalho de emergência.
+ Não seguir seus planos.
**Benefícios do estabelecimento desta prática recomendada:** Ao usar a automação para implantar todas as alterações, você elimina as chances de introduzir erros humanos e permite que sejam feitos testes antes de alterar a produção para garantir que seus planos sejam conduzidos.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Automatize seu pipeline de implantação. Os pipelines de implantação permitem invocar testes automatizados e detecção de anomalias. Além disso, eles interrompem o pipeline em uma determinada etapa antes da implantação em produção ou revertem automaticamente uma alteração.
+ [A Amazon Builders’ Library: garanta a segurança da reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [A Amazon Builders’ Library: acelere a entrega contínua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Use o AWS CodePipeline (ou um produto de terceiros confiável) para definir e executar seus pipelines.
+ Configure o pipeline para ser iniciado quando uma alteração for confirmada no repositório do seu código.
+ [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Use o Amazon Simple Notification Service (Amazon SNS) e o Amazon Simple Email Service (Amazon SES) para enviar notificações sobre problemas no pipeline ou integrar-se com uma ferramenta de bate-papo da equipe, como o Amazon Chime.
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [O que é o Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [O que é o Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automatize mensagens de chat com webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudá-lo a criar soluções de implantação automatizada](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: produtos que podem ser usados para automatizar suas implantações](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automatize mensagens de chat com webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [A Amazon Builders’ Library: garanta a segurança da reversão durante implantações](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [A Amazon Builders’ Library: acelere a entrega contínua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [O que é o AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [O que é o CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [O que é o Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Vídeos relacionados:**
+ [Conferência da AWS 2019: CI/CD na AWS](https://youtu.be/tQcF6SqWCoY)
# Gerenciamento de falhas
**Topics**
+ [REL 9 Como você faz backup dos dados?](w2aac19b9c11b5.md)
+ [REL 10 Como usar o isolamento de falhas para proteger sua carga de trabalho?](w2aac19b9c11b7.md)
+ [REL 11 Como você projeta sua carga de trabalho para resistir a falhas de componentes?](w2aac19b9c11b9.md)
+ [REL 12 Como testar a confiabilidade?](w2aac19b9c11c11.md)
+ [REL 13 Como você planeja a recuperação de desastres (DR)?](w2aac19b9c11c13.md)
# REL 9 Como você faz backup dos dados?
Faça backup de dados, aplicativos e configurações para atender aos seus requisitos de Recovery Time Objective (RTO – Objetivo do tempo de recuperação) e de Recovery Point Objective (RPO – Objetivo do ponto de recuperação).
**Topics**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Proteger e criptografar backups](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Realizar o backup de dados automaticamente](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes
Todos os armazenamentos de dados da AWS oferecem recursos de backup. Serviços como o Amazon RDS e o Amazon DynamoDB oferecem suporte adicional ao backup automatizado que permite a recuperação a um ponto anterior no tempo (PITR), ajudando você a restaurar um backup a qualquer momento até cinco minutos ou menos, antes da hora atual. Muitos serviços da AWS oferecem a capacidade de copiar backups para outra Região da AWS. O AWS Backup é uma ferramenta que fornece a capacidade de centralizar e automatizar a proteção de dados em todos os serviços da AWS.
É possível usar o Amazon S3 como destino de backup para fontes de dados autogerenciadas e gerenciadas pela AWS. Os serviços da AWS como o Amazon EBS, o Amazon RDS e o Amazon DynamoDB, têm recursos integrados para criar backups. É possível também usar um software de backup de terceiros.
É possível fazer backup de dados on-premises na Nuvem AWS usando [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) ou [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). É possível usar os buckets do Amazon S3 para armazenar estes dados na AWS. O Amazon S3 oferece vários níveis de armazenamento, como [Amazon Glacier ou S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) , para reduzir custos de armazenamento de dados.
Você pode atender às necessidades de recuperação de dados reproduzindo os dados de outras fontes. Por exemplo: [os nós de réplicas do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) ou [as réplicas de leitura do RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) podem ser usados para reproduzir dados caso o primário seja perdido. Nos casos em que fontes como esta podem ser usadas para atender aos seus [objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), pode ser que você não precise fazer backup. Outro exemplo: se estiver trabalhando com Amazon EMR, poderá não ser necessário fazer backup do seu armazenamento de dados HDFS, desde que você possa [reproduzir os dados no EMR do S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Ao selecionar uma estratégia de backup, considere o tempo necessário para recuperar os dados. Ele depende do tipo de backup (no caso de uma estratégia de backup) ou da complexidade do mecanismo de reprodução de dados. O tempo deve estar dentro do RTO para a workload.
**Resultado desejado:**
As fontes de dados foram identificadas e classificadas com base na criticidade. Em seguida, estabeleça uma estratégia de recuperação de dados com base no RPO. A estratégia envolve fazer o backup dessas fontes de dados ou a capacidade de reproduzir dados de outras fontes. Em caso de perda de dados, a estratégia implementada permite a recuperação ou reprodução de dados dentro do RPO e RTO definidos.
**Fase de maturidade da nuvem:** Foundational
**Antipadrões comuns:**
+ Não estar ciente de todas as fontes de dados para a workload e sua criticidade.
+ Não fazer backups de fontes de dados essenciais.
+ Fazer backups apenas de algumas fontes de dados sem usar a criticidade como critério.
+ Não ter um RPO definido ou a frequência de backup não atender ao RPO.
+ Não avaliar a necessidade de um backup ou se os dados podem ser reproduzidos de outras fontes.
**Benefícios do estabelecimento dessa prática recomendada:** Identificar os locais onde os backups são necessários, implementar um mecanismo para criar backups ou poder reproduzir os dados de uma fonte externa melhora a capacidade de restaurar e recuperar dados durante uma interrupção.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
Compreenda e use os recursos de backup dos serviços e recursos da AWS usados pela workload. A maioria dos serviços da AWS oferece recursos para fazer backup dos dados da workload.
**Etapas da implementação:**
1. **Identifique todas as fontes de dados para a workload**. Os dados podem ser armazenados em vários recursos, como [relacional](https://aws.amazon.com/products/databases/), [volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [sistemas de arquivos](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemas de registro em logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)e aos [armazenamento de objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulte o **Recursos** seção para encontrar **Documentos relacionados** a diferentes serviços da AWS onde os dados são armazenados e a capacidade de fazer backup que eles fornecem.
1. **Classifique as fontes de dados com base na criticidade**. Diferentes conjuntos de dados terão diferentes níveis de criticidade para uma workload e, portanto, diferentes requisitos de resiliência. Por exemplo, alguns dados podem ser críticos e exigir um RPO próximo de zero, enquanto outros dados podem ser menos críticos e tolerar um RPO mais alto e a perda de alguns dados. Da mesma forma, diferentes conjuntos de dados também podem ter diferentes requisitos de RTO.
1. **Use a AWS ou os serviços de terceiros para criar backups dos dados**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) é um serviço gerenciado que permite criar backups de várias fontes de dados na AWS. A maioria desses serviços também possui recursos nativos para criar backups. O AWS Marketplace tem muitas soluções que também fornecem esses recursos. Consulte o **Recursos** listados abaixo para obter informações sobre como criar backups de dados de vários serviços da AWS.
1. **Para dados sem backup, estabeleça um mecanismo de reprodução de dados.**. Você pode optar por não fazer backup dos dados que podem ser reproduzidos de outras fontes por vários motivos. Ás vezes, pode ser mais barato reproduzir dados de fontes se necessário, em vez de criar um backup, pois pode haver um custo associado ao armazenamento de backups. Outro exemplo é quando a restauração de um backup demora mais do que a reprodução dos dados das fontes, resultando em uma violação no RTO. Nestas situações, considere concessões e estabeleça um processo bem definido de como os dados podem ser reproduzidos dessas fontes quando a recuperação de dados for necessária. Por exemplo, se você carregou dados do Amazon S3 para um data warehouse (como o Amazon Redshift) ou para um cluster MapReduce (como o Amazon EMR) para analisá-los, esse é um exemplo de dados que podem ser reproduzidos de outras fontes. Desde que os resultados dessas análises sejam armazenados em algum lugar ou reproduzíveis, você não sofreria uma perda de dados devido a uma falha no data warehouse ou no cluster do MapReduce. Outros exemplos que podem ser reproduzidos de origens incluem caches (como o Amazon ElastiCache) ou réplicas de leitura do RDS.
1. **Estabeleça um ritmo para fazer backup de dados**. A criação de backups de fontes de dados é um processo periódico, e a frequência deve depender do RPO.
**Nível de esforço para o plano de implementação:** Moderado
## Recursos
**Práticas recomendadas relacionadas:**
[REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
**Documentos relacionados:**
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [O que é o Gateway de Volumes?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Fazer backup do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Fazer backup do Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup e restauração para o ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Criar um snapshot do cluster de banco de dados no Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Criar um snapshot do banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) com o Amazon S3
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exportação de dados de log para o Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Gerenciamento do ciclo de vida de objetos](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Recuperação a um ponto anterior no tempo para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Como trabalhar com snapshots de índice do Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Laboratório do Well-Architected: backup e restauração com failback para workload do Analytics](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Laboratório do Well-Architected: recuperação de desastres: backup e restauração](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Proteger e criptografar backups
Controle e detecte o acesso a backups usando autenticação e autorização, como o AWS IAM. Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida.
O Amazon S3 oferece suporte a vários métodos de criptografia de dados ociosos. Ao usar a criptografia no lado do servidor, o Amazon S3 aceita seus objetos como dados não criptografados e, em seguida, criptografa-os ao armazená-los. Ao usar a criptografia do lado do cliente, a aplicação da workload é responsável por criptografar os dados antes de serem enviados ao Amazon S3. Ambos os métodos permitem que você use o AWS Key Management Service (AWS KMS) para criar e armazenar a chave de dados, ou você pode fornecer sua própria chave, pela qual você é responsável. Usando o AWS KMS, você pode definir políticas usando o IAM sobre quem pode e não pode acessar suas chaves de dados e dados descriptografados.
Para o Amazon RDS, se você tiver optado por criptografar seus bancos de dados, seus backups também serão criptografados. Os backups do DynamoDB sempre são criptografados.
**Antipadrões comuns:**
+ Ter o mesmo acesso aos backups e à automação de restauração que os dados.
+ Não criptografar seus backups.
**Benefícios do estabelecimento dessa prática recomendada:** A proteção dos backups impede a violação dos dados, e a criptografia dos dados impede o acesso a eles se forem expostos por engano.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Use a criptografia em cada um dos seus armazenamentos de dados. Se os dados de origem forem criptografados, o backup também será.
+ Habilite a criptografia no RDS. Você pode configurar a criptografia em repouso usando o AWS Key Management Service ao criar uma instância do RDS.
+ [Criptografia de recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Habilite a criptografia nos volumes do EBS. Você pode configurar a criptografia padrão ou especificar uma chave exclusiva após a criação do volume.
+ [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Use a criptografia necessário do Amazon DynamoDB. O DynamoDB criptografa todos os dados em repouso. Você pode usar uma chave AWS KMS de propriedade da AWS ou uma chave KMS gerenciada pela AWS, especificando uma chave armazenada na sua conta.
+ [Criptografia em repouso do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Gerenciamento de tabelas criptografadas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Criptografe seus dados armazenados no Amazon EFS. Configure a criptografia ao criar seu sistema de arquivos.
+ [Criptografia de dados e metadados no EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ Configure a criptografia nas regiões de origem e de destino. Você pode configurar a criptografia em repouso no Amazon S3 usando as chaves armazenadas no KMS, mas as chaves são específicas da região. Você pode especificar as chaves de destino ao configurar a replicação.
+ [Configuração adicional de CRR: replicação de objetos criados com a criptografia do lado do servidor (SSE) usando as chaves de criptografia armazenadas no AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ Implemente permissões de privilégio mínimo para acessar seus backups. Siga as melhores práticas para limitar o acesso aos backups, aos snapshots e às réplicas de acordo com as melhores práticas de segurança.
+ [Pilar Segurança: AWS Well-Architected](./wat.pillar.security.en.html)
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criptografia do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: proteção de dados usando criptografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Configuração adicional de CRR: replicação de objetos criados com a criptografia do lado do servidor (SSE) usando as chaves de criptografia armazenadas no AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Criptografia em repouso do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Criptografia de recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Criptografia de dados e metadados no EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Criptografia para backups na AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Gerenciamento de tabelas criptografadas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar Segurança: AWS Well-Architected](./wat.pillar.security.en.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Realizar o backup de dados automaticamente
Configure os backups para serem feitos automaticamente com base em uma programação periódica informadas pelo objetivo de ponto de recuperação (RPO) ou de acordo com alterações no conjunto de dados. É necessário fazer backup de conjuntos de dados críticos com requisitos de baixa perda de dados automaticamente com frequência, enquanto o backup de dados menos críticos, em que alguma perda é aceitável, pode ser feito com menos frequência.
É possível usar o AWS Backup para criar backups de dados automatizados de várias fontes de dados da AWS. É possível fazer backup das instâncias do Amazon RDS quase continuamente a cada cinco minutos e dos objetos do Amazon S3 a cada quinze minutos, proporcionando recuperação a um ponto anterior no tempo (PITR) para um momento específico no histórico de backup. Para outras fontes de dados da AWS, como volumes do Amazon EBS, tabelas do Amazon DynamoDB ou sistemas de arquivos do Amazon FSx, o AWS Backup pode executar backup automatizado de hora em hora. Esses serviços também oferecem recursos de backup nativos. Os serviços da AWS que oferecem backup automatizado com recuperação a um ponto anterior no tempo incluem [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)e aos [Amazon Keyspaces (para Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) . Eles podem ser restaurados a um momento específico no histórico do backup. A maioria dos outros serviços de armazenamento de dados da AWS oferece a capacidade de programar backups periódicos, até de hora em hora.
O Amazon RDS e o Amazon DynamoDB permitem o backup contínuo com recuperação a um ponto anterior no tempo. O versionamento do Amazon S3, uma vez habilitado, é automático. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) pode ser usado para automatizar a criação, cópia e exclusão de snapshots do Amazon EBS. Ele também pode automatizar a criação, cópia, suspensão e cancelamento de imagens de máquina da Amazon (AMIs) suportadas pelo Amazon EBS e seus snapshots básicos do Amazon EBS.
Para obter uma visão centralizada da automação e do histórico de backups, o AWS Backup oferece uma solução de backup totalmente gerenciada e baseada em políticas. Ele centraliza e automatiza o backup de dados em vários serviços da AWS, na nuvem e on-premises, usando o AWS Storage Gateway.
Além do versionamento, o Amazon S3 oferece replicação. Todo o bucket do S3 pode ser replicado automaticamente para outro bucket na mesma Região da AWS ou em uma diferente.
**Resultado desejado:**
Um processo automatizado que cria backups de fontes de dados em um ritmo estabelecido.
**Antipadrões comuns:**
+ Fazer backups manualmente.
+ Usar recursos que têm o recurso de backup, mas não incluir o backup em sua automação.
**Benefícios do estabelecimento desta prática recomendada:** A automação de backups garante que eles sejam feitos regularmente com base no RPO e alerta você caso isso não ocorra.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
1. **Identifique as fontes de dados** que estão sendo copiados manualmente. Consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para orientações sobre isso.
1. **Determine o RPO** para a workload. Consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md) para orientações sobre isso.
1. **Use uma solução de backup automatizada ou serviço gerenciado**. O AWS Backup é um serviço totalmente gerenciado que facilita a [centralização e automatização da proteção de dados em todos os serviços da AWS, na nuvem ou on-premises](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Os planos de backup são um recurso do AWS Backup que permite a criação de regras que definem os recursos para backup e a frequência com que eles devem ser criados. A frequência deve ser informada pelo RPO estabelecido na etapa 2. [Este laboratório do WA](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornece orientação prática sobre como criar backups automatizados usando o AWS Backup. A maioria dos serviços da AWS que armazenam dados oferecem recursos de backup nativos. Por exemplo, o RDS pode ser aproveitado para backups automatizados com recuperação a um ponto anterior no tempo (PITR).
1. **Para fontes de dados não suportadas** por uma solução de backup automatizado ou serviço gerenciado, como fontes de dados ou filas de mensagens on-premises, considere usar uma solução confiável de terceiros para criar backups automatizados. Como alternativa, você pode criar automação para fazer isso usando a AWS CLI ou os SDKs. Você pode usar o AWS Lambda Functions ou o AWS Step Functions para definir a lógica envolvida na criação de um backup de dados e o Amazon EventBridge para executá-la em uma frequência baseada no RPO (conforme estabelecido na etapa 2).
**Nível de esforço para o plano de implementação:** Baixo
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup
Execute um teste de recuperação para confirmar se a implementação do processo de backup atende aos seus objetivos do tempo de recuperação e de ponto de recuperação.
Ao usar a AWS, você pode criar um ambiente de teste e restaurar seus backups para avaliar os recursos de RTO e RPO e executar testes de conteúdo e integridade dos dados.
Além disso, o Amazon RDS e o Amazon DynamoDB permitem a recuperação point-in-time (PITR). Ao usar o backup contínuo, você pode restaurar o conjunto de dados para o estado em que estava em uma data e hora especificadas.
**Resultado desejado:** Os dados de backups são recuperados periodicamente usando mecanismos bem definidos para garantir que a recuperação seja possível dentro do objetivo de tempo de recuperação (RTO) estabelecido para a workload. Verifique se a restauração de um backup resulta em um recurso contendo os dados originais sem que estejam corrompidos ou inacessíveis e que a perda de dados esteja dentro do objetivo de ponto de recuperação (RPO).
**Antipadrões comuns:**
+ Restaurar um backup, mas não consultar ou recuperar os dados para garantir que a restauração seja útil.
+ Presumir a existência de um backup.
+ Presumir que o backup de um sistema esteja totalmente operacional e que os dados possam ser recuperados dele.
+ Presumir que o tempo para recuperar ou restaurar dados de um backup esteja dentro do RTO para a workload.
+ Presumir que os dados contidos no backup estejam dentro do RPO para a workload.
+ Restaurar ad hoc, sem usar um runbook, ou o lado de fora de um procedimento automatizado estabelecido.
**Benefícios do estabelecimento desta prática recomendada:** Testar a recuperação dos backups garante que os dados possam ser restaurados quando necessário, sem a preocupação de que possam estar ausentes ou corrompidos. Os teste também garantem que a restauração e a recuperação sejam possíveis dentro do RTO para a workload e qualquer perda de dados caia dentro do RPO para a workload.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
Testar a capacidade de backup e de restauração aumenta a confiança na aptidão de realizar essas ações durante uma interrupção. Restaure periodicamente os backups em um novo local e execute testes para verificar a integridade dos dados. Alguns testes comuns que devem ser realizados são a verificação
de que todos os dados estão disponíveis, não corrompidos, acessíveis e que qualquer perda de dados está dentro do RPO para a workload. Eles também podem ajudar a verificar se os mecanismos de recuperação são rápidos o suficiente para acomodar o RTO da workload.
1. **Identifique as fontes de dados** que estão sendo copiados no momento e onde estes backups estão sendo armazenados. Consulte [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para orientações sobre como implementar isso.
1. **Estabeleça critérios para a validação de dados** para cada fonte de dados. Diferentes tipos de dados terão propriedades distintas que podem exigir mecanismos de validação diferentes. Considere como validar esses dados antes de se sentir confiante em usá-los na produção. Algumas maneiras comuns de validar dados são o uso de dados e propriedades de backup, como tipo de dados, formato, soma de verificação, tamanho ou uma combinação deles com lógica de validação personalizada. Por exemplo, pode ser uma comparação dos valores de soma de verificação entre o recurso restaurado e a fonte de dados no momento em que o backup foi criado.
1. **Estabeleça um RTO e um RPO** para restaurar os dados com base na sua criticidade. Consulte [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md) para orientações sobre como implementar isso.
1. **Avalie sua capacidade de recuperação**. Revise sua estratégia de backup e de restauração para entender se ela pode atender ao RTO e ao RPO e ajuste a estratégia conforme necessário. Com o uso do [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), você pode executar uma avaliação da workload. Essa avaliação analisa a aplicação em relação à política de resiliência e relata se as metas de RTO e RPO podem ser atendidas.
1. **Faça uma restauração de teste** por meio de processos atualmente estabelecidos usados na produção para restauração de dados. Esses processos dependem de como foi feito o backup da fonte de dados original, do formato e do local de armazenamento do próprio backup ou se os dados são reproduzidos de outras fontes. Por exemplo, se você estiver usando um serviço gerenciado, como o [AWS Backup, isso poderá ser tão simples quanto restaurar o backup em um novo recurso.](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se usou o AWS Elastic Disaster Recovery, você poderá [executar um exercício de recuperação.](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Valide a recuperação dos dados** do recurso restaurado (da etapa anterior) com base nos critérios estabelecidos anteriormente para validação de dados na etapa 2. Os dados restaurados e recuperados contêm o registro ou item mais recente no momento do backup? Esses dados se enquadram no RPO para a workload?
1. **Meça o tempo necessário** para restauração e recuperação e compare-o ao RTO estabelecido anteriormente na etapa 3. Esse processo se enquadra no RTO para a workload? Por exemplo, compare a data e hora em que o processo de restauração foi iniciado e que a validação da recuperação foi concluída para calcular quanto tempo esse processo leva. Todas as chamadas de API da AWS têm registro de data e hora e essas informações estão disponíveis em [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Embora essas informações possam fornecer detalhes sobre o início do processo de restauração, o registro final de data e hora da conclusão da validação deve ser registrado pela lógica de validação. Se estiver usando um processo automatizado, serviços como o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) podem ser usado para armazenar essas informações. Além disso, muitos serviços da AWS oferecem um histórico de eventos que fornece informações sobre a data e hora que determinadas ações ocorreram. No AWS Backup, as ações de backup e restauração são chamadas de *Empregos*. Eles contêm informações de data e hora como parte dos metadados, que podem ser usados para medir o tempo necessário para restauração e recuperação.
1. **Notifique as partes interessadas** se a validação de dados falhar ou se o tempo necessário para restauração e recuperação exceder o RTO estabelecido para a workload. Ao implementar a automação para fazer isso, [como neste laboratório](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), é possível usar serviços como o Amazon Simple Notification Service (Amazon SNS) para enviar notificações por push, como e-mail ou SMS, para as partes interessadas. [Essas mensagens também podem ser publicadas em aplicativos de mensagens, como o Amazon Chime, o Slack ou o Microsoft Teams,](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) ou usadas para [criar tarefas como OpsItems usando o AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Automatize este processo para ser executado periodicamente**. Por exemplo, serviços como o AWS Lambda ou uma máquina de estado no AWS Step Functions podem ser usados para automatizar os processos de restauração e recuperação, e é possível usar o Amazon EventBridge para acionar esse fluxo de trabalho de automação periodicamente, conforme mostrado no diagrama de arquitetura abaixo. Saiba como [Automatizar validação de recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Além disso, o [laboratório do Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornece uma experiência prática em como automatizar várias das etapas aqui.
![\[Diagrama mostrando um processo de backup e restauração automatizado\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Nível de esforço para o plano de implementação:** De moderado a alto dependendo da complexidade do critério de validação.
## Recursos
**Documentos relacionados:**
+ [Automatizar validação de recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: produtos que podem ser usados para backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Criar uma regra do EventBridge que é acionada de acordo com uma programação](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: teste de backup e restauração de dados](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 Como usar o isolamento de falhas para proteger sua carga de trabalho?
Os limites isolados de falhas restringem o efeito de uma falha em uma carga de trabalho a um número controlado de componentes. A falha não afeta os componentes fora do limite. Ao usar vários limites isolados de falhas, você pode restringir o impacto sobre sua carga de trabalho.
**Topics**
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Automatizar a recuperação de componentes restritos a um único local](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Implantar a workload em vários locais
Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou por Regiões da AWS, quando necessário. A diversidade dos locais pode variar conforme a necessidade.
Um dos princípios fundamentais do design de serviço na AWS é evitar pontos únicos de falha em infraestrutura física subjacente. Isso nos motiva a criar software e sistemas que usam várias zonas de disponibilidade e são resilientes à falha de uma única zona. De modo similar, os sistemas são criados para serem resilientes à falha de um único nó de computação, volume de armazenamento ou instância de um banco de dados. Ao criar um sistema que dependa de componentes redundantes, é importante garantir que os componentes operem de modo independente e, no caso de Regiões da AWS, de modo autônomo. Os benefícios obtidos com cálculos teóricos de disponibilidade com componentes redundantes só serão válidos se isso for verdadeiro.
**Zonas de disponibilidade (AZ)**
As Regiões da AWS são compostas de várias zonas de disponibilidade projetadas para serem independentes umas das outras. Cada zona de disponibilidade é separada por uma grande distância física de outras zonas para evitar cenários de falha correlacionados devido a riscos ambientais, como incêndios, enchentes e tornados. Cada zona de disponibilidade tem uma infraestrutura física independente: conexões dedicadas à rede elétrica, fontes de alimentação de reserva independentes, serviços mecânicos independentes e conectividade de rede independente dentro e além da zona de disponibilidade. O design limita as falhas em qualquer um desses sistemas apenas à AZ afetada. Apesar de estarem geograficamente separadas, as zonas de disponibilidade estão localizadas na mesma área regional, permitindo uma rede de alto throughput e baixa latência. Toda a Região da AWS (em todas as zonas de disponibilidade, consistindo em vários datacenters fisicamente independentes) pode ser tratada como um único destino de implantação lógica para a workload, incluindo a capacidade de replicar dados de forma síncrona (por exemplo, entre bancos de dados). Assim, você pode usar as zonas de disponibilidade em uma configuração ativa/ativa ou ativa/em espera.
As zonas de disponibilidade são independentes e, portanto, a disponibilidade da workload aumenta quando ela é projetada para usar várias zonas. Alguns serviços da AWS (incluindo o plano de dados da instância do Amazon EC2) são implantados como serviços estritamente zonais, compartilhando o destino com a zona de disponibilidade em que estão. No entanto, as instâncias do Amazon EC2 nas outras AZs não serão afetadas e continuarão funcionando. Da mesma forma, se uma falha em uma zona de disponibilidade fizer com que um banco de dados do Amazon Aurora falhe, uma instância do Aurora de réplica de leitura em uma AZ não afetada poderá ser promovida automaticamente para primária. Entretanto, os serviços da AWS regionais (como o Amazon DynamoDB) usam várias zonas de disponibilidade em uma configuração ativa/ativa para atingir as metas de design de disponibilidade para aquele serviço, sem a necessidade de configurar o posicionamento da AZ.
![\[Diagrama mostrando arquitetura multicamada implantada em três zonas de disponibilidade. Observe que o Amazon S3 e o Amazon DynamoDB são sempre multi-AZ automaticamente. O ELB também é implantado em todas as três zonas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Embora os ambientes de gerenciamento da AWS costumem permitir o gerenciamento de recursos dentro de toda a região (várias zonas de disponibilidade), determinados ambientes (incluindo o Amazon EC2 e o Amazon EBS) podem filtrar os resultados para uma única zona de disponibilidade. Quando isso é feito, a solicitação é processada apenas na zona de disponibilidade especificada, o que reduz a exposição a interrupções em outras zonas de disponibilidade. Veja um exemplo da AWS CLI que ilustra como obter informações da instância do Amazon EC2 apenas da zona de disponibilidade us-east-2c:
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*Zonas locais da AWS*
Zonas locais da AWS atuam de forma semelhante às zonas de disponibilidade nas suas respectivas Região da AWS, pois elas podem ser selecionadas como um local de posicionamento para recursos zonais da AWS, como sub-redes e instâncias do EC2. O que as torna especiais é que elas estão localizadas não na Região da AWS associada, mas perto de grandes centros populacionais, industriais e de TI onde não existe nenhuma Região da AWS atualmente. No entanto, elas ainda mantêm uma conexão segura e de alta largura de banda entre as workloads locais na zona local e as executadas na Região da AWS. Você deve usar as zonas locais da AWS para implantar workloads mais perto dos seus usuários para requisitos de baixa latência.
**Amazon Global Edge Network**
A Amazon Global Edge Network consiste em locais da borda em cidades ao redor do mundo. O Amazon CloudFront usa essa rede para entregar conteúdo aos usuários finais com menor latência. O AWS Global Accelerator permite criar endpoints de workload nesses locais da borda para fornecer integração à rede global da AWS próxima aos seus usuários. O Amazon API Gateway habilita endpoints de API otimizados para borda usando uma distribuição do CloudFront para facilitar o acesso do cliente por meio do local da borda mais próximo.
*Regiões da AWS*
As Regiões da AWS foram projetadas para serem autônomas. Portanto, para usar uma abordagem multirregional, você pode implantar cópias dedicadas de serviços em cada região.
Uma abordagem multirregional é comum para estratégias de *recuperação de desastres* atenderem aos objetivos de recuperação quando ocorrem eventos pontuais de grande escala. Perceber [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) para obter mais informações sobre essas estratégias. No entanto, aqui focaremos na *disponibilidade*, que busca entregar um objetivo de tempo de atividade médio ao longo do tempo. Para objetivos de alta disponibilidade, geralmente uma arquitetura multirregional será projetada para ser ativa/ativa, onde cada cópia de serviço (nas suas respectivas regiões) está ativa (atendimento a solicitações).
**Recomendação**
Os objetivos de disponibilidade para a maioria das workloads podem ser cumpridos usando uma estratégia multi-AZ em uma única Região da AWS. Considere arquiteturas multirregionais somente quando as workloads tiverem requisitos de disponibilidade extrema ou outros objetivos de negócios que exijam uma arquitetura multirregional.
A AWS oferece a capacidade de operar serviços entre regiões. Por exemplo, a AWS fornece replicação contínua e assíncrona de dados usando replicação do Amazon Simple Storage Service (Amazon S3), réplicas de leitura do Amazon RDS (incluindo réplicas de leitura do Aurora) e tabelas globais do Amazon DynamoDB. Com a replicação contínua, as versões dos dados estão disponíveis para uso quase imediato em cada uma das suas regiões ativas.
Ao usar o AWS CloudFormation, você pode definir a infraestrutura e implantá-la de forma consistente em todas as Contas da AWS e Regiões da AWS. O AWS CloudFormation StackSets estende essa funcionalidade, permitindo que criar, atualizar ou excluir pilhas do AWS CloudFormation em várias contas e regiões com uma única operação. Para implantações de instância do Amazon EC2, uma imagem de máquina da Amazon (AMI) é usada para fornecer informações como configuração de hardware e software instalado. É possível implementar um pipeline do construtor de imagem do Amazon EC2 que cria as AMIs necessárias e as copia para as regiões ativas. Isso garante que essas *AMIs de referência (golden)* tenham o necessário para implantar e expandir a workload em cada nova região.
Para rotear o tráfego, o Amazon Route 53 e o AWS Global Accelerator permitem a definição de políticas que determinam os usuários que vão para cada endpoint regional ativo. Com o Global Accelerator, você define uma discagem de tráfego para controlar a porcentagem do tráfego que é direcionado para cada endpoint da aplicação. O Route 53 é compatível com a abordagem de porcentagem e com várias outras políticas disponíveis, incluindo as baseadas em geoproximidade e latência. O Global Accelerator aproveita automaticamente a extensa rede de servidores de borda da AWS para integrar o tráfego à estrutura da rede da AWS o mais rápido possível, resultando em menores latências de solicitação.
Todos esses recursos operam de forma a preservar a autonomia de cada região. Há poucas exceções a essa abordagem, incluindo nossos serviços que fornecem entrega global de borda (como o Amazon CloudFront e o Amazon Route 53), juntamente com o ambiente de gerenciamento para o serviço AWS Identity and Access Management (IAM). A maioria dos serviços opera totalmente dentro de uma única região.
**Datacenter no local**
Para workloads executadas em um datacenter on-premises, arquitete uma experiência híbrida quando possível. O AWS Direct Connect fornece uma conexão de rede dedicada entre o local e a AWS, permitindo que você execute em ambos.
Outra opção é executar a infraestrutura e os serviços da AWS on-premises usando o AWS Outposts. O AWS Outposts é um serviço totalmente gerenciado que estende a infraestrutura da AWS, os serviços da AWS, as APIs e as ferramentas para o seu datacenter. A mesma infraestrutura de hardware usada na Nuvem AWS é instalada no seu datacenter. O AWS Outposts é então conectados à Região da AWS mais próxima. Em seguida, você pode usar AWS Outposts para oferecer suporte a cargas de trabalho com baixa latência ou requisitos de processamento de dados locais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Use várias zonas de disponibilidade e Regiões da AWS. Distribua os dados e os recursos da workload por várias zonas de disponibilidade ou por Regiões da AWS, quando necessário. A diversidade dos locais pode variar conforme a necessidade.
+ Os serviços regionais são inerentemente implantados nas zonas de disponibilidade.
+ Isso inclui o Amazon S3, o Amazon DynamoDB e o AWS Lambda (quando não conectados a uma VPC).
+ Implemente suas cargas de trabalho baseadas em contêiner, instância e função em várias zonas de disponibilidade. Use datastores multizona, incluindo caches. Use os recursos do EC2 Auto Scaling, o posicionamento de tarefas do ECS, a configuração da função do AWS Lambda ao executá-lo na sua VPC e clusters do ElastiCache.
+ Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling.
+ [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Configuração de uma função do AWS Lambda para acessar recursos em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling.
+ [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Use os parâmetros de posicionamento de tarefas do ECS, especificando grupos de sub-rede do banco de dados.
+ [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Use sub-redes em várias zonas de disponibilidade ao configurar uma função para executar na sua VPC.
+ [Configuração de uma função do AWS Lambda para acessar recursos em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Use várias zonas de disponibilidade com os clusters do ElastiCache.
+ [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Se a workload precisar ser implantada em várias regiões, escolha uma estratégia multirregional. A maioria das necessidades de confiabilidade pode ser atendida em uma única Região da AWS usando uma estratégia de várias zonas de disponibilidade. Use uma estratégia multirregional quando necessário para atender às suas demandas empresariais.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ O backup para outra Região da AWS pode servir como mais uma camada visando garantir que os dados estejam disponíveis quando necessário.
+ Algumas workloads têm requisitos regulamentares que exigem o uso de uma estratégia multirregional.
+ Avalie o AWS Outposts para a workload. Se a carga de trabalho exigir baixa latência do datacenter no local ou tiver requisitos de processamento de dados locais. Em seguida, execute a infraestrutura e os serviços da AWS on-premises usando o AWS Outposts
+ [O que é o AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Determine se as zonas locais da AWS ajudam você a fornecer serviços aos usuários. Se você tiver requisitos de baixa latência, veja se as zonas locais da AWS estão próximas dos seus usuários. Se estiverem, use-as para implantar as workloads mais próximas desses usuários.
+ [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Recursos
**Documentos relacionados:**
+ [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Exemplo: distribuição de instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Uso de bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Série de blogs sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [O que é o AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais
## Resultado desejado
Para alta disponibilidade, sempre (que possível) implante os componentes da workload em várias zonas de disponibilidade (AZs), conforme mostrado na figura 10. Para workloads com requisitos de resiliência extrema, avalie cuidadosamente as opções para uma arquitetura multirregional.
![\[Diagrama mostrando uma implantação de banco de dados resiliente com backup para outra região da AWS\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Antipadrões comuns:
+ Projetar uma arquitetura multirregional quando uma arquitetura multi-AZ seria suficiente para atender aos requisitos.
+ Não contabilizar as dependências entre os componentes da aplicação caso os requisitos de resiliência e de vários locais forem diferentes entre esses componentes.
## Benefícios do estabelecimento desta prática recomendada:
Para resiliência, você deve usar uma abordagem que construa camadas de defesa. Uma camada protege contra interrupções menores e mais comuns criando uma arquitetura altamente disponível usando várias AZs. Outra camada de defesa destina-se a proteger contra eventos raros, como desastres naturais generalizados e interrupções em nível regional. Essa segunda camada envolve arquitetar a aplicação para abranger várias Regiões da AWS.
+ A diferença entre as disponibilidades de 99,5% e 99,99% é superior a 3,5 horas por mês. A disponibilidade esperada de uma workload só pode atingir “quatro noves” se estiver em várias AZs.
+ Ao executar a workload em várias AZs, é possível isolar falhas de energia, refrigeração, rede e a maioria dos desastres naturais, como incêndio e inundação.
+ A implementação de uma estratégia multirregional para a workload ajuda a protegê-la contra desastres naturais generalizados, que afetam uma grande área geográfica de um país, ou falhas técnicas de escopo regional. Esteja ciente de que a implementação de uma arquitetura multirregional pode ser complexa e, geralmente, não é necessária para a maioria das workloads.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
Para um evento de desastre baseado em interrupção ou perda parcial de uma zona de disponibilidade, implementar uma workload altamente disponível em várias zonas de disponibilidade em uma única Região da AWS ajuda a atenuar os desastres naturais e técnicos. Cada Região da AWS é composta por várias zonas de disponibilidade, cada uma isolada de falhas nas outras zonas e separadas por uma distância significativa. No entanto, para um evento de desastre que inclua o risco de perder vários componentes da zona de disponibilidade, distantes umas das outras de forma significativa, deve-se implementar opções de recuperação de desastres para atenuar as falhas de escopo regional. Para workloads que exigem resiliência extrema (infraestrutura crítica, aplicações relacionados à integridade, infraestrutura do sistema financeiro etc.), pode ser necessária uma estratégia multirregional.
## Etapas da implementação
1. Avalie a workload e determine se as necessidades de resiliência podem ser atendidas por uma abordagem multi-AZ (Região da AWS única) ou se elas requerem uma abordagem multirregional. A implementação de uma arquitetura multirregional para atender a esses requisitos introduzirá complexidade adicional, portanto, considere cuidadosamente seu caso de uso e seus requisitos. Os requisitos de resiliência quase sempre podem ser atendidos usando uma única Região da AWS. Considere os seguintes requisitos possíveis ao determinar a necessidade de usar várias regiões:
1. **Recuperação de desastres (DR)**: para um evento de desastre baseado em interrupção ou perda parcial de uma zona de disponibilidade, implementar uma workload altamente disponível em várias zonas de disponibilidade em uma única Região da AWS ajuda a atenuar os desastres naturais e técnicos. Para um evento de desastre que inclua o risco de perder vários componentes da zona de disponibilidade, distantes umas das outras de forma significativa, deve-se implementar recuperação de desastres multirregional para atenuar os desastres naturais ou as falhas técnicas de escopo regional.
1. **Alta disponibilidade (AD)**: é possível usar uma arquitetura multirregional (usando várias AZs em cada região) para alcançar uma disponibilidade superior a quatro noves (> 99,99%).
1. **Localização de pilhas**: ao implantar uma workload para um público global, é possível implantar pilhas localizadas em diferentes Regiões da AWS para atender o público nessas regiões. A localização pode incluir idioma, moeda e tipos de dados armazenados.
1. **Proximidade aos usuários:** ao implantar uma workload para um público global, é possível reduzir a latência implantando pilhas em Regiões da AWS perto de onde os usuários finais estão.
1. **Residência de dados**: algumas workloads estão sujeitas a requisitos de residência de dados, em que os dados de determinados usuários devem permanecer dentro das fronteiras de um país específico. Com base na regulamentação em questão, você pode optar por implantar uma pilha inteira ou apenas os dados na Região da AWS dentro dessas fronteiras.
1. Veja alguns exemplos de funcionalidade multi-AZ fornecida pelos serviços da AWS:
1. Para proteger workloads usando o EC2 ou o ECS, implante um Elastic Load Balancer na frente dos recursos de computação. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as íntegras.
1. [Conceitos básicos do Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Conceitos básicos do Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Em caso de instâncias do EC2 executando software comercial pronto para uso que não oferece suporte ao balanceamento de carga, é possível obter uma forma de tolerância a falhas implementando uma metodologia de recuperação de desastre multi-AZ.
1. [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
1. Para tarefas do Amazon ECS, implante seu serviço uniformemente em três AZs para alcançar um equilíbrio entre disponibilidade e custo.
1. [Práticas recomendadas de disponibilidade do Amazon ECS \$1 Contêineres](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Para os que não são Aurora Amazon RDS, você pode escolher multi-AZ como uma opção de configuração. Em caso de falha da instância de banco de dados primário, o Amazon RDS promove automaticamente um banco de dados em espera para receber o tráfego em outra zona de disponibilidade. Também é possível criar réplicas de leitura multirregionais para melhorar a resiliência.
1. [Implantações multi-AZ do Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Criação de uma réplica de leitura em uma Região da AWS diferente](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Veja alguns exemplos de funcionalidade multirregional fornecida pelos serviços da AWS:
1. Para workloads do Amazon S3, em que a disponibilidade multi-AZ é fornecida automaticamente pelo serviço, considere os pontos de acesso multirregionais se for necessária uma implantação multirregional.
1. [Pontos de acesso multirregionais no Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Para tabelas do DynamoDB, em que a disponibilidade multi-AZ é fornecida automaticamente pelo serviço, é possível converter tabelas existentes em tabelas globais para aproveitar várias regiões.
1. [Conversão de tabelas de região única do Amazon DynamoDB em tabelas globais](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Se a workload for liderada pelo Application Load Balancers ou pelo Network Load Balancers, use o AWS Global Accelerator para melhorar a disponibilidade da aplicação direcionando o tráfego para várias regiões que contenham endpoints íntegros.
1. [Endpoints para aceleradores padrão no AWS Global Accelerator – AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Para aplicações que utilizam o AWS EventBridge, considere os barramentos entre regiões para encaminhar eventos para outras regiões selecionadas.
1. [Envio e recebimento de eventos do Amazon EventBridge entre Regiões da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Para bancos de dados do Amazon Aurora, considere os bancos de dados globais do Aurora, que abrangem várias regiões da AWS. Os clusters existentes também podem ser modificados para adicionar novas regiões.
1. [Conceitos básicos dos bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Se a workload incluir chaves de criptografia do AWS Key Management Service (AWS KMS), considere se as chaves multirregionais são apropriadas para a aplicação.
1. [Chaves multirregionais no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Para recursos de outros serviços da AWS, consulte [Série sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**Nível de esforço para o plano de implementação: **Moderado a alto
## Recursos
**Documentos relacionados:**
+ [Série sobre a criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo-ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Perguntas frequentes sobre zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Arquitetura de recuperação de desastres (DR) na AWS, parte I: estratégias de recuperação na nuvem](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Recuperação de desastres é diferente na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: arquitetura multirregional de alta disponibilidade que escala a até mais de 1,5 bilhão de logins por mês com failover automático](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Exemplos relacionados:**
+ [Arquitetura de recuperação de desastres (DR) na AWS, parte I: estratégias de recuperação na nuvem](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC alcança resiliência muito além do que conseguem em ambiente on-premises](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group usa uma arquitetura multirregional e de várias zonas de disponibilidade com um serviço de DNS proprietário para adicionar resiliência às aplicações](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: recuperação de desastres para Kafka multirregional](https://eng.uber.com/kafka/)
+ [Netflix: ativo-ativo para resiliência multirregional](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Como criamos residência de dados para o Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax executa em duas regiões](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Automatizar a recuperação de componentes restritos a um único local
Se os componentes da workload só puderem ser executados em uma única zona de disponibilidade ou em um datacenter on-premises, você deverá implementar capacidade suficiente para fazer uma recompilação completa da workload de acordo com os objetivos de recuperação definidos.
Se a melhor prática para implantar a carga de trabalho em vários locais não for possível devido a restrições tecnológicas, você deverá implementar um caminho alternativo para a resiliência. Você deve automatizar a capacidade de recriar a infraestrutura necessária, reimplantar aplicativos e recriar os dados necessários para esses casos.
Por exemplo, o Amazon EMR executa todos os nós de um determinado cluster na mesma zona de disponibilidade, pois a execução de um cluster na mesma zona melhora a performance dos fluxos de trabalho, pois fornece uma taxa de acesso a dados mais alta. Se esse componente for necessário para a resiliência da workload, você deverá ter uma maneira de reimplantar o cluster e seus dados. Além disso, para o Amazon EMR, você deve provisionar redundância de maneiras diferentes de usar o multi-AZ. Você pode provisionar [vários nós](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Com o uso do [Sistema de arquivos do EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), os dados no EMR podem ser armazenados no Amazon S3, que podem ser replicados em várias zonas de disponibilidade ou Regiões da AWS.
Da mesma forma, o Amazon Redshift, por padrão, provisiona o cluster em uma zona de disponibilidade escolhida aleatoriamente dentro da Região da AWS selecionada. Todos os nós de cluster são provisionados na mesma zona.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Implemente a autorreparação. Quando possível, use a escalabilidade automática para implantar instâncias ou contêineres. Quando não for possível, use a recuperação automática de instâncias do EC2 ou implemente a automação de autorreparação com base nos eventos de ciclo de vida do contêiner do Amazon EC2 ou do ECS.
+ Use os grupos de Auto Scaling para instâncias e cargas de trabalho de contêiner que não têm requisitos de endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
+ [O que é o EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Escalabilidade automática do serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ É possível usar os dados do usuário da configuração de execução para implementar uma automação capaz de fazer a autorreparação da maioria das cargas de trabalho.
+ Use a recuperação automática de instâncias do EC2 para cargas de trabalho que exigem um endereço do ID de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
+ [Recupere sua instância.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada.
+ Use os eventos de ciclo de vida da instância do EC2 ou os eventos do ECS para automatizar a autorreparação quando a escalabilidade automática ou a recuperação do EC2 não puder ser usada.
+ [Ganchos do ciclo de vida do EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Use os eventos para chamar a automação que recuperará seu componente de acordo com a lógica do processo necessária.
## Recursos
**Documentos relacionados:**
+ [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Ganchos do ciclo de vida do EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Recupere sua instância.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Escalabilidade automática do serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [O que é o EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto
Assim como os anteparos de um navio, esse padrão garante que uma falha seja contida em um pequeno subconjunto de solicitações ou clientes para que o número de solicitações prejudicadas seja limitado e a maioria possa continuar sem erros. Geralmente, os anteparos de dados são chamados de partições, enquanto os anteparos de serviços são conhecidos como células.
Em uma *arquitetura baseada em células*, cada célula é uma instância completa e independente do serviço e tem um tamanho máximo fixo. À medida que a carga aumenta, as cargas de trabalho também aumenta por meio da adição de células. Uma chave de partição é usada no tráfego de entrada para determinar qual célula processará a solicitação. Qualquer falha é contida na única célula em que ela ocorre. Assim, o número de solicitações prejudicadas é limitado, e as outras células continuam sem erros. É importante identificar a chave de partição adequada para minimizar as interações entre células e evitar a necessidade de envolver serviços de mapeamento complexos em cada solicitação. Os serviços que exigem mapeamento complexo acabam apenas transferindo o problema para os serviços de mapeamento, enquanto os serviços que exigem interações entre células criam dependências entre células (e, assim, reduzem as melhorias de disponibilidade esperadas desse processo).
![\[Diagrama mostrando arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Em sua publicação no blog da AWS, Colm MacCarthaigh explica como o Amazon Route 53 usa o conceito de [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) para isolar as solicitações do cliente em fragmentos. Neste caso, um fragmento consiste em duas ou mais células. Com base na chave de partição, o tráfego de um cliente (ou recursos, ou o que você deseja isolar) é roteado para o fragmento atribuído. No caso de oito células com duas células por fragmento e clientes divididos entre os quatro fragmentos, 25% dos clientes terão impacto no caso de um problema.
![\[Diagrama mostrando serviço dividido em fragmentos tradicionais\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Com a fragmentação aleatória, você cria fragmentos virtuais de duas células cada e atribui seus clientes a um desses fragmentos virtuais. Quando ocorre um problema, você ainda pode perder um quarto de todo o serviço, mas a maneira como clientes ou recursos são atribuídos significa que o escopo do impacto com fragmentação aleatória é consideravelmente menor que 25%. Com oito células, há 28 combinações exclusivas de duas células, o que significa que há 28 possíveis fragmentos embaralhados (fragmentos virtuais). Se você tiver centenas ou milhares de clientes e atribuir cada cliente a um fragmento embaralhado, o escopo do impacto devido a um problema será apenas 1/28. Isso é sete vezes melhor do que a fragmentação normal.
![\[Diagrama mostrando serviço dividido em fragmentos aleatórios.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Um fragmento pode ser usado para servidores, filas ou outros recursos, além de células.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Use arquiteturas de anteparo. Assim como os anteparos de um navio, esse padrão garante que uma falha seja contida em um pequeno subconjunto de solicitações ou usuários de modo que o número de solicitações prejudicadas seja limitado, e a maioria possa continuar sem erros. Geralmente, os anteparos de dados são chamados de partições, enquanto os anteparos de serviços são conhecidos como células.
+ [Laboratório do Well-Architected: isolamento de falhas com fragmentação aleatória](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ Avalie a arquitetura baseada em células da workload. Em uma arquitetura baseada em células, cada célula é uma instância completa e independente do serviço e tem um tamanho máximo fixo. À medida que a carga aumenta, as cargas de trabalho também aumenta por meio da adição de células. Uma chave de partição é usada no tráfego de entrada para determinar qual célula processará a solicitação. Qualquer falha é contida na única célula em que ela ocorre. Assim, o número de solicitações prejudicadas é limitado, e as outras células continuam sem erros. É importante identificar a chave de partição adequada para minimizar as interações entre células e evitar a necessidade de envolver serviços de mapeamento complexos em cada solicitação. Os serviços que exigem mapeamento complexo acabam apenas transferindo o problema para os serviços de mapeamento, enquanto os serviços que exigem interações entre células reduzem a autonomia das células (e, assim, as melhorias de disponibilidade esperadas desse processo).
+ Em sua publicação no blog da AWS, Colm MacCarthaigh explica como o Amazon Route 53 usa o conceito de fragmentação aleatória para isolar as solicitações do cliente em fragmentos.
+ [Fragmentação aleatória: isolamento de falhas massivo e mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Recursos
**Documentos relacionados:**
+ [Fragmentação aleatória: isolamento de falhas massivo e mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [A Amazon Builders’ Library: isolamento de workload usando a fragmentação aleatória](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: isolamento de falhas com fragmentação aleatória](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 Como você projeta sua carga de trabalho para resistir a falhas de componentes?
As cargas de trabalho que exigem alta disponibilidade e baixo Tempo médio até a recuperação (MTTR) devem ser projetadas visando a resiliência.
**Topics**
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover para recursos íntegros](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Usar a estabilidade estática para evitar o comportamento bimodal](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Monitorar todos os componentes da workload para detectar falhas
Monitore constantemente a integridade da workload para que você e seus sistemas automatizados detectem degradações ou falhas assim que elas ocorrerem. Monitore os Key Performance Indicators (KPIs – Indicadores-chave de performance) com base no valor empresarial.
Todos os mecanismos de reparo e recuperação devem começar com a capacidade de detectar problemas rapidamente. As falhas técnicas devem ser detectadas primeiro para que possam ser resolvidas. No entanto, a disponibilidade é baseada na capacidade da workload em entregar valor empresarial, portanto, os indicadores-chave de performance (KPIs) que medem isso precisam fazer parte da sua estratégia de detecção e remediação.
**Antipadrões comuns:**
+ Nenhum alarme foi configurado, portanto as interrupções ocorrem sem notificação.
+ Os alarmes existem, mas com limites que não permitem um tempo adequado para reação.
+ As métricas não são coletadas com frequência suficiente para atender ao Recovery Time Objective (RTO – Objetivo do tempo de recuperação).
+ Dentre os níveis da carga de trabalho, somente aquele voltado ao cliente é monitorado ativamente.
+ Coleta apenas das métricas técnicas, não das métricas de função de negócios.
+ Não há métricas que medem a experiência do usuário da carga de trabalho.
**Benefícios do estabelecimento dessa prática recomendada:** O monitoramento adequado de todas as camadas reduz o tempo de detecção e, assim, permite reduzir o tempo de recuperação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Determine o intervalo de coleta dos componentes com base nas suas metas de recuperação.
+ O intervalo de monitoramento depende da rapidez com que você precisa fazer a recuperação. O tempo de recuperação é determinado pelo tempo necessário para a recuperação. Desse modo, você deve considerar esse tempo e o RTO para determinar a frequência da coleta.
+ Configure o monitoramento detalhado dos componentes.
+ Determine se o monitoramento detalhado das instâncias do EC2 e do Auto Scaling é necessário. O monitoramento detalhado fornece métricas de intervalo de 1 minuto, e o monitoramento padrão fornece métricas de intervalo de 5 minutos.
+ [Habilitar ou desabilitar o monitoramento detalhado de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoramento de grupos do Auto Scaling e instâncias usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determine se o monitoramento avançado para RDS é necessário. O monitoramento avançado usa um agente nas instâncias do RDS para obter informações úteis sobre processos ou threads diferentes em uma instância do RDS.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Crie métricas personalizadas para medir os indicadores-chave de performance (KPIs) de negócios. As cargas de trabalho implementam as principais funções de negócios. Essas funções devem ser usadas como KPIs que ajudam a identificar quando ocorre um problema indireto.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Use os canários de usuário para monitorar falhas na experiência do usuário. O teste de transações sintéticas (também conhecido como teste canário, que não deve ser confundido com as implantações canário) que pode executar e simular o comportamento do cliente está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da carga de trabalho de diversos locais remotos.
+ [O Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Crie métricas personalizadas que acompanham a experiência do usuário. Se você puder estabelecer instrumentos de medição da experiência do cliente, conseguirá determinar o momento de degradação da experiência do consumidor.
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Defina alarmes para detectar quando uma parte da carga de trabalho não estiver funcionando corretamente e indicar quando deve ser feita a escalabilidade automática dos recursos. É possível exibir os alarmes em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala verticalmente dos recursos de uma workload.
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Crie painéis para visualizar as métricas. É possível usar os painéis para ver as tendências, os casos atípicos e outros indicadores de possíveis problemas ou para obter uma indicação de problemas a serem investigados.
+ [Uso de painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Recursos
**Documentos relacionados:**
+ [O Amazon CloudWatch Synthetics permite criar canários de usuário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Habilitar ou desabilitar o monitoramento detalhado de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoramento de grupos do Auto Scaling e instâncias usando o Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover para recursos íntegros
Verifique se, caso ocorra uma falha de recurso, os recursos íntegros podem continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para executar failover para recursos íntegros em locais sem problemas.
Os serviços da AWS, como o Elastic Load Balancing e o AWS Auto Scaling, ajudam a distribuir carga entre recursos e zonas de disponibilidade. Portanto, a falha de um recurso individual (como uma instância do EC2) ou o comprometimento de uma zona de disponibilidade podem ser atenuados desviando o tráfego para os recursos íntegros restantes. Para as cargas de trabalho multirregionais, o procedimento é mais complicado. Por exemplo, réplicas de leitura entre as regiões permitem implantar os dados em várias Regiões da AWS, mas você ainda deve promover a réplica de leitura a primária e apontar o tráfego para ela em caso de failover. O Amazon Route 53 e o AWS Global Accelerator ajudam a rotear o tráfego entre Regiões da AWS.
Se a workload estiver usando serviços da AWS, como o Amazon S3 ou o Amazon DynamoDB, ela será implantada automaticamente em várias zonas de disponibilidade. Em caso de falha, o ambiente de gerenciamento da AWS roteia automaticamente o tráfego para locais íntegros. Os dados são armazenados de forma redundante em várias zonas de disponibilidade e permanecem disponíveis. Para o Amazon RDS, você deve escolher multi-AZ como opção de configuração e, em caso de falha, a AWS direcionará automaticamente o tráfego para a instância íntegra. Para instâncias do Amazon EC2, tarefas do Amazon ECS ou pods do Amazon EKS, você escolhe em quais zonas de disponibilidade implantar. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as zonas íntegras. O Elastic Load Balancing pode até mesmo rotear o tráfego para componentes no seu datacenter on-premises.
Para abordagens multirregionais (que também podem incluir datacenters on-premises), o Amazon Route 53 oferece uma maneira de definir domínios da Internet e de atribuir políticas de roteamento que podem incluir verificações de integridade para garantir que o tráfego seja roteado para regiões íntegras. Como alternativa, o AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para a aplicação e, em seguida, roteia para endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet para obter melhor performance e confiabilidade.
A AWS aborda o design dos nossos serviços pensando na recuperação de falha. Projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente repositórios de dados que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. Esses serviços e recursos incluem o Amazon Aurora, instâncias de banco de dados multi-AZ doAmazon Relational Database Service (Amazon RDS), o Amazon S3, o Amazon DynamoDB, o Amazon Simple Queue Service (Amazon SQS) e o Amazon Elastic File System (Amazon EFS). Eles são criados para usar isolamento com base em células e usar o isolamento de falhas fornecido por Zonas de disponibilidade. Usamos automação amplamente em nossos procedimentos operacionais. Também otimizamos nossa funcionalidade de substituir e reiniciar para a recuperação rápida de interrupções.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Faça failover para recursos íntegros. Verifique se, caso ocorra uma falha de recurso, os recursos íntegros podem continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para executar failover para recursos íntegros em locais sem problemas.
+ Se a workload estiver usando serviços da AWS, como o Amazon S3 ou o Amazon DynamoDB, ela será implantada automaticamente em várias zonas de disponibilidade. Em caso de falha, o ambiente de gerenciamento da AWS roteia automaticamente o tráfego para locais íntegros.
+ Para o Amazon RDS, você deve escolher multi-AZ como opção de configuração e, em caso de falha, a AWS direcionará automaticamente o tráfego para a instância íntegra.
+ [Alta disponibilidade (multi-AZ) para o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Para instâncias do Amazon EC2 ou tarefas do Amazon ECS, você escolhe em quais Zonas de disponibilidade implantar. Em seguida, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas com problemas de integridade e rotear o tráfego para as zonas íntegras. O Elastic Load Balancing pode até mesmo rotear o tráfego para componentes no seu datacenter on-premises.
+ Para abordagens em várias regiões (que também podem incluir datacenters on-premises), certifique-se de que os dados e os recursos de locais íntegros possam continuar atendendo a solicitações
+ Por exemplo, réplicas de leitura entre as regiões permitem implantar os dados em várias Regiões da AWS, mas você ainda deve promover a réplica de leitura a primária e apontar o tráfego para ela em caso de falha no local primário.
+ [Visão geral das réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ O Amazon Route 53 oferece uma maneira de definir domínios da Internet e de atribuir políticas de roteamento que podem incluir verificações de integridade para garantir que o tráfego seja roteado para regiões íntegras. Como alternativa, o AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para a aplicação e, em seguida, roteia para endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet pública para obter melhor performance e confiabilidade.
+ [Amazon Route 53: escolher uma política de roteamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: escolher uma política de roteamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilidade (multi-AZ) para o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Visão geral das réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Estratégias de posicionamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Criação de grupos de Auto Scaling do Kubernetes para várias zonas de disponibilidade](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [O que é o AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizar a reparação em todas as camadas
Após a detecção de uma falha, use recursos automatizados para executar ações de correção.
*Capacidade de reiniciar* é uma ferramenta importante para corrigir falhas. Como discutido anteriormente para sistemas distribuídos, uma melhor prática é tornar os serviços sem estado sempre que possível. Isso evita a perda de dados ou a disponibilidade na reinicialização. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, instância do EC2 ou função do Lambda) como parte da reinicialização. A reinicialização em si é uma maneira simples e confiável de se recuperar de falhas. Muitos tipos diferentes de falhas ocorrem em cargas de trabalho. As falhas podem ocorrer em hardware, software, comunicações e operações. Em vez de criar mecanismos novos para capturar, identificar e corrigir cada um dos diferentes tipos de falhas, mapeie várias categorias diferentes de falhas para a mesma estratégia de recuperação. Uma instância pode falhar devido a uma falha de hardware, um bug no sistema operacional, vazamento de memória ou outras causas. Em vez de criar uma correção personalizada para cada situação, trate qualquer uma delas como uma falha de instância. Encerre a instância e permita que o AWS Auto Scaling a substitua. Posteriormente, você pode executar a análise do recurso com falha fora de banda.
Outro exemplo é a capacidade de reiniciar uma solicitação de rede. Aplique a mesma abordagem de recuperação tanto a um tempo limite de rede quanto a uma falha de dependência em que a dependência retorna um erro. Ambos os eventos têm um efeito similar sobre o sistema, assim, em vez de tentar tornar qualquer um dos eventos um “caso especial”, aplique uma estratégia similar de nova tentativa limitada com recuo e variação exponenciais.
*Capacidade de reiniciar* é um mecanismo de recuperação destacado em computação orientada à recuperação (ROC) e arquiteturas de cluster de alta disponibilidade.
É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode acionar o AWS Lambda, o AWS Systems Manager Automation ou outros destinos para executar a lógica de correção personalizada na workload.
O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instâncias do EC2. Se a instância estiver em qualquer estado que não seja em execução, ou se o status do sistema for prejudicado, o Amazon EC2 Auto Scaling considerará que essa instância não é íntegra e executará uma instância de substituição. Se estiver usando o AWS OpsWorks, você poderá configurar a autorreparação das instâncias do EC2 no nível da camada do OpsWorks.
Para substituições em grande escala (como a perda de uma Zona de disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade, em vez de tentar obter vários novos recursos de uma só vez.
**Antipadrões comuns:**
+ Implantação de aplicações em instâncias ou contêineres individualmente.
+ Implantação de aplicações que não podem ser implantadas em vários locais sem usar a recuperação automática.
+ Reparação manual de aplicações que não são reparadas por meio da escalabilidade e recuperação automáticas.
**Benefícios do estabelecimento desta prática recomendada:** A reparação automatizada, mesmo que a carga de trabalho só possa ser implantada em um local por vez, reduzirá o tempo médio até a recuperação e garantirá a disponibilidade da carga de trabalho.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Use os grupos de Auto Scaling para implantar níveis em uma workload. O Auto Scaling pode executar a autorreparação em aplicativos sem estado e adicionar e remover capacidade.
+ [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implemente a recuperação automática em instâncias do EC2 que tenham aplicativos implantados que não possam ser implantados em vários locais e possam tolerar a reinicialização em caso de falhas. É possível usar a recuperação automática para substituir o hardware com falha e reiniciar a instância quando o aplicativo não puder ser implantado em vários locais. Os metadados e os endereços IP associados da instância são mantidos, assim como os volumes e pontos de montagem do Amazon EBS para o Elastic File Systems ou File Systems for Lustre e Windows.
+ [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [O que é o Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [O que é o Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Ao usar o AWS OpsWorks, é possível configurar a autorreparação das instâncias do EC2 no nível da camada
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implemente a recuperação automatizada usando o AWS Step Functions e o AWS Lambda quando não for possível usar a escalabilidade ou a recuperação automáticas, ou quando a recuperação automática falhar. Quando não for possível usar a escalabilidade ou a recuperação automáticas ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda.
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode acionar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload.
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: como usar a autorreparação para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Recuperação automática do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Uso de alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [O que é o AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [O que é o Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [O que é o Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Vídeos relacionados:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação
O ambiente de gerenciamento é usado para configurar recursos, e o plano de dados fornece serviços. Os planos de dados geralmente têm metas de design de disponibilidade mais altas do que os ambientes de gerenciamento e costumam ser menos complexos. Ao implementar respostas de recuperação ou mitigação para eventos que possam ter um impacto na resiliência, o uso de operações do ambiente de gerenciamento pode diminuir a resiliência geral da sua arquitetura. Por exemplo, você pode confiar no plano de dados do Amazon Route 53 para rotear consultas ao DNS com base nas verificações de integridade. Porém, a atualização das políticas de roteamento do Route 53 usa o ambiente de gerenciamento, portanto, não conte com ele para a recuperação.
Os planos de dados do Route 53 respondem as consultas ao DNS, além de realizarem e avaliarem verificações de integridade. Eles são distribuídos globalmente e projetados para um [Acordo de Serviço (SLA) de 100% de disponibilidade.](https://aws.amazon.com/route53/sla/) As APIs e consoles de gerenciamento do Route 53 usados para criar, atualizar e excluir recursos do Route 53 são executados em ambientes de gerenciamento projetados para priorizar a consistência e a durabilidade necessária para gerenciar o DNS. Para que isso aconteça, os ambientes de gerenciamento estão localizados em uma única região, US East (N. Virginia). Embora ambos os sistemas sejam construídos para serem muito confiáveis, os ambientes de gerenciamento não estão incluídos no SLA. Pode ser que ocorram raros eventos onde o design resiliente do plano de dados permita que ele mantenha a disponibilidade, enquanto os ambientes de gerenciamento não. Para mecanismos de recuperação de desastres e failover, use funções de plano de dados para fornecer a melhor confiabilidade possível.
Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender destinos de alta disponibilidade, consulte o documento [estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) e a [Amazon Builders’ Library.](https://aws.amazon.com/builders-library/)
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Confie no plano de dados e não no ambiente de gerenciamento ao usar o Amazon Route 53 para recuperação de desastres. O Route 53 Application Recovery Controller ajuda a gerenciar e coordenar o failover usando verificações de prontidão e controles de roteamento. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, zonas de disponibilidade e ambientes on-premises.
+ [O que é o Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Compreenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento.
+ [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
## Recursos
**Documentos relacionados:**
+ [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados)
+ [Plano de dados do AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [O que é o Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Exemplos relacionados:**
+ [Introdução ao Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Usar a estabilidade estática para evitar o comportamento bimodal
O comportamento bimodal é quando a carga de trabalho apresenta um comportamento diferente nos modos normal e de falha, por exemplo, depender da execução de novas instâncias se uma zona de disponibilidade falhar. Em vez disso, você deve criar cargas de trabalho que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona de disponibilidade para processar a carga de trabalho se uma AZ foi removida e use as verificações de integridade do Elastic Load Balancing ou do Amazon Route 53 para remover a carga das instâncias danificadas.
A estabilidade estática para implantação de computação (como instâncias ou contêineres do EC2) resultará na mais alta confiabilidade. Isso deve ser ponderado em relação a preocupações de custo. É mais barato provisionar menos capacidade computacional e contar com a execução de novas instâncias em caso de falha. No entanto, para falhas em grande escala (como uma falha de zona de disponibilidade), essa abordagem é menos eficaz porque depende de reagir a prejuízos à medida que ocorrem, em vez de estar preparada para essas deficiências antes que elas ocorram. Sua solução deve ponderar a confiabilidade em comparação com as necessidades de custo para sua carga de trabalho. Ao usar mais zonas de disponibilidade, a quantidade de computação adicional necessária para a estabilidade estática diminui.
![\[Diagrama mostrando estabilidade estática de instâncias do EC2 em várias zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/static-stability.png)
Depois que o tráfego for deslocado, use o AWS Auto Scaling para substituir de forma assíncrona instâncias da zona com falha e executá-las nas zonas íntegras.
Outro exemplo de comportamento bimodal seria um tempo limite de rede que poderia fazer com que um sistema tentasse atualizar o estado de configuração de todo o sistema. Isso adicionaria uma carga inesperada a outro componente e pode fazê-lo falhar, levando a outras consequências inesperadas. Esse ciclo de comentário negativo afeta a disponibilidade de sua carga de trabalho. Em vez disso, você deve criar sistemas estaticamente estáveis e operar em apenas um modo. Um design estático estável seria fazer um trabalho constante e sempre atualizar o estado da configuração em um ritmo fixo. Quando uma chamada falha, a carga de trabalho usa o valor armazenado em cache anteriormente e aciona um alarme.
Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da carga de trabalho em caso de falhas. Isso pode parecer ser uma solução que acomoda as necessidades do cliente, mas não deve ser permitida porque altera significativamente as demandas em sua carga de trabalho e provavelmente resultará em falhas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Use a estabilidade estática para evitar o comportamento bimodal. O comportamento bimodal é quando a carga de trabalho apresenta um comportamento diferente nos modos normal e de falha, por exemplo, depender da execução de novas instâncias se uma zona de disponibilidade falhar.
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Em vez disso, você deve criar sistemas que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona para processar a workload se uma AZ foi removida e use as verificações de integridade do Elastic Load Balancing ou do Amazon Route 53 para remover a carga das instâncias danificadas.
+ Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da carga de trabalho em caso de falhas. Isso pode parecer uma solução para acomodar as necessidades do cliente, mas não deve ser permitido porque altera significativamente as demandas em sua carga de trabalho e pode resultar em falhas.
## Recursos
**Documentos relacionados:**
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Vídeos relacionados:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
As notificações são enviadas após a detecção de eventos significativos, mesmo que o problema causado pelo evento tenha sido resolvido automaticamente.
A correção automatizada permite que a carga de trabalho seja confiável. No entanto, ele também pode obscurecer problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela correção automática, para que você possa resolver problemas de causa raiz. Alarmes do Amazon CloudWatch podem ser acionados com base em falhas que ocorrem. Eles também podem ser acionados com base em ações de correção automatizadas executadas. Alarmes do CloudWatch podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a integração com o Amazon SNS.
**Antipadrões comuns:**
+ Envio de alarmes sem necessidade de reação.
+ Execução da automação de autorreparação, mas sem notificar que a reparação era necessária.
**Benefícios do estabelecimento dessa prática recomendada:** As notificações de eventos de recuperação garantem que você não ignore problemas que ocorrem com pouca frequência.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Alarmes de indicadores-chave de performance de negócios quando eles excedem um limite baixo. Possuir um alarme de limite baixo nos KPIs de negócios ajuda a saber quando a workload está indisponível ou não funcional.
+ [Criação de um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarmes de eventos que invocam automação de reparação. Você pode invocar diretamente uma API do SNS para enviar notificações com qualquer automação criada.
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Recursos
**Documentos relacionados:**
+ [Criação de um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 Como testar a confiabilidade?
Depois de projetar sua carga de trabalho para resiliência à pressão da produção, o teste é a única maneira de garantir que ela opere conforme projetado e com a resiliência esperada.
**Topics**
+ [REL12-BP01 Usar playbooks para investigar falhas](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Realizar análise pós-incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Testar os requisitos funcionais](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Testar os requisitos de escalabilidade e performance](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Realizar dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Usar playbooks para investigar falhas
Faça a documentação do processo de investigação em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks são as etapas predefinidas executadas para identificar os fatores que contribuem para um cenário de falha. Os resultados de qualquer etapa do processo são usados para determinar as próximas etapas a serem seguidas até que o problema seja identificado ou encaminhado.
O playbook é um planejamento proativo que você deve fazer para poder executar ações reativas com eficácia. Quando cenários de falha não cobertos pelo playbook forem encontrados na produção, resolva primeiro o problema (apague o fogo). Em seguida, volte e veja as etapas que você seguiu para resolver o problema e use-as para adicionar uma nova entrada no playbook.
Observe que playbooks são usados em resposta a incidentes específicos, enquanto runbooks são usados para alcançar resultados específicos. Muitas vezes, runbooks são usados para atividades de rotina e os playbooks são usados para responder a eventos que não são rotineiros.
**Antipadrões comuns:**
+ Planejar a implantação de uma carga de trabalho sem conhecer os processos para diagnosticar problemas ou responder a incidentes.
+ Decisões não planejadas de quais sistemas coletar logs e métricas ao investigar um evento.
+ Não armazenar as métricas e os eventos pelo tempo suficiente para recuperar os dados.
**Benefícios do estabelecimento desta prática recomendada:** Capturar playbooks garante que os processos possam ser seguidos de forma consistente. A codificação dos seus playbooks limita a introdução de erros por atividades manuais. A automação dos playbooks reduz o tempo de resposta a um evento ao eliminar a necessidade de intervenção de membros da equipe ou ao fornecer a eles informações adicionais desde o início da intervenção.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Use playbooks para identificar problemas. Os manuais são processos documentados para investigar problemas. Faça a documentação dos processos em playbooks para permitir respostas consistentes e rápidas em cenários de falha. Os playbooks devem incluir as informações e as diretrizes necessárias para que uma pessoa com as devidas qualificações colete as informações aplicáveis, identifique possíveis fontes de falha, isole as falhas e determine os fatores contribuintes (realize uma análise pós-incidente).
+ Implemente playbooks como código. Execute suas operações como código ao criar scripts de seus playbooks para garantir a consistência e reduzir os erros causados por processos manuais. Os playbooks podem ser compostos por vários scripts representando as diferentes etapas que podem ser necessárias para identificar os fatores que contribuem para um problema. As atividades do runbook podem ser acionadas ou executadas como parte das atividades do playbook, ou podem solicitar a execução de um playbook em resposta a eventos identificados.
+ [Automatizar playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Recursos
**Documentos relacionados:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automatizar playbooks operacionais com o AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Exemplos relacionados:**
+ [Automating operations with Playbooks and Runbooks (Automatização de operações com manuais e runbooks)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Realizar análise pós-incidente
Analise os eventos que afetam o cliente e identifique os fatores contribuintes e os itens de ação preventiva. Use essas informações para desenvolver mitigações para limitar ou evitar recorrência. Desenvolva procedimentos para respostas rápidas e eficazes. Comunique os fatores contribuintes e as ações corretivas conforme apropriado, de acordo com o público-alvo. Tenha um método para comunicar essas causas a outras pessoas, conforme necessário.
Avalie por que os testes existentes não encontraram o problema. Adicione testes para esse caso se os testes ainda não existirem.
**Antipadrões comuns:**
+ Encontrar fatores contribuintes, mas não continuar buscando mais profundamente outros possíveis problemas e abordagens de mitigação.
+ Identificar apenas as causas de erros humanos e não oferecer nenhum treinamento ou automação que possa evitar erros humanos.
**Benefícios do estabelecimento dessa prática recomendada:** A realização de análises pós-incidentes e o compartilhamento dos resultados permitem que outras cargas de trabalho atenuem o risco caso tenham implementado os mesmos fatores contribuintes, além de permitir que elas implementem a mitigação ou a recuperação automatizada antes que ocorra um incidente.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Estabeleça um padrão para sua análise pós-incidente. Uma boa análise pós-incidente oferece oportunidades para propor soluções comuns a problemas com padrões de arquitetura usados em outros locais nos sistemas.
+ Garantir que os fatores contribuintes sejam justos e isentos de acusações.
+ Se você não documentar os problemas, não poderá corrigi-los.
+ Garanta que a análise pós-incidente seja isenta de acusações para que você possa ser imparcial em relação às ações corretivas propostas e promover uma autoavaliação e uma colaboração justas às equipes de aplicativos.
+ Use um processo para determinar fatores contribuintes. Tenha um processo para identificar e documentar os fatores que contribuem para um evento para que você possa desenvolver mitigações a fim de limitar ou impedir a recorrência e elaborar procedimentos para respostas rápidas e eficazes. Comunique os fatores contribuintes conforme apropriado, de acordo com o público-alvo.
+ [O que é análise de log?](https://aws.amazon.com/log-analytics/)
## Recursos
**Documentos relacionados:**
+ [O que é análise de log?](https://aws.amazon.com/log-analytics/)
+ [Por que você deve desenvolver uma correção de erro (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Testar os requisitos funcionais
Use técnicas como testes de unidade e de integração que validam a funcionalidade necessária.
Você obtém os melhores resultados quando esses testes são executados automaticamente como parte das ações de compilação e implantação. Por exemplo, usando o AWS CodePipeline, os desenvolvedores confirmam alterações em um repositório de origem onde o CodePipeline detecta automaticamente as alterações. Essas alterações são criadas e os testes são executados. Após a conclusão dos testes, o código criado é implantado nos servidores de preparação para testes. No servidor de preparação, o CodePipeline executa mais testes, como testes de integração ou carga. Após a conclusão bem-sucedida desses testes, o CodePipeline implanta o código testado e aprovado nas instâncias de produção.
Além disso, a experiência mostra que o teste de transações sintéticas (também conhecido como *teste canário*, que não deve ser confundido com as implantações canário) que pode executar e simular o comportamento do cliente está entre os processos de teste mais importantes. Execute esses testes constantemente nos endpoints da carga de trabalho de diversos locais remotos. O Amazon CloudWatch Synthetics permite [criar canários](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para monitorar seus endpoints e APIs.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Teste os requisitos funcionais. Esse procedimento inclui testes de unidade e de integração que validam a funcionalidade necessária.
+ [Usar o CodePipeline com o AWS CodeBuild para testar código e executar builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Entrega contínua e integração contínua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar na implementação de um pipeline de integração contínua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [O AWS CodePipeline adiciona compatibilidade para testes de unidade e de integração personalizada com o AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: produtos que podem ser usados para integração contínua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Entrega contínua e integração contínua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automação de teste de software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Usar o CodePipeline com o AWS CodeBuild para testar código e executar builds](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Uso de canários (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Testar os requisitos de escalabilidade e performance
Use técnicas como o teste de carga para validar se a workload atende aos requisitos de escalabilidade e performance.
Na nuvem, você pode criar um ambiente de teste em escala de produção sob demanda para sua carga de trabalho. Se você executar esses testes na infraestrutura reduzida, deverá escalar os resultados observados para o que você acha que acontecerá na produção. Os testes de carga e performance também podem ser feitos na produção se você tiver cuidado para não afetar os usuários reais e marcar seus dados de teste para que eles não se sintam com dados reais do usuário e estatísticas de uso corrompidas ou relatórios de produção.
Com os testes, certifique-se de que seus recursos básicos, configurações de escalabilidade, cotas de serviço e design de resiliência operem conforme o esperado sob carga.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Teste os requisitos de escalabilidade e performance. Execute o teste de carga para validar se a carga de trabalho atende aos requisitos de escalabilidade e performance.
+ [Distributed Load Testing on AWS: simulate thousands of connected users (Teste de carga distribuída na AWS: simular milhares de usuários conectados)](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Implante seu aplicativo em um ambiente idêntico ao seu ambiente de produção e execute um teste de carga.
+ Use os conceitos de infraestrutura como código para criar um ambiente que seja o mais semelhante possível ao seu ambiente de produção.
## Recursos
**Documentos relacionados:**
+ [Distributed Load Testing on AWS: simulate thousands of connected users (Teste de carga distribuída na AWS: simular milhares de usuários conectados)](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Testar a resiliência por meio da engenharia do caos
Execute testes de caos regularmente em ambientes que estão em produção, ou muito próximos de entrarem em produção, para entender como seu sistema responde a condições adversas.
** Resultado desejado: **
A resiliência da workload é regularmente verificada por meio da aplicação de engenharia de caos na forma de testes de injeção de falha ou injeção de carga inesperada, além de testes de resiliência que validam o comportamento conhecido esperado da workload durante um evento. Combine engenharia de caos e testes de resiliência para ter confiança de que sua workload poderá sobreviver à falha de componentes e se recuperar de interferências inesperadas com pouco ou nenhum impacto.
** Antipadrões comuns: **
+ Projetar para resiliência, mas não verificar como a workload funciona como um todo quando ocorrem falhas.
+ Nunca realizar testes sob condições reais e carga esperada.
+ Não tratar seus testes como código nem mantê-los ao longo do ciclo de desenvolvimento.
+ Não realizar testes de caos tanto como parte do pipeline de CI/CD quanto fora das implantações.
+ Negar o uso de análises pós-incidentes passadas ao determinar quais falhas usar para realizar testes.
** Benefícios do estabelecimento desta prática recomendada:** A injeção de falhas para verificar a resiliência de uma workload permite que você obtenha confiança de que os procedimentos de recuperação de seu design resiliente vão funcionar em caso de falha real.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação de implementação
A engenharia de caos proporciona à sua equipe os recursos para injetar continuamente interferências (simulações) reais de maneira controlada no provedor de serviço, na infraestrutura, na workload e no componente, com pouco ou nenhum impacto para os clientes. Permite que as equipes aprendam com as falhas e observem, mensurem e aumentem a resiliência das workloads, além de validar o acionamento de alertas e a notificação das equipes em caso de evento.
Quando realizada continuamente, a engenharia de caos pode destacar deficiências nas workloads que, se não respondidas, podem afetar negativamente a disponibilidade e a operação.
**nota**
A engenharia do caos é a disciplina de experimentar um sistema distribuído para aumentar a confiança na capacidade do sistema de resistir a condições turbulentas na produção. – [Princípios da engenharia do caos](https://principlesofchaos.org/)
Se um sistema é capaz de suportar essas interferências, os testes de caos devem ser mantidos como testes de regressão automatizados. Dessa forma, os testes de caos devem ser realizados como parte do ciclo de vida de desenvolvimento dos sistemas (SDLC) e como parte do pipeline de CI/CD.
Para garantir que sua workload pode sobreviver à falha de componentes, injete eventos reais como parte dos testes. Por exemplo, realize testes com perda de instâncias do Amazon EC2 ou failover da instância de banco de dados primária do Amazon RDS e verifique se a workload não é afetada (ou apenas minimamente afetada). Use uma combinação de falhas de componentes para simular eventos que podem ser causados por uma interferência em uma zona de disponibilidade.
Para falhas no nível da aplicação (como travamentos), você pode começar com fatores de estresse, como exaustão de memória e CPU.
Para validar [mecanismos de fallback ou failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) para dependências externas devido a interferências intermitentes na rede, os componentes devem simular esse tipo de evento bloqueando o acesso aos provedores externos durante um período especificado, que pode variar de segundos a horas.
Outros modos de degradação podem levar a uma redução nas funcionalidades e a respostas lentas, muitas vezes levando a uma interrupção dos serviços. Essa degradação costuma resultar de um aumento na latência de serviços críticos e comunicação de rede não confiável (pacotes abandonados). Testes com essas falhas, incluindo efeitos de rede como latência, mensagens perdidas e falhas de DNS, podem incluir a incapacidade de resolver um nome, alcançar o serviço de DNS ou estabelecer conexões com serviços dependentes.
**Ferramentas de engenharia de caos:**
o AWS Fault Injection Service (AWS FIS) é um serviço totalmente gerenciado para a execução de experimentos de injeção de falha que podem ser usados como parte do pipeline de CD, ou fora do pipeline. O AWS FIS é uma boa opção para ser usado durante dias de jogo de engenharia de caos. Oferece suporte à introdução simultânea de falhas em diferentes tipos de recursos, incluindo Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Essas falhas incluem encerramento de recursos, failovers forçados, esgotamento de CPU ou memória, controle de utilização, latência e perda de pacotes. Por ser integrado a alarmes do Amazon CloudWatch, você pode definir condições de parada como barreiras de proteção para reverter um teste se causar impacto inesperado.
![\[Diagrama mostrando que o AWS Fault Injection Service se integra a recursos da AWS para permitir a execução de experimentos de injeção de falha para as workloads.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Existem também várias opções de terceiros para experimentos de injeção de falhas. Elas incluem ferramentas de código aberto, como o [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)e aos [Litmus Chaos](https://litmuschaos.io/), bem como opções comerciais como o Gremlin. Para expandir o escopo de falhas que podem ser injetadas na AWS, o AWS FIS [integra-se ao Chaos Mesh e Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), possibilitando que você coordene fluxos de trabalho de injeção de falhas entre várias ferramentas. Por exemplo, você pode executar um teste de estresse na CPU de um pod usando falhas do Chaos Mesh ou Litmus enquanto encerra uma porcentagem selecionada aleatoriamente de nós de cluster usando ações de falha do AWS FIS.
## Etapas da implementação
+ Determine quais falhas usar para os testes.
Avalie o design de sua workload quanto à resiliência. Tais designs (criados usando as práticas recomendadas do [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) consideram riscos baseados em dependências críticas, eventos passados, problemas conhecidos e requisitos de conformidade. Liste cada elemento do design destinado a manter a resiliência e as falhas que foi projetado para mitigar. Para obter mais informações sobre a criação dessas listas, consulte o [artigo técnico Análise de prontidão operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) que orienta você sobre como criar um processo para impedir a recorrência de incidentes passados. O processo de modos de falhas e análises de efeitos (FMEA) proporciona um framework para realização de análise de falhas em nível de componente e como elas afetam a workload. O FMEA foi descrito em mais detalhes por Adrian Cockcroft em [Failure Modes and Continuous Resilience (Modos de falhas e resiliência contínua)](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Atribua uma prioridade a cada falha.
Comece com uma categorização bruta, como alta, média e baixa. Para avaliar a prioridade, considere a frequência da falha e o impacto da falha na workload total.
Ao considerar a frequência de determinada falha, analise os dados passados para essa workload sempre que disponíveis. Caso contrário, use os dados de outras workloads executadas em ambientes semelhantes.
Ao considerar o impacto de determinada falha, em geral, quanto maior o escopo da falha, maior o impacto. Considere também o design e a finalidade da workload. Por exemplo, a capacidade de acessar os datastores de origem é essencial para uma workload que executa análise e transformação de dados. Nesse caso, priorize testes de falhas de acesso, além de acesso controlado e inserção de latência.
Análises pós-incidente são boas fontes de dados para entender a frequência e o impacto dos modos de falha.
Use a prioridade atribuída para determinar quais falhas escolher para testar primeiro e a sequência para desenvolver novos testes de injeção de falhas.
+ Para cada teste realizado, siga o flywheel de engenharia de caos e resiliência contínua.
![\[Diagrama do flywheel de engenharia de caos e resiliência contínua, mostrando as fases Melhoria, Estado estável, Hipótese, Executar teste e Verificar.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Defina o estado estável como uma saída mensurável de uma workload que indica comportamento normal.
Sua workload apresentará estado estável se estiver operando de maneira confiável e conforme o esperado. Portanto, valide a integridade da workload antes de definir o estado estável. O estado estável nem sempre significa que não há nenhum impacto à workload quando ocorre uma falha, já que determinada porcentagem de falhas pode estar dentro de limites aceitáveis. O estado estável é a linha de base que você vai observar durante o teste, o que vai destacar anomalias se a hipótese definida na próxima etapa não sair conforme o esperado.
Por exemplo, um estado estável de um sistema de pagamentos pode ser definido como o processamento de 300 TPS com taxa de sucesso de 99% e tempo de ida e volta de 500 ms.
+ Formule uma hipótese sobre como a workload vai reagir à falha.
Uma boa hipótese se baseia em como se espera que a workload mitigue a falha para manter o estado estável. A hipótese afirma que para determinado tipo de falha, o sistema ou a workload vai permanecer em estado estável, pois a workload foi projetada com mitigações específicas. O tipo específico de falhas e mitigações deve ser especificado na hipótese.
O modelo a seguir pode ser usado para a hipótese (mas outras palavras também são aceitáveis):
**nota**
Se *falha específica* ocorrer, a workload *nome da workload* vai *descrever os controles de mitigação* para manter *impacto da métrica de negócios ou técnica*.
Por exemplo:
+ Se 20% dos nós no grupo de nós do Amazon EKS forem desativados, a API Transaction Create continuará atendendo ao 99.º percentil das solicitações em menos de 100 ms (estado estável). Os nós do Amazon EKS vão se recuperar em cinco minutos e os pods serão agendados e processarão o tráfego oito minutos depois do início do experimento. Os alertas serão acionados em três minutos.
+ Se ocorrer uma única falha de instância do Amazon EC2, a verificação de integridade do Elastic Load Balancing do sistema de ordem vai fazer com que o Elastic Load Balancing envie solicitações apenas para as instâncias íntegras restantes, enquanto o Amazon EC2 Auto Scaling substitui a instância com falha, mantendo um aumento inferior a 0,01% na quantidade de erros no servidor (5xx) (estado estável).
+ Se a instância de banco de dados primária do Amazon RDS falhar, a workload de coleta de dados da cadeia de suprimentos vai entrar em failover e se conectará à instância de banco de dados de espera do Amazon RDS para manter menos de um minuto de erros de leitura ou gravação de banco de dados (estado estável).
+ Execute o teste injetando a falha.
Um teste deve, por padrão, ser seguro contra falhas e tolerado pela workload. Se você sabe que a workload vai falhar, não execute o teste. A engenharia de caos deve ser usada para encontrar incertezas conhecidas ou desconhecidas. *Incertezas conhecidas* são coisas que você conhece, mas não entende totalmente, enquanto *incertezas desconhecidas* são coisas que você não conhece nem entende totalmente. Realizar testes em uma workload que você sabe que está quebrada não oferecerá novos insights. Seu teste deve ser cuidadosamente planejado, ter um escopo claro do impacto e fornecer um mecanismo de reversão que possa ser aplicado em caso de turbulência inesperada. Se sua devida diligência mostrar que a workload sobreviverá ao teste, prossiga com o teste. Há diversas opções para injetar as falhas. Para workloads na AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) oferece diversas simulações de falhas predefinidas chamadas de [ações](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Você também pode definir ações personalizadas que são executadas no AWS FIS usando [documentos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Nós desencorajamos o uso de scripts personalizados para testes de caos, a menos que os scripts tenham os recursos para entender o estado atual da workload, sejam capazes de emitir logs e ofereçam mecanismos para rollbacks e condições de parada sempre que possível.
Um conjunto de ferramentas ou framework eficaz que ofereça suporte à engenharia de caos deve monitorar o estado atual de um experimento, emitir logs e fornecer mecanismos de rollback para oferecer suporte à execução controlada de um teste. Comece com um serviço estabelecido, como o AWS FIS, que permita que você realize testes com um escopo claramente definido e mecanismos de segurança que reverterão o teste se ele introduzir turbulência inesperada. Para conhecer uma ampla variedade de testes que usam o AWS FIS, consulte também o [laboratório Aplicações resilientes e bem-arquitetadas com engenharia de caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Além disso, o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) vai analisar sua workload e criar testes que você pode escolher para implementação e execução no AWS FIS.
**nota**
Para cada teste, entenda claramente o escopo e seu impacto. Recomendamos que as falhas sejam simuladas primeiro em um ambiente que não seja de produção, antes de serem executadas em produção.
Os testes devem ser executados em produção sob carga real usando [implantações canário](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) que ativam implantações de controle e experimentais no sistema, sempre que viável. A realização de testes durante horários fora de pico é uma boa prática para mitigar o impacto potencial durante o primeiro teste em produção. Além disso, se o uso de tráfego real de clientes for algo muito arriscado, você poderá executar testes usando tráfego sintético na infraestrutura de produção em implantações de controle e experimentais. Quando não for possível usar a produção, realize os testes em ambientes de pré-produção que sejam o mais parecido possível com produção.
Estabeleça e monitore barreiras de proteção para garantir que o teste não afete o tráfego de produção ou outros sistemas além dos limites aceitáveis. Estabeleça condições de parada para interromper um teste se ele atingir um limite definido de uma métrica de barreira de proteção. Isso deve incluir as métricas de estado estável da workload, bem como a métrica em relação aos componentes em que você está injetando a falha. A [monitor sintético](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como canário de usuário) é uma métrica que geralmente deve ser incluída como proxy de usuário. [Condições de parada do AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) são compatíveis como parte do modelo de teste, permitindo até cinco condições de parada por modelo.
Um dos princípios de caos é minimizar o escopo do teste e seu impacto:
embora deva existir uma provisão para algum impacto negativo de curto prazo, é responsabilidade e obrigação do engenheiro de caos garantir que as perdas dos testes sejam minimizadas e contidas.
Um método para verificar o escopo e o impacto potencial é realizar o teste primeiro em um ambiente que não seja de produção, verificando se os limites para as condições de parada são ativados conforme o esperado durante o teste e se há observabilidade em vigor para identificar uma exceção, em vez de testar diretamente em produção.
Ao executar testes de injeção de falhas, verifique se todas as partes responsáveis estão bem informadas. Comunique-se com as equipes adequadas, como equipes de operações, equipes de confiabilidade do serviço e atendimento ao cliente, para avisá-las sobre quando os testes serão realizados e o que esperar. Ofereça a essas equipes ferramentas de comunicação para que informem os responsáveis pela execução do teste caso percebam algum efeito adverso.
Você deve restaurar a workload e seus sistemas subjacentes de volta para o estado íntegro original. Normalmente, o design resiliente da workload vai se autorrestaurar. No entanto, alguns designs de falhas ou testes malsucedidos podem deixar a workload em um estado de falha inesperado. Ao final do teste, você deverá estar ciente disso e restaurar a workload e os sistemas. Com o AWS FIS, você pode definir uma configuração de reversão (também chamada de ação posterior) nos parâmetros de ação. Uma ação posterior restaura o destino para o estado em que estava antes da execução da ação. Independentemente de serem automatizadas (como as que usam o AWS FIS) ou manuais, essas ações posteriores devem fazer parte de um playbook que descreve como detectar e lidar com falhas.
+ Verifique a hipótese.
[Princípios da engenharia do caos](https://principlesofchaos.org/) oferecem a seguinte orientação sobre como verificar o estado estável de sua workload:
Concentre-se na saída mensurável de um sistema, em vez de atributos internos do sistema. As medições dessa saída durante um curto período constituem um proxy do estado estável do sistema. A throughput total do sistema, as taxas de erros e os percentis de latência podem ser métricas de interesse que representam o comportamento do estado estável. Ao focar em padrões de comportamento sistêmicos durante os testes, a engenharia de caos verifica se o sistema de fato funciona em vez de tentar validar como ele funciona.
Nos dois exemplos anteriores, nós incluímos as métricas de estado estável de menos de 0,01% de aumento na quantidade de erros no servidor (5xx) e menos de um minuto de erros de leitura ou gravação de banco de dados.
Os erros 5xx são uma boa métrica, pois são consequência do modo de falha que um cliente da workload vai vivenciar diretamente. A medição dos erros do banco de dados é boa como consequência direta da falha, mas também deve ser complementada com uma medição de impacto para o cliente, como solicitações malsucedidas ou erros apresentados ao cliente. Além disso, inclua um monitor sintético (também conhecido como canário de usuário) em todas as APIs ou URIs acessadas pelo cliente da workload.
+ Melhore o design da workload para agregar resiliência.
Se o estado estável não tiver sido mantido, investigue como o design da workload pode ser melhorado para mitigar a falha, aplicando as práticas recomendadas do [pilar Confiabilidade do AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Orientação e recursos adicionais podem ser encontrados na [AWS Builder’s Library](https://aws.amazon.com/builders-library/), que contém artigos sobre como [melhorar as verificações de integridade](https://aws.amazon.com/builders-library/implementing-health-checks/) ou [implantar repetições sem recuo no código de sua aplicação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre outros.
Depois de implementar essas mudanças, execute o teste novamente (mostrado pela linha pontilhada no flywheel de engenharia de caos) para determinar a eficácia. Se a etapa de verificação indicar que a hipótese é verdadeira, a workload estará em estado estável e o ciclo continuará.
+ Execute testes regularmente.
Um teste de caos é um ciclo, e os testes devem ser realizados regularmente como parte da engenharia de caos. Depois que uma workload cumprir a hipótese do teste, o teste deverá ser automatizado para ser executado continuamente como parte de regressão do pipeline de CI/CD. Para saber como fazer isso, consulte este blog sobre [como executar testes do AWS FIS usando o AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Este laboratório sobre [testes recorrentes do AWS FIS em um pipeline de CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) permite que você trabalhe de maneira prática.
Os testes de injeção de falhas também fazem parte dos dias de jogo (consulte [REL12-BP06 Realizar dias de jogo regularmente](rel_testing_resiliency_game_days_resiliency.md)). Os dias de jogo simulam uma falha ou um evento para verificar sistemas, processos e respostas das equipes. O objetivo é realmente executar as ações que a equipe executaria como se um evento excepcional acontecesse.
+ Capture e armazene os resultados do teste.
Os resultados da injeção de falhas devem ser capturados e persistidos. Inclua todos os dados necessários (como tempo, workload e condições) para poder analisar os resultados e as tendências do teste posteriormente. Exemplos de resultados podem incluir capturas de tela de painéis, despejos em CSV do banco de dados da métrica ou um registro manual dos eventos e das observações do teste. [O registro do teste em log com o AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) pode fazer parte dessa captura de dados.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL08-BP03 Integrar testes de resiliência como parte da sua implantação](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 Testar a implementação de recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [O que é o AWS Fault Injection Service?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [O que é o AWS Resilience Hub?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Princípios da engenharia do caos](https://principlesofchaos.org/)
+ [Engenharia de caos: planejando seu primeiro teste](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Engenharia de resiliência: aprendendo a aceitar falhas](https://queue.acm.org/detail.cfm?id=2371297)
+ [Histórias sobre engenharia de caos](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Implantação canário para testes de caos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316) (AWS re:Invent 2020: teste de resiliência usando engenharia de caos)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1) (AWS re:Invent 2019: melhoria da resiliência com engenharia de caos)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301) (AWS re:Invent 2019: execução da engenharia de caos em um universo de tecnologia sem servidor)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: testes de resiliência do Amazon EC2, Amazon RDS e Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Laboratório Engenharia de caos na AWS](https://chaos-engineering.workshop.aws/en/)
+ [Laboratório Aplicações resilientes e bem-arquitetadas com engenharia de caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Laboratório Caos em tecnologia sem servidor](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Laboratório Mensurar e aumentar a resiliência de sua aplicação com o AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Ferramentas relacionadas: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [plataforma de engenharia de caos Gremlin](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Realizar dias de jogo regularmente
Use os dias de jogo para praticar regularmente seus procedimentos de resposta a eventos e falhas o mais próximo possível da produção (inclusive em ambientes de produção) e com as pessoas que estarão envolvidas nos cenários de falha reais. Os dias de jogo aplicam medidas para garantir que os eventos de produção não afetem os usuários.
Os dias de jogo simulam uma falha ou evento para testar sistemas, processos e respostas das equipes. O objetivo é realmente executar as ações que a equipe executaria como se um evento excepcional acontecesse. Isso ajudará a compreender onde as melhorias podem ser feitas e pode ajudar a desenvolver experiência organizacional ao lidar com eventos. Eles devem ser realizados regularmente para que a equipe desenvolva *memória muscular* sobre como responder.
Depois que o projeto de resiliência estiver em vigor e tiver sido testado em ambientes que não sejam de produção, um dia de jogo será a maneira de garantir que tudo funcione conforme o planejado na produção. Um dia de jogo, especialmente o primeiro, é uma atividade de "todos os funcionários" em que engenheiros e operações são informados quando isso acontecerá e o que ocorrerá. Há runbooks disponíveis. Os eventos simulados são executados, incluindo possíveis eventos de falha, nos sistemas de produção da maneira prescrita, e o impacto é avaliado. Se todos os sistemas operarem conforme projetado, a detecção e a recuperação automática ocorrerão com pouco ou nenhum impacto. No entanto, se houver impacto negativo, o teste será revertido e os problemas da workload serão corrigidos manualmente, se necessário (usando o runbook). Como os dias de jogos ocorrem na produção, todas as precauções devem ser tomadas para garantir que não haja impacto na disponibilidade dos clientes.
**Antipadrões comuns:**
+ Documentar seus procedimentos, mas nunca os praticar.
+ Não incluir os tomadores de decisão de negócios nos exercícios de teste.
**Benefícios do estabelecimento desta prática recomendada:** A realização frequente dos dias de jogo garante que toda a equipe siga e valide as políticas e os procedimentos apropriados quando ocorrer um incidente real.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Programe os dias de jogo para praticar regularmente os runbooks e os manuais. Os dias de jogo devem incluir todas as pessoas envolvidas em um evento de produção: proprietário da empresa, equipe de desenvolvimento, equipe operacional e equipes de resposta a incidentes.
+ Execute os testes de carga ou de performance e, em seguida, execute a injeção de falha.
+ Procure por anomalias nos runbooks e oportunidades de praticar os playbooks.
+ Se você se desviar dos runbooks, refine-os ou corrija o comportamento. Se você praticar o playbook, identifique o runbook que deveria ter sido usado ou crie um novo.
## Recursos
**Documentos relacionados:**
+ [O que é o AWS GameDay?](https://aws.amazon.com/gameday/)
**Vídeos relacionados:**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Exemplos relacionados:**
+ [Laboratórios do AWS Well-Architected: testes de resiliência](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 Como você planeja a recuperação de desastres (DR)?
Implementar backups e componentes redundantes de carga de trabalho é o ponto de partida da sua estratégia de DR. [RTO e RPO são os seus objetivos](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) para restauração de sua workload. Defina-os de acordo com suas necessidades de negócios. Implemente uma estratégia para atender a esses objetivos, considerando os locais e a função dos recursos e dos dados da carga de trabalho. A probabilidade de interrupção e o custo de recuperação também são fatores principais que ajudam a determinar o valor empresarial de fornecer a recuperação de desastres para uma workload.
**Topics**
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação de recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizar a recuperação](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados
A carga de trabalho tem um Recovery Time Objective (RTO – Objetivo do tempo de recuperação) e um Recovery Point Objective (RPO – Objetivo do ponto de recuperação).
*Recovery Time Objective (RTO – Objetivo do tempo de recuperação)* é o atraso máximo aceitável entre a interrupção do serviço e sua restauração. Isso determina o que é considerado uma janela de tempo aceitável quando o serviço está indisponível.
*Recovery Point Objective (RPO – Objetivo do ponto de recuperação)* é o tempo máximo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda aceitável de dados entre o último ponto de recuperação e a interrupção do serviço.
Os valores de RTO e RPO são considerações importantes ao selecionar uma estratégia de recuperação de desastres (DR) apropriada para a workload. Esses objetivos são determinados pelo negócio e, em seguida, usados pelas equipes técnicas para selecionar e implementar uma estratégia de DR.
**Resultado desejado:**
Cada workload tem um RTO e um RPO atribuídos, definidos com base no impacto empresarial. A workload é atribuída a uma camada predefinida com um RTO e um RPO associados, estabelecendo a disponibilidade do serviço e a perda aceitável de dados. Se isso não for possível, poderá ser atribuído sob medida por workload com a intenção de criar camadas posteriormente. O RTO e o RPO são usados como uma das principais considerações para a seleção da implementação de uma estratégia de recuperação de desastres para a workload. São considerações adicionais na escolha de uma estratégia de DR as restrições de custo, as dependências da workload e os requisitos operacionais.
Para o RTO, compreenda o impacto com base na duração de uma interrupção. É linear ou há implicações não lineares? (Por exemplo, após quatro horas, você desliga uma linha de produção até o início do próximo turno).
Uma matriz de recuperação de desastres, como a seguinte, pode ajudar você a compreender como a criticidade da workload se relaciona com os objetivos de recuperação. (Observe que os valores reais dos eixos X e Y devem ser personalizados de acordo com as necessidades da sua organização).
![\[Gráfico mostrando a matriz de recuperação de desastres\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Antipadrões comuns:**
+ Objetivos de recuperação não definidos.
+ Seleção de objetivos de recuperação arbitrários.
+ Seleção de objetivos de recuperação que são muito permissivos e não atendem aos objetivos de negócios.
+ Não compreender o impacto do tempo de inatividade e da perda de dados.
+ Seleção de objetivos de recuperação irreais, como nenhum tempo para recuperação e nenhuma perda de dados, que podem não ser alcançáveis para a configuração da workload.
+ Seleção de objetivos de recuperação mais rigorosos do que os objetivos de negócios reais. Isso força implementações de DR mais caras e complicadas do que as necessidades da workload.
+ Seleção de objetivos de recuperação incompatíveis com os da workload dependente.
+ Os objetivos de recuperação não consideram os requisitos regulamentares de conformidade.
+ RTO e RPO definidos para uma workload, mas nunca testados.
**Benefícios do estabelecimento dessa prática recomendada:** Os objetivos de recuperação referentes a tempo e perda de dados são necessários para orientar a implementação da DR.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
Para a workload, você deve compreender o impacto do tempo de inatividade e da perda de dados em seus negócios. O impacto geralmente aumenta com maior tempo de inatividade ou perda de dados, mas a forma desse crescimento pode diferir com base no tipo de workload. Por exemplo, pode ser que você consiga tolerar o tempo de inatividade por até uma hora com pouco impacto, mas depois disso o impacto aumenta rapidamente. O impacto nos negócios se manifesta de diversas formas, incluindo custo monetário (como perda de receita), confiança do cliente (e impacto na reputação), problemas operacionais (como folha de pagamento ausente ou diminuição na produtividade) e risco regulatório. Use as etapas a seguir para compreender esses impactos e defina o RTO e o RPO para sua workload.
**Etapas da implementação**
1. Determine as partes interessadas do negócio para a workload e interaja com eles para implementar essas etapas. Os objetivos de recuperação para uma workload são uma decisão de negócios. As equipes técnicas trabalham com as partes interessadas do negócio para usar esses objetivos para selecionar uma estratégia de DR.
**nota**
Para as etapas 2 e 3, você pode usar o [Planilha de implementação](#implementation-worksheet).
1. Reúna as informações necessárias para tomar uma decisão respondendo às perguntas abaixo.
1. Você tem categorias ou níveis de criticidade para o impacto da workload na sua organização?
1. Se sim, atribua esta workload a uma categoria
1. Se não, estabeleça estas categorias. Crie cinco ou menos categorias e refine o intervalo do seu objetivo de tempo de recuperação para cada uma delas. Os exemplos de categorias incluem: crítica, alta, média, baixa. Para entender como uma workloads é mapeada para uma categoria, considere se ela é de missão crítica, importante para os negócios ou não comercial.
1. Defina o RTO e o RPO da workload com base na categoria. Sempre escolha uma categoria mais restrita (RTO e RPO mais baixos) do que os valores brutos calculados no começo desta etapa. Se isso resultar em uma mudança de valor inadequadamente grande, considere a criação de uma nova categoria.
1. Com base nessas respostas, atribua valores de RTO e RPO à workload. Isso pode ser feito diretamente ou atribuindo a workload a uma camada de serviço predefinida.
1. Documente o plano de recuperação de desastres (DRP) para esta workload, que faz parte [do plano de continuidade de negócios (BCP) da sua organização](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), em um local acessível à equipe de workload e às partes interessadas
1. Registre o RTO, o RPO e as informações usadas para determinar esses valores. Inclua a estratégia usada para avaliar o impacto da workload nos negócios.
1. Registre outras métricas, além do RTO e do RPO que você está acompanhando ou planeja acompanhar, para os objetivos de recuperação de desastres
1. Você adicionará detalhes da sua estratégia de DR e runbook a este plano ao criá-los.
1. Ao pesquisar a criticidade da workload em uma matriz, como a da figura 15, você pode começar a estabelecer camadas predefinidas de serviço estabelecidos para sua organização.
1. Após implementar uma estratégia de DR (ou uma prova de conceito para uma estratégia de DR) conforme [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md), teste a estratégia para determinar a capacidade de tempo de recuperação (RTC) e a capacidade de ponto de recuperação (RPC) reais da workload. Se elas não atenderem aos objetivos de recuperação de destino, trabalhe com as partes interessadas do negócio para ajustar esses objetivos ou faça alterações na estratégia de DR para atingir os objetivos de destino.
**Perguntas principais**
1. Qual é o tempo máximo que a workload pode ficar inativa antes que ocorra um impacto grave nos negócios?
1. Determine o custo monetário (impacto financeiro direto) para o negócio por minuto se a workload for interrompida.
1. Considere que o impacto nem sempre é linear. O impacto pode ser limitado no início e aumentar rapidamente após um ponto crítico.
1. Qual é a quantidade máxima de dados que podem ser perdidos antes que ocorra um impacto severo nos negócios?
1. Considere esse valor para seu armazenamento de dados mais crítico. Identifique a respectiva criticidade para outros armazenamentos de dados.
1. Os dados de workload podem ser recriados em caso de perda? Se isso for operacionalmente mais fácil do que fazer backup e restauração, escolha o RPO com base na criticidade dos dados de origem usados para recriar os dados da workload.
1. Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads das quais este depende (downstream) ou as workloads que dependem deste (upstream)?
1. Escolha objetivos de recuperação que permitam que essa workload atenda aos requisitos das dependências upstream.
1. Escolha objetivos de recuperação que possam ser alcançados com base nos recursos de recuperação das dependências downstream. Dependências downstream não críticas (aquelas que podem ser “contornadas”) podem ser excluídas. Ou trabalhe com dependências críticas downstream para melhorar os recursos de recuperação quando necessário.
**Perguntas adicionais**
Considere estas perguntas e como elas podem se aplicar a essa workload:
1. Você tem RTO e RPO diferentes dependendo do tipo de interrupção (região versus AZ etc.)?
1. Existe um momento específico (sazonalidade, eventos de vendas, lançamentos de produtos) em que seu RTO/RPO pode mudar? Se sim, quais são a medição e o limite de tempo diferentes?
1. Quantos clientes serão afetados se a workload for interrompida?
1. Qual será o impacto na reputação se a workload for interrompida?
1. Quais outros impactos operacionais poderão ocorrer se a workload for interrompida? Por exemplo, impacto na produtividade do funcionário se os sistemas de e-mail não estiverem disponíveis ou se os sistemas de folha de pagamento não puderem enviar transações.
1. Como o RTO e o RPO da workload se alinham à estratégia de DR da linha empresarial e organizacional?
1. Há obrigações contratuais internas para a prestação de um serviço? Há penalidades por não cumpri-las?
1. Quais são as restrições regulatórias ou de conformidade com os dados?
## Planilha de implementação
Você pode usar esta planilha para as etapas 2 e 3 de implementação. É possível ajustar esta planilha para atender às suas necessidades específicas, como adicionar perguntas.
![\[Planilha\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Nível de esforço para o plano de implementação: **Baixo
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP04 Realizar a recuperação periódica dos dados para verificar a integridade e os processos de backup](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação de recuperação de desastres para validá-la](rel_planning_for_recovery_dr_tested.md)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gerenciamento de políticas de resiliência com o AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Usar estratégias de recuperação definidas para atender aos objetivos de recuperação
Defina uma estratégia de recuperação de desastres (DR) que atenda os objetivos de recuperação da workload. Escolha uma estratégia como: backup e restauração, standby (ativo-passivo) ou ativo-ativo.
Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se seu local primário não puder executar a workload. Os objetivos de recuperação mais comuns são o RTO e o RPO, conforme discutido em [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md).
Uma estratégia de DR em várias zonas de disponibilidade (AZs) em uma única Região da AWS pode fornecer mitigação contra eventos de desastre, como incêndios, inundações e grandes interrupções de energia. Se for um requisito implementar proteção contra um evento improvável que impeça a execução da workload em uma determinada Região da AWS, você poderá optar por uma estratégia de DR que use várias regiões.
Ao arquitetar uma estratégia de DR em várias regiões, você deve escolher uma das seguintes estratégias. Elas estão listadas em ordem crescente de custo e complexidade e em ordem decrescente de RTO e RPO. *região de recuperação* refere-se a uma Região da AWS diferente da primária usada para a workload.
![\[Diagrama mostrando estratégias de DR\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Backup e restauração** (RPO em horas, RTO em 24 horas ou menos): faça backup de seus dados e aplicações na região de recuperação. O uso de backups automatizados ou contínuos permitirá a recuperação a um ponto anterior no tempo, podendo reduzir o RPO para até 5 minutos em alguns casos. Em caso de desastre, você implantará a infraestrutura (usando a infraestrutura como código para reduzir o RTO), implantará o código e restaurará os dados salvos para se recuperar de um desastre na região de recuperação.
+ **Luz piloto** (RPO em minutos, RTO em dezenas de minutos): provisione uma cópia da infraestrutura de workload principal na região de recuperação. Replique seus dados na região de recuperação e crie backups deles lá. Os recursos necessários para oferecer suporte à replicação e ao backup, como bancos de dados e armazenamento de objetos, estão sempre ativos. Outros elementos, como servidores de aplicações ou computação com tecnologia sem servidor, não são implantados. Porém, podem ser criados com a configuração e o código da aplicação necessários.
+ **Modo de espera passivo** (RPO em segundos, RTO em minutos): mantenha uma versão reduzida, mas totalmente funcional, da workload sempre em execução na região de recuperação. Os sistemas críticos para os negócios são totalmente duplicados e estão sempre ativados, mas com uma frota reduzida. Os dados são replicados e vivem na região de recuperação. Quando chega o momento da recuperação, o sistema é dimensionado rapidamente para processar a carga de produção. Quanto mais a escala do modo de espera passivo for aumentada verticalmente, menor será a dependência do RTO e do ambiente de gerenciamento. Quando totalmente dimensionado, isso é conhecido como **standby a quente**.
+ **Multirregional (multissite) ativo-ativo** (RPO próximo a zero, RTO potencialmente zero): a workload é implantada em várias Regiões da AWS e processa ativamente o tráfego delas. Esta estratégia exige que você sincronize os dados entre regiões. Deve-se evitar ou processar possíveis conflitos causados por gravações no mesmo registro em duas réplicas regionais diferentes, o que pode ser complexo. A replicação de dados é útil para a sincronização de dados e protegerá você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua opções para recuperação a um ponto anterior no tempo.
**nota**
Às vezes, a diferença entre luz piloto e modo de espera passivo pode ser difícil de entender. Ambos incluem um ambiente na região de recuperação com cópias dos ativos da região primária. A diferença é que a luz piloto não pode processar solicitações sem primeiro realizar uma ação adicional, enquanto o modo de espera passivo pode processar o tráfego (em níveis de capacidade reduzidos) imediatamente. A luz piloto exigirá que você ative os servidores, possivelmente implante infraestrutura adicional (não essencial) e aumente a escala verticalmente. Já o modo de espera passivo exige apenas que você aumente a escala verticalmente (tudo já está implantado e em execução). Escolha entre elas com base nas suas necessidades de RTO e RPO.
**Resultado desejado:**
Há uma estratégia de DR definida e implementada para cada workload, permitindo que ela atinja os objetivos de DR. As estratégias de DR entre workloads fazem uso de padrões reutilizáveis (como as estratégias descritas anteriormente).
**Antipadrões comuns:**
+ Implementar procedimentos de recuperação inconsistentes para workloads com objetivos de DR semelhantes.
+ Deixar que a estratégia de DR seja implementada ad hoc quando ocorrer um desastre.
+ Não tendo nenhum plano para DR.
+ Depender das operações do ambiente de gerenciamento durante a recuperação.
**Benefícios do estabelecimento dessa prática recomendada:**
+ O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste.
+ O uso de estratégias de recuperação definidas permite o compartilhamento de conhecimento eficiente entre as equipes e uma implementação mais fácil de DR nas workloads que elas possuem.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
+ Sem uma estratégia de DR planejada, implementada e testada, é improvável que você atinja os objetivos de recuperação em caso de desastre.
## Orientações para a implementação
Para cada uma dessas etapas, veja os detalhes abaixo.
1. Determine uma estratégia de DR que satisfaça os requisitos de recuperação para esta workload.
1. Revise os padrões de como a estratégia de DR selecionada pode ser implementada.
1. Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).
1. Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).
1. Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).
1. Projete um plano de como a workload retornará.
**Etapas da implementação**
1. **Determine uma estratégia de DR que satisfaça os requisitos de recuperação para esta workload.**
Escolher uma estratégia de DR é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) versus o custo e a complexidade da sua implementação. Você deve evitar implementar uma estratégia mais rigorosa do que necessário, pois isso resulta em custos desnecessários.
Por exemplo, no diagrama a seguir, a empresa determinou seu RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos do negócio, as estratégias de DR luz piloto e modo de espera passivo satisfarão tanto o RTO quanto os critérios de custo.
![\[Gráfico mostrando a escolha de uma estratégia de DR com base no RTO e no custo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Para saber mais, consulte [Plano de continuidade de negócios (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Revise os padrões de como a estratégia de DR selecionada pode ser implementada.**
Esta etapa é para compreender como implementar a estratégia selecionada. As estratégias são explicadas usando as Regiões da AWS como locais primários e de recuperação. No entanto, também é possível optar por usar as zonas de disponibilidade em uma única região como sua estratégia de DR, que faz uso de elementos de várias dessas estratégias.
Nas etapas subsequentes, você aplicará a estratégia à sua workload específica.
**Backup e restauração**
*Backup e restauração* é a estratégia menos complexa de implementar. Porém, exigirá mais tempo e esforço para restaurar a workload, levando a RTO e RPO mais altos. É uma boa prática sempre fazer backups dos seus dados e copiá-los para outro local (como outra Região da AWS).
![\[Diagrama mostrando uma arquitetura de backup e restauração\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte II: backup e restauração com recuperação rápida](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Luz piloto**
Com a abordagem de *luz piloto* , você replica os dados da região primária para a região de recuperação. Os recursos principais usados para a infraestrutura de workload são implantados na região de recuperação. No entanto, recursos adicionais e quaisquer dependências ainda são necessários para tornar isso uma pilha funcional. Por exemplo, na figura 20, nenhuma instância de computação é implantada.
![\[Diagrama mostrando uma arquitetura de luz piloto\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e modo de espera passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Modo de espera passivo**
O *standby passivo* envolve garantir que haja uma cópia com escala reduzida verticalmente, mas totalmente funcional, do seu ambiente de produção em outra região. Essa abordagem estende o conceito de luz piloto e diminui o tempo de recuperação já que a workload está sempre ativa em outra região. A implementação da região de recuperação com capacidade total é conhecido como *standby a quente*.
![\[Diagrama mostrando a Figura 21: uma arquitetura de modo de espera passivo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
O uso do modo de espera passivo ou luz piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para garantir que a capacidade esteja disponível quando necessário, considere o uso de [reservas de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) para instâncias do EC2. Se estiver usando o AWS Lambda, [a concorrência provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) poderá garantir que ambientes de execução estejam preparados para responder imediatamente às invocações da sua função.
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e modo de espera passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multissite ativo-ativo**
Você pode executar sua workload simultaneamente em várias regiões como parte de uma *estratégia de* multissite ativo-ativo. O multissite ativo-ativo atende ao tráfego de todas as regiões onde está implantado. Os clientes podem selecionar esta estratégia por outros motivos, além da DR. Ele pode ser usado para aumentar a disponibilidade ou ao implantar uma workload para um público global (para aproximar o endpoint dos usuários e/ou implantar pilhas localizadas para o público nessa região). Como uma estratégia de DR, se a workload não puder ser suportada em uma das Regiões da AWS onde está implantada, esta região será evacuada e as regiões restantes serão usadas para manter a disponibilidade. O multissite ativo-ativo é a estratégia de DR mais complexa operacionalmente e deve ser selecionada apenas quando os requisitos de negócios exigirem.
![\[Diagrama mostrando uma arquitetura de multissite ativo-ativo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Para obter mais detalhes sobre esta estratégia, consulte [Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo-ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Práticas adicionais para proteção de dados**
Com todas as estratégias, você também deve atenuar um desastre de dados. A replicação contínua de dados protege você contra alguns tipos de desastre, mas não contra corrupção ou destruição de dados, a menos que sua solução também inclua o versionamento de dados armazenados ou opções para recuperação a um ponto anterior no tempo. Você também deve fazer backup dos dados replicados no local de recuperação para criar backups pontuais além das réplicas.
**O uso de várias zonas de disponibilidade (AZs) em uma única Região da AWS**
Ao utilizar várias AZs em uma única região, sua implementação de DR usa vários elementos das estratégias acima. Primeiro, você deve criar uma arquitetura de alta disponibilidade (HA), usando várias AZs, conforme mostrado na figura 23. Esta arquitetura faz uso de uma abordagem multissite ativo-ativo, já que as [instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) e a seção [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) têm recursos implantados em várias AZs, processando solicitações ativamente. A arquitetura também demonstra standby a quente, no qual se a instância primária do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) falhar (ou se a própria AZ falhar), a instância em espera será promovida a primária.
![\[Diagrama mostrando a Figura 23: uma arquitetura multi-A\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
Além da arquitetura de alta disponibilidade, você precisa adicionar backups de todos os dados necessários para executar a workload. Isso é especialmente importante para dados restritos a uma única zona, como [volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) ou [clusters do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se uma AZ falhar, você precisará restaurar esses dados para outra AZ. Sempre que possível, você também deve copiar backups de dados para outra Região da AWS, como uma camada adicional de proteção.
Uma alternativa de abordagem menos comum para região única, DR multi-AZ é ilustrada na publicação do blog, [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Aqui, a estratégia é manter o máximo de isolamento possível entre as AZs, assim como as regiões operam. Ao usar esta estratégia alternativa, você pode escolher uma abordagem ativa/ativa ou ativa/passiva.
Observação: algumas workloads têm requisitos regulamentares de residência de dados. Se isso se aplicar à sua workload em uma localidade que atualmente tem apenas uma Região da AWS, a multirregião não atenderá às suas necessidades de negócios. As estratégias multi-AZ fornecem boa proteção contra a maioria dos desastres.
1. **Avalie os recursos da workload e qual será sua configuração na região de recuperação antes do failover (durante a operação normal).**
Para infraestrutura e recursos da AWS, use a infraestrutura como código, como o [AWS CloudFormation](https://aws.amazon.com/cloudformation) ou ferramentas de terceiros como o Hashicorp Terraform. Para implantar em várias contas e regiões com uma única operação, você pode usar o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Para estratégias multissite ativo-ativo e standby a quente, a infraestrutura implantada na região de recuperação tem os mesmos recursos que a região primária. Para as estratégias luz piloto e modo de espera passivo, a infraestrutura implantada exigirá ações adicionais para ficar pronta para produção. Ao usar o CloudFormation [parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [a lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), você pode controlar se uma pilha implantada está ativa ou em espera com um único modelo. Um exemplo desse modelo do CloudFormation está incluído [nesta publicação do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Todas as estratégias de DR exigem que sejam feitos backup das fontes de dados dentro da Região da AWS e, em seguida, esses backups sejam copiados para a região de recuperação. [AWS Backup](https://aws.amazon.com/backup/) fornece uma visão centralizada na qual você pode configurar, programar e monitorar backups para esses recursos. Para luz piloto, modo de espera passivo e multissite ativo-ativo, você também deve replicar dados da região primária para recursos de dados na região de recuperação, como instâncias de banco de dados do [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) ou tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . Esses recursos de dados estão ativos e prontos para atender a solicitações na região de recuperação.
Para saber mais sobre como os serviços da AWS operam entre as regiões, consulte esta série de blogs em [Criação de uma aplicação multirregional com os serviços da AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Determine e implemente como deixar sua região de recuperação pronta para failover quando necessário (durante um evento de desastre).**
Para multissite ativo-ativo, failover significa evacuar uma região e confiar nas regiões ativas restantes. No geral, essas regiões estão prontas para aceitar tráfego. Para as estratégias luz piloto e modo de espera passivo, as ações de recuperação precisarão implantar os recursos ausentes, como as instâncias do EC2 na figura 20, além de quaisquer outros recursos ausentes.
Para todas as estratégias acima, pode ser necessário promover instâncias somente leitura de bancos de dados para se tornar a instância primária de leitura/gravação.
Para backup e restauração, a restauração de dados do backup cria recursos para esses dados, como volumes do EBS, instâncias de banco de dados do RDS e tabelas do DynamoDB. Você também precisa restaurar a infraestrutura e implantar o código. É possível usar o AWS Backup para restaurar dados na região de recuperação. Perceber [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md) para obter mais detalhes. A reconstrução da infraestrutura inclui a criação de recursos como instâncias do EC2, além do [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), sub-redes e grupos de segurança necessários. Você pode automatizar grande parte do processo de restauração. Para saber mais, consulte [nesta publicação do blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Determine e implemente como redirecionar o tráfego para failover quando necessário (durante um evento de desastre).**
Essa operação de failover pode ser iniciada automaticamente ou manualmente. O failover iniciado automaticamente com base em verificações de integridade ou alarmes deve ser usado com cautela, pois um failover desnecessário (alarme falso) resulta em custos como indisponibilidade e perda de dados. Portanto, o failover iniciado manualmente é geralmente usado. Nesse caso, você ainda deve automatizar as etapas para failover, para que a inicialização manual seja como apertar um botão.
Há várias opções de gerenciamento de tráfego a serem consideradas ao usar os serviços da AWS. Uma opção é usar o [Amazon Route 53](https://aws.amazon.com/route53). Ao usar o Amazon Route 53, você pode associar vários endpoints de IP em uma ou mais Regiões da AWS a um nome de domínio do Route 53. Para implementar o failover iniciado manualmente, você pode usar o [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), que fornece uma API de plano de dados altamente disponível para redirecionar o tráfego para a região de recuperação. Ao implementar o failover, use as operações do plano de dados e evite as do ambiente de gerenciamento, conforme descrito em [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md).
Para saber mais sobre esta e outras opções, consulte [a seção de whitepaper sobre a recuperação de desastres](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Projete um plano de como a workload retornará.**
Failback é quando você retorna a operação de workload para a região primária, após a redução de um evento de desastre. O provisionamento de infraestrutura e código para a região primária geralmente segue as mesmas etapas que foram usadas inicialmente, contando com a infraestrutura como código e pipelines de implantação de código. O desafio com o failback é restaurar os armazenamentos de dados e garantir sua consistência com a região de recuperação em operação.
No estado de failover, os bancos de dados na região de recuperação estão ativos e têm dados atualizados. O objetivo é ressincronizar da região de recuperação para a região primária, garantindo que ela esteja atualizada.
Alguns serviços da AWS farão isso automaticamente. Se usar [as tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), mesmo que a tabela na região primária tenha ficado indisponível, quando ela voltar a ficar online, o DynamoDB retomará a propagação das gravações pendentes. Se usar [o banco de dados global do Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e o [failover planejado e gerenciado](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), a topologia de replicação existente do banco de dados global do Aurora é mantida. Portanto, a antiga instância de leitura/gravação na região primária se tornará uma réplica e receberá atualizações da região de recuperação.
Em casos onde isso não for automático, você precisará restabelecer o banco de dados na região primária como uma réplica do banco de dados na região de recuperação. Em muitos casos, isso envolverá a exclusão do banco de dados primário antigo e a criação de novas réplicas. Por exemplo, para obter instruções sobre como fazer isso com o banco de dados global do Amazon Aurora presumindo um *failover* não planejado, consulte este laboratório: [Retornar um banco de dados global](https://awsauroralabsmy.com/global/failback/).
Após um failover, se você puder continuar executando na região de recuperação, considere torná-la a nova região primária. Você ainda seguiria todas as etapas acima para transformar a antiga região primária em uma região de recuperação. Algumas organizações fazem uma rotação programada, trocando suas regiões primárias e de recuperação periodicamente (por exemplo, a cada três meses).
Todas as etapas necessárias para failover e failback devem ser mantidas em um playbook disponível para todos os membros da equipe e que seja revisado periodicamente.
**Nível de esforço para o plano de implementação**: alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL09-BP01 Identificar e fazer backup de todos os dados que precisam de backup ou reproduzir os dados das fontes](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
**Documentos relacionados:**
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opções de recuperação de desastres na nuvem](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Crie uma solução de backend ativo-ativo multirregional sem servidor em uma hora](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend multirregional sem servidor: recarregado](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: replicação de uma réplica de leitura entre regiões](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: configuração do failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Introdução; AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vídeos relacionados:**
+ [Recuperação de desastres de workloads na AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Introdução ao AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Exemplos relacionados:**
+ [Laboratórios do AWS Well-Architected: recuperação de desastres](https://wellarchitectedlabs.com/reliability/disaster-recovery/) : série de workshops que ilustram as estratégias de DR
# REL13-BP03 Testar a implementação de recuperação de desastres para validá-la
Teste regularmente o failover no site de recuperação para garantir a operação adequada e que o RTO e o RPO sejam atendidos.
Um padrão que deve ser evitado é o desenvolvimento de caminhos de recuperação que raramente são executados. Por exemplo, você pode ter um repositório de dados secundário utilizado para consultas somente leitura. Quando você grava em um repositório de dados e o repositório de dados primário falha, pode ser necessário fazer o failover para o repositório de dados secundário. Se você não testar esse failover com frequência, poderá descobrir que suas suposições sobre as capacidades do armazenamento de dados secundário são incorretas. A capacidade do secundário, que talvez tenha sido suficiente quando testado pela última vez, pode não conseguir mais tolerar a carga neste cenário. Nossa experiência mostrou que a única recuperação de erro que funciona é o caminho que você testa com frequência. É por isso que é melhor ter um pequeno número de caminhos de recuperação. Você pode estabelecer padrões de recuperação e testá-los regularmente. Se você tiver um caminho de recuperação complexo ou crítico, ainda precisará executar regularmente essa falha na produção para garantir o funcionamento desse caminho. No exemplo que acabamos de discutir, você deve realizar o failover para o standby regularmente, não importa a necessidade.
**Antipadrões comuns:**
+ Nunca execute failovers em produção.
**Benefícios do estabelecimento desta prática recomendada:** Teste regularmente seu plano de recuperação de desastres para garantir que ele funcione quando necessário e que sua equipe saiba como executar a estratégia.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Projete suas cargas de trabalho para recuperação. Teste regularmente os caminhos de recuperação. A computação orientada à recuperação identifica as características nos sistemas que aprimoram a recuperação. Essas características são: isolamento e redundância, capacidade de reverter alterações em todo o sistema, capacidade de monitorar e determinar a integridade, capacidade de realizar diagnósticos, recuperação automatizada, design modular e recurso de reinicialização. Pratique o caminho de recuperação para garantir que possa realizá-la no tempo especificado para o estado determinado. Use seus runbooks durante essa recuperação para documentar problemas e encontrar soluções para eles antes do próximo teste.
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Use o CloudEndure Disaster Recovery para implementar e testar sua estratégia de DR.
+ [Teste da solução de recuperação de desastres com o CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [CloudEndure Disaster Recovery para AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Teste da solução de recuperação de desastres com o CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [O que é o AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Exemplos relacionados:**
+ [Laboratórios do AWS Well-Architected: testes de resiliência](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Gerenciar o desvio de configuração para o local ou a região de DR
Certifique-se de que a infraestrutura, os dados e a configuração estejam conforme necessário no local ou na região de DR. Por exemplo, verifique se as AMIs e as cotas de serviço estão atualizadas.
O AWS Config monitora e registra continuamente as configurações dos recursos da AWS. Ele pode detectar desvios e acionar o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) para corrigi-lo e gerar alarmes. O AWS CloudFormation também pode detectar desvios nas pilhas que você implantou.
**Antipadrões comuns:**
+ Falhar ao atualizar os locais de recuperação, ao fazer alterações de configuração ou infraestrutura nos locais primários.
+ Não considerar possíveis limitações (como diferenças de serviço) nos locais primários e de recuperação.
**Benefícios do estabelecimento desta prática recomendada:** Garantir que o ambiente de DR seja consistente com seu ambiente existente para assegurar a recuperação completa.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Garanta que seus pipelines de entrega enviem para seus locais primário e de backup. Os pipelines de entrega para implantação de aplicativos em produção devem ser distribuídos para todos os locais de estratégia de recuperação de desastres especificados, incluindo os ambientes de desenvolvimento e de teste.
+ Habilite o AWS Config para acompanhar possíveis locais de desvio. Use as regras do AWS Config para criar sistemas que aplicam suas estratégias de recuperação de desastres e geram alertas ao detectar desvios.
+ [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Use o AWS CloudFormation para implantar a infraestrutura. O AWS CloudFormation pode detectar desvios entre as especificações dos modelos do CloudFormation e o que é realmente implantado.
+ [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: detectar desvios em uma pilha inteira do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Como faço para implementar uma solução de gerenciamento de configuração de infraestrutura na AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Correção de recursos não compatíveis do Regras do AWS Config pela AWS](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatizar a recuperação
Use ferramentas da AWS ou de terceiros para automatizar a recuperação do sistema e rotear o tráfego para o local ou a região de DR.
Com base em verificações de integridade configuradas, os serviços da AWS, como o Elastic Load Balancing e o AWS Auto Scaling, podem distribuir a carga para zonas de disponibilidade íntegras, enquanto outros serviços, como o Amazon Route 53 e o AWS Global Accelerator, podem rotear a carga para Regiões da AWS íntegras. O Amazon Route 53 Application Recovery Controller ajuda a gerenciar e coordenar o failover usando verificações de prontidão e recursos de controle de roteamento. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, zonas de disponibilidade e ambientes on-premises.
Para workloads em datacenters físicos ou virtuais existentes ou nuvens privadas, o [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/), disponível por meio do AWS Marketplace, permite que as organizações configurem uma estratégia automatizada de recuperação de desastres para a AWS. O CloudEndure também oferece suporte à recuperação de desastres entre regiões e entre AZs na AWS.
**Antipadrões comuns:**
+ A implementação de failover e failback automatizados idênticos pode causar oscilação quando uma falha ocorre.
**Benefícios do estabelecimento dessa prática recomendada:** A recuperação automatizada reduz o tempo de recuperação ao eliminar a oportunidade de erros manuais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Automatize caminhos de recuperação. No caso de tempos de recuperação curtos, não é possível adotar critério e ação humanos em cenários de alta disponibilidade. O sistema deve recuperar-se automaticamente sob qualquer situação.
+ Use o CloudEndure Disaster Recovery para automatizar failover e failback. Ele replica continuamente suas máquinas (incluindo sistema operacional, configuração de estado do sistema, bancos de dados, aplicações e arquivos) em uma área de preparação de baixo custo na Conta da AWS de destino e na região de preferência. Em caso de desastre, você pode instruir o CloudEndure Disaster Recovery a executar automaticamente milhares de máquinas em seu estado totalmente provisionado em minutos.
+ [Realizar um failover e failback de recuperação de desastres](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Recursos
**Documentos relacionados:**
+ [Parceiro do APN: parceiros que podem ajudar com a recuperação de desastres](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog de arquitetura da AWS: série de recuperação de desastres](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produtos que podem ser usados para recuperação de desastres](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [CloudEndure Disaster Recovery para AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)