# Confiabilidade
O pilar Confiabilidade abrange a capacidade de uma workload de executar a função pretendida correta e consistentemente quando esperado. Você pode encontrar orientações prescritivas sobre implementação no [whitepaper sobre o pilar de confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp).
**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**
+ [CONFIABILIDADE 1. Como gerenciar as Service Quotas e restrições?](rel-01.md)
+ [CONFIABILIDADE 2. Como planejar sua topologia de rede?](rel-02.md)
# CONFIABILIDADE 1. Como gerenciar as Service Quotas e restrições?
Para arquiteturas de workload baseadas na nuvem, há Service Quotas, que também são conhecidas como limites de serviço. Essas cotas existem para evitar o provisionamento 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 restrições e as cotas 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 Garantir 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
Esteja ciente das suas cotas padrão e das solicitações de aumento de cota referentes à sua arquitetura de workload. Saiba quais restrições de recursos, como disco ou rede, podem gerar impactos.
**Resultado desejado:** os clientes conseguem evitar a degradação ou a interrupção do serviço nas Contas da AWS implementando diretrizes adequadas para monitorar as principais métricas, análises da infraestrutura e etapas de remediação da automação, a fim de confirmar que as cotas e as restrições do serviço não foram atingidas, o que poderia causar degradação ou interrupção do serviço.
**Antipadrões comuns:**
+ Implantar uma workload sem compreender as cotas flexíveis ou fixas e seus limites para os serviços utilizados.
+ Implantar uma workload de substituição sem analisar e reconfigurar as cotas necessárias ou entrar em contato com o suporte com antecedência.
+ Pressupor que os serviços em nuvem não têm limites e os serviços podem ser usados sem considerar taxas, limites, contagens e quantidades.
+ Pressupor que as cotas aumentarão automaticamente.
+ Não saber o processo e a linha de tempo das solicitações de cota.
+ Pressupor que a cota de serviço em nuvem padrão é idêntica para todos os serviços em comparação entre as regiões.
+ Pressupor que as restrições do serviço podem ser violadas e os sistemas vão ser escalados automaticamente ou aumentar o limite além das restrições do recurso
+ Não testar a aplicação em tráfego de pico a fim de aplicar tensão na utilização de seus recursos.
+ Provisionar o recurso sem analisar o tamanho necessário dele.
+ Superprovisionar capacidade selecionando tipos de recurso que superam em muito a necessidade real ou os picos esperados.
+ Não avaliar os requisitos de capacidade para novos níveis de tráfego antes de um novo evento de cliente ou implantação de uma nova tecnologia.
**Benefícios do estabelecimento desta prática recomendada:** o monitoramento e o gerenciamento automatizado de cotas de serviço e restrições de recursos podem reduzir as falhas de forma proativa. As alterações nos padrões de tráfego do serviço de um cliente poderão causar interrupção ou degradação se as práticas recomendadas não forem seguidas. Ao monitorar e gerenciar esses valores em todas as regiões e contas, as aplicações podem ter uma resiliência aprimorada em eventos adversos ou não planejados.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto
## Orientações para a implementação
O Service Quotas é um serviço da AWS que ajuda você a gerenciar as cotas de mais de 250 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 SDK. 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 por respectivo serviço, por exemplo, consulte [Cotas da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html).
Alguns limites de serviço, como os limites de taxa para APIs limitadas, são definidos no próprio Amazon API Gateway por meio da configuração de um plano de uso. Alguns limites definidos como configuração em seus respectivos serviços incluem IOPS provisionadas, armazenamento do Amazon RDS alocado e alocações de volume do Amazon EBS. O Amazon Elastic Compute Cloud tem seu próprio painel de limites de serviço, que pode ajudar você a gerenciar sua instância, o Amazon Elastic Block Store 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 de sua aplicação e elas não forem ajustadas às suas necessidades, entre em contato com o Suporte para ver se há mitigações.
As cotas de serviço podem ser específicas da região e também pode ser globais por natureza. O uso de um serviço da AWS com a cota atingida fará com que o comportamento dele não seja o esperado e poderá causar interrupção ou degradação do serviço. Por exemplo, a cota de um serviço limita o número de DL Amazon EC2 que pode ser usado em uma região e esse limite poderá ser atingido durante um evento de escalabilidade de tráfego usando grupos do Auto Scaling (ASG).
As cotas de serviço de cada conta devem ser avaliadas regularmente quanto ao uso a fim de determinar quais são os limites de serviço apropriados para a conta em questão. Essas cotas de serviço existem como barreiras de proteção operacionais, a fim de impedir o provisionamento acidental de recursos além do necessário. Elas também servem para limitar as taxas de solicitação em operações de API para proteger os serviços contra abuso.
Restrições de serviço são diferentes de cotas de serviço. As restrições de serviço representam os limites de um recurso específico conforme definido pelo tipo de recurso em questão. Podem ser a capacidade de armazenamento (por exemplo, o gp2 tem um limite de tamanho de 1 GB a 16 TB) ou o throughput de disco (10 mil iops). É essencial que a restrição de um tipo de recurso seja projetada e avaliada constantemente quanto ao uso que pode atingir o limite. Se uma restrição for atingida de modo inesperado, as aplicações da conta ou os serviços poderão sofrer degradação ou interrupção.
Se houver um caso de uso em que as cotas de serviço afetem a performance de uma aplicação e elas não puderem ser ajustadas às necessidades, entre em contato com o Suporte para ver se há mitigações. Para obter mais detalhes sobre o ajuste de cotas fixas, consulte [REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md).
Há uma série de serviços e ferramentas da AWS para ajudar a monitorar e gerenciar o Service Quotas. O serviço e as ferramentas devem ser utilizadas para oferecer verificações automatizadas ou manuais dos níveis de cota.
+ O AWS Trusted Advisor oferece uma verificação de cotas de serviço que exibe o uso e cotas para alguns aspectos de alguns serviços. Ele pode ajudar na identificação de serviços que estão próximos da cota.
+ O Console de gerenciamento da AWS oferece métodos para exibir valores de cota de serviço, gerenciar, solicitar novas cotas, monitorar o status das solicitações de cota e exibir o histórico de cotas.
+ A AWS CLI e os CDKs oferecem métodos programáticos para gerenciar e monitorar automaticamente os níveis e o uso de cotas de serviço.
**Etapas da implementação**
Para Service Quotas:
+ [ Analisar o AWS Service Quotas. ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Para saber suas cotas de serviço existentes, determine os serviços (como o IAM Access Analyzer) utilizados. Há cerca de 250 serviços da AWS controlados por cotas de serviço. Depois, determine o nome específico da cota de serviço que pode estar sendo usada em cada conta e região. Há cerca de 3 mil nomes de cota de serviço por região.
+ Incremente essa análise de cota com o AWS Config para encontrar todos os [recursos da AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) utilizados em suas Contas da AWS.
+ Use [dados do AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) para determinar seus recursos da AWS utilizados. Examine os recursos que foram criados no Console de gerenciamento da AWS ou com o comando [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) da AWS CLI. Você também pode ver no próprio modelo os recursos configurados para implantação.
+ Examine o código da implantação para determinar todos os serviços necessários à sua workload.
+ Determine as cotas de serviço aplicáveis. Use as informações acessíveis programaticamente por meio do Trusted Advisor e do Service Quotas.
+ Estabeleça um método de monitoramento automatizado (consulte [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)) para alertar e informar se as cotas de serviço estiverem perto do limite ou o atingirem.
+ Estabeleça um método automatizado e programático para conferir se uma cota de serviço foi alterada em uma região, mas não em outras na mesma conta (consulte [REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitorar e gerenciar cotas](rel_manage_service_limits_monitor_manage_limits.md)).
+ Automatize as verificações de logs e métricas de aplicações para determinar se há erros de restrição de serviço ou cota. Se houver esses erros, envie alertas ao sistema de monitoramento.
+ Estabeleça os procedimentos de engenharia para calcular a alteração necessária na cota (consulte [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md)) depois de identificar que são necessárias cotas maiores para serviços específicos.
+ Crie um fluxo de trabalho de provisionamento e aprovação para solicitar alterações na cota de serviço. Isso deve incluir um fluxo de trabalho de exceção em caso de negação de solicitação ou aprovação parcial.
+ Crie um método de engenharia para analisar cotas de serviço antes de provisionar e usar novos serviços da AWS antes de distribuir na produção ou carregar ambientes (por exemplo, conta de teste de carga).
Para restrições de serviço:
+ Estabeleça métodos de monitoramento e métricas para alertar sobre recursos que estejam próximos de suas restrições de recurso. Utilize o CloudWatch conforme apropriado para métricas ou monitoramento de logs.
+ Estabeleça limites de alerta para cada recurso que tenha uma restrição significativa para a aplicação ou o sistema.
+ Crie um fluxo de trabalho e procedimentos de gerenciamento de infraestrutura para alterar o tipo de recurso se a restrição estiver próxima da utilização. Esse fluxo de trabalho deve incluir testes de carga como prática recomendada para verificar se o novo tipo de recurso é o correto com as novas restrições.
+ Migre o recurso identificado para o novo tipo de recurso usando os procedimentos e os processos existentes.
## Recursos
**Práticas recomendadas relacionadas:**
+ [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 restrições e as cotas 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 Garantir 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)
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
**Documentos relacionados:**
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2)
+ [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?)
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+ [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
**Ferramentas relacionadas:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP02 Gerenciar cotas de serviço de várias contas e regiões
Se você estiver usando várias contas ou regiões, solicite as cotas adequadas em todos os ambientes nos quais suas workloads de produção são executadas.
**Resultado desejado:** os serviços e as aplicações não devem ser afetados pelo esgotamento da cota de serviço para configurações que abrangem contas ou regiões ou que têm designs de resiliência que usam failover de conta, zona ou região.
**Antipadrões comuns:**
+ Permitir que a utilização de recursos em uma região de isolamento aumente sem nenhum mecanismo para manter a capacidade das demais.
+ Configurar manualmente todas as cotas nas regiões de isolamento de forma independente.
+ Não considerar o efeito das arquiteturas de resiliência (como ativa ou passiva) em necessidades futuras de cota durante a degradação na região que não é a principal.
+ Não avaliar as cotas regularmente e fazer alterações necessárias em cada região e conta nas quais a workload é executada.
+ Não utilizar [modelos de solicitação de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html) para solicitar aumentos em várias regiões e contas.
+ Não atualizar as cotas de serviço por imaginar incorretamente que aumentar as cotas tem implicações de custo, como solicitações de reserva computacional.
**Benefícios do estabelecimento desta prática recomendada:** confirmar que você pode lidar com sua carga atual em contas ou regiões secundárias se os serviços regionais ficarem indisponíveis. Isso pode ajudar a reduzir o número de erros ou níveis de degradações que ocorrem durante a perda da região.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto
## Orientações para a implementação
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. Manter um alto grau de resiliência exige que as cotas de serviço sejam avaliadas de forma contínua (sejam elas automatizadas ou manuais).
Com mais workloads abrangendo regiões devido à implementação de designs usando as abordagens *Ativo/Ativo*, *Ativo/Passivo: Quente*, *Ativo/Passivo: Frio* e *Ativo/Passivo: Luz piloto*, é essencial entender todos os níveis de cota de contas e regiões. Padrões de tráfego passados nem sempre são um bom indicador de que a cota de serviço está definida corretamente.
Igualmente importante, o limite do nome da cota de serviço nem sempre é o mesmo para cada região. Em uma região, o valor pode ser cinco e em outra região pode ser dez. O gerenciamento dessas cotas deve abranger todos os mesmos serviços, contas e regiões para fornecer resiliência consistente sob carga.
Reconcilie todas as diferenças de cota de serviço em todas as diferentes regiões (Região ativa ou Região passiva) e crie processos para reconciliar de forma contínua essas diferenças. Os planos de teste de failovers de região passiva raramente são escalados para a capacidade ativa de pico, o que significa que os exercícios de simulações teóricas e dias de teste podem não encontrar diferenças em cotas de serviço entre regiões e também depois manter os limites corretos.
É muito importante rastrear e avaliar o *desvio de cotas de serviço*, a condição em que os limites de uma cota de serviço específica são alterados em uma região e não em todas. É necessário pensar em alterar a cota em regiões com tráfego ou que possam ter tráfego.
+ 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.
+ 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. Esses valores devem ser comparados em relação a diferenças.
**Etapas da implementação**
+ Analise os valores do Service Quotas que possam ter ultrapassado um nível de risco de uso. O AWS Trusted Advisor oferece alertas para violações de limite de 80% e 90%.
+ Analise os valores de cotas de serviço em todas as regiões passivas (em um design ativo/passivo). Verifique se a carga será executada com êxito em regiões secundárias em caso de falha na região principal.
+ Automatize a avaliação se ocorreu algum desvio de cota de serviço entre as regiões na mesma conta e aja adequadamente para alterar os limites.
+ Se as unidades organizações (UO) do cliente estiverem estruturadas da forma compatível, os modelos de cota de serviço deverão ser atualizados para refletir alterações em todas as cotas que devem ser aplicadas a várias regiões e contas.
+ Crie um modelo e associe regiões à alteração de cota.
+ Analise todos os modelos de cota de serviço existentes para todas as alterações necessárias (região, limites e contas).
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL01-BP01 Conhecimento das cotas e restrições de serviço](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP03 Acomodar as restrições e as cotas 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 Garantir 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)
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
**Documentos relacionados:**
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2)
+ [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?)
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+ [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
**Serviços relacionados:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP03 Acomodar as restrições e as cotas fixas de serviço por meio da arquitetura
Esteja ciente das cotas de serviço, das restrições do serviço e dos limites de recursos físicos que não podem ser alterados. Projete arquiteturas para aplicações e serviços visando evitar que esses limites afetem a confiabilidade.
Os exemplos incluem largura de banda da rede, tamanho da carga útil da invocação da função sem servidor, taxa de intermitência de aceleração para um gateway da API e conexões simultâneas de usuários com um banco de dados.
**Resultado desejado:** a aplicação ou o serviço tem o desempenho esperado em condições de tráfego normal e alto. Elas foram projetadas para funcionar com as limitações referentes às restrições ficas ou cotas de serviço do recurso.
**Antipadrões comuns:**
+ Escolher um design que usa um recurso de um serviço sem saber que há restrições de design que causarão falha à medida que você escala.
+ Usar parâmetros de comparação irrealistas e que atingirão as cotas fixas do serviço durante os testes. Por exemplo, executar testes em um limite de intermitência mas por um período estendido.
+ Escolher um design que não possa ser escalado nem modificado caso seja necessário ultrapassar as cotas fixas do serviço. Por exemplo, um tamanho de carga útil do SQS de 256 KB.
+ A capacidade de observação não foi projetada nem implementada para monitorar e alertar sobre os limites das cotas de serviço que podem estar em risco durante eventos com tráfego alto.
**Benefícios do estabelecimento dessa prática recomendada:** verificar se a aplicação será executada em todos os níveis de carga de serviços projetados sem interrupção ou dano.
**Nível de risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
Ao contrário das cotas de serviço flexíveis ou de recursos que são substituídos com unidades de capacidade mais altas, as cotas fixas dos serviços da AWS não podem ser alteradas. Isso significa que todos esses tipos de serviços da AWS devem ser avaliados com relação a possíveis limites de capacidade rígidos quando usados em um design da aplicação.
Os limites rígidos são mostrados no console do Service Quotas. Se a coluna mostrar `ADJUSTABLE = No`, o serviço tem um limite rígido. Os limites rígidos também são mostrados em algumas páginas de configuração de recursos. Por exemplo, o Lambda tem limites rígidos específicos que não podem ser ajustados.
Como exemplo, ao projetar uma aplicação Python para ser executada em uma função do Lambda, a aplicação deve ser avaliada para determinar se há alguma chance de o Lambda ser executado por mais de 15 minutos. Se código puder ser executado mais do que esse limite de cota de serviço, tecnologias ou designs alterativos devem ser considerados. Se esse limite for atingido depois da implantação na produção, a aplicação sofrerá uma degradação e interrupção até que isso possa ser corrigido. Ao contrário das cotas flexíveis, não há um método para alterar esses limites mesmo sob eventos de emergência de gravidade 1.
Depois que a aplicação for implantada em um ambiente de teste, devem ser usadas estratégias para descobrir se algum limite rígido pode ser atingido. Testes de estresse, testes de carga e testes de caos devem fazer parte do plano de teste de introdução.
**Etapas da implementação**
+ Revise a lista completa de serviços da AWS que poderiam ser usados na fase de design da aplicação.
+ Revise os limites da cota flexível e os da cota rígida para todos esses serviços. Nem todos os limites são mostrados no console do Service Quotas. Alguns serviços [descrevem esses limites em locais alternativos](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).
+ À medida que você planeja a aplicação, revise os fatores que impulsionam a tecnologia e os negócios da workload, como resultados empresariais, casos de uso, sistemas dependentes, destinos de disponibilidade e objetos de recuperação de desastres. Permita que os fatores que impulsionam a tecnologia e os negócios orientem o processo para identificar o sistema distribuído certo para sua workload.
+ Analise a carga do serviço nas regiões e contas. Muitos limites rígidos são regionais para os serviços. No entanto, alguns limites são por conta.
+ Analise arquiteturas de resiliência quanto ao uso de recursos durante uma falha de zona e de região. Na progressão de designs de várias regiões usando as abordagens ativo/ativo, ativo/passivo – quente, ativo/passivo – frio e ativo/passivo – luz-piloto, esses casos de falha resultarão em maior uso. Isso cria um possível caso de uso para atingir limites rígidos.
## Recursos
**Práticas recomendadas relacionadas:**
+ [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-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 Garantir 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)
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
**Documentos relacionados:**
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2)
+ [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?)
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+ [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)
**Ferramentas relacionadas:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP04 Monitorar e gerenciar cotas
Avalie seu uso potencial e aumente suas cotas adequadamente, permitindo o crescimento planejado do uso.
**Resultado desejado:** sistemas ativos e automáticos que gerenciam e monitoram foram implantados. Essas soluções garantem que os limites de uso da cota sejam quase atingidos. Isso seria corrigido proativamente por mudanças na cota solicitada.
**Antipadrões comuns:**
+ Não configurar o monitoramento para verificar os limites da cota de serviço.
+ Não configurar o monitoramento de limites rígidos, embora esses valores não possam ser alterados.
+ Presumir que o tempo necessário para solicitar e proteger uma mudança de cota flexível seja imediato ou período curto.
+ Configurar alarmes para quando as cotas de serviço estiverem sendo atingidas, mas não ter um processo de resposta a um alerta.
+ Configurar alarmes apenas para serviços compatíveis com o AWS Service Quotas e não monitorar outros serviços da AWS.
+ Não considerar o gerenciamento da cota para designs com resiliência de várias regiões, como as abordagens ativo/ativo, ativo/passivo – quente, ativo/passivo – frio e ativo/passivo – luz-piloto.
+ Não avaliar as diferenças de cota entre regiões.
+ Não avaliar as necessidades de cada região com relação a uma solicitação de aumento de cota específica.
+ Não utilizar [modelos para o gerenciamento de cota de várias regiões](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html).
**Benefícios do estabelecimento dessa prática recomendada:** o rastreamento automático do AWS Service Quotas e o monitoramento do uso em relação a essas cotas permitirão que você veja quando estiver perto de atingir um limite de cota. Também é possível usar esse monitoramento de dados para ajudar a limitar qualquer dano devido à exaustão da cota.
**Nível de risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
Para dispositivos compatíveis, é possível monitorar as cotas configurando vários serviços diferentes que podem avaliar e, então, enviar alertas ou alarmes. Isso pode auxiliar o monitoramento do uso e alertar quando você estiver se aproximando das cotas. Esses alarmes podem ser acionados pelo AWS Config, por funções do Lambda, pelo Amazon CloudWatch ou pelo AWS Trusted Advisor. Você também pode usar filtros de métrica no CloudWatch Logs para pesquisar e extrair padrões nos logs a fim de determinar se o uso está se aproximando dos limites de cota.
**Etapas da implementação**
Para monitoramento:
+ Capture o consumo atual de recursos (por exemplo, buckets ou instâncias). Use operações de API de serviço, como a API do Amazon EC2 `DescribeInstances` para coletar o consumo atual de recursos.
+ Capture as cotas atuais que são essenciais e aplicáveis aos serviços usando:
+ AWS Service Quotas
+ AWS Trusted Advisor
+ Documentação da AWS
+ Páginas específicas de serviços da AWS
+ AWS Command Line Interface (AWS CLI)
+ AWS Cloud Development Kit (AWS CDK)
+ Use o AWS Service Quotas, um serviço da AWS que ajuda você a gerenciar as cotas de mais de 250 serviços da AWS em um único local.
+ Use os limites de serviço do Trusted Advisor para monitorar os limites de serviço atuais em vários limites.
+ Use o histórico da cota de serviço (console ou AWS CLI) para verificar os aumentos regionais.
+ Compare as alterações na cota de serviço em cada região e cada conta para criar equivalência, se necessário.
Para gerenciamento:
+ Automático: configure uma regra personalizada do AWS Config para verificar as cotas de serviço nas regiões e comparar as diferenças.
+ Automático: configure uma função programada do Lambda para verificar as cotas de serviço nas regiões e comparar as diferenças.
+ Manual: verifique as cotas de serviço por meio da AWS CLI, da API ou do Console da AWS para conferir as cotas de serviço nas regiões e comparar as diferenças. Relate as diferenças.
+ Se forem identificadas diferenças nas cotas entre as regiões, solicite uma mudança na cota, se necessário.
+ Avalie o resultado de todas as solicitações.
## Recursos
**Práticas recomendadas relacionadas:**
+ [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 restrições e as cotas fixas de serviço por meio da arquitetura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP05 Automatizar o gerenciamento de cotas](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Garantir 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)
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
**Documentos relacionados:**
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2)
+ [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?)
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+ [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)
**Ferramentas relacionadas:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# 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 Garantir que existe uma lacuna suficiente entre as cotas atuais e o uso máximo para acomodar o failover
Quando um recurso falha ou fica inacessível, ele ainda pode ser contabilizado nas cotas até ser encerrado com êxito. Verifique se as cotas abrangem a sobreposição de recursos inacessíveis ou com falha e suas substituições. Você deve considerar casos de uso como falha de rede, falha na zona de disponibilidade ou falhas regionais ao calcular essa lacuna.
**Resultado desejado:** falhas pequenas ou grandes em recursos ou na acessibilidade de recursos podem ser cobertas nos limites atuais do serviço. As falhas de zona, falhas de rede ou até mesmo falhas regionais têm sido consideradas no planejamento de recursos.
**Antipadrões comuns:**
+ Configurar cotas de serviço com base nas necessidades atuais sem considerar os cenários de failover.
+ Não considerar as entidades principais de estabilidade estática ao calcular a cota de pico de um serviço.
+ Não considerar o potencial de recursos inacessíveis no cálculo da cota total necessária para cada região.
+ Não considerar os limites de isolamento de falhas de serviço da AWS para alguns serviços e seus padrões de uso possivelmente anormais.
**Benefícios do estabelecimento dessa prática recomendada:** quando um evento de interrupção do serviço afeta a disponibilidade da aplicação, a nuvem permite implementar estratégias para mitigar ou se recuperar desses eventos. Essas estratégias geralmente incluem a criação de recursos adicionais para substituir os que falharam ou estão inacessíveis. Sua estratégia de cota acomodaria essas condições de failover e não incluiria danos adicionais devido à exaustão do limite de serviço.
**Nível de risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
Ao avaliar os limites de cota, considere casos de failover que podem ocorrer devido a algum dano. Os seguintes tipos de casos de failover devem ser considerados:
+ Uma VPC interrompida ou inacessível.
+ Uma sub-rede inacessível.
+ Uma zona de disponibilidade foi danificada o suficiente para afetar a acessibilidade de muitos recursos.
+ Várias rotas de rede ou pontos de ingresso e egresso são bloqueados ou alterados.
+ Uma região foi danificada o suficiente para afetar a acessibilidade de muitos recursos.
+ Há vários recursos, mas nem todos são afetados por uma falha em uma região ou zona de disponibilidade.
Falhas como as da lista acima poderiam ser o gatilho para iniciar um evento de failover. A decisão de fazer failover é única para cada situação e cliente, já que o impacto na empresa pode variar drasticamente. No entanto, ao decidir operacionalmente realizar failover de aplicações ou serviços, o planejamento da capacidade de recursos no local de failover e as cotas relacionadas devem ser solucionados antes do evento.
Revise as cotas de cada serviço considerando os picos mais altos do que o normal que podem ocorrer. Esses picos podem estar relacionados aos recursos que podem ser acessados devido às redes ou permissões, mas ainda estão ativos. Os recursos ativos não encerrados ainda serão contabilizados no limite de cota do serviço.
**Etapas da implementação**
+ Verifique se há uma lacuna suficiente entre a cota de serviço e o uso máximo para acomodar um failover ou uma perda de acessibilidade.
+ 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 o atendimento das solicitações de aumento de cota.
+ Determine os requisitos de confiabilidade (também conhecidos como “número de noves”).
+ Estabeleça seus 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 uma reserva adequada (por exemplo, 15%) do limite atual.
+ Inclua cálculos para estabilidade estática (por zona e região), quando apropriado.
+ Planeje o aumento do consumo (por exemplo, monitore suas tendências de consumo).
+ Considere o impacto da estabilidade estática das suas workloads mais críticas. Avalie os recursos em conformidade com um sistema estaticamente estável em todas as regiões e zonas de disponibilidade.
+ Considere o uso de reservas de capacidade sob demanda para programas a capacidade antecipadamente de qualquer failover. Isso pode ser uma estratégia útil durante as programações empresariais mais críticas para reduzir possíveis riscos de obter a quantidade o tipo certo de recursos durante o failover.
## Recursos
**Práticas recomendadas relacionadas:**
+ [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 restrições e as cotas 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)
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
**Documentos relacionados:**
+ [AWS Pilar Confiabilidade da Well-Architected Framework: Disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [AWS Service Quotas (anteriormente chamado de limites de serviço)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor Best Practice Checks (Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Service Limits (Limites de serviço))](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS limit monitor on AWS answers](https://aws.amazon.com/answers/account-management/limit-monitor/) (Monitor de limites da AWS em respostas da AWS)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (Limites de serviço do Amazon EC2)
+ [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) (O que é o Service Quotas?)
+ [ How to Request Quota Increase ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (Como solicitar aumento de cota)
+ [ Service endpoints and quotas ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) (Endpoints e cotas de serviço)
+ [Guia do usuário do Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [ Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/) (Monitor de cotas da AWS)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [AWS para dados ](https://aws.amazon.com/data/)
+ [ O que significa integração contínua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ O que significa distribuição contínua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiro do APN: parceiros que podem ajudar no gerenciamento de configuração](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/) (Gerenciar o ciclo devida da conta em ambientes de SaaS de conta por locatário na AWS)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/) (Gerenciar e monitorar o controle de utilização de API em workloads)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/) (Exibir recomendações do AWS Trusted Advisor em grande escala com AWS Organizations)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/) (Automatizar aumentos de limite de serviço e suporte empresarial com AWS Control Tower)
+ [Ações, recursos e chaves de condição do Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)
**Vídeos relacionados:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc) (Exibir e gerenciar cotas para serviços da AWS usando o Service Quotas)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ) (Demonstração de cotas do AWS IAM)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)
**Ferramentas relacionadas:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# CONFIABILIDADE 2. Como planejar sua topologia de rede?
Muitas vezes, as workloads 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
Criar uma conectividade de rede altamente disponível nos endpoints públicos das workloads pode ajudar a reduzir o tempo de inatividade devido à perda de conectividade e melhorar a disponibilidade e o SLA da workload. Para que isso seja possível, use DNS altamente disponível, redes de entrega de conteúdo (CDNs), gateways de API, balanceamento de carga ou proxies reversos.
**Resultado desejado:** é fundamental planejar, criar e operacionalizar a conectividade de rede altamente disponível para endpoints públicos. Se a workload ficar inacessível devido a uma perda de conectividade, mesmo se ela estiver em execução e indisponível, os clientes verão o sistema como inativo. Ao combinar a conectividade de rede altamente disponível e resiliente para os endpoints públicos da workload, junto com uma arquitetura resiliente para a própria workload, é possível fornecer o melhor nível possível de serviço e disponibilidade possível aos clientes.
O AWS Global Accelerator, o Amazon CloudFront, o Amazon API Gateway, os URLs de função do AWS Lambda, as APIs do AWS AppSync e o Elastic Load Balancing (ELB) fornecem endpoints públicos altamente disponíveis. O Amazon Route 53 fornece um serviço de DNS altamente disponível para a resolução do nome de domínio a fim de verificar se os endereços do endpoint público podem ser resolvidos.
Também é possível avaliar os dispositivos de software do AWS Marketplace com relação ao proxy e ao balanceamento de carga.
**Antipadrões comuns:**
+ Projetar uma workload altamente disponível sem planejar a alta disponibilidade do DNS e da conectividade de rede.
+ Usar endereços de internet públicos em instâncias ou contêineres individuais e gerenciar a conectividade com eles por meio de DNS.
+ Usar endereços IP em vez de nomes de domínio para localizar serviços.
+ Não testar cenários em que a conectividade com os endpoints públicos é perdida.
+ Não analisar as necessidades de throughput de rede e os padrões de distribuição.
+ Não testar nem se planejar para cenários em que a conectividade de rede da internet com os endpoints públicos da workload possam ser interrompidos.
+ Fornecer conteúdo (como páginas da web, ativos estáticos ou arquivos de mídia) para uma grande área geográfica e não usar uma rede de entrega de conteúdo.
+ Não se planejar para ataques de negação distribuída de serviços (DDoS). Ataques DDoS representam um risco de obstruir o tráfego legítimo e reduzir a disponibilidade para os usuários.
**Benefícios do estabelecimento dessa prática recomendada:** projetar-se para uma conectividade de rede resiliente e altamente disponível garante que a workload esteja acessível e disponível para os usuários.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto
## Orientações para a implementação
No centro da criação de uma conectividade de rede altamente disponível com os endpoints públicos está o roteamento do tráfego. Para verificar se o tráfego consegue acessar os endpoints, o DNS deve poder resolver os nomes de domínio para os endereços IP correspondentes. Use um [Sistema de Nomes de Domínio (DNS)](https://aws.amazon.com/route53/what-is-dns/) escalável e altamente disponível, como o Amazon Route 53, para gerenciar os registros de DNS do domínio. Também é possível usar verificações de integridade fornecidas pelo Amazon Route 53. As verificações de integridade conferem se a aplicação está acessível, disponível e funcional, e podem ser configuradas de uma maneira que imitem o comportamento do usuário, como solicitar uma página da web ou um URL específico. Em caso de falha, o Amazon Route 53 responde às solicitações de resolução de DNS e direciona o tráfego somente aos endpoints íntegros. Também é possível considerar o uso dos recursos DNS GEO e Roteamento baseado em latência oferecidos pelo Amazon Route 53.
Para verificar se a própria workload é altamente disponível, use o Elastic Load Balancing (ELB). O Amazon Route 53 pode ser usado para direcionar o tráfego para o ELB, o que distribui o tráfego às instâncias de computação de destino. Também é possível usar o Amazon API Gateway com o AWS Lambda para obter uma solução sem servidor. Os clientes também podem executar workloads em várias Regiões da AWS. Com o [padrão multissite ativo/ativo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/), a workload pode fornecer o tráfego de várias regiões. Com um padrão multissite ativo/passivo, a workload fornece tráfego da região ativa enquanto os dados são replicados para a região secundária e se torna ativa caso ocorra uma falha na região primaria. As verificações de integridade do Route 53 podem então ser usadas para controlar o failover de DNS de qualquer endpoint em uma região primária para um endpoint em uma região secundária, verificando se a workload está acessível e disponível para os usuários.
O Amazon CloudFront fornece uma API simples para distribuir o conteúdo com baixa latência e altas taxas de transferência de dados atendendo a solicitações usando uma rede de locais de borda ao redor do mundo. As redes de entrega de conteúdo (CDNs) atendem os clientes fornecendo conteúdo localizado ou armazenado em cache em um local próximo ao usuário. Isso também melhora a disponibilidade da aplicação, já que a carga do conteúdo é migrada dos servidores para os [locais da borda](https://aws.amazon.com/products/networking/edge-networking/) do CloudFront. Os locais da borda e os caches de borda regionais armazenam cópias em cache do conteúdo próximo aos visualizadores, resultando em recuperação rápida e aumentando a acessibilidade e a disponibilidade da workload.
Para workloads com usuários distribuídos geograficamente, o AWS Global Accelerator ajuda a melhorar a disponibilidade e o desempenho das aplicações. O AWS Global Accelerator fornece endereços IP estáticos anycast que servem como um ponto de entrada fixo para a aplicação hospedada em uma ou mais Regiões da AWS. Isso permite que o tráfego entre na rede global da AWS o mais próximo possível dos usuários, melhorando a acessibilidade e a disponibilidade da workload. O AWS Global Accelerator também monitora a integridade dos endpoints da aplicação usando as verificações de integridade de TCP, HTTP e HTTPS. Qualquer mudança na integridade ou na configuração dos endpoints aciona o redirecionamento do tráfego de usuários para endpoints íntegros que oferecem o melhor desempenho e disponibilidade aos usuários. Além disso, o AWS Global Accelerator tem um design de isolamento de falhas que usa dois endereços IPv4 estáticos que são fornecidos por zonas de rede independentes, aumentando a disponibilidade das aplicações.
Para ajudar a proteger os clientes de ataques DDoS, a AWS oferece o AWS Shield Standard. O Shield Standard vem automaticamente habilitado e protege de ataques de infraestrutura comum (camadas três e quatro) como inundações de SYN/UDP e ataques de reflexão para comportar a alta disponibilidade das aplicações na AWS. Para obter mais proteções contra ataques maiores e mais sofisticados (como inundações de UDP), ataques de exaustão de estado (como inundações de TCP SYN) e para ajudar a proteger as aplicações executadas nos serviços Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53, considere o uso do AWS Shield Advanced. Para proteção contra ataques de camada da aplicação como inundações de HTTP POST e GET, use o AWS WAF. O AWS WAF pode usar condições de scripts entre sites, endereços IP, cabeçalhos HTTP, corpo HTTP, strings de URI e injeção de SQL para determinar se uma solicitação deve ser bloqueada ou permitida.
**Etapas da implementação**
1. Configure DNS de alta disponibilidade: o Amazon Route 53 é um serviço da web de [Sistema de Nomes de Domínio (DNS)](https://aws.amazon.com/route53/what-is-dns/) escalável e altamente disponível. O Route 53 conecta as solicitações dos usuários às aplicações da internet executadas na AWS ou on-premises. Para obter mais informações, consulte [Configurar o Amazon Route 53 como serviço DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html).
1. Configure verificações de integridade: ao usar o Route 53, verifique se somente os destinos íntegros podem ser resolvidos. Comece [criando verificações de integridade do Route 53 e configurando o failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Os aspectos a seguir são importantes a considerar ao configurar verificações de integridade:
1. [ How Amazon Route 53 determines whether a health check is healthy ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)(Como o Amazon Route 53 determina se uma verificação de integridade é íntegra)
1. [ Criar, atualizar e excluir verificações de integridade ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)
1. [ Monitorar o status da verificação de integridade e receber notificações ](https://docs.aws.amazon.com/)
1. [ Práticas recomendadas do Amazon Route 53 DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)
1. [ Conectar o serviço de DNS aos endpoints. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)
1. Ao usar o Elastic Load Balancing como destino do tráfego, crie um [registro de alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) usando o Amazon Route 53 que aponte para o endpoint regional do balanceador de carga. Durante a criação do registro de alias, defina a opção “Evaluate target health” (Avaliar integridade do destino) como “Yes” (Sim).
1. Para workloads sem servidor ou APIs privadas quando o API Gateway é usado, use o [Route 53 para redirecionar o tráfego para o API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Decida sobre uma rede de entrega de conteúdo.
1. Para entregar conteúdo usando locais da borda mais próximos ao usuário, comece entendendo [como o CloudFront entrega conteúdo](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html).
1. Comece com uma [distribuição simples do CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). O CloudFront então sabe de onde você quer que o conteúdo seja entregue e os detalhes sobre como rastrear e gerenciar a entrega de conteúdo. É importante entender e considerar os aspectos a seguir ao configurar uma distribuição do CloudFront:
1. [ Como funciona o armazenamento em cache com os pontos de presença do CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)
1. [ Aumentar a taxa de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)
1. [ Usar o Amazon CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)
1. [ Otimizar a alta disponibilidade com o failover de origem do CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)
1. Configure a proteção da camada da aplicação: o AWS WAF ajuda você a se proteger contra explorações e bots comuns da web que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos em excesso. Para obter uma compreensão mais profunda, veja [como o AWS WAF funciona](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) e, quando estiver pronto para implementar proteções contra inundações HTTP POST E GET da camada de aplicações, consulte [Getting started with AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) (Conceitos básicos do AWS WAF). Também é possível usar o AWS WAF com o CloudFront. Consulte a documentação sobre [como o AWS WAF funciona com os recursos do Amazon CloudFront](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html).
1. Configure proteção adicional contra DDoS: por padrão, todos os clientes da AWS recebem proteção contra ataques de DDoS da camada de transporte e rede comuns e que ocorrem com mais frequência que visam seu site ou sua aplicação com o AWS Shield Standard sem custo adicional. Para proteção adicional de aplicações voltadas para a internet executadas no Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator e Amazon Route 53, considere o [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) e consulte [exemplos de arquiteturas resilientes a DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Para proteger sua workload e seus endpoints públicos de ataques de DDoS, consulte [Getting started with AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html) (Conceitos básicos do AWS Shield Advanced).
## Recursos
**Práticas recomendadas relacionadas:**
+ [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)
+ [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-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](rel_withstand_component_failures_notifications_sent_system.md)
**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)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [O que é o Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [ Network Connectivity capability - Establishing Your Cloud Foundations ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)(Recurso de conectividade de rede: como estabelecer as bases da nuvem)
+ [ O que é o Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ What are AWS WAF, AWS Shield, and AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)(O que são o AWS WAF, o AWS Shield e o AWS Firewall Manager?)
+ [ O que é o Amazon Route 53 Application Recovery Controller? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Configurar verificações de integridade personalizadas para failover de DNS ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)(AWS re:Invent 2022: melhore o desempenho e a disponibilidade com o AWS Global Accelerator)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)(AWS re:Invent 2020: gerenciamento de tráfego global com o Amazon Route 53)
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications ](https://www.youtube.com/watch?v=mwUV5skJJ0s)(AWS re:Invent 2022: operar aplicações Multi-AZ altamente disponíveis)
+ [AWS re:Invent 2022 - Dive deep on AWS networking infrastructure ](https://www.youtube.com/watch?v=HJNR_dX8g8c)(AWS re:Invent 2022: aprofundamento na infraestrutura de rede da AWS)
+ [AWS re:Invent 2022 - Building resilient networks ](https://www.youtube.com/watch?v=u-qamiNgH7Q)(AWS re:Invent 2022: criar redes resilientes)
**Exemplos relacionados:**
+ [ Disaster Recovery with Amazon Route 53 Application Recovery Controller (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)(Recuperação de desastres com o Amazon Route 53 Application Recovery Controller (ARC))
+ [ Reliability Workshops ](https://wellarchitectedlabs.com/reliability/)(Workshops sobre confiabilidade)
+ [Workshop sobre o AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
# 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/2023-10-03/framework/images/without-transit-gateway.png)
![\[Diagrama mostrando o uso do AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/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**
+ [CONFIABILIDADE 3. Como projetar sua arquitetura de serviços de workload?](rel-03.md)
+ [CONFIABILIDADE 4. Como projetar interações em um sistema distribuído para evitar falhas?](rel-04.md)
+ [CONFIABILIDADE 5. Como projetar interações em um sistema distribuído para mitigar ou resistir a falhas?](rel-05.md)
# CONFIABILIDADE 3. Como projetar sua arquitetura de serviços de workload?
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 enfocados em 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/2023-10-03/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 enfocados em 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 enfocados em domínios e funcionalidades de negócios específicos
A arquitetura orientada a serviços (SOA) define serviços com funções bem delineadas que seguem as necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto delimitado para traçar limites de serviço ao longo dos limites do contexto de negócios. O foco nos domínios de negócios e na funcionalidade ajuda as equipes a definir requisitos independentes de confiabilidade para seus serviços. Contextos delimitados isolam e encapsulam a lógica de negócios, permitindo que as equipes raciocinem melhor sobre como lidar com falhas.
**Resultado desejado:** Em conjunto, engenheiros e partes interessadas do negócio definem contextos delimitados e os usam para projetar sistemas como serviços que cumprem funções empresariais específicas. Essas equipes usam práticas estabelecidas, como Event Storming, para definir os requisitos. As novas aplicações são projetadas como serviços, limites bem definidos e acoplamento fraco. Os monólitos existentes são decompostos em [contextos delimitados](https://martinfowler.com/bliki/BoundedContext.html) e os projetos de sistemas migram para arquiteturas SOA ou de microsserviços. Quando os monólitos são refatorados, abordagens estabelecidas, como contextos de bolha e padrões de decomposição de monólitos, são aplicadas.
Os serviços orientados a domínios são executados como um ou mais processos que não compartilham o estado. Eles respondem de forma independente às flutuações na demanda e lidam com cenários de falha à luz dos requisitos específicos do domínio.
**Antipadrões comuns:**
+ As equipes são formadas em torno de domínios técnicos específicos, como UI e UX, middleware ou banco de dados, em vez de domínios empresariais específicos.
+ As aplicações abrangem as responsabilidades do domínio. Serviços que abrangem contextos delimitados podem ser mais difíceis de manter, exigir maiores esforços de teste e que várias equipes de domínio participem das atualizações de software.
+ As dependências de domínio, como as bibliotecas de entidades de domínio, são compartilhadas entre serviços, de forma que as alterações em um domínio de serviço exijam alterações em outros domínios de serviço.
+ Os contratos de serviço e a lógica de negócios não expressam entidades em uma linguagem de domínio comum e consistente, ocasionando camadas de tradução que complicam os sistemas e aumentam os esforços de depuração.
**Benefícios de estabelecer esta prática recomendada:** As aplicações são projetadas como serviços independentes delimitados por domínios de negócios e usam uma linguagem comercial comum. Os serviços podem ser testados e implantados de forma independente. Os serviços atendem aos requisitos de resiliência específicos do domínio implementado.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
A decisão orientada por domínio (DDD) é a abordagem fundamental para projetar e criar software em torno de domínios empresariais. É útil trabalhar com uma framework existente ao criar serviços enfocados em domínios empresariais. Ao trabalhar com aplicações monolíticas existentes, você pode utilizar os padrões de decomposição que fornecem técnicas estabelecidas para modernizar aplicações em serviços.
![\[Fluxograma descrevendo a abordagem da decisão orientada por domínio.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)
## Etapas da implementação
+ As equipes podem realizar workshops de [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) a fim de identificar rapidamente eventos, comandos, agregados e domínios em um formato leve de notas adesivas.
+ Depois que as entidades e as funções do domínio forem formadas em um contexto de domínio, você poderá dividir seu domínio em serviços usando [contexto delimitado](https://martinfowler.com/bliki/BoundedContext.html), em que entidades que compartilham recursos e atributos semelhantes são agrupadas. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços.
+ Por exemplo, as entidades do site Amazon.com podem incluir pacote, entrega, programação, preço, desconto e moeda.
+ Pacote, entrega e cronograma são agrupados no contexto de envio, enquanto preço, desconto e moeda são agrupados no contexto de preços.
+ [Decompor monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) descreve padrões para refatorar microsserviços. O uso de padrões para decomposição por capacidade comercial, subdomínio ou transação se alinha bem às abordagens orientadas por domínio.
+ Técnicas táticas, como o [contexto de bolha,](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) permitem introduzir o DDD em aplicações existentes ou legadas sem reformulações antecipadas e compromissos totais com o DDD. Em uma abordagem de contexto de bolha, um pequeno contexto delimitado é estabelecido usando um mapeamento e coordenação de serviços, ou [camada anticorrupção](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), que protege o modelo de domínio recém-definido de influências externas.
Depois que as equipes realizarem a análise de domínio e definirem entidades e contratos de serviço, elas podem utilizar os serviços da AWS para implementar o design orientado por domínio como serviços baseados em nuvem.
+ Comece o desenvolvimento definindo testes que exercitem as regras de negócios de seu domínio. O desenvolvimento orientado por testes (TDD) e o desenvolvimento orientado por comportamento (BDD) ajudam as equipes a manter os serviços enfocados na solução de problemas de negócios.
+ Selecione os [serviços da AWS](https://aws.amazon.com/microservices/) que mais bem atendam aos requisitos de domínio de sua empresa e [arquitetura de microsserviços](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [tecnologia sem servidor da AWS](https://aws.amazon.com/serverless/) permite que sua equipe enfoque a lógica de domínio específica em vez de gerenciar servidores e infraestrutura.
+ [Contêineres na AWS](https://aws.amazon.com/containers/) simplificam o gerenciamento de sua infraestrutura para que você possa enfocar nos requisitos de domínio.
+ [Bancos de dados com propósito específico](https://aws.amazon.com/products/databases/) ajudam você a adequar seus requisitos de domínio ao tipo de banco de dados mais adequado.
+ [Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) descreve uma framework para criar lógica de negócios em serviços que funcionam retroativamente a partir de um domínio empresarial para atender aos requisitos funcionais e, depois, conectar adaptadores de integração. Os padrões que separam os detalhes da interface da lógica de negócios com serviços da AWS ajudam as equipes a enfocar na funcionalidade do domínio e melhorar a qualidade do software.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
**Documentos relacionados:**
+ [AWS Microsserviços](https://aws.amazon.com/microservices/)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices (Como dividir um monólito em microsserviços)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Conceitos básicos do DDD quando cercado por sistemas herdados)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Design orientado por domínio: como lidar com a complexidade no núcleo do software) ](https://www.amazon.com/gp/product/0321125215)
+ [ Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decompor monólitos em microsserviços ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Mensagens entre contextos delimitados ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microsserviços ](https://www.martinfowler.com/articles/microservices.html)
+ [ Desenvolvimento orientado por testes ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Desenvolvimento orientado pelo comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Exemplos relacionados:**
+ [ Workshop nativo da nuvem corporativa ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) (Como projetar microsserviços nativos em nuvem na AWS (do DDD/EventStormingWorkshop)) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Ferramentas relacionadas:**
+ [ Bancos de dados da Nuvem AWS](https://aws.amazon.com/products/databases/)
+ [ Tecnologia sem servidor na AWS](https://aws.amazon.com/serverless/)
+ [ Contêineres na AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fornecer contratos de serviço por API
Os contratos de serviço são acordos documentados entre produtores e consumidores de API estabelecidos em uma definição de API legível por máquina. Uma estratégia de versionamento de contrato permite que os consumidores continuem usando a API existente e migrem suas aplicações para uma API mais recente quando estiverem prontos. A implantação do produtor pode acontecer a qualquer momento, desde que o contrato seja cumprido. A equipe de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API.
**Resultado desejado:**
**Antipadrões comuns:** As aplicações criadas com arquiteturas orientadas a serviços ou microsserviços podem operar de forma independente e, ao mesmo tempo, ter uma dependência de runtime integrada. As alterações implantadas em um consumidor ou produtor de API não interrompem a estabilidade do sistema geral quando os dois lados seguem um contrato de API comum. Os componentes que se comunicam por meio de APIs de serviço podem realizar lançamentos funcionais independentes, atualizações para dependências de runtime ou fazer failover em um site de recuperação de desastres (DR) com pouco ou nenhum impacto entre si. Além disso, serviços diferentes são capazes de escalar de forma independente a absorção da demanda de recursos sem exigir que outros serviços escalem simultaneamente.
+ Criar APIs de serviço sem esquemas altamente tipificados. Isso ocasiona APIs que não podem ser usadas para gerar vinculações de API e payloads que não possam ser validadas de maneira programática.
+ Não adotar uma estratégia de versionamento, o que força os consumidores de API a atualizarem e lançarem ou falharem com a evolução dos contratos de serviço.
+ Mensagens de erro que vazam detalhes da implementação do serviço subjacente em vez de descreverem falhas de integração no contexto e no idioma do domínio.
+ Não usar contratos de API para desenvolver casos de teste e simular implementações de API para permitir testes independentes dos componentes do serviço.
**Benefícios de estabelecer esta prática recomendada:** Sistemas distribuídos compostos por componentes que se comunicam por meio de contratos de serviço de API podem aumentar a confiabilidade. Os desenvolvedores podem detectar possíveis problemas no início do processo de desenvolvimento com a verificação de tipo durante a compilação a fim de verificar se as solicitações e as respostas seguem o contrato da API e se os campos obrigatórios estão presentes. Os contratos de API oferecem uma interface clara de autodocumentação de APIs e oferecem melhor interoperabilidade entre diferentes sistemas e linguagens de programação.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Depois de identificar os domínios de negócios e determinar a segmentação da workload, você pode desenvolver suas APIs de serviço. Primeiro, defina contratos de serviço legíveis por máquina para APIs e, depois, implemente uma estratégia de versionamento de API. Quando estiver pronto para integrar serviços em protocolos comuns, como REST, GraphQL ou eventos assíncronos, você poderá incorporar serviços da AWS à sua arquitetura para integrar seus componentes com contratos de API altamente tipificados.
**Serviços da AWS para contratos de API de serviços**
Incorpore serviços da AWS, incluindo [Amazon API Gateway](https://aws.amazon.com/api-gateway/), o [AWS AppSync](https://aws.amazon.com/appsync/)e o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) à sua arquitetura para usar contratos de serviço de API em sua aplicação. O Amazon API Gateway ajuda você a se integrar diretamente a serviços nativos da AWS e outros serviços da web. O API Gateway é compatível com a [especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification) e versionamento. O AWS AppSync é um endpoint [GraphQL](https://graphql.org/) gerenciado que você configura definindo um esquema GraphQL para definir uma interface de serviço para consultas, mutações e assinaturas. O Amazon EventBridge usa esquemas de eventos para definir eventos e gerar associações de código para seus eventos.
## Etapas da implementação
+ Primeiro, defina um contrato para sua API. Um contrato expressará os recursos de uma API, bem como definirá objetos e campos de dados altamente tipificados para a entrada e a saída da API.
+ Ao configurar APIs no API Gateway, você pode importar e exportar especificações da OpenAPI para seus endpoints.
+ [A importação de uma definição de OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica a criação de sua API e pode ser integrada a ferramentas de infraestrutura como código da AWS, como o [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e o [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [A exportação de uma definição de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica a integração a ferramentas de teste de API e oferece ao consumidor de serviços uma especificação de integração.
+ Você pode definir e gerenciar APIs do GraphQL com o AWS AppSync [definindo um arquivo de esquema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para gerar sua interface de contrato e simplificar a interação com modelos REST complexos, várias tabelas de banco de dados ou serviços legados.
+ [Projetos do AWS Amplify](https://aws.amazon.com/amplify/) integrados ao AWS AppSync geram arquivos de consulta JavaScript altamente tipificados para uso em sua aplicação, bem como uma biblioteca cliente do AWS AppSync GraphQL para [tabelas do Amazon DynamoDB](https://aws.amazon.com/dynamodb/) .
+ Quando você consome eventos de serviço do Amazon EventBridge, eles seguem os esquemas já existentes no registro do esquema ou os definidos com a especificação da OpenAPI. Com um esquema definido no registro, também é possível gerar vinculações de cliente a partir do contrato de esquema para integrar seu código aos eventos.
+ Estender ou realizar o versionamento de sua API. Estender uma API é uma opção mais simples ao adicionar campos que podem ser configurados com campos opcionais ou valores padrão para campos obrigatórios.
+ Contratos baseados em JSON para protocolos, como REST e GraphQL, podem ser uma boa opção para a extensão do contrato.
+ Contratos baseados em XML para protocolos, como SOAP, devem ser testados com consumidores de serviços para determinar a viabilidade da extensão do contrato.
+ Ao realizar o versionamento de uma API, considere implementar o controle de versão por procuração em que uma fachada é usada para oferecer compatibilidade com versões para que a lógica possa ser mantida em uma única base de código.
+ Com o API Gateway, você pode usar [mapeamentos de solicitações e respostas](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar a absorção de alterações no contrato estabelecendo uma fachada para fornecer valores padrão para novos campos ou para retirar os campos removidos de uma solicitação ou resposta. Com essa abordagem, o serviço subjacente pode manter uma única base de código.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços enfocados em domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
**Documentos relacionados:**
+ [ O que é uma API (interface de programação de aplicações)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.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/)
+ [ Trabalhar com extensões do API Gateway para OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ Especificação da OpenAPI ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: esquemas e tipos ](https:/graphql.org/learn/schema)
+ [ Vinculações de código do Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Exemplos relacionados:**
+ [ Amazon API Gateway: configurar uma API REST usando o OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Amazon API Gateway para a aplicação CRUD Amazon DynamoDB usando OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Padrões modernos de integração de aplicações em uma era sem servidor: integração do serviço API Gateway ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Implementar o versionamento baseado em cabeçalho do API Gateway com Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: criar uma aplicação cliente ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Vídeos relacionados:**
+ [ Usar a OpenAPI no AWS SAM para gerenciar o API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Ferramentas relacionadas:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
# CONFIABILIDADE 4. Como projetar 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.
Em sistemas fortemente acoplados, as mudanças em um componente podem exigir mudanças em outros componentes que dependem dele, o que resulta em desempenho degradado em todos eles. O acoplamento fraco interrompe essa dependência de forma que os componentes dependentes só precisem conhecer 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 acoplamento fraco permite modificar o código ou adicionar recursos a um componente, minimizando o risco para outros componentes que dependem dele. Ele também permite resiliência detalhada em nível de componente, caso em que é possível aumentar a escala horizontalmente ou até mesmo alterar a implementação subjacente 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 Amazon SQS, uma plataforma de dados de streaming, como o AWS Step Functions, ou o Amazon Kinesis.
![\[Diagram showing dependencies such as queuing systems and load balancers are loosely coupled\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/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 a 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.
**Resultado desejado:** a implementação de dependências com acoplamento fraco permite minimizar a área de superfície da falha para o nível de componente, o que ajuda a diagnosticar e resolver problemas. Também simplifica os ciclos de desenvolvimento, permitindo que as equipes implementem mudanças em um nível modular sem impactar o desempenho de outros componentes que dependem delas. Essa abordagem fornece a capacidade de aumentar a escala horizontalmente em nível de componente com base nas necessidades dos recursos, bem como na utilização de um componente que contribui para a redução de custos.
**Antipadrões comuns:**
+ Implantar uma workload monolítica.
+ Invocar diretamente as APIs entre níveis de workload sem recurso de failover ou processamento assíncrono da solicitação.
+ Acoplamento forte usando dados compartilhados. Sistemas com acoplamento fraco devem evitar o compartilhamento de dados por meio de bancos de dados compartilhados ou outras formas de armazenamento de dados fortemente acoplado, o que pode reintroduzir o acoplamento forte e impedir a escalabilidade.
+ Ignorar a contrapressão. A workload deve ter a capacidade de diminuir ou interromper a entrada de dados quando um componente não puder processá-los na mesma velocidade.
**Benefícios do estabelecimento dessa prática recomendada:** o acoplamento fraco 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 se esta prática recomendada não for estabelecida:** alto
## Orientações para a implementação
Implemente dependências com acoplamento fraco. Existem várias soluções que permitem criar aplicações com acoplamento fraco. Isso inclui serviços para implementar filas totalmente gerenciadas, fluxos de trabalho automatizados, reação a eventos e APIs, entre outros, que podem ajudar a isolar o comportamento de componentes de outros componentes e, dessa forma, aumentar a resiliência e a agilidade.
+ **Criar arquiteturas orientadas a eventos:** o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ajuda a criar arquiteturas orientadas a eventos com acoplamento fraco e distribuídas.
+ **Implementar filas em sistemas distribuídos:** é possível usar o [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) para integrar e desacoplar sistemas distribuídos.
+ **Conteinerizar componentes como microsserviços:** os [microsserviços](https://aws.amazon.com/microservices/) permitem que as equipes criem aplicações constituídas de pequenos componentes independentes que se comunicam por meio de APIs bem definidas. O [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) e o [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) podem ajudar você a começar a usar contêineres mais rapidamente.
+ **Gerenciar fluxos de trabalho com o Step Functions:** o [Step Functions](https://aws.amazon.com/step-functions/getting-started/) ajuda você a coordenar vários serviços da AWS em fluxos de trabalho flexíveis.
+ **Utilizar as arquiteturas de mensagens de publicação e assinatura (pub/sub):** o [ Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) fornece a entrega de mensagens dos publicadores aos assinantes (também conhecidos como produtores e consumidores).
### Etapas da implementação
+ Os componentes em uma arquitetura orientada a eventos são iniciados por eventos. Eventos são ações que ocorrem em um sistema, como um usuário que adiciona um item a um carrinho. Quando uma ação é bem-sucedida, é gerado um evento que aciona o próximo componente do sistema.
+ [ Building Event-driven Applications with Amazon EventBridge ](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Os sistemas de mensagens distribuídos têm três partes principais que precisam ser implementadas para uma arquitetura baseada em fila. Eles incluem componentes do sistema distribuído, a fila usada para desacoplamento (distribuída em servidores do Amazon SQS) e as mensagens na fila. Um sistema típico tem produtores que iniciam a mensagem na fila e o consumidor que recebe a mensagem da fila. A fila armazena as mensagens em vários servidores do Amazon SQS para redundância.
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Os microsserviços, quando bem utilizados, melhoram a capacidade de manutenção e aumentam a escalabilidade, pois os componentes com acoplamento fraco são gerenciados por equipes independentes. Também permitem o isolamento de comportamentos em um único componente em caso de mudanças.
+ [ Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Com o AWS Step Functions é possível criar aplicações distribuídas, automatizar processos, orquestrar microsserviços, entre outras coisas. A orquestração de vários componentes em um fluxo de trabalho automatizado permite desacoplar as dependências na aplicação.
+ [ Create a Serverless Workflow with AWS Step Functions and AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [ Conceitos básicos do AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: Ensuring Idempotency](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)
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [Arquitetura baseada em fila](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Introduction 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 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)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)
# 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)
# CONFIABILIDADE 5. Como projetar 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 workload. Essas práticas recomendadas permitem que as workloads 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 para 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 a utilização 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
Os componentes da aplicação devem continuar desempenhando sua função principal mesmo que as dependências se tornem indisponíveis. Eles podem estar fornecendo dados um pouco obsoletos, dados alternativos ou até mesmo nenhum dado. Isso garante que o funcionamento geral do sistema seja minimamente impedido por falhas localizadas e, ao mesmo tempo, ofereça o valor empresarial central.
**Resultado desejado:** Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Os modos de falha dos componentes devem ser vistos como operação normal. Os fluxos de trabalho devem ser projetados de forma que essas falhas não ocasionem à falha total ou, pelo menos, a estados previsíveis e recuperáveis.
**Antipadrões comuns:**
+ Não identificar a principal funcionalidade empresarial necessária. Não testar se os componentes estão funcionando mesmo durante falhas de dependência.
+ Não fornecer dados sobre erros ou quando apenas uma das várias dependências não está disponível e resultados parciais ainda podem ser retornados.
+ Criar um estado inconsistente quando uma transação falha parcialmente.
+ Não ter uma forma alternativa de acessar um armazenamento de parâmetros central.
+ Invalidar ou esvaziar o estado local como resultado de uma falha na atualização sem levar em conta as consequências de fazer isso.
**Benefícios de estabelecer esta prática recomendada:** A degradação gradual melhora a disponibilidade do sistema como um todo e mantém as funções mais importantes em execução mesmo durante falhas.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
A implementação de uma degradação gradual ajuda a minimizar o impacto das falhas de dependência na função do componente. Preferencialmente, um componente detecta falhas de dependência e as contorna de uma maneira que afete minimamente outros componentes ou clientes.
Arquitetar para uma degradação gradual significa considerar possíveis modos de falha durante o projeto de dependência. Para cada modo de falha, tenha uma maneira de fornecer a maior parte ou pelo menos a funcionalidade mais crítica do componente para chamadores ou clientes. Essas considerações podem se tornar requisitos adicionais que podem ser testados e verificados. Preferencialmente, um componente é capaz de realizar sua função principal de maneira aceitável, mesmo quando uma ou várias dependências falhem.
Trata-se tanto de uma discussão empresarial quanto técnica. Todos os requisitos empresariais são importantes e devem ser atendidos, se possível. No entanto, ainda faz sentido perguntar o que deve acontecer quando nem todos eles podem ser cumpridos. Um sistema pode ser projetado para estar disponível e ser consistente, mas em circunstâncias em que um requisito deve ser descartado, qual deles é mais importante? Para o processamento de pagamentos, pode ser a consistência. Para uma aplicação em tempo real, pode ser a disponibilidade. Para um site voltado para o cliente, a resposta pode depender das expectativas do cliente.
O que isso significa depende dos requisitos do componente e do que deve ser considerado sua função principal. Por exemplo:
+ Um site de comércio eletrônico pode exibir dados de vários sistemas diferentes, como recomendações personalizadas, produtos mais bem classificados e status dos pedidos dos clientes na página de pouso. Quando um sistema upstream falha, ainda faz sentido exibir todo o resto em vez de mostrar uma página de erro para um cliente.
+ Um componente que executa gravações em lote ainda poderá continuar processando um lote se ocorrer uma falha em uma das operações individuais. Deve ser simples implementar um mecanismo de repetição. Isso pode ser feito retornando informações sobre quais operações foram bem-sucedidas, quais falharam e por que falharam para o chamador, ou colocando solicitações com falha em uma fila de mensagens não entregues para implementar repetições assíncronas. As informações sobre operações com falha também devem ser registradas em log.
+ Um sistema que processa transações deve verificar se todas ou nenhuma atualização individual foi executada. Para transações distribuídas, o padrão saga pode ser usado para reverter operações anteriores caso ocorra uma falha em uma operação posterior da mesma transação. Aqui, a função principal é manter a consistência.
+ Sistemas essenciais devem ser capazes de lidar com dependências não correspondentes em tempo hábil. Nesses casos, o padrão do disjuntor pode ser usado. Quando as respostas de uma dependência começam a atingir o tempo limite, o sistema pode mudar para um estado fechado em que nenhuma chamada adicional é realizada.
+ Uma aplicação pode ler parâmetros de um armazenamento de parâmetros. Pode ser útil criar imagens de contêiner com um conjunto padrão de parâmetros e usá-las caso o armazenamento de parâmetros não esteja disponível.
Observe que as vias percorridas em caso de falha do componente precisam ser testadas e devem ser significativamente mais simples do que a via principal. Geralmente, [estratégias alternativas devem ser evitadas](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Etapas da implementação
Identifique dependências externas e internas. Leve em conta quais tipos de falhas podem ocorrer nelas. Pense em maneiras de minimizar o impacto negativo nos sistemas upstream e downstream e nos clientes durante essas falhas.
Veja a seguir uma lista de dependências e como degradar normalmente quando elas falham:
1. **Falha parcial das dependências:** Um componente pode fazer várias solicitações para sistemas downstream, como várias solicitações para um sistema ou uma solicitação para vários sistemas cada. Dependendo do contexto empresarial, diferentes maneiras de lidar com isso podem ser apropriadas (para obter mais detalhes, consulte exemplos anteriores em Orientações de implementação).
1. **Um sistema downstream não consegue processar solicitações devido à alta carga:** Se as solicitações para um sistema downstream falharem de modo consistente, não faz sentido continuar tentando. Isso pode criar carga adicional em um sistema já sobrecarregado e dificultar a recuperação. O padrão do disjuntor pode ser utilizado aqui, que monitora as chamadas com falha para um sistema downstream. Se ocorrer uma falha em um grande número de chamadas, ele deixará de enviar mais solicitações para o sistema downstream e só ocasionalmente permitirá que as chamadas passem para testar se o sistema downstream está disponível novamente.
1. **Um armazenamento de parâmetros não está disponível:** Para transformar um armazenamento de parâmetros, é possível usar o armazenamento em cache flexível de dependências ou padrões razoáveis incluídos nas imagens do contêiner ou da máquina. Observe que esses padrões precisam ser mantidos atualizados e incluídos nos pacotes de testes.
1. **Um serviço de monitoramento ou outra dependência não funcional não está disponível:** Se um componente não conseguir enviar logs, métricas ou rastreamentos de forma intermitente para um serviço de monitoramento central, geralmente é melhor continuar executando as funções empresariais normalmente. Não registrar em log nem enviar métricas silenciosamente por um longo período geralmente não é aceitável. Além disso, alguns casos de uso podem exigir entradas de auditoria completas para atender aos requisitos de conformidade.
1. **Uma instância primária de um banco de dados relacional pode não estar disponível:** Amazon Relational Database Service, como quase todos os bancos de dados relacionais, só pode ter uma instância primária de gravador. Isso cria um único ponto de falha para workloads de gravação e dificulta o ajuste de escala. Isso pode ser parcialmente reduzido com o uso de uma configuração Multi-AZ para alta disponibilidade ou da tecnologia sem servidor da Amazon Aurora para melhor ajuste de escala. Para requisitos de disponibilidade muito altos, pode fazer sentido não confiar no gravador principal. Para consultas que são somente leitura, podem ser usadas réplicas de leitura, que fornecem redundância e a capacidade de aumentar a escala horizontalmente, não apenas para verticalmente. As gravações podem ser armazenadas em buffer, por exemplo, em uma fila do Amazon Simple Queue Service, para que as solicitações de gravação dos clientes ainda possam ser aceitas mesmo que a primária esteja temporariamente indisponível.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar a utilização das solicitações de API para um melhor throughput](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) (Repetição, recuo e jitter: AWS re:Invent 2019: Introdução à 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 a utilização de solicitações
Controle a utilização das solicitações para reduzir o esgotamento de recursos devido a aumentos inesperados na demanda. Solicitações abaixo das taxas de controle de utilização são processadas, enquanto aquelas acima do limite definido são rejeitadas com uma mensagem de retorno indicando que o uso da solicitação foi controlado.
**Resultado desejado:** Grandes picos de volume, sejam causados por aumentos repentinos de tráfego de clientes, ataques de inundação ou tempestades de novas tentativas, são reduzidos pelo controle de utilização de solicitações, permitindo que as workloads continuem com o processamento normal do volume de solicitações compatível.
**Antipadrões comuns:**
+ Os controles de utilização de endpoint da API não são implementados ou são mantidos em valores padrão sem considerar os volumes esperados.
+ Não há teste de carregamento nem limites de controle de utilização dos endpoints da API.
+ Controlar a utilização de taxas de solicitações sem considerar o tamanho ou a complexidade da solicitação.
+ Testar as taxas máximas de solicitação ou o tamanho máximo da solicitação, mas não testar os dois juntos.
+ Os recursos não são provisionados nos mesmos limites estabelecidos nos testes.
+ Os planos de uso não foram configurados nem considerados para consumidores de API de aplicação para aplicação (A2A).
+ Os consumidores da fila que escalam horizontalmente não têm as configurações máximas de simultaneidade configuradas.
+ A limitação de taxas por endereço IP não foi implementada.
**Benefícios de estabelecer esta prática recomendada:** As workloads que definem limites de controle de utilização podem operar normalmente e processar a carga de solicitações aceitas com êxito em picos de volume inesperados. Os picos repentinos ou contínuos de solicitações para APIs e filas têm controle de utilização e não esgotam os recursos de processamento de solicitações. Os limites de taxas controlam a utilização de solicitantes individuais para que grandes volumes de tráfego de um único endereço IP ou consumidor de API não esgotem os recursos e afetem outros consumidores.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Os serviços devem ser projetados para processar uma capacidade conhecida de solicitações; essa capacidade pode ser estabelecida por meio de testes de carga. Se as taxas de chegada de solicitações excederem os limites, a resposta apropriada sinalizará que uma solicitação teve controle de utilização. Isso permite que o consumidor resolva o erro e tente novamente mais tarde.
Quando seu serviço exigir uma implementação de controle de utilização, considere implementar o algoritmo de bucket de token, em que um token é contabilizado para uma solicitação. Os tokens são recarregados a uma taxa de controle de utilização por segundo e esvaziados de forma assíncrona por meio de um token por solicitação.
![\[Diagrama descrevendo o algoritmo do bucket de token.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/token-bucket-algorithm.png)
[O Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa o algoritmo do bucket de token de acordo com os limites da conta e da região e pode ser configurado por cliente com planos de uso. Além disso, o [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) e o [Amazon Kinesis](https://aws.amazon.com/kinesis/) podem armazenar solicitações em buffer para suavizar a taxa de solicitações e permitir taxas de controle de utilização mais altas para solicitações que podem ser atendidas. Por fim, você pode implementar a limitação de taxa com o [AWS WAF](https://aws.amazon.com/waf/) para controlar a utilização de consumidores de API específicos que geram uma carga excepcionalmente alta.
## Etapas da implementação
É possível configurar o API Gateway com limites de controle de utilização para suas APIs e retornar erros `“429 Muitas solicitações”` quando os limites são excedidos. Você pode usar o AWS WAF com seus endpoints do AWS AppSync e do API Gateway para habilitar o limite de taxa por endereço IP. Além disso, se seu sistema tolerar o processamento assíncrono, será possível colocar mensagens em uma fila ou em um fluxo para acelerar as respostas aos clientes do serviço, o que permite que você atinja taxas de controle de utilização mais altas.
Com o processamento assíncrono, ao configurar o Amazon SQS como fonte de eventos para o AWS Lambda, é possível [configurar a simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para evitar que altas taxas de eventos consumam a cota de execução simultânea da conta disponível necessária para outros serviços em sua workload ou conta.
Embora o API Gateway ofereça uma implementação gerenciada do bucket de token, em casos em que não é possível usar o API Gateway, você pode utilizar as implementações de código aberto específicas da linguagem (veja exemplos relacionados em Recursos) do bucket de token para seus serviços.
+ Entenda e configure [limites de controle de utilização do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) em nível de conta por região, API por estágio e chave de API por nível do plano de uso.
+ Aplique [regras de controle de utilização de taxas do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) para endpoints do API Gateway e do AWS AppSync a fim de se proteger contra inundações e bloquear IPs mal-intencionados. As regras de controle de utilização de taxas também podem ser configuradas em chaves de API do AWS AppSync para consumidores A2A.
+ Decida se você precisa de mais controle de limitação do que limitação de taxas para APIs do AWS AppSync e, em caso afirmativo, configure um API Gateway na frente do seu endpoint do AWS AppSync.
+ Quando filas do Amazon SQS são configuradas como gatilhos para os consumidores da fila do Lambda, defina a [simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) como um valor que processe o suficiente para atender aos seus objetivos de nível de serviço, mas não consuma limites de simultaneidade que afetem outras funções do Lambda. Considere definir a simultaneidade reservada em outras funções do Lambda na mesma conta e região ao consumir filas com o Lambda.
+ Use o API Gateway com integrações de serviços nativos para Amazon SQS ou Kinesis para armazenar solicitações em buffer.
+ Se você não puder usar o API Gateway, consulte bibliotecas específicas de linguagens para implementar o algoritmo do bucket de token para sua workload. Confira a seção de exemplos e faça sua própria pesquisa para encontrar uma biblioteca adequada.
+ Teste os limites que você planeja definir ou permitir que sejam aumentados e documente os limites testados.
+ Não aumente os limites além do que você estabeleceu nos testes. Ao aumentar um limite, verifique se os recursos provisionados já são equivalentes ou maiores do que os dos cenários de teste antes de aplicar o aumento.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
**Documentos relacionados:**
+ [Amazon API Gateway: controlar a utilização das solicitações de API para um melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: instrução de regra baseada em taxas ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introdução da máxima simultaneidade do AWS Lambda ao usar o Amazon SQS como fonte de eventos ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: simultaneidade máxima ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Exemplos relacionados:**
+ [ As três regras mais importantes baseadas em taxas do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Bucket de tokens do Python ](https://pypi.org/project/token-bucket/)
+ [ Bucket de tokens do Node ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitação da taxa de segmentação do sistema .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Vídeos relacionados:**
+ [ Implementing GraphQL API security best practices with AWS AppSync (Implementação das práticas recomendadas de segurança da API GraphQL com AWS AppSync) ](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Ferramentas relacionadas:**
+ [ O Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
# REL05-BP03 Controlar e limitar as chamadas de repetição
Use o recuo exponencial para repetir as solicitações em intervalos progressivamente maiores entre cada nova repetição. Introduza o jitter entre as repetições para tornar os intervalos de repetição aleatórios. Limite o número máximo de repetições.
**Resultado desejado:** Os componentes típicos em um sistema de software distribuído incluem servidores, load balancers, bancos de dados e servidores DNS. Durante a operação normal, esses componentes podem responder a solicitações com erros temporários ou limitados, além de erros que seriam persistentes, independentemente de repetições. Quando os clientes fazem solicitações aos serviços, elas consomem recursos, incluindo memória, threads, conexões, portas ou quaisquer outros recursos limitados. Controlar e limitar as repetições é uma estratégia para liberar e minimizar o consumo de recursos para que os componentes do sistema sob pressão não fiquem sobrecarregados.
Quando as solicitações do cliente atingem o tempo limite ou recebem respostas de erro, ele deve determinar se deve ou não tentar novamente. Se tentar novamente, ele o fará com um recuo exponencial com jitter e um valor máximo de repetição. Como resultado, os serviços e os processos de back-end recebem alívio da carga e do tempo de recuperação automática, ocasionando uma recuperação mais rápida e atendimento bem-sucedido das solicitações.
**Antipadrões comuns:**
+ Implementar repetições sem adicionar recuo exponencial, jitter e valores máximos de repetição. O recuo e o jitter ajudam a evitar picos artificiais de tráfego devido a repetições coordenadas involuntariamente em intervalos comuns.
+ Implementar repetições sem testar seus efeitos ou presumir que repetições já estejam incorporadas a um SDK sem testar cenários de repetição.
+ Não entender os códigos de erro publicados das dependências, ocasionando a repetição de todos os erros, inclusive aqueles com uma causa clara que indica falta de permissão, erro de configuração ou outra condição que, previsivelmente, não será resolvida sem intervenção manual.
+ Não abordar práticas de observabilidade, incluindo monitoramento e alertas sobre falhas repetidas de serviço para que os problemas subjacentes sejam divulgados e possam ser resolvidos.
+ Desenvolver mecanismos de repetição personalizados quando os recursos de repetição integrados ou de terceiros são suficientes.
+ Tentar novamente em várias camadas da pilha de aplicações de uma forma que agrava as tentativas de repetição, consumindo ainda mais recursos em uma tempestade de repetições. Entenda como esses erros afetam sua aplicação, as dependências nas quais você confia e implemente repetições em apenas um nível.
+ Repetir chamadas de serviço que não são idempotentes, causando efeitos colaterais inesperados, como resultados duplicados.
**Benefícios de estabelecer esta prática recomendada:** As repetições ajudam os clientes a obter os resultados desejados quando as solicitações falham, mas também consomem mais tempo do servidor para obter as respostas bem-sucedidas que eles desejam. Quando as falhas são raras ou transitórias, as repetições funcionam bem. Quando as falhas são causadas pela sobrecarga de recursos, as repetições podem piorar as coisas. Adicionar um recuo exponencial com jitter às repetições do cliente permite que os servidores se recuperem quando as falhas são causadas pela sobrecarga de recursos. O jitter evita o alinhamento das solicitações em picos, e o recuo diminui o escalonamento de carga causado pela adição de repetições à carga normal da solicitação. Por fim, é importante configurar um número máximo de repetições ou o tempo decorrido para evitar a criação de backlogs que produzam falhas metaestáveis.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Controle e limite as chamadas de repetição. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza jitter para tornar esses intervalos de repetição aleatórios e limite o número máximo de repetições.
Alguns AWS SDKs implementam repetições e recuo exponencial por padrão. Use essas implementações integradas da AWS quando aplicável em sua workload. Implemente uma lógica semelhante em sua workload ao chamar serviços que sejam idempotentes e em que repetições melhorem a disponibilidade do cliente. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso. Crie e exercite cenários de teste para esses casos de uso de repetições.
## Etapas da implementação
+ Determine a camada ideal em sua pilha de aplicações para implementar repetições para os serviços dos quais sua aplicação depende.
+ Conheça os SDKs existentes que implementam estratégias comprovadas de repetição com retrocesso exponencial e jitter para a linguagem de sua escolha e dê preferência a esses SDKs em vez de escrever suas próprias implementações de repetição.
+ Verifique se [os serviços são idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) antes de implementar repetições. Depois que as repetições forem implementadas, elas devem ser testadas e exercitadas regularmente na produção.
+ Ao chamar APIs de serviço da AWS, use os [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) e o [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) e entenda as opções de configuração de repetições. Determine se os padrões funcionam para seu caso de uso, teste e ajuste conforme necessário.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL04-BP04 Fazer com que todas as respostas sejam idempotentes](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.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)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
**Documentos relacionados:**
+ [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/)
+ [ Recuo exponencial e jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Tornar as tentativas seguras com APIs idempotentes ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Exemplos relacionados:**
+ [ Repetição Spring ](https://github.com/spring-projects/spring-retry)
+ [ Repetição Resilience4j ](https://resilience4j.readme.io/docs/retry)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328) (Repetição, recuo e jitter: AWS re:Invent 2019: Introdução à biblioteca de criadores da Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Ferramentas relacionadas:**
+ [AWS SDKs e ferramentas: comportamento de repetição ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: repetições da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Antecipar-se à falha e filas limitadas
Quando um serviço não consegue responder com êxito a uma solicitação, antecipe-se à falha. Isso permite a liberação dos recursos associados a uma solicitação e possibilita que o serviço se recupere se estiver ficando sem recursos. Antecipar-se à falha é um padrão de design de software bem estabelecido que pode ser utilizado para criar workloads altamente confiáveis na nuvem. As filas também correspondem a um padrão de integração empresarial bem estabelecido que pode facilitar o carregamento e permitir que os clientes liberem recursos quando o processamento assíncrono pode ser tolerado. Quando um serviço consegue responder com êxito em condições normais, mas falha quando a taxa de solicitações é muito alta, use uma fila para armazenar solicitações em buffer. No entanto, não permita a formação de backlogs de filas longas que possam ocasionar o processamento de solicitações antigas das quais um cliente já desistiu.
**Resultado desejado:** Quando os sistemas enfrentam contenção de recursos, tempos limite, exceções ou falhas de causa desconhecida que tornam os objetivos de nível de serviço inatingíveis, as estratégias de antecipação a falhas permitem uma recuperação mais rápida do sistema. Sistemas que precisam absorver picos de tráfego e acomodar o processamento assíncrono podem melhorar a confiabilidade ao permitir que os clientes liberem solicitações rapidamente usando filas para armazenar solicitações em buffer para serviços de back-end. Ao armazenar solicitações em filas, estratégias de gerenciamento de filas são implementadas para evitar backlogs intransponíveis.
**Antipadrões comuns:**
+ Implementar filas de mensagens, mas não configurar filas de mensagens não entregues (DLQ) ou alarmes em volumes DLQ para detectar quando um sistema está em falha.
+ Não medir a idade das mensagens em uma fila, uma medida de latência para entender quando os consumidores da fila estão ficando para trás ou cometendo erros, ocasionando repetições.
+ Não limpar mensagens pendentes de uma fila, quando não há utilidade em processar essas mensagens se a necessidade empresarial deixar de existir.
+ Configurar filas do tipo “first in first out” (FIFO) quando filas do tipo “last in first out” (LIFO) atenderia melhor às necessidades do cliente, por exemplo, quando a ordenação rigorosa não é necessária e o processamento de backlog está atrasando todas as solicitações novas e urgentes, ocasionando violação dos níveis de serviço de todos os clientes.
+ Expor filas internas aos clientes em vez de expor APIs que gerenciem a entrada de trabalho e coloquem as solicitações em filas internas.
+ Combinar muitos tipos de solicitações de trabalho em uma única fila, o que pode agravar as condições de backlog ao distribuir a demanda de recursos entre os tipos de solicitação.
+ Processar solicitações complexas e simples na mesma fila, apesar da necessidade de monitoramento, tempos limite e alocação de recursos diferentes.
+ Não validar entradas ou usar afirmações para implementar mecanismos de antecipação à falha em software que agreguem exceções a componentes de nível superior que podem lidar com erros sem problemas.
+ Não remover recursos com defeito do roteamento de solicitações, principalmente quando as falhas estão emitindo êxitos e falhas em decorrência de travamento e reinicialização, falha de dependência intermitente, capacidade reduzida ou perda de pacotes de rede.
**Benefícios de estabelecer esta prática recomendada:** Sistemas que se antecipam à falha são mais fáceis de depurar e corrigir e geralmente expõem problemas de codificação e configuração antes que as versões sejam publicadas em produção. Os sistemas que incorporam estratégias eficazes de filas oferecem maior resiliência e confiabilidade a picos de tráfego e às condições intermitentes de falha do sistema.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
As estratégias de antecipação à falha podem ser codificadas em soluções de software e configuradas em infraestrutura. Além de se anteciparem à falha, as filas são uma técnica arquitetônica simples, mas poderosa, para dissociar os componentes do sistema e facilitar o carregamento. [O Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) oferece recursos para monitorar e alertar sobre falhas. Quando se sabe que um sistema está falhando, estratégias de mitigação podem ser invocadas, inclusive evitar recursos afetados. Quando os sistemas implementam filas com o [Amazon SQS](https://aws.amazon.com/sqs/) e outras tecnologias de fila para facilitar o carregamento, eles devem considerar como gerenciar os backlogs de filas, bem como as falhas no consumo de mensagens.
## Etapas da implementação
+ Implemente afirmações programáticas ou métricas específicas em seu software e use-as para alertar explicitamente sobre problemas do sistema. O Amazon CloudWatch ajuda você a criar métricas e alarmes com base no padrão de log da aplicação e na instrumentação do SDK.
+ Use métricas e alarmes do CloudWatch para eliminar recursos danificados que estão aumentando a latência no processamento ou falhando repetidamente no processamento das solicitações.
+ Use o processamento assíncrono criando APIs para aceitar e anexar solicitações às filas internas usando o Amazon SQS e, depois, responder ao cliente que produz a mensagem com uma mensagem de êxito para que o cliente possa liberar recursos e prosseguir com outros trabalhos enquanto os consumidores da fila de back-end processam as solicitações.
+ Avalie e monitore a latência do processamento da fila produzindo uma métrica do CloudWatch sempre que retirar uma mensagem de uma fila, comparando o momento presente com o carimbo de data/hora da mensagem.
+ Quando falhas impedem o processamento bem-sucedido de mensagens ou geram picos de tráfego em volumes que não podem ser processados de acordo com acordos de serviço, deixe de lado o tráfego antigo ou excedente para uma fila de transbordamento. Isso permite o processamento prioritário de trabalhos novos e antigos, quando há capacidade disponível. Essa técnica é uma aproximação do processamento LIFO e permite o processamento normal do sistema para todos os novos trabalhos.
+ Use filas de mensagens não entregues ou de redirecionamento para mover mensagens que não podem ser processadas do backlog para um local que possa ser pesquisado e resolvido posteriormente.
+ Tente novamente ou, quando possível, elimine as mensagens antigas comparando o momento presente com o carimbo de data/hora da mensagem e descartando as mensagens que não são mais relevantes para o cliente solicitante.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Controlar a utilização 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)
+ [REL06-BP02 Definir e calcular as métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [ Evitar backlogs de fila intransponíveis ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ Como evitar um aumento do backlog de mensagens na minha fila do Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: mudança de zona ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Controlador de recuperação de aplicações Amazon Route 53: controle de roteamento para failover de tráfego ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Exemplos relacionados:**
+ [ Padrões de integração empresarial: canal de mensagens não entregues ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications (re:Invent 2022: operar aplicações Multi-AZ altamente disponíveis)](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Ferramentas relacionadas:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ O Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Definir tempos limite do cliente
Defina tempos limite adequados para conexões e solicitações, verifique-os sistematicamente e não confie nos valores padrão, pois eles não estão cientes das especificações da workload.
**Resultado desejado:** Os tempos limite do cliente devem considerar o custo para o cliente, o servidor e a workload associados à espera por solicitações que levam um tempo anormal para serem concluídas. Como não é possível saber a causa exata de nenhum tempo limite, os clientes devem usar o conhecimento dos serviços para desenvolver expectativas de causas prováveis e prazos apropriados.
As conexões do cliente atingem o tempo limite com base nos valores configurados. Depois de encontrar um tempo limite, os clientes tomam a decisão de recuar e tentar novamente ou abrir um [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html). Esses padrões evitam a emissão de solicitações que podem exacerbar uma condição de erro subjacente.
**Antipadrões comuns:**
+ Não estar ciente dos tempos limite do sistema ou dos tempos limite padrão.
+ Não estar ciente do tempo normal de conclusão da solicitação.
+ Não estar ciente das possíveis causas das solicitações levarem muito tempo para serem concluídas ou dos custos de performance do cliente, do serviço ou da workload associados à espera por essas conclusões.
+ Não estar ciente da probabilidade de uma rede danificada fazer com que uma solicitação falhe somente quando o tempo limite é atingido e dos custos para a performance do cliente e da workload por não adotar um tempo limite mais curto.
+ Não testar cenários de tempo limite tanto para conexões quanto para solicitações.
+ Definir tempos limite muito altos, o que pode resultar em longos tempos de espera e aumentar a utilização de recursos.
+ Definir tempos limite muito baixos, gerando falhas artificiais.
+ Ignorar padrões para lidar com erros de tempo limite para chamadas remotas, como disjuntores e novas tentativas.
+ Não considerar o monitoramento de taxas de erro de chamadas de serviço, objetivos de nível de serviço para latência e valores atípicos de latência. Essas métricas podem fornecer informações sobre tempos limite agressivos ou permissivos.
**Benefícios de estabelecer esta prática recomendada:** Os tempos limite de chamadas remotas são configurados e os sistemas são projetados para lidar com os tempos limite normalmente, de forma que os recursos sejam conservados quando as chamadas remotas respondem de forma anormalmente lenta e os erros de tempo limite são tratados normalmente pelos clientes do serviço.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada de dependência de serviço e, geralmente, em qualquer chamada entre processos. Muitas frameworks oferecem recursos de tempo limite integrados, mas tenha cuidado, pois algumas têm valores padrão infinitos ou superiores ao aceitável para seus objetivos de serviço. 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.
Considere o seguinte ao determinar as estratégias de tempo limite:
+ As solicitações podem levar mais tempo do que o normal para serem processadas devido ao conteúdo, a deficiências em um serviço de destino ou a uma falha na partição de rede.
+ Solicitações com conteúdo anormalmente caro podem consumir recursos desnecessários do servidor e do cliente. Nesse caso, reduzir o tempo limite dessas solicitações e não tentar novamente pode preservar os recursos. Os serviços também devem se proteger de conteúdo anormalmente caro com limitações e tempos limite do servidor.
+ Solicitações que demoram muito devido a uma falha no serviço podem expirar e ser repetidas. Deve-se considerar os custos do serviço para a solicitação e a nova tentativa, mas se a causa for uma deficiência localizada, uma nova tentativa provavelmente não será cara e reduzirá o consumo de recursos do cliente. O tempo limite também pode liberar recursos do servidor, dependendo da natureza da deficiência.
+ Solicitações que demoram muito para serem concluídas porque a solicitação ou a resposta não foi entregue pela rede podem expirar e ser repetidas. Como a solicitação ou a resposta não foi entregue, a falha teria sido o resultado, independentemente da duração do tempo limite. Nesse caso, o tempo limite não liberará recursos do servidor, mas liberará recursos do cliente e melhorará a performance da workload.
Aproveite os padrões de design bem estabelecidos, como novas tentativas e disjuntores, para lidar com os tempos de espera de forma eficiente e oferecer compatibilidade com abordagens de antecipação à falha. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks) e a [AWS CLI](https://aws.amazon.com/cli/) permitem a configuração dos tempos limite de conexão e solicitação e as repetições com recuo exponencial e instabilidade. [As funções do AWS Lambda](https://aws.amazon.com/lambda/) são compatíveis com a configuração de tempos limite e com o [AWS Step Functions](https://aws.amazon.com/step-functions/), você pode criar disjuntores de uso de pouco código que utilizam integrações pré-incorporadas com serviços da AWS e SDKs. [O AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy oferece recursos de tempo limite e disjuntor.
## Etapas da implementação
+ Configure tempos limite em chamadas de serviço remoto e utilize os recursos de tempo limite de linguagem integrados ou as bibliotecas de tempo limite de código aberto.
+ Quando sua workload fizer chamadas com um AWS SDK, revise a documentação para saber a configuração de tempo limite específica da linguagem.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Ao usar AWS SDKs ou comandos da AWS CLI em sua workload, configure os valores de tempo limite padrão definindo [os padrões de configuração da AWS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) de `connectTimeoutInMillis` e `tlsNegotiationTimeoutInMillis`.
+ Aplique [opções de linha de comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` e `cli-read-timeout` para controlar comandos únicos da AWS CLI para serviços da AWS.
+ Monitore o tempo limite de chamadas de serviço remoto e defina alarmes para erros persistentes para que você possa lidar proativamente com cenários de erro.
+ Implemente [métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e [detecção de anomalias do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) em taxas de erro de chamada, objetivos de nível de serviço para latência e valores atípicos de latência para fornecer informações sobre o gerenciamento de tempos limite excessivamente agressivos ou permissivos.
+ Configure tempos limite em [funções do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ Os clientes do API Gateway devem implementar suas próprias repetições ao lidar com os tempos limite. O API Gateway é compatível com um [tempo limite de integração de 50 milissegundos a 29 segundos](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) para integrações posteriores e não tenta novamente quando as solicitações de integração atingem o tempo limite.
+ Implemente o padrão de [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html) para evitar fazer chamadas remotas quando o tempo limite está prestes a ser atingido. Abra o circuito para evitar falhas nas chamadas e feche-o quando as chamadas estiverem respondendo normalmente.
+ Para workloads baseadas em contêineres, analise os recursos do [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) para utilizar os tempos limite e os disjuntores integrados.
+ Use o AWS Step Functions para criar disjuntores de pouco uso de código para chamadas de serviço remoto, especialmente ao chamar AWS SDKs nativos e integrações do Step Functions compatíveis para simplificar sua workload.
## Recursos
**Práticas recomendadas relacionadas:**
+ [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)
+ [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.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/)
+ [ Cotas do Amazon API Gateway e notas importantes ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: opções de linha de comando ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: configurar tempos limite de API ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore usando o objeto de configuração e a referência de configuração ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK para .NET: repetições e tempos limite ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: configurar as opções de função do Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Exemplos relacionados:**
+ [ Usar o padrão do disjuntor com o AWS Step Functions e o Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Ferramentas relacionadas:**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [ As funções do AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# 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/2023-10-03/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.
As medidas emergenciais funcionam com a desativação, o controle de utilização ou a alteração do comportamento dos componentes ou das dependências com o uso de mecanismos conhecidos e testados. Isso pode aliviar as deficiências da workload decorrentes da exaustão dos recursos provocada por aumentos inesperados na demanda e reduzir o impacto de falhas em componentes não essenciais da workload.
**Resultado desejado:** ao implementar medidas de emergência, é possível estabelecer processos bem conhecidos para manter a disponibilidade dos componentes essenciais na workload. A workload deve se degradar normalmente e continuar desempenhando suas funções essenciais aos negócios durante a ativação de uma medida emergencial. Para obter mais detalhes sobre a degradação simples, consulte [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Antipadrões comuns:**
+ A falha de dependências não essenciais afeta a disponibilidade da workload principal.
+ Não testar ou verificar o comportamento dos componentes essenciais durante a deterioração de componentes não essenciais.
+ Não há critérios claros e determinísticos definidos para ativação ou desativação de uma medida emergencial.
**Benefícios do estabelecimento desta prática recomendada:** a implementação de medidas emergenciais pode melhorar a disponibilidade dos componentes essenciais na workload fornecendo aos resolvedores processos estabelecidos para responder a picos inesperados na demanda ou a falhas de dependências não essenciais.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
+ Identifique os componentes essenciais na workload.
+ Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais.
+ Conduza testes para validar o comportamento dos componentes essenciais durante a falha de componentes não essenciais.
+ Defina e monitore métricas ou acionadores relevantes para iniciar procedimentos de medida emergencial.
+ Defina os procedimentos (manuais ou automatizados) que compõem a medida emergencial.
### Etapas da implementação
+ Identificar os componentes essenciais aos negócios na workload.
+ Cada componente técnico na workload deve ser mapeado para a função de negócios relevante e classificado como essencial ou não essencial. Para obter exemplos de funcionalidades essenciais e não essenciais na Amazon, consulte [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Essa é uma decisão técnica e de negócios e varia de acordo com a organização e a workload.
+ Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais.
+ Durante a análise de dependências, considere todos os possíveis modos de falha e verifique se os mecanismos de medida emergencial fornecem a funcionalidade essencial aos componentes subsequentes.
+ Conduza testes para validar o comportamento dos componentes essenciais durante a ativação das medidas emergenciais.
+ Evite o comportamento bimodal. Para obter mais detalhes, consulte [ REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Defina, monitore e emita alertas sobre as métricas relevantes para iniciar o procedimento de medida emergencial.
+ A descoberta das métricas certas a serem monitoradas depende da workload. Alguns exemplos de métricas são a latência ou o número de solicitações com falha feitas para uma dependência.
+ Defina os procedimentos, manuais ou automatizados, que compõem a medida emergencial.
+ Isso pode incluir mecanismos como [descarte de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [controle de utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) ou implementação de [degradação simples](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Controlar a utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documentos relacionados:**
+ [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)
# Gerenciamento de alterações
**Topics**
+ [CONFIABILIDADE 6. Como monitorar recursos de workload?](rel-06.md)
+ [CONFIABILIDADE 7. Como projetar sua workload para se adaptar às mudanças na demanda?](rel-07.md)
+ [CONFIABILIDADE 8. Como implementar uma alteração?](rel-08.md)
# CONFIABILIDADE 6. Como monitorar recursos de workload?
Os logs e as métricas são uma ferramenta poderosa para saber a integridade de sua workload. Você pode configurar sua workload 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 workload 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 Envie 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 de 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 Envie notificações (processamento e emissão de alarmes em tempo real)
Quando as organizações detectam possíveis problemas, elas enviam notificações e alertas em tempo real para a equipe e os sistemas apropriados para responder de forma rápida e eficaz a esses problemas.
**Resultado desejado:** respostas rápidas a eventos operacionais são possíveis por meio da configuração de alarmes relevantes com base nas métricas de serviços e aplicações. Quando os limites do alarme são violados, o pessoal e os sistemas apropriados são notificados para que possam resolver os problemas subjacentes.
**Antipadrões comuns:**
+ Configuração de alarmes com um limite excessivamente alto, resultando em falha no envio de notificações vitais.
+ Configurar alarmes com um limite muito baixo, ocasionando inatividade diante de alertas importantes devido ao ruído de notificações excessivas.
+ Não atualizar os alarmes e seu limite quando o uso muda.
+ Para alarmes mais bem abordados por meio de ações automatizadas, enviar a notificação ao pessoal em vez de gerar a ação automatizada gera o envio excessivo de notificações.
**Benefícios de estabelecer esta prática recomendada:** O envio de notificações e alertas em tempo real para o pessoal e os sistemas apropriados permite a detecção precoce de problemas e respostas rápidas aos incidentes operacionais.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
As workloads devem ser equipadas com processamento e alarmes em tempo real para melhorar a detectabilidade de problemas que possam afetar a disponibilidade da aplicação e servir como gatilhos para respostas automatizadas. As organizações podem realizar processamento e alarmes em tempo real criando alertas com métricas definidas para receber notificações sempre que eventos significativos ocorrerem ou quando uma métrica ultrapassar um limite.
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) permite criar [alarmes de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e compostos usando alarmes do CloudWatch com base em limite estático, detecção de anomalias e outros critérios. Para obter mais detalhes sobre os tipos de alarme que você pode configurar usando o CloudWatch, consulte a [seção de alarmes da documentação do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
É possível criar visualizações personalizadas de métricas e alertas dos recursos da AWS para as equipes usando [painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). As páginas iniciais personalizáveis no console do CloudWatch permitem que você monitore seus recursos em uma única visualização em várias regiões.
Os alarmes podem realizar uma ou mais ações, como enviar uma notificação a um [tópico do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), realizando uma ação do [Amazon EC2](https://aws.amazon.com/ec2/) ou do [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , ou [criando um OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidente](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) no AWS Systems Manager.
O Amazon CloudWatch usa o [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificações quando o alarme muda de estado, fornecendo a entrega de mensagens dos publicadores (produtores) para os assinantes (consumidores). Para obter mais detalhes sobre como configurar notificações do Amazon SNS, consulte [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html).
O CloudWatch envia eventos do [EventBridge](https://aws.amazon.com/eventrbridge/) [segurança](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) sempre que um alarme do CloudWatch é criado, atualizado, excluído ou o estado muda. É possível usar o EventBridge com esses eventos para criar regras que realizam ações, como enviar uma notificação sempre que o estado de um alarme mudar ou acionar eventos automaticamente na conta usando o [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html).
** Quando você deve usar o EventBridge ou o Amazon SNS? **
Tanto o EventBridge quanto o Amazon SNS podem ser usados para desenvolver aplicações orientadas a eventos, e sua escolha dependerá de suas necessidades específicas.
O Amazon EventBridge é recomendado quando você deseja criar uma aplicação que reaja a eventos de suas próprias aplicações, aplicações SaaS e serviços da AWS. O EventBridge é o único serviço baseado em eventos que se integra diretamente com parceiros SaaS de terceiros. O EventBridge também ingere automaticamente eventos de mais de 200 serviços da AWS sem exigir que os desenvolvedores criem recursos em suas contas.
O EventBridge usa uma estrutura definida baseada em JSON para eventos e ajuda você a criar regras que são aplicadas em todo o corpo do evento para selecionar eventos a serem encaminhados a um [destino](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). O EventBridge no momento é compatível com mais de vinte serviços da AWS como destinos, incluindo [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), o [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)e o [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
O Amazon SNS é recomendado para aplicações que precisam de alta distribuição (milhares ou milhões de endpoints). Um padrão comum que vemos é que os clientes usam o Amazon SNS como destino para a regra a fim de filtrar os eventos de que precisam e distribuí-los para vários endpoints.
As mensagens não são estruturadas e podem estar em qualquer formato. O Amazon SNS permite o encaminhamento de mensagens a seis tipos diferentes de destinos, incluindo Lambda, Amazon SQS, endpoints HTTP/S, SMS, push de dispositivos móveis e e-mail. A latência típica do Amazon SNS [é inferior a 30 milissegundos](https://aws.amazon.com/sns/faqs/). Uma ampla variedade de serviços da AWS envia ao Amazon SNS mensagens configurando o serviço para fazer isso (mais de trinta, incluindo o Amazon EC2, o [Amazon S3](https://aws.amazon.com/s3/)e o [Amazon RDS](https://aws.amazon.com/rds/)).
### Etapas da implementação
1. Crie um alarme usando [alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
1. Um alarme de métrica monitora uma única métrica do CloudWatch ou uma expressão dependente de métricas do CloudWatch. O alarme inicia uma ou mais ações com base no valor da métrica ou expressão em comparação com um limite em vários intervalos de tempo. A ação pode consistir em enviar uma notificação a um [tópico do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), realizando uma ação do [Amazon EC2](https://aws.amazon.com/ec2/) ou do [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) , ou [criando um OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidente](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) no AWS Systems Manager.
1. Um alarme composto consiste em uma expressão de regra que considera as condições de alarme de outros alarmes que você criou. O alarme composto só entra no estado de alarme se todas as condições da regra forem atendidas. Os alarmes especificados na expressão da regra de um alarme composto podem incluir alarmes de métricas e outros alarmes compostos. Alarmes compostos podem enviar notificações do Amazon SNS quando o estado muda e podem criar Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) ou [incidentes](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) quando entram no estado de alarme, mas não conseguem realizar ações do Amazon EC2 ou do Auto Scaling.
1. Configure o [Notificações do Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). Ao criar um alarme do CloudWatch, é possível incluir um tópico do Amazon SNS para enviar uma notificação quando o alarme mudar de estado.
1. [Crie regras no EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) que corresponde aos alarmes do CloudWatch especificados. Cada regra é compatível com vários destinos, incluindo funções do Lambda. Por exemplo, você pode definir um alarme que é iniciado quando o espaço disponível em disco está acabando, o que aciona uma função do Lambda por meio de uma regra do EventBridge para limpar o espaço. Para obter mais detalhes sobre destinos do EventBridge, consulte [EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html).
## Recursos
**Práticas recomendadas relacionadas ao Well-Architected:**
+ [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)
+ [REL12-BP01 Usar playbooks para investigar falhas](rel_testing_resiliency_playbook_resiliency.md)
**Documentos relacionados:**
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ CloudWatch Logs insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Using Amazon CloudWatch metrics (Uso de métricas do Amazon CloudWatch)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Setting up Amazon SNS notifications ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ detecção de anomalias do CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch Logs data protection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)
**Vídeos relacionados:**
+ [ reinvent 2022 observability videos (Vídeos sobre observabilidade do AWS re:Invent 2022) ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon (AWS re:Invent 2022: práticas recomendadas de observabilidade na Amazon) ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**Exemplos relacionados:**
+ [Um workshop de observabilidade](https://observability.workshop.aws/)
+ [ Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# 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.
O processamento automatizado de alarmes em tempo real é implementado para que os sistemas possam tomar medidas corretivas rapidamente e tentar evitar falhas ou degradação dos serviços quando os alarmes são acionados. As respostas automatizadas a alarmes podem incluir a substituição de componentes com falha, o ajuste da capacidade computacional, o redirecionamento do tráfego para hosts, zonas de disponibilidade ou outras regiões íntegras e a notificação dos operadores.
**Resultado desejado:** os alarmes em tempo real são identificados, e o processamento automatizado dos alarmes é configurado para invocar as ações apropriadas realizadas para manter os objetivos de nível de serviço e os acordos de serviço (SLAs). A automação pode variar de atividades de autorrecuperação de componentes individuais a failover de todo o site.
**Antipadrões comuns:**
+ Não ter um inventário ou catálogo claro dos principais alarmes em tempo real.
+ Não haver respostas automatizadas para alarmes essenciais (por exemplo, quando a computação está quase esgotada, ocorre o ajuste de escala automático).
+ Usar ações contraditórias de resposta a alarmes.
+ Não haver procedimentos operacionais padrão (SOPs) para os operadores seguirem ao receberem notificações de alerta.
+ Não monitorar as alterações da configuração, pois alterações não detectadas podem causar tempo de inatividade nas workloads.
+ Não haver uma estratégia para desfazer alterações não intencionais da configuração.
**Benefícios do estabelecimento desta prática recomendada: ** a automatização do processamento de alarmes pode melhorar a resiliência do sistema. O sistema executa ações corretivas automaticamente, reduzindo as atividades manuais que permitem intervenções humanas sujeitas a erros. A workload opera, atende às metas de disponibilidade e reduz a interrupção do serviço.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
Para gerenciar alertas com eficiência e automatizar as respectivas respostas, categorize os alertas com base em sua criticidade e impacto, documente os procedimentos de resposta e planeje as respostas antes das tarefas de classificação.
Identifique tarefas que exigem ações específicas (geralmente detalhadas em runbooks) e examine todos os runbooks e manuais para determinar as tarefas que podem ser automatizadas. Geralmente, se for possível definir ações, elas poderão ser automatizadas. Se não for possível automatizar as ações, documente as etapas manuais em um SOP e treine os operadores a respeito. Conteste continuamente os processos manuais em busca de oportunidades de automação em que seja possível estabelecer e manter um plano para automatizar as respostas a alertas.
### Etapas da implementação
1. **Criar um inventário de alarmes:** para obter uma lista de todos os alarmes, é possível utilizar a [AWS CLI](https://aws.amazon.com/cli/) usando o comando do [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)`. Dependendo de quantos alarmes você configurou, talvez seja necessário usar paginação para recuperar um subconjunto de alarmes para cada chamada ou, alternativamente, utilizar o AWS SDK para obter os alarmes [usando uma chamada de API](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html).
1. **Documentar todas as ações do alarme: ** atualize um runbook com todos os alarmes e as respectivas ações, independentemente de serem manuais ou automatizados. O [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html)fornece runbooks predefinidos. Para obter mais informações sobre runbooks, consulte [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Para obter detalhes sobre como visualizar o conteúdo do runbook, consulte [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json).
1. **Configurar e gerenciar ações de alarmes:** para qualquer um dos alarmes que exijam uma ação, especifique a [ação automatizada usando o SDK do CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). Por exemplo, é possível alterar o estado das instâncias do Amazon EC2 automaticamente com base em um alarme do CloudWatch criando e ativando ações em um alarme ou desativando ações em um alarme.
Também é possível usar o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) para responder automaticamente a eventos do sistema, como problemas de disponibilidade de aplicações ou alterações de recursos. Você pode criar regras para indicar em quais eventos tem interesse e as ações a serem executadas quando um evento corresponder a uma regra. As ações que podem ser iniciadas automaticamente incluem invocar um perfil do [AWS Lambda](https://aws.amazon.com/lambda/), invocar o `Run Command` do [Amazon EC2](https://aws.amazon.com/ec2/), transmitir o evento para o [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) e visualizar o documento [Automatizar o Amazon EC2 usando o EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html).
1. **Procedimentos operacionais padrão (SOPs):** com base nos componentes da aplicação, o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) recomenda vários [modelos de SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). É possível usar esses SOPs para documentar todos os processos que um operador deve seguir caso um alerta seja emitido. Também é possível [estruturar um SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) com base nas recomendações do Resilience Hub, caso em que você precisa de uma aplicação do Resilience Hub com uma política de resiliência associada, bem como de uma avaliação histórica de resiliência em relação a essa aplicação. As recomendações para o SOP são produzidas pela avaliação de resiliência.
O Resilience Hub trabalha com o Systems Manager para automatizar as etapas dos SOPs, fornecendo vários [documentos do SSM](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html) que podem ser usados como base para esses SOPs. Por exemplo, o Resilience Hub pode recomendar um SOP para adicionar espaço em disco com base em um documento de automação existente do SSM.
1. **Realizar ações automatizadas usando o Amazon DevOps Guru:** é possível usar o [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) para monitorar automaticamente recursos da aplicação em busca de comportamento anômalo e fornecer recomendações direcionadas para acelerar o tempo de identificação e de correção de problemas. Com o DevOps Guru, é possível monitorar fluxos de dados operacionais quase em tempo real de várias fontes, incluindo as métricas do Amazon CloudWatch, o [AWS Config](https://aws.amazon.com/config/), o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) e o [AWS X-Ray](https://aws.amazon.com/xray/). Também é possível usar o DevOps Guru para criar [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) no OpsCenter e enviar eventos ao [EventBridge para automação adicional](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [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 Envie notificações (processamento e emissão de alarmes em tempo real)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 Usar runbooks para atividades padrão, como implantação](rel_tracking_change_management_planned_changemgmt.md)
**Documentos relacionados:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](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/)
+ [What is 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)
**Vídeos relacionados:**
+ [AWS re:Invent 2022: Práticas recomendadas de observabilidade na Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Criar sistemas de tickets personalizados para notificações do Amazon DevOps Guru ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)
**Exemplos relacionados:**
+ [ Reliability Workshops ](https://wellarchitectedlabs.com/reliability/)(Workshops sobre confiabilidade)
+ [ Workshop do Amazon CloudWatch e do Systems Manager ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# 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 de seu sistema
Rastreie as solicitações à medida que elas são processadas por meio de componentes de serviço para que as equipes de produto possam analisar e depurar problemas com maior facilidade e melhorar a performance.
**Resultado desejado:** As workloads com rastreamento abrangente em todos os componentes são fáceis de depurar, o que melhora [o tempo médio até a resolução](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) de erros e latência simplificando a descoberta da causa raiz. O rastreamento completo reduz o tempo necessário para descobrir os componentes afetados e detalhar as causas raiz dos erros ou da latência.
**Antipadrões comuns:**
+ O rastreamento é usado para alguns componentes, mas não para todos. Por exemplo, sem rastrear o AWS Lambda, as equipes podem não entender claramente a latência causada por partidas a frio em uma workload com picos.
+ Canários sintéticos ou monitoramento de usuário real (RUM) não são configurados com rastreamento. Sem canários ou RUM, a telemetria de interação com o cliente é omitida da análise de rastreamento, gerando um perfil de performance incompleto.
+ As workloads híbridas incluem ferramentas de rastreamento nativas da nuvem e de terceiros, mas ainda não foram tomadas medidas eletivas e integram totalmente uma única solução de rastreamento. Com base na solução de rastreamento escolhida, os SDKs de rastreamento nativos de nuvem devem ser usados para instrumentar componentes que não são nativos de nuvem ou ferramentas de terceiros devem ser configuradas para ingerir a telemetria de rastreamento nativa de nuvem.
**Benefícios de estabelecer esta prática recomendada:** Quando as equipes de desenvolvimento são alertadas sobre problemas, elas podem ter uma visão completa das interações dos componentes do sistema, incluindo a correlação componente por componente com registros em log, performance e falhas. Como o rastreamento facilita a identificação visual das causas raiz, menos tempo é gasto na investigação delas. As equipes que entendem detalhadamente as interações dos componentes tomam decisões melhores e mais rápidas ao resolver problemas. Decisões como quando invocar o failover de recuperação de desastres (DR) ou onde melhor implementar estratégias de autorrecuperação podem ser aprimoradas com a análise de rastreamentos de sistemas e aumentar a satisfação do cliente com seus serviços.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
As equipes que operam aplicações distribuídas podem usar ferramentas de rastreamento para estabelecer um identificador de correlação, coletar rastreamentos de solicitações e criar mapas de serviço dos componentes conectados. Todos os componentes da aplicação devem ser incluídos nos rastreamentos de solicitações, incluindo clientes de serviços, gateways de middleware e barramentos de eventos, componentes computacionais e armazenamento, incluindo armazenamentos de chave-valor e bancos de dados. Inclua canários sintéticos e monitoramento de usuários reais em sua configuração de rastreamento completo a fim de medir as interações remotas com clientes e a latência, para que você possa avaliar com precisão a performance de seus sistemas em relação aos seus objetivos e acordos de serviço.
Você pode usar o [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) e os [serviços de instrumentação de monitoramento de aplicações do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) para oferecer uma visão completa das solicitações à medida que elas passam por sua aplicação. O X-Ray coleta a telemetria da aplicação e permite que você a visualize e filtre em payloads, funções, rastreamentos, serviços, APIs e pode ser ativada para componentes do sistema com pouco ou nenhum código. O monitoramento de aplicações do CloudWatch inclui o ServiceLens para integrar seus rastreamentos a métricas, logs e alarmes. O monitoramento de aplicações do CloudWatch também inclui sintéticos a fim de monitorar seus endpoints e APIs, bem como monitoramento de usuários reais para instrumentar seus clientes de aplicações web.
## Etapas da implementação
+ Use o AWS X-Ray em todos os serviços nativos compatíveis, como [Amazon S3, AWS Lambda e Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Esses serviços da AWS permitem ao X-Ray alternar a configuração usando a infraestrutura como código, AWS SDKs ou o Console de gerenciamento da AWS.
+ Aplicações de instrumentos [AWS Distro for Open Telemetry e X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) ou agentes de coleta de terceiros.
+ Revise o [Guia do desenvolvedor do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) para implementação específica da linguagem de programação. Essas seções da documentação detalham como instrumentar solicitações HTTP, consultas SQL e outros processos específicos de sua linguagem de programação de aplicações.
+ Use o rastreamento do X-Ray para [Canários sintéticos do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) e os [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) para analisar o caminho da solicitação de seu cliente de usuário final por meio de sua infraestrutura downstream da AWS.
+ Configure métricas e alarmes do CloudWatch com base na integridade dos recursos e na telemetria canário para que as equipes sejam alertadas sobre problemas rapidamente e, depois, possam se aprofundar em rastreamentos e mapas de serviços com o ServiceLens.
+ Habilite a integração do X-Ray a ferramentas de rastreamento de terceiros, como [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/)ou [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) se você estiver usando ferramentas de terceiros para sua solução de rastreamento principal.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL06-BP01 Monitorar todos os componentes da workload (geração)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
**Documentos relacionados:**
+ [O que é o AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch: Monitoramento de aplicações ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.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/)
+ [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/)
+ [ Integrar o AWS X-Ray a outros serviços da AWS](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry e AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: uso do monitoramento sintético ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: usar o CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Configurar o canário sintético do Amazon CloudWatch e o alarme do Amazon CloudWatch ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ Disponibilidade e além: compreensão e melhoria da resiliência de sistemas distribuídos na AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**Exemplos relacionados:**
+ [ Um workshop de observabilidade ](https://catalog.workshops.aws/observability/en-US)
**Vídeos relacionados:**
+ [AWS re:Invent 2022 - How to monitor applications across multiple accounts (re:Invent 2022: Como monitorar aplicações em várias contas) ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ How to Monitor your AWS Applications (Como monitorar suas aplicações da AWS) ](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**Ferramentas relacionadas:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)
# CONFIABILIDADE 7. Como projetar sua workload 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. Notifique o pessoal apropriado para escalar manualmente o recurso ou inicie a automação para escalá-lo automaticamente.
A escala pode ser ajustada manualmente para a workload (por exemplo, alterando o número de instâncias do EC2 em um grupo do Auto Scaling ou modificando o throughput de uma tabela do DynamoDB por meio do Console de gerenciamento da AWS ou da AWS CLI). No entanto, a automação deve ser usada sempre que possível (consulte **Usar automação ao obter ou escalar recursos**).
**Resultado desejado:** as atividades de ajuste de escala (de forma automática ou manual) são iniciadas para restaurar a disponibilidade após a detecção de uma falha ou de uma degradação da experiência do cliente.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
Implemente a observabilidade e o monitoramento em todos os componentes da workload para monitorar a experiência do cliente e detectar falhas. Defina os procedimentos, manuais ou automatizados, que escalam os recursos necessários. Para obter mais informações, consulte [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html).
### Etapas da implementação
+ Definir os procedimentos, manuais ou automatizados, que escalam os recursos necessários.
+ Os procedimentos de ajuste de escala dependem de como os diferentes componentes da workload são projetados.
+ Eles também variam dependendo da tecnologia subjacente utilizada.
+ Os componentes que usam o AWS Auto Scaling podem utilizar planos de ajuste de escala para configurar um conjunto de instruções para escalar os recursos. Se você trabalha com o AWS CloudFormation ou adiciona tags aos recursos da AWS, poderá configurar planos de ajuste de escala para diferentes conjuntos de recursos por aplicação. O Auto Scaling fornece recomendações para estratégias de ajuste de escala personalizadas para cada recurso. Depois que o plano de ajuste de escala for criado, o Auto Scaling combinará os métodos de ajuste de escala dinâmica e preditiva para compatibilidade com a estratégia de ajuste de escala. Para obter mais detalhes, consulte [Como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html).
+ O Amazon EC2 Auto Scaling verifica se você tem 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 do Auto Scaling. É possível especificar o número mínimo e máximo de instâncias em cada grupo do Auto Scaling, e o Amazon EC2 Auto Scaling garantirá que o grupo nunca fique abaixo ou acima desses limites. Para obter mais detalhes, consulte [O que é o Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ O ajuste de escala automático do Amazon DynamoDB usa o serviço Application Auto Scaling para ajustar dinamicamente a capacidade de throughput provisionado por você, em resposta a padrões de tráfego reais. Isso permite que uma tabela ou um índice secundário global aumente a capacidade provisionada de leitura e gravação para sustentar aumentos repentinos no tráfego, sem controle de utilização. Para obter mais detalhes, consulte [Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [ REL07-BP01 Usar a automação ao obter ou escalar recursos ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**Documentos relacionados:**
+ [AWS Auto Scaling: Como funcionam os planos de escalabilidade](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB](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/)
# CONFIABILIDADE 8. Como implementar uma alteração?
As alterações controladas são necessárias para implantar novas funcionalidades e garantir que as workloads 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 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 infraestrutura imutável
A infraestrutura imutável é um modelo que não requer atualizações, patches de segurança ou que alterações na configuração ocorram no local nas workloads de produção. Quando uma alteração é necessária, a arquitetura é criada em uma nova infraestrutura e implantada na produção.
Siga uma estratégia de implantação de infraestrutura imutável para aumentar a confiabilidade, a consistência e a reprodutibilidade nas implantações de workload.
**Resultado desejado:** com a infraestrutura imutável, nenhuma [modificação no local](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html) é permitida para executar recursos de infraestrutura em uma workload. Em vez disso, quando uma alteração é necessária, um novo conjunto de recursos atualizados da infraestrutura que contém todas as alterações necessárias é implantado paralelamente aos recursos existentes. Essa implantação é validada automaticamente e, se bem-sucedida, o tráfego é gradualmente transferido para o novo conjunto de recursos.
Essa estratégia de implantação aplica-se a atualizações de software, patches de segurança, alterações na infraestrutura, atualizações de configuração e atualizações de aplicações, entre outros.
**Antipadrões comuns:**
+ Implementação de mudanças no local em recursos da infraestrutura em execução.
**Benefícios do estabelecimento desta prática recomendada:**
+ **Maior consistência entre os ambientes:** como não há diferenças nos recursos de infraestrutura entre os ambientes, a consistência aumenta e os testes são simplificados.
+ **Redução dos desvios da configuração:** ao substituir os recursos da infraestrutura por uma configuração conhecida e controlada por versão, a infraestrutura é definida para um estado conhecido, testado e confiável, o que evita desvios de configuração.
+ **Implantações atômicas confiáveis:** as implantações são concluídas com sucesso ou, do contrário, nada muda, aumentando a consistência e a confiabilidade no processo de implantaçã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 mais seguras com processos de reversão e recuperação rápidos:** as implantações são mais seguras porque a versão de trabalho anterior não é alterada. Você pode reverter para ele se forem detectados erros.
+ **Procedimento de segurança aprimorado:** quando não se permitem alterações na infraestrutura, os mecanismos de acesso remoto (como o SSH) podem ser desativados. Isso reduz o vetor de ataque, melhorando o procedimento de segurança da organização.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
**Automação**
Ao definir uma estratégia de implantação de infraestrutura imutável, é recomendável usar a [automação](https://aws.amazon.com/iam/) o máximo possível para aumentar a reprodutibilidade e minimizar a possibilidade de erro humano. Para obter mais detalhes, consulte [REL08-BP05 Implantar alterações com automação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) e [Automating safe, hands-off deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
Com a [infraestrutura como código (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html), as etapas de provisionamento, orquestração e implantação da infraestrutura são definidas de forma programática, descritiva e declarativa e armazenadas em um sistema de controle de origem. O uso da infraestrutura como código simplifica a automatização da implantação da infraestrutura e ajuda a obter a imutabilidade da infraestrutura.
**Padrões de implantação**
Quando uma mudança na workload é necessária, a estratégia de implantação da infraestrutura imutável exige que um novo conjunto de recursos da infraestrutura seja implantado, incluindo todas as alterações necessárias. É importante que esse novo conjunto de recursos siga um padrão de implantação que minimize o impacto sobre o usuário. Há duas estratégias principais para essa implantação:
[https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html): prática de direcionar um pequeno número de 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, será possível continuar a implantação a uma velocidade desejada e monitorar 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](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) que permitirá uma implantação canário.
[https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html): é semelhante à implantação canário, exceto que uma frota completa da aplicação é implantada 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 vez. No entanto, também é possível 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](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) podem ser definidos com uma configuração de implantação que permitirá uma implantação azul/verde.
![\[Diagram showing blue/green deployment with AWS Elastic Beanstalk and Amazon Route 53\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/blue-green-deployment.png)
**Detecção de desvios**
Define-se *desvio* como qualquer alteração que faça com que um recurso da infraestrutura tenha um estado ou uma configuração diferente do esperado. Alterações não gerenciadas da configuração, sejam de que tipo for, são contrárias ao conceito de infraestrutura imutável e devem ser detectadas e corrigidas para que a implementação da infraestrutura imutável seja bem-sucedida.
### Etapas da implementação
+ Proibir a modificação no local dos recursos de infraestrutura em execução.
+ É possível usar o [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) para especificar quem ou o que pode acessar serviços e recursos na AWS, gerenciar as permissões refinadas centralmente e analisar o acesso para refinar as permissões em toda a AWS.
+ Automatize a implantação dos recursos da infraestrutura para aumentar a reprodutibilidade e minimizar a possibilidade de erro humano.
+ Conforme descrito no whitepaper [Introdução ao DevOps na AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html), a automação é uma referência dos serviços da AWS e é compatível com todos os serviços, recursos e ofertas.
+ *[Pré-fabricar](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)* a imagem de máquina da Amazon (AMI) pode acelerar o tempo para iniciá-la. O [EC2 Image Builder](https://aws.amazon.com/image-builder/)é um serviço da AWS totalmente gerenciado que ajuda você a automatizar a criação, a manutenção, a validação, o compartilhamento e a implantação de AMIs personalizadas, seguras e atualizadas para Linux ou Windows.
+ Alguns dos serviços compatíveis com automação são:
+ O [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)é um serviço para implantar e escalar rapidamente aplicações web desenvolvidas com Java, .NET, PHP, Node.js, Python, Ruby, Go e Docker em servidores conhecidos, como Apache, NGINX, Passenger e IIS.
+ O [AWS Proton](https://aws.amazon.com/proton/) ajuda as equipes da plataforma a se conectarem e coordenarem todas as diferentes ferramentas de que as equipes de desenvolvimento precisam para provisionamento de infraestrutura, implantações de código, monitoramento e atualizações. O AWS Proton permite o provisionamento de infraestrutura como código automatizada e a implantação de aplicações sem servidor e baseadas em contêineres.
+ A utilização da infraestrutura como código facilita a automatização da implantação da infraestrutura e ajuda a obter a imutabilidade da infraestrutura. A AWS fornece serviços que permitem a criação, a implantação e a manutenção da infraestrutura de forma programática, descritiva e declarativa.
+ O [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ajuda os desenvolvedores a criar recursos da AWS de forma ordenada e previsível. Os recursos são escritos em arquivos de texto usando o formato JSON ou YAML. Os modelos exigem sintaxe e estrutura específicas que dependem dos tipos de recurso que estão sendo criados e gerenciados. Você cria os recursos em JSON ou YAML com qualquer editor de código, como o AWS Cloud9, e os insere em um sistema de controle de versão, e o CloudFormation cria os serviços especificados de maneira segura e repetível.
+ O [AWS Serverless Application Model (AWS SAM)](https://aws.amazon.com/serverless/sam/) é uma estrutura de código aberto que você pode usar para criar aplicações sem servidor na AWS. O AWS SAM integra-se a outros serviços da AWS e é uma extensão do CloudFormation.
+ O [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) é um framework de desenvolvimento de software de código aberto para modelar e provisionar recursos da aplicação em nuvem usando linguagens de programação conhecidas. É possível usar o AWS CDK para modelar a infraestrutura de aplicações usando TypeScript, Python, Java e .NET. O AWS CDK usa o CloudFormation em segundo plano para provisionar recursos de forma segura e repetível.
+ O [AWS API Cloud Control](https://aws.amazon.com/cloudcontrolapi/) apresenta um conjunto comum de APIs de criação, leitura, atualização, exclusão e lista (CRUDL) para ajudar os desenvolvedores a gerenciar a infraestrutura em nuvem de forma fácil e consistente. As APIs comuns do Cloud Control API permitem que os desenvolvedores gerenciem de maneira uniforme o ciclo de vida de serviços da AWS e de terceiros.
+ Implemente padrões de implantação que minimizem o impacto no usuário.
+ Implantações canário:
+ [ Configurar uma implantação de versão canary do API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [ Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
+ Implantações azul/verde: o whitepaper [Blue/Green Deployments on AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html) descreve [exemplos de técnicas](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html) para implementar estratégias de implantação azul/verde.
+ Detecte variações da configuração ou do estado. Para obter mais detalhes, consulte[Detectar alterações de configuração não gerenciadas em pilhas e recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html).
## Recursos
**Práticas recomendadas relacionadas:**
+ [ REL08-BP05 Implantar alterações com automação ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)
**Documentos relacionados:**
+ [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [ Leveraging AWS CloudFormation to create an immutable infrastructure at Nubank ](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [Infraestrutura como código](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [ Implementing an alarm to automatically detect drift in AWS CloudFormation stacks ](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY)
# 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**
+ [CONFIABILIDADE 9. Como fazer backup dos dados?](rel-09.md)
+ [CONFIABILIDADE 10. Como usar o isolamento de falhas para proteger sua workload?](rel-10.md)
+ [CONFIABILIDADE 11. Como projetar a workload para resistir a falhas de componentes?](rel-11.md)
+ [CONFIABILIDADE 12. Como testar a confiabilidade?](rel-12.md)
+ [CONFIABILIDADE 13. Como planejar a recuperação de desastres (DR)?](rel-13.md)
# CONFIABILIDADE 9. Como fazer 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 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
Compreenda e use os recursos de backup dos serviços e recursos de dados usados pela workload. A maioria dos serviços oferece recursos para fazer backup dos dados da workload.
**Resultado desejado:** as fontes de dados foram identificadas e classificadas com base na criticidade. Depois, estabeleça uma estratégia de recuperação de dados com base no RPO. A estratégia envolve fazer backup dessas fontes de dados ou poder 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:** básica
**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 e 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 é estabelecida:** alto
## Orientações para a implementação
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), permitindo restaurar um backup a qualquer momento até cinco minutos ou menos, antes da hora atual. Muitos serviços da AWS permitem copiar backups para outra Região da AWS. O AWS Backup é uma ferramenta que permite centralizar e automatizar a proteção de dados nos serviços da AWS. O [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) permite copiar workloads de servidor completas e manter uma proteção de dados contínua de um ambiente on-premises, entre zonas de disponibilidade ou entre regiões, com um objetivo de ponto de recuperação (RPO) medido em segundos.
O Amazon S3 pode ser usado como um 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.
E possível fazer backup de dados on-premises na Nuvem AWS usando o [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) ou o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Os buckets do Amazon S3 podem ser usados para armazenar esses dados na AWS. O Amazon S3 oferece vários níveis de armazenamento, como [Amazon Glacier ou Amazon Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) para reduzir os custos do 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éplica do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) ou as [réplicas de leitura do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) poderiam ser usadas para reproduzir dados caso os primários sejam perdidos. Em casos em que fontes como essa podem ser usadas para atender ao [objetivo de ponto de recuperação (RPO) e objetivo de tempo de recuperação (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), pode ser que você não precise de um backup. Outro exemplo, se estiver trabalhando com o Amazon EMR, pode não ser necessário fazer backup do armazenamento de dados HDFS, contanto que você possa reproduzir os dados no Amazon EMR [ pelo Amazon 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.
**Etapas da implementação**
1. **Identifique todas as fontes de dados para a workload**. Os dados podem ser armazenados em vários recursos, como [bancos de dados](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](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html) e [armazenamento de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulte a seção **Recursos** para encontrar **Documentos relacionados** sobre diferentes serviços da AWS onde os dados são armazenados e o recurso de backup que esses serviços 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 serviços de terceiros para criar backups dos dados**. O [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. O [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) lida com a replicação de dados automáticos de subsegundos em uma Região da AWS. A maioria dos serviços da AWS também possui recursos nativos para criar backups. O AWS Marketplace tem muitas soluções que também fornecem esses recursos. Consulte os **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 uma frequência 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 do 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 cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
**Documentos relacionados:**
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [What is AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) (O que é o AWS Data Sync?)
+ [What is Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) (O que é o Gateway de Volumes?)
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup)
+ [Snapshots do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Backing Up Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) (Fazer backup do Amazon EFS)
+ [Backing up Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) (Fazer backup do Amazon FSx para Windows File Server)
+ [Backup e restauração para o ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Creating a DB Cluster Snapshot in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) (Criar um snapshot do cluster de banco de dados no Neptune)
+ [Criar um snapshot do banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação)
+ [Replicação entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) com o Amazon S3
+ [EFS para EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exporting Log Data to Amazon S3](https://docs.aws.amazon.com/Amazon/latest/logs/S3Export.html) (Exportação de dados de log para o Amazon S3)
+ [Gerenciamento do ciclo de vida de objetos](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Usar backup e restauração sob demanda para o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Recuperação pontual para DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Criação de snapshots de índices no Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2021: Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc) (Backup, recuperação de desastres e proteção contra ransomware com a AWS)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE) (Demonstração: Backup entre contas e entre regiões)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Exemplos relacionados:**
+ [Well-Architected Lab - Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) (Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon 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/)
+ [Well-Architected Lab - Backup and Restore with Failback for Analytics Workload](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) (Laboratório do Well-Architected: backup e restauração com failback para workload do Analytics)
+ [Well-Architected Lab - Disaster Recovery - Backup and Restore](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) (Laboratório do Well-Architected: recuperação de desastres: backup e restauração)
# REL09-BP02 Proteger e criptografar backups
Controle e detecte o acesso a backups usando autenticação e autorização. Use a criptografia para prevenir e detectar se a integridade dos dados de backups está comprometida.
**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 é estabelecida:** alto
## Orientações para a implementação
Controle e detecte o acesso a backups usando autenticação e autorização, como o AWS Identity and Access Management (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 do lado do servidor, o Amazon S3 aceita os objetos como dados não criptografados e, depois, 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. Ao usar o AWS Elastic Disaster Recovery, todos os dados em trânsito e em repouso são criptografados. Com o Elastic Disaster Recovery, os dados em repouso podem ser criptografados usando a chave de criptografia de volume padrão do Amazon EBS ou uma chave personalizada gerenciada pelo cliente.
**Etapas da implementação**
1. Use a criptografia em cada um dos seus armazenamentos de dados. Se os dados de origem forem criptografados, o backup também será.
+ [Use criptografia no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). Você pode configurar a criptografia em repouso usando o AWS Key Management Service ao criar uma instância do RDS.
+ [Use criptografia em volumes do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Você pode configurar a criptografia padrão ou especificar uma chave exclusiva após a criação do volume.
+ Use a [criptografia do Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) necessária. O DynamoDB criptografa todos os dados em repouso. Você pode usar uma chave do AWS KMS de propriedade da AWS ou uma chave do KMS gerenciada pela AWS, especificando uma chave armazenada na sua conta.
+ [Criptografe seus dados armazenados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Configure a criptografia ao criar seu sistema de arquivos.
+ 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.
+ Escolha se deseja usar a [critptografia do Amazon EBS para o Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption) padrão ou personalizada. Essa opção criptografa os dados em repouso replicados nos discos da sub-rede da área de preparação e os discos replicados.
1. Implemente permissões de privilégio mínimo para acessar seus backups. Siga as práticas recomendadas para limitar o acesso aos backups, aos snapshots e às réplicas de acordo com as [práticas recomendadas de segurança](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
## Recursos
**Documentos relacionados:**
+ [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para 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)
+ [Replicar objetos criados com criptografia do lado do servidor (SSE) usando chaves do 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)
+ [Criptografar recursos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Encrypting Data and Metadata in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) (Criptografia de dados e metadados no Amazon EFS)
+ [Encryption for Backups in AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) (Criptografia para backups na AWS)
+ [Gerenciamento de tabelas criptografadas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilar Segurança: AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [O que é o AWS Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**Exemplos relacionados:**
+ [Well-Architected Lab - Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) (Laboratório do Well-Architected: implementação da replicação bidirecional entre regiões (CRR) para o Amazon S3)
# REL09-BP03 Realizar backup de dados automaticamente
Configure os backups para serem feitos automaticamente com base em uma programação periódica informada pelo objetivo de ponto de recuperação (RPO) ou de acordo com alterações no conjunto de dados. É necessário fazer frequentemente o backup automático de conjuntos de dados críticos com requisitos de baixa perda de dados, enquanto o backup de dados menos críticos, em que alguma perda é aceitável, pode ser feito com menos frequência.
**Resultado desejado:** um processo automatizado que cria backups de fontes de dados em uma frequência estabelecida.
**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 dessa 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 risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
É 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 [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 permite programar backups periódicos, até de hora em hora.
O Amazon RDS e o Amazon DynamoDB oferecem backup contínuo com recuperação a um ponto anterior no tempo. O versionamento do Amazon S3, quando habilitado, é automático. O [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) pode ser usado para automatizar a criação, a cópia e a exclusão de snapshots do Amazon EBS. Ele também pode automatizar a criação, a cópia, a suspensão e o cancelamento do registro de imagens de máquina da Amazon (AMIs) com base no Amazon EBS e seus snapshots subjacentes do Amazon EBS.
O AWS Elastic Disaster Recovery fornece replicação contínua no nível de bloco do ambiente de origem (on-premises ou a AWS) para a região de recuperação de destino. Os snapshots do Amazon EBS de um ponto anterior no tempo são criados automaticamente e gerenciados pelo serviço.
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.
**Etapas da implementação**
1. **Identifique fontes de dados** que estão sendo copiados manualmente. Para obter mais detalhes, 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).
1. **Determine o RPO** da workload. Para obter mais detalhes, 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).
1. **Use uma solução de backup automático ou um serviço gerenciado**. O AWS Backup é um serviço totalmente gerenciado que facilita [centralizar e automatizar a proteção de dados nos serviços da AWS, na nuvem e no ambiente on-premises](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). O uso de planos no AWS Backup permite a criação de regras que definem os recursos para backup e a frequência com que esses backups devem ser criados. A frequência deve ser informada pelo RPO estabelecido na Etapa 2. Para obter orientações práticas sobre como criar backups automáticos usando o AWS Backup, consulte [Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) (Teste de backup e restauração de dados). 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 incompatíveis** com 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.
**Nível de esforço do 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: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação)
+ [O que é o AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [O que é o AWS Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.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 de tempo de recuperação (RTO) e de ponto de recuperação (RPO).
**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 dessa 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 testes também garantem que a restauração e a recuperação sejam possíveis de acordo com o RTO da workload e qualquer perda de dados se enquadre no RPO da workload.
**Nível de risco exposto se esta prática recomendada não é 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 verificar se todos os dados estão disponíveis, não corrompidos, acessíveis e garantir que toda a perda de dados se enquadre no RPO da 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.
Ao usar a AWS, você pode criar um ambiente de teste e restaurar os 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.
Se todos os dados estiverem disponíveis, não corrompidos, acessíveis e qualquer perda de dados está de acordo com o RPO da 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.
O AWS Elastic Disaster Recovery oferece snapshots contínuos de recuperação a um ponto anterior no tempo de volumes do Amazon EBS. Como os servidores de origem são replicados, os estados de um ponto anterior no tempo são registrados ao longo do tempo com base na política configurada. O Elastic Disaster Recovery ajuda a verificar a integridade desses snapshots iniciando instâncias para fins de teste e simulação sem redirecionar o tráfego.
**Etapas da implementação**
1. **Identifique fontes de dados** das quais está sendo feito backup no momento e onde esses backups estão sendo armazenados. Para obter orientações de implementação, 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).
1. **Estabeleça critérios para a validação de dados** a 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 o RTO e o RPO** para restaurar os dados com base na criticidade deles. Para obter orientações de implementação, 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).
1. **Avalie sua capacidade de recuperação**. Revise sua estratégia de backup e de restauração para entender se ela pode cumprir o RTO e o RPO e ajuste a estratégia conforme necessário. Usando o [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 configuração da aplicação em relação à política de resiliência e relata se as metas de RTO e RPO podem ser cumpridas.
1. **Faça uma restauração de teste** com os 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 pode 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 você usar o AWS Elastic Disaster Recovery, poderá [iniciar uma simulação de recuperação](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Valide a recuperação de dados** do recurso restaurado com base nos critérios estabelecidos anteriormente para validação dos dados. Os dados restaurados e recuperados contêm o registro ou item mais recente no momento do backup? Esses dados se enquadram no RPO da workload?
1. **Calcule o tempo necessário** para a restauração e recuperação e compare-o com o RTO estabelecido. Esse processo se enquadra no RTO da workload? Por exemplo, compare o carimbo de data/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 carimbo de data/hora e essas informações estão disponíveis no [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 carimbo final de data/hora da conclusão da validação deve ser registrado pela lógica de validação. Se você usar um processo automático, serviços como o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) poderão ser usados 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 em que determinadas ações ocorreram. No AWS Backup, as ações de backup e restauração são chamadas de *trabalhos*, e esses trabalhos contêm informações de data e hora como parte dos metadados, que podem ser usados para calcular o tempo necessário para restauração e recuperação.
1. **Informe 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/), serviços como o Amazon Simple Notification Service (Amazon SNS) podem ser usados para enviar notificações por push como e-mail ou SMS às partes interessadas. [Essas mensagens também podem ser publicadas em aplicações 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 esse 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 a validação da recuperação de dados com o AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Além disso, [este laboratório do Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fornece uma experiência prática de 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/2023-10-03/framework/images/automated-backup-restore-process.png)
**Nível de esforço do plano de implementação:** moderado a alto, dependendo da complexidade dos critérios de validação.
## Recursos
**Documentos relacionados:**
+ [Automate data recovery validation with AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) (Automatizar validação de recuperação de dados com o AWS Backup)
+ [Parceiro do APN: parceiros que podem ajudar com o backup](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: products that can be used for backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) (AWS Marketplace: produtos que podem ser usados para backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) (Criar uma regra do EventBridge que é acionada de acordo com uma programação)
+ [Usar 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 Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [O que é o Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
**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/)
# CONFIABILIDADE 10. Como usar o isolamento de falhas para proteger sua workload?
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/2023-10-03/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/2023-10-03/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 cumprir os 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 datacenter on-premises, você deverá implementar capacidade suficiente para fazer uma recompilação completa da workload em conformidade com os objetivos de recuperação definidos.
**Nível de risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
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). Usando o [EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), os dados no EMR podem ser armazenados no Amazon S3, que, por sua vez, 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.
Para workloads com estado baseadas em servidor e implantadas em um datacenter on-premises, é possível usar o AWS Elastic Disaster Recovery para proteger as workloads na AWS. Se você já estiver hospedado na AWS, poderá usar o Elastic Disaster Recovery para proteger a workload em uma zona de disponibilidade ou região alternativa. O Elastic Disaster Recovery usa a replicação contínua no nível de bloco para uma área de preparação leve visando fornecer recuperação rápida e confiável de aplicações on-premises e na nuvem.
**Etapas da implementação**
1. 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 do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) para workloads de contêiner e instâncias que não têm requisitos para um endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados da instância.
+ Os dados do usuário do modelo de execução podem ser usados para implementar uma automação que pode recuperar automaticamente a maioria das workloads.
+ Use a [recuperação automática de instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) para workloads que exijam um único endereço de ID da instância, endereço IP privado, endereço IP elástico e metadados da instância.
+ 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 do ciclo de vida da instância do Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ou os [eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) para automatizar a autorreparação, em que não seja possível usar a escalabilidade automática ou a recuperação do EC2.
+ Use os eventos para chamar a automação que recuperará seu componente de acordo com a lógica do processo necessária.
+ Proteja workloads com estado que são limitadas a um único local usando o [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## 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 Amazon 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 Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto
Implemente arquiteturas de anteparo (também chamadas de arquiteturas baseadas em células) para restringir o efeito ou a falha em uma workload a um número limitado de componentes.
**Resultado desejado:** uma arquitetura baseada em células usa várias instâncias isoladas de uma workload, em que cada instância é considerada uma célula. Cada célula é independente, não compartilha o estado com outras células e processa um subconjunto das solicitações gerais da workload. Isso reduz o possível impacto de uma falha, como uma atualização de software incorreta, a uma célula individual e às solicitações que ela está processando. Se uma workload usa 10 células para atender a 100 solicitações, quando ocorre uma falha, 90% das solicitações gerais não seriam afetadas pela falha.
**Antipadrões comuns:**
+ Permitir que as células cresçam sem limites.
+ Aplicar implantações ou atualizações de código a todas as células ao mesmo tempo.
+ Compartilhar o estado ou os componentes entre as células (com a exceção da camada do roteador).
+ Adicionar negócios complexos ou rotear lógica para a camada do roteador.
+ Não minimizar as interações entre as células.
**Benefícios do estabelecimento dessa prática recomendada:** com arquiteturas baseadas em células, muitos tipos comuns de falhas são contidas na própria célula, fornecendo isolamento de falhas adicional. Esses limites de falhas podem fornecer resiliência com relação a tipos de falha que, de outra maneira, seriam difíceis de conter, como implantações de código sem êxito ou solicitações corrompidas ou que acionam um modo de falha específico (também conhecidas como *solicitações com conteúdo malicioso*).
## Orientação de implementação
Em um navio, as anteparas garantem que uma ruptura no casco seja contida em uma seção do casco. Em sistemas complexos, esse padrão costuma ser replicado para permitir o isolamento de falhas. Os limites isolados de falhas restringem o efeito de uma falha em uma workload 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. Na AWS, os clientes podem usar várias zonas de disponibilidade e regiões para fornecer o isolamento de falhas, mas o conceito do isolamento de falhas também pode ser estendido à arquitetura da workload.
A workload geral é composta por células particionadas por uma chave de partição. Essa chave precisa se alinhar à *granularidade* do serviço, ou da maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Exemplos de chaves de partição são ID de cliente, ID de recurso ou qualquer outro parâmetro facilmente acessível na maioria das chamadas de API. Uma camada de roteamento de célula distribui solicitações a células individuais com base na chave de partição e apresenta um único endpoint aos clientes.
![\[Diagrama mostrando arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)
**Etapas da implementação**
Ao projetar uma arquitetura baseada em células, há várias considerações de design a levar em conta:
1. **Chave de partição**: deve-se dedicar uma consideração especial ao escolher a chave de partição.
+ Ela precisa se alinhar à granularidade do serviço, ou da maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Dentre os exemplos estão o `ID de cliente` ou `ID de recurso`.
+ A chave de partição deve estar disponível em todas as solicitações, seja diretamente ou de uma maneira que possa ser facilmente inferida de forma determinística por outros parâmetros.
1. **Mapeamento de células persistentes**: os serviços de upstream só devem interagir com uma única célula pelo ciclo de vida dos recursos.
+ Dependendo da workload, uma estratégia de migração de células pode ser necessária para migrar os dados de uma célula para outra. Um possível cenário de quando é necessário fazer uma migração de célula seria quando um usuário ou recurso específico na workload fica grande demais e exige uma célula dedicada.
+ As células não devem compartilhar estado ou componentes entre si.
+ Consequentemente, as interações entre as células devem ser evitadas e mantidas no mínimo, já que elas podem criar dependências entre as células e, assim, reduzir as melhorias do isolamento de falhas.
1. **Camada do roteador**: a camada do roteador é um componente compartilhado entre células e, portanto, não pode seguir a mesma estratégia de compartimentalização das células.
+ É recomendável que a camada do roteador distribua as solicitações para células individuais usando um algoritmo de mapeamento de partição de maneira computacionalmente eficiente, como combinando funções de hash criptográficas e aritmética modular para mapear chaves de partição a células.
+ Para evitar impactos em várias células, a camada de roteamento deve permanecer o mais simples e horizontalmente escalável possível, o que exige evitar uma lógica empresarial complexa nessa camada. Isso tem o benefício adicional de facilitar a compreensão de seu comportamento esperado em todos os momentos, permitindo uma capacidade de testes completa. Conforme explicado por Colm MacCárthaigh em [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) (Confiabilidade, trabalho constante e uma boa xícara de café), designs simples e padrões de trabalho constantes produzem sistemas confiáveis e reduzem a antifragilidade.
1. **Tamanho da célula**: as células devem ter um tamanho máximo e não devem ter permissão para crescer além disso.
+ O tamanho máximo deve ser identificado com a realização de testes completos, até que os pontos de ruptura sejam atingidos e as margens operacionais seguras sejam estabelecidas. Para obter mais detalhes sobre como implementar práticas de testes, consulte [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md)
+ A workload geral deve crescer com a adição de mais células, permitindo que a workload seja escalada com aumentos na demanda.
1. **Estratégias de várias zonas de disponibilidade ou várias regiões**: várias camadas de resiliência devem ser utilizadas para a proteção contra diferentes domínios de falha.
+ Para resiliência, você deve usar uma abordagem que crie 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 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. Para obter mais detalhes, consulte [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md).
1. **Implantação de código**: uma estratégia de implantação de código escalonada deve ter preferência com relação à implantação de alterações de código em todas as células ao mesmo tempo.
+ Isso ajudará a reduzir a possibilidade de falhas em várias células devido a uma implantação incorreta ou a erro humano. Para obter mais detalhes, consulte [Automating safe, hands-off deployment](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) (Automatizar uma implantação prática e segura).
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL07-BP04 Fazer o teste de carga da sua workload](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP02 Escolher os locais apropriados para sua implantação de vários locais](rel_fault_isolation_select_location.md)
**Documentos relacionados:**
+ [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) (Confiabilidade, trabalho constante e uma boa xícara de café)
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/) (AWS e compartimentalização)
+ [isolamento de carga de trabalho usando fragmentos aleatórios](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automating safe, hands-off deployment](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) (Automatizar uma implantação prática e segura)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: fechar ciclos e abrir mentes: como controlar sistemas, sejam grandes ou pequenos)
+ [AWS re:Invent 2018: como a AWS reduz o impacto das falhas (ARC338)](https://youtu.be/swQbA4zub20)
+ [Fragmentação aleatória: AWS re:Invent 2019: apresentação da Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021: tudo falha o tempo todo: como criar o design visando a resiliência ](https://www.youtube.com/watch?v=wUzSeSfu1XA)
**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/)
# CONFIABILIDADE 11. Como projetar a workload 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 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-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade](rel_withstand_component_failures_service_level_agreements.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 falhas ou degradações assim que elas ocorrerem. Monitore os indicadores-chave de performance (KPIs) 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 de 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.
**Resultado desejado:** Os componentes essenciais de uma workload são monitorados de forma independente para detectar e alertar sobre falhas quando e onde elas acontecem.
**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 objetivo de tempo de recuperação (RTO)
+ Somente as interfaces da workload voltadas para o cliente são monitoradas 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 workload.
+ São criados monitores em excesso.
**Benefícios de estabelecer esta prática recomendada:** O monitoramento adequado de todas as camadas permite reduzir o tempo de recuperação ao reduzir o tempo de detecção.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Identifique todas as workloads que serão analisadas para monitoramento. Depois de identificar todos os componentes da workload que precisarão ser monitorados, você precisará determinar o intervalo de monitoramento. O intervalo de monitoramento terá um impacto direto na rapidez com que a recuperação pode ser iniciada com base no tempo necessário para detectar uma falha. O tempo médio de detecção (MTTD) é a quantidade de tempo entre a ocorrência de uma falha e o início das operações de reparo. A lista de serviços deve ser extensa e completa.
O monitoramento deve abranger todas as camadas da pilha de aplicações, incluindo aplicação, plataforma, infraestrutura e rede.
Sua estratégia de monitoramento deve considerar o impacto de *falhas cinzentas*. Para obter mais detalhes sobre falhas cinzentas, consulte [ Falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) no whitepaper Advanced Multi-AZ Resilience Patterns (Padrões avançados de resiliência Multi-AZ).
### Etapas da implementaçã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 objetivo de tempo de recuperação (RTO) para determinar a frequência da coleta.
+ Configure o monitoramento detalhado de componentes e serviços gerenciados.
+ Determine se [o monitoramento detalhado para instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) e [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) são necessários. O monitoramento detalhado fornece métricas de intervalo de um minuto, e o monitoramento padrão fornece métricas de intervalo de cinco minutos.
+ Determine se [o monitoramento aprimorado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) para RDS é necessário. O monitoramento aprimorado usa um agente nas instâncias do RDS para obter informações úteis sobre processos ou threads diferentes.
+ Determine os requisitos de monitoramento de componentes essenciais sem servidor para [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), o [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), o [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs), e todos os tipos de [balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html).
+ Determine os requisitos de monitoramento dos componentes de armazenamento para [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), o [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), o [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)e o [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html).
+ Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) para medir os indicadores-chave de performance (KPIs) do negócio. As workloads implementam as principais funções empresariais, que devem ser usadas como KPIs para ajudar a identificar quando ocorre um problema indireto.
+ Utilize os canários de usuário para monitorar a experiência do usuário e verificar se há falhas. [O teste de transação sintética](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (também conhecido como “teste canário”, que não deve ser confundido com “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 workload de diversos locais remotos.
+ Crie [métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) que rastreiem 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.
+ [Defina alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para detectar quando uma parte da workload não estiver funcionando corretamente e indicar quando deve ser feita a escalabilidade automática dos recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload.
+ Crie [painéis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) para visualizar suas 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.
+ Crie [monitoramento de rastreamento distribuído](https://aws.amazon.com/xray/faqs/) para seus serviços. Com o monitoramento distribuído, você compreende como está a performance de sua aplicação e seus serviços subjacentes para identificar e solucionar a causa principal de problemas e erros de performance.
+ Crie painéis de sistemas de monitoramento (usando [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) ou [X-Ray](https://aws.amazon.com/xray/faqs/)) e coleta de dados em uma Região e conta separadas.
+ Crie integração para o monitoramento do [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) para permitir a visibilidade de monitoramento de recursos da AWS que possam ter degradações. Para workloads essenciais aos negócios, essa solução fornece acesso a alertas proativos e em tempo real para serviços da AWS.
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Documentos relacionados:**
+ [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 da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoramento aprimorado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoramento de grupos e instâncias do Auto Scaling 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 dos 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)
+ [Uso de painéis do CloudWatch entre regiões e contas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [Uso do rastreamento do X-Ray entre regiões e contas](https://aws.amazon.com/xray/faqs/)
+ [Compreensão da disponibilidade](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
+ [Implementação do Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
**Vídeos relacionados:**
+ [Mitigating gray failures (Mitigando falhas cinzentas)](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.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)
+ [Um workshop de observabilidade: explore o X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 Failover para recursos íntegros
Se ocorrer uma falha no recurso, os recursos íntegros deverão 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 realizar failover para recursos íntegros em locais sem problemas.
Ao projetar um serviço, distribua a carga entre recursos, zonas de disponibilidade ou regiões. Portanto, a falha ou a deficiência de um recurso individual podem ser atenuadas transferindo o tráfego para os recursos íntegros restantes. Pense em como os serviços são descobertos e encaminhados em caso de falha.
Projete seus serviços pensando na recuperação de falhas. Na AWS, projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente datastores que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. 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.
Os padrões e os designs que permitem o failover variam para cada serviço de plataforma da AWS. Muitos serviços gerenciados nativos da AWS são nativamente várias zonas de disponibilidade (como o Lambda ou o API Gateway). Outros serviços da AWS (como EC2 e EKS) exigem designs específicos de práticas recomendadas para oferecer compatibilidade com o failover de recursos ou armazenamento de dados entre AZs.
O monitoramento deve ser configurado para conferir se o recurso de failover está íntegro, acompanhar o andamento do failover dos recursos e monitorar a recuperação do processo empresarial.
**Resultado desejado:** Os sistemas são capazes de usar novos recursos de forma automática ou manual para se recuperarem da degradação.
**Antipadrões comuns:**
+ Planejar o fracasso não faz parte da fase de planejamento e design.
+ O RTO e o RPO não são estabelecidos.
+ Monitoramento insuficiente para detectar falhas nos recursos.
+ Isolamento adequado dos domínios de falha.
+ O failover multirregional não é considerado.
+ A detecção de falhas é sensível ou agressiva demais ao decidir realizar o failover.
+ Não testar nem validar o design de failover.
+ Executar a automação de autorreparação sem notificar que a reparação era necessária.
+ Falta de um período de amortecimento a fim de evitar falhas muito precoces.
**Benefícios de estabelecer esta prática recomendada:** Você pode criar sistemas mais resilientes que mantenham a confiabilidade em caso de falhas, degradando-se normalmente e se recuperando com rapidez.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Os serviços da AWS, como o [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) e o [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), ajudam a distribuir a 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 workloads multirregionais, os projetos são mais complicados. Por exemplo, réplicas de leitura entre regiões permitem que você implante os dados em várias Regiões da AWS. No entanto, o failover ainda é necessário para promover a réplica de leitura como primária e direcionar seu tráfego para o novo endpoint. O Amazon Route 53, o Route 53, o ARC, o CloudFront e o AWS Global Accelerator podem ajudar a direcionar o tráfego entre Regiões da AWS.
Serviços da AWS, como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge ou Amazon DynamoDB, são implantados automaticamente em várias zonas de disponibilidade pela AWS. Em caso de falha, esses serviços da AWS direcionam 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, o Amazon Aurora, o Amazon Redshift, o Amazon EKS ou o Amazon ECS, Multi-AZ é uma opção de configuração. A AWS poderá direcionar o tráfego para a instância íntegra se o failover for iniciado. Essa ação de failover pode ser realizada pela AWS ou conforme exigido pelo cliente.
Para instâncias do Amazon EC2, o Amazon Redshift, tarefas do Amazon ECS ou pods do Amazon EKS, você escolhe em quais zonas de disponibilidade implantar. Para alguns designs, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas não íntegras e direcionar o tráfego para as zonas íntegras. O Elastic Load Balancing também pode rotear o tráfego para componentes em seu datacenter on-premises.
Para o failover de tráfego em várias regiões, o redirecionamento pode utilizar o Amazon Route 53, o ARC, o AWS Global Accelerator, o Route 53 Private DNS for VPCs ou o CloudFront para oferecer uma maneira de definir domínios da Internet e atribuir políticas de roteamento, incluindo verificações de integridade, para rotear o tráfego para regiões íntegras. O AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para sua aplicação e, depois, são roteados para os endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet com o objetivo de melhorar o desempenho e a confiabilidade.
### Etapas da implementação
+ Crie designs de failover para todas as aplicações e serviços apropriados. Isole cada componente da arquitetura e crie designs de failover que atendam ao RTO e ao RPO de cada componente.
+ Configure ambientes inferiores (como desenvolvimento ou teste) com todos os serviços necessários para ter um plano de failover. Implemente as soluções usando a infraestrutura como código (IaC) para garantir a repetibilidade.
+ Configure um local de recuperação, como uma segunda região, para implementar e testar os designs de failover. Se necessário, os recursos para testes podem ser configurados temporariamente para limitar os custos adicionais.
+ Determine quais planos de failover são automatizados pela AWS, quais podem ser automatizados por um processo de DevOps e quais podem ser manuais. Documente e avalie o RTO e o RPO de cada serviço.
+ Crie um manual de failover e inclua todas as etapas para realizar o failover de cada recurso, aplicação e serviço.
+ Crie um manual de failback e inclua todas as etapas de failback (com tempo) de cada recurso, aplicação e serviço.
+ Crie um plano para iniciar e ensaiar o manual. Use simulações e testes de caos para testar a automação e as etapas do manual.
+ Para danos na localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais sem problemas. Confira a cota, os níveis de ajuste de escala automático e os recursos em execução antes do teste de failover.
## Recursos
**Práticas recomendadas relacionadas ao Well-Architected:**
+ [REL13 – Plano para DR](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 – Usar o isolamento de falhas para proteger a workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**Documentos relacionados:**
+ [Setting RTO and RPO Targets](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [Set up ARC with application loadbalancers](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/)
+ [Failover using Route 53 Weighted routing](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)
+ [DR with ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2 Deployments - Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-)
+ [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Switch traffic using ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [Lambda with an Application Load Balancer and Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [ECR cross region replication and Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Secrets manager cross region replication configuration](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [Enable cross region replication for EFS and Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [EFS Cross Region Replication and Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [Networking Failover](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [S3 Endpoint failover using MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [Create cross region replication for S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Failover Regional API Gateway with ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449)
+ [Failover using multi-region global accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [Failover with DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b)
**Exemplos relacionados:**
+ [Recuperação de desastres na AWS](https://disaster-recovery.workshop.aws/en/)
+ [Recuperação elástica de desastres na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# 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. As degradações podem ser corrigidas automaticamente por meio de mecanismos internos de serviço ou exigir que os recursos sejam reiniciados ou removidos por meio de ações de remediação.
Para aplicações autogerenciadas e reparação entre regiões, os projetos de recuperação e os processos de recuperação automatizados podem ser extraídos de [práticas recomendadas existentes](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/).
A capacidade de reiniciar ou remover um recurso é uma ferramenta importante para corrigir falhas. Uma prática recomendada é deixar os serviços sem estado sempre que possível. Isso evita a perda de dados ou a disponibilidade na reinicialização do recurso. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, uma instância de computação ou função sem servidor) 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.
Reiniciar ou tentar novamente também se aplica às solicitações 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. A capacidade de reiniciar é um mecanismo de recuperação presente na computação orientada para a recuperação e arquiteturas de cluster de alta disponibilidade.
**Resultado desejado:** Ações automatizadas são executadas para corrigir a detecção de uma falha.
**Antipadrões comuns:**
+ Provisionamento de recursos sem dimensionamento automático.
+ 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 do ajuste de escala automático e recuperação automática.
+ Sem automação para failover nos bancos de dados.
+ Não há métodos automatizados para redirecionar o tráfego para novos endpoints.
+ Sem replicação de armazenamento.
**Benefícios de estabelecer esta prática recomendada:** A reparação automatizada pode reduzir seu tempo médio de recuperação e melhorar sua disponibilidade.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** alto
## Orientação para implementação
Os designs para Amazon EKS ou outros serviços do Kubernetes devem incluir conjuntos mínimos e máximos de réplicas ou com estado e tamanho mínimo do cluster e do grupo de nós. Esses mecanismos fornecem uma quantidade mínima de recursos de processamento continuamente disponíveis e, ao mesmo tempo, remediam automaticamente quaisquer falhas usando o ambiente de gerenciamento do Kubernetes.
Os padrões de design que são acessados por meio de um balanceador de carga usando clusters de computação devem utilizar grupos Auto Scaling. O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada da aplicação entre vários destinos e dispositivos virtuais em uma ou mais Zonas de Disponibilidade (AZs).
Designs baseados em computação em cluster que não usam balanceamento de carga devem ter seu tamanho projetado para a perda de pelo menos um nó. Isso permitirá que o serviço se mantenha funcionando em uma capacidade potencialmente reduzida enquanto recupera um novo nó. Entre os exemplos de serviço estão Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK e Amazon OpenSearch Service. Muitos desses serviços podem ser projetados com recursos adicionais de recuperação automática. Algumas tecnologias de cluster devem gerar um alerta sobre a perda de um nó, acionando um fluxo de trabalho automático ou manual para recriar um novo nó. Esse fluxo de trabalho pode ser automatizado usando o AWS Systems Manager para corrigir problemas rapidamente.
É 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 então invocar AWS Lambda, Systems Manager Automation ou outros destinos para executar uma lógica de remediação personalizada na workload. O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instância 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. Para substituições em grande escala (como a perda de uma Zona de Disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade.
### Etapas da implementação
+ Use grupos do Auto Scaling para implantar camadas em uma workload. [O Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) pode executar a autorreparação em aplicações sem estado e adicionar e remover capacidade.
+ Para instâncias computacionais mencionadas anteriormente, use [balanceamento de carga](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) e escolha o tipo apropriado de balanceador de carga.
+ Considere a recuperação para Amazon RDS. Com instâncias em espera, configure para [failover automático](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) para a instância em espera. Para a réplica de leitura do Amazon RDS, é necessário um fluxo de trabalho automatizado para tornar uma réplica de leitura primária.
+ Implemente [recuperação automática em instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) que têm aplicações implantadas que não podem estar em vários locais e podem 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 a aplicação não puder ser implantada em vários locais. Os metadados da instância e os endereços IP associados são mantidos, bem como os [volumes do EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) e pontos de montagem no [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) ou [sistemas de arquivos para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) e [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Com o uso do [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html), é possível configurar a autorreparação das instâncias do EC2 no nível da camada.
+ Implemente a recuperação automatizada usando o [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) e o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) quando não for possível usar o ajuste de escala automático ou a recuperação automática, ou quando a recuperação automática falhar. Quando não for possível usar o ajuste de escala automático e a recuperação automática ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda.
+ [O Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) pode ser usado para monitorar e filtrar eventos como [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ou mudanças de estado em outros serviços da AWS. Com base nas informações do evento, ele pode invocar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload.
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**Documentos relacionados:**
+ [Como funciona o AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.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)
+ [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)
+ [AWS OpsWorks: como usar a correção automática para substituir instâncias com falha](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [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)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Uso dos alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Failover do Amazon RDS](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM - Automação do Systems Manager](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [Práticas recomendadas de arquitetura resiliente](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**Vídeos relacionados:**
+ [Provisionar e escalar automaticamente o OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Failover automático do Amazon RDS](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**Exemplos relacionados:**
+ [Workshop sobre Auto Scaling](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling)
+ [Workshop de failover do Amazon RDS](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação
Os ambientes de gerenciamento fornecem as APIs administrativas usadas para criar, ler e descrever, atualizar, excluir e listar recursos (CRUDL), enquanto os planos de dados lidam com o tráfego diário de serviços. Ao implementar respostas de recuperação ou mitigação a eventos potencialmente impactantes na resiliência, concentre-se em usar um número mínimo de operações do ambiente de gerenciamento para recuperar, redimensionar, restaurar, reparar ou realizar o failover do serviço. A ação do plano de dados deve substituir qualquer atividade durante esses eventos de degradação.
Por exemplo, estas são ações do ambiente de gerenciamento: iniciar uma nova instância de computação, criar armazenamento em bloco e descrever serviços de fila. Quando você executa instâncias de computação, o ambiente de gerenciamento precisa realizar várias tarefas, como encontrar um host físico com capacidade, alocar interfaces de rede, preparar volumes de armazenamento em blocos locais, gerar credenciais e adicionar regras de segurança. Os ambientes de gerenciamento tendem a ser uma orquestração complicada.
**Resultado desejado:** Quando um recurso entra em um estado comprometido, o sistema é capaz de se recuperar automática ou manualmente, transferindo o tráfego de recursos danificados para recursos saudáveis.
**Antipadrões comuns:**
+ Dependência da alteração dos registros DNS para redirecionar o tráfego.
+ Dependência das operações de escalonamento do ambiente de gerenciamento para substituir componentes danificados devido a recursos insuficientemente provisionados.
+ Dependência de ações de ambiente de gerenciamento abrangentes, com vários serviços e várias APIs para remediar qualquer categoria de deficiência.
**Benefícios de estabelecer esta prática recomendada:** O aumento da taxa de sucesso da remediação automatizada pode reduzir seu tempo médio de recuperação e melhorar a disponibilidade da workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** médio: para certos tipos de degradação do serviço, os ambientes de gerenciamento são afetados. As dependências do uso extensivo do ambiente de gerenciamento para remediação podem aumentar o tempo de recuperação (RTO) e o tempo médio de recuperação (MTTR).
## Orientação para implementação
Para limitar as ações do plano de dados, avalie cada serviço quanto às ações necessárias para restaurar o serviço.
Use o Amazon Application Recovery Controller (ARC) para mudar o tráfego de DNS. 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.
As políticas de roteamento do Route 53 usam o ambiente de gerenciamento. Portanto, não confie nele para 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: Leste dos EUA (Norte da Virgínia). 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 o Amazon EC2, use designs de estabilidade estática para limitar as ações do ambiente de gerenciamento. As ações do ambiente de gerenciamento incluem a ampliação de recursos individualmente ou usando grupos do Auto Scaling (ASG). Para obter os níveis mais altos de resiliência, provisione capacidade suficiente no cluster usado para failover. Se essa capacidade precisar ser limitada, defina valores no sistema geral completo para definir com segurança o tráfego total que atinge o conjunto limitado de recursos.
Para serviços como Amazon DynamoDB, Amazon API Gateway, balanceadores de carga e AWS Lambda sem servidor, o uso aproveita o plano de dados. No entanto, criar novas funções, balanceadores de carga, gateways de API ou tabelas de DynamoDB é uma ação do ambiente de gerenciamento e deve ser concluída antes da degradação, como preparação para um evento e ensaio das ações de failover. Para o Amazon RDS, as ações do plano de dados permitem o acesso aos dados.
Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender metas de alta disponibilidade, consulte [Estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/).
Entenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento.
### Etapas da implementação
Para cada workload que precisa ser restaurada após um evento de degradação, avalie o runbook de failover, o projeto de alta disponibilidade, o projeto de recuperação automática ou o plano de restauração de recursos de HA. Identifique cada ação que pode ser considerada uma ação do ambiente de gerenciamento.
Considere alterar a ação de gerenciamento para uma ação do plano de dados:
+ Auto Scaling (ambiente de gerenciamento) em comparação com recursos do Amazon EC2 pré-escalados (plano de dados)
+ Migre para Lambda e seus métodos de escalabilidade (plano de dados) ou Amazon EC2 e ASG (ambiente de gerenciamento)
+ Avalie qualquer projeto usando o Kubernetes e a natureza das ações do ambiente de gerenciamento. Adicionar pods é uma ação do plano de dados no Kubernetes. As ações devem se limitar à adição de pods e não adição de nós. O uso de [nós com provisionamento excessivo](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) é o método preferido para limitar as ações do ambiente de gerenciamento
Considere abordagens alternativas que permitam que as ações do plano de dados afetem a mesma remediação.
+ Alteração de registro Route 53 (ambiente de gerenciamento) ou ARC (plano de dados)
+ [ Verificações de integridade do Route 53 para atualizações mais automatizadas ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
Se o serviço for essencial, considere alguns serviços em uma região secundária para permitir mais ações no ambiente de gerenciamento e no plano de dados em uma região não afetada.
+ Amazon EC2 Auto Scaling ou Amazon EKS em uma região primária em comparação com Amazon EC2 Auto Scaling ou Amazon EKS em uma região secundária e roteando o tráfego para a região secundária (ação do ambiente de gerenciamento).
+ Faça uma réplica de leitura na primária secundária ou tente a mesma ação na região primária (ação do ambiente de gerenciamento).
## Recursos
**Práticas recomendadas relacionadas:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**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)
+ [ Ambiente de gerenciamento e plano de dados do Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**Vídeos relacionados:**
+ [ Back to Basics - Using Static Stability (De volta ao básico: uso da estabilidade estática) ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Building resilient multi-site workloads using AWS global services (Criação de workloads resilientes em vários sites usando serviços globais da AWS) ](https://www.youtube.com/watch?v=62ZQHTruBnk)
**Exemplos relacionados:**
+ [Introdução ao Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [ 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/)
+ [ 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/)
+ [ Estabilidade estática usando Zonas de disponibilidade ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**Ferramentas relacionadas:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 Usar estabilidade estática para evitar o comportamento bimodal
As workloads devem ser estaticamente estáveis e operar somente em um único modo normal. O comportamento bimodal ocorre quando a workload exibe um comportamento diferente nos modos normal e de falha.
Por exemplo, você pode tentar se recuperar de uma falha na zona de disponibilidade iniciando novas instâncias em uma zona de disponibilidade diferente. Isso pode resultar em uma resposta bimodal durante um modo de falha. Em vez disso, você deve criar workloads que sejam estaticamente estáveis e que operem em apenas um modo. Neste exemplo, essas instâncias deveriam ter sido provisionadas na segunda zona de disponibilidade antes da falha. Esse design de estabilidade estática verifica se a workload opera somente em um único modo.
**Resultado desejado:** As workloads não apresentam comportamento bimodal durante os modos normal e de falha.
**Antipadrões comuns:**
+ Supor que os recursos sempre possam ser provisionados, independentemente do escopo da falha.
+ Tentar adquirir recursos dinamicamente durante uma falha.
+ Não provisionar recursos adequados entre zonas ou regiões até que ocorra uma falha.
+ Pensar em projetos estáticos estáveis somente para recursos computacionais.
**Benefícios de estabelecer esta prática recomendada:** As workloads executadas com projetos estaticamente estáveis podem ter resultados previsíveis durante eventos normais e de falha.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
O comportamento bimodal ocorre quando a workload apresenta um comportamento diferente nos modos normal e de falha (por exemplo, depender da inicialização de novas instâncias se uma zona de disponibilidade falhar). Um exemplo de comportamento bimodal é quando projetos estáveis do Amazon EC2 provisionam instâncias suficientes em cada zona de disponibilidade para lidar com a carga da workload se uma AZ for removida. A integridade do Elastic Load Balancing ou do Amazon Route 53 conferiria a possibilidade de isolar a carga das instâncias prejudicadas. 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. A estabilidade estática para implantação de computação (como instâncias ou contêineres do EC2) resulta na mais alta confiabilidade.
![\[Diagrama mostrando a estabilidade estática de instâncias do EC2 em várias zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/static-stability.png)
Isso deve ser comparado ao custo desse modelo e ao valor comercial de manter a workload em todos os casos de resiliência. É mais barato provisionar menos capacidade computacional e depender da inicialização de novas instâncias em caso de falha. No entanto, para falhas em grande escala (como um dano regional ou da zona de disponibilidade), essa abordagem é menos eficaz porque depende tanto de um plano operacional quanto de recursos suficientes disponíveis nas zonas ou regiões não afetadas.
A solução também deve comparar a confiabilidade com os custos necessários para a workload. As arquiteturas de estabilidade estática se aplicam a uma variedade de arquiteturas, incluindo instâncias de computação espalhadas por zonas de disponibilidade, projetos de réplicas de leitura de banco de dados, projetos de cluster do Kubernetes (Amazon EKS) e arquiteturas de failover de várias regiões.
Também é possível implementar um design mais estável estaticamente usando mais recursos em cada zona. Ao adicionar mais zonas, você reduz a quantidade de computação adicional necessária para a estabilidade estática.
Um exemplo de comportamento bimodal seria um tempo limite de rede que poderia fazer com que um sistema tentasse atualizar seu próprio estado de configuração por completo. Isso adicionaria uma carga inesperada a outro componente e poderia fazê-lo falhar, resultando em outras consequências inesperadas. Esse ciclo de feedback negativo afeta a disponibilidade da workload. Em vez disso, você pode criar sistemas estaticamente estáveis e operar em apenas um modo. Um design estático estável faria um trabalho constante e sempre atualizaria o estado da configuração em um ritmo fixo. Quando uma chamada falha, a workload usa o valor previamente armazenado em cache e inicia um alarme.
Outro exemplo de comportamento bimodal é permitir que os clientes ignorem o cache da workload em caso de falhas. Essa pode parecer uma solução que acomoda as necessidades do cliente, mas pode alterar significativamente as demandas da workload e provavelmente resultar em falhas.
Avalie workloads importantes para determinar quais workloads exigem esse tipo de projeto de resiliência. Para as que são consideradas críticas, cada componente da aplicação deve ser revisado. Exemplos de tipos de serviço que exigem avaliações de estabilidade estática são:
+ **Computação**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2
+ **Bancos de dados**: Amazon Redshift, Amazon RDS, Amazon Aurora
+ **Armazenamento**: Amazon S3 (Zona única), Amazon EFS (montagens), Amazon FSx (montagens)
+ **Balanceadores de carga:** Em determinados projetos
### Etapas da implementação
+ Crie sistemas que sejam estaticamente estáveis e que operem em apenas um modo. Nesse caso, provisione instâncias suficientes em cada zona de disponibilidade ou região para lidar com a capacidade da workload se uma zona de disponibilidade ou região for removida. Uma variedade de serviços pode ser usada para roteamento a recursos íntegros, como:
+ [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Roteamento de várias regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ Configure [réplicas de leitura do banco de dados](https://aws.amazon.com/rds/features/multi-az/) para contabilizar a perda de uma única instância principal ou de uma réplica de leitura. Se o tráfego estiver sendo servido por réplicas de leitura, a quantidade em cada zona de disponibilidade e cada região deve ser igual à necessidade geral em caso de falha na zona ou região.
+ Configure dados importantes no armazenamento do Amazon S3, projetado para ser estaticamente estável para dados armazenados em caso de falha na zona de disponibilidade. Se [Se a classe de armazenamento Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) for usada, ela não deverá ser considerada estaticamente estável, pois a perda dessa zona minimiza o acesso a esses dados armazenados.
+ [Às vezes, os balanceadores de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) são configurados incorretamente ou intencionalmente para atender a uma zona de disponibilidade específica. Nesse caso, o design estaticamente estável pode envolver a distribuição de uma workload entre várias zonas de disponibilidade em um design mais complexo. O design original pode ser usado para reduzir o tráfego entre zonas por motivos de segurança, latência ou custo.
## Recursos
**Práticas recomendadas relacionadas ao Well-Architected:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**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)
+ [Limites de isolamento de falhas](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [Estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Multi-AZ do Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
+ [Minimizar dependências em um plano de recuperação de desastres](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Roteamento de DNS entre regiões](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [Roteamento de várias regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Zona única do Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Balanceamento de carga entre zonas](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.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:**
+ [A Amazon Builders’ Library: estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
# REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
As notificações são enviadas após a detecção de limites violados, mesmo que o evento causado pelo problema tenha sido resolvido automaticamente.
A correção automatizada permite que a workload 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.
Os sistemas resilientes são projetados para que os eventos de degradação sejam comunicados imediatamente às equipes apropriadas. Essas notificações devem ser enviadas por meio de um ou vários canais de comunicação.
**Resultado desejado: **Os alertas são enviados imediatamente às equipes de operações quando os limites são violados. Esses alertas podem incluir taxas de erro, latência ou outras métricas importantes de indicadores-chave de performance (KPI), permitindo que esses problemas sejam resolvidos o mais rápido possível e o impacto do usuário seja evitado ou minimizado.
**Antipadrões comuns:**
+ Enviar muitos alarmes.
+ Enviar alarmes que não resultam em ações concretas.
+ Definir limites de alarme muito altos (supersensíveis) ou muito baixos (subsensíveis).
+ Não enviar alarmes para dependências externas.
+ Não considerar [falhas cinzentas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) ao projetar monitoramento e alarmes.
+ Executar a automação da correção, mas sem notificar a equipe apropriada de que a correção era necessária.
**Benefícios de estabelecer esta prática recomendada:** As notificações de recuperação alertam as equipes operacionais e empresariais sobre as degradações do serviço, para que possam reagir imediatamente a fim de minimizar o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR). As notificações de eventos de recuperação também garantem que você não ignore problemas que ocorrem com pouca frequência.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio. A falha na implementação de mecanismos adequados de monitoramento e notificação de eventos pode resultar em falha na detecção de padrões de problemas, incluindo aqueles resolvidos pela recuperação automática. Uma equipe só será informada da degradação do sistema quando os usuários entrarem em contato com o atendimento ao cliente ou por acaso.
## Orientações para a implementação
Ao definir uma estratégia de monitoramento, um alarme acionado é um evento comum. Esse evento provavelmente conteria um identificador para o alarme, o estado do alarme (como `EM ALARME` ou `OK`) e detalhes do que o desencadeou. Em muitos casos, deve-se detectar um evento de alarme e enviar uma notificação por e-mail. Este é um exemplo de uma ação em um alarme. A notificação do alarme é fundamental para a observabilidade, pois informa às pessoas certas que há um problema. No entanto, quando a ação sobre eventos amadurece em sua solução de observabilidade, ela pode corrigir automaticamente o problema sem a necessidade de intervenção humana.
Depois que os alarmes de monitoramento de KPI forem estabelecidos, os alertas deverão ser enviados às equipes apropriadas quando os limites forem excedidos. Esses alertas também podem ser usados para acionar processos automatizados que tentarão remediar a degradação.
Para um monitoramento de limite mais complexo, considere alarmes compostos. Eles usam vários alarmes de monitoramento de KPI para criar um alerta com base na lógica operacional de negócios. Os 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 ou Amazon EventBridge.
### Etapas para a implementação
Crie vários tipos de alarme com base na forma como as workloads são monitoradas, por exemplo:
+ Os alarmes de aplicações são usados para detectar quando alguma parte da workload não está funcionando adequadamente.
+ [Alarmes de infraestrutura](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indicam quando escalar os recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload horizontalmente.
+ Simples [alarmes estáticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) podem ser criados para monitorar quando uma métrica ultrapassa um limite estático durante um número específico de períodos de avaliação.
+ [Os alarmes compostos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) podem representar alarmes complexos de várias origens.
+ Depois que o alarme for criado, crie eventos de notificação apropriados. Você pode invocar diretamente uma [API do Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para enviar notificações e vincular qualquer automação para correção ou comunicação.
+ integre o [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) para permitir a visibilidade de monitoramento de recursos da AWS que possam ter degradações. Para workloads essenciais aos negócios, essa solução fornece acesso a alertas proativos e em tempo real para serviços da AWS.
## Recursos
**Práticas recomendadas relacionadas ao Well-Architected:**
+ [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
**Documentos relacionados:**
+ [Criar 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)
+ [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Uso dos alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/)
+ [Setup CloudWatch Composite alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [What's new in AWS Observability at re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**Ferramentas relacionadas:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade
Arquitete o produto para cumprir as metas de disponibilidade e os acordos de nível de serviço (SLAs) de tempo de atividade. Se você publicar ou concordar de forma privada com as metas de disponibilidade ou SLAs de tempo de atividade, verifique se sua arquitetura e seus processos operacionais foram projetados para comportá-los.
**Resultado desejado:** cada aplicação tem uma meta definida com relação à disponibilidade e SLA para métricas de desempenho, o que pode ser monitorado e mantido para cumprir os resultados empresariais.
**Antipadrões comuns:**
+ Planejar e implantar workloads sem definir SLAs.
+ As métricas de SLA são definidas como altas sem justificativa ou requisitos empresariais.
+ Definir SLAs sem considerar as dependências e o SLA subjacente.
+ Os designs da aplicação são criados sem considerar o modelo de responsabilidade compartilhada para resiliência.
**Benefícios do estabelecimento dessa prática recomendada:** projetar aplicações com base nas principais metas de resiliência ajuda a cumprir os objetivos empresariais e atender às expectativas dos clientes. Esses objetivos ajudam a orientar o processo de design da aplicação que avalia diferentes tecnologias e considera as vantagens e desvantagens.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientação de implementação
Os designs da aplicação precisam levar em conta um conjunto de requisitos diversos que são derivados dos objetivos empresariais, operacionais e financeiros. Nos requisitos operacionais, as workloads precisam ter metas de métricas de resiliência específicas para que possam ser monitorados e comportados adequadamente. As métricas de resiliência não devem ser definidas nem derivadas depois de implantar a workload. Elas devem ser definidas durante a fase de design e ajudar a orientar as diversas decisões e concessões.
+ Cada workload deve ter seu próprio conjunto de métricas de resiliência. Essas métricas podem ser diferentes de outras aplicações empresariais.
+ Reduzir as dependências pode ter um impacto positivo na disponibilidade. Cada workload deve considerar suas dependências e seus SLAs. Em geral, escolha dependências com metas de disponibilidade iguais ou maiores que as metas da workload.
+ Considere designs com acoplamento fraco para que a workload possa operar corretamente apesar do comprometimento da dependência, quando possível.
+ Reduza as dependências do ambiente de gerenciamento, especialmente durante uma recuperação ou degradação. Avalie os designs estaticamente estáveis com relação às workloads essenciais à missão. Use a economia de recursos para aumentar a disponibilidade dessas dependências em uma workload.
+ A capacidade de observação e a instrumentalização são críticas para cumprir os SLAs reduzindo o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR).
+ Falha menos frequente (MTBF mais longo), tempo de detecção de falhas mais curto (MTTD mais curto) e tempo de reparo mais curto (MTTR mais curto) são os três fatores usados para melhorar a disponibilidade em sistemas distribuídos.
+ Estabelecer e cumprir métricas de resiliência para uma workload é fundamental para qualquer design eficaz. Esses designs devem levar em consideração as vantagens e desvantagens da complexidade de design, as dependências do serviço, o desempenho, a escalabilidade e os custos.
**Etapas da implementação**
+ Analise e documente o design da workload considerando as seguintes questões:
+ Onde são usados ambientes de gerenciamento na workload?
+ Como a workload implementa tolerância a falhas?
+ Quais são os padrões de design para componentes de escalabilidade, escalabilidade automática, redundância e alta disponibilidade?
+ Quais são os requisitos para disponibilidade e consistência de dados?
+ Há considerações quanto à economia de recursos ou estabilidade estática de recursos?
+ Quais são as dependências do serviço?
+ Defina métricas de SLA com base na arquitetura da workload enquanto trabalha com as partes interessadas. Considere os SLAs de todas as dependências usadas pela workload.
+ Quando a meta de SLA for definida, otimize a arquitetura para cumprir o SLA.
+ Quando for definido o design que cumprirá o SLA, implemente mudanças operacionais, automação do processo e runbooks que também terão como foco uma redução de MTTD e MTTR.
+ Depois da implantação, monitore e informe sobre o SLA.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 Testar a resiliência por meio da engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.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)
+ [ Compreensão de integridade da workload ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Documentos relacionados:**
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html) (Disponibilidade com redundância)
+ [ Pilar Confiabilidade: disponibilidade ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Measuring availability ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)(Medição da disponibilidade)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) (Limites de isolamento de falhas da AWS)
+ [ Modelo de responsabilidade compartilhada para resiliência ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS Service Level Agreements (SLAs) ](https://aws.amazon.com/legal/service-level-agreements/)(Acordos de Nível de Serviço (SLAs) da AWS)
+ [ Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)(Orientações para arquitetura baseada em células com a AWS)
+ [ Infraestrutura da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Advanced Multi-AZ Resiliance Patterns whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)(Whitepaper de padrões de resiliência Multi-AZ avançados)
**Serviços relacionados:**
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
# CONFIABILIDADE 12. Como testar a confiabilidade?
Depois de projetar a workload 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.
**Resultado desejado:** suas equipes têm uma abordagem consistente e acordada para lidar com a análise pós-incidente. Um mecanismo é o [processo de correção de erros (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). O processo de COE ajuda as equipes a identificar, compreender e abordar as causas básicas dos incidentes, ao mesmo tempo em que cria mecanismos e barreiras de proteção para limitar a probabilidade do mesmo incidente ocorrer novamente.
**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.
+ Concentrar-se em atribuir a culpa em vez de compreender a causa raiz, criando uma cultura de medo e impedindo a comunicação aberta.
+ Não compartilhar insights, o que mantém as descobertas da análise de incidentes em um pequeno grupo e impede que outras pessoas se beneficiem das lições aprendidas.
+ Não ter um mecanismo para capturar conhecimento institucional e, dessa forma, perder insights valiosos por não preservar as lições aprendidas na forma de práticas recomendadas atualizadas e resultando em incidentes repetidos com a mesma causa raiz ou similar.
**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 workloads atenuem o risco caso tenham implementado os mesmos fatores contribuintes, além de possibilitar que elas implementem a mitigação ou a recuperação automatizada antes que ocorra um incidente.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto
## Orientações para a implementação
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.
A base do processo da COE é documentar e resolver problemas. É recomendável definir uma forma padronizada de documentar as causas raízes essenciais e garantir que elas sejam analisadas e abordadas. Atribua uma propriedade clara ao processo de análise pós-incidente. Designe uma equipe ou uma pessoa responsável para supervisionar as investigações e o acompanhamento de incidentes.
Incentive uma cultura que se concentre no aprendizado e na melhoria, em vez de na atribuição de culpas. Enfatize que a meta é evitar futuros incidentes, não penalizar pessoas.
Desenvolva procedimentos bem definidos para conduzir análises pós-incidentes. Esses procedimentos devem descrever as etapas a serem seguidas, as informações a serem coletadas e as principais questões a serem abordadas durante a análise. Investigue os incidentes minuciosamente, indo além das causas imediatas para identificar as causas raízes e os fatores contribuintes. Use técnicas, como os *[cinco porquês](https://en.wikipedia.org/wiki/Five_whys)*, para se aprofundar nos problemas subjacentes.
Mantenha um repositório das lições aprendidas com as análises dos incidentes. Esse conhecimento institucional pode servir como referência para futuros incidentes e iniciativas de prevenção. Compartilhe descobertas e insights de análises pós-incidentes e considere realizar reuniões abertas sobre a revisão pós-incidente para discutir as lições aprendidas.
### Etapas da implementação
+ Ao conduzir a análise pós-incidente, verifique se o processo está livre de culpabilização. Isso permite que as pessoas envolvidas no incidente sejam imparciais com as ações corretivas propostas e promovam uma autoavaliação honesta e a colaboração entre as equipes.
+ Defina uma forma padronizada de documentar problemas essenciais. Um exemplo de estrutura para esse documento é o seguinte:
+ O que aconteceu?
+ Qual foi o impacto nos clientes e em sua empresa?
+ Qual foi a causa raiz?
+ Quais dados você tem para apoiar isso?
+ Por exemplo, métricas e grafos
+ Quais foram as implicações críticas nos pilares, especialmente em relação à segurança?
+ Ao arquitetar workloads, você faz concessões entre os pilares com base no contexto da sua empresa. Essas decisões de negócios podem definir suas prioridades de engenharia. Você pode reduzir custos e assim diminuir a confiabilidade em ambientes de desenvolvimento, ou otimizar a confiabilidade e aumentar os custos para soluções importantes. A segurança é sempre prioritária, porque você precisa proteger seus clientes.
+ Quais lições você aprendeu?
+ Quais ações corretivas você está tomando?
+ Itens de ação
+ Itens relacionados
+ Crie procedimentos operacionais padrão bem definidos para conduzir análises pós-incidentes.
+ Configure um processo padronizado de relatórios de incidentes. Documente todos os incidentes de forma abrangente, incluindo o relatório inicial do incidente, logs, comunicações e ações tomadas durante o incidente.
+ Lembre-se de que um incidente não exige uma interrupção. Pode ser uma quase falha ou um sistema que, embora esteja funcionando de forma inesperada, cumpre sua função de negócios.
+ Melhore continuamente o processo de análise pós-incidente com base no feedback e nas lições aprendidas.
+ Capture as principais descobertas em um sistema de gerenciamento de conhecimento e considere os padrões que devem ser adicionados aos guias de desenvolvedor ou às listas de verificação de pré-implantação.
## Recursos
**Documentos relacionados:**
+ [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**Vídeos relacionados:**
+ [ Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# 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/2023-10-03/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/2023-10-03/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 da 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/)
# CONFIABILIDADE 13. Como planejar 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 a restauração da 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 cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação da 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/2023-10-03/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 cumprir os 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/2023-10-03/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 cumprir os objetivos de recuperação](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Testar a implementação da 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 cumprir os objetivos de recuperação
Defina uma estratégia de recuperação de desastres (DR) que cumpra os objetivos de recuperação da workload. Escolha uma estratégia como backup e restauração, standby (ativo/passivo) ou ativo/ativo.
**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 ter um plano para a recuperação de desastres.
+ Depender das operações do ambiente de gerenciamento durante a recuperação.
**Benefícios do estabelecimento desta prática recomendada:**
+ O uso de estratégias de recuperação definidas permite que você adote ferramentas comuns e procedimentos de teste.
+ Usar estratégias de recuperação definidas melhora o compartilhamento de conhecimento entre as equipes e a implementação da DR nas workloads que possuem.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto. Sem uma estratégia de DR planejada, implementada e testada, é improvável que você cumpra os objetivos de recuperação em caso de desastre.
## Orientação de implementação
Uma estratégia de DR depende da capacidade de manter a workload em um site de recuperação se o 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 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 estratégias a seguir. 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/2023-10-03/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é cinco 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 permitir a replicação e o 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.
+ **Standby 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 standby 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*.
+ **Ativo/ativo de várias regiões (multissite)** (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. Essa estratégia exige que você sincronize os dados entre regiões. Deve-se evitar ou lidar com 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 standby 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 standby 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 standby 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.
Quando o custo é uma preocupação e você deseja alcançar objetivos de RPO e RTO semelhantes, conforme definido na estratégia de standby passivo, é possível considerar soluções nativas da nuvem, como AWS Elastic Disaster Recovery, que adota a abordagem de luz piloto e oferece metas de RPO e RTO aprimoradas.
**Etapas da implementação**
1. **Determine uma estratégia de DR que satisfaça os requisitos de recuperação para essa workload.**
Escolher uma estratégia de DR é uma troca entre reduzir o tempo de inatividade e a perda de dados (RTO e RPO) e 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 o RTO máximo permitido e o orçamento limite da estratégia de restauração de serviço. Considerando os objetivos empresariais, as estratégias de DR luz-piloto e standby 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/2023-10-03/framework/images/choosing-a-dr-strategy.png)
Para saber mais, consulte [Business Continuity Plan (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html) (Plano de continuidade de negócios (BCP).
1. **Revise os padrões de como a estratégia de DR selecionada pode ser implementada.**
Essa 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 a seguir, é possível aplicar a estratégia para 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 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/2023-10-03/framework/images/backup-restore-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/) (Arquitetura de recuperação de desastres (DR) na AWS, parte II: backup e restauração com recuperação rápida).
**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 principais recursos usados para a infraestrutura da workload são implantados na região de recuperação. No entanto, recursos adicionais e as dependências ainda são necessários para tornar a 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/2023-10-03/framework/images/pilot-light-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz-piloto e standby passivo).
**Modo de espera passivo**
A abordagem de *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. Se a região de recuperação estiver implantada com sua capacidade total, isso é conhecido como *standby a quente*.
![\[Diagrama mostrando a Figura 21: uma arquitetura de standby passivo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/warm-standby-architecture.png)
O uso de standby passivo ou luz-piloto requer que a escala dos recursos seja aumentada verticalmente na região de recuperação. Para verificar se a capacidade está 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 você usar o AWS Lambda, a [simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) poderá fornecer ambientes de execução para que eles sejam preparados para responder imediatamente às invocações da função.
Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz-piloto e standby passivo).
**Multissite ativo/ativo**
É possível executar a 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 essa estratégia por outros motivos, além da DR. Ela pode ser usada para aumentar a disponibilidade ou ao implantar uma workload para um público global (a fim de 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 for compatível com uma das Regiões da AWS onde está implantada, essa 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 empresariais exigirem.
![\[Diagrama mostrando uma arquitetura de multissite ativo-ativo\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)
Para obter mais detalhes sobre essa estratégia, consulte [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) (Arquitetura de recuperação de desastres (DR) na AWS, parte IV: multissite ativo/ativo).
**AWS Elastic Disaster Recovery**
Se você estiver considerando a estratégia de luz-piloto ou de standby passivo para a recuperação de desastres, o AWS Elastic Disaster Recovery poderia fornecer uma abordagem alternativa com benefícios melhorados. O Elastic Disaster Recovery pode oferecer uma meta de RPO e RTO semelhante à do standby passivo, mas mantém a abordagem de baixo custo da luz-piloto. O Elastic Disaster Recovery replica os dados da região primária para a região de recuperação, usando a proteção contínua de dados para alcançar um RPO medido em segundos e um RTO que pode ser medido em minutos. Somente os recursos necessários para replicar os dados são implantados na região de recuperação, o que mantém os custos baixos, semelhante à estratégia de luz-piloto. Ao usar o Elastic Disaster Recovery, o serviço coordena e orquestra a recuperação de recursos de computação quando iniciado como parte de um failover ou de uma simulação.
![\[Diagrama da arquitetura descrevendo como o AWS Elastic Disaster Recovery opera.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/drs-architecture.png)
**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, a 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. Essa arquitetura usa 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 o [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) tem recursos implantados em várias AZs, processando solicitações ativamente. A arquitetura também demonstra o standby a quente, no qual, caso a instância primária do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) falhe (ou a própria AZ falhe), a instância de standby será promovida a primária.
![\[Diagrama mostrando a Figura 24: Arquitetura Multi-AZ\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/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 abordagem alternativa menos comum para uma única região, a DR Multi-AZ está ilustrada nesta publicação de blog, [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack](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/) (Criar aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única). 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.
**nota**
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 empresariais. 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 recursos de infraestrutura e 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 de luz-piloto e standby passivo, a infraestrutura implantada exigirá ações adicionais para ficar pronta para produção. Usando [parâmetros](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [lógica condicional](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) do CloudFormation, é possível controlar se uma pilha implantada está ativa ou em espera com [um único modelo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Ao usar o Elastic Disaster Recovery, o serviço vai replicar e orquestrar a restauração de configurações da aplicação e os recursos de computação.
Todas as estratégias de DR exigem que seja feito backup das fontes de dados na Região da AWS e, então, esses backups são copiados para a região de recuperação. O [AWS Backup](https://aws.amazon.com/backup/) fornece uma visão centralizada em que é possível configurar, programar e monitorar backups para esses recursos. Para luz-piloto, standby 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 regiões, consulte essa série de blog em [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) (Criar uma aplicação de várias regiões com os serviços da AWS).
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 de luz-piloto e standby 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 da [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), de sub-redes e dos grupos de segurança necessários. É possível automatizar grande parte do processo de restauração. Para saber como, consulte [esta 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 de forma manual ou automática. 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, geralmente é usado o failover iniciado manualmente. 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 Regiões 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 um failover iniciado manualmente, é possível usar o [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), o que fornece uma API de plano de dados altamente disponível para rotear novamente 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 essa e outras opções, consulte [esta seção do whitepaper de 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 será feito failback da workload.**
Failback é quando você retorna a operação de workload para a região primária, após o término 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 você usar [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 você 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/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), a topologia da replicação existente do banco de dados global do Aurora será 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 nos quais isso não seja 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 outras réplicas. Por exemplo, para obter instruções de como fazer isso com o banco de dados global do Amazon Aurora presumindo um failover *não planejado*, consulte este laboratório: [Fail Back a Global Database](https://awsauroralabsmy.com/global/failback/) (Executar failback em um banco de dados global).
Após um failover, se você puder continuar a execução 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 alternância programada, trocando as 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 manual disponível para todos os membros da equipe e que seja revisado periodicamente.
Ao usar o Elastic Disaster Recovery, o serviço auxiliará na orquestração e automatização do processo de failback. Para obter mais detalhes, consulte [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html) (Como executar failback).
**Nível de esforço do 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: conceitos básicos – 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: padrões de arquitetura para aplicações ativas/ativas de várias regiões (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Conceitos básicos do AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Exemplos relacionados:**
+ [Well-Architected Lab - Disaster Recovery](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Series of workshops illustrating DR strategies (Laboratório do Well-Architected – Recuperação de desastres: série de workshops ilustrando estratégias de DR)
# REL13-BP03 Testar a implementação da recuperação de desastres para validá-la
Teste regularmente o failover no site de recuperação para verificar se a operação está correta e que o RTO e o RPO sejam cumpridos.
**Antipadrões comuns:**
+ Nunca execute failovers na produção.
**Benefícios do estabelecimento dessa prática recomendada:** testar regularmente seu plano de recuperação de desastres garante 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 é estabelecida:** alto
## Orientações para a implementação
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 nesse 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.
**Etapas da implementação**
1. Projete suas cargas de trabalho para recuperação. Teste regularmente seus caminhos de recuperação. A computação orientada para a recuperação identifica as características em sistemas que aprimoram a recuperaçã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 capacidade de reinicialização. Pratique o caminho da recuperação para verificar se é possível 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.
1. Para workloads com base no Amazon EC2, use o [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) para implementar e iniciar instâncias de simulação para a estratégia de DR. O AWS Elastic Disaster Recovery permite executar simulações com eficiência, o que ajuda você a se preparar para um evento de failover. Também é possível iniciar frequentemente as instâncias usando o Elastic Disaster Recovery para fins de teste e simulação sem redirecionar o tráfego.
## 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 Elastic Disaster Recovery](https://aws.amazon.com/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)
+ [AWS Elastic Disaster Recovery Preparing for Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html) (AWS Elastic Disaster Recovery: preparação para failover)
+ [O projeto de computação orientado por recuperação de Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [What is AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) (O que e o AWS Fault Injection Simulator?)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4) (AWS re:Invent 2018: padrões de arquitetura para aplicações ativas/ativas de várias regiões)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8) (AWS re:Invent 2019: soluções de backup e restauração e de recuperação de desastres com a AWS)
**Exemplos relacionados:**
+ [Well-Architected Lab - Testing for Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) (Laboratório do Well-Architected: teste de resiliência)
# 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)