As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Padrões de resiliência Multi-AZ avançados
Data de publicação: **11 de julho de 2023** ([Revisões do documento](document-revisions.md))
Muitos clientes executam seus workloads em configurações de zona de multidisponibilidade (AZ) altamente disponíveis. Essas arquiteturas funcionam bem durante eventos de falha binária, mas geralmente encontram problemas com falhas *cinzentas*. As manifestações desse tipo de falha podem ser sutis e desafiam a detecção rápida e definitiva. Este documento fornece orientação sobre como instrumentar workloads para detectar o impacto de falhas cinzentas isoladas em uma única zona de disponibilidade e, em seguida, tomar medidas para mitigar o impacto na zona de disponibilidade.
## Introdução
O objetivo deste documento é ajudá-lo a implementar com mais eficiência arquiteturas Multi-AZ resilientes. Uma das melhores práticas para criar sistemas resilientes nas redes da [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) (VPC) é [implantar cada workload](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) em várias zonas de disponibilidade.
Uma [zona de disponibilidade](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) é um ou mais datacenters discretos com energia, redes e conectividade redundantes. O uso de várias zonas de disponibilidade permite operar workloads com alta disponibilidade, tolerância a falhas e escalabilidade superiores ao que seria possível com um só datacenter.
Muitos serviços de AWS, como o [Amazon Elastic Compute Cloud (EC2), o Amazon Elastic Compute Cloud (EC2) Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) ou o [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS), fornecem uma configuração multi-AZ. Esses serviços não exigem a criação de nenhuma ferramenta adicional de observabilidade ou failover. Eles tornam os workloads resilientes a modos de falha binária facilmente detectáveis em uma [Região da AWS](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), que afetam uma única zona de disponibilidade. Pode ser uma falha física completa do hardware, perda de energia ou um bug latente de software que afeta a maioria dos recursos.
Mas há outra categoria de falhas denominada *falhas cinzentas*, cujas manifestações são sutis e desafiam a detecção rápida e definitiva. Isso, por sua vez, resulta em tempos mais longos para mitigar o impacto causado pela falha. Este documento se concentra nos impactos que as falhas cinzentas podem gerar nas arquiteturas multi-AZ, como detectá-las e, por fim, como mitigá-las.
****
A orientação fornecida neste whitepaper aplica-se principalmente a classes específicas de cargas de trabalho que:
Usam principalmente serviços de zona de AWS
Precisam melhorar a resiliência de uma única região
Estão dispostas a fazer um investimento significativo para criar os padrões de observabilidade e resiliência necessários
Nesses workloads, talvez você não esteja disposto a fazer algumas ou todas as compensações apresentadas em [Como responder a falhas cinzentas](gray-failures.md#responding-to-gray-failures), ou não tenha a opção de usar várias regiões. É provável que esses tipos de workload representem um pequeno subconjunto de seu portfólio geral e, portanto, essa orientação deve ser considerada no nível do workload versus no nível da plataforma.