%3F.png)
Estoy buscando encontrar algunos buenos patrones y antipatrones para implementar entornos reflejados (para simplificar, digamos una instancia EC2 y un depósito RDS y S3, que es una configuración bastante común). Digamos que tenemos que hacer esto cientos o incluso miles de veces. He discutido algunas ideas como
Múltiples cuentas - Propósito único - Usar todas las regiones
- Implementamos una instancia de una VPC por región e implementamos nuestro conjunto de servicios en esa región.
- Bien, garantiza aislamiento y no
noisy neighbors, los módulos TF o las plantillas de CloudFormation no serán complicados - Malo, una maldita pesadilla de gestión.
Cuenta Única - Multipropósito
- Dividimos nuestra VPC en múltiples subredes e implementamos recursos por grupo de subredes
- Bien, más fácil de gestionar, más por menos
- Malo, está limitado a 20 subredes por región (16 regiones * 20), posibilidad de vecinos ruidosos, la conexión en red podría terminar siendo espagueti
Estoy buscando más formas de hacer esto y por qué serían malas (deuda técnica, imposible de mantener) o buenas (fácilmente reutilizables, etc.)
Un millón de gracias
Respuesta1
Entonces, algunos puntos generales que decir sobre este tema bastante complejo; depende mucho de lo que realmente esté tratando de lograr.
Tienes tres opciones:
VPC única (conjunto único de subredes grandes); en su ejemplo, serían 4: 2 subredes "públicas" y 2 subredes "privadas". Luego use grupos de seguridad para aislar las 'implementaciones'; veo que no hay ningún beneficio en usar subredes para la separación, aparte de tener que administrar el espacio de direcciones IP y muchas subredes. En última instancia, la única diferencia entre una subred suele ser: AZ/route-table/nacl/dhcp-options: solo use una nueva subred si una de esas cambia. Una subred no genera ningún problema de "vecino ruidoso" en sí misma. No es un dominio de capa 2 en el sentido clásico de 'vlan' y la puerta de enlace de Internet ascendente es horizontalmente escalable sin límites, según:Preguntas frecuentes sobre Amazon VPC
Múltiples VPC: si tenía una sola cuenta, puede tener múltiples VPC en una región, el límite flexible es 5 VPC, pero el máximo máximo es:
La cantidad de VPC en la región multiplicada por la cantidad de grupos de seguridad por VPC no puede exceder 10000.
Lo cual es bastante alto, en su ejemplo se podría decir que podría haber 4 grupos de seguridad (ELB, EC2 ASG, RDS, acceso de administrador), por lo que, en teoría, ¿eso significa 2500 VPC? No he oído que nadie tenga eso, pero podría ser una opción.
Sin embargo, otra cosa en la que pensar, dependiendo de qué tan autoescalable sea su plataforma, es que algunos límites son para toda la cuenta y si los alcanza para una implementación, entonces podría afectar a otra (por ejemplo, simplemente el recuento de instancias de un tipo particular) o Lambda concurrente. límites de ejecución. Entonces eso lleva a la tercera opción...
Varias cuentas: ahora puede crear nuevas cuentas a través de API gracias a la API de AWS Organizations; sin embargo, desafortunadamente la página de Límites es vaga sobre cuál es ese límite en términos de número de cuentas. Aunque he oído hablar de empresas más grandes que tienen miles de cuentas. Ver:Límites de las organizaciones de AWSyCómo utilizar AWS Organizations para automatizar la creación de cuentas de un extremo a otro
En general, para su caso de uso, querrá tener una pila de CloudFormation limpia que pueda reutilizarse por completo con una variación mínima, simplemente para lograr coherencia en la implementación, las operaciones y el soporte. Para mí, esto apunta a VPC como unidad de implementación o a Cuenta como unidad de implementación. Deberá tener cuidado y estar atento a los límites en ambos casos. Hacerlo dentro de una VPC, ya sea con subredes grandes o dividido por subred, en última instancia será complicado de mantener: mi punto de vista subjetivo.