El primer paso para disponer de infraestructura en la nube es disponer de un Datacenter Virtual estructurado para soportar el crecimiento de una manera controlada y organizada. Si bien es posible que se hagan modificaciones en el futuro y que el diseño no sea el definitivo, sí es importante tratar de que esté lo más estructurado posible para evitar esfuerzos a posteriori.
Es importante definir y seguir una política de nomenclatura que permita identificar los recursos.
Es importante decidir en qué región se van a ubicar los recursos y si se desea implementar redundancia geográfica. Si es así qué región será el respaldo natural.
Es importante definir un espacio de direcciones CIDR que, sobre todo, no presente conflictos con redes ya existentes.
Es importante pensar en el modelo de imputación de costes de cara a identificar cuántas suscripciones crear y con qué criterio. Es este punto es importante pensar si se desea crear una zona común para varios proyectos/unidades de negocio, con servicios compartidos de red o seguridad, por ejemplo, de modo que ciertos elementos de infraestructura no sea necesario implementarlos varias veces.
Es importante pensar en quién y cómo va a gestionar la infraestructura, qué roles y grupos han de tener qué permisos.
Una vez definidos estos criterios el siguiente paso natural es plasmarlo en lo que sería el esqueleto sobre el que implementar las cargas de cómputo.
Desde el punto de vista de recursos serían, al menos, una Virtual Network o VNET con una subnet, pero normalmente se desea segmentar la red por seguridad.
Azure recientemente ha implementado como blueprints un par de conjuntos de elementos que se pueden desplegar en un par de clicks que, además, es cumplen con la normativa ISO 27001.
De manera muy sencilla se puede desplegar una Landing Zone estructurada en una zona de servicios compartidos https://docs.microsoft.com/es-es/azure/governance/blueprints/samples/iso27001-shared/ y una zona de cargas de trabajo con un Application Service Environment y bbdd SQL https://docs.microsoft.com/es-es/azure/governance/blueprints/samples/iso27001-ase-sql-workload/
No obstante como el objetivo de este blog es divulgativo destriparemos la estructura para implementar algo muy similar pero sin utilizar los blueprints.
Es habitual utilizar un modelo en el que se separa una zona de Servicios Compartidos o Tránsito de Red de una zona de Cómputo.
Es habitual también utilizar una Topología de Red HUB & SPOKE en la que una VNET centraliza el flujo de tráfico entre todas las demás, de modo que se puede hacer pasar todo el tráfico por un único punto (Virtual Appliance) mediante Rutas (UDR) y aplicar un filtrado de red adicional a los NSGs, mediante alguna tecnología de Firewall como Azure Firewall.
Ejemplo de modelo HUB & SPOKE con zona de Servicios Compartidos a la derecha y Zona de Cómputo a la Izquierda, en este caso con 3 VNets pertenecientes a 2 proyectos:
Este modelo se apoya en varios elementos básicos de Azure que es necesario conocer para poder desplegar e implementar cargas:
- VNets y Subnets
- VNET Peering
- Network Security Groups (NSGs)
- Tablas de Rutas definidas por el usuario (Route Tables)
- Service Endpoints
- Virtual Appliance (Azure Firewall, Palo Alto)
- VPN Gateway
En la siguiente entrada entraremos en profundidad con cada uno de ellos.