En este artículo nos alejaremos del apartado más técnico y hablaremos de arquitectura, pero no de aquella del estilo barroco o renacentista, ni de las grandes construcciones como el Burj Khalifa, sino de arquitectura en la nube.
 
Concretamente nos vamos a centrar en el servicio VPC de AWS y vamos a plantear la situación de tener los entornos de producción y preproducción (u otros entornos no productivos):

• En diferentes VPCs
• En diferentes subredes dentro de la misma VPC

Además, todo ello puede tener impacto en el tema de costes, que suele ser uno de los puntos que más nos preocupan.

Antes de nada convendría repasar el concepto de VPC.

Breve introducción a VPC

El servicio VPC (Virtual Private Cloud) de AWS (Amazon Web Services) permite crear una red privada para tus instancias y servicios en la nube. Con él se pueden crear subredes, configurar el enrutamiento de tráfico, etc., y por supuesto, gestionar y asignar direcciones IP.
 
Entre otras muchas opciones más, también permite definir los llamados Security Groups, que viene a ser el firewall de toda la vida y permite definir reglas para permitir o denegar el tráfico desde o hacia una instancia o servicio.
 
En definitiva, VPC es el servicio que nos permite configurar lo relativo a networking interno de AWS. Teniendo este contexto en mente, pasemos a plantear las situaciones que nos atañen en este artículo.

Una VPC por entorno

Este planteamiento cuenta con numerosas ventajas.

Por un lado, todo queda más ordenado y organizado. Es además muy correcto desde el punto de vista de seguridad ya que existe una clara separación física entre el entorno de preproducción y el entorno de producción. A veces se va más allá en lo referente a seguridad y se usan cuentas de AWS independientes para alojar el VPC de cada entorno, vinculadas todas ellas a una organización AWS.

Por otro lado, disminuye la probabilidad de error humano: tener los entornos separados en diferentes VPCs hace que sea mucho más difícil cometer el error de que dos servidores de entornos diferentes se comuniquen o interactúen entre ellos cuando no deberían hacerlo. Además, aislar entornos minimiza la posibilidad de que cualquier problema en un entorno afecta en el otro.

Por último, otra ventaja a destacar sería a la hora de configurar aspectos relacionados con el control de acceso. Toda regla/configuración definida a nivel de VPC, a nivel práctico, viene a ser una regla a nivel de entorno. Esto facilita y simplifica mucho las configuraciones cuando estas tienen que ser distintas en ambos entornos.

Por contra, lo habitual es que manejar varios entornos genere un sobrecoste debido a:

• La necesidad de duplicar sistemas de monitorización, gestión y servicios auxiliares
• Tráfico que pueda existir entre entornos (idealmente no debería haber, pero pueden darse muchos casos que lo requieran)
• Una mayor complejidad y coste a nivel de operaciones en muchos casos especialmente si los entornos no son idénticos

Nosotros recomendamos este planteamiento de tener una VPC por entorno de manera general, aunque hay que conocer la realidad de cada proyecto, el momento que se encuentra en su ciclo de vida y analizar todas las variables para ver si realmente es necesario.     

Una subred por entorno, misma VPC

Se podría decir que este es el “sweet spot”, como dirían nuestros amigos ingleses.

Teniendo en cuenta y asumiendo que desde el punto de vista de "seguridad corporativa" es erróneo, con este planteamiento seguiríamos teniendo cada entorno separado en subredes distintas por un tema organizativo, pero no de seguridad. Ésta, entre otras cosas, vendrá dada por la configuración de los diferentes Security Groups que deberán impedir el tráfico entre entornos.

El impacto en costes puede ser potencialmente menor al contar con servicios en una sola VPC en lugar de en varias, y poder reutilizar componentes comunes entre varios entornos.

Además, perdemos las ventajas de simplificación de gestión de accesos, configuraciones por entorno, etc. Ya no basta con aplicar reglas a nivel de VPC como sucedía en el caso anterior donde las reglas aplicadas a la VPC de PRO solo afectan a instancias y servicios de PRO (y lo mismo para otros entornos). En este caso ya hay que ser más cuidadoso a la hora de configurar/limitar accesos (IAM, Security Groups, etc.) y la gestión de la plataforma se puede complicar algo más puesto que ambos entornos ya no están tan extremadamente aislados entre sí. 

Conclusión

En una plataforma en la nube nunca hay una solución universal para todos los planteamientos y problemas. Como habéis visto en este artículo, solamente a nivel de red ya hay distintas alternativas, aunque realmente una de ellas es la totalmente correcta si tenemos en cuenta la seguridad.

Al final todo depende de tus necesidades, de los costes que estés dispuesto a asumir y de cuánto estés dispuesto a sacrificar en lo referente a disponibilidad, a tolerancia, a fallos, a seguridad y a errores (humanos o no humanos).

Por eso, lo mejor es consultar a expertos en administración de sistemas y desde STR Sistemas podemos ofrecerte una solución personalizada para tus necesidades ;)