AZ-900
Deep Dive
Nube pública, privada, híbrida y multi-cloud. Cuándo elegir cada una, qué servicios de Azure aplican a cada modelo y las trampas de examen más comunes.
Contenido
El AZ-900 evalúa 4 modelos. Muchos estudiantes solo estudian 3 (público, privado, híbrido) y pierden preguntas sobre multi-cloud.
Nube Pública
Infraestructura operada por un proveedor de cloud de terceros (Microsoft, AWS, Google) y entregada por internet. Recursos compartidos entre múltiples clientes (multi-tenant) aunque lógicamente aislados.
Ejemplos
Mejor para
La mayoría de empresas. Default para nuevos proyectos.
Nube Privada
Infraestructura de cloud usada exclusivamente por una organización. Puede estar físicamente en las instalaciones de la empresa (on-premises) o en un datacenter de terceros, pero los recursos NO se comparten con otros.
Ejemplos
Mejor para
Compliance ultra-estricto, performance predecible, control total.
Nube Híbrida
Combinación de nube pública y privada (o on-premises) conectadas, que permite compartir datos y aplicaciones entre ellas. La aplicación puede "bursting" hacia nube pública cuando la privada se satura.
Ejemplos
Mejor para
Migraciones graduales, compliance con burst capacity, apps legacy + nuevas.
Multi-cloud
Uso deliberado de servicios de dos o más proveedores de cloud público. No es lo mismo que híbrido — es múltiples nubes públicas (ej: Azure + AWS). Puede incluir también nube privada.
Ejemplos
Mejor para
Evitar vendor lock-in, aprovechar mejores servicios por proveedor.
¿Qué significa realmente "multi-tenant"?
Tu VM en Azure corre en el mismo servidor físico que VMs de otras empresas (quizás competidores). El hipervisor Hyper-V las aísla completamente a nivel de hardware. Tú no puedes acceder a sus datos ni ellos a los tuyos. Pero comparten: CPU threads (limitados por vCPU quota), memoria física (limitada por RAM asignada), y el mismo disco físico NVMe (aunque volúmenes separados).
Ventajas reales de multi-tenant
Riesgos y limitaciones de multi-tenant
Solución al noisy neighbor: Azure Dedicated Hosts
Si necesitas hardware físico exclusivo en nube pública → Azure Dedicated Hosts. Pagas por el host completo, solo tus VMs corren en él. Precio: ~$3-8/hora por host físico completo. Cumple requisitos de compliance que exigen hardware no compartido.
"Nube privada" no significa solo servidores en tu oficina. Hay múltiples arquitecturas posibles.
On-premises tradicional
Tu propio datacenter, tus propios servidores, tu propio hypervisor (VMware, Hyper-V, OpenStack). Máximo control, máxima responsabilidad.
Ventajas
Limitaciones
Relación con Azure
Puedes extender Azure a tu on-premises con Azure Arc
Azure Stack HCI
Hardware certificado por Microsoft que corre en tus instalaciones, gestionado como Azure desde el portal de Azure. Tienes las APIs de Azure, el modelo de Azure, pero el hardware está donde tú digas.
Ventajas
Limitaciones
Relación con Azure
Es un producto de Microsoft — literalmente Azure en tu datacenter
Colocation (colo)
Tu hardware en el datacenter de un tercero (Equinix, NTT, Tier 4 providers). Tú posees el hardware; el datacenter te da espacio, electricidad, cooling y conectividad.
Ventajas
Limitaciones
Relación con Azure
Puedes conectar colo a Azure via ExpressRoute para conectividad privada de alta velocidad
La nube híbrida es la más común en empresas enterprise que llevan años con infraestructura on-premises. Microsoft ofrece herramientas específicas para este modelo.
Azure Arc — Extiende Azure a cualquier lugar
Azure Arc permite gestionar servidores, Kubernetes clusters, bases de datos SQL y servicios de Azure en cualquier nube o on-premises, desde el portal de Azure, con las mismas herramientas.
Servidores on-prem Linux/Windows
Aparecen en Azure Portal como recursos. Azure Monitor, Defender, Updates aplican.
Kubernetes clusters en AWS/GCP
Gestionados desde Azure. GitOps, políticas Azure Policy aplicadas.
SQL Server on-premises
Azure Arc-enabled SQL → telemetría, assessments, Defender for SQL.
Azure services anywhere
App Service, Kubernetes, Data Services en tu hardware, gestionados por Azure.
Casos de uso reales de nube híbrida
Conectividad híbrida en Azure
Azure VPN Gateway
Conexión VPN encriptada over internet. Económica, hasta ~1 Gbps. Para híbrido sin SLA estricto.
Azure ExpressRoute
Conexión privada dedicada (no por internet) via partner de telecomunicaciones. 1–100 Gbps. SLA garantizado. Para workloads críticos.
Según Flexera 2024, el 89% de las empresas grandes usan múltiples clouds. Multi-cloud ya no es opcional para muchas organizaciones.
¿Por qué las empresas usan multi-cloud?
Evitar vendor lock-in
No depender de un solo proveedor para negociar mejores precios y no quedar vulnerable si el proveedor sube precios.
Best-of-breed por servicio
AWS Kinesis para streaming, Azure OpenAI para IA, Google BigQuery para analytics. Usar el mejor servicio de cada proveedor.
Adquisiciones corporativas
Empresa A usa Azure. Adquiere empresa B que usa AWS. Multi-cloud por defecto.
Requisitos regulatorios
Algunos países requieren usar cloud providers locales o específicos para ciertos datos.
Redundancia inter-proveedor
Si Azure tiene outage regional, failover a AWS. La probabilidad de que ambos fallen simultáneamente es extremadamente baja.
Equipo con expertise múltiple
Empresa tiene devs con AWS expertise y otros con Azure. Cada equipo usa lo que conoce mejor.
Complejidad del multi-cloud
Multi-cloud no es gratis de complejidad. Cada cloud tiene su propio: modelo IAM, CLI/APIs, networking, monitoreo, compliance. Necesitas equipos que dominen múltiples plataformas. Los costos de egress entre clouds pueden ser significativos. La gobernanza se vuelve compleja. Azure Arc puede gestionar recursos de otros clouds desde Azure — una forma de reducir esta complejidad.
| Dimensión | Pública | Privada | Híbrida | Multi-cloud |
|---|---|---|---|---|
| Costo inicial | 0 | Muy alto | Medio | 0 (por cloud) |
| Control de hardware | Ninguno | Total | Mixto | Ninguno |
| Escalabilidad | Ilimitada | Limitada a HW | Mixta | Ilimitada (multi) |
| Gestión operativa | Baja | Muy alta | Alta | Muy alta |
| Costo long-term | Variable | Fijo (alto) | Variable+fijo | Variable (múltiple) |
| Seguridad física | Del proveedor | Tuya | Mixta | De cada proveedor |
| Tiempo de setup | Minutos | 3-12 meses | 2-6 meses | Meses (governance) |
| Vendor lock-in | Alto (1 vendor) | Tuyo propio | Parcial | Bajo |
| Complejidad | Baja | Alta (tuya) | Alta | Muy alta |
| Compliance data residency | Depende región | Total control | Flexible | Multi-jurisdicción |
| Mejor para startups | ✓✓✓ | ✗ | ✗ | ✗ |
| Mejor para enterprise legacy | ✓ | ✓✓ | ✓✓✓ | ✓✓ |
¿Tienes requisitos regulatorios que exigen hardware FÍSICAMENTE en tus instalaciones?
¿Tienes infraestructura legacy que no puedes mover a cloud a corto plazo?
¿Tu empresa ya tiene inversión significativa en otro proveedor cloud (AWS, GCP)?
¿Necesitas servicios específicos que solo ofrece otro proveedor (ej: BigQuery, AWS Redshift)?
¿Ninguna de las anteriores?
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa del sector salud necesita cumplir regulaciones estrictas sobre dónde residen sus datos y no puede usar infraestructura compartida. ¿Qué modelo de nube debe elegir?