Todo el mundo empieza en Azure de la misma manera: una sola suscripción, todo desparramado en un resource group llamado rg-teste y la contraseña de owner circulando por el chat del equipo. Funciona durante unos meses. Después llega la factura, el incidente de seguridad o el auditor, y el desorden pasa la cuenta con intereses.
La gobernanza en Azure no es burocracia de una empresa grande. Es lo que separa la nube que controlas de la nube que te controla. Estas son las prácticas que valen el esfuerzo.
Organiza la casa antes de invitar gente
Una suscripción no es una carpeta: es una frontera. Una frontera de facturación, de cuota y de políticas. Antes de empezar a crear recursos, diseña la jerarquía de management groups: un grupo raíz y, debajo, divisiones por entorno (prod, no prod) o por área de negocio.
La clave está en aplicar Azure Policy en el nivel adecuado: puedes prohibir regiones fuera de Brasil, exigir tags en todos los recursos o bloquear SKUs caras una sola vez, en el management group, y la configuración se hereda en todo lo que esté debajo. Corregirlo recurso por recurso después es un suplicio.
RBAC: menos es más, siempre
Owner es el nuevo root, y nadie debería andar por ahí con acceso de root. RBAC en Azure es granular a propósito: úsalo.
Asigna el rol menos permisivo que resuelva la necesidad. Quien solo lee métricas recibe Reader. Quien modifica una aplicación recibe Contributor en ese resource group, no en toda la suscripción. Prefiere grupos de Entra ID a asignaciones individuales; así, para hacer offboarding, basta con quitar a la persona del grupo en lugar de rastrear permisos dispersos. Y para los accesos privilegiados, activa PIM: en vez de mantener Owner de forma permanente, el acceso se eleva bajo demanda, por un plazo definido y con una justificación. Menos puertas abiertas, menos dolores de cabeza.
Un budget no es decoración: configúralo antes del susto
La factura de Azure no te avisa de que va a doler. Eres tú quien tiene que preguntar.
Cost Management es gratuito y no lo estás usando. Crea budgets por suscripción o por resource group, con alertas al 50 %, 80 % y 100 % de lo previsto. Activa las alertas de anomalías, que avisan cuando el gasto se desvía del patrón sin que tengas que mirar el dashboard todos los días. Y reserva una reunión de treinta minutos al mes para abrir el cost analysis, agrupar por tag y encontrar la VM encendida que nadie usa desde marzo. Siempre hay una.
Los servicios administrados casi siempre ganan a las VM
Cada VM que levantas es un sistema operativo que tienes que parchear, un disco que debes monitorear y un backup que esperas haber configurado correctamente. ¿Escalar? También es tu responsabilidad.
Antes de crear una Virtual Machine, pregunta si un servicio administrado puede resolverlo. App Service o Container Apps en lugar de una VM ejecutando tu backend. Azure SQL o PostgreSQL Flexible Server en lugar de una base de datos que instalas y mantienes por tu cuenta. Pagas un poco más por hora y ahorras horas de operación; además, obtienes aplicación de parches, alta disponibilidad y escalado con un clic. Una VM es la última opción, no la primera.
Un tag es el impuesto que pagas con una sonrisa
Un tag parece una exageración hasta que abres una factura de cinco cifras y no sabes de qué proyecto salió.
Define un conjunto pequeño de tags obligatorios y trátalos como un contrato: owner, environment, costCenter, project. No confíes en la buena voluntad del equipo: usa Azure Policy para exigir el tag durante la creación e incluso para heredarlo del resource group. Con tags consistentes, el cost analysis, los informes de compliance y la búsqueda de recursos huérfanos se convierten en un filtro de un clic en lugar de una excavación arqueológica.
Nada de portal a mano: Bicep o Terraform
Un recurso creado haciendo clics en el portal es un recurso que nadie sabe recrear. Es una mascota, no ganado.
La infraestructura es código. Bicep si vives en el ecosistema de Azure y quieres algo ligero y nativo; Terraform si ya trabajas con multi-cloud o el equipo está acostumbrado a HCL. La herramienta es lo de menos; lo importante es la regla: cualquier cambio en producción pasa por un commit, una revisión y un pipeline. Así tienes un historial de lo que cambió, puedes replicar todo el entorno en otra región cuando lo necesites y dejas de descubrir configuraciones por sorpresa. El portal se convierte en una herramienta de lectura, no de escritura.
La gobernanza en Azure no es un proyecto de seis meses. Son media docena de hábitos aplicados a tiempo. Hazlo ahora, con diez recursos, y lo agradecerás cuando sean mil. Si lo dejas para después, se convierte en una deuda con intereses compuestos en la factura.