Probé mi infraestructura de Azure antes de tener cuenta en Azure
24 de octubre de 2026
La prueba gratuita de Azure dura 30 días desde que la creas. Escribí y probé toda la infraestructura antes de abrirla, con 170 pruebas de Terraform que no necesitan nube ni credenciales.
Una cuenta de prueba de Azure da 200 dólares de crédito y 30 días, y el reloj empieza a correr el día que la creas. Yo no tenía experiencia en Azure y sabía que el primer mes se me iría escribiendo código, así que decidí no abrir la cuenta hasta tener la infraestructura escrita y probada.
Para comparar, la prueba gratuita de Google Cloud da 300 dólares por 90 días. Con un mes, el margen para aprender a costa del crédito es mucho menor, y eso cambió cómo organicé el trabajo.
Probar sin nube
Terraform permite, desde la versión 1.7, simular el proveedor dentro de sus propias pruebas. Con un proveedor simulado, terraform test ejecuta un plan real contra el esquema de Azure sin credenciales y sin crear nada. El esquema es el contrato completo de lo que Azure acepta, así que un error de forma aparece en el computador y no en la nube.
Lo que me convenció fue la diferencia con validar. terraform validate revisa sintaxis y tipos, y no te dice si un grupo de seguridad de verdad niega, si la ruta por defecto apunta al firewall o si cada zona de DNS privado quedó vinculada a las dos redes. Esas son las propiedades que vale la pena proteger, y se pueden afirmar en un plan.
Terminé con 170 pruebas repartidas entre módulos y capas, y todas corren en integración continua con cada cambio.
Lo que aprendí del simulador
El proveedor valida el formato de los identificadores al planear. Una asignación de política rechazó el identificador aleatorio que el simulador inventa para una fuente de datos, y tuve que darle uno sintético con la estructura correcta.
Las aserciones solo leen valores conocidos al planear. Un atributo que calcula la API, como el identificador de un recurso, queda desconocido y la prueba falla. La salida fue ejecutar esas pruebas en modo apply, que contra un proveedor simulado tampoco crea nada pero resuelve esos valores. Uso apply solo cuando la aserción lo necesita, porque plan es más barato y falla antes.
Y un detalle que me costó un rato: en el proveedor de Azure el espacio de direcciones de una red es un conjunto y los prefijos de una subred son una lista. Parecen lo mismo hasta que intentas tomar el primer elemento.
Lo que el simulador no ve
Tiene un límite claro: no sabe nada que solo sepa la API. La cuota de tu suscripción, si un tamaño de máquina existe en tu región, si un nombre ya está tomado o cómo funcionan los permisos. Todo eso falla en el primer despliegue y ninguna prueba simulada te avisa.
Me pasó. La cuenta de prueba solo permite tres direcciones públicas y el firewall ya usa dos. Y cuando desplegué desde cero, como lo haría un desconocido, aparecieron tres permisos que yo había dado a mano y que no estaban en el código. Para eso escribí las nueve verificaciones contra Azure real: las pruebas simuladas cuidan la forma y las vivas cuidan lo que solo la nube sabe.
| Opción | Costo | Riesgo | Veredicto |
|---|---|---|---|
| Solo terraform validate | CostoNada | RiesgoAprueba un grupo de seguridad que no niega nada | VeredictoInsuficiente |
| Pruebas con proveedor simulado | CostoEscribir y mantener 170 pruebas | RiesgoNo ven cuota, permisos ni disponibilidad por región | VeredictoElegido para la forma |
| Desplegar en la nube cada cambio | CostoCrédito y minutos de espera por cada error de forma | RiesgoGastar la prueba gratuita corrigiendo detalles | VeredictoSolo para lo que únicamente la API sabe |
Lo que costó
Cuando abrí la cuenta, el código ya estaba probado contra el esquema de Azure, y el crédito se fue en responder lo que solo Azure puede responder.
La decisión y sus límites están escritos en el repositorio.
¿Cuánto de lo que hoy descubres pagando horas de nube podrías haberlo descubierto en tu computador, antes de abrir la cuenta?