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

Apêndice B - Orientação de serviço global da rede Edge

Para serviços globais de rede de ponta, você deve implementar a estabilidade estática para manter a resiliência de sua carga de trabalho durante uma interrupção do plano AWS de controle de serviço.

Route 53

O plano de controle do Route 53 consiste em todas as APIs públicas do Route 53 que abrangem a funcionalidade de zonas hospedadas, registros, verificações de integridade, registros de consultas de DNS, conjuntos de delegações reutilizáveis, políticas de tráfego e tags de alocação de custos. Ele é hospedado em us-east-1. O plano de dados é o serviço DNS autoritativo, que é executado em mais de 200 locais PoP, bem como em cada umRegião da AWS, respondendo a consultas de DNS com base nas suas zonas hospedadas e dados de verificação de integridade. Além disso, o Route 53 tem um plano de dados para verificações de saúde, que também é um serviço distribuído globalmente em vários. Regiões da AWS Esse plano de dados realiza verificações de integridade, agrega os resultados e os entrega aos planos de dados do DNS público e privado do Route 53 e do AGA. Durante uma falha no plano de controle, as operações do tipo CRUDL para a Rota 53 podem não funcionar, mas as verificações de resolução e integridade do DNS e as atualizações no roteamento resultantes de alterações nas verificações de saúde continuarão funcionando.

O que isso significa é que, ao planejar dependências no Route 53, você não deve confiar no plano de controle do Route 53 em seu caminho de recuperação. Por exemplo, um design estaticamente estável seria usar o status das verificações de saúde para realizar failovers entre regiões ou evacuar uma zona de disponibilidade. Você pode usar os controles de roteamento do Route 53 Application Recovery Controller (ARC) para alterar manualmente o status das verificações de integridade e alterar as respostas às consultas de DNS. Existem padrões semelhantes aos fornecidos pelo ARC que você pode implementar com base em seus requisitos. Alguns desses padrões são descritos em Criando mecanismos de recuperação de desastres usando o Route 53 e na seção de disjuntores de verificação de integridade de padrões avançados de resiliência Multi-AZ. Se você optou por usar um plano de DR multirregional, pré-provisione recursos que exigem a criação de registros DNS, como ELBs e instâncias de RDS. Um non-statically-stable projeto seria atualizar o valor de um registro de recurso do Route 53 por meio da ChangeResourceRecordSets API, alterar o peso de um registro ponderado ou criar novos registros para realizar o failover. Essas abordagens dependem do plano de controle da Rota 53.

Amazon CloudFront

O plano CloudFront de controle da Amazon consiste em todas as CloudFront APIs públicas para gerenciar distribuições e está hospedado em us-east-1. O plano de dados é a distribuição em si servida pela PoPs rede periférica. Ele executa o tratamento da solicitação, o roteamento e o armazenamento em cache do seu conteúdo de origem. Durante uma falha no plano de controle, as operações do tipo CRUDL para CloudFront (incluindo solicitações de invalidação) podem não funcionar, mas seu conteúdo continuará sendo armazenado em cache e servido, e os failovers de origem continuarão funcionando.

O que isso significa é que, ao planejar dependências doCloudFront, você não deve confiar no plano de CloudFront controle em seu caminho de recuperação. Por exemplo, um projeto estaticamente estável seria usar failovers de origem automatizados para mitigar o impacto de uma deficiência em uma de suas origens. Você também pode optar por criar balanceamento de carga de origem ou failover usando o Lamda @Edge. Consulte Três padrões de design avançados para aplicativos de alta disponibilidade usando a Amazon CloudFront e o Amazon S3 para criar aplicativos de geoproximidade ativos CloudFront e ativos em várias regiões para obter mais detalhes sobre esse padrão. Um non-statically-stable projeto seria atualizar manualmente a configuração de sua distribuição em resposta a uma falha de origem. Essa abordagem dependeria do plano CloudFront de controle.

AWS Certificate Manager

Se você estiver usando certificados personalizados com sua CloudFront distribuição, também dependerá do ACM. Usar certificados personalizados com sua CloudFront distribuição depende do ambiente de gerenciamento da ACM na região us-east-1. Durante uma falha no plano de controle, seus certificados existentes configurados em sua distribuição continuarão funcionando, assim como as renovações automáticas de certificados. Não confie em alterar a configuração da distribuição ou criar novos certificados como parte do seu caminho de recuperação.

AWSFirewall de aplicativos Web (WAF) e WAF Classic

Se você estiver usando AWS WAF com sua CloudFront distribuição, você depende do plano de controle WAF, que também está hospedado na região us-east-1. Durante uma falha no plano de controle, as listas de controle de acesso à web (ACLs) configuradas e suas regras associadas continuam funcionando. Não confie na atualização de suas ACLs web do WAF como parte de seu caminho de recuperação.

AWS Global Accelerator

O plano de controle AGA consiste em todas as APIs públicas da AGA e está hospedado em us-west-2. O plano de dados é o roteamento de rede dos endereços IP anycast fornecidos pela AGA para seus endpoints registrados. O AGA também utiliza verificações de saúde do Route 53 para determinar a integridade de seus endpoints AGA, que fazem parte do plano de dados do Route 53. Durante uma falha no plano de controle, as operações do tipo CRUDL para AGA podem não funcionar. O roteamento para seus endpoints existentes, bem como as verificações de integridade, marcadores de tráfego e configurações de peso de terminais existentes usadas para rotear ou transferir o tráfego para outros endpoints e grupos de endpoints, continuarão funcionando.

O que isso significa é que, ao planejar dependências do AGA, você não deve confiar no plano de controle do AGA em seu caminho de recuperação. Por exemplo, um design estaticamente estável seria usar o status das verificações de saúde configuradas para evitar falhas em endpoints não íntegros. Consulte Implantação de aplicativos multirregionais AWS usando o AWS Global Accelerator para obter exemplos dessa configuração. Um non-statically-stable projeto seria modificar as porcentagens de discagem de tráfego AGA, editar grupos de endpoints ou remover um endpoint de um grupo de endpoints durante uma deficiência. Essas abordagens dependeriam do plano de controle da AGA.

Amazon Shield Advanced

O plano de controle Amazon Shield Advanced consiste em todas as APIs públicas do Shield Advanced e está hospedado em us-east-1. Isso inclui funcionalidades como CreateProtectionCreateProtectionGroup, AssociateHealthCheckDesribeDRTAccess,, ListProtections e. O plano de dados é a proteção contra DDoS fornecida pelo Shield Advanced, bem como a criação das métricas do Shield Advanced. O Shield Advanced também utiliza verificações de integridade do Route 53 (que fazem parte do plano de dados do Route 53), se você as tiver configurado. Durante uma falha no plano de controle, as operações do tipo CRUDL do Shield Advanced podem não funcionar, mas a proteção contra DDoS configurada para seus recursos, bem como as respostas às mudanças nas verificações de saúde, continuarão funcionando.

O que isso significa é que você não deve confiar no plano de controle Shield Advanced em seu caminho de recuperação. Embora o plano de controle Shield Advanced não forneça a funcionalidade direta que você normalmente usaria em uma situação de recuperação, pode haver momentos em que você o faria. Por exemplo, um design estaticamente estável seria ter seus recursos de DR já configurados para fazer parte de um grupo de proteção e ter verificações de integridade associadas a eles, em vez de configurar essa proteção após a ocorrência da falha. Isso evita depender do plano de controle Shield Advanced para recuperação.