Quais seriam alguns Padrões e Antipadrões para implantação de ambientes espelhados na AWS (ou outros provedores de nuvem)

Question

Estou procurando alguns bons padrões e antipadrões para implantar ambientes espelhados (para simplificar, digamos uma instância EC2 e um bucket RDS e S3, que é uma configuração bastante comum). Digamos que tenhamos que fazer isso centenas ou até milhares de vezes. Eu discuti algumas ideias, como

• Várias contas – Finalidade única – Usar todas as regiões

  • Implantamos uma instância de VPC por região e implantamos nosso conjunto de serviços nessa região.
  • Bom, garante isolamento e não noisy neighbors, módulos TF ou modelos CloudFormation não serão complicados
  • Ruim, um maldito pesadelo de gerenciamento

• Conta Única - Multiuso

  • Dividimos nossa 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ê está limitado a 20 sub-redes por região (16 regiões * 20), possibilidade de vizinhos barulhentos, a rede pode acabar sendo espaguete

Estou procurando mais maneiras de fazer isso e por que elas seriam ruins (dívida técnica, insustentáveis) ou boas (facilmente reutilizáveis ​​e etc.)

Obrigado um milhão

Answer 1

Portanto, alguns pontos gerais a serem ditos sobre esse tópico bastante complexo – depende muito do que você realmente está tentando alcançar.

Você tem três opções:

1. VPC único - conjunto único de sub-redes grandes - 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 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 oferece nenhum problema de 'vizinho barulhento'. Não é um domínio de camada 2 no sentido clássico de 'vlan' e o gateway de Internet upstream é escalonável horizontalmente sem limites, conforme:Perguntas frequentes sobre Amazon VPC

2. Múltiplas 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 máximo máximo é:

   O número de VPCs na região multiplicado pelo número de grupos de segurança por VPC não pode exceder 10.000.

   Limites de Amazon VPC

   O que é 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 2.500 VPCs, teoricamente? Não ouvi falar de ninguém que tenha isso, mas pode ser uma opção.

   No entanto, outra coisa a se pensar, dependendo de quão autoescalável é sua plataforma, é que alguns limites abrangem toda a conta e se você atingi-los em uma implantação, isso pode afetar outra - por exemplo, simplesmente contagem de instâncias de um tipo específico - ou Lambda simultâneo limites de execução. Então isso leva à terceira opção...

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

No geral, para o seu caso de uso, você desejará ter uma pilha limpa do CloudFormation que possa ser totalmente reutilizada com variação mínima - simplesmente para consistência de implantação, operações e suporte. Para mim, isso aponta para VPC como unidade de implantação ou Conta como unidade de implantação. Você precisará ter cuidado ao observar os limites em ambos os casos. Fazer isso dentro de uma VPC, seja com sub-redes grandes ou dividido por sub-rede, acabará sendo complicado de manter - minha visão subjetiva.