REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload - Pilar Confiabilidade
Orientação de implementaçãoRecursos

REL02-BP01 Usar conectividade de rede altamente disponível nos endpoints públicos de workload

Criar uma conectividade de rede altamente disponível nos endpoints públicos das workloads pode ajudar a reduzir o tempo de inatividade devido à perda de conectividade e melhorar a disponibilidade e o SLA da workload. Para que isso seja possível, use DNS altamente disponível, redes de entrega de conteúdo (CDNs), gateways de API, balanceamento de carga ou proxies reversos.

Resultado desejado: é fundamental planejar, criar e operacionalizar a conectividade de rede altamente disponível para endpoints públicos. Se a workload ficar inacessível devido a uma perda de conectividade, mesmo se ela estiver em execução e indisponível, os clientes verão o sistema como inativo. Ao combinar a conectividade de rede altamente disponível e resiliente para os endpoints públicos da workload, junto com uma arquitetura resiliente para a própria workload, é possível fornecer o melhor nível possível de serviço e disponibilidade possível aos clientes.

O AWS Global Accelerator, o Amazon CloudFront, o Amazon API Gateway, os URLs de função do AWS Lambda, as APIs do AWS AppSync e o Elastic Load Balancing (ELB) fornecem endpoints públicos altamente disponíveis. O Amazon Route 53 fornece um serviço de DNS altamente disponível para a resolução do nome de domínio a fim de verificar se os endereços do endpoint público podem ser resolvidos.

Também é possível avaliar os dispositivos de software do AWS Marketplace com relação ao proxy e ao balanceamento de carga.

Antipadrões comuns:

  • Projetar uma workload altamente disponível sem planejar a alta disponibilidade do DNS e da conectividade de rede.

  • Usar endereços de internet públicos em instâncias ou contêineres individuais e gerenciar a conectividade com eles por meio de DNS.

  • Usar endereços IP em vez de nomes de domínio para localizar serviços.

  • Não testar cenários em que a conectividade com os endpoints públicos é perdida.

  • Não analisar as necessidades de throughput de rede e os padrões de distribuição.

  • Não testar nem se planejar para cenários em que a conectividade de rede da internet com os endpoints públicos da workload possam ser interrompidos.

  • Fornecer conteúdo (como páginas da web, ativos estáticos ou arquivos de mídia) para uma grande área geográfica e não usar uma rede de entrega de conteúdo.

  • Não se planejar para ataques de negação distribuída de serviços (DDoS). Ataques DDoS representam um risco de obstruir o tráfego legítimo e reduzir a disponibilidade para os usuários.

Benefícios do estabelecimento dessa prática recomendada: projetar-se para uma conectividade de rede resiliente e altamente disponível garante que a workload esteja acessível e disponível para os usuários.

Nível de exposição a riscos quando esta prática recomendada não é estabelecida: alto

Orientações para a implementação

No centro da criação de uma conectividade de rede altamente disponível com os endpoints públicos está o roteamento do tráfego. Para verificar se o tráfego consegue acessar os endpoints, o DNS deve poder resolver os nomes de domínio para os endereços IP correspondentes. Use um Sistema de Nomes de Domínio (DNS) escalável e altamente disponível, como o Amazon Route 53, para gerenciar os registros de DNS do domínio. Também é possível usar verificações de integridade fornecidas pelo Amazon Route 53. As verificações de integridade conferem se a aplicação está acessível, disponível e funcional, e podem ser configuradas de uma maneira que imitem o comportamento do usuário, como solicitar uma página da web ou um URL específico. Em caso de falha, o Amazon Route 53 responde às solicitações de resolução de DNS e direciona o tráfego somente aos endpoints íntegros. Também é possível considerar o uso dos recursos DNS GEO e Roteamento baseado em latência oferecidos pelo Amazon Route 53.

Para verificar se a própria workload é altamente disponível, use o Elastic Load Balancing (ELB). O Amazon Route 53 pode ser usado para direcionar o tráfego para o ELB, o que distribui o tráfego às instâncias de computação de destino. Também é possível usar o Amazon API Gateway com o AWS Lambda para obter uma solução sem servidor. Os clientes também podem executar workloads em várias Regiões da AWS. Com o padrão multissite ativo/ativo, a workload pode fornecer o tráfego de várias regiões. Com um padrão multissite ativo/passivo, a workload fornece tráfego da região ativa enquanto os dados são replicados para a região secundária e se torna ativa caso ocorra uma falha na região primaria. As verificações de integridade do Route 53 podem então ser usadas para controlar o failover de DNS de qualquer endpoint em uma região primária para um endpoint em uma região secundária, verificando se a workload está acessível e disponível para os usuários.

O Amazon CloudFront fornece uma API simples para distribuir o conteúdo com baixa latência e altas taxas de transferência de dados atendendo a solicitações usando uma rede de locais de borda ao redor do mundo. As redes de entrega de conteúdo (CDNs) atendem os clientes fornecendo conteúdo localizado ou armazenado em cache em um local próximo ao usuário. Isso também melhora a disponibilidade da aplicação, já que a carga do conteúdo é migrada dos servidores para os locais da borda do CloudFront. Os locais da borda e os caches de borda regionais armazenam cópias em cache do conteúdo próximo aos visualizadores, resultando em recuperação rápida e aumentando a acessibilidade e a disponibilidade da workload.

Para workloads com usuários distribuídos geograficamente, o AWS Global Accelerator ajuda a melhorar a disponibilidade e o desempenho das aplicações. O AWS Global Accelerator fornece endereços IP estáticos anycast que servem como um ponto de entrada fixo para a aplicação hospedada em uma ou mais Regiões da AWS. Isso permite que o tráfego entre na rede global da AWS o mais próximo possível dos usuários, melhorando a acessibilidade e a disponibilidade da workload. O AWS Global Accelerator também monitora a integridade dos endpoints da aplicação usando as verificações de integridade de TCP, HTTP e HTTPS. Qualquer mudança na integridade ou na configuração dos endpoints aciona o redirecionamento do tráfego de usuários para endpoints íntegros que oferecem o melhor desempenho e disponibilidade aos usuários. Além disso, o AWS Global Accelerator tem um design de isolamento de falhas que usa dois endereços IPv4 estáticos que são fornecidos por zonas de rede independentes, aumentando a disponibilidade das aplicações.

Para ajudar a proteger os clientes de ataques DDoS, a AWS oferece o AWS Shield Standard. O Shield Standard vem automaticamente habilitado e protege de ataques de infraestrutura comum (camadas três e quatro) como inundações de SYN/UDP e ataques de reflexão para comportar a alta disponibilidade das aplicações na AWS. Para obter mais proteções contra ataques maiores e mais sofisticados (como inundações de UDP), ataques de exaustão de estado (como inundações de TCP SYN) e para ajudar a proteger as aplicações executadas nos serviços Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53, considere o uso do AWS Shield Advanced. Para proteção contra ataques de camada da aplicação como inundações de HTTP POST e GET, use o AWS WAF. O AWS WAF pode usar condições de scripts entre sites, endereços IP, cabeçalhos HTTP, corpo HTTP, strings de URI e injeção de SQL para determinar se uma solicitação deve ser bloqueada ou permitida.

Etapas da implementação

  1. Configure DNS de alta disponibilidade: o Amazon Route 53 é um serviço da web de Sistema de Nomes de Domínio (DNS) escalável e altamente disponível. O Route 53 conecta as solicitações dos usuários às aplicações da internet executadas na AWS ou on-premises. Para obter mais informações, consulte Configurar o Amazon Route 53 como serviço DNS.

  2. Configure verificações de integridade: ao usar o Route 53, verifique se somente os destinos íntegros podem ser resolvidos. Comece criando verificações de integridade do Route 53 e configurando o failover de DNS. Os aspectos a seguir são importantes a considerar ao configurar verificações de integridade:

    1. How Amazon Route 53 determines whether a health check is healthy (Como o Amazon Route 53 determina se uma verificação de integridade é íntegra)

    2. Criar, atualizar e excluir verificações de integridade

    3. Monitorar o status da verificação de integridade e receber notificações

    4. Práticas recomendadas do Amazon Route 53 DNS

  3. Conectar o serviço de DNS aos endpoints.

    1. Ao usar o Elastic Load Balancing como destino do tráfego, crie um registro de alias usando o Amazon Route 53 que aponte para o endpoint regional do balanceador de carga. Durante a criação do registro de alias, defina a opção “Evaluate target health” (Avaliar integridade do destino) como “Yes” (Sim).

    2. Para workloads sem servidor ou APIs privadas quando o API Gateway é usado, use o Route 53 para redirecionar o tráfego para o API Gateway.

  4. Decida sobre uma rede de entrega de conteúdo.

    1. Para entregar conteúdo usando locais da borda mais próximos ao usuário, comece entendendo como o CloudFront entrega conteúdo.

    2. Comece com uma distribuição simples do CloudFront. O CloudFront então sabe de onde você quer que o conteúdo seja entregue e os detalhes sobre como rastrear e gerenciar a entrega de conteúdo. É importante entender e considerar os aspectos a seguir ao configurar uma distribuição do CloudFront:

      1. Como funciona o armazenamento em cache com os pontos de presença do CloudFront

      2. Aumentar a taxa de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache)

      3. Usar o Amazon CloudFront Origin Shield

      4. Otimizar a alta disponibilidade com o failover de origem do CloudFront

  5. Configure a proteção da camada da aplicação: o AWS WAF ajuda você a se proteger contra explorações e bots comuns da web que podem afetar a disponibilidade, comprometer a segurança ou consumir recursos em excesso. Para obter uma compreensão mais profunda, veja como o AWS WAF funciona e, quando estiver pronto para implementar proteções contra inundações HTTP POST E GET da camada de aplicações, consulte Getting started with AWS WAF (Conceitos básicos do AWS WAF). Também é possível usar o AWS WAF com o CloudFront. Consulte a documentação sobre como o AWS WAF funciona com os recursos do Amazon CloudFront.

  6. Configure proteção adicional contra DDoS: por padrão, todos os clientes da AWS recebem proteção contra ataques de DDoS da camada de transporte e rede comuns e que ocorrem com mais frequência que visam seu site ou sua aplicação com o AWS Shield Standard sem custo adicional. Para proteção adicional de aplicações voltadas para a internet executadas no Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator e Amazon Route 53, considere o AWS Shield Advanced e consulte exemplos de arquiteturas resilientes a DDoS. Para proteger sua workload e seus endpoints públicos de ataques de DDoS, consulte Getting started with AWS Shield Advanced (Conceitos básicos do AWS Shield Advanced).

Recursos

Práticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados: