# Use o isolamento de falhas para proteger a workload
O isolamento de falhas limita o impacto de uma falha de componente ou do sistema a um limite definido. Com o isolamento adequado, os componentes fora do limite não são afetados pela falha. Executar a workload em vários limites de isolamento de falhas pode torná-la mais resistente a falhas.
**Topics**
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Automatizar a recuperação de componentes restritos a um único local](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Usar arquiteturas de anteparo para limitar o escopo de impactos](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, quando necessário, por Regiões da AWS.
Um princípio fundamental do design de serviço na AWS é evitar pontos únicos de falha, incluindo a infraestrutura física subjacente. A AWS fornece recursos e serviços de computação em nuvem globalmente em várias localizações geográficas chamadas [regiões](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Cada região é física e logicamente independente e consiste em três ou mais [zonas de disponibilidade (AZs)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html). As zonas de disponibilidade ficam geograficamente próximas umas das outras, mas estão fisicamente separadas e isoladas. Ao distribuir as workloads entre zonas de disponibilidade e regiões, você reduz o risco de ameaças, como incêndios, inundações, desastres relacionados ao clima, terremotos e erro humano.
Crie uma estratégia de localização para fornecer alta disponibilidade adequada às workloads.
**Resultado desejado:** as workloads de produção são distribuídas entre várias zonas de disponibilidade (AZs) ou regiões para oferecer tolerância a falhas e alta disponibilidade.
**Práticas comuns que devem ser evitadas:**
+ A workload de produção existe somente em uma única zona de disponibilidade.
+ Implantar uma arquitetura multirregional quando uma arquitetura multi-AZ é suficiente para satisfazer os requisitos de negócios.
+ As implantações ou os dados ficam dessincronizados, o que resulta em desvio na configuração ou em dados sub-replicados.
+ Não contabilizar as dependências entre os componentes da aplicação se os requisitos de resiliência e de vários locais são diferentes entre esses componentes.
**Benefícios de implementar essa prática recomendada:**
+ A workload é mais resistente a incidentes, como falhas de energia ou de controle ambiental, desastres naturais, falhas no serviço upstream ou problemas de rede que afetam uma AZ ou uma região inteira.
+ Você pode acessar um inventário mais amplo de instâncias do Amazon EC2 e reduzir a probabilidade de InsufficientCapacityExceptions (ICE) ao iniciar tipos específicos de instância do EC2.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Implemente e opere todas as workloads de produção em pelo menos duas zonas de disponibilidade (AZs) em uma região.
**Usar várias zonas de disponibilidade**
As zonas de disponibilidade são locais de hospedagem de recursos fisicamente separados uns dos outros para evitar falhas correlacionadas devido a riscos como incêndios, inundações e tornados. Cada zona de disponibilidade tem uma infraestrutura física independente, incluindo conexões de energia elétrica, fontes de energia de backup, serviços mecânicos e conectividade de rede. Esse arranjo limita as falhas em qualquer um desses componentes apenas à zona de disponibilidade afetada. Por exemplo, se um incidente em toda a AZ tornar as instâncias do EC2 indisponíveis na zona de disponibilidade afetada, suas instâncias em outra zona de disponibilidade permanecerão disponíveis.
Apesar de serem separadas fisicamente, as zonas de disponibilidade na mesma Região da AWS são próximas o suficiente para fornecer redes de alto throughput e baixa latência (milissegundo de um dígito). Você pode replicar dados de forma síncrona entre as zonas de disponibilidade para a maioria das workloads sem afetar significativamente a experiência do usuário. Assim, você pode usar as zonas de disponibilidade de uma região em uma configuração ativa/ativa ou ativa/em espera.
Toda a computação associada à workload deve ser distribuída entre várias zonas de disponibilidade. Isso inclui instâncias do [Amazon EC2](https://aws.amazon.com/ec2/), tarefas do [AWS Fargate](https://aws.amazon.com/fargate/) e funções do [AWS Lambda](https://aws.amazon.com/lambda/) anexadas à VPC. Os serviços de computação da AWS, incluindo [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) e [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), fornecem maneiras de você iniciar e gerenciar a computação em todas as zonas de disponibilidade. Configure-os para substituir automaticamente a computação conforme necessário em uma zona de disponibilidade diferente para manter a disponibilidade. Para direcionar o tráfego para as zonas de disponibilidade disponíveis, coloque um balanceador de carga na frente da computação, como um Application Load Balancer ou Network Load Balancer. Os balanceadores de carga da AWS podem redirecionar o tráfego para instâncias disponíveis em caso de falha na zona de disponibilidade.
Você também deve replicar dados para a workload e disponibilizá-los em várias zonas de disponibilidade. Alguns serviços de dados gerenciados pela AWS, como o [Amazon S3](https://aws.amazon.com/s3/), o [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), o [Amazon Aurora](https://aws.amazon.com/aurora/), o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), o [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) e o [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), replicam dados em várias zonas de disponibilidade por padrão e são robustos contra o comprometimento da zona de disponibilidade. Com outros serviços de dados gerenciados pela AWS, como [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) e [Amazon ElastiCache](https://aws.amazon.com/elasticache/), você deve habilitar a replicação multi-AZ. Depois de habilitados, esses serviços detectam automaticamente uma deficiência na zona de disponibilidade, redirecionam as solicitações para uma zona de disponibilidade disponível e replicam novamente os dados conforme necessário após a recuperação, sem a intervenção do cliente. Familiarize-se com o guia do usuário de cada serviço de dados gerenciado pela AWS que você usa para entender os recursos, os comportamentos e as operações multi-AZ deles.
Se você estiver usando armazenamento autogerenciado, como volumes do [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) ou armazenamento de instâncias do Amazon EC2, deverá gerenciar a replicação multi-AZ por conta própria.
![\[Diagrama que mostra uma 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/latest/reliability-pillar/images/multi-tier-architecture.png)
**Usar várias Regiões da AWS**
Se você tem workloads que exigem extrema resiliência (como infraestrutura crítica, aplicações relacionadas à saúde ou serviços com rigorosos requisitos de clientes ou de disponibilidade obrigatória), pode precisar de disponibilidade adicional além do que uma única Região da AWS pode oferecer. Nesse caso, você deve implantar e operar a workload em pelo menos duas Regiões da AWS (supondo que os requisitos de residência de dados permitam isso).
As Regiões da AWS estão localizadas em diferentes regiões geográficas ao redor do mundo e em vários continentes. As Regiões da AWS têm separação física e isolamento ainda maiores do que as zonas de disponibilidade sozinhas. Os serviços da AWS, com poucas exceções, aproveitam esse design para operar de forma totalmente independente entre diferentes regiões (também conhecidos como *serviços regionais*). Uma falha em um serviço que opera por Região da AWS não deve afetar o serviço em uma região diferente.
Ao operar a workload em várias regiões, você deve considerar requisitos adicionais. Como os recursos em diferentes regiões são separados e independentes uns dos outros, você deve duplicar os componentes da workload em cada região. Isso inclui infraestrutura básica, como VPCs, além de serviços de computação e dados.
**OBSERVAÇÃO:** ao considerar um design multirregional, verifique se a workload é capaz de ser executada em uma única região. Se você criar dependências entre regiões, em que um componente em uma região depende de serviços ou componentes de outra região, poderá aumentar o risco de falha e enfraquecer significativamente sua postura de confiabilidade.
Para facilitar as implantações multirregionais e manter a consistência, o [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) pode replicar toda a sua infraestrutura da AWS em várias regiões. O [AWS CloudFormation](https://aws.amazon.com/cloudformation/) também pode detectar desvios na configuração e informar você quando os recursos da AWS em uma região estiverem fora de sincronia. Muitos serviços da AWS oferecem replicação multirregional para ativos importantes de workload. Por exemplo, o [EC2 Image Builder](https://aws.amazon.com/image-builder/) pode publicar as imagens de máquina (AMIs) do EC2 após cada compilação em cada região que você usa. O [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) pode replicar as imagens de contêiner nas regiões selecionadas.
Você também deve replicar os dados em cada uma das regiões escolhidas. Muitos serviços de dados gerenciados pela AWS oferecem capacidade de replicação entre regiões, incluindo Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon ElastiCache e Amazon EFS. As tabelas [globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) aceitam gravações em qualquer região compatível e replicarão dados entre todas as outras regiões configuradas. Com outros serviços, você deve designar uma região primária para gravações, pois outras regiões contêm réplicas somente leitura. Para cada serviço de dados gerenciado pela AWS que a workload usa, consulte o guia do usuário e o guia do desenvolvedor para entender as capacidades e limitações multirregionais de cada um. Preste atenção especial para onde as gravações devem ser direcionadas, aos recursos e limitações transacionais, à forma como a replicação é executada e à forma de monitorar a sincronização entre regiões.
A AWS também fornece a capacidade de rotear o tráfego de solicitações para as implantações regionais com grande flexibilidade. Por exemplo, você pode configurar os registros DNS usando o [Amazon Route 53](https://aws.amazon.com/route53/) a fim de direcionar o tráfego para a região disponível mais próxima do usuário. Como alternativa, você pode configurar os registros DNS em uma configuração ativa/em espera, em que designa uma região como primária e retorna a uma réplica regional somente se a região primária não estiver íntegra. Você pode configurar as [verificações de integridade do Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) para detectar endpoints não íntegros e realizar failover automático, além de usar o [Controlador de Recuperação de Aplicações (ARC)](https://aws.amazon.com/application-recovery-controller/) para fornecer um controle de roteamento altamente disponível a fim de redirecionar manualmente o tráfego conforme necessário.
Mesmo que você opte por não operar em várias regiões para obter alta disponibilidade, considere várias regiões como parte da sua estratégia de recuperação de desastres (DR). Se possível, replique os componentes e os dados da infraestrutura da workload em uma configuração de *espera passiva* ou de *luz piloto* em uma região secundária. Nesse design, você replica a infraestrutura de linha de base da região primária, como VPCs, grupos do Auto Scaling, orquestradores de contêineres e outros componentes, mas configura os componentes de tamanho variável na região de espera (como o número de instâncias do EC2 e réplicas de banco de dados) para ter um tamanho minimamente operável. Você também organiza a replicação contínua de dados da região primária para a região de standby. Se ocorrer um incidente, você poderá aumentar a escala horizontalmente ou aumentar os recursos na região de standby e promovê-la para se tornar a região primária.
### Etapas de implementação
1. Trabalhe com partes interessadas empresariais e especialistas em residência de dados para determinar quais Regiões da AWS podem ser usadas para hospedar os recursos e os dados.
1. Trabalhe com partes interessadas de áreas comerciais e técnicas para avaliar a workload e determinar se as necessidades de resiliência podem ser atendidas por uma abordagem multi-AZ (Região da AWS única) ou se elas exigem uma abordagem multirregional (se várias regiões forem permitidas). O uso de várias regiões pode alcançar maior disponibilidade, mas pode envolver complexidade e custo adicionais. Considere os seguintes fatores em sua avaliação:
1. **Objetivos de negócios e requisitos do cliente**: quanto tempo de inatividade é permitido caso ocorra um incidente que afete a workload em uma zona de disponibilidade ou região? Avalie os objetivos de ponto de recuperação conforme discutido em [REL13-BP01 Definir objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).
1. **Requisitos de recuperação de desastres (DR)**: contra qual tipo de desastre potencial você quer se proteger? Considere a possibilidade de perda de dados ou indisponibilidade de longo prazo em diferentes escopos de impacto, de uma única zona de disponibilidade a uma região inteira. Se você replicar dados e recursos em todas as zonas de disponibilidade e uma única zona de disponibilidade apresentar uma falha contínua, você poderá recuperar o serviço em outra zona de disponibilidade. Se você replicar dados e recursos entre regiões, poderá recuperar o serviço em outra região.
1. Implemente seus recursos computacionais em várias zonas de disponibilidade.
1. Na VPC, crie várias sub-redes em diferentes zonas de disponibilidade. Configure cada uma para ser grande o suficiente para acomodar os recursos necessários e atender à workload, mesmo durante um incidente. Para conferir mais detalhes, consulte [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Se você estiver usando instâncias do Amazon EC2, use o [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) para gerenciar suas instâncias. Especifique as sub-redes que você escolheu na etapa anterior ao criar os grupos do Auto Scaling.
1. Se você estiver usando a computação do AWS Fargate para o [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) ou o [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), selecione as sub-redes escolhidas na primeira etapa ao criar um serviço do ECS, inicializar uma tarefa do ECS ou criar um [perfil do Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) para o EKS.
1. Se você estiver usando funções do AWS Lambda que precisam ser executadas na VPC, selecione as sub-redes escolhidas na primeira etapa ao criar a função do Lambda. Para qualquer função que não tenha uma configuração de VPC, o AWS Lambda gerencia a disponibilidade para você automaticamente.
1. Coloque diretores de tráfego, como balanceadores de carga, na frente dos recursos de computação. Se o balanceamento de carga entre zonas estiver habilitado, os [AWS Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) e [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) detectarão quando destinos, como instâncias e contêineres do EC2, estiverem inacessíveis devido ao comprometimento da zona de disponibilidade e redirecionarão o tráfego para destinos em zonas de disponibilidade íntegras. Se você desabilitar o balanceamento de carga entre zonas, use o Controlador de Recuperação de Aplicações (ARC) para fornecer a capacidade de mudança de zona. Se você estiver usando um balanceador de carga de terceiros ou tiver implementado seus próprios balanceadores de carga, configure-os com vários front-ends em diferentes zonas de disponibilidade.
1. Replique os dados da workload em várias zonas de disponibilidade.
1. Se você usa um serviço de dados gerenciado pela AWS, como Amazon RDS, Amazon ElastiCache ou Amazon FSx, estude os guias do usuário para entender os recursos de replicação e resiliência de dados deles. Habilite o failover e a replicação entre AZs, se necessário.
1. Se você usa serviços de armazenamento gerenciados pela AWS, como Amazon S3, Amazon EFS e Amazon FSx, evite usar configurações single-AZ ou One Zone para dados que exijam alta durabilidade. Use uma configuração multi-AZ para esses serviços. Consulte o guia do usuário do respectivo serviço para determinar se a replicação multi-AZ está habilitada por padrão ou se você deve habilitá-la.
1. Se você executar um banco de dados, uma fila ou outro serviço de armazenamento autogerenciado, providencie a replicação multi-AZ de acordo com as instruções ou práticas recomendadas da aplicação. Familiarize-se com os procedimentos de failover da aplicação.
1. Configure o serviço DNS para detectar deficiências na AZ e redirecionar o tráfego para uma zona de disponibilidade íntegra. O Amazon Route 53, quando usado em combinação com Elastic Load Balancers, pode fazer isso automaticamente. O Route 53 também pode ser configurado com registros de failover que usam verificações de integridade para responder a consultas somente com endereços IP íntegros. Para registros DNS usados para failover, especifique um valor curto de vida útil (TTL) (por exemplo, 60 segundos ou menos) para ajudar a evitar que o armazenamento em cache de registros impeça a recuperação (os registros de alias do Route 53 fornecem TTLs apropriados para você).
**Etapas adicionais ao usar várias Regiões da AWS**
1. Replique todo o sistema operacional (SO) e código de aplicação usados pela workload nas regiões selecionadas. Replique as imagens de máquina da Amazon (AMIs) usadas pelas instâncias do EC2, se necessário, usando soluções como o Amazon EC2 Image Builder. Replique imagens de contêineres armazenadas em registros usando soluções como a replicação entre regiões do Amazon ECR. Habilite a replicação regional para qualquer bucket do Amazon S3 usado para armazenar recursos de aplicações.
1. Implante os recursos de computação e os metadados de configuração (como parâmetros armazenados no AWS Systems Manager Parameter Store) em várias regiões. Use os mesmos procedimentos descritos nas etapas anteriores, mas replique a configuração para cada região em que você está usando a workload. Use soluções de infraestrutura como código, como o AWS CloudFormation, para reproduzir uniformemente as configurações entre as regiões. Se você estiver usando uma região secundária em uma configuração de luz piloto para recuperação de desastres, poderá reduzir o número de recursos de computação a um valor mínimo para reduzir os custos, com um aumento correspondente no tempo de recuperação.
1. Replique os dados da região primária para as regiões secundárias.
1. As tabelas globais do Amazon DynamoDB fornecem réplicas globais dos dados que podem receber gravações de qualquer região compatível. Com outros serviços de dados gerenciados pela AWS, como Amazon RDS, Amazon Aurora e Amazon ElastiCache, designe uma região primária (leitura/gravação) e regiões de réplica (somente leitura). Consulte os guias do usuário e do desenvolvedor dos respectivos serviços para obter detalhes sobre a replicação regional.
1. Se você estiver executando um banco de dados autogerenciado, providencie a replicação multirregional de acordo com as instruções ou as práticas recomendadas da aplicação. Familiarize-se com os procedimentos de failover da aplicação.
1. Se a workload usa o AWS EventBridge, talvez seja necessário encaminhar eventos selecionados da região primária para as regiões secundárias. Para fazer isso, especifique os barramentos de eventos nas regiões secundárias como metas para eventos correspondentes na região primária.
1. Considere se e em que medida você deseja usar chaves de criptografia idênticas em todas as regiões. Uma abordagem típica que equilibra segurança e facilidade de uso é usar chaves com escopo regional para dados e autenticação locais em uma região e usar chaves com escopo global para criptografia de dados que são replicadas entre diferentes regiões. O [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) oferece suporte a [chaves multirregionais](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) para distribuição segura e proteção das chaves compartilhadas entre regiões.
1. Considere o AWS Global Accelerator para melhorar a disponibilidade da aplicação direcionando o tráfego para regiões que contêm endpoints íntegros.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL02-BP03 Garantir contas de alocação de sub-rede IP para expansão e disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Definir objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Documentos relacionados:**
+ [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [White paper: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Resiliência no Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: exemplo: distribuir instâncias entre zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Como o EC2 Image Builder funciona](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Como o Amazon ECS posiciona tarefas em instâncias de contêineres (inclui o Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Resiliência no AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3: Visão geral sobre a replicação de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Replicação de imagem privada no Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Tabelas globais: replicação em várias regiões com o DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon ElastiCache for Redis OSS: Replication across Regiões da AWS using global datastores](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Resiliência no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Usar bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Guia do desenvolvedor do AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Chaves de multirregiões no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: configurar o failover de DNS](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Guia do desenvolvedor do Controlador de Recuperação de Aplicações (ARC) da Amazon](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Como enviar e receber eventos do Amazon EventBridge entre regiões da Regiões da AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Série de blogs Criar aplicações multirregiões com 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 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/)
+ [Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz piloto e standby passivo](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 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 data center on-premises, será necessário 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 for estabelecida:** Médio
## Orientação para implementação
Se a prática recomendada para implantar a workload 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 aplicações 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 porque 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. É possível 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),Regiões da AWS 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 .
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 data center on-premises, é possível usar o Recuperação de desastres do AWS Elastic para proteger as workloads na AWS. Se você já estiver hospedado na AWS, poderá usar o Elastic Disaster Recovery para proteger sua workload em uma zona ou região de disponibilidade alternativa. O Elastic Disaster Recovery usa a replicação contínua em nível de bloco para uma área temporária leve para fornecer recuperação rápida e confiável de aplicações on-premises e baseadas na nuvem.
**Etapas de implementação**
1. Implemente a autorrecuperação. Quando possível, use o ajuste de escala automático 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 autorrecuperaçã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 instâncias e workloads de contêiner que não têm requisitos de endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
+ 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 exigem um endereço do ID de instância única, endereço IP privado, endereço IP elástico e metadados de 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 [eventos de ciclo de vida da instância do Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ou [eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) para automatizar a autorrecuperação quando ajuste de escala automático ou a recuperação do EC2 não puderem ser usadas.
+ Use os eventos para invocar a automação que recuperará seu componente de acordo com a lógica do processo necessária.
+ Proteja workloads monitoradas que estão limitadas a um único local usando o [Recuperação de desastres do AWS Elastic](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)
+ [Recuperar a instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Ajuste de escala automático 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)
+ [Recuperação de desastres do AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 Usar arquiteturas de anteparo para limitar o escopo de impactos
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 é conhecida como 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 uma falha ocorrer, 90% das solicitações gerais não serão afetadas pela falha.
**Práticas comuns que devem ser evitadas:**
+ 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 de implementar esta prática recomendada:** com arquiteturas baseadas em células, muitos tipos comuns de falha são contidos na própria célula, o que permite o isolamento adicional das falhas. Esses limites de falha podem fornecer resiliência contra tipos de falha que, de outra forma, seriam difíceis de conter, como implantações de código malsucedidas ou solicitações corrompidas ou que invocam um modo de falha específico (também conhecido como *solicitações de pílulas venenosas*).
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Em uma embarcação, os anteparos 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. Os componentes fora do limite não são afetados pela falha. Ao usar vários limites isolados de falhas, é possível limitar o impacto na workload. 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. 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. 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 que mostra arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/cell-based-architecture.png)
**Etapas de 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**: consideração especial deve ser feita em relação à chave de partição.
+ Ela precisa se alinhar à granularidade do serviço, ou à maneira natural que a workload de um serviço pode ser subdividida em interações mínimas entre células. Os exemplos são `customer ID` ou `resource ID`.
+ 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 celular persistente**: os serviços upstream devem interagir somente com uma única célula durante o ciclo de vida de seus 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 se torna 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 as células e, portanto, não pode seguir a mesma estratégia de compartimentaçã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 traz o benefício adicional de facilitar a compreensão de seu comportamento esperado em todos os momentos, permitindo a realização de testes rigorosos. Conforme explicado por Colm MacCárthaigh em [Confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/), 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 se estender além dele.
+ O tamanho máximo deve ser identificado com a realização de testes completos até que os pontos de ruptura sejam atingidos e 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 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 multi-AZ ou multirregiões**: utilize várias camadas de resiliência para oferecer 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 multirregiões 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 multirregiões pode ser complexa e, geralmente, não é necessária para a maioria das workloads. Para obter mais detalhes, consulte [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md).
1. **Implantação de código**: uma estratégia de implantação de código em etapas deve ser preferida à implantação de alterações de código em todas as células ao mesmo tempo.
+ Isso ajuda 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 [Automatizar implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL07-BP04 Fazer o teste de carga da workload](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
**Documentos relacionados:**
+ [Confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS e a compartimentalização](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [Isolamento de workloads via fragmentação aleatória](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automatizar implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: Como a AWS minimiza o raio de ação das falhas (ARC338)](https://youtu.be/swQbA4zub20)
+ [Fragmentação aleatória: AWS re:Invent 2019: Introdução à Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021: Tudo falha, o tempo todo: projetando para resiliência](https://www.youtube.com/watch?v=wUzSeSfu1XA)