Azure
Por qué lo recomiendo como la entrada a la nube de menor fricción para empresas alineadas con Microsoft
He trabajado en AWS, Azure y GCP a profundidad de conocimiento práctico multi-cloud, no como especialista puro de Azure, pero lo suficiente en deployments reales para saber dónde la plataforma vale lo que cuesta y dónde la cadencia de renombres castiga a cualquiera que intente mantener la documentación al día. Este es el caso que les hago a los clientes que ya corren M365 y están evaluando cargas en la nube, y el sprawl de portales que ningún vendedor imprime en su brochure.
Por qué Azure funciona
Cuatro razones se sostienen en todos los deployments.
Entra ID es la capa de identidad de la nube
Un solo IDP para recursos de Azure, M365, SaaS de terceros (vía SCIM, SAML y OIDC) y on-prem (vía Entra Connect o Cloud Sync). El conditional access a nivel de plataforma aplica de la misma forma al acceso a recursos de Azure que al acceso a apps de M365, lo que significa un solo modelo de política, no dos.
El doloroso anti-patrón de "cada carga es dueña de su propio almacén de identidad" se disuelve una vez que Entra es la fuente de verdad. Un alta en RRHH, un offboard, todos los planos afectados.
Defender for Cloud y Sentinel como seguridad integrada
Defender for Cloud carga CSPM más detección de amenazas en runtime sobre VMs, contenedores y bases de datos, con precio por tier de recurso para que pagues por lo que realmente proteges. Sentinel corre como SIEM cloud-native con Azure Monitor y Log Analytics como columna, y las consultas nativas en KQL le ganan al grep crudo de logs por un margen amplio.
Entregarle a un auditor un secure score de Defender for Cloud más un log de incidentes de Sentinel más logs de sign-in de Entra cubre la mayor parte de un set de controles SOC 2 sin un SIEM de tercero. La plataforma está haciendo trabajo de auditoría por el que antes pagabas aparte.
Híbrido que de verdad existe (Azure Arc)
Los servidores y Kubernetes habilitados con Arc significan que recursos on-prem y de otras nubes aparecen en Azure RBAC, Policy y Monitor como si fueran nativos. Defender for Cloud se extiende a los recursos manejados por Arc, así que la vista de postura de seguridad se mantiene unificada en el híbrido en vez de fragmentarse por ambiente.
Manejar VMs on-prem más instancias EC2 de AWS más VMs de Azure desde una sola vista de Azure Policy es lo más cercano a un híbrido realmente unificado que he visto shippear. Las otras nubes hablan de híbrido; Arc lo hace.
Baseline de cumplimiento para industrias reguladas
Azure Government y Azure China cubren requisitos de nube soberana. Los baselines de FedRAMP High, HIPAA, PCI y GDPR son extensos. Microsoft Purview maneja clasificación de datos, DLP y retención sobre M365 y Azure desde una sola superficie de admin.
Para mid-market regulado en salud, finanzas y verticales adyacentes a gobierno, el baseline de cumplimiento de Azure es el camino de menor esfuerzo hacia listo-para-auditoría. El auditor ya vio los paquetes de evidencia de Microsoft antes.
Dónde encaja mejor
No para todas las empresas. El encaje es más nítido cuando uno de estos te describe:
Extendiéndose a cargas de nube cuando la identidad, el billing y el soporte ya están cableados a través de tu tenant existente de Microsoft. Agregar suscripciones de Azure encima de una huella de M365 existente es trabajo incremental, no una migración.
Arc maneja on-prem y multi-cloud de una forma que AWS no intenta igualar actualmente. Si tu realidad es "vamos a mantener la huella on-prem por años y agregar nube encima", la historia híbrida de Azure es la más honesta.
Salud, finanzas y empresas adyacentes a gobierno donde el baseline de cumplimiento carga peso real. Purview más Defender for Cloud más Compliance Manager cubren un pedazo significativo de la evidencia de auditoría de fábrica.
El mercado laboral de admins con skills de Azure es profundo donde sea que ya existan admins de M365. Contratar un AZ-104 en LATAM es una conversación distinta a contratar un especialista de Google Cloud de profundidad comparable.
Si no estás en M365 y no necesitas integración con el stack de Microsoft, AWS es la nube por defecto más defendible. Si no estás seguro si M365 en sí es el baseline correcto, arranca primero con la evaluación de Microsoft.
Los tradeoffs honestos
Marketing no va a imprimir estos. Yo sí, en producción. Toca para expandir.
Sprawl de portalesCinco portales, un tenant, ninguna memoria muscular se transfiere
Portal de Azure, portal de Entra, portal de Defender, portal de Intune, portal de Purview. Equipos distintos viven en blades distintos, la búsqueda se comporta diferente en cada uno, y las URLs cambian aproximadamente cada 18 meses mientras Microsoft reposiciona servicios. Marca como favoritos las URLs reales de los blades que tu equipo usa, documenta el camino en tus runbooks, y presupuesta tiempo para la próxima reorganización. Los portales son abordables individualmente; cambiar entre ellos es la fricción.
Renombres"Azure AD" → "Entra ID" → el próximo nombre, y la documentación se queda atrás
Azure AD se volvió Entra ID. AAD Connect se volvió Entra Connect, y luego Cloud Sync para deployments nuevos. Azure Sentinel se volvió Microsoft Sentinel. La cadencia de renombres no es por confusión gratuita; refleja a Microsoft reposicionando identidad y seguridad como capacidades de toda la plataforma en vez de productos específicos de Azure. Mantener el nombre canónico actual al día es overhead administrativo, y la documentación de terceros siempre va meses atrás del renombre.
Observabilidad de costosCost Management mejoró pero todavía va atrás de AWS Cost Explorer
La matemática de Reserved Instances vs Savings Plans vs Spot vs Pay-as-you-go vs Azure Hybrid Benefit no es trivial, y la mezcla correcta depende de la predictibilidad de la carga. El rollup de costos a nivel de suscripción vs a nivel de management group es una curva de aprendizaje en sí, y las vistas de Cost Management se sienten una generación atrás de lo que AWS shippó hace años. Configura alertas de Budgets al 50%, 80% y 100% antes de que aterrice la primera carga, y trata la primera revisión trimestral de la factura como obligatoria, no opcional.
Lock-in de plataformaIdentidad, seguridad y nube concentradas bajo un solo vendedor
Una vez que Entra ID es tu columna de identidad y Defender for Cloud es tu CSPM, salirse es un proyecto de varios trimestres. El mismo cálculo aplica al lock-in de AWS, pero con la dimensión adicional de que Microsoft es dueño de identidad, productividad Y nube en el mismo tenant. La concentración de poder de negociación del vendedor vale entrar con los ojos abiertos, no es una razón para evitar Azure pero sí una razón para diseñar el costo de salida en la revisión de arquitectura en vez de descubrirlo tres años después.
La fortaleza de Azure es el tejido de plataforma. El tradeoff es que el mismo tejido hace difícil salirse una vez que estás adentro.
¿Es lo correcto para tu empresa?
Cuatro dimensiones para revisar antes de comprometerte:
- Tamaño: 50–10.000+ empleados. Por debajo de 50, el overhead de Azure más allá de lo que un tenant de M365 Business Premium ya te da usualmente no vale el lift administrativo. Por encima de 10.000, la conversación necesita un Microsoft Partner con músculo real de entrega de Azure Landing Zone, no un consultor solo.
- Madurez de IT: Al menos un admin con baseline AZ-104 (Azure Administrator Associate) o dispuesto a invertir en ello. El arquitecto líder en una primera landing zone debería estar en el camino de AZ-305; las decisiones de diseño tomadas en la semana uno son caras de refactorizar una vez que las suscripciones de producción están en uso.
- Stack existente: Microsoft 365 más Entra ID es el mejor encaje. Empresas AWS-primero o GCP-primero enfrentan más fricción agregando Azure como nube secundaria, y la historia de integración no es lo suficientemente convincente por sí sola para justificar el segundo tenant a menos que haya una razón específica de carga de trabajo.
- Geografía: Global. LATAM tiene a Brazil South como ancla regional más una presencia menor de edge; México Central está en el roadmap publicado pero todavía no GA al momento de escribir esto. Las nubes soberanas de US Gov y Alemania importan para cargas reguladas específicas.
Si tres de las cuatro coinciden, Azure está en la shortlist. Si las cuatro coinciden, probablemente es la respuesta correcta.
Quién lo implementa
Internamente, el implementador líder debería ser un arquitecto de nube o ingeniero de sistemas senior con exposición real a Azure. AZ-104 es el baseline práctico para el equipo; AZ-305 (Azure Solutions Architect Expert) para el líder en trabajo de landing zone o Arc. Las decisiones a nivel de tenant y de estructura de suscripciones tomadas en la semana uno (jerarquía de management groups, modelo de RBAC, topología de red, políticas baseline) son caras de refactorizar una vez que las cargas de producción dependen de ellas.
La ayuda externa vale la pena para el primer build de landing zone. Un Microsoft Partner que ya haya shippeado deployments con el acelerador de Azure Landing Zone, baselines de gobierno y rollouts de Defender for Cloud varias veces te ahorra el costo de descubrimiento en las partes que se ven simples en los docs y no lo son en la práctica. Los partners CSP manejan el lado de billing y procurement, lo que importa en LATAM donde la facturación en moneda local y la negociación de margen de canal son parte de la conversación.
Si estás levantando tu primera landing zone de Azure o extendiendo un tenant existente de M365 a cargas de nube, hablemos. Arrancamos con una llamada de scoping de 30 minutos; si encaja, especificamos el engagement desde ahí.
Primeros pasos
- Lee primero la evaluación de Microsoft 365 + Entra ID + Intune. Azure encima de M365 es incremental; Azure sin M365 es más difícil de defender contra AWS. El broker de identidad, la relación de billing y el skill set de admin ya están en su lugar si M365 está corriendo. Si no lo están, la pregunta de la fundación va primero.
- Elige la carga de entrada y arranca con la fundación. Mi secuencia recomendada:
- VNets más topología Hub-Spoke. Baseline de networking antes de que aterricen las cargas. Las decisiones de topología son caras de deshacer.
- Entra ID más Entra Connect. Baseline de identidad, probablemente ya en su lugar desde M365. Confirma el alcance de sync y la postura de conditional access antes de agregar recursos de Azure.
- Defender for Cloud más Sentinel. Baseline de seguridad antes de escalar. Quieres el secure score visible el día que la primera VM arranca, no el día después del primer incidente.
- Cost Management más Budgets. Baseline financiero antes de la primera factura grande. Las alertas al 50%, 80% y 100% de la expectativa mensual no son opcionales.
- Usa el acelerador de Azure Landing Zone para el primer deployment. No hagas la fundación a mano. El acelerador captura años de guía de Microsoft más la comunidad sobre management groups, asignaciones de política y topología de red que de otro modo redescubrirías a las malas en producción.
Más allá de los primeros pasos: tomo trabajo de red, identidad y seguridad en Azure para clientes SMB y mid-market en LATAM y remoto globalmente. Hablemos de tu roadmap de nube. Te digo en 30 minutos si es trabajo de Azure, trabajo de AWS, o trabajo de “arregla lo que ya tienes”.