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á.
Antipadrões para acesso à rede no Nuvem AWS
Um antipadrão é uma solução frequentemente usada para um problema recorrente em que a solução é contraproducente, ineficaz ou menos eficaz do que uma alternativa. As opções de design mencionadas nesta seção geralmente funcionam, mas apresentam desvantagens significativas. Se possível, eles devem ser evitados porque existem alternativas melhores.
Esta seção discute os seguintes antipadrões e desafios:
Incompatibilidade da zona de disponibilidade com AWS PrivateLink
Ao fornecer acesso a um aplicativo por meio de AWS PrivateLink, os consumidores de SaaS podem criar endpoints VPC de interface somente nas zonas de disponibilidade em que o aplicativo é implantado. Por exemplo, se o aplicativo for implantado em use1-az1 euse1-az2, o consumidor não poderá implantar um VPC endpoint em. use1-az3 Recomendamos que você implante a oferta de SaaS em todas as zonas de disponibilidade. A maioria Regiões da AWS tem três zonas de disponibilidade, embora algumas tenham mais. Para obter uma lista abrangente, consulte Regiões e zonas de disponibilidade
nota
Os nomes das zonas de disponibilidade são diferentes dos da zona de disponibilidade IDs. Para obter mais informações, consulte Zona de disponibilidade IDs para seus AWS recursos.
Se um provedor de SaaS optar por não implantar em todas as zonas de disponibilidade, haverá algumas consequências. Suponha que a oferta de SaaS esteja implantada em use1-az1 euse1-az2, mas o consumidor esteja usando todas as três zonas de disponibilidade, inclusive. use1-az3 Os endpoints VPC da interface são implantados no lado do consumidor use1-az1 euse1-az2, agora, o aplicativo use1-az3 precisa acessar um desses endpoints. Em primeiro lugar, o tráfego deve ser permitido das sub-redes nas zonas de disponibilidade incomparáveis para os respectivos VPC endpoints. O consumidor pode decidir usar o nome AWS PrivateLink
DNS regional, que pode ser resolvido em qualquer um dos endpoints da VPC e que distribui uniformemente o tráfego entre os dois. Ou o consumidor pode optar por enviar tráfego diretamente para um endpoint, comouse1-az2. Isso resulta em 67% do tráfego chegando ao lado do provedor use1-az2 e 33% entrando. use1-az1 A figura a seguir mostra esse cenário.
Com um número significativo de consumidores e uma distribuição desigual do tráfego, uma carga de trabalho pode ter problemas de capacidade em uma zona de disponibilidade e estar abaixo da capacidade em outra. Para resolver esse problema, o provedor de SaaS pode decidir balancear uniformemente a carga do tráfego do seu lado, habilitando o balanceamento de carga entre zonas no Network Load Balancer. Isso acarreta custos adicionais.
Se apenas uma zona de disponibilidade for correspondida pelo provedor de serviços, todo o tráfego entrará em um único endpoint. Isso cria um desequilíbrio ainda maior. Como resultado, a oferta de SaaS não está mais altamente disponível para o consumidor. Não importa para o consumidor se o aplicativo é servido em zonas de disponibilidade adicionais que ele mesmo não está usando. Na pior das hipóteses, um provedor de SaaS pode não ser capaz de atender um consumidor que não usa nenhuma das mesmas zonas de disponibilidade.
No caso raro de não haver uma opção viável para o provedor de SaaS provisionar seu aplicativo em todas as zonas de disponibilidade, também é possível criar uma sub-rede somente nas zonas de disponibilidade ausentes e, em seguida, estender o serviço para essas zonas de disponibilidade vazias. O balanceamento de carga entre zonas pode então distribuir o tráfego de entrada pelos endpoints reais do aplicativo nas outras zonas de disponibilidade.
AWS Site-to-Site VPN conexões entre Contas da AWS
Às vezes, as empresas que migram de ambientes locais para a nuvem tentam elevar e deslocar toda a rede. Isso pode causar problemas porque há diferenças significativas entre as práticas de rede local e na nuvem. Se essa mudança de mentalidade não acontecer, coisas como AWS Site-to-Site VPN conexões de uma VPC para outra VPC podem acontecer. Essa abordagem não tira proveito dos serviços de rede desenvolvidos especificamente no Nuvem AWS, que simplificam o gerenciamento e melhoram o desempenho. A adaptação aos designs nativos da nuvem ajuda a reduzir a sobrecarga operacional e resulta em uma conectividade mais confiável e escalável entre eles. VPCs
Se você está pensando em fornecer essa opção de conectividade como provedor de SaaS, pergunte a si mesmo ou ao consumidor por que ela AWS Site-to-Site VPN deve ser usada. Em seguida, retroceda a partir desses requisitos para encontrar uma melhor opção de conectividade. A seção Comparando os recursos do serviço deste guia contém uma matriz que você pode usar para ajudar a identificar opções. Em seguida, você pode examinar as seções relevantes deste guia para encontrar uma abordagem arquitetônica que aborde seu caso de uso.