La lliçó anterior va acabar amb dos extrems solts, un cap endins i un altre cap enfora. Cap endins: les oficines de Barcelona i Palma continuen fora de la xarxa d'Azure, el sistema de facturació heretat viu en un servidor del soterrani de Barcelona, i la Marta Ríos no pot administrar la plataforma des de casa sense exposar alguna cosa a internet. Cap enfora: un client que compra un bitllet des de Sud-amèrica creua l'Atlàntic a cada petició contra West Europe, i ho nota.

Tots dos problemes són de connectivitat, però de signe oposat. El primer es resol amb connectivitat híbrida: túnels xifrats o circuits dedicats que uneixen la xarxa local amb la xarxa virtual d'Azure, de manera que 10.100.0.0/16 i 10.20.0.0/16 es comportin com una sola xarxa. El segon es resol amb lliurament global: serveis que posen el contingut i la terminació de les connexions a prop del client, estigui on estigui.

Aquesta lliçó tanca el mòdul 2 amb totes dues coses i amb un avís que apareix a totes les factures d'Azure i que gairebé ningú no anticipa: el cost de la sortida de dades.

Avís de cost important: aquesta és la lliçó més cara del mòdul. Una porta d'enllaç de VPN es factura per hora des que es crea, encara que no hi hagi ni un túnel connectat, i triga entre 20 i 45 minuts a desplegar-se. ExpressRoute implica un contracte amb un operador i no es prova en un laboratori. Front Door i CDN tenen cost per dades servides. Desplega només el que faràs servir i esborra-ho el mateix dia.

1. L'escenari híbrid de Contoso Airlines
2. VPN de punt a lloc: administrar des de casa
3. VPN de lloc a lloc: connectar Barcelona i Palma
4. Desplegament de la porta d'enllaç amb Azure CLI
5. ExpressRoute: quan justifica el seu preu
6. Azure Virtual WAN, a nivell conceptual
7. Lliurament global: el client que compra des de Sud-amèrica
8. Azure Front Door, Azure CDN i Traffic Manager comparats
9. DNS públic amb Azure DNS
10. El cost de la sortida de dades
11. Arquitectura final del mòdul i neteja
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

El que queda en local després de la migració, i per què:

Recorda el pla d'adreçament fixat a la lliçó anterior, perquè la connectivitat híbrida és on aquest pla demostra el seu valor: Barcelona és 10.100.0.0/16, Palma 10.101.0.0/16, el concentrador d'Azure 10.10.0.0/16 i producció 10.20.0.0/16. Res no s'encavalca, així que tot es pot encaminar.

Les tres opcions de connectivitat, comparades d'un cop d'ull:

Una VPN de punt a lloc (P2S) connecta un equip individual a la xarxa virtual. La Marta Ríos instal·la un client al seu portàtil, s'autentica i el portàtil rep una adreça d'un rang dedicat, amb accés als recursos privats de la xarxa.

Els seus components:

Contoso reserva 172.16.30.0/24 per als clients de P2S: un rang que no col·lisiona ni amb Azure (10.x) ni amb les oficines.

L'autenticació amb Microsoft Entra ID és l'opció preferible davant dels certificats: s'integra amb l'autenticació multifactor que vas configurar a la lliçó 01-03, permet revocar l'accés d'una persona desactivant-ne el compte i no obliga a distribuir ni renovar certificats un per un.

Amb la P2S connectada, la Marta arriba a snet-gestion i a Bastion sense cap IP pública exposada, que és exactament la promesa que vam deixar pendent a la lliçó anterior.

Una VPN de lloc a lloc (S2S) connecta una xarxa sencera amb la xarxa virtual mitjançant un túnel IPsec/IKE entre el dispositiu VPN de l'oficina i la porta d'enllaç d'Azure. No s'instal·la res als equips: tots els llocs de treball de l'oficina arriben a Azure de manera transparent.

Els quatre components que cal crear, i en aquest ordre:

El quart és el que més confon pel seu nom: una local network gateway no és un aparell, sinó un objecte d'Azure que descriu l'altre extrem. Si l'oficina canvia d'IP pública o hi afegeix una subxarxa, cal actualitzar aquest objecte.

Contoso tria VpnGw1AZ: el trànsit entre les oficines i Azure és modest (sincronitzacions nocturnes i accés a un tauler), però la política de l'empresa exigeix redundància de zona als components crítics, i la porta d'enllaç és un punt únic de fallada per a les dues oficines.

Notes sobre aquest script, perquè cadascuna correspon a un error real que es comet sovint:

• --vpn-type RouteBased: és el tipus modern, obligatori per a P2S, per a diversos túnels i per a la majoria d'escenaris. PolicyBased només es fa servir amb dispositius antics que no admeten cap altra cosa i té límits severs.
• --no-wait: el desplegament triga fins a 45 minuts. Sense aquesta opció, el teu terminal es queda bloquejat.
• La clau compartida (--shared-key) és un secret de debò: ha de sortir d'Azure Key Vault (lliçó 04-03), mai d'una variable escrita al repositori.
• Les IP 198.51.100.x són d'un rang reservat per a documentació (RFC 5737): en el desplegament real s'hi posen les IP públiques dels tallafocs de les oficines.
• El dispositiu de l'oficina també s'ha de configurar, amb els paràmetres equivalents. Azure genera plantilles de configuració per als fabricants més comuns.

Verificació de l'estat dels túnels:

L'estat ha de ser Connected. Si apareix Connecting de manera indefinida, el 90 % de les vegades és un desajust de paràmetres IPsec entre els dos extrems o una clau compartida diferent.

I recorda el detall econòmic de la lliçó anterior: gràcies a --allow-gateway-transit al concentrador i --use-remote-gateways als radis, aquesta única porta d'enllaç dona connectivitat a vnet-contoso-pro i a vnet-contoso-dev. Aquest és l'estalvi que justifica el patró hub-and-spoke.

ExpressRoute és una connexió privada entre la teva xarxa i Azure a través d'un operador de telecomunicacions. El trànsit no passa per internet en cap moment.

I dos models de connexió: ExpressRoute Direct (et connectes directament a la xarxa de Microsoft amb ports de 10 o 100 Gbps, per a volums enormes) i l'habitual a través d'un proveïdor de connectivitat.

La Marta Ríos ho avalua i decideix que no, encara no:

ExpressRoute es justifica quan es compleix algun d'aquests: moure terabytes amb regularitat, migrar bases de dades grans, escriptoris virtuals per a centenars d'empleats, sistemes interactius que no toleren variabilitat de latència, o un requisit de compliment que prohibeixi explícitament travessar internet. Contoso ho reavaluarà si migra el sistema de facturació complet. Un patró habitual, per cert, és tenir ExpressRoute com a principal i una VPN de lloc a lloc com a reserva, que és barat i cobreix el tall del circuit.

Quan el nombre d'oficines i de xarxes virtuals creix, muntar i mantenir a mà les portes d'enllaç, els aparellaments i les taules de rutes es converteix en una feina a temps complet. Azure Virtual WAN és el servei gestionat que automatitza aquesta feina.

Per a Contoso, amb dues oficines i tres xarxes virtuals, el hub-and-spoke manual de la lliçó 02-05 és més simple i més barat. Virtual WAN entraria en joc si l'aerolínia creixés fins a vint delegacions o si operés en diverses regions. N'hi ha prou que sàpigues que existeix i quin problema resol.

Canviem de direcció. Una passatgera a Buenos Aires entra a www.contosoairlines.example per comprar un vol. Tot és a West Europe. Vegem què li costa això.

La latència d'anada i tornada entre Buenos Aires i Amsterdam ronda els 220 ms. Una càrrega de pàgina típica encadena diverses operacions en sèrie:

Resultat: més d'un segon abans de veure res, sense comptar el temps de procés del servidor. I en un embut de venda de bitllets, cada segon d'espera es tradueix en abandonaments.

El que arregla el lliurament global, i és més del que la gent suposa:

1. Terminació TLS a la vora: la salutació TCP i TLS es fa contra un punt de presència proper (São Paulo, per exemple, a uns 30 ms), no contra West Europe. Només la petició ja establerta viatja a Europa, per connexions persistents ja obertes i optimitzades dins de la xarxa de Microsoft.
2. Memòria cau de contingut estàtic: imatges, fulls d'estil i scripts se serveixen des del punt de presència, sense creuar l'Atlàntic.
3. Encaminament òptim: el trànsit entra a la xarxa troncal de Microsoft al punt més proper i hi viatja, no per l'internet públic.
4. Commutació per error: si l'origen d'una regió no respon, el servei global envia el trànsit a un altre.

Criteris d'elecció, en forma de decisió:

• Lloc o API web accessible des de diverses regions del món, que vols accelerar i protegir → Azure Front Door. És la resposta per defecte avui, perquè inclou el que abans es feia amb CDN més Traffic Manager.
• Només distribució de fitxers estàtics molt voluminosos (vídeo, descàrregues, imatges) → Azure CDN, si el seu model de preus surt millor per a aquest perfil.
• Servei que no parla HTTP (el protocol del motor heretat, un servidor de correu, una base de dades) o commutació entre regions sense tocar l'aplicació → Traffic Manager, perquè treballa a nivell de DNS i és agnòstic del protocol.

Advertència sobre Traffic Manager que evita disgustos: com que només respon consultes DNS, la commutació per error triga el que trigui a caducar el registre a la memòria cau dels clients i dels resolutors intermedis. Amb un TTL de 60 segons, la commutació real pot durar diversos minuts. No és el mecanisme per a una commutació en segons.

Les opcions que mereixen explicació:

Aquest últim punt mereix un avís seriós: no posis a la memòria cau respostes personalitzades ni resultats de disponibilitat. Si Front Door desa a la memòria cau /vuelos?origen=BCN&destino=EZE ignorant la cadena de consulta, un client pot veure els vols que va buscar un altre. Contoso només posa a la memòria cau /estatico/* (imatges, CSS, JS) i deixa passar sense memòria cau tot el que és dinàmic.

Si més endavant Contoso muntés un segon desplegament a North Europe, n'hi hauria prou d'afegir-lo com a origen amb prioritat 2 i Front Door commutaria sol quan la sonda del principal fallés. Recorda, però, la decisió conscient del mòdul 1: no hi ha actiu-actiu multiregió per cost.

Azure DNS allotja les zones DNS públiques dels teus dominis a la infraestructura de Microsoft, amb anycast global i sense servidors per mantenir. No registra dominis (per a això hi ha App Service Domains o el teu registrador habitual), només els allotja.

El pas 5 resol un problema clàssic: l'estàndard DNS no permet un CNAME al vèrtex de la zona (el domini sense www). Els registres d'alias d'Azure DNS ho solucionen apuntant directament a un recurs d'Azure, i a més s'actualitzen sols si la IP del recurs canvia.

Sobre el TTL: un valor alt (3600 s) redueix consultes i cost; un de baix (60 s) permet canviar de destinació ràpid. Pràctica habitual: baixar el TTL a 60 segons uns dies abans d'una migració planificada i tornar a pujar-lo després.

Aquí hi ha la sorpresa que s'emporta tothom amb la seva primera factura d'Azure, i per això tanca la part tècnica del mòdul.

La regla general d'Azure:

• L'entrada de dades (ingress) és gratuïta. Pujar a Azure no costa.
• La sortida de dades (egress) es factura. Tot el que surt cap a internet, i bona part del que es mou entre regions o entre zones.

On fa mal això en el cas de Contoso:

1. Targetes d'embarcament descarregades pels passatgers. Cada PDF que surt a internet es factura. Un milió de descàrregues de 300 KB són 300 GB al mes: petit, però real, i creix amb el negoci.
2. Sincronització nocturna amb la facturació de Barcelona a través de la VPN: surt d'Azure, es factura.
3. Replicació GZRS del compte de targetes cap a North Europe: la replicació geogràfica té el seu propi cost de transferència.
4. Trànsit entre radis i concentrador per aparellament: sembla «intern», però es factura per GB en tots dos sentits.

Quatre formes de reduir-lo, totes aplicables des d'ara:

• Posar a la memòria cau a la vora: cada resposta servida des de la memòria cau de Front Door és una sortida menys des de la regió (i més ràpida).
• Comprimir: activar la compressió a Front Door i a App Service redueix els bytes servits.
• No moure dades entre regions sense motiu: processa on són les dades.
• Vigilar el desglossament de la factura: al mòdul 8 veuràs com Cost Management descompon la despesa per servei i per tipus de mesurador, i com la Nuria Peña, la responsable financera, ho revisa cada mes amb l'equip. La sortida de dades sol estar entre les tres primeres línies i gairebé ningú no l'havia pressupostada.

Neteja, començant pel més car:

Esborrar la porta d'enllaç triga diversos minuts. Fes-ho abans d'anar-te'n, no després: una VpnGw1AZ oblidada un mes costa més que tota la resta del laboratori d'aquest mòdul junta.

• Crear la porta d'enllaç de VPN «per provar» i oblidar-la. Factura per hora des del minut u, estigui o no connectada. És l'error de cost més car de tot el mòdul.
• Encavalcar el grup d'adreces de la P2S amb la xarxa d'Azure o amb la de l'oficina. El client connecta, però no arriba a res. Reserva un rang exclusiu (172.16.30.0/24 a Contoso).
• Fer servir PolicyBased quan cal RouteBased. No admet P2S ni diversos túnels i cal refer la porta d'enllaç sencera.
• Posar malament els rangs a la porta d'enllaç de xarxa local. Si falta una subxarxa de l'oficina, aquella part de la xarxa no arriba a Azure i el símptoma és «funciona a mitges».
• Escriure la clau compartida de la VPN a l'script. Va a Key Vault (04-03). Un repositori amb una clau IPsec és un incident de seguretat.
• Suposar que ExpressRoute xifra el trànsit. És un circuit privat, no xifrat per defecte. Si el requisit és xifratge d'extrem a extrem, cal afegir-lo.
• Esperar de Traffic Manager una commutació en segons. Treballa per DNS: la memòria cau dels clients mana. Per a commutació ràpida, Front Door.
• Posar a la memòria cau contingut dinàmic o personalitzat a Front Door. Un resultat de cerca de vols a la memòria cau es pot mostrar a un altre client. Posa-hi només el que és estàtic.
• Oblidar el registre d'alias al vèrtex del domini. No es pot fer servir CNAME a @; els alias d'Azure DNS són la solució.
• No pressupostar la sortida de dades. És una de les primeres línies de la factura i la que menys gent anticipa. Enllaça-ho amb el pressupost que vas crear a la lliçó 01-03.
• Consell: desplega la porta d'enllaç amb --no-wait i aprofita els 30-45 minuts per configurar la resta. I posa-li una alerta de pressupost específica.
• Consell: documenta al repositori la taula de rangs (Azure, oficines, P2S). En una incidència de connectivitat a les tres de la matinada, aquest document val més que qualsevol diagrama bonic.

Per a cada necessitat de Contoso Airlines, indica quina solució faries servir i justifica-la:

1. La Marta Ríos administra les VM des d'un hotel durant un congrés.
2. Els 30 llocs de treball de l'oficina de Palma accedeixen cada dia al tauler d'operacions i al recurs compartit d'Azure Files.
3. Contoso decideix migrar el sistema de facturació complet i moure 8 TB d'històric en un cap de setmana, a més de mantenir després una sincronització contínua de baixa latència.
4. L'aerolínia obre delegacions a 18 aeroports, cadascuna amb la seva xarxa local, i vol connectar-les totes sense gestionar 18 portes d'enllaç.

La passatgera de Buenos Aires triga més d'un segon a veure la pàgina de cerca de vols.

1. Quin servei de lliurament global triaries i per què davant dels altres dos?
2. Quins continguts posaries a la memòria cau i quins no? Justifica el risc d'equivocar-te.
3. Escriu la configuració de la sonda d'estat del grup d'orígens i explica cada paràmetre.
4. Si Contoso hi afegís un desplegament a North Europe, com el configuraries perquè fos de reserva i no actiu-actiu?

La Nuria Peña, la responsable financera, pregunta per què l'apartat de xarxa de la factura ha pujat un 40 % aquest trimestre.

1. Enumera almenys quatre fonts de sortida de dades a l'arquitectura actual de Contoso.
2. Per a cadascuna, proposa una mesura concreta de reducció.
3. Quin trànsit de l'arquitectura és gratuït i convé explicar a la Nuria perquè no el persegueixi?

Solució 1:

Solució 2:

1. Azure Front Door. Davant d'Azure CDN, perquè no només cal posar a la memòria cau estàtics: també interessa acabar TLS a la vora i accelerar el contingut dinàmic per la xarxa troncal de Microsoft, a més de poder afegir WAF (04-04). Davant de Traffic Manager, perquè aquest només respon consultes DNS i no toca el trànsit: no reduiria en res la latència d'establiment de connexió, que és el gruix del problema.

2. Cacheable i no cacheable:

El risc d'equivocar-se és doble i greu: mostrar dades personals d'un passatger a un altre (incident de privacitat i RGPD) i vendre places que ja no existeixen.

3. Sonda d'estat:

4. Afegint el segon origen al mateix grup amb prioritat 2:

Front Door envia tot el trànsit a la prioritat 1 mentre estigui sana i només commuta a la 2 quan les sondes fallen. Amb la mateixa prioritat a totes dues, es repartiria el trànsit (actiu-actiu), que és precisament el que Contoso va descartar per cost al mòdul 1.

Solució 3:

1 i 2. Fonts de sortida i mesures:

3. Trànsit gratuït, que convé explicar per no perseguir fantasmes: tota l'entrada de dades cap a Azure (pujades de targetes, peticions entrants, la càrrega inicial de la migració), i el trànsit dins de la mateixa regió i la mateixa xarxa virtual, com el que va de snet-web a snet-app o de l'aplicació a la seva base de dades. És a dir: processar dades on són no costa transferència; moure-les fora, sí.

Amb aquesta lliçó tanques el mòdul 2 i la plataforma de Contoso Airlines ja és dempeus. Has resolt l'escenari híbrid: VPN de punt a lloc amb autenticació de Microsoft Entra ID perquè la Marta Ríos administri des de qualsevol lloc sense exposar ni un sol port, i VPN de lloc a lloc per a Barcelona i Palma, amb els seus quatre components —GatewaySubnet, IP pública, porta d'enllaç de xarxa virtual i porta d'enllaç de xarxa local—, l'elecció de SKU VpnGw1AZ amb redundància de zona i l'aprofitament d'una única porta d'enllaç per a tots els radis del hub-and-spoke. Saps què aporta ExpressRoute davant de la VPN —amplada de banda, latència predictible, SLA i no travessar internet—, els seus models d'aparellament, i per què Contoso decideix no contractar-lo encara. Coneixes Azure Virtual WAN i el problema que resol quan les seus es multipliquen. I en l'altra direcció has muntat el lliurament global: entens d'on surten els més de mil mil·lisegons que pateix una passatgera a Buenos Aires, has comparat Front Door, CDN i Traffic Manager amb criteris d'elecció clars, has publicat Contoso Reserves darrere de Front Door amb sonda d'estat, redirecció a HTTPS i memòria cau només del que és estàtic, has allotjat el domini a Azure DNS amb el seu registre d'alias al vèrtex, i saps anticipar el cost de la sortida de dades que apareixerà a la factura del mòdul 8.

Recapitulant el mòdul sencer: vas començar desplegant màquines virtuals per al motor de disponibilitat heretat, amb els seus discos, les seves mides i la diferència entre aturada i desassignada. Després vas donar escalat i alta disponibilitat al còmput amb conjunts d'escalat, regles automàtiques i programades, zones de disponibilitat i un Load Balancer amb sondes d'estat. Vas publicar Contoso Reserves i l'API de Disponibilitat a App Service, amb plans, ranures de desplegament i intercanvi amb escalfament per publicar sense tallar la venda. Vas desar les targetes d'embarcament a Azure Storage, resolent la redundància pendent —LRS en desenvolupament, GZRS en producció— i automatitzant-ne el cicle de vida cap a Cool i Archive. Vas construir la xarxa virtual amb les seves subxarxes, NSG, zones DNS privades i punts de connexió privats que van treure la base de dades i l'emmagatzematge d'internet. I avui has unit aquesta xarxa amb les oficines i amb el món.

Tens còmput, emmagatzematge i xarxa. Falta el que dona sentit a tot: les dades. La base de dades db-reservas va apareixent a cada lliçó com una peça que existeix però que encara no has dissenyat ni desplegat, i les decisions que queden per prendre no són menors: una base relacional o un magatzem de documents? Azure SQL Database, MySQL, PostgreSQL o Cosmos DB? Quant costa cada opció, com s'escala i com es recupera si algú esborra una taula un divendres a la tarda?

Al mòdul 3, Bases de dades d'Azure, comencem justament per aquí: pel criteri per triar el servei de dades adequat —relacional davant de NoSQL, gestionat davant d'instal·lat en una VM, cost davant de rendiment— i després desplegarem de debò la base de dades de reserves de Contoso Airlines a Azure SQL Database, amb el seu nivell de servei, la seva còpia de seguretat, la seva restauració a un moment donat i la seva connexió privada a la xarxa que acabes de construir. Ens hi veiem.