Quais seriam alguns padrões e antipadrões para implantar ambientes espelhados na AWS (ou outros provedores de nuvem)?

Question

Estou procurando alguns bons padrões e antipadrões para a implantação de ambientes espelhados (para simplificar, digamos, uma Instância do EC2 e o bucket do RDS e do S3, que é uma configuração bem comum). Vamos dizer que temos que fazer isso centenas ou até milhares de vezes. Eu bati algumas idéias em torno de como

• Contas múltiplas - Único propósito - Use todas as regiões

  • Implementamos uma instância de uma VPC por região e implementamos nosso conjunto de serviços nessa região.
  • Bom, Garantir isolamento e não noisy neighbors , módulos TF ou modelos do CloudFormation não serão complicados
  • Mau, um pesadelo de gestão maldito

• Conta Única - Multipurpose

  • dividimos nosso VPC em várias sub-redes e implantamos recursos por agrupamento de sub-redes
  • Bom, mais fácil de gerenciar, mais por menos
  • Ruim, você é limitado a 20 sub-redes por região (16 regiões * 20), possibilidade de vizinhos barulhentos, rede pode acabar sendo espaguete

Estou procurando mais maneiras de fazer isso e por que eles seriam ruins (dívida técnica, inamovível) ou bons (facilmente reutilizáveis e etc)

Obrigado um milhão

    

Answer 1

Portanto, alguns pontos gerais a dizer sobre este tópico bastante complexo - depende muito do que você está realmente tentando alcançar.

Você tem três opções:

1. VPC única - conjunto único de grandes sub-redes - no seu exemplo, seriam 4 - 2 sub-redes 'públicas' e 2 sub-redes 'privadas'. Em seguida, use grupos de segurança para isolar 'implantações' - não há nenhum benefício em usar sub-redes para separação que eu vejo, além de ter que gerenciar o espaço de endereço IP e muitas sub-redes. Em última análise, a única diferença entre uma sub-rede é normalmente: AZ / route-table / nacl / dhcp-options - use apenas uma nova sub-rede se uma dessas alterações. Uma sub-rede não fornece problemas de 'vizinho barulhento'. Não é um domínio de camada 2 em um sentido clássico 'vlan' e o gateway de Internet upstream é horizontalmente escalável sem limites, como por exemplo: Perguntas frequentes sobre o Amazon VPC

2. Vários VPCs - se você tivesse uma única conta - você pode ter várias VPCs em uma região, o limite flexível é de 5 VPCs, mas o disco rígido máximo é:

   The number of VPCs in the region multiplied by the number of security groups per VPC cannot exceed 10000.

   Limites do Amazon VPC

   Qual é bastante alto, no seu exemplo você poderia dizer que pode haver 4 grupos de segurança (ELB, EC2 ASG, RDS, acesso de administrador), o que significa, na teoria, 2.500 VPCs? Eu não ouvi falar de ninguém ter isso, mas poderia ser uma opção.

   No entanto, outra coisa em que pensar, dependendo de como sua plataforma é autoescalonável, é que alguns limites têm largura de conta e, se você os atingir para uma implantação, isso poderá afetar outra - por exemplo, simplesmente contagem de instâncias de um determinado tipo - ou limites de execução concorrentes do Lambda. Então isso leva à 3ª opção ...

3. Múltiplas contas - Agora você pode criar novas contas via API graças à AWS Organizations API, no entanto, infelizmente, a página Limits é vaga sobre o limite em termos de número de contas. Embora eu tenha ouvido falar de empresas maiores com milhares de contas. Consulte: Limites das organizações da AWS e Como usar as organizações da AWS para automatizar a criação de contas de ponta a ponta

De modo geral, para o seu caso de uso, você desejará ter uma pilha limpa do CloudFormation que possa ser totalmente reutilizada com uma variação mínima - simplesmente para consistência de implantação, operações e suporte. Para mim, isso aponta para o VPC como a unidade de implantação ou a conta como a unidade de implantação. Você precisará ter cuidado para observar os limites nos dois casos. Fazê-lo em um VPC, seja com grandes sub-redes ou divididos por sub-rede, acabará se tornando confuso para manter - minha visão subjetiva.