Contoso Airlines té ja una plataforma que es veu i que s'opera sola en bona mesura. Falta la pregunta del dia dolent, la que ningú no es vol fer fins que arriba: algú esborra per error el grup de recursos equivocat, un ransomware xifra un servidor, una actualització corromp la base de dades de reserves, o una regió sencera d'Azure deixa de respondre. Cap d'aquestes coses no la resol un tauler ni una alerta. Les resol —o no— el que hagis preparat abans.

Aquesta lliçó tanca el mòdul amb la part menys glamurosa i més decisiva d'operar al núvol. Veuràs la diferència real entre còpia de seguretat i recuperació davant desastres, els dos números que governen totes les decisions, Azure Backup i els seus magatzems, la protecció davant l'esborrat maliciós, què resguarda cada servei PaaS pel seu compte i què continua sent teu, i l'estratègia completa de Contoso entre West Europe i North Europe, amb el seu pla escrit i el seu simulacre. Perquè una plataforma que no es pot restaurar no està acabada.

1. Còpia de seguretat davant de recuperació davant desastres
2. RPO i RTO: els dos números que ho governen tot
3. Azure Backup: magatzems, directives i càrregues de treball
4. Redundància, eliminació temporal i immutabilitat davant del ransomware
5. Restaurar: màquina completa, discos i fitxers solts
6. Què resguarda cada servei PaaS i què continua sent teu
7. Azure Site Recovery
8. L'estratègia de recuperació de Contoso
9. El pla de recuperació escrit
10. El simulacre: un pla no provat no existeix
11. Recuperar el que s'ha esborrat: bloquejos, Bicep i còpies de configuració
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Es confonen constantment i resolen problemes diferents.

La distinció té una conseqüència pràctica que molta gent descobreix tard: la replicació no és una còpia de seguretat. Si un ransomware xifra el disc de la regió primària, la rèplica geogràfica replica diligentment el disc xifrat a la secundària en segons. La replicació protegeix de la fallada d'infraestructura; només una còpia de seguretat immutable i amb historial protegeix de l'error i de l'atac. Es necessiten totes dues.

Tota l'arquitectura d'aquesta lliçó es deriva de dues preguntes al negoci:

• RPO (objectiu de punt de recuperació): quantes dades ens podem permetre perdre? Es mesura en temps. Un RPO de 15 minuts significa acceptar la pèrdua dels últims 15 minuts de feina.
• RTO (objectiu de temps de recuperació): quant de temps podem estar caiguts? Des que passa el desastre fins que el servei torna.

La conversa es torça sempre igual: preguntes al negoci i respon «zero i zero». Aquí és on cal traduir-ho a diners, perquè tots dos números són inversament proporcionals al cost, i de manera molt pronunciada. Baixar l'RPO de 24 hores a 1 hora és assequible; d'1 hora a zero exigeix replicació síncrona, que a més penalitza la latència d'escriptura de cada transacció. Baixar l'RTO de 8 hores a 1 hora significa tenir la infraestructura secundària ja creada i pagant-se. La pregunta correcta no és «quant en vols?», sinó «quant costa una hora d'aturada d'aquest sistema, i estàs disposat a gastar menys que això a evitar-la?».

Amb aquesta conversa feta, Contoso va fixar els seus nivells:

Fixa't en l'última fila i en la tercera columna de l'analítica: no tot mereix el mateix nivell, i decidir que un sistema té un RTO de 72 hores és una decisió d'arquitectura tan legítima i tan deliberada com decidir que un altre el té d'una hora. Aplicar el nivell màxim a tot és la manera més ràpida de multiplicar la factura sense millorar el que importa.

Azure Backup és el servei administrat de còpies. No hi ha servidor de backup, ni agent per llicenciar, ni cintes. Els seus dos contenidors:

Tots dos viuen a rg-contoso-seguridad-pro, separats dels recursos que protegeixen. Això no és cosmètic: si el magatzem és al mateix grup que la càrrega, un esborrat accidental del grup s'emporta la dada i la seva còpia alhora.

Una directiva defineix la freqüència i la retenció en un esquema d'avi-pare-fill:

La directiva pol-backup-vm-diaria de Contoso: còpia diària a les 02:00, 30 punts diaris, 12 setmanals, 12 mensuals i 7 anuals. La retenció llarga respon a una realitat incòmoda: la corrupció i el ransomware es detecten tard, de vegades setmanes després, i una retenció de set dies deixa sense punt net al qual tornar.

Dos detalls operatius importants. La còpia d'una VM d'Azure fa servir instantànies de disc, sense agent i amb la màquina encesa; per a bases de dades dins de la VM cal consistència d'aplicació, que a Windows aporta VSS i a Linux exigeix scripts previs i posteriors propis. I la còpia operativa de discos i blobs conserva instantànies locals per restaurar en segons, complementant —no substituint— la còpia del magatzem.

La redundància del magatzem reutilitza el que has après al mòdul 2 sobre Azure Storage:

Contoso fa servir GRS amb restauració entre regions activada a rsv-contoso-pro. Aquest ajust té un parany clàssic: la redundància només es pot fixar abans de protegir el primer element. Després és immutable, i canviar-la obliga a crear un magatzem nou i tornar a protegir-ho tot, perdent l'historial. És una d'aquestes decisions que costa molt poc prendre bé el primer dia i molt corregir l'any següent.

Ara, la part que separa una còpia de seguretat real d'una il·lusió de seguretat. Un atacant que aconsegueix credencials amb permisos no ataca les dades: ataca les còpies, perquè sap que sense elles el rescat es paga. Les tres defenses d'Azure Backup:

• Eliminació temporal (soft delete): en esborrar una còpia, no desapareix; queda retinguda 14 dies —ampliables— i es pot recuperar. En la seva modalitat millorada es pot fer irreversible, de manera que ni un administrador pot escurçar aquest termini.
• Immutabilitat del magatzem: un cop bloquejada, impedeix reduir la retenció, esborrar punts de recuperació o desprotegir un element conservant la dada. El bloqueig és irreversible, i aquest és exactament el seu valor: si es pogués revertir, l'atacant el revertiria.
• Autorització multiusuari (MUA): les operacions crítiques —desactivar l'eliminació temporal, reduir la retenció, eliminar la protecció amb dades— requereixen l'aprovació d'un segon principal, protegit per un guardià de recursos que viu en una altra subscripció i sota un altre administrador. El compromís d'un sol compte deixa de ser suficient.

Completa-ho amb el del mòdul 4: RBAC estricte sobre el magatzem —molt poca gent necessita el rol de col·laborador de còpies—, alertes sobre les operacions d'esborrat a AzureActivity (07-01), i Microsoft Defender for Cloud vigilant accessos anòmals. La regla que cal endur-se: una còpia que un atacant amb permisos pot esborrar no és una còpia.

Azure Backup ofereix tres granularitats, i triar l'adequada canvia l'RTO completament:

La restauració de fitxers individuals mereix atenció perquè resol gairebé totes les peticions reals —«necessito el fitxer de configuració d'abans del canvi»— sense tocar la màquina en producció: munta el punt de recuperació com a unitat temporal, copies, i desmuntes. I la restauració entre regions permet recuperar a North Europe a partir de la còpia geogràfica quan West Europe no està disponible; sense la marca cross-region-restore-flag activada per endavant, aquesta porta simplement no existeix el dia que fa falta.

Aquest és el malentès més car del núvol: donar per fet que «el servei ja fa còpies». De vegades les fa, però gairebé mai no cobreix el que et penses.

Tres avisos concrets. A Storage, la redundància protegeix de la fallada de maquinari i no que algú esborri un blob: això ho cobreixen el versionat i l'eliminació temporal, que cal activar explícitament a sttarjetascontosopro. A Key Vault, sense protecció contra purga un secret eliminat es pot purgar de manera definitiva abans que expiri el termini d'eliminació temporal. I a AKS, els manifestos versionats permeten reconstruir la plataforma, però no retornen el contingut dels volums persistents.

Site Recovery replica màquines completes —d'Azure a una altra regió, o des d'un centre de dades local cap a Azure— mantenint un punt de recuperació consistent, i orquestra la commutació per error.

Les seves tres capacitats: replicació contínua amb RPO típic de segons a pocs minuts; plans de recuperació que defineixen l'ordre d'arrencada per grups, amb scripts i pauses manuals entre ells; i, la més valuosa, la commutació per error de prova, que aixeca les màquines en una xarxa aïllada de la regió secundària sense afectar producció i sense interrompre la replicació. És el que permet assajar de debò, i és la base del simulacre de l'apartat 10.

Contoso el fa servir exclusivament per a vm-motor-disponibilidad-dev i per a dos servidors locals de Barcelona. Per a les càrregues PaaS no aporta res: app-contoso-reservas-pro es recupera redesplegant des de Bicep en minuts, i db-reservas té el seu propi grup de commutació per error. Site Recovery és l'eina per al que continua sent una màquina, i una plataforma ben migrada en necessita cada vegada menys.

Les peces i la raó de cadascuna. El parell de regions West Europe i North Europe no és arbitrari: Azure va aparellar aquestes regions i això implica actualitzacions de plataforma seqüencials entre totes dues, prioritat de recuperació i replicació geogràfica nativa. fg-contoso-reservas manté la rèplica de db-reservas a North Europe i ofereix un punt de connexió d'escolta estable, de manera que l'aplicació no canvia la seva cadena de connexió en commutar. fd-contoso-global sondeja el punt de salut /salud i encamina cap a la regió sana. L'emmagatzematge és GZRS, que combina redundància de zona a la primària amb rèplica geogràfica.

I la decisió que més es va discutir: pilot lleuger, no actiu-actiu. A North Europe existeixen els plans, les aplicacions, les ranures i la configuració, però amb escala mínima i sense trànsit; en commutar, s'escala i es rep. Les alternatives i la seva realitat econòmica:

Contoso va descartar l'actiu-actiu per dos motius, i el segon va pesar més que el primer: duplicava la factura de producció, i exigia resoldre l'escriptura multiregió a la base de dades, amb conflictes, latència i una complexitat que hauria afectat la fiabilitat diària per protegir-se d'un esdeveniment improbable. L'RTO real mesurat a l'últim simulacre va ser d'1 hora i 47 minuts, dels quals 25 minuts van ser la decisió humana de commutar. És una dada honesta i reveladora: la part més lenta d'una recuperació no sol ser tècnica.

Un pla que viu al cap de la Marta Ríos no és un pla: és un punt únic de fallada amb vacances. plan-recuperacion-contoso és un document versionat a contoso-infra que respon a cinc preguntes.

Qui decideix. La commutació la declara el responsable de guàrdia amb el director d'operacions, amb criteris objectius escrits per endavant —per exemple, «el punt de salut falla des de tres ubicacions durant més de 20 minuts i Azure confirma incidència regional»—. Decidir amb criteris acordats evita la paràlisi de les 3 de la matinada.

En quin ordre. L'ordre importa perquè les dependències existeixen: (1) confirmar l'abast amb l'estat del servei d'Azure; (2) commutar fg-contoso-reservas i verificar que la rèplica accepta escriptures; (3) escalar els plans de North Europe; (4) verificar kv-contoso-pro i les identitats administrades a la regió secundària —l'oblit més freqüent—; (5) redirigir fd-contoso-global; (6) validar amb una compra de prova d'extrem a extrem; (7) reactivar les funcions i els fluxos d'integració.

Com es comunica. Canal d'incidència, avís a atenció al passatger amb un missatge ja redactat, pàgina d'estat pública i actualitzacions cada 30 minuts encara que no hi hagi novetats. El silenci s'interpreta sempre com que ningú no està fent res.

Com es torna. La tornada és més perillosa que l'anada, perquè es fa amb pressa i amb la sensació que ja ha passat el pitjor. Es fa en finestra programada, mai en calent, després de confirmar que la regió primària és estable, resincronitzar les dades en sentit invers i verificar que no s'ha perdut res escrit durant la contingència.

Què cal tenir a mà. Contactes, identificadors de subscripció, la ubicació de les plantilles Bicep i l'accés d'emergència. Amb un matís que s'aprèn per les males: aquest material no pot dependre de la regió caiguda. Contoso guarda una còpia del pla fora d'Azure i un compte d'accés d'emergència amb les seves credencials en custòdia física.

Tota organització té un pla de recuperació. Molt poques en tenen un que funcioni, i la diferència és exactament si s'ha executat alguna vegada. Contoso fa un simulacre semestral amb aquest guió:

1. Preparació (dues setmanes abans): data anunciada, abast definit i criteris d'èxit escrits —RTO objectiu, RPO objectiu, transacció de prova superada—.
2. Congelació: sense desplegaments durant la finestra; regla de processament d'alertes activa per silenciar el soroll previst (07-01).
3. Execució amb cronòmetre, seguint el pla literalment, sense improvisar i sense que ningú «arregli» pel seu compte el que no està escrit. Si el pla està malament, ha de fallar al simulacre.
4. Validació: comprar un bitllet real de prova, emetre'n la targeta d'embarcament i comprovar la telemetria a log-contoso-pro. El criteri d'èxit és de negoci, no tècnic.
5. Tornada enrere controlada, cronometrada també.
6. Autòpsia sense culpables en les 48 hores següents, amb accions concretes, responsables i dates, que s'incorporen al pla.

El que Contoso va aprendre en fer-ho per primera vegada, i que cap document no hauria revelat:

• La cadena de connexió de func-contoso-tarjetas-pro apuntava al servidor primari pel nom, no al punt d'escolta del grup de commutació. Les targetes van deixar d'emetre's tot i que la base de dades estava disponible.
• Ningú no tenia permisos per escalar els plans de North Europe: l'assignació RBAC s'havia fet només al grup de producció primària.
• El certificat del domini secundari havia caducat tres mesos abans, sense que ningú se n'adonés perquè no es feia servir.
• El primer simulacre va durar 4 hores i 20 minuts; el tercer, 1 hora i 47. La millora va venir de descobrir aquestes tres fallades, no de comprar més infraestructura.

Queda el cas més comú de tots, que no és un desastre regional sinó un az group delete a la finestra equivocada. Les defenses, en ordre:

• Bloquejos de recursos: CanNotDelete a tots els grups de producció i als magatzems. És la mesura més barata i més eficaç d'aquesta lliçó. Un bloqueig ReadOnly va més enllà però interfereix amb les operacions normals, així que Contoso el reserva per a rg-contoso-red-pro.
• Subscripció eliminada: es pot reactivar dins d'un termini limitat des de la facturació. Un grup de recursos esborrat, no: no hi ha paperera. L'única cosa que retorna la dada és la còpia de seguretat, i l'única cosa que retorna la infraestructura és el codi.
• Bicep a contoso-infra (mòdul 5): reconstruir la infraestructura completa des de les plantilles, de manera repetible i en minuts. Aquesta és la raó de fons per la qual la infraestructura com a codi no és una preferència estètica: és el teu pla de recuperació de la infraestructura.

I el punt final, el que gairebé ningú no contempla: cal resguardar la configuració, no només les dades. Regles de NSG, assignacions RBAC, configuracions de diagnòstic, definicions d'alertes, directives i regles del WAF. Si tot això viu únicament al portal, restaurar les dades deixa una plataforma que no funciona. A Contoso viu a Bicep, i el que no cap a Bicep s'exporta periòdicament amb un runbook d'aa-contoso-operaciones (07-04) cap a stlagocontosopro. Els secrets de kv-contoso-pro mereixen menció a part: es resguarden amb el seu propi mecanisme i només es poden restaurar en un magatzem del mateix arrendatari i regió geogràfica.

• Confondre replicació amb còpia de seguretat. La rèplica copia també la dada corrupta o xifrada. Necessites totes dues coses.
• Guardar el magatzem al costat del que protegeix. Un esborrat del grup s'emporta dada i còpia alhora.
• No activar la restauració entre regions en crear el magatzem. La redundància no es pot canviar després.
• Retenció massa curta. El ransomware i la corrupció es detecten setmanes més tard.
• Donar per fet que el PaaS fa còpies. Storage no protegeix de l'esborrat sense versionat; AKS no resguarda els teus volums.
• No provar la restauració. Una còpia mai restaurada és una hipòtesi, no una còpia.
• Consell: bloqueja amb CanNotDelete tots els grups de producció avui mateix. Costa un minut.
• Consell: mesura l'RTO real amb cronòmetre al simulacre i publica'l. El número mesurat sempre és pitjor que l'estimat, i aquest és el valor de l'exercici.
• Consell: inclou una prova de negoci a la validació —comprar i emetre—, no només un ping. Els serveis poden respondre i el flux estar trencat.

Exercici 1. El negoci exigeix per a db-reservas un RPO de 0 i un RTO de 5 minuts. Explica què implica tècnicament, què costa i quina contraproposta faries amb arguments.

Exercici 2. Un ransomware ha xifrat vm-motor-disponibilidad-dev i s'ha detectat sis dies després. Descriu la recuperació pas a pas i quines mesures preventives n'haurien reduït l'impacte.

Exercici 3. Contoso Millas (centro-coste=CC-2077) va a producció amb una base de dades PostgreSQL flexible, blobs de justificants de bescanvi i una Container App. Dissenya la seva estratègia de còpies i recuperació amb RPO i RTO justificats, indicant què aporta cada servei pel seu compte i què cal afegir-hi.

Solució 1: un RPO de 0 exigeix replicació síncrona: cada transacció es confirma a les dues regions abans de respondre a l'usuari. Això afegeix la latència d'anada i tornada entre West Europe i North Europe a cada escriptura, degradant el rendiment de la compra en condicions normals per protegir-se d'un esdeveniment que passa cada uns quants anys; i fg-contoso-reservas, que és asíncron, no ho proporciona. Un RTO de 5 minuts exigeix commutació automàtica sense decisió humana, amb la infraestructura secundària ja escalada i funcionant —actiu-actiu, amb el 100 % de cost addicional de la taula de l'apartat 8— i amb el risc afegit d'una commutació espúria davant d'un problema transitori de xarxa. Contraproposta: mantenir l'RPO en 5 minuts, que és el que dona la replicació asíncrona sense penalitzar l'operació diària, i baixar l'RTO a 30 minuts amb dues mesures barates: criteris de decisió preacordats i automatitzats fins al punt de l'aprovació —els 25 minuts de deliberació mesurats en són el sumand més gran—, i un runbook que escali North Europe automàticament en detectar-se la condició. Argument per al negoci: quantificar el cost d'una hora d'aturada i comparar-lo amb el cost anual de l'actiu-actiu; si el segon supera el primer multiplicat per la probabilitat anual de l'esdeveniment, la inversió no es justifica. I complementar amb degradació elegant: una memòria cau de només lectura que permeti consultar reserves durant la commutació protegeix l'experiència del passatger per una fracció del preu.

Solució 2: recuperació. (1) Aïllar: treure la màquina de la xarxa amb un NSG que bloquegi tot, sense apagar-la si es vol preservar evidència de memòria; no restaurar sobre la màquina compromesa. (2) Determinar la data d'infecció amb la telemetria de log-contoso-pro i AzureActivity, buscant el primer indici anòmal: sis dies de detecció signifiquen que els punts més recents probablement ja estan xifrats. (3) Triar un punt de recuperació anterior a aquesta data, cosa que només és possible gràcies a la retenció de 30 punts diaris de pol-backup-vm-diaria. (4) Restaurar a una màquina nova en un grup aïllat, verificar que està neta i només llavors reintegrar-la. (5) Comprovar que el magatzem no va ser atacat, revisant AzureActivity a la cerca d'intents d'esborrat de punts. (6) Rotar totes les credencials accessibles des d'aquella màquina. (7) Autòpsia i notificació de seguretat segons escaigui. Prevenció: immutabilitat del magatzem i eliminació temporal irreversible, que és el que impedeix que l'atacant esborri els punts; autorització multiusuari perquè un sol compte compromès no basti; retenció llarga, sense la qual sis dies de latència deixarien sense punt net; alertes de Defender for Cloud i sobre operacions d'esborrat al magatzem; i RBAC mínim, perquè l'atac a les còpies requereix permisos que gairebé ningú no hauria de tenir.

Solució 3: per criticitat, un projecte de fidelització no bloqueja la venda de bitllets, així que RPO d'1 hora i RTO de 8 hores són raonables i molt barats de sostenir; convé escriure-ho i que el negoci ho signi. PostgreSQL flexible aporta pel seu compte còpies automàtiques: cal ampliar la retenció a 35 dies, activar la redundància geogràfica de còpies i exportar l'esquema amb cada desplegament; no cal rèplica de lectura en una altra regió per a aquest RTO. Blobs de justificants: la redundància no protegeix de l'esborrat, així que cal activar versionat, eliminació temporal de blobs i contenidors, i còpia operativa des de bv-contoso-pro; si els justificants tenen valor probatori, a més una directiva d'immutabilitat temporal. Container App: no guarda estat, es reconstrueix des de la imatge d'acrcontosopro i la plantilla Bicep, amb la precaució de conservar les imatges etiquetades al registre i la seva pròpia redundància geogràfica. Transversalment: magatzem a rg-contoso-seguridad-pro, bloqueig CanNotDelete al grup de producció, configuració a Bicep dins de contoso-infra, i un simulacre anual —no semestral, atès el nivell— el criteri d'èxit del qual sigui bescanviar punts de prova d'extrem a extrem. Etiquetes: entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario.

Ja distingeixes còpia de seguretat de recuperació davant desastres, i saps que la replicació no protegeix de l'error ni de l'atac perquè replica fidelment la dada corrupta. Domines els dos números que governen totes les decisions —RPO i RTO—, la conversa amb el negoci que els fixa i la seva traducció a diners, amb la taula de nivells de Contoso que assigna una hora d'RTO a db-reservas i setanta-dues a l'analítica de manera deliberada. Coneixes Azure Backup, els seus dos magatzems rsv-contoso-pro i bv-contoso-pro, la directiva pol-backup-vm-diaria amb retenció d'avi-pare-fill, i per què el magatzem viu separat del que protegeix. Saps triar la redundància —amb el parany que és immutable després de la primera protecció— i protegir les còpies del mateix atacant amb eliminació temporal irreversible, immutabilitat i autorització multiusuari, perquè una còpia que un atacant amb permisos pot esborrar no és una còpia. I saps restaurar en les tres granularitats, inclosa la de fitxers solts que resol el 90 % dels casos reals.

Tens clara la frontera del PaaS: què resguarda cada servei pel seu compte i què continua sent teu, amb els tres avisos que surten més cars —Storage no protegeix de l'esborrat sense versionat, Key Vault necessita protecció contra purga activada, i AKS no resguarda els teus volums—. Situes Azure Site Recovery en el seu àmbit, el que continua sent una màquina, amb la seva commutació per error de prova. I comprens l'estratègia de Contoso al complet: parell de regions West Europe i North Europe, fg-contoso-reservas, fd-contoso-global, emmagatzematge GZRS i la decisió raonada de pilot lleuger en lloc d'actiu-actiu, amb el seu cost del 15 % i el seu RTO mesurat d'1 hora i 47 minuts. Per damunt de la tecnologia t'endus les dues peces que de debò decideixen el resultat: el pla escrit —qui decideix, en quin ordre, com es comunica, com es torna— i el simulacre semestral, que a Contoso va destapar una cadena de connexió mal apuntada, uns permisos que faltaven i un certificat caducat, tres coses que cap document no hauria revelat. Més els bloquejos, Bicep com a pla de recuperació de la infraestructura i la còpia de la configuració, no només de les dades.

Amb això es tanca el mòdul 7 i val la pena mirar enrere. Contoso Airlines hi va entrar amb una plataforma distribuïda que ningú no sabia operar i en surt amb una de ben diferent: observable, perquè Azure Monitor recull mètriques, registres i traces, i les configuracions de diagnòstic porten tot a log-contoso-pro; investigable, perquè KQL converteix la queixa d'un passatger en una causa arrel en cinc consultes i la funció SeguirLocalizador posa aquesta capacitat a l'abast de qualsevol; traçable d'extrem a extrem, perquè Application Insights correlaciona la reserva a través dels sis components que l'atenen; automatitzada, perquè aa-contoso-operaciones executa la feina repetitiva amb identitat administrada, versionat i vigilància; i ara recuperable, amb còpies immutables, un pla escrit i un simulacre que el posa a prova dues vegades l'any. La pregunta «què li va passar a aquesta reserva?» té resposta, i la pregunta «i si demà desapareix tot?» també.

Queda una conversa pendent, i és la que la Nuria Peña fa mesos que demana. Cada decisió d'aquestes set lliçons ha tingut un preu: les regions aparellades, les rèpliques, els conjunts d'escalat, l'àrea de Log Analytics amb la seva ingesta, el pilot lleuger de North Europe, les còpies amb trenta dies de retenció. Ningú a Contoso no sap avui, amb precisió, quant costa cada peça de la plataforma, ni quina part d'aquesta factura és valor i quina part és malbaratament. El mòdul 8, Gestió i optimització de costos, aborda exactament això: com s'estima abans de desplegar, com s'analitza i es pressuposta després, quins descomptes existeixen i quan compensen, què recomana Azure Advisor i com es construeix una cultura FinOps que optimitzi sense trencar res. I comença per on cal començar: aprenent a estimar el cost abans de crear el recurs, amb la calculadora de preus, perquè la factura més difícil de corregir és la que ja has provocat.