La Nuria Peña, responsable financera de Contoso Airlines, fa mesos que formula la mateixa pregunta al comitè i rep la mateixa resposta imprecisa. Quan es va aprovar la migració, algú va posar en una diapositiva «uns 8.500 € al mes». La factura mitjana del primer trimestre real va ser de 17.500 € al mes: exactament el doble. Ningú no va mentir. Simplement, l'estimació es va fer sumant màquines virtuals i bases de dades, que és el que tothom estima, i es va oblidar tota la resta: el tallafoc, el bastió, la passarel·la global, la ingesta de registres, la sortida de dades i un clúster de Kubernetes els nodes del qual algú creia que eren «part d'AKS».

Aquesta lliçó ensenya a estimar abans de desplegar. Veuràs com factura Azure de debò —quina unitat de mesura fa servir cada família de serveis—, els tres tipus de cost que gairebé ningú no estima, el maneig complet de la calculadora de preus, l'estimació reconstruïda de tota la plataforma de Contoso línia per línia, la calculadora de cost total de propietat per comparar-la amb el centre de dades de Barcelona, per què la mateixa màquina costa diferent en dues regions, com automatitzar estimacions amb l'API de preus minoristes i, sobretot, com es documenta el marge d'error, perquè una estimació sense supòsits escrits no és una estimació: és una xifra.

Avís sobre els preus d'aquesta lliçó i de tot el mòdul: totes les xifres en euros que hi apareixen són orientatives i fictícies, triades perquè els ordres de magnitud i les proporcions siguin didàctics. Els preus reals d'Azure canvien amb freqüència, varien per regió, per moneda, per tipus d'oferta i per descomptes contractats. Cap xifra d'aquest mòdul no s'ha de fer servir per decidir res: consulta sempre la calculadora oficial de preus d'Azure i el teu propi acord comercial.

1. Per què estimar abans de desplegar
2. Com factura Azure de debò: unitats de mesura
3. Els tres costos que gairebé ningú no estima
4. La calculadora de preus d'Azure, pas a pas
5. L'estimació completa de Contoso Airlines
6. La calculadora de cost total de propietat
7. Preus per regió: la mateixa VM a dos preus
8. L'API de preus minoristes
9. El marge d'error i els supòsits escrits
10. L'estimació com a part del disseny
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

En un centre de dades propi, gastar diners exigeix una ordre de compra, una signatura i unes quantes setmanes. A Azure exigeix tres clics. Aquesta és tota la diferència, i és enorme: el control de la despesa s'ha desplaçat del departament de compres al teclat de l'enginyer, i ningú no va avisar l'enginyer.

La conseqüència és un patró que es repeteix a totes les organitzacions que migren:

L'estimació és l'única palanca que actua a la primera fila. Dit d'una altra manera: la factura més difícil de corregir és la que ja has provocat. Un nivell de redundància triat a la lleugera el primer dia es converteix en una migració de dades l'any següent.

I hi ha un segon motiu, menys obvi i més important: estimar obliga a entendre l'arquitectura. Quan la Marta Ríos va refer l'estimació de Contoso amb la calculadora, va descobrir tres coses que feia mesos que hi eren sense que ningú no les veiés —una rèplica geogràfica de base de dades que costava gairebé el mateix que la principal, un grup de nodes d'AKS dimensionat per a una prova de càrrega que va acabar al març, i una passarel·la de VPN sense cap connexió activa—. Estimar és auditar el disseny amb una calculadora a la mà.

L'error de fons de l'estimació fallida de Contoso va ser mental: es va pensar en Azure com en un catàleg de màquines amb preu mensual. Azure factura unitats de consum, i cada família de serveis fa servir la seva. Fins que no interioritzes la taula següent, no pots estimar res.

Tres lectures d'aquesta taula que canvien la manera d'estimar:

• La unitat no sempre és el recurs que veus. No pagues app-contoso-reservas-pro; pagues plan-contoso-reservas-pro, i tant se val que hi allotgis una aplicació o cinc.
• Gairebé tot té una segona unitat. L'emmagatzematge té GB i transaccions. El tallafoc té hores i gigabytes processats. La base de dades té còmput i emmagatzematge i còpies. Estimar només la unitat principal produeix sistemàticament estimacions baixes.
• Algunes unitats no són proporcionals a l'ús que perceps. Una consulta mal escrita a Synapse sense servidor llegeix 2 TB i costa més que un dia sencer de màquines virtuals, encara que l'usuari només hagi premut «actualitza».

De l'estimació fallida de Contoso, gairebé la meitat de la desviació va venir de tres partides que ni tan sols apareixien al full de càlcul original.

Sortida de dades (egress). El trànsit cap a Azure és gratuït; el trànsit **des d'**Azure cap a internet, no. I tampoc no és gratuït el trànsit entre regions, ni en molts casos entre zones de disponibilitat. Tal com s'avançava al mòdul 2, aquesta és la sorpresa habitual de la factura, perquè no apareix en cap recurs: no hi ha cap objecte anomenat «sortida de dades» al portal que puguis mirar. A Contoso la produeix tot això alhora: cada targeta d'embarcament descarregada per un passatger, cada resposta de l'API de Disponibilitat als agregadors externs, la replicació de db-reservas a North Europe, la replicació geogràfica d'acrcontosopro i les exportacions nocturnes cap al sistema de facturació local. S'estima amb una regla senzilla: quants objectes surten al mes × mida mitjana, i es documenta el supòsit.

Transaccions i operacions. Els GB d'un compte d'emmagatzematge s'estimen bé; les transaccions, gairebé mai. I en càrregues amb molts objectes petits —que és exactament el cas de les targetes d'embarcament— les transaccions poden superar l'emmagatzematge. Encara pitjor: els nivells freds abarateixen el GB-mes i encareixen la transacció, de manera que un cicle de vida mal ajustat que mogui a Cool dades que encara es llegeixen molt pot apujar la factura. El mateix s'aplica a les operacions de Key Vault, a les peticions de Cosmos DB i a les operacions de Defender for Cloud sobre Storage.

Les funcions «gratis» que arrosseguen un recurs de pagament. Aquest és el més traïdor, perquè el servei anuncia cost zero i ho compleix:

La regla que cal gravar-se: quan activis alguna cosa gratuïta, pregunta't sempre quin consum genera aigües avall. Les configuracions de diagnòstic del mòdul 7 són gratis i van produir la tercera partida més cara de la plataforma.

La calculadora de preus d'Azure (azure.microsoft.com/pricing/calculator) és una eina pública, sense necessitat de compte, que permet muntar una estimació completa. És enganyosament simple, i fer-la servir bé té mètode.

El procediment que segueix la Marta:

1. Buscar el servei i afegir-lo. La calculadora té un catàleg per categories i un cercador. Afegeix cada servei de l'arquitectura, inclosos els que «no costen» —per deixar constància que s'han considerat—.
2. Configurar regió, nivell i quantitat. Aquí hi ha el 90 % de la feina. Per a una VM: regió, sistema operatiu, tipus d'instància, nombre d'instàncies, hores al mes (730 si és 24x7, unes 176 si només és horari laborable), tipus de disc i nombre de discos, i l'opció d'estalvi (pagament per ús, reserva d'1 o 3 anys, pla d'estalvi, spot). Aquest selector és el que connecta aquesta lliçó amb la 08-03.
3. Agrupar per component. La calculadora permet crear grups i reanomenar-los. Contoso fa servir un grup per bloc de l'arquitectura: Frontal web, API de Disponibilitat, Dades, Xarxa i seguretat, Observabilitat, Integració i IA, Desenvolupament. Sense grups, una estimació de quaranta línies és il·legible i ningú no la revisa.
4. Fixar moneda, regió de facturació i programa de llicències. La calculadora aplica el tipus d'oferta (pagament per ús, Enterprise, CSP) i permet indicar un percentatge de descompte negociat.
5. Desar i compartir. Amb un compte Microsoft, l'estimació es desa i s'obté un enllaç. És el que s'adjunta a la revisió d'arquitectura.
6. Exportar a full de càlcul. El botó d'exportació genera un .xlsx amb una fila per línia, que és el format amb el qual la Nuria pot treballar i comparar mesos.

Dos advertiments d'ús. El primer: la calculadora no coneix la teva càrrega; només multiplica el que li diguis. Si hi poses 730 hores per a una màquina que en realitat estarà encesa 200, la culpa no és de l'eina. El segon: hi ha serveis el cost dels quals no es pot estimar sense dades prèvies —sortida de dades, transaccions, tokens, GB ingerits—; per a aquests, la calculadora t'obliga a introduir una quantitat, i aquesta quantitat és un supòsit que cal documentar (apartat 9).

La Marta va refer l'estimació de la plataforma tal com és avui. El resultat, en euros mensuals orientatius i ficticis:

D'on surt cada bloc mereix comentari, perquè l'aprenentatge és aquí:

• Les cinc línies que sorprenen són, per aquest ordre: log-contoso-pro (1.500 €, més que la meitat de la plataforma web), fw-contoso-hub-pro (1.010 €, que factura per hora i per gigabyte processat tant si hi passa trànsit com si no), el clúster aks-contoso-operaciones (1.980 €, perquè els nodes són màquines virtuals que es paguen senceres), bastion-contoso-pro (205 € per un servei que es fa servir quinze minuts al dia) i fd-contoso-global (385 € pel nivell Premium que exigeix el WAF).
• La rèplica de db-reservas costa 1.180 €, un 80 % de la principal. És el preu explícit de la decisió de recuperació del mòdul 7, i ara es veu en euros: exactament la mena de dada que permet una conversa honesta amb el negoci.
• La sortida de dades (700 €) no correspon a cap recurs. Ningú no l'hauria estimada sense la taula de l'apartat 2.
• Tot l'entorn de desenvolupament són 285 € gràcies al runbook Detener-IniciarEntornosDev i al nivell sense servidor amb pausa automàtica. Sense aquestes dues decisions rondaria els 1.100 €.

Comparat amb els 8.500 € de la diapositiva original, la diferència s'explica gairebé sencera amb cinc línies: AKS, Log Analytics, tallafoc, la rèplica de base de dades i la sortida de dades. Cap d'elles no és un recurs que l'equip hagués «demanat»; totes són conseqüències de decisions d'arquitectura correctes que ningú no va traduir a diners.

La Nuria va fer la pregunta inevitable: «no era més barat el centre de dades de Barcelona?». Per respondre-la existeix la calculadora de cost total de propietat (TCO), una eina diferent de la de preus: es descriu la infraestructura local —servidors, nuclis, memòria, emmagatzematge, amplada de banda, llicències— i retorna una comparació a diversos anys davant de l'equivalent a Azure.

El valor de l'eina no és el número que produeix, sinó que obliga a incloure els costos que la comptabilitat local mai no imputa al projecte:

Amb la calculadora de TCO i aquests ajustos, la comparació de Contoso va quedar així (xifres orientatives i fictícies, anuals):

La conclusió que Contoso va escriure, i que convé copiar literalment en qualsevol informe: la comparació no és «Azure és més barat», sinó «Azure és més barat que un centre de dades honestament comptabilitzat, i a més converteix inversió en despesa operativa, elimina la sobrecapacitat i aporta capacitats —redundància geogràfica, escalat en minuts, serveis administrats— que el centre de dades no tenia a cap preu». Comparar només maquinari contra factures d'Azure és la manera més habitual d'enganyar-se un mateix.

La mateixa mida d'instància costa diferent a West Europe, a North Europe, a Suècia Central o als Estats Units. Les causes són reals: cost de l'energia i del terreny, impostos, maduresa del centre de dades, tipus de canvi i demanda local.

Índex orientatiu i fictici prenent West Europe com a 100 per a una mateixa VM:

La temptació és òbvia: moure càrregues a la regió més barata. Abans de fer-ho, quatre frens que Contoso va aplicar:

• Latència. El web de reserves serveix passatgers europeus. Un 13 % d'estalvi en còmput no compensa 120 ms addicionals a cada compra.
• Residència de la dada. Les dades personals de passatgers i tripulacions no surten de la UE. És una restricció legal, no una preferència, i la imposa la directiva de regions permeses del mòdul 4.
• Sortida entre regions. Repartir components que es parlen molt entre dues regions converteix trànsit intern gratuït en trànsit entre regions facturat.
• Disponibilitat del servei. No tots els serveis ni totes les mides existeixen a totes les regions, i les zones de disponibilitat tampoc.

La regla pràctica: la regió es tria per latència, residència de la dada i disponibilitat de serveis, i només es fa servir el preu com a criteri de desempat, o per a càrregues que no tenen cap d'aquestes lligadures —per exemple, un processament per lots nocturn sense dades personals—.

Per automatitzar estimacions —o per comparar regions sense obrir la calculadora quaranta vegades— Azure publica l'API de preus minoristes (Retail Prices), pública, sense autenticació i sense cost. Retorna els preus de tarifa oficial, sense els teus descomptes negociats.

El paràmetre $filter fa servir sintaxi OData i admet serviceName, armRegionName, armSkuName, meterName, priceType (Consumption, Reservation, DevTestConsumption) i reservationTerm. La clàusula select de jq descarta les variants amb llicència de Windows, que apareixen barrejades amb les de Linux i són l'error de lectura més comú.

Bucle equivalent sobre diverses regions —l'ús que més rendiment dona— substituint armRegionName eq '$REGION' dins d'un for REGION in westeurope northeurope swedencentral eastus, prenent [.Items[].retailPrice] | min i multiplicant per 730 hores per obtenir el mes mitjà. La resposta ve paginada mitjançant el camp NextPageLink, així que per a consultes àmplies cal iterar. Un ús molt pràctic: mantenir a contoso-infra un script que, a cada sol·licitud d'incorporació de canvis que modifiqui un .bicep, consulti els preus de les SKU declarades i publiqui l'estimació com a comentari automàtic a la mateixa sol·licitud (apartat 10).

Cada element retornat té aquesta forma. Fixa't en unitOfMeasure: és la clau per no equivocar-se de tres ordres de magnitud. Hi ha mesuradors expressats en «1 Hour», d'altres en «1 GB/Month», d'altres en «10K» operacions i d'altres en «1M» tokens. Multiplicar sense llegir aquesta columna és l'error clàssic de qui automatitza estimacions per primera vegada.

Una estimació és un model, i tot model té error. La diferència entre una estimació professional i una xifra improvisada és que la primera declara el seu error i els seus supòsits.

Els components de l'estimació de Contoso es classifiquen per previsibilitat:

I així s'estima el que és variable, que és on tothom es rendeix:

• Escalat automàtic: no s'estima el màxim ni el mínim, sinó el perfil horari esperat. Contoso va documentar: 2 instàncies de 00:00 a 07:00, 6 de 07:00 a 22:00, i un perfil apertura-temporada-verano amb mitjana de 14 durant tres setmanes. La mitjana ponderada mensual va sortir 6, i per això la línia diu 6 i no 20.
• Transaccions i sortida: s'estimen des del negoci, no des de la infraestructura. «92.000 reserves al mes × 1,4 targetes per reserva × 180 KB» dona els gigabytes de sortida de targetes; la resta s'acota amb un factor.
• Tokens: consum per interacció × interaccions esperades, amb un límit dur configurat al servei perquè l'error no sigui il·limitat.

El coixí de Contoso: sobre els 17.450 € base, un 15 % de contingència dona 20.070 €/mes, i aquesta és la xifra que es va portar al comitè. És deliberadament conservadora, i respon a una asimetria real: quedar-se curt en una estimació costa credibilitat davant de finances; passar-se una mica produeix una bona notícia. La regla escrita va ser: «es pressuposta l'estimació amb coixí; es persegueix l'estimació base».

Els supòsits van al document, no al cap:

Aquest fitxer viu al costat de les plantilles a contoso-infra. El seu valor apareix tres mesos després, quan la factura no quadra: es compara el supòsit amb la realitat i se sap què va fallar, no només quant.

Que el cost deixi de ser una sorpresa exigeix integrar-lo en dos moments del procés, no en una revisió anual.

A la revisió d'arquitectura. Cap proposta no s'aprova a Contoso sense una estimació adjunta amb els seus supòsits i, quan hi ha alternatives, sense una taula comparativa. Exemple real del disseny de l'API de Disponibilitat:

Fixa't que no va guanyar l'opció més barata, i aquest és el punt: l'estimació no decideix, informa. El que sí que és inacceptable és decidir sense ella.

A la sol·licitud d'incorporació de canvis d'infraestructura. Tota modificació d'un .bicep a contoso-infra (05-06) passa per una comprovació automatitzada que compara les SKU declarades contra la branca principal i comenta l'impacte:

La sortida es publica com a comentari a la sol·licitud, amb el format de taula markdown ja muntat. L'efecte cultural és més gran que el tècnic: qui proposa un canvi en veu el preu abans que ningú no l'hi pregunti, i la conversa sobre cost passa en el moment en què corregir-lo és gratis.

• Estimar només el còmput i les bases de dades. És exactament l'error que va duplicar la factura de Contoso. Recorre la taula d'unitats de l'apartat 2 servei per servei.
• Oblidar la sortida de dades. No té recurs propi, no apareix al portal com a objecte i sol ser una de les deu primeres partides.
• Confondre el recurs amb la unitat facturada. Es paga el pla, no l'aplicació; els nodes, no el clúster; el vCore-hora, no la base de dades.
• Posar 730 hores a tot, o estimar el màxim de l'escalat automàtic. El primer infla els entorns apagats de nit; el segon produeix xifres que ningú no es creu i desprestigien l'estimació sencera. Estima el perfil, i declara el màxim com a risc.
• Llegir malament unitOfMeasure a l'API. «1M tokens» i «1K operacions» conviuen a la mateixa resposta.
• Activar alguna cosa gratuïta sense mirar aigües avall. Les configuracions de diagnòstic són gratis; la ingesta que provoquen, no.
• Consell: agrupa l'estimació per component d'arquitectura, no per servei d'Azure. Ningú no discuteix «Storage»; tothom discuteix «quant costa l'API de Disponibilitat».
• Consell: desa l'estimació amb enllaç i exporta-la a full de càlcul el dia que la facis, i revisa-la quan canviï l'arquitectura, no quan arribi la factura.

Exercici 1. Estima amb la calculadora oficial —fes servir la teva regió i la teva moneda— un entorn de desenvolupament equivalent al de Contoso: un pla d'App Service bàsic, una base de dades SQL sense servidor amb pausa automàtica, un compte d'emmagatzematge LRS de 200 GB i una VM de 2 vCPU encesa només en horari laborable. Agrupa per component, exporta i anota quins tres supòsits t'has hagut d'inventar.

Exercici 2. Contoso Millas (centro-coste=CC-2077) està a punt de llançar-se: web a App Service, PostgreSQL flexible, blobs de justificants, una Function que calcula punts, un Event Grid i un tauler a Log Analytics. Construeix la llista de totes les unitats de mesura que caldrà estimar, marcant quines són fixes, variables acotades i variables obertes, i quin marge aplicaries a cada grup.

Exercici 3. Un company proposa moure vmss-api-disponibilidad-pro de West Europe a East US perquè «costa un 13 % menys». Escriu la resposta tècnica i econòmica: quins costos nous apareixen, quines restriccions ho impedeixen i quines càrregues de Contoso sí que serien candidates legítimes a aquesta mudança.

Solució 1: l'exercici importa pels supòsits, no pel total. Els tres que inevitablement cal inventar-se són: (1) hores de la VM —176 h al mes amb el patró laborable de 8 h × 22 dies, davant de les 730 que la calculadora proposa per defecte—; (2) segons de còmput de la base sense servidor, que depenen de quantes hores al dia treballa l'equip i de la finestra de pausa automàtica configurada, i que en desenvolupament sol quedar en un 15-25 % del mes; i (3) transaccions de l'emmagatzematge, que la calculadora demana en operacions d'escriptura, lectura i llistat i que en desenvolupament ningú no ha mesurat mai. A més hi ha dos costos que gairebé segur que s'han omès i cal afegir: el disc gestionat de la VM, que es factura encara que la màquina estigui desassignada, i la seva IP pública si en té. Comprovació de sensatesa: en un entorn així, el disc i la base de dades solen pesar més que el còmput, precisament perquè el còmput s'apaga i l'emmagatzematge no.

Solució 2: unitats per servei i la seva classificació. Fixes (±5 %): hora del pla d'App Service; vCore-hora i GB-mes de PostgreSQL flexible si està aprovisionat; rèplica d'alta disponibilitat si s'activa. Variables acotades (±25 %): execucions i GB-segon de la Function si està en pla de consum —acotada perquè el nombre de bescanvis té un sostre conegut—; operacions d'Event Grid; GB-mes dels blobs, que creixen de manera previsible al ritme de bescanvis. Variables obertes (±50 %): transaccions de l'emmagatzematge, que en justificants petits poden superar el GB-mes; GB ingerits a log-contoso-pro per les configuracions de diagnòstic del projecte, que és la partida que més se subestima; i sortida de dades per la descàrrega de justificants. Costos gratuïts amb consum aigües avall que cal declarar encara que valguin zero: Event Grid té una franja gratuïta generosa, les etiquetes i directives no costen, però l'assignació diagnostico-app-service heretada de la iniciativa «Base de governança de Contoso» generarà ingesta des del primer dia. Marge global recomanat: 15 % sobre el total, amb els supòsits de bescanvis mensuals i mida mitjana de justificant escrits al document.

Solució 3: l'estalvi del 13 % s'aplica només a la línia de còmput (1.320 € → uns 1.150 €, uns 170 € al mes), i contra això apareixen costos nous: sortida entre regions per cada consulta de disponibilitat que el VMSS faci a db-reservas i a cosmos-contoso-tarifas-pro, que continuen a West Europe —trànsit avui intern i gratuït que passaria a facturar-se i que, amb el volum de l'API, es menja l'estalvi amb escreix—; latència d'anada i tornada transatlàntica a cada petició, que degrada la disponibilitat mostrada al passatger; i doble operació, perquè caldria replicar xarxa, NSG, punts privats, bastion, regles de fw-contoso-hub-pro i configuracions de diagnòstic en una segona regió. La restricció que ho tanca sense discussió és de compliment: les dades de passatgers no surten de la UE, i la directiva de regions permeses del mòdul 4 denegarà el desplegament. Càrregues que sí que serien candidates legítimes: processos per lots nocturns sobre dades ja anonimitzades, agents de compilació autoallotjats de contoso-reservas-ci —que a més poden anar en instàncies d'accés puntual (08-03)—, i entrenaments o proves de càrrega puntuals sense dades personals. Regla general: es mou per preu allò que no té latència crítica, ni dades regulades, ni conversa intensa amb recursos d'una altra regió.

Ja saps per què l'estimació és l'única palanca que actua quan corregir encara és gratis, i per què l'error de Contoso —duplicar la previsió— no va ser de càlcul sinó de model mental: Azure no és un catàleg de màquines amb preu mensual, sinó un conjunt d'unitats de consum. Tens la taula d'aquestes unitats per família de servei —hora d'instància, hora de pla, GB-mes, transacció, unitat de sol·licitud, TB llegit, GB ingerit, GB de sortida, execució, token, instància protegida—, l'advertiment que gairebé tot té una segona unitat que ningú no estima, i els tres costos que s'obliden sempre: la sortida de dades, que no té recurs a què mirar; les transaccions, que en objectes petits superen l'emmagatzematge; i les funcions «gratuïtes» que arrosseguen consum aigües avall, amb les configuracions de diagnòstic com a exemple perfecte.

Manegues la calculadora de preus amb mètode —buscar, configurar regió, nivell, quantitat i hores, agrupar per component, fixar moneda i oferta, desar, compartir i exportar— i has vist l'estimació completa de Contoso: 17.450 €/mes orientatius, amb les cinc línies que sorprenen identificades —Log Analytics, el tallafoc, els nodes d'AKS, el bastió i Front Door— més la rèplica de db-reservas, que costa el 80 % de la principal i posa preu explícit a la decisió de recuperació del mòdul 7. Saps fer servir la calculadora de cost total de propietat i quins costos ocults del centre de dades cal sumar perquè la comparació sigui honesta: energia, personal, espai, renovació, sobrecapacitat i risc. Entens per què la mateixa VM costa diferent a cada regió i per què la regió es tria per latència, residència de la dada i disponibilitat, amb el preu només com a desempat; i pots automatitzar-ho amb l'API de preus minoristes, vigilant sempre unitOfMeasure. Per damunt de l'eina t'endus el que converteix una xifra en una estimació: el marge d'error declarat, la manera d'estimar el que és variable a partir del perfil horari i del negoci en lloc del màxim teòric, el coixí del 15 % que va portar els 17.450 € als 20.070 € pressupostats, i el fitxer de supòsits i riscos versionat al costat de les plantilles.

Però una estimació, per bona que sigui, continua sent una hipòtesi. La pregunta de la Nuria —«per què puja la factura cada mes?»— només es respon amb dades reals: què s'ha gastat, en quin recurs, de quin equip, quin dia i per què. Això és Azure Cost Management, i és la lliçó següent: la jerarquia de facturació i la seva diferència amb la de recursos, l'anàlisi de costos agrupada per servei, ubicació, grup de recursos i etiqueta —on per fi es cobra la disciplina de centro-coste=CC-1042 sembrada al mòdul 1 i forçada per la política hereda-centro-coste del mòdul 4—, els pressupostos amb les seves alertes automatitzades, el repartiment entre equips, les exportacions a stlagocontosopro i la detecció d'anomalies. D'estimar el cost passem a mesurar-lo.