Guía

Autenticación de identidad híbrida donde los hashes de contraseña deben permanecer on-premise, con conmutación por error.

→Azure AD Connect con Autenticación de Paso (PTA) y Sincronización de Hash de Contraseña (PHS) habilitadas como copia de seguridad.

Por qué: PTA mantiene los hashes on-premise al validar contra el AD local. PHS proporciona conmutación por error de autenticación si el AD on-premise o el agente Connect no están disponibles.

Referencia↗

Implementar Zero Trust aplicando control de acceso granular basado en el usuario, la ubicación, el estado del dispositivo y el riesgo.

→Políticas de Acceso Condicional de Microsoft Entra que combinan Ubicaciones Nombradas, cumplimiento de dispositivos (Intune) y riesgo de inicio de sesión (Identity Protection) con controles de concesión como MFA.

Por qué: El Acceso Condicional es el motor de aplicación de Zero Trust, evaluando múltiples señales por solicitud antes de conceder acceso. Una única política no puede aplicar diferentes controles a diferentes condiciones.

Referencia↗

Aplicar políticas consistentes (por ejemplo, etiquetado, regiones permitidas) en docenas o cientos de suscripciones.

→Una jerarquía de grupos de administración con iniciativas de Azure Policy asignadas a nivel del grupo de administración raíz o padre.

Por qué: Los Grupos de Administración proporcionan un ámbito de gobernanza por encima de las suscripciones, permitiendo que las políticas se hereden. Las iniciativas agrupan múltiples políticas para una asignación simplificada.

Referencia↗

Proporcionar a los administradores acceso privilegiado just-in-time (JIT) con flujos de trabajo de aprobación y auditoría.

→Microsoft Entra Privileged Identity Management (PIM) para hacer que los usuarios sean elegibles para roles en lugar de estar permanentemente activos.

Por qué: PIM aplica el principio de menor privilegio al requerir que los usuarios activen roles por un período de tiempo limitado, con MFA opcional, justificación y aprobación, creando una pista de auditoría completa.

Referencia↗

Recopilar registros de todos los recursos de Azure en múltiples suscripciones para análisis y consultas centralizadas.

→Un único espacio de trabajo centralizado de Log Analytics con RBAC de contexto de recurso para control de acceso.

Por qué: Un espacio de trabajo centralizado permite consultas entre suscripciones, simplifica la administración y evita la duplicación de datos. RBAC de contexto de recurso asegura que los usuarios solo consulten registros de recursos a los que tienen acceso.

Un recurso de Azure (por ejemplo, App Service, Function, VM) necesita acceder de forma segura a otros recursos de Azure (Key Vault, SQL, Storage) sin credenciales almacenadas.

→Asignar una identidad administrada (asignada por el sistema o por el usuario) al recurso de cómputo y concederle roles RBAC en los recursos de destino.

Por qué: Las identidades administradas eliminan la gestión de credenciales (secretos, certificados), gestionando automáticamente la adquisición y rotación de tokens. Use las asignadas por el usuario para compartir una identidad en múltiples recursos.

Referencia↗

Remediar automáticamente los recursos de Azure existentes y no conformes identificados por una Azure Policy.

→Utilice un efecto de política "DeployIfNotExists" o "Modify". Para los recursos existentes, se debe crear una tarea de remediación para la asignación de políticas, lo que requiere una identidad administrada con permisos suficientes.

Por qué: Las políticas con estos efectos solo se aplican a los recursos nuevos/actualizados por defecto. Se requiere una tarea de remediación para escanear y corregir los recursos existentes no conformes.

Aplicar etiquetas obligatorias en todos los recursos y heredar automáticamente etiquetas (por ejemplo, CostCenter) del grupo de recursos padre.

→Utilice una Azure Policy con un efecto "Deny" para las etiquetas obligatorias y una política separada con un efecto "Modify" para heredar etiquetas del grupo de recursos si faltan.

Por qué: Deny aplica el cumplimiento en la creación. El efecto Modify automatiza la propagación de etiquetas, reduciendo el esfuerzo manual y asegurando la consistencia.

Monitorizar una aplicación de múltiples niveles o microservicios para rastrear transacciones de extremo a extremo e identificar cuellos de botella de rendimiento.

→Instrumentar todos los servicios con Application Insights. Utilizar el Mapa de Aplicaciones para visualizar dependencias y el rastreo distribuido para el análisis de solicitudes de extremo a extremo.

Por qué: Application Insights es la solución APM nativa que correlaciona automáticamente la telemetría entre componentes para proporcionar una vista unificada de una transacción, señalando problemas de latencia.

Gobernar el acceso para socios externos, incluyendo solicitudes, aprobaciones, acceso por tiempo limitado y revisiones periódicas.

→Administración de derechos de Microsoft Entra ID Governance. Crear paquetes de acceso que agrupen recursos, definan flujos de trabajo de aprobación, establezcan políticas de vencimiento y programen revisiones de acceso.

Por qué: Proporciona un ciclo de vida completo y automatizado para el acceso externo, reduciendo la sobrecarga administrativa y el riesgo de seguridad en comparación con la gestión manual de cuentas de invitado.

Un proveedor de servicios gestionados o un equipo central de TI necesita gestionar recursos en múltiples inquilinos de Azure AD de clientes/departamentos.

→Azure Lighthouse. Incorporar suscripciones de clientes para conceder al inquilino gestor acceso delegado con roles RBAC específicos.

Por qué: Lighthouse proporciona un único plano de control para la gestión entre inquilinos sin cambiar de directorios ni gestionar cuentas de invitado, mientras el cliente conserva el control y la propiedad total.

Proporcionar acceso remoto seguro a una aplicación web on-premise para usuarios externos sin una VPN o exponer la aplicación a internet.

→Microsoft Entra Application Proxy.

Por qué: Application Proxy utiliza un conector on-premise ligero que establece una conexión saliente a Azure. Actúa como un proxy inverso, permitiendo la preautenticación de Entra ID y un acceso seguro sin reglas de firewall entrantes ni una IP pública en la aplicación.

Una aplicación distribuida globalmente requiere una base de datos con latencia de lectura/escritura inferior a 10 ms, esquema flexible y 99.999% de disponibilidad.

→Azure Cosmos DB con escrituras multi-región habilitadas. La clave de partición debe elegirse para distribuir la carga de trabajo de manera uniforme.

Por qué: Cosmos DB está diseñado específicamente para la distribución global con escrituras multi-región "llave en mano", proporcionando baja latencia garantizada y el SLA de mayor disponibilidad. Otras bases de datos requieren replicación manual y no pueden igualar la latencia de escritura.

Ingerir telemetría IoT de alto volumen en Cosmos DB, permitiendo consultas eficientes por dispositivo y archivado automático de datos antiguos.

→Utilice `/deviceId` como clave de partición. Configure TTL en el contenedor para eliminar automáticamente documentos antiguos. Utilice Change Feed para capturar datos antes de la eliminación para archivarlos en almacenamiento frío (por ejemplo, Blob Storage).

Por qué: La partición por `deviceId` co-localiza datos para un solo dispositivo, haciendo las consultas eficientes. TTL proporciona eliminación automática y gratuita. Change Feed habilita una tubería de archivado reactiva.

Seleccionar un modelo de precios rentable de Azure SQL DB para una carga de trabajo con tráfico impredecible, en ráfagas y períodos de inactividad significativos.

→Utilice el modelo basado en vCore con el nivel de cómputo Serverless.

Por qué: Serverless escala automáticamente el cómputo según la demanda y se pausa automáticamente durante los períodos de inactividad, cobrando solo por el cómputo utilizado por segundo. Esto es mucho más rentable para cargas de trabajo intermitentes que los niveles aprovisionados.

Una solución de almacenamiento para una plataforma de análisis de datos a gran escala que requiere un espacio de nombres jerárquico y ACLs a nivel de directorio.

→Azure Data Lake Storage Gen2 (una cuenta con espacio de nombres jerárquico habilitado).

Por qué: ADLS Gen2 está optimizado para el análisis de big data, combinando la escalabilidad del almacenamiento de objetos con un verdadero sistema de archivos jerárquico y ACLs compatibles con POSIX para una seguridad granular.

Elegir la redundancia de almacenamiento basándose en requisitos por niveles: máxima durabilidad con acceso de lectura, solo DR y protección contra fallos de centros de datos dentro de la región.

→1. Máxima durabilidad/lectura: RA-GZRS. 2. Solo DR: GRS. 3. En la región: ZRS.

Por qué: Haga coincidir la opción de redundancia con el RPO/RTO específico y las necesidades de acceso. RA-GZRS es el nivel más alto. GRS es solo para conmutación por error. ZRS protege contra fallos de centros de datos dentro de una región.

Consultar grandes volúmenes de datos estructurados en un almacén de datos y datos semiestructurados en un data lake utilizando una plataforma de análisis unificada.

→Azure Synapse Analytics. Utilice un pool de SQL dedicado para los datos estructurados y un pool de SQL sin servidor para consultas ad-hoc en el data lake.

Por qué: Este enfoque híbrido optimiza tanto el rendimiento como el costo. El pool dedicado proporciona alto rendimiento para el almacén de datos gestionado, mientras que el pool sin servidor proporciona acceso de pago por consulta a los datos brutos en el data lake.

Una solución de caché para el estado de sesión y datos de productos que requiere más de 100 GB de memoria y alta disponibilidad.

→Azure Cache for Redis Enterprise o nivel Premium con clustering habilitado.

Por qué: El clustering en los niveles Premium/Enterprise permite que la caché escale más allá de los límites de memoria de un solo nodo al fragmentar los datos en múltiples nodos, mejorando también el rendimiento.

Una arquitectura de base de datos para una aplicación SaaS que aísla a los inquilinos mientras optimiza los costos para muchas cargas de trabajo pequeñas y con picos.

→Azure SQL Elastic Pools. Agrupar inquilinos en pools para compartir recursos, con bases de datos dedicadas para inquilinos grandes o "vecinos ruidosos".

Por qué: Los pools elásticos proporcionan los beneficios de costo del intercambio de recursos mientras aplican límites de rendimiento por base de datos, ofreciendo un equilibrio entre el problema del "vecino ruidoso" y el alto costo de una base de datos por inquilino.

Migrar una base de datos SQL Server on-premise compleja que utiliza características como SQL Agent, consultas entre bases de datos y CLR a un servicio PaaS.

→Azure SQL Managed Instance.

Por qué: SQL Managed Instance ofrece una compatibilidad cercana al 100% con el motor de SQL Server on-premise, soportando características a nivel de instancia que Azure SQL Database no. Esto es ideal para lift-and-shift con cambios mínimos de código.

Asegurar que todos los datos y las claves de cifrado gestionadas por el cliente permanezcan dentro de un límite geográfico específico (por ejemplo, la UE).

→Implementar todos los recursos en regiones dentro del límite. Utilizar una Azure Policy con el efecto "Ubicaciones permitidas" para aplicar esto. Almacenar las claves de cifrado gestionadas por el cliente (CMK) en un Azure Key Vault también ubicado dentro del límite.

Por qué: Se requiere una combinación de ubicación de implementación física, aplicación basada en políticas y residencia de claves para cumplir con estrictas regulaciones de soberanía de datos.

Descubrir, clasificar y rastrear el linaje de datos en un entorno de datos híbrido (Azure, on-premise, otras nubes).

→Microsoft Purview.

Por qué: Purview proporciona una solución unificada de gobernanza de datos con escaneo automatizado, un glosario de negocio, clasificación y seguimiento de linaje en una amplia gama de fuentes de datos.

Almacenar datos (por ejemplo, registros financieros) en un estado no borrable y no modificable (WORM) durante un período de retención definido.

→Azure Blob Storage con una política inmutable basada en tiempo en el contenedor, que luego se bloquea.

Por qué: Las políticas inmutables bloqueadas evitan la eliminación o modificación de blobs por parte de cualquier usuario, incluidos los administradores, hasta que expire el período de retención, cumpliendo con estrictos requisitos de cumplimiento normativo.

Diseñar una solución de DR para una aplicación web (App Service + SQL DB) con un RPO de minutos y un RTO inferior a una hora.

→Grupo de conmutación automática por error de Azure SQL Database, una implementación secundaria de App Service y Azure Front Door o Traffic Manager para el enrutamiento.

Por qué: Este patrón aborda la DR para cada nivel. El grupo de conmutación por error de SQL gestiona la replicación y conmutación por error de datos. El App Service preimplementado evita retrasos en la implementación. Un enrutador global (Front Door/Traffic Manager) dirige el tráfico a la región activa.

El SLA compuesto de una aplicación en serie (A -> B -> C) es demasiado bajo. ¿Cómo se mejora?

→Identificar el componente con el SLA individual más bajo (el "eslabón más débil") y hacerlo redundante implementando instancias paralelas (por ejemplo, en varias regiones o zonas con un balanceador de carga).

Por qué: El SLA compuesto para una cadena en serie se calcula multiplicando los SLAs (SLA_A * SLA_B * SLA_C). Añadir instancias paralelas a un componente mejora su SLA efectivo, lo que tiene el mayor impacto positivo en el compuesto.

Lograr la mayor disponibilidad posible para VMs dentro de una única región de Azure.

→Implementar múltiples VMs en todas las Zonas de Disponibilidad disponibles en la región.

Por qué: Las Zonas de Disponibilidad son centros de datos físicamente separados con energía, refrigeración y redes independientes. Esto protege contra fallos a nivel de centro de datos y proporciona el SLA más alto dentro de la región del 99.99%.

Proporcionar una solución de recuperación ante desastres para máquinas virtuales VMware o Hyper-V on-premise a Azure.

→Azure Site Recovery (ASR). Configurar la replicación a Azure, crear planes de recuperación para la conmutación por error orquestada y usar conmutaciones por error de prueba para simulacros de DR no disruptivos.

Por qué: ASR es el servicio de Azure diseñado específicamente para la replicación de DR de VMs on-premise (y de Azure), proporcionando replicación continua, recuperación orquestada y capacidades de prueba aisladas.

Lograr la mayor disponibilidad en la región para Azure SQL Database con cero pérdida de datos (RPO=0) y capacidad de escalado de lectura.

→Utilice el nivel de servicio Business Critical con redundancia de zona habilitada.

Por qué: El nivel Business Critical utiliza un grupo de disponibilidad Always On con replicación síncrona en múltiples réplicas, proporcionando un RPO de 0. La redundancia de zona coloca réplicas en diferentes AZs para un SLA del 99.995%. Incluye una réplica secundaria legible.

Una aplicación global debe atender a los usuarios desde la región más cercana y conmutar por error de forma automática e instantánea.

→Utilice un patrón de implementación activo-activo en múltiples regiones con Azure Front Door para enrutamiento basado en latencia y conmutación por error basada en sondeo de estado.

Por qué: Azure Front Door proporciona enrutamiento global anycast al backend de menor latencia. Sus sondeos de estado detectan fallos regionales y redirigen automáticamente el tráfico a regiones saludables en segundos, permitiendo una arquitectura activo-activo sin interrupciones.

Realizar copias de seguridad de aplicaciones con estado en AKS, incluyendo tanto las definiciones de objetos de Kubernetes como los datos de volumen persistente.

→Utilice Azure Backup para AKS.

Por qué: Azure Backup para AKS es la solución nativa que proporciona copias de seguridad integradas y basadas en políticas tanto para el estado del clúster (etcd) como para los datos de volumen persistente (a través de instantáneas CSI) en un Backup Vault seguro y centralizado.

Proteger las copias de seguridad de la eliminación accidental o maliciosa, incluso por parte de los administradores, para el cumplimiento normativo.

→Habilitar vaults inmutables en el vault de Azure Backup o Recovery Services.

Por qué: La inmutabilidad es una configuración a nivel de vault que asegura que los puntos de recuperación de la copia de seguridad, una vez creados, no pueden ser eliminados por nadie antes de su fecha de caducidad, proporcionando el nivel más alto de protección de la copia de seguridad.

Un App Service Environment v3 (ASEv3) aloja una aplicación crítica en una región y requiere una solución de DR en otra región.

→Implementar un segundo ASEv3 en la región de DR. Utilizar Azure Front Door para balanceo de carga global y conmutación por error. Replicar datos utilizando la tecnología adecuada (por ejemplo, grupos de conmutación automática por error de SQL).

Por qué: Los ASEv3 son implementaciones regionales. Para DR, debe implementar un segundo ASE y utilizar un enrutador global como Front Door para gestionar el tráfico. ASR no se utiliza para DR de App Service.

Diseñar una red escalable para una empresa con conectividad centralizada (ExpressRoute/VPN), servicios compartidos y aislamiento de cargas de trabajo.

→Una topología hub-and-spoke. La VNet del hub contiene la puerta de enlace, Azure Firewall y otros servicios compartidos. Las VNets spoke contienen cargas de trabajo de aplicaciones y están emparejadas con el hub.

Por qué: Este es el patrón empresarial estándar y recomendado. Centraliza la seguridad y la conectividad, reduciendo costos y complejidad, mientras que los spokes proporcionan un fuerte aislamiento de las cargas de trabajo.

Una aplicación web global necesita balanceo de carga de Capa 7, un Firewall de Aplicaciones Web (WAF), descarga SSL y enrutamiento basado en URL.

→Azure Front Door (Estándar o Premium).

Por qué: Front Door es un CDN en la nube moderno y un balanceador de carga global que integra estas capacidades en un único servicio, proporcionando un mejor rendimiento y una gestión más sencilla que combinar Traffic Manager con Application Gateways regionales.

Diseñar un clúster AKS de grado de producción para múltiples equipos con diferentes tipos de cargas de trabajo (CPU, GPU, intensivas en memoria).

→Utilice un pool de nodos de sistema dedicado y múltiples pools de nodos de usuario con diferentes SKUs de VM (por ejemplo, F-series para CPU, E-series para memoria, N-series para GPU). Utilice el autoescalador de clúster y habilite el nivel Estándar/Premium para el SLA de tiempo de actividad.

Por qué: Múltiples pools de nodos permiten hacer coincidir el hardware correcto con la carga de trabajo adecuada para el rendimiento y la eficiencia de costos. La separación de los pods del sistema mejora la estabilidad. El nivel Estándar/Premium es necesario para un SLA respaldado financieramente.

Un flujo de trabajo sin servidor impulsado por eventos requiere tiempos de ejecución superiores al límite de 10 minutos del plan de Consumo de Functions.

→Utilice Azure Functions en un plan Premium o un plan de App Service, o utilice Azure Durable Functions para la orquestación.

Por qué: El plan Premium admite la ejecución de hasta 60 minutos (30 por defecto) y evita los arranques en frío. Durable Functions son ideales para orquestar flujos de trabajo de larga duración y con estado que pueden implicar interacción humana o largas esperas.

Elegir un servicio de mensajería para un sistema de notificación de eventos fan-out frente a un sistema de procesamiento de comandos fiable y ordenado.

→Utilice Azure Event Grid para eventos fan-out y reactivos. Utilice Azure Service Bus Queues (con sesiones para el orden) para el procesamiento de comandos transaccional y fiable.

Por qué: Event Grid es un servicio de enrutamiento de eventos ligero y basado en push optimizado para la programación reactiva. Service Bus es un broker de mensajes robusto con características como FIFO (sesiones), dead-lettering y transacciones para la mensajería empresarial.

Exponer una API que se ejecuta en una VNet privada a socios externos de forma segura, con políticas de limitación de velocidad y autenticación.

→Implementar Azure API Management (APIM) en modo VNet interna, con un Azure Application Gateway con WAF para la entrada pública.

Por qué: Este patrón proporciona defensa en profundidad. APIM en la VNet puede acceder al backend privado. El App Gateway termina SSL, inspecciona el tráfico con WAF y lo reenvía a la instancia privada de APIM. Las políticas de APIM gestionan la autenticación, los límites de velocidad, etc.

Conectar cientos de sucursales y VNets globalmente con conectividad automatizada, de cualquier a cualquier.

→Azure Virtual WAN.

Por qué: Virtual WAN es la solución administrada de Microsoft para redes de tránsito globales a gran escala. Automatiza el enrutamiento complejo y proporciona un hub unificado para conectar VPN, ExpressRoute y spokes de VNet.

Ejecutar un trabajo por lotes paralelo a gran escala (por ejemplo, simulación CFD) que requiere miles de núcleos y comunicación MPI de baja latencia.

→Azure Batch con un pool de VMs habilitadas para InfiniBand (por ejemplo, serie HB) utilizando precios de baja prioridad (Spot).

Por qué: Azure Batch es un programador de trabajos diseñado para HPC. Las VMs habilitadas para InfiniBand proporcionan la red RDMA de alto rendimiento y baja latencia requerida para MPI. Las VMs de baja prioridad reducen drásticamente el costo para cargas de trabajo tolerantes a fallos.

Una aplicación en una VNet necesita acceder a servicios PaaS (SQL, Storage) sin que el tráfico atraviese la internet pública.

→Crear Private Endpoints para los servicios PaaS. Esto asigna al servicio una dirección IP privada dentro de su VNet.

Por qué: Private Endpoints son el método más seguro para la conectividad PaaS privada. Aseguran que el tráfico permanezca en la red troncal de Microsoft y le permiten deshabilitar completamente el endpoint público del servicio PaaS.

Alojar una aplicación de página única (SPA) moderna con un backend de API sin servidor, integración CI/CD y un dominio personalizado.

→Azure Static Web Apps.

Por qué: Este es un servicio simplificado y diseñado específicamente para este patrón. Combina el alojamiento de contenido estático, Azure Functions integrado para la API, integración con GitHub/Azure DevOps y dominios personalizados gestionados con certificados SSL gratuitos.

Administrar y aplicar gobernanza (Azure Policy) a servidores que se ejecutan on-premise y en otras nubes (por ejemplo, AWS) desde Azure.

→Instalar el agente de Azure Arc en los servidores que no son de Azure para proyectarlos como servidores habilitados para Azure Arc.

Por qué: Azure Arc extiende el plano de control de Azure a cualquier infraestructura. Una vez que un servidor está habilitado para Arc, puede ser administrado con Azure Policy, Monitor, Defender for Cloud, etc., al igual que una VM nativa de Azure.

Migrar incrementalmente la funcionalidad de una aplicación monolítica heredada a nuevos microservicios sin una migración "big bang".

→Aplicar el patrón Strangler Fig utilizando un proxy inverso como Azure API Management o Application Gateway.

Por qué: El proxy inverso intercepta las llamadas al monolito y enruta selectivamente el tráfico para características específicas a los nuevos microservicios. Con el tiempo, el proxy "estrangula" el monolito redirigiendo cada vez más tráfico hasta que el sistema antiguo pueda ser retirado.

Las VMs están en una VNet con tunelización forzada (todo el tráfico de internet enrutado on-premise), pero no pueden acceder a los servicios PaaS de Azure.

→La tunelización forzada interrumpe el acceso directo a los endpoints públicos de Azure. Utilice service endpoints o private endpoints para el acceso a PaaS. Alternativamente, añada UDRs para service tags específicos de Azure con un próximo salto de "Internet" para evitar el túnel.

Por qué: Los servicios PaaS tienen endpoints públicos. La tunelización forzada envía ese tráfico on-premise. Debe crear una ruta de excepción, ya sea haciendo que el servicio PaaS sea privado (endpoints) o creando excepciones de ruta específicas (UDRs con service tags).

Una red hub-spoke necesita resolver nombres DNS on-premise desde Azure, y zonas DNS privadas de Azure desde on-premise.

→Implementar Azure DNS Private Resolver en la VNet del hub. Configurar un endpoint de entrada para que on-premise resuelva DNS de Azure, y un endpoint de salida con conjuntos de reglas de reenvío para resolver DNS on-premise desde Azure.

Por qué: Esta es la solución PaaS moderna para la resolución DNS híbrida, que reemplaza la necesidad de administrar VMs de servidor DNS personalizados. Se integra de forma nativa con zonas DNS privadas y reenviadores DNS on-premise.

Múltiples VNets necesitan una IP pública estática y predecible para todo el tráfico saliente para el whitelisting por servicios externos.

→En una topología hub-spoke, enrutar todo el tráfico saliente (0.0.0.0/0) desde los spokes a través de un Azure Firewall o NAT Gateway en la VNet del hub.

Por qué: La centralización de la salida en el hub asegura que todo el tráfico saliente utilice las IPs públicas del firewall/NAT Gateway del hub, simplificando la gestión y el whitelisting externo. NAT Gateway es más simple para SNAT puro, mientras que Firewall añade inspección de seguridad.

Procesar datos altamente sensibles de manera que estén cifrados incluso mientras se utilizan en memoria, protegiéndolos del operador de la nube.

→Utilice VMs de Azure Confidential Computing (series DCsv3/ECsv3) con Intel SGX o AMD SEV-SNP para ejecutar código en un Entorno de Ejecución Confiable (TEE) basado en hardware o memoria cifrada.

Por qué: Confidential Computing aborda el pilar de seguridad de "datos en uso", que el cifrado tradicional en reposo y en tránsito no. Proporciona aislamiento verificable a nivel de hardware.

Un proveedor SaaS necesita exponer su servicio, ejecutándose en su VNet, a un cliente en la VNet del cliente, completamente sobre la red privada de Azure.

→El proveedor crea un Azure Private Link Service en su Standard Load Balancer. El cliente crea un Private Endpoint en su VNet que se conecta al servicio.

Por qué: Private Link es el patrón definitivo para la exposición de servicios segura, privada y entre inquilinos. Evita la exposición a internet pública, problemas de solapamiento de IP y configuraciones complejas de peering de VNet.