La lección anterior terminó con dos extremos sueltos, uno hacia dentro y otro hacia fuera. Hacia dentro: las oficinas de Barcelona y Palma siguen fuera de la red de Azure, el sistema de facturación heredado vive en un servidor del sótano de Barcelona, y Marta Ríos no puede administrar la plataforma desde casa sin exponer algo a internet. Hacia fuera: un cliente que compra un billete desde Sudamérica cruza el Atlántico en cada petición contra West Europe, y lo nota.

Ambos problemas son de conectividad, pero de signo opuesto. El primero se resuelve con conectividad híbrida: túneles cifrados o circuitos dedicados que unen la red local con la red virtual de Azure, de forma que 10.100.0.0/16 y 10.20.0.0/16 se comporten como una sola red. El segundo se resuelve con entrega global: servicios que ponen el contenido y la terminación de las conexiones cerca del cliente, esté donde esté.

Esta lección cierra el módulo 2 con ambas cosas y con un aviso que aparece en todas las facturas de Azure y que casi nadie anticipa: el coste de la salida de datos.

Aviso de coste importante: esta es la lección más cara del módulo. Una puerta de enlace de VPN se factura por hora desde que se crea, aunque no haya ni un túnel conectado, y tarda entre 20 y 45 minutos en desplegarse. ExpressRoute implica un contrato con un operador y no se prueba en un laboratorio. Front Door y CDN tienen coste por datos servidos. Despliega solo lo que vayas a usar y bórralo el mismo día.

1. El escenario híbrido de Contoso Airlines
2. VPN de punto a sitio: administrar desde casa
3. VPN de sitio a sitio: conectar Barcelona y Palma
4. Despliegue de la puerta de enlace con Azure CLI
5. ExpressRoute: cuándo justifica su precio
6. Azure Virtual WAN, a nivel conceptual
7. Entrega global: el cliente que compra desde Sudamérica
8. Azure Front Door, Azure CDN y Traffic Manager comparados
9. DNS público con Azure DNS
10. El coste de la salida de datos
11. Arquitectura final del módulo y limpieza
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Lo que queda en local después de la migración, y por qué:

Recuerda el plan de direccionamiento fijado en la lección anterior, porque la conectividad híbrida es donde ese plan demuestra su valor: Barcelona es 10.100.0.0/16, Palma 10.101.0.0/16, el concentrador de Azure 10.10.0.0/16 y producción 10.20.0.0/16. Nada se solapa, así que todo puede enrutarse.

Las tres opciones de conectividad, comparadas de un vistazo:

Una VPN de punto a sitio (P2S) conecta un equipo individual a la red virtual. Marta Ríos instala un cliente en su portátil, se autentica y su portátil recibe una dirección de un rango dedicado, con acceso a los recursos privados de la red.

Sus componentes:

Contoso reserva 172.16.30.0/24 para los clientes de P2S: un rango que no colisiona ni con Azure (10.x) ni con las oficinas.

La autenticación con Microsoft Entra ID es la opción preferible frente a los certificados: se integra con la autenticación multifactor que configuraste en la lección 01-03, permite revocar el acceso de una persona desactivando su cuenta y no obliga a distribuir ni renovar certificados uno por uno.

Con la P2S conectada, Marta llega a snet-gestion y a Bastion sin ninguna IP pública expuesta, que es exactamente la promesa que dejamos pendiente en la lección anterior.

Una VPN de sitio a sitio (S2S) conecta una red entera con la red virtual mediante un túnel IPsec/IKE entre el dispositivo VPN de la oficina y la puerta de enlace de Azure. No se instala nada en los equipos: todos los puestos de la oficina llegan a Azure de forma transparente.

Los cuatro componentes que hay que crear, y en este orden:

El cuarto es el que más confunde por su nombre: una local network gateway no es un aparato, sino un objeto de Azure que describe el otro extremo. Si la oficina cambia de IP pública o añade una subred, hay que actualizar este objeto.

Contoso elige VpnGw1AZ: el tráfico entre las oficinas y Azure es modesto (sincronizaciones nocturnas y acceso a un panel), pero la política de la empresa exige redundancia de zona en los componentes críticos, y la puerta de enlace es un punto único de fallo para las dos oficinas.

Notas sobre este script, porque cada una corresponde a un error real que se comete a menudo:

• --vpn-type RouteBased: es el tipo moderno, obligatorio para P2S, para varios túneles y para la mayoría de escenarios. PolicyBased solo se usa con dispositivos antiguos que no admiten otra cosa y tiene límites severos.
• --no-wait: el despliegue tarda hasta 45 minutos. Sin esta opción, tu terminal se queda bloqueado.
• La clave compartida (--shared-key) es un secreto de verdad: debe salir de Azure Key Vault (lección 04-03), nunca de una variable escrita en el repositorio.
• Las IP 198.51.100.x son de un rango reservado para documentación (RFC 5737): en el despliegue real se ponen las IP públicas de los cortafuegos de las oficinas.
• El dispositivo de la oficina hay que configurarlo también, con los parámetros equivalentes. Azure genera plantillas de configuración para los fabricantes más comunes.

Verificación del estado de los túneles:

El estado debe ser Connected. Si aparece Connecting de forma indefinida, el 90 % de las veces es un desajuste de parámetros IPsec entre los dos extremos o una clave compartida distinta.

Y recuerda el detalle económico de la lección anterior: gracias a --allow-gateway-transit en el concentrador y --use-remote-gateways en los radios, esta única puerta de enlace da conectividad a vnet-contoso-pro y a vnet-contoso-dev. Ese es el ahorro que justifica el patrón hub-and-spoke.

ExpressRoute es una conexión privada entre tu red y Azure a través de un operador de telecomunicaciones. El tráfico no pasa por internet en ningún momento.

Y dos modelos de conexión: ExpressRoute Direct (te conectas directamente a la red de Microsoft con puertos de 10 o 100 Gbps, para volúmenes enormes) y el habitual a través de un proveedor de conectividad.

Marta Ríos lo evalúa y decide que no, todavía no:

ExpressRoute se justifica cuando se cumple alguno de estos: mover terabytes con regularidad, migrar grandes bases de datos, escritorios virtuales para cientos de empleados, sistemas interactivos que no toleran variabilidad de latencia, o un requisito de cumplimiento que prohíba explícitamente atravesar internet. Contoso lo reevaluará si migra el sistema de facturación completo. Un patrón habitual, por cierto, es tener ExpressRoute como principal y una VPN de sitio a sitio como respaldo, que es barato y cubre el corte del circuito.

Cuando el número de oficinas y de redes virtuales crece, montar y mantener a mano las puertas de enlace, los emparejamiento y las tablas de rutas se convierte en un trabajo a tiempo completo. Azure Virtual WAN es el servicio gestionado que automatiza ese trabajo.

Para Contoso, con dos oficinas y tres redes virtuales, el hub-and-spoke manual de la lección 02-05 es más simple y más barato. Virtual WAN entraría en juego si la aerolínea creciera a veinte delegaciones o si operase en varias regiones. Basta con que sepas que existe y qué problema resuelve.

Cambiamos de dirección. Una pasajera en Buenos Aires entra en www.contosoairlines.example para comprar un vuelo. Todo está en West Europe. Veamos qué le cuesta eso.

La latencia de ida y vuelta entre Buenos Aires y Ámsterdam ronda los 220 ms. Una carga de página típica encadena varias operaciones en serie:

Resultado: más de un segundo antes de ver nada, sin contar el tiempo de proceso del servidor. Y en un embudo de venta de billetes, cada segundo de espera se traduce en abandonos.

Lo que arregla la entrega global, y es más de lo que la gente supone:

1. Terminación TLS en el borde: el saludo TCP y TLS se hace contra un punto de presencia cercano (São Paulo, por ejemplo, a unos 30 ms), no contra West Europe. Solo la petición ya establecida viaja a Europa, por conexiones persistentes ya abiertas y optimizadas dentro de la red de Microsoft.
2. Caché de contenido estático: imágenes, hojas de estilo y scripts se sirven desde el punto de presencia, sin cruzar el Atlántico.
3. Enrutamiento óptimo: el tráfico entra en la red troncal de Microsoft en el punto más cercano y viaja por ella, no por el internet público.
4. Conmutación por error: si el origen de una región no responde, el servicio global envía el tráfico a otra.

Criterios de elección, en forma de decisión:

• Sitio o API web accesible desde varias regiones del mundo, que quieres acelerar y proteger → Azure Front Door. Es la respuesta por defecto hoy, porque incluye lo que antes se hacía con CDN más Traffic Manager.
• Solo distribución de archivos estáticos muy voluminosos (vídeo, descargas, imágenes) → Azure CDN, si su modelo de precios sale mejor para ese perfil.
• Servicio que no habla HTTP (el protocolo del motor heredado, un servidor de correo, una base de datos) o conmutación entre regiones sin tocar la aplicación → Traffic Manager, porque trabaja a nivel DNS y es agnóstico del protocolo.

Advertencia sobre Traffic Manager que evita disgustos: como solo responde consultas DNS, la conmutación por error tarda lo que tarde en caducar el registro en la caché de los clientes y de los resolutores intermedios. Con un TTL de 60 segundos, la conmutación real puede llevar varios minutos. No es el mecanismo para una conmutación en segundos.

Las opciones que merecen explicación:

Ese último punto merece un aviso serio: no caches respuestas personalizadas ni resultados de disponibilidad. Si Front Door cachea /vuelos?origen=BCN&destino=EZE ignorando la cadena de consulta, un cliente puede ver los vuelos que buscó otro. Contoso cachea únicamente /estatico/* (imágenes, CSS, JS) y deja pasar sin caché todo lo dinámico.

Si más adelante Contoso montase un segundo despliegue en North Europe, bastaría con añadirlo como origen con prioridad 2 y Front Door conmutaría solo cuando la sonda del principal fallase. Recuerda, sin embargo, la decisión consciente del módulo 1: no hay activo-activo multirregión por coste.

Azure DNS aloja las zonas DNS públicas de tus dominios en la infraestructura de Microsoft, con anycast global y sin servidores que mantener. No registra dominios (para eso está App Service Domains o tu registrador habitual), solo los aloja.

El paso 5 resuelve un problema clásico: el estándar DNS no permite un CNAME en el vértice de la zona (el dominio sin www). Los registros de alias de Azure DNS lo solucionan apuntando directamente a un recurso de Azure, y además se actualizan solos si la IP del recurso cambia.

Sobre el TTL: un valor alto (3600 s) reduce consultas y coste; uno bajo (60 s) permite cambiar de destino rápido. Práctica habitual: bajar el TTL a 60 segundos unos días antes de una migración planificada y volver a subirlo después.

Aquí está la sorpresa que se lleva todo el mundo con su primera factura de Azure, y por eso cierra la parte técnica del módulo.

La regla general de Azure:

• La entrada de datos (ingress) es gratuita. Subir a Azure no cuesta.
• La salida de datos (egress) se factura. Todo lo que sale hacia internet, y buena parte de lo que se mueve entre regiones o entre zonas.

Dónde duele esto en el caso de Contoso:

1. Tarjetas de embarque descargadas por los pasajeros. Cada PDF que sale a internet se factura. Un millón de descargas de 300 KB son 300 GB al mes: pequeño, pero real, y crece con el negocio.
2. Sincronización nocturna con la facturación de Barcelona a través de la VPN: sale de Azure, se factura.
3. Replicación GZRS de la cuenta de tarjetas hacia North Europe: la replicación geográfica tiene su propio coste de transferencia.
4. Tráfico entre radios y concentrador por emparejamiento: parece «interno», pero se factura por GB en ambos sentidos.

Cuatro formas de reducirlo, todas aplicables desde ya:

• Cachear en el borde: cada respuesta servida desde caché de Front Door es una salida menos desde la región (y más rápida).
• Comprimir: activar la compresión en Front Door y en App Service reduce los bytes servidos.
• No mover datos entre regiones sin motivo: procesa donde están los datos.
• Vigilar el desglose de la factura: en el módulo 8 verás cómo Cost Management descompone el gasto por servicio y por tipo de medidor, y cómo Nuria Peña, la responsable financiera, lo revisa cada mes con el equipo. La salida de datos suele estar entre las tres primeras líneas y casi nadie la había presupuestado.

Limpieza, empezando por lo más caro:

Borrar la puerta de enlace tarda varios minutos. Hazlo antes de irte, no después: una VpnGw1AZ olvidada un mes cuesta más que todo el resto del laboratorio de este módulo junto.

• Crear la puerta de enlace de VPN «para probar» y olvidarla. Factura por hora desde el minuto uno, esté o no conectada. Es el error de coste más caro de todo el módulo.
• Solapar el grupo de direcciones de la P2S con la red de Azure o con la de la oficina. El cliente conecta, pero no llega a nada. Reserva un rango exclusivo (172.16.30.0/24 en Contoso).
• Usar PolicyBased cuando hace falta RouteBased. No admite P2S ni varios túneles y hay que rehacer la puerta de enlace entera.
• Poner mal los rangos en la puerta de enlace de red local. Si falta una subred de la oficina, esa parte de la red no llega a Azure y el síntoma es «funciona a medias».
• Escribir la clave compartida de la VPN en el script. Va a Key Vault (04-03). Un repositorio con una clave IPsec es un incidente de seguridad.
• Suponer que ExpressRoute cifra el tráfico. Es un circuito privado, no cifrado por defecto. Si el requisito es cifrado extremo a extremo, hay que añadirlo.
• Esperar de Traffic Manager una conmutación en segundos. Trabaja por DNS: la caché de los clientes manda. Para conmutación rápida, Front Door.
• Cachear contenido dinámico o personalizado en Front Door. Un resultado de búsqueda de vuelos cacheado puede mostrarse a otro cliente. Cachea solo lo estático.
• Olvidar el registro de alias en el vértice del dominio. No se puede usar CNAME en @; los alias de Azure DNS son la solución.
• No presupuestar la salida de datos. Es una de las primeras líneas de la factura y la que menos gente anticipa. Enlázalo con el presupuesto que creaste en la lección 01-03.
• Consejo: despliega la puerta de enlace con --no-wait y aprovecha los 30-45 minutos para configurar el resto. Y ponle una alerta de presupuesto específica.
• Consejo: documenta en el repositorio la tabla de rangos (Azure, oficinas, P2S). En una incidencia de conectividad a las tres de la mañana, ese documento vale más que cualquier diagrama bonito.

Para cada necesidad de Contoso Airlines, indica qué solución usarías y justifícala:

1. Marta Ríos administra las VM desde un hotel durante un congreso.
2. Los 30 puestos de la oficina de Palma acceden a diario al panel de operaciones y al recurso compartido de Azure Files.
3. Contoso decide migrar el sistema de facturación completo y mover 8 TB de histórico en un fin de semana, además de mantener después una sincronización continua de baja latencia.
4. La aerolínea abre delegaciones en 18 aeropuertos, cada una con su red local, y quiere conectarlas todas sin gestionar 18 puertas de enlace.

La pasajera de Buenos Aires tarda más de un segundo en ver la página de búsqueda de vuelos.

1. ¿Qué servicio de entrega global elegirías y por qué frente a los otros dos?
2. ¿Qué contenidos cachearías y cuáles no? Justifica el riesgo de equivocarte.
3. Escribe la configuración de la sonda de estado del grupo de orígenes y explica cada parámetro.
4. Si Contoso añadiese un despliegue en North Europe, ¿cómo lo configurarías para que fuese de respaldo y no activo-activo?

Nuria Peña, la responsable financiera, pregunta por qué el apartado de red de la factura ha subido un 40 % este trimestre.

1. Enumera al menos cuatro fuentes de salida de datos en la arquitectura actual de Contoso.
2. Para cada una, propón una medida concreta de reducción.
3. ¿Qué tráfico de la arquitectura es gratuito y conviene explicar a Nuria para que no lo persiga?

Solución 1:

Solución 2:

1. Azure Front Door. Frente a Azure CDN, porque no solo hay que cachear estáticos: también interesa terminar TLS en el borde y acelerar el contenido dinámico por la red troncal de Microsoft, además de poder añadir WAF (04-04). Frente a Traffic Manager, porque este solo responde consultas DNS y no toca el tráfico: no reduciría en nada la latencia de establecimiento de conexión, que es el grueso del problema.

2. Cacheable y no cacheable:

El riesgo de equivocarse es doble y grave: mostrar datos personales de un pasajero a otro (incidente de privacidad y RGPD) y vender plazas que ya no existen.

3. Sonda de estado:

4. Añadiendo el segundo origen al mismo grupo con prioridad 2:

Front Door envía todo el tráfico a la prioridad 1 mientras esté sana y solo conmuta a la 2 cuando las sondas fallan. Con la misma prioridad en ambos, se repartiría el tráfico (activo-activo), que es precisamente lo que Contoso descartó por coste en el módulo 1.

Solución 3:

1 y 2. Fuentes de salida y medidas:

3. Tráfico gratuito, que conviene explicar para no perseguir fantasmas: toda la entrada de datos hacia Azure (subidas de tarjetas, peticiones entrantes, la carga inicial de la migración), y el tráfico dentro de la misma región y la misma red virtual, como el que va de snet-web a snet-app o de la aplicación a su base de datos. Es decir: procesar datos donde están no cuesta transferencia; moverlos fuera, sí.

Con esta lección cierras el módulo 2 y la plataforma de Contoso Airlines ya está de pie. Has resuelto el escenario híbrido: VPN de punto a sitio con autenticación de Microsoft Entra ID para que Marta Ríos administre desde cualquier sitio sin exponer un solo puerto, y VPN de sitio a sitio para Barcelona y Palma, con sus cuatro componentes —GatewaySubnet, IP pública, puerta de enlace de red virtual y puerta de enlace de red local—, la elección de SKU VpnGw1AZ con redundancia de zona y el aprovechamiento de una única puerta de enlace para todos los radios del hub-and-spoke. Sabes qué aporta ExpressRoute frente a la VPN —ancho de banda, latencia predecible, SLA y no atravesar internet—, sus modelos de emparejamiento, y por qué Contoso decide no contratarlo todavía. Conoces Azure Virtual WAN y el problema que resuelve cuando las sedes se multiplican. Y en la otra dirección has montado la entrega global: entiendes de dónde salen los más de mil milisegundos que sufre una pasajera en Buenos Aires, has comparado Front Door, CDN y Traffic Manager con criterios de elección claros, has publicado Contoso Reservas tras Front Door con sonda de estado, redirección a HTTPS y caché solo de lo estático, has alojado el dominio en Azure DNS con su registro de alias en el vértice, y sabes anticipar el coste de la salida de datos que aparecerá en la factura del módulo 8.

Recapitulando el módulo entero: empezaste desplegando máquinas virtuales para el motor de disponibilidad heredado, con sus discos, sus tamaños y la diferencia entre detenida y desasignada. Después diste escalado y alta disponibilidad al cómputo con conjuntos de escalado, reglas automáticas y programadas, zonas de disponibilidad y un Load Balancer con sondas de estado. Publicaste Contoso Reservas y la API de Disponibilidad en App Service, con planes, ranuras de despliegue e intercambio con calentamiento para publicar sin cortar la venta. Guardaste las tarjetas de embarque en Azure Storage, resolviendo la redundancia pendiente —LRS en desarrollo, GZRS en producción— y automatizando su ciclo de vida hacia Cool y Archive. Construiste la red virtual con sus subredes, NSG, zonas DNS privadas y puntos de conexión privados que sacaron la base de datos y el almacenamiento de internet. Y hoy has unido esa red con las oficinas y con el mundo.

Tienes cómputo, almacenamiento y red. Falta lo que da sentido a todo: los datos. La base de datos db-reservas lleva apareciendo en cada lección como una pieza que existe pero que aún no has diseñado ni desplegado, y las decisiones que quedan por tomar no son menores: ¿una base relacional o un almacén de documentos? ¿Azure SQL Database, MySQL, PostgreSQL o Cosmos DB? ¿Cuánto cuesta cada opción, cómo se escala y cómo se recupera si alguien borra una tabla un viernes por la tarde?

En el módulo 3, Bases de datos de Azure, empezamos justamente por ahí: por el criterio para elegir el servicio de datos adecuado —relacional frente a NoSQL, gestionado frente a instalado en una VM, coste frente a rendimiento— y después desplegaremos de verdad la base de datos de reservas de Contoso Airlines en Azure SQL Database, con su nivel de servicio, su copia de seguridad, su restauración a un momento dado y su conexión privada a la red que acabas de construir. Nos vemos allí.