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á.
# Modos de falha maiores
Para projetar arquiteturas de HA para mitigar modos de falha maiores, como falhas de rack, datacenter, zona de disponibilidade (AZ) ou região, você deve implantar vários Outposts com capacidade de infraestrutura suficiente em datacenters separados com energia independente e conectividade WAN. Você ancora os Outposts em diferentes zonas de disponibilidade AZs () dentro de Região da AWS uma ou em várias regiões. Você também deve provisionar site-to-site conectividade resiliente e suficiente entre os locais para oferecer suporte à replicação de dados síncrona ou assíncrona e ao redirecionamento do tráfego da carga de trabalho. Dependendo da arquitetura do seu aplicativo, você pode usar o [Amazon Route 53](https://aws.amazon.com/route53/) DNS disponível globalmente e o [Amazon Route 53 on Outposts](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) para direcionar o tráfego para o local desejado e automatizar o redirecionamento de tráfego para locais sobreviventes no caso de falhas em grande escala.
# Outposts Rack: roteamento intra-VPC
AWS Outposts O rack suporta [comunicação intra-VPC em vários Outposts](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/). Os recursos em dois Outposts lógicos separados podem se comunicar entre si roteando o tráfego entre sub-redes dentro da mesma VPC, abrangendo todas elas usando os gateways locais do Outpost (LGW). Com a comunicação intra-VPC em vários Outposts, você pode substituir a Rota Local na tabela de rotas associada à sub-rede Outposts adicionando uma rota mais específica à outra sub-rede Outposts usando o LGW local como o próximo salto. [Ele pode oferecer vantagens para a arquitetura de aplicativos que exigem uma extensão de uma VPC entre dois Outposts lógicos, como o [Amazon ECS em dois racks Outposts ou](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks) o cluster Amazon EKS. AWS Outposts](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/)
![\[Diagrama mostrando caminhos de rede para uma única VPC com vários Outposts lógicos\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts o roteamento de tráfego pela região está bloqueado, pois esse é um antipadrão. Esse tráfego incorreria em cobranças de saída em ambas as direções e em uma latência significativamente maior do que o roteamento do tráfego pela WAN do cliente.
# Outposts Rack: roteamento entre VPCs
Recursos em dois Outposts separados implantados em diferentes VPCs podem se comunicar entre si na rede do cliente. A implantação dessa arquitetura permite que você roteie o tráfego Outposts-to-Outposts pelas redes locais e WAN locais, adicionando rotas para as sub-redes Outposts/VPC equivalentes.
![\[Diagrama mostrando caminhos de rede para várias VPC com vários Outposts lógicos\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
Práticas recomendadas para proteção contra modos de falha maiores:
+ Implante vários Outposts ancorados em várias regiões. AZs
+ Use separadamente VPCs para cada Posto Avançado em uma implantação de vários Postos Avançados.
# Resolvedor local do Route 53 em Outposts
Quando o link de AWS Outposts serviço é afetado por uma desconexão temporária, a resolução do DNS local falha, dificultando que aplicativos e serviços descubram outros serviços, mesmo quando estão sendo executados no mesmo rack do Outposts. No entanto, com o Route 53 Resolver ativado AWS Outposts, os aplicativos e serviços continuarão se beneficiando da resolução de DNS local para descobrir outros serviços, mesmo no caso de perda de conectividade com o pai Região da AWS. Ao mesmo tempo, para resolução de DNS para nomes de host locais, o Route 53 Resolver on Outposts ajuda a reduzir a latência, pois os resultados da consulta são armazenados em cache e veiculados localmente, além de ser totalmente integrado aos endpoints do Route 53 Resolver.
Os endpoints de entrada do resolvedor do Route 53 encaminham as consultas DNS que recebem de fora da VPC para o Resolver executado em Outposts. Por outro lado, o Route 53 Resolver Outbound permite que os Resolvedores do Route 53 encaminhem consultas de DNS para resolvedores de DNS que você gerencia em sua rede local, conforme ilustrado no diagrama a seguir.
![\[Diagrama mostrando o resolvedor Route 53 em Outposts\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Considerações sobre o Route 53 Resolver on Outposts
Considere o seguinte:
+ Você deve habilitar o Route 53 Resolver em Outposts, e ele se aplica a toda a implantação do Outposts, mesmo que isso envolva vários racks de computação sob um único ID do Outposts.
+ Para habilitar esse recurso, seus Outposts devem ter capacidade computacional suficiente para implantar o resolvedor local na forma de pelo menos 4 EC2 instâncias de qualquer c5.xlarge, m5.large ou m5.xlarge.
+ Se você estiver usando DNS privado, deverá compartilhar a Zona Hospedada Privada com os ' VPCsOutposts' necessários para armazenar em cache os registros localmente no Resolvedor do Route 53 em Outposts.
+ Para permitir a integração com o DNS local com endpoints de entrada e saída, seus Outposts devem ter capacidade computacional suficiente para implantar duas instâncias por endpoint do Route53. EC2
# Cluster local EKS em Outposts
Quando há desconexões do link de serviço do Outposts da região principal, pode haver desafios com serviços como o EKS Extended Cluster, onde o plano de controle reside na região. Entre os desafios está a perda de comunicação entre o plano de controle EKS e os nós do trabalhador PODs e. Embora os nós de trabalho PODs possam continuar operando e atendendo aplicativos que residem localmente nos Outposts, o plano de controle do Kubernetes pode considerá-los insalubres e agendar sua substituição quando a conexão com o plano de controle for recuperada. Isso pode levar a períodos de inatividade do aplicativo quando a conectividade for restaurada.
Para simplificar isso, existe a opção de hospedar todo o seu cluster EKS no Outposts. Nessa configuração, tanto o plano de controle do Kubernetes quanto seus nós de trabalho são executados localmente no local, na capacidade computacional do Outposts. Dessa forma, seu cluster continua operando mesmo no caso de uma queda temporária na conexão do link de serviço e depois que ela for restaurada.
![\[Cluster local Amazon EKS em Outposts\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Considerações sobre o EKS Local Cluster on Outposts
Há algumas considerações quando um cluster local EKS é implantado no Outposts:
+ Durante uma desconexão, não há opções para executar nenhuma alteração no próprio cluster que exija adicionar novos nós de trabalho ou escalar automaticamente um grupo de nós, desde que isso EC2 dependa das chamadas da API ASG para a AWS região principal.
+ • Há um conjunto de recursos não suportados em clusters locais listados no suporte ao [eksctl AWS Outposts](https://eksctl.io/usage/outposts/). .