La buena práctica es tener la producción completamente separada de los entornos de prueba o desarrollo, lo que se logra mejor al tener cuentas separadas para ellos:

Las cuentas en SDLC OU alojan cargas de trabajo que no son de producción y, por lo tanto , no deben tener dependencias de producción de otras cuentas.

Dado que no está utilizando una cuenta diferente, lo más cercano que puede obtener (si desea seguir la buena práctica) es tener diferentes VPC (opción 1). Además, para separar aún más los entornos, las VPC podrían estar en diferentes regiones .

También lo alentaría a repensar por qué necesita recursos comunes (es decir, VPC). Si comparte algo (por ejemplo, RDS) entre prod y devel a través de la cuarta VPC, es un desastre a punto de ocurrir.

Me encontré con un problema similar.

VPC por entorno puede crear una gran separación entre los recursos, por lo que recomendaría tener al menos VPC PROD y no PROD (dev, test, uat).

Tener una VPC por entorno puede provocar un aumento de los costes:

• Puerta de enlace NAT/instancia NAT por subred por VPC
• Puntos finales de VPC (pueden ser bastante caros, alrededor de 7 USD por punto final y, a menudo, necesita más de uno, pero debe tener en cuenta que solo puede tener una subred por AZ adjunta).
• VPN (dentro de cada VPC)
• CICD (si utiliza agentes autohospedados [p. ej., utilizando Azure DevOps], necesita un agente en cada VPC)
• La gestión puede ser más difícil (más recursos redundantes, etc.).

(Por supuesto, puede resolver algunos problemas utilizando VPC Peering , pero no creo que esta sea la solución adecuada en este caso)

Por otro lado, tener una VPC por entorno puede generar algunos beneficios:

• La matriz de subred puede ser la misma para todos los ENV, por lo que es más fácil de depurar
• Una VPN por entorno puede reducir la posibilidad de estar "en el entorno equivocado por accidente"
• Mínimo el riesgo de afecto de recursos mutuos.

Para un entorno de producción, la respuesta clara es aislarlo en su propia cuenta de AWS (no solo en una VPC separada). Con Control Tower y SSO, la complejidad de administrar varias cuentas de AWS ya no es lo que solía ser.

Para entornos que NO son de producción como Dev, Staging, QA, Demo, etc., la respuesta es menos clara. Ciertamente me gustaría saber de otros. Puedo ver 3 formas principales de hacerlo.

1. Cada entorno tiene su propia cuenta de AWS. Esto podría usarse para entornos de demostración o UAT (además de Prod), pero parece excesivo para otros tipos de entornos que normalmente se usan internamente para el desarrollo. También hay un costo adicional para esta solución.

2. Cada entorno tiene su propia VPC, dentro de una cuenta de AWS compartida. Esto aísla cada entorno a nivel de red y de ACL.

   Contras:

   • Límite de 5 VPC por cuenta de AWS
   • Costos adicionales como respondió [Filip Niko arriba .

   Ventajas:

   • ¿Configuración simplificada? Dado que todas las VPC se pueden aprovisionar de manera idéntica (a través de CDK, por ejemplo).
   • Mejor aislamiento entre entornos que la solución 3 a continuación.

3. Cada entorno tiene su propia pila de red, dentro de una VPC compartida y una cuenta de AWS.

   Contras:

   • Más difícil de "soltar y recrear". Con CDK, se puede aprovisionar fácilmente un nuevo "entorno" creando la VPC y sus servicios. Supongo (confirme) que esto es más difícil cuando una VPC contiene todo.
   • No es seguro para entornos de cara al público.

   Ventajas:

   • Una VPC puede tener 200 subredes. Incluso si se asignan 3 subredes por entorno (público, privado y aislado), esto da ~60 entornos.
   • Más barato en general. Menos NAT, se necesitan terminales.

Me encantaría escuchar comentarios sobre lo anterior.