La factura de juliol de Contoso Airlines van ser 17.800 €, i tota ella es va pagar a tarifa de pagament per ús: la més flexible que existeix i, precisament per això, la més cara. Azure cobra un sobrepreu per no exigir-te cap compromís, i quan fa nou mesos que executes els mateixos set nodes de Kubernetes vint-i-quatre hores al dia, pagar per una flexibilitat que no fas servir és llençar diners.

Aquesta lliçó tracta del mecanisme de descompte més potent d'Azure i del que menys s'aprofita: comprometre's. Veuràs què són les instàncies reservades —terminis, formes de pagament, àmbits, flexibilitat d'instància, intercanvi i reemborsament—, en què es diferencien dels plans d'estalvi, quan tolera una càrrega les instàncies d'accés puntual, com es reutilitzen llicències amb Azure Hybrid Benefit, què són els nivells de desenvolupament i proves, i la decisió de compra completa de Contoso amb la seva taula d'estalvi i el seu punt d'equilibri. I sobretot veuràs el risc, perquè aquest és l'únic capítol del mòdul on equivocar-se costa diners de debò: reservar abans d'estabilitzar l'arquitectura és la manera més cara que existeix d'estalviar.

Recordatori: totes les xifres i percentatges de descompte d'aquesta lliçó són orientatius i ficticis. Els descomptes reals depenen del servei, la regió, la SKU, el termini, la moneda i el teu acord comercial, i canvien amb freqüència. Consulta sempre la calculadora oficial i la pàgina de preus del servei abans de comprar res.

1. El principi: flexibilitat davant de preu
2. Instàncies reservades
3. Flexibilitat d'instància i com s'aplica el descompte
4. Intercanvi, reemborsament i cancel·lació
5. Plans d'estalvi d'Azure
6. Reserva o pla d'estalvi: criteris de decisió
7. Instàncies d'accés puntual
8. Azure Hybrid Benefit
9. Nivells de desenvolupament i proves
10. La decisió de compra de Contoso
11. El risc de comprometre's
12. Utilització, seguiment i recomanacions automàtiques
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Tot el capítol es resumeix en un eix. En un extrem, el pagament per ús: encens i apagues quan vulguis, pagues per hora, preu màxim. A l'altre, el compromís a tres anys pagat per avançat: preu mínim, i si demà canvies d'arquitectura els diners ja estan gastats.

Els percentatges són orientatius i varien enormement per servei i regió. El que no varia és la forma de la corba: com més et compromets, menys pagues. L'habilitat no és comprometre's molt, sinó comprometre's exactament amb la part de la plataforma que saps que continuarà existint.

Una reserva és un compromís de consumir una capacitat concreta —una mida de VM, una quantitat de vCore de SQL, unes RU/s de Cosmos DB— durant un o tres anys, a canvi d'un preu per hora rebaixat. És important entendre què no és: no és una màquina que Azure t'aparta, ni t'obliga a tenir res encès. És un descompte de facturació que s'aplica automàticament a l'ús que coincideixi amb el que has reservat. Si no tens ús que hi coincideixi, aquella hora es perd.

Els paràmetres de compra:

L'àmbit és la decisió que més errors produeix. Compartit permet que el descompte s'apliqui a qualsevol subscripció del compte de facturació, cosa que maximitza la probabilitat d'aprofitar-lo; àmbit d'una subscripció o d'un grup de recursos el restringeix, i només té sentit quan es vol que el descompte beneficiï un centre de cost concret —chargeback, apartat 7 de la lliçó anterior—. L'àmbit de grup d'administració és el terme mitjà: el descompte s'aplica a qualsevol subscripció dins d'aquell grup, que és el que Contoso fa servir perquè les reserves comprades per plataforma no s'«escapin» a projectes aliens.

Serveis que admeten reserva (llista orientativa, canvia amb el temps):

I el criteri de fons: es reserva el que està encès de manera sostinguda. Si un recurs està apagat la meitat del temps —pel runbook Detener-IniciarEntornosDev, per escalat automàtic o perquè és de temporada— la reserva paga hores que no consumeixes i el descompte efectiu s'ensorra.

Un dubte raonable en comprar una reserva de VM: he d'executar exactament aquella mida? Per a la majoria de famílies, no. La flexibilitat de mida d'instància fa que la reserva s'expressi en «unitats» de la família i s'apliqui a qualsevol mida de la mateixa sèrie dins de la mateixa regió.

Exemple amb les màquines de Contoso (relacions orientatives dins d'una mateixa sèrie):

Així, si Contoso compra una reserva de dos Standard_D8s_v5 per als nodes aplicaciones d'aks-contoso-operaciones i mesos després l'equip els redimensiona a quatre Standard_D4s_v5, el descompte continua aplicant-se íntegre: 8 unitats reservades, 8 unitats consumides. Això redueix molt la por de comprometre's, encara que no l'elimina: la flexibilitat opera dins de la sèrie i la regió, no entre sèries. Canviar de la sèrie D a la sèrie E, o moure la càrrega a North Europe, deixa la reserva sense ús a què aplicar-se.

Com s'aplica el descompte cada hora, que és el que cal visualitzar:

1. Azure agrupa l'ús d'aquella hora que coincideix amb la reserva (mateixa regió, mateixa família, dins de l'àmbit).
2. Aplica el descompte fins a exhaurir la quantitat reservada, començant per l'ús més car —cosa que és una bona notícia: no cal ordenar res a mà—.
3. L'ús restant es factura a pagament per ús.
4. La capacitat reservada no consumida es perd: no s'acumula per a l'hora següent.

Aquest quart punt és la raó de la regla d'or: es reserva la línia base, no la mitjana i molt menys el pic. Amb vmss-api-disponibilidad-pro, que oscil·la entre 2 i 20 instàncies amb una mitjana de 6, Contoso reserva 2. Les hores en què hi ha 6 instàncies, dues van amb descompte i quatre a demanda; les hores en què n'hi ha 2, les dues van amb descompte. Si n'hagués reservades 6, cada nit en perdria quatre.

Les reserves no són totalment irreversibles, però les seves sortides tenen límits que convé conèixer abans de comprar:

Dos advertiments importants. El primer: les condicions d'intercanvi i reemborsament han canviat diverses vegades, i el que era possible fa dos anys pot no ser-ho avui; verifica les condicions vigents a la documentació oficial en el moment de comprar, no en un article de blog. El segon, més útil: planifica com si no hi hagués sortida. Si la teva decisió de compra depèn de poder desfer-la, és que encara no tens dades suficients per comprar-la.

Un pla d'estalvi d'Azure per a còmput resol el punt feble de les reserves: la rigidesa. En lloc de comprometre una capacitat concreta, compromets una despesa per hora en còmput.

Exemple: Contoso es compromet a gastar 0,80 € per hora en còmput durant un any. A canvi, tot el seu consum de còmput fins a aquest import es factura amb preus de pla d'estalvi, que estan rebaixats respecte al pagament per ús. El consum per damunt va a pagament per ús; el consum per sota es factura igualment fins al compromís —és a dir, et compromets a pagar aquests 0,80 € cada hora, els facis servir o no—.

El decisiu és el que abasta: el pla d'estalvi s'aplica a famílies i serveis de còmput diferents, i en regions diferents. Una VM a West Europe, un pla d'App Service Premium v3, una Container App, una Function en pla Premium i un node d'AKS poden consumir el mateix compromís, i si demà redissenyes i en canvies uns per altres, el descompte continua aplicant-se. Aquesta és exactament la flexibilitat que una reserva no té.

Un detall important: les reserves s'apliquen abans que el pla d'estalvi. Si tens totes dues coses, Azure descompta primer el que coincideix amb reserves i només després consumeix el compromís del pla. Per això l'estratègia habitual —i la de Contoso— és reservar el nucli immòbil i cobrir amb pla d'estalvi la perifèria mòbil, no triar una cosa o l'altra.

Les instàncies d'accés puntual (spot) fan servir capacitat sobrant d'Azure amb descomptes que poden arribar al 70-90 % sobre el preu de llista. La contrapartida és dura i cal prendre-se-la literalment: Azure pot desallotjar la màquina amb uns 30 segons d'avís quan necessita la capacitat o quan el preu supera el teu màxim. No hi ha SLA.

El que caracteritza una càrrega apta per a spot:

• És interrompible: si mor a mitges, es reintenta i no passa res greu.
• No guarda estat local: tot el que és important viu fora de la instància.
• No té compromís de temps estricte amb un usuari esperant a l'altre costat.
• Pot escalar horitzontalment: perdre una de deu instàncies és un contratemps, perdre l'única és una caiguda.

A Contoso, dues càrregues ho compleixen i ja són en spot:

I el que mai no va en spot a Contoso: app-contoso-reservas-pro, vmss-api-disponibilidad-pro, els nodes sistema d'AKS —dels quals depèn el funcionament mateix del clúster— i qualsevol cosa que atengui un passatger en temps real.

--spot-max-price -1 significa «paga fins al preu de pagament per ús», que evita desallotjaments per preu i deixa només els desallotjaments per capacitat. El taint és imprescindible: sense ell, el planificador col·locaria càrregues normals en nodes que poden desaparèixer, i l'estalvi es convertiria en una incidència. I --min-count 0 permet que el grup baixi a zero nodes quan no hi ha lots per executar, que és un estalvi addicional al del mateix spot.

Azure Hybrid Benefit permet reutilitzar llicències de Windows Server i SQL Server que ja tinguis amb Software Assurance o subscripció activa, de manera que Azure et cobra només la infraestructura i no la llicència inclosa en el preu.

Tres característiques que el fan especialment interessant. S'acumula amb les reserves: primer la reserva rebaixa el preu de la infraestructura, després Hybrid Benefit treu el component de llicència. S'activa i es desactiva amb un interruptor, sense migrar res. I no costa res provar-lo, perquè l'efecte es veu a la factura del mes següent.

I ara l'avís que no pot faltar, perquè aquí no s'hi juguen diners sinó compliment: activar la casella és una declaració que posseeixes les llicències amb la cobertura adequada. Els requisits —edició, nombre de nuclis, doble ús durant una migració, Software Assurance vigent— són responsabilitat del client i una auditoria els pot reclamar. A Contoso, l'interruptor no el toca enginyeria: el valida i l'autoritza per escrit el responsable de llicències de l'organització, i aquesta autorització es desa al costat de la plantilla Bicep que l'aplica. Cap estalvi no justifica una infracció de llicència.

Azure ofereix preus reduïts per a entorns que no són de producció, mitjançant subscripcions de tipus Dev/Test:

Contoso Airlines - Desarrollo és una subscripció d'aquest tipus, i la seva regla d'ús està escrita: res que atengui un passatger real no viu allà. La temptació de moure una càrrega «petita» de producció a la subscripció barata apareix sempre, i cal tallar-la la primera vegada.

Amb tres mesos de dades d'ús real a stlagocontosopro (08-02), la Marta i la Nuria van muntar la proposta. Xifres orientatives i fictícies, en euros mensuals:

Un estalvi del 16 % de la factura sense canviar ni una línia d'arquitectura, sense apagar res i sense degradar cap servei. És, de bon tros, la palanca de més relació resultat/esforç de tot el mòdul.

Què es deixa deliberadament a demanda, i per què:

Aquesta última fila conté la millor lliçó de la taula: comprometre capacitat sobre dades que deixaràs d'ingerir és pagar un descompte per escombraries.

El punt d'equilibri. La reserva de tres anys dels nodes d'AKS, pagada per avançat, costa 27.540 € davant dels 61.200 € que costaria el mateix ús a demanda durant 36 mesos. Dividint el desemborsament entre el cost mensual actual:

• 27.540 € ÷ 1.700 €/mes = 16,2 mesos de punt d'equilibri.
• A partir del mes 17, tot és estalvi; si s'abandona la càrrega abans, s'han perdut diners.

La pregunta que Contoso es va fer, i que cal fer-se sempre, no és «quant estalvio?» sinó «estic raonablement segur que aquesta càrrega continuarà existint, en aquesta forma, d'aquí a 17 mesos?». Per als nodes d'AKS i per a db-reservas, la resposta va ser sí. Per al portal en MySQL, la resposta va ser no, i per això no es va reservar.

Reservar malament és l'única acció de tot aquest mòdul que pot augmentar el cost. Els quatre escenaris en què passa:

• Reservar abans d'estabilitzar. L'equip compra tres anys d'una SKU, dos mesos després redissenya el component i la reserva queda sense ús a què aplicar-se. Se segueix pagant.
• Reservar el pic en lloc de la línia base. La capacitat no consumida es perd hora a hora, i el descompte efectiu pot caure per sota del pagament per ús.
• Reservar i després optimitzar. Comprar la reserva i tot seguit dimensionar millor, apagar de nit o migrar a sense servidor deixa la reserva penjada. L'ordre correcte és optimitzar primer i reservar després, sobre la plataforma ja aprimada.
• Àmbit massa estret. Una reserva amb àmbit d'un grup de recursos deixa d'aplicar-se tan bon punt algú mou el recurs a un altre grup.

D'aquí les quatre regles escrites de Contoso, que mereixen copiar-se tal qual:

1. No es reserva res amb menys de tres mesos de dades d'ús real.
2. No es reserva un component amb una revisió d'arquitectura oberta.
3. S'optimitza primer i es reserva després.
4. Es reserva la línia base observada, no la mitjana ni el pic.

I una cinquena de sentit comú: quan el dubte és gran, 1 any en lloc de 3. Es renuncia a una part del descompte a canvi d'una opció de sortida, i aquesta opció té valor.

Una reserva comprada no s'oblida: es vigila. Cost Management ofereix informes d'utilització de reserves —quin percentatge de la capacitat reservada s'està consumint cada dia— i d'estalvi obtingut.

Un patró concret que cal reconèixer: una reserva que era al 100 % i cau bruscament gairebé sempre significa que algú va moure o redimensionar la càrrega sense saber que hi havia una reserva al darrere. Per això Contoso configura una alerta sobre la utilització de reserves i anota al README de contoso-infra quins recursos estan coberts per un compromís, perquè qui els hagi de tocar ho sàpiga abans.

Azure genera a més recomanacions de compra automàtiques, visibles tant a Cost Management com a Azure Advisor (08-04): analitza els últims 7, 30 o 60 dies d'ús i proposa la reserva que maximitzaria l'estalvi, amb el seu percentatge estimat.

Aquestes recomanacions no s'accepten a cegues, i hi ha tres motius concrets:

• Miren cap enrere, no cap endavant. Recomanen tres anys sobre 30 dies d'ús d'un component que potser es retirarà el trimestre que ve. Advisor no sap què hi ha al full de ruta.
• Recomanen sobre l'estat actual, no sobre l'optimitzat. Si una VM està sobredimensionada, la recomanació et proposa reservar-la sobredimensionada. Primer es corregeix la mida (08-04), després es reserva.
• Suposen àmbit compartit i termini llarg per defecte, que és el que maximitza l'estalvi teòric i no sempre el que convé.

La manera correcta de fer-les servir: com a punt de partida d'una conversa entre qui coneix el full de ruta tècnic i qui signa el desemborsament. A Contoso, aquesta conversa és un punt fix de la revisió mensual de costos (08-05).

• Creure que una reserva aparta capacitat. No ho fa: és un descompte de facturació. Si no executes res que hi coincideixi, l'hora es perd.
• Reservar el pic o la mitjana. Es reserva la línia base. Amb vmss-api-disponibilidad-pro, 2 i no 6.
• Reservar abans d'optimitzar. Dimensionar i apagar primer; comprometre's després, sobre la plataforma ja aprimada.
• Comprometre's amb una arquitectura en discussió. Si hi ha una revisió oberta, no es reserva.
• Àmbit de grup de recursos per defecte. Un moviment de recurs deixa la reserva sense aplicar. Compartit o grup d'administració llevat de motiu exprés.
• Donar per fet l'intercanvi o el reemborsament. Les condicions canvien; planifica com si no hi hagués sortida.
• Activar Hybrid Benefit sense validar les llicències. És una declaració contractual, no una casella d'optimització.
• Posar càrregues en spot sense taint ni tolerància a AKS: el planificador hi col·locarà el que no ha de ser.
• Consell: comença sempre per 1 any en allò que no porti sis mesos estable. El descompte menor és el preu de l'opció de sortida.
• Consell: anota a contoso-infra quins recursos estan coberts per un compromís. Evitaràs que algú redimensioni una VM reservada sense saber-ho.
• Consell: revisa la utilització de reserves un cop al mes. Una caiguda brusca és sempre un senyal que alguna cosa ha canviat.

Exercici 1. vmss-api-disponibilidad-pro té el perfil mensual següent: 2 instàncies durant 7 hores al dia, 6 instàncies durant 17 hores al dia, i un pic de 14 instàncies durant tres setmanes d'estiu. Cada instància costa 220 €/mes orientatius a demanda. Decideix quina quantitat reservar i amb quin termini, i calcula l'estalvi aproximat i el que s'hauria perdut reservant-ne 6.

Exercici 2. Contoso Millas (centro-coste=CC-2077) fa quatre mesos que és en producció amb una App Service Premium v3, un PostgreSQL flexible de 2 vCore, blobs i una Function en pla de consum. El projecte té aprovació de negoci per a dos anys, però s'està avaluant migrar el web a Container Apps. Proposa l'estratègia de compromís completa, indicant què reservar, què cobrir amb pla d'estalvi i què deixar a demanda.

Exercici 3. Azure Advisor recomana una reserva de 3 anys sobre sis Standard_D8s_v5 d'aks-contoso-operaciones amb un estalvi estimat del 45 %. Saps que: el grup aplicaciones està sobredimensionat i funciona al 20 % de CPU, hi ha una migració a Standard_D4s_v5 planificada per d'aquí a dos mesos, i el clúster continuarà existint almenys tres anys. Acceptes, ajornes o rebutges? Justifica-ho amb números.

Solució 1: la línia base real és 2, perquè és el mínim que hi ha en qualsevol moment del mes. Reservant 2 instàncies a 1 any amb un descompte orientatiu del 30 %: 2 × 220 € × 30 % ≈ 132 €/mes d'estalvi, amb una utilització del 100 % perquè mai no hi ha menys de 2 instàncies funcionant. Reservant-ne 6, l'aritmètica s'espatlla: durant les 7 hores nocturnes només hi ha 2 instàncies, així que 4 reserves es perden cada nit; sobre un mes, la utilització cau a aproximadament (7×2 + 17×6) / (24×6) ≈ 81 %, i el descompte efectiu sobre la despesa total baixa en conseqüència, a més d'haver immobilitzat un compromís més gran. El pic d'estiu no es reserva mai: són tres setmanes l'any, i una reserva pagaria aquesta capacitat les 49 setmanes restants. Termini: 1 any, perquè l'escalat automàtic i el perfil apertura-temporada-verano encara s'estan ajustant i perquè l'estalvi addicional de 3 anys sobre 440 € de base no compensa la rigidesa. Regla generalitzable: reserva el mínim del percentil més baix observat, mai la mitjana.

Solució 2: reservar el PostgreSQL flexible de 2 vCore a 1 any —fa quatre mesos que és estable, no està en discussió, el negoci té horitzó de dos anys i el servidor està encès 24x7—, amb estalvi orientatiu del 20-25 % sobre el còmput; l'emmagatzematge va a part i no es reserva. No reservar l'App Service Premium v3: encara que és reservable i seria l'estalvi més gran, hi ha una migració a Container Apps en avaluació, i la regla 2 de Contoso ho prohibeix expressament. En el seu lloc, pla d'estalvi de còmput a 1 any dimensionat per sota de la despesa actual de l'App Service —per exemple, al 70 % de la despesa horària observada—: s'obté un descompte menor però sobreviu a la migració, perquè Container Apps també consumeix el pla. Deixar a demanda: la Function en pla de consum, el cost de la qual és proporcional a l'ús i no admet aquest tipus de compromís, i els blobs, el volum dels quals encara creix i no té línia base fiable. Afegir capacitat reservada de Storage només quan el creixement s'estabilitzi. I una comprovació prèvia: l'àmbit de tots els compromisos ha de ser compartit o de grup d'administració, no de grup de recursos, perquè el projecte encara reorganitza els seus grups. Estalvi esperable: modest en euros absoluts, però sense cap risc de quedar-se amb un compromís orfe.

Solució 3: s'ajorna, i l'aritmètica ho demostra. Acceptar la recomanació significa comprometre tres anys de sis Standard_D8s_v5; dos mesos després, la migració a Standard_D4s_v5 redueix a la meitat les unitats consumides. Gràcies a la flexibilitat de mida d'instància la reserva no es perd —sis D8s són 24 unitats i dotze D4s també serien 24—, però si el redimensionament és a sis D4s (12 unitats), la utilització cau al 50 % i s'estaran pagant 34 mesos de capacitat que ningú no consumeix. Traduït: sobre 1.700 €/mes de despesa actual, la meitat de la reserva ociosa malbarata de l'ordre de 380 €/mes durant gairebé tres anys, més del que estalviaria la part ben aprofitada. La seqüència correcta és la regla 3: primer optimitzar, després reservar. S'aplica el redimensionament a D4s en els dos mesos previstos, s'observen 30 dies d'ús ja optimitzat, s'identifica la nova línia base i llavors es compra la reserva de 3 anys sobre aquesta base —el clúster continuarà existint, així que el termini llarg està justificat—. Mentrestant, si es vol capturar una mica de descompte sense risc, hi cap un pla d'estalvi de còmput petit, dimensionat sobre la despesa que es mantindrà amb seguretat després de la migració. I s'anota al seguiment de la revisió mensual, perquè la decisió no es perdi.

Ja tens interioritzat l'eix que governa tot el capítol: flexibilitat i preu són inversos, i l'habilitat no consisteix a comprometre's molt, sinó a comprometre's exactament amb la part de la plataforma que saps que continuarà existint. Coneixes les instàncies reservades amb tots els seus paràmetres —termini d'1 o 3 anys, pagament per avançat o mensual sense penalització, àmbit compartit, de subscripció, de grup de recursos o de grup d'administració, quantitat i regió—, la llista de serveis que les admeten, i les dues claus de funcionament que eviten gairebé tots els errors: la flexibilitat de mida d'instància dins de la sèrie i la regió, i el fet que la capacitat reservada no consumida es perd cada hora, d'on surt la regla de reservar la línia base i mai el pic. Saps també quines sortides existeixen —canvi d'àmbit, divisió, intercanvi restringit, reemborsament limitat— i que cal planificar com si no n'hi hagués cap.

Distingeixes els plans d'estalvi de les reserves: compromís de despesa per hora davant de compromís de capacitat concreta, aplicable entre sèries, serveis i regions de còmput, amb menys descompte a canvi de molta més flexibilitat, i aplicant-se sempre després de les reserves —de manera que l'estratègia sensata és reservar el nucli immòbil i cobrir amb pla d'estalvi la perifèria mòbil—. Saps quan una càrrega tolera instàncies d'accés puntual i com es configuren amb el seu taint al grup lotes d'aks-contoso-operaciones, i quan no s'han de fer servir mai. Entens Azure Hybrid Benefit, que s'acumula amb les reserves i s'activa amb un interruptor, amb l'avís ineludible que el seu compliment el valida el responsable de llicències, no enginyeria. I situes els nivells de desenvolupament i proves amb el seu requisit de subscriptors de Visual Studio i la seva prohibició contractual d'allotjar producció.

Tens a més la decisió completa de Contoso: uns 2.900 € al mes, el 16 % de la factura, sense canviar arquitectura, sense apagar res i sense degradar cap servei, repartits entre reserves de tres anys sobre AKS, App Service i el còmput de db-reservas, reserves d'un any sobre la línia base del VMSS, Cosmos i Storage, un pla d'estalvi per a la perifèria i Hybrid Benefit; amb el que es deixa deliberadament a demanda i el perquè de cada exclusió, i amb un punt d'equilibri de 16,2 mesos que converteix la pregunta econòmica en una pregunta tècnica: continuarà existint aquesta càrrega, així, d'aquí a disset mesos? I t'endus les quatre regles que impedeixen que l'estalvi es converteixi en pèrdua —tres mesos de dades, cap arquitectura en discussió, optimitzar abans de reservar, línia base i no mitjana—, més el seguiment de la utilització i el criteri per no acceptar a cegues les recomanacions automàtiques, que miren cap enrere i sobre l'estat sense optimitzar.

I aquí queda el fil solt que obre la lliçó següent. Dues de les tres raons per desconfiar d'una recomanació de compra apunten al mateix lloc: abans de comprometre's cal optimitzar, i per optimitzar cal saber què està mal dimensionat, què està orfe i què porta mesos encès sense que ningú ho faci servir. Azure ho sap i ho diu gratis. Azure Advisor analitza la teva subscripció real —no dona consells genèrics— i produeix recomanacions de fiabilitat, seguretat, excel·lència operativa, rendiment i cost: la VM al 3 %, els discos que ningú no va desassociar, les IP públiques reservades i oblidades, les instantànies de fa un any, les passarel·les sense connexions. És el malbaratament silenciós, i a la lliçó següent el trobaràs sencer: amb Advisor primer, i després amb les consultes d'Azure Resource Graph que descobreixen el que Advisor no veu.