

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á.

# AWSinfraestrutura
<a name="aws-infrastructure"></a>

 Esta seção apresenta um resumo da infraestrutura AWS global e dos limites de isolamento de falhas que ela fornece. Além disso, esta seção fornecerá uma visão geral do conceito de planos de controle e planos de dados, que são distinções críticas na forma como AWS projeta seus serviços. Essas informações fornecem a linha de base para entender como os limites de isolamento de falhas e o plano de controle e o plano de dados de um serviço se aplicam aos tipos de AWS serviço que discutiremos na próxima seção. 

**Topics**
+ [Zonas de disponibilidade](availability-zones.md)
+ [Regiões](regions.md)
+ [AWSZonas Locais](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Pontos de presença](points-of-presence.md)
+ [Partições](partitions.md)
+ [Ambientes de gerenciamento e planos de dados](control-planes-and-data-planes.md)
+ [Estabilidade estática](static-stability.md)
+ [Resumo](summary.md)

# Zonas de disponibilidade
<a name="availability-zones"></a>

 AWSopera mais de 100 zonas de disponibilidade em várias regiões ao redor do mundo (os números atuais podem ser encontrados aqui: [Infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/)). Uma zona de disponibilidade é um ou mais data centers discretos com infraestrutura de energia, rede e conectividade independentes e redundantes em um. Região da AWS As zonas de disponibilidade em uma região estão significativamente distantes umas das outras, até 60 milhas (\$1 100 km) para evitar falhas correlacionadas, mas próximas o suficiente para usar a replicação síncrona com latência de milissegundos de um dígito. Eles foram projetados para não serem afetados simultaneamente por um cenário de destino compartilhado, como energia elétrica, interrupção da água, isolamento de fibras, terremotos, incêndios, tornados ou inundações. Pontos comuns de falha, como geradores e equipamentos de resfriamento, não são compartilhados entre as zonas de disponibilidade e são projetados para serem fornecidos por subestações de energia independentes. Quando AWS implanta atualizações em seus serviços, as implantações em zonas de disponibilidade na mesma região são separadas no tempo para evitar falhas correlacionadas. 

 Todas as zonas de disponibilidade em uma região são interconectadas com redes de alta largura de banda e baixa latência, por meio de fibra metropolitana dedicada e totalmente redundante. *Cada zona de disponibilidade em uma região se conecta à Internet por meio de dois centros de trânsito onde há AWS pares com vários [provedores de internet de nível 1](https://en.wikipedia.org/wiki/Tier_1_network) (para obter mais informações, consulte [Visão geral da Amazon Web](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card) Services).* 

 Esses recursos fornecem um forte isolamento das zonas de disponibilidade umas das outras, o que chamamos de Independência da Zona de Disponibilidade (AZI). A construção lógica das zonas de disponibilidade e sua conectividade com a Internet é mostrada na figura a seguir. 

![\[Esta imagem mostra como as zonas de disponibilidade consistem em um ou mais data centers físicos conectados de forma redundante entre si e à Internet\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)


# Regiões
<a name="regions"></a>

 Cada uma Região da AWS consiste em várias zonas de disponibilidade independentes e fisicamente separadas dentro de uma área geográfica. Atualmente, todas as regiões têm três ou mais zonas de disponibilidade. As próprias regiões são isoladas e independentes de outras regiões, com algumas exceções mencionadas posteriormente neste documento [(consulte Operações globais de uma única região](global-services.md#global-single-region-operations)). Essa separação entre regiões limita as falhas de serviço, quando elas ocorrem, a uma única região. As operações normais de outras regiões não são afetadas neste caso. Além disso, os recursos e dados que você cria em uma região não existem em nenhuma outra região, a menos que você use explicitamente um recurso de replicação ou cópia oferecido por um AWS serviço ou replique o recurso você mesmo. 

![\[Esta imagem ilustra as regiões atuais e planejadas da AWS em dezembro de 2022.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)


# AWSZonas Locais
<a name="aws-local-zones"></a>

 AWSAs [Zonas Locais](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) são um tipo de implantação de infraestrutura que coloca computação, armazenamento, banco de dados e outros [AWSserviços selecionados](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) próximos a grandes centros populacionais e industriais. Você pode usar AWS serviços, como serviços de computação e armazenamento, na Zona Local para executar aplicativos de baixa latência na borda ou simplificar as migrações para a nuvem híbrida. As Zonas Locais têm entrada e saída locais de Internet para reduzir a latência, mas também estão conectadas à sua região principal por meio da rede privada redundante e de alta largura de banda da Amazon, oferecendo aos aplicativos executados em Zonas AWS Locais acesso rápido, seguro e contínuo a toda a gama de serviços. 

# AWS Outposts
<a name="aws-outposts"></a>

 [AWS Outposts](https://aws.amazon.com/outposts/)é uma família de soluções totalmente gerenciadas que fornece AWS infraestrutura e serviços para praticamente qualquer local local ou local periférico para uma experiência híbrida verdadeiramente consistente. As soluções Outposts permitem que você estenda e execute AWS serviços nativos no local e estão disponíveis em vários formatos, de servidores Outposts de 1U e 2U a racks de 42U Outposts e várias implantações de racks. 

 ComAWS Outposts, você pode executar [AWSserviços selecionados](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services) localmente e se conectar a uma ampla variedade de serviços disponíveis na matrizRegião da AWS. AWS Outpostssão racks de computação e armazenamento totalmente gerenciados e configuráveis, construídos com hardware AWS projetado que permite que os clientes executem computação e armazenamento no local, enquanto se conectam perfeitamente à ampla variedade AWS de serviços na nuvem. 

# Pontos de presença
<a name="points-of-presence"></a>

 Além das zonas de disponibilidade Regiões da AWS e de disponibilidade, AWS também opera uma rede de ponto de presença (PoP) distribuída globalmente. Eles PoPs hospedam a Amazon CloudFront, uma rede de entrega de conteúdo (CDN); o Amazon Route 53, um serviço público de resolução de Sistema de Nomes de Domínio (DNS); e o AWS Global Accelerator (AGA), um serviço de otimização de rede de ponta. Atualmente, a rede de borda global consiste em mais de 410 PoPs, incluindo mais de 400 pontos de presença e 13 caches regionais de médio porte em mais de 90 cidades em 48 países (o status atual pode ser encontrado aqui: [Amazon CloudFront Key](https://aws.amazon.com/cloudfront/features/) Features). 

![\[Esta imagem mostra a rede de borda CloudFront global da Amazon\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)


 Cada PoP é isolado dos outros, o que significa que uma falha que afeta um único PoP ou área metropolitana não afeta o resto da rede global. A AWS rede é compatível com milhares de operadoras de telecomunicações de nível 1/2/3 em todo o mundo, está bem conectada a todas as principais redes de acesso para um desempenho ideal e tem centenas de terabits de capacidade implantada. As localizações periféricas são conectadas ao backbone Regiões da AWS através da AWS rede, uma fibra paralela múltipla de 100 GbE totalmente redundante que circunda o globo e se conecta a dezenas de milhares de redes para melhorar as buscas de origem e acelerar o conteúdo dinâmico. 

# Partições
<a name="partitions"></a>

 AWSagrupa regiões em [partições.](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) Cada região está em exatamente uma partição, e cada partição tem uma ou mais regiões. As partições têm instâncias independentes de AWS Identity and Access Management (IAM) e fornecem um limite rígido entre regiões em partições diferentes. AWSAs regiões comerciais estão na `aws` partição, as regiões na China estão na `aws-cn` partição e AWS GovCloud as regiões estão na `aws-us-gov` partição. Alguns AWS serviços são projetados para fornecer funcionalidade entre regiões, como a replicação entre regiões do [Amazon S3 ou o emparelhamento entre regiões](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) do [AWSTransit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html). Esses tipos de recursos só são compatíveis entre regiões na mesma partição. Você não pode usar as credenciais do IAM de uma partição para interagir com recursos em uma partição diferente. 

# Ambientes de gerenciamento e planos de dados
<a name="control-planes-and-data-planes"></a>

 AWSsepara a maioria dos serviços nos conceitos de plano de *controle e plano* *de dados*. Esses termos vêm do mundo das redes, especificamente dos roteadores. O plano de dados do roteador, que é sua principal funcionalidade, está movendo pacotes com base em regras. Mas as políticas de roteamento precisam ser criadas e distribuídas de algum lugar, e é aí que entra o plano de controle. 

 Os planos de controle fornecem as APIs administrativas usadas para criar, ler/descrever, atualizar, excluir e listar recursos (CRUDL). Por exemplo, todas as ações do plano de controle são: iniciar uma nova instância do [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), criar um bucket do [Amazon Simple Storage](https://aws.amazon.com/s3/) Service (Amazon S3) e descrever uma fila do Amazon [Simple Queue Service (Amazon](https://aws.amazon.com/sqs/) SQS). Quando você executa uma instância do EC2, o plano de controle precisa realizar várias tarefas, como encontrar um host físico com capacidade, alocar as interfaces de rede, preparar um volume do Amazon [Elastic Block Store (Amazon](https://aws.amazon.com/ebs/) EBS), gerar credenciais do IAM, adicionar as regras do Security Group e muito mais. Os planos de controle tendem a ser sistemas complicados de orquestração e agregação. 

 O plano de dados é o que fornece a função principal do serviço. Por exemplo, a seguir estão todas as partes do plano de dados para cada um dos serviços envolvidos: a própria instância do EC2 em execução, leitura e gravação em um volume do EBS, obtenção e colocação de objetos em um bucket do S3 e o Route 53 respondendo a consultas de DNS e realizando verificações de saúde. 

 Os planos de dados são intencionalmente menos complicados, com menos partes móveis em comparação com os planos de controle, que geralmente implementam um sistema complexo de fluxos de trabalho, lógica de negócios e bancos de dados. Isso torna os eventos de falha estatisticamente menos prováveis de ocorrerem no plano de dados em relação ao plano de controle. Embora os dados e o plano de controle contribuam para a operação geral e o sucesso do serviço, os AWS considera componentes distintos. Essa separação traz benefícios de desempenho e disponibilidade. 

# Estabilidade estática
<a name="static-stability"></a>

 Uma das características de resiliência mais importantes dos AWS serviços é o que AWS chama de estabilidade estática. O que esse termo significa é que os sistemas operam em um estado estático e continuam operando normalmente, sem a necessidade de fazer alterações durante a falha ou a indisponibilidade das dependências. Uma maneira de fazer isso é evitar dependências circulares em nossos serviços que possam impedir a recuperação bem-sucedida de um desses serviços. Outra forma de fazer isso é mantendo o estado existente. Consideramos o fato de que os planos de controle são estatisticamente mais propensos a falhar do que os planos de dados. Embora o plano de dados normalmente dependa dos dados que chegam do plano de controle, o plano de dados mantém seu estado existente e continua funcionando mesmo em face da deficiência do plano de controle. O acesso do plano de dados aos recursos, uma vez provisionado, não depende do plano de controle e, portanto, não é afetado por nenhuma deficiência no plano de controle. Em outras palavras, mesmo que a capacidade de criar, modificar ou excluir recursos seja prejudicada, os recursos existentes permanecerão disponíveis. Isso torna AWS os planos de dados estaticamente estáveis a uma deficiência no plano de controle. Você pode implementar padrões diferentes para ser estaticamente estável contra diferentes tipos de falhas de dependência. 

 Um exemplo de estabilidade estática pode ser encontrado no Amazon EC2. Depois que uma instância do EC2 é iniciada, ela fica tão disponível quanto o servidor físico em um data center. Ele não depende de nenhuma API do plano de controle para continuar em execução ou para começar a ser executado novamente após uma reinicialização. A mesma propriedade vale para outros AWS recursos, como VPCs, buckets e objetos do Amazon S3 e volumes do Amazon EBS. 

 A estabilidade estática é um conceito profundamente enraizado na forma como AWS projeta seus serviços, mas também é um padrão que pode ser usado pelos clientes. Na verdade, a maioria das diretrizes de melhores práticas para usar os diferentes tipos de AWS serviços de forma resiliente é implementar estabilidade estática em ambientes de produção. Os mecanismos de recuperação e mitigação mais confiáveis são aqueles que exigem menos mudanças para alcançar a recuperação. Em vez de depender do plano de controle do EC2 para iniciar novas instâncias do EC2 para se recuperar de uma zona de disponibilidade com falha, ter essa capacidade extra pré-provisionada ajuda a obter estabilidade estática. Assim, eliminar as dependências nos planos de controle (as APIs que implementam mudanças nos recursos) em seu caminho de recuperação ajuda a produzir cargas de trabalho mais resilientes. Para obter mais detalhes sobre estabilidade estática, planos de controle e planos de dados, consulte o artigo [Estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) da Amazon Builders' Library. 

# Resumo
<a name="summary"></a>

 AWSutiliza diferentes contêineres de falhas em nossa infraestrutura para criar isolamento de falhas. Os principais contêineres de falhas da infraestrutura são partições, regiões, zonas de disponibilidade, planos de controle e planos de dados. A seguir, examinaremos diferentes tipos de AWS serviços, como esses contêineres de falhas são utilizados em seu design e como você deve arquitetar cargas de trabalho com eles para serem resilientes. 