Construí en Azure lo que ya sabía hacer en Google Cloud, y esto fue lo que me encontré

Llevo años diseñando y operando plataformas en Google Cloud y hasta hace poco no tenía ni una cuenta de Azure. Cuando un cliente me preguntaba por Azure, mi respuesta salía de comparativas ajenas, así que decidí construir en Azure lo mismo que ya sabía hacer en Google Cloud y contar lo que me encontré.

Este es el panorama: los hallazgos que más cambiaron mi forma de pensar la plataforma, con lo que haría distinto desde el primer día. Cada uno tiene su propio artículo en la serie, con el detalle y los números.

Qué construí y cómo lo probé

Una zona de aterrizaje de laboratorio con Terraform: una red central con Azure Firewall por la que sale y entra todo, una red de aplicación emparejada con ella, un clúster AKS privado con identidad de Entra y sin cuentas locales, y un registro de imágenes, una bóveda de secretos y almacenamiento alcanzables solo por endpoints privados.

La probé en dos capas. Primero sin nube: 170 pruebas de Terraform contra el esquema de Azure, sin credenciales, antes de abrir la cuenta de prueba y su reloj de 30 días. Después contra Azure real: nueve verificaciones que atacan cada control y fallan si no logran medir nada. La primera capa cuida la forma, y la segunda, lo que solo la API de Azure sabe. Cómo lo organicé sin tener cuenta lo cuento en la parte 5.

La red: negar por defecto tiene letra pequeña

En una red personalizada de Google Cloud la entrada se niega por defecto. En Azure, cada grupo de seguridad trae AllowVnetInBound en la prioridad 65000, así que todo lo que cae en la etiqueta VirtualNetwork, redes emparejadas incluidas, habla con todo. Para tener la misma postura hay que agregar una denegación propia, y ahí está la letra pequeña: varias piezas de la plataforma dependían de ese permiso implícito.

Si vas a negar el tráfico interno, declara desde el principio tres permisos: los nodos hacia su propia subred, porque AKS pone ahí el endpoint privado del servidor de API; AzureLoadBalancer hacia los nodos, porque la sonda de salud cae dentro de VirtualNetwork y su regla por defecto queda debajo de tu denegación; y el rango de pods, si usas CNI Overlay con más de un nodo. Enciende también los registros de flujo de la red virtual, porque ni el firewall ni el grupo de seguridad te van a mostrar lo que se niega dentro de una subred. El clúster que pasó 87 minutos creándose sin un solo error lo cuento en la parte 3.

Los permisos: control y datos van por separado

En Google Cloud estaba acostumbrado a que un propietario del proyecto lo pueda casi todo. En Azure, Owner de la suscripción tiene todas las acciones del plano de control y ninguna de datos: no lee un secreto, ni el estado de Terraform, ni usa kubectl en un clúster con Azure RBAC.

Lo práctico es diseñar el plano de datos aparte y asignar cada rol al recurso que protege, no al grupo de recursos. Y apagar las llaves alternativas, las claves compartidas del almacenamiento y las cuentas locales de Kubernetes, para que los roles sean la única forma de entrar. Los roles exactos y la única excepción que dejé están en la parte 4.

La entrada: decide temprano si necesitas saber quién te visita

Si la entrada desde internet pasa por una regla DNAT de Azure Firewall, el firewall también traduce el origen, y tu aplicación ve la dirección del firewall en lugar de la del visitante. Microsoft lo documenta, y la verificación nueve lo comprueba en cada corrida.

La consecuencia es de diseño: sin la dirección del cliente no hay límites por cliente, ni reglas por país, ni un registro útil ante un abuso, y externalTrafficPolicy en Local no la recupera. Si algún requisito menciona cualquiera de esas tres cosas, presupuesta desde el primer día una pieza de capa 7 delante, como Application Gateway o Front Door. Las opciones que pesé y por qué me quedé con el firewall están en la parte 2.

Los registros: nada viene encendido

En Google Cloud los registros de auditoría de actividad administrativa vienen encendidos y no se pueden apagar. En Azure el registro de actividad de la suscripción existe, pero casi todo lo demás se declara recurso por recurso: el diagnóstico del firewall hacia tablas dedicadas, la auditoría del servidor de API del clúster y los registros de flujo de la red virtual. Un recurso sin su diagnóstico es un recurso del que no vas a saber nada cuando falle.

La cuenta de prueba tiene sus propias reglas

Algunos límites no son de Azure sino de la oferta. La prueba gratuita permite tres direcciones IP públicas, y Azure Firewall Basic ya consume dos: una para el tráfico y otra para el plano de administración que ese nivel exige. Eso descartó un balanceador público por aplicación y empujó toda la entrada por el firewall. Las máquinas spot tampoco están disponibles en la prueba gratuita, así que el nodo corre a precio normal.

El costo quedó en unos 15 dólares al mes por la capa permanente y unos 54 centavos por hora mientras el firewall y el clúster están arriba, casi tres cuartas partes de eso el firewall. Por eso la capa que cobra por hora se destruye al terminar cada sesión.

Lo que resume todo

En Azure casi nada viene hecho: se declara. La red confía por dentro hasta que la vences, los datos no son del dueño hasta que se los asignas y los registros no existen hasta que los pides. Da más control explícito y lo cobra en trabajo, y un plan de migración desde Google Cloud que no presupueste ese trabajo lo descubre en el despliegue, que es el momento más caro.

Entonces, ¿Azure o Google Cloud?

A este nivel las dos hacen todo, y lo que decide es lo que el cliente ya tiene. La identidad pesa más que cualquier servicio: si la empresa vive en Microsoft 365, su directorio ya es Entra ID y ya está pagado, y llevarla a otra nube es pagar la identidad dos veces.

Los seis criterios que uso en orden de peso, y los pocos casos en que tiene sentido usar las dos nubes a la vez, están en la parte 6.

Pruébalo tú

El código, la guía para desplegarlo en tu propia suscripción, las trece decisiones con lo que cuesta cada una y la evidencia de la última corrida están en github.com/dhatune/platform-blueprints, en la carpeta azure.

¿Cuántos de los reflejos que traes de tu nube actual son en realidad supuestos que la otra nube no comparte?