Estrategias multinube con Azure

La multinube consiste en operar cargas de trabajo en más de un proveedor de nube; por ejemplo, usar Azure para la mayoría de los servicios y AWS para una plataforma específica de aprendizaje automático, o Google Cloud para análisis con BigQuery. Las organizaciones adoptan la multinube para evitar la dependencia del proveedor, aprovechar los servicios líderes de cada proveedor, cumplir requisitos contractuales o normativos que eviten depender de un único proveedor, o porque las fusiones y adquisiciones reunieron empresas que habían estandarizado sus operaciones en nubes diferentes. Actualmente, la multinube es la norma en las grandes empresas.

La multinube introduce importantes desafíos operativos: dispersión de conocimientos: los equipos necesitan experiencia en varias plataformas de nube. Gobernanza incoherente: cada nube tiene herramientas diferentes de IAM, directivas y cumplimiento. Complejidad de la seguridad: distintos modelos de amenazas, servicios de seguridad y registros de auditoría. Gestión de costes: portales de facturación independientes, diferentes unidades de tarificación y ninguna vista unificada de los costes entre proveedores. Complejidad de red: el tráfico entre nubes genera costes de salida y latencia. Microsoft aborda muchos de estos desafíos con Azure Arc y la compatibilidad multinube de Defender for Cloud.

El mismo agente de máquina conectada de Azure Arc que incorpora servidores locales también funciona en máquinas virtuales que se ejecutan en AWS EC2, Google Cloud Compute Engine o cualquier otra nube. Una vez registradas en Arc, estas máquinas virtuales aparecen junto a los recursos nativos de Azure en el portal de ARM. Puede aplicar Azure Policy, usar Azure Monitor con las mismas consultas KQL y consultar las recomendaciones de seguridad de Defender for Cloud para máquinas virtuales de AWS y GCP, sin salir del portal de Azure ni aprender herramientas específicas de AWS.

Microsoft Defender for Cloud admite conectores nativos para AWS y Google Cloud Platform. Al conectar su cuenta de AWS o proyecto de GCP, Defender for Cloud puede evaluar la posición de seguridad de instancias EC2, buckets de S3, bases de datos RDS y recursos de GCP mediante el mismo marco Secure Score que utiliza para Azure. Asocia los hallazgos con estándares como CIS AWS Foundations Benchmark y detecta configuraciones incorrectas —como buckets de S3 accesibles públicamente o roles de IAM con permisos excesivos— junto con las recomendaciones de Azure en un único panel.

Azure Cost Management + Billing puede incorporar los costes de AWS conectando su AWS Cost and Usage Report (CUR) a un Azure Connector. Esto muestra el gasto de AWS junto al de Azure en una vista unificada de análisis de costes, lo que permite comparar y asignar costes entre nubes. Puede crear presupuestos y alertas que abarquen ambos proveedores y aplicar la misma estrategia de etiquetado para la imputación informativa o la refacturación. Esta visibilidad de los costes multinube es valiosa para los equipos de FinOps que gestionan el gasto de varios proveedores desde un único panel.

Muchas estrategias multinube utilizan Kubernetes como capa de abstracción que se ejecuta de forma idéntica en cualquier nube. AKS en Azure, EKS en AWS y GKE en GCP ejecutan Kubernetes estándar. Azure Arc-enabled Kubernetes puede administrar todos ellos desde Azure, aplicando de forma coherente implementaciones basadas en GitOps y Azure Policy (OPA Gatekeeper). Las imágenes de contenedor almacenadas en Azure Container Registry se pueden extraer desde el clúster de Kubernetes de cualquier nube, lo que convierte a Azure ACR en un centro de registro de imágenes multinube natural.

Una Azure Landing Zone es un entorno preconfigurado que implementa prácticas recomendadas de gobernanza, identidad, seguridad y redes. Al adoptar la multinube, las organizaciones amplían el concepto de landing zone para definir estándares aplicables a todos los proveedores. El Cloud Adoption Framework (CAF) de Microsoft incluye orientación sobre multinube para estructurar jerarquías de grupos de administración, convenciones de nomenclatura y estrategias de etiquetado que funcionen de forma coherente, independientemente de que el recurso se encuentre en Azure, AWS o en un entorno local.

La conexión de cargas de trabajo de Azure y AWS (o GCP) requiere redes entre nubes. Patrones habituales: túneles VPN entre Azure VPN Gateway y AWS Virtual Private Gateway o GCP VPN: una opción sencilla, pero con ancho de banda limitado y latencia variable. SD-WAN de terceros (por ejemplo, Megaport o Equinix Fabric): crea circuitos privados entre nubes similares a ExpressRoute. Integración en la capa de aplicación: los servicios se comunican mediante HTTPS a través de puntos de conexión públicos (la opción más sencilla, pero utiliza Internet). Los costes del ancho de banda de salida en AWS y GCP encarecen las transferencias de datos entre nubes de gran volumen.

Microsoft Entra ID puede actuar como proveedor de identidad (IdP) para el acceso multinube. En AWS, puede configurar Entra ID as the SAML 2.0 IdP for AWS IAM Identity Center, lo que permite a los usuarios acceder a la consola de AWS con sus credenciales de Entra ID y MFA, sin usuarios de AWS IAM independientes. En GCP también es posible una federación similar. Esto centraliza la gobernanza de identidades: las altas, los cambios y las bajas se gestionan en Entra ID, y el acceso se propaga automáticamente a todos los proveedores de nube.

Las prácticas de FinOps (operaciones financieras en la nube) se vuelven más complejas en entornos multinube porque cada proveedor tiene modelos de precios, mecanismos de descuento y niveles de detalle de facturación diferentes. Prácticas recomendadas: estandarizar el etiquetado en todos los proveedores para asignar costes; usar el conector de AWS de Azure Cost Management + Billing para obtener una visibilidad unificada; establecer un equipo de FinOps que conozca las Reserved Instances (Azure), los Savings Plans (AWS/Azure) y los Committed Use Discounts (GCP); y realizar revisiones periódicas de costes entre proveedores para comparar el coste de cargas de trabajo equivalentes.

La multinube puede crear problemas si no se gestiona con cuidado. Antipatrones habituales que debe evitar: multinube accidental: usar varias nubes sin una estrategia provoca una dispersión y unos costes descontrolados. Exceso de exigencia sobre las habilidades: exigir que todos los ingenieros sean expertos en cada nube; en su lugar, designe responsables de cada plataforma. Seguridad incoherente: aplicar líneas base de seguridad diferentes en cada nube; use Azure Arc y Defender for Cloud para imponer la coherencia. Ignorar los costes de salida: las transferencias de datos entre nubes se cobran según las tarifas de salida del proveedor y pueden sorprender a los equipos de FinOps.

Ponga a prueba su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que Azure Arc amplía la administración de Azure a las máquinas virtuales de AWS y GCP mediante el mismo agente de máquina conectada; los conectores multinube de Microsoft Defender for Cloud muestran los hallazgos de seguridad entre proveedores en un Secure Score unificado; y la federación de Microsoft Entra ID permite el inicio de sesión único en las consolas de AWS y GCP desde una única identidad corporativa. Con esto finaliza el curso de Azure híbrido y multinube. A continuación se presenta Well-Architected Framework para evaluar y mejorar sus arquitecturas de Azure.