MercadoFresco ha apagat el que sobrava, ha esborrat el que ningú no feia servir i ha posat límits al que pot créixer. La factura és de 1.749,60 USD al mes i cada línia té una explicació. Queda una palanca sense fer servir, i és l'única que redueix la despesa sense canviar absolutament res de l'arquitectura: tot el que està funcionant es paga a preu sota demanda, és a dir, al preu de qui podria marxar demà. I hi ha una part d'aquest consum que hi continuarà sent d'aquí a un any amb tota seguretat.

Aquesta lliçó va de convertir aquesta certesa en descompte. Veuràs els quatre models de compra amb el seu descompte, el seu compromís i el seu risc; els Savings Plans en les seves tres variants, amb terminis i formes de pagament; com funciona el compromís per dòlar-hora amb un exemple numèric pas a pas; què cobreix cada tipus —crític en una arquitectura com aquesta, majoritàriament sense servidor—; les instàncies reservades per a allò que els Savings Plans no abasten; com s'identifica la base estable enfront de la part elàstica; el pla de compra concret de MercadoFresco amb el seu estalvi; i el seguiment amb cobertura i utilització, que són dues coses diferents i es confonen constantment.

Avís de cost. Els Savings Plans i les instàncies reservades no costen res per si mateixos: són una manera diferent de pagar el que ja es consumeix. El risc no és un càrrec inesperat, és comprometre's de més: un pla a 3 anys amb pagament total per avançat no es pot cancel·lar, ni retornar, ni reduir. El que es compra, es paga. Els percentatges de descompte d'aquesta lliçó són orientatius, varien per regió, servei i data, i s'han de comprovar sempre a la calculadora oficial abans de comprar. Dades i identificadors ficticis.

1. Per què existeix el descompte per compromís
2. Els quatre models de compra
3. Els tres tipus de Savings Plans
4. Terminis i formes de pagament
5. Com funciona el compromís per dòlar-hora
6. Un exemple numèric pas a pas
7. Què cobreix cada pla i què no
8. Instàncies reservades: allò que els Savings Plans no abasten
9. Estàndard enfront de convertible, abast i capacitat reservada
10. Spot, revisat des del cost
11. Identificar la base estable enfront de la part elàstica
12. Les recomanacions automàtiques i per què no són decisions
13. El pla de compra de MercadoFresco
14. L'abans i el després
15. Cobertura i utilització: dues coses diferents
16. Seguiment i alarmes
17. Què fer si l'arquitectura canvia
18. Repartiment de compromisos entre comptes
19. Errors cars
20. Errors comuns i consells
21. Exercicis
22. Conclusió

La lògica de negoci d'AWS és la mateixa que la de qualsevol proveïdor amb infraestructura física: els centres de dades es construeixen per endavant. Un servidor comprat avui s'ha d'amortitzar durant anys, i per a això cal previsió de demanda.

Un client que paga sota demanda no aporta cap previsió: pot marxar demà. Un client que es compromet per escrit a gastar una quantitat concreta durant un o tres anys sí que l'aporta, i AWS li'n retorna part d'aquest valor en forma de descompte.

D'aquí se'n dedueix tota la resta, sense necessitat de memoritzar taules:

• A més termini, més descompte: tres anys valen més que un.
• A més pagament per avançat, més descompte: els diners d'avui valen més que els diners d'aquí a un any.
• A menys flexibilitat, més descompte: comprometre's a una família d'instàncies concreta val més que comprometre's a «computació en general».
• El risc es trasllada al client: si deixes de fer-ho servir, ho pagues igualment.

Aquest últim punt és el que cal tenir present durant tota la lliçó. Un compromís és una aposta sobre el futur, i com tota aposta es dimensiona pel que es pot perdre, no pel que es pot guanyar.

Els quatre es combinen, i la combinació és el que és normal en una arquitectura madura. L'ordre mental correcte per decidir:

MercadoFresco ja fa servir el primer camí des de 10-02: els treballadors corren en Fargate Spot perquè la seva feina es reintenta sola. El que falta és recórrer els altres dos.

La comparació que importa per a gairebé tothom és entre els dos primers:

• L'EC2 Instance dona uns 6-8 punts percentuals més de descompte, però et lliga a la família m6g a eu-west-1. El dia que vulguis passar a m7g, a una altra regió o a contenidors, el compromís deixa de servir-te i el continues pagant.
• El Compute dona una mica menys i sobreviu a gairebé qualsevol canvi d'arquitectura. Continua aplicant-se si migres d'EC2 a Fargate, si canvies de regió, si passes part de la feina a Lambda.

Per a MercadoFresco no hi ha debat: l'EC2 Instance Savings Plan no li serveix de res, perquè pràcticament no té EC2. La seva computació és a Fargate i a Lambda, i totes dues només les cobreix el Compute Savings Plan. Aquest és exactament el tipus de detall que fa que les recomanacions automàtiques s'hagin de llegir amb criteri.

I un advertiment de vocabulari que estalvia confusions: també existeix un tercer producte anomenat Savings Plans de bases de dades en algunes comunicacions comercials, però la cobertura d'RDS, Aurora, ElastiCache o Redshift es compra amb instàncies reservades, no amb Savings Plans de computació. Confondre-ho porta a comprar un compromís que no cobreix res del que es pretenia.

Dos eixos independents que es combinen en sis opcions:

Dues lectures d'aquesta taula, i totes dues són importants:

1. La forma de pagament aporta poc. Entre «sense pagament inicial» i «total per avançat» a un any hi ha uns 4 punts percentuals. Per a MercadoFresco, 4 punts sobre un compromís petit són uns pocs dòlars al mes a canvi d'immobilitzar tot l'import anual. No compensa. Per a una empresa que compromet centenars de milers de dòlars, aquests 4 punts sí que són molts diners, i la decisió és financera: depèn del cost d'oportunitat del capital.
2. El termini aporta molt. Duplicar el descompte del 20 % al 40 % passant d'un a tres anys és una diferència real. I també ho és el risc: tres anys és més del que ha durat la meitat de les decisions d'arquitectura d'aquest curs.

La regla que MercadoFresco adopta i que serveix per a la majoria d'empreses petites i mitjanes: primer compromís a 1 any i sense pagament inicial. S'aprèn com funciona, es comprova que la previsió era bona, i en renovar-lo —amb un any de dades reals— es pot plantejar tres anys sobre la part que hagi demostrat ser estable.

Aquí hi ha el concepte que més es malinterpreta. Un Savings Plan no compra instàncies: compra una despesa per hora a preu rebaixat.

Quan contractes un Compute Savings Plan de 0,17 USD/hora, el que estàs dient és:

«Em comprometo a gastar 0,17 USD cada hora, durant un any, en computació elegible. A canvi, aquesta despesa es factura a tarifa de Savings Plan en lloc de a tarifa sota demanda.»

El funcionament hora a hora:

1. AWS mira el teu consum de computació elegible en aquella hora i el valora a tarifa de Savings Plan.
2. Aplica el compromís fins a esgotar-lo, començant per l'ús amb més percentatge de descompte —ho fa automàticament per maximitzar el teu estalvi—.
3. L'ús que quedi per damunt del compromís es factura a preu sota demanda.
4. Si el consum no arriba al compromís, la diferència es paga igualment. Aquest és el risc, i és l'única manera de perdre diners amb un Savings Plan.

Tres conseqüències pràctiques que convé tenir clares:

• El compromís s'expressa en diners, no en capacitat. Si AWS abaixa els preus, el teu compromís cobreix més màquines.
• És horari, no mensual. No hi ha compensació entre hores: una hora sense consum no es recupera amb una hora de molt consum. Per això es dimensiona sobre el mínim sostingut, no sobre la mitjana.
• No reserva capacitat. Un Savings Plan no garanteix que hi hagi màquines disponibles; només canvia el preu. Per garantir capacitat calen reserves zonals o blocs de capacitat.

Suposem un compromís de 0,17 USD/hora en un Compute Savings Plan a 1 any, amb un descompte del 20 % sobre Fargate. Això significa que 1 USD d'ús sota demanda costa 0,80 USD a tarifa de pla, i per tant el compromís de 0,17 USD/h cobreix 0,2125 USD/h d'ús a preu sota demanda (0,17 ÷ 0,80).

Hora A: consum exactament igual al compromís.

Hora B: consum per damunt del compromís (pic del divendres, el doble de tasques).

Lliçó: l'excedent no es penalitza, simplement es paga a preu normal. Quedar-se curt en el compromís no té cap càstig; només vol dir que no aprofites el descompte en aquella part.

Hora C: consum per sota del compromís (matinada de diumenge, entorns apagats).

Aquí hi ha tot el risc condensat. Aquella hora ha costat un 70 % més del que hauria costat sense el pla. I no és una hipòtesi rebuscada: és exactament el que passa les nits i els caps de setmana tan bon punt s'apaguen els entorns no productius, que és justament el que MercadoFresco acaba de fer a 11-03.

D'aquí surt la regla de dimensionament que governa tota la decisió: el compromís es fixa per sota del consum mínim sostingut de l'hora més fluixa de la setmana, no per la mitjana i molt menys pel pic.

Aquesta taula és la que cal consultar abans de comprar res, i la que explica per què MercadoFresco estalviarà menys del que esperava:

I aquí arriba la conclusió incòmoda per a MercadoFresco, que convé dir sense adorns perquè és una lliçó general:

Una arquitectura majoritàriament sense servidor té molt menys marge de descompte per compromís que una basada en instàncies.

El detall concret: aurora-mercadofresco-pedidos funciona en Aurora Serverless v2, que es factura per ACU-hora i no admet instàncies reservades. El mateix passa amb wg-mercadofresco-analitica, que és Redshift Serverless. Entre totes dues sumen 447,10 USD al mes que no es poden comprometre de cap manera.

Això no és una mala notícia disfressada: és l'altra cara d'una decisió que ja va rendir. Serverless ja va estalviar abans, escalant a zero quan no hi ha càrrega —recordem la comparació de 06-04, on Redshift provisionat costava 1.586 USD al mes enfront dels 16 de Serverless—. No es pot cobrar dues vegades el mateix estalvi. Un clúster de Redshift provisionat amb reserva a tres anys sortiria més barat per hora i moltíssim més car al mes, perquè estaria encès les 730 hores.

Per al que no cobreixen els Savings Plans i sí que és provisionat, existeixen les instàncies reservades (RI). Funcionen de manera semblant però es comprometen a recursos concrets, no a diners per hora.

El que MercadoFresco pot reservar:

Només una fila és accionable, i és la d'ElastiCache. Els nodes de memòria cau fa mesos que estan encesos les 730 hores del mes, la seva mida està validada i no hi ha cap pla de canviar-los: és el cas de llibre per a una reserva.

Les opcions que cal decidir en comprar una reserva:

Dos avisos que eviten decepcions:

• Els Savings Plans no es poden vendre ni cancel·lar. El mercat de revenda existeix només per a reserves estàndard d'EC2. Si compres un Compute Savings Plan i te'n sobra, te'n sobra durant tot el termini.
• La flexibilitat de mida només funciona dins de la mateixa família i sistema operatiu. Una reserva de cache.t4g.medium cobreix cache.t4g.small a mitja potència, però no cobreix cache.r7g.large.

Per a MercadoFresco: reserva d'ElastiCache, estàndard, regional, 1 any, pagament parcial. Estàndard perquè la mida està validada i no hi ha intenció de canviar de família; regional perquè no cal garantir capacitat; un any per la mateixa raó que el Savings Plan.

Spot és capacitat sobrant d'AWS venuda amb fins a un 90 % de descompte a canvi de poder retirar-la amb dos minuts d'avís. No hi ha compromís ni termini: és un preu, no un contracte.

MercadoFresco ja el fa servir des de 10-02, amb el repartiment base=1, weight 1:4 a svc-mercadofresco-trabajadores: una tasca sempre sota demanda i la resta majoritàriament a Fargate Spot. El criteri que va decidir on entra continua sent vàlid i val la pena repetir-lo, perquè és el que evita el desastre:

Spot entra només on una interrupció amb dos minuts d'avís es reintenta sola i ningú no se n'assabenta.

Càrregues que l'admeten en una arquitectura com aquesta:

I una relació important amb el que hem vist: l'ús de Spot no consumeix el compromís d'un Savings Plan de computació, perquè ja es factura amb el seu propi descompte. Per tant, en calcular la base estable sobre la qual comprometre's, el consum Spot es resta. Oblidar-ho porta a comprometre de més.

Aquesta és la feina analítica que precedeix qualsevol compra. La pregunta: quanta computació elegible està encesa a l'hora més fluixa de la setmana?

L'eina és la vista horària de Cost Explorer, filtrada a Fargate i Lambda, excloent-hi Spot, sobre les últimes quatre setmanes. El perfil de MercadoFresco després de les optimitzacions d'11-03:

Tres xifres i tres conclusions:

• El mínim sostingut és 0,214 USD/hora. És el que està encès sempre, sense excepció, inclosa la matinada del diumenge.
• La mitjana és 0,328 USD/hora, un 53 % per damunt del mínim. Comprometre's per la mitjana significaria malgastar compromís totes les nits i tots els caps de setmana.
• El pic és 0,690, més del triple del mínim. Comprometre's pel pic seria un desastre.

La regla pràctica: comprometre's entre el 70 % i el 85 % del mínim sostingut en el primer pla. MercadoFresco tria 0,17 USD/hora, que és el 79 % del mínim. Aquest marge del 21 % cobreix tres riscos concrets:

1. Que s'apagui alguna cosa més del que estava previst en els propers mesos —hi ha optimitzacions pendents—.
2. Que una part de la computació es mogui a Spot i deixi de ser elegible.
3. Que un canvi d'arquitectura redueixi la computació, com passaria si alguna càrrega es passa a un servei no cobert.

Cost Explorer ofereix recomanacions de compra a Savings Plans → Recommendations, configurables per termini, forma de pagament i període d'anàlisi (7, 30 o 60 dies).

Per a MercadoFresco, amb 30 dies i 1 any sense pagament inicial, la recomanació és:

I MercadoFresco no la segueix. Compra 0,17, no 0,29. Les raons són instructives i valen per a qualsevol cas:

1. La recomanació dona per fet que el futur serà igual que el passat. Els 30 dies analitzats inclouen les dues primeres setmanes anteriors a l'apagada nocturna d'11-03. La recomanació està calculada sobre un consum que ja no existeix.
2. Optimitza l'estalvi esperat, no el risc. L'algorisme busca el punt que maximitza l'estalvi mitjà; no sap que d'aquí a tres mesos hi ha una migració planificada, ni que l'equip vol provar de moure una càrrega a Lambda.
3. La utilització estimada del 98 % és una mitjana mensual, no una garantia horària. Amb les nits apagades, la utilització real d'un compromís de 0,29 seria molt pitjor del que suggereix aquest número.
4. Ningú d'AWS no perd diners si te'n passes. La recomanació és honesta i està ben calculada, però l'incentiu no està alineat amb el teu.

La manera correcta de fer-les servir: com a punt de partida i com a sostre, mai com a decisió. Si la recomanació diu 0,29, se sap que 0,29 és massa i que la resposta és per sota. I sempre es contrasta amb la vista horària pròpia, que és la dada que la recomanació no pot tenir en compte: el teu coneixement del que passarà.

Després de l'anàlisi, la Marta porta a gerència una proposta de dues línies:

La justificació de cada decisió, escrita a l'ADR-024:

• Compute i no EC2 Instance, perquè la computació de MercadoFresco és Fargate i Lambda, que l'EC2 Instance no cobreix en absolut.
• 0,17 USD/hora i no els 0,29 recomanats, perquè és el 79 % del mínim sostingut real posterior a les optimitzacions.
• Un any i no tres, perquè a 10-03 es van escriure sis criteris objectius que portarien MercadoFresco a migrar a EKS, i dos d'ells es podrien complir en divuit mesos. Comprometre's tres anys amb una migració plausible a l'horitzó és exactament l'error que aquesta lliçó ensenya a evitar. Amb el matís que un Compute Savings Plan sobreviuria a aquesta migració —EKS sobre Fargate continua sent Fargate—, però no sobreviuria a un canvi d'estratègia més gran.
• Sense pagament inicial, perquè els 4 punts de descompte addicionals del pagament total suposen uns 5 USD al mes a canvi d'immobilitzar 1.489 USD durant un any. Per a una empresa d'aquesta mida, l'efectiu val més.
• La compra es fa des del compte de gestió perquè el descompte es reparteixi automàticament per tota l'organització mitjançant la facturació consolidada.
• Els nodes d'ElastiCache sí que amb pagament parcial, perquè l'import és petit i la certesa és total: fa deu mesos que estan encesos i no hi ha cap pla de tocar-los.

L'ordre de compra —que a la pràctica s'executa des de la consola després de revisar el resum dues vegades, perquè no hi ha desfer:

Tres notes sobre aquestes ordres:

• --commitment és USD per hora, no mensual ni anual. Escriure 170 en lloc de 0.17 compraria un compromís mil vegades més gran, i no hi ha manera de desfer-ho. És l'error més car que es pot cometre en tota aquesta lliçó.
• --duration 31536000 són els segons d'un any. Tres anys són 94608000.
• Etiquetar la compra permet veure-la als informes amb les mateixes dimensions que tota la resta. Sí: fins i tot un compromís financer s'etiqueta.

I el balanç complet del mòdul, que és la xifra que es porta a gerència:

Convé assenyalar la proporció, perquè és la lliçó que més es repeteix a la pràctica i la que menys s'explica: dels 556 USD d'estalvi, 488 vénen d'apagar i netejar, i només 68 de comprometre. És a dir, el 88 % de l'estalvi es va aconseguir sense signar res. En una arquitectura majoritàriament sense servidor, els compromisos són la cirereta, no el plat principal.

Es confonen constantment i mesuren coses oposades:

La clau és que una utilització del 100 % és obligatòria i una cobertura del 100 % és un error:

• Utilització per sota del 100 % significa que estàs pagant compromís que no fas servir. Cada punt perdut són diners llençats. Si baixa del 95 %, cal investigar.
• Cobertura del 100 % significaria que tot el teu consum, inclòs el pic del divendres, està compromès. Com que el pic no és sostingut, per arribar-hi hauries hagut de comprometre moltíssim més de la base, i estaries perdent diners totes les nits.

Per a MercadoFresco, amb un compromís de 0,17 sobre una mitjana de 0,328:

Una cobertura del 65 % amb utilització del 100 % és exactament el punt correcte: s'aprofita tot el que s'ha compromès i queda la part variable pagant-se sota demanda, que és on ha de ser.

Un compromís comprat i no vigilat és una fuita silenciosa. Tres mecanismes, en ordre d'importància:

1. Pressupost d'utilització de Savings Plans (11-04), que és la forma més directa:

Amb una notificació de tipus ACTUAL, operador LESS_THAN i llindar 95: avisa quan la utilització baixa d'aquest percentatge. És un dels pocs usos legítims de LESS_THAN en un pressupost, i aquí és imprescindible.

2. Informes d'utilització i cobertura a Cost Explorer, revisats a la reunió mensual juntament amb la resta. Dos gràfics que es miren en deu segons i que expliquen tota la història.

3. Un avís de venciment noranta dies abans que expiri el pla. Els Savings Plans no es renoven sols: el dia que vencen, tot el consum torna a preu sota demanda de cop i la factura puja sense que ningú hagi fet res. Una regla d'EventBridge sobre la data d'expiració, o simplement una entrada al calendari, evita aquesta sorpresa. La renovació és, a més, el moment ideal per replantejar el compromís amb un any de dades reals damunt la taula.

L'escenari que cal anticipar abans de signar. Suposem que MercadoFresco hagués comprat el 2024 un EC2 Instance Savings Plan a 3 anys sobre la família m5 a eu-west-1, dimensionat per al seu ASG d'aleshores. I que el 2026, seguint el mòdul 10, migra tota la botiga a Fargate amb arm64.

El resultat: el compromís deixa d'aplicar-se completament. No cobreix Fargate, no cobreix Graviton fora de la seva família, i quedaria un any pagant per capacitat que no es fa servir. Sobre un compromís d'uns 150 USD al mes, serien 1.800 USD llençats i, pitjor encara, un incentiu pervers a endarrerir la migració per no malgastar el pla. Aquest és el dany real d'un compromís mal escollit: no només costa diners, sinó que condiciona decisions tècniques.

D'aquí les tres regles de MercadoFresco:

1. Compute Savings Plan per defecte, encara que doni una mica menys de descompte. Sobreviu a la majoria dels canvis: EC2 a Fargate, x86 a arm64, canvi de regió, part a Lambda.
2. Un any mentre hi hagi qualsevol canvi plausible a l'horitzó. Tres anys només per a la part de l'arquitectura que faci anys que no es mou i no tingui alternativa a la vista.
3. Abans de comprometre, revisar el registre de decisions d'arquitectura (11-01). Si hi ha un ADR que preveu un canvi en els propers dos anys, aquest canvi afecta la decisió de compra.

I si tot i així el pla es queda sense ús, les opcions són escasses i convé conèixer-les per endavant: un Compute Savings Plan no es cancel·la, no es redueix i no es ven. L'única cosa que es pot fer és donar-li ús: moure càrregues a serveis coberts, avançar migracions que estaven previstes, o deixar encès alguna cosa que s'anava a apagar —cosa que és absurda, però és exactament el que acaba fent la gent—.

Amb facturació consolidada (09-04), un Savings Plan comprat en qualsevol compte s'aplica a l'ús de tots els comptes de l'organització, començant pel que el va comprar i continuant per la resta en ordre de més descompte.

Aquest comportament es controla amb l'ajust de compartició de descomptes (Discount sharing), que es configura a les preferències de facturació del compte de gestió:

MercadoFresco la deixa activada, que és el correcte en el seu cas: hi ha un sol pressupost i l'objectiu és que el compromís s'aprofiti al màxim, vingui d'on vingui el consum. Amb dues conseqüències que convé tenir presents:

• El descompte apareix al compte que consumeix, no al que va comprar. El cost amortitzat d'11-03 és la mètrica que reflecteix bé això; el no combinat, no.
• Comprar des del compte de gestió és la pràctica recomanada precisament per això: la gestió no consumeix gairebé res, així que el compromís es reparteix per on de debò hi ha ús, i la propietat del contracte queda on hi ha el control financer.

Els tres que arruïnen una compra, en ordre de freqüència:

1. Comprometre abans d'optimitzar. És l'error d'ordre i el més car de tots. Si MercadoFresco hagués comprat un Savings Plan a l'agost, sobre un consum de computació de 262,40 USD, i al setembre hagués executat les deu optimitzacions d'11-03 —que abaixen aquest consum un 24 %—, el compromís sobrant es pagaria durant tot el termini. L'ordre correcte no admet excepcions: primer apagar el que sobra, després dimensionar el que queda, i només aleshores comprometre.

2. Comprometre massa. Neix de dimensionar sobre la mitjana o sobre la recomanació automàtica en lloc de sobre el mínim sostingut. El símptoma és una utilització per sota del 100 % des del primer mes, i no té arreglament fins al venciment.

3. Confondre cobertura amb utilització. Algú veu una cobertura del 65 % i conclou que cal comprar-ne més. És exactament al revés: una cobertura del 65 % amb utilització del 100 % està bé; pujar la cobertura al 90 % obligaria a comprometre per damunt del mínim sostingut i faria baixar la utilització. La pregunta correcta mai no és «quanta cobertura tinc?» sinó «estic aprofitant tot el que pago?».

Error: comprar un EC2 Instance Savings Plan tenint la càrrega en contenidors. Dona més descompte sobre el paper i cobreix exactament zero del teu consum. Consell: comprova la taula de cobertura abans de mirar els percentatges. Fargate i Lambda només els cobreix el Compute.

Error: escriure el compromís en unitats equivocades. --commitment és USD per hora. Posar-hi l'import mensual multiplica el compromís per 730 i no hi ha desfer. Consell: revisa el resum de la compra dues vegades i compara'l amb la teva vista horària abans de confirmar.

Error: dimensionar per la mitjana. La mitjana de MercadoFresco és 0,328 i el seu mínim sostingut 0,214. Comprometre per la mitjana significa malgastar totes les nits i tots els caps de setmana. Consell: el compromís es fixa entre el 70 i el 85 % del mínim sostingut.

Error: comprar a tres anys en la primera compra. El descompte sedueix i el termini supera la vida mitjana d'una decisió d'arquitectura. Consell: primer pla a un any; a la renovació, amb dades reals, es planteja el termini llarg sobre la part demostradament estable.

Error: incloure el consum Spot en el càlcul de la base. Spot ja té el seu descompte i no consumeix compromís, així que comprometre sobre ell és comprometre sobre res. Consell: exclou Spot del filtre de la vista horària abans de calcular el mínim.

Error: esperar que el pla cobreixi RDS, ElastiCache o Redshift. No els cobreix cap dels tres tipus. Consell: per a això hi ha les instàncies reservades, i només si el recurs és provisionat: Serverless no admet reserves.

Error: oblidar la data de venciment. El pla expira, tot torna a preu sota demanda i la factura puja sense que ningú hagi tocat res. Consell: avís 90 dies abans i renovació tractada com una decisió nova, no com un tràmit.

Error: deixar que el compromís condicioni l'arquitectura. «No migrem encara perquè desaprofitaríem el pla» és una frase que se sent massa. Consell: si un compromís mal escollit està frenant una decisió tècnica correcta, assumeix la pèrdua i tira endavant. El cost d'una arquitectura pitjor durant dos anys supera de llarg el del pla malgastat.

Consell: compra des del compte de gestió i deixa la compartició activada. És el que fa que el compromís s'aprofiti on de debò hi ha consum.

Consell: escriu un ADR per a la compra. Un compromís d'un o tres anys és una decisió d'arquitectura amb conseqüències financeres: mereix el mateix tractament que qualsevol altra, amb les seves alternatives descartades i la seva data de revisió.

Una empresa fictícia, TallerNube, té aquest perfil de computació elegible (EC2 i Fargate, sense Spot) mesurat durant quatre setmanes:

1. Calcula la mitjana horària del mes i compara-la amb el mínim.
2. Proposa un compromís i justifica el percentatge escollit.
3. Amb un descompte del 22 %, calcula l'estalvi mensual i anual.
4. La recomanació automàtica d'AWS proposa 1,95 USD/hora. La seguiries? Per què?

Per a cadascuna d'aquestes càrregues, indica quin model de compra faries servir i per què:

1. Un clúster d'Aurora provisionat db.r6g.large Multi-AZ, encès 24/7 des de fa dos anys.
2. Un servei de Fargate que escala entre 2 i 20 tasques segons l'hora.
3. Un procés nocturn de transformació de dades que triga 3 hores i es pot reintentar.
4. Un clúster de Redshift Serverless que es fa servir 2 hores al dia.
5. Una flota de 40 instàncies m6i.xlarge que fa tres anys que no canvien i no es preveu migrar.
6. Una funció Lambda invocada 4 milions de vegades al mes amb durada mitjana de 200 ms.

Tres mesos després de comprar un Compute Savings Plan de 0,30 USD/hora a un any, els informes mostren:

1. Quin és el problema i quin no ho és?
2. Enumera tres causes possibles, ordenades per probabilitat.
3. Quines opcions hi ha per arreglar-ho i quina recomanaries?

Solució a l'exercici 1

(1) Mitjana horària. Sobre una setmana tipus de 168 hores, amb el pic repartit (17 hores al mes ≈ 4 hores setmanals, que surten de l'horari laboral):

La mitjana (1,471) està un 34 % per damunt del mínim sostingut (1,10). Comprometre's per la mitjana suposaria malgastar 0,371 USD/hora durant les 96 hores setmanals de vall: unes 39,7 USD setmanals llençades, més de 170 USD al mes.

(2) Compromís proposat: 0,88 USD/hora, que és el 80 % del mínim sostingut. El marge del 20 % cobreix el que és previsible: que alguna càrrega es mogui a Spot, que s'apagui algun entorn, o que una optimització pendent redueixi el consum base. Si TallerNube ja té fetes totes les seves optimitzacions i una previsió de creixement ferma, es podria pujar a 0,93 (85 %), però no més en una primera compra.

(3) Estalvi amb un descompte del 22 %:

(4) La recomanació d'1,95 USD/hora no se segueix. Està per damunt fins i tot de la mitjana horària (1,471) i gairebé duplica el mínim sostingut (1,10). Amb aquest compromís, TallerNube pagaria 0,85 USD/hora de compromís no utilitzat durant les 96 hores setmanals de vall —unes 353 USD al mes llençades—, que superarien de llarg l'estalvi obtingut a les hores d'activitat. És un exemple perfecte de per què la recomanació és un punt de partida i no una decisió: probablement està calculada sobre un període amb un pic atípic, o està optimitzant l'estalvi esperat sense ponderar el risc de les hores vall.

Solució a l'exercici 2

L'observació transversal de l'exercici: de sis càrregues, quatre models diferents. No existeix «el millor model de compra», existeix l'adequat per a cada perfil de consum.

Solució a l'exercici 3

(1) Quin és el problema. El problema és la utilització del 78 %: s'està pagant el 22 % del compromís sense rebre res a canvi, uns 48,20 USD al mes, que són 578 USD si continua així tot l'any. La cobertura del 71 % no és cap problema; de fet està a la banda raonable. Qui miri només la cobertura conclourà que tot va bé, i és justament la confusió que aquesta lliçó adverteix.

(2) Tres causes possibles, per probabilitat:

1. Es va comprometre per damunt del mínim sostingut, probablement dimensionant sobre la mitjana o seguint la recomanació automàtica. És la causa més freqüent amb diferència, i el símptoma característic és que la utilització sigui dolenta des del primer mes.
2. Alguna cosa es va apagar o es va optimitzar després de comprar: un entorn amb apagada nocturna, una migració a arm64, una càrrega moguda a Spot o a un servei no cobert. El símptoma seria una utilització bona al principi que empitjora en un moment identificable.
3. Una part de la computació va deixar de ser elegible: es va moure a Spot —que no consumeix compromís— o a un servei que el pla no cobreix, com passar una feina per lots de Fargate a AWS Batch sobre capacitat Spot.

Per distingir-les n'hi ha prou de mirar la sèrie temporal d'utilització des de la compra: plana i baixa apunta a la causa 1; amb un esglaó, a la 2 o a la 3, i la data de l'esglaó assenyala què va passar.

(3) Opcions i recomanació. Les opcions reals són poques, perquè un Savings Plan no es cancel·la, no es redueix i no es ven:

Recomanació: una combinació de la segona i la quarta. Primer, revisar si hi ha migracions ja planificades cap a serveis coberts que es puguin avançar; això converteix compromís malgastat en descompte real sense distorsionar cap decisió. El que quedi, s'assumeix. I sobretot, es documenta el perquè perquè la renovació no repeteixi l'error: compromís al 75-80 % del mínim sostingut, calculat sobre dades posteriors a les optimitzacions i excloent-hi Spot.

El que no s'ha de fer sota cap concepte és deixar d'optimitzar per «rendibilitzar» el pla. Seria exactament l'incentiu pervers que aquesta lliçó adverteix: el compromís passaria de ser una eina d'estalvi a ser un fre per a l'arquitectura.

MercadoFresco ha tancat el cicle d'optimització amb l'única palanca que redueix la factura sense tocar una línia de l'arquitectura.

Saps per què existeix el descompte per compromís —AWS construeix centres de dades per endavant i paga per la previsió de demanda— i les quatre conseqüències que se'n dedueixen soles, d'aquesta lògica: més termini, més pagament inicial i menys flexibilitat donen més descompte, i el risc es trasllada íntegre al client. Amb els quatre models de compra i l'arbre de decisió que els ordena: Spot si la càrrega tolera interrupcions, sota demanda si el consum és impredictible, Savings Plans per a EC2, Fargate i Lambda, i instàncies reservades per a tota la resta que sigui provisionat.

Tens els tres tipus de Savings Plans amb la comparació que de debò importa: l'EC2 Instance dona 6-8 punts més i et lliga a una família i una regió; el Compute dona una mica menys i sobreviu a canvis d'instància, de regió, d'arquitectura de CPU i de servei. I saps per què per a MercadoFresco no hi ha debat: la seva computació és Fargate i Lambda, que l'EC2 Instance no cobreix en absolut.

Tens el mecanisme del compromís per dòlar-hora entès de debò, amb les tres hores de l'exemple: l'hora que consumeix exactament el que s'ha compromès i estalvia un 20 %, l'hora de pic on l'excedent no es penalitza i simplement es paga a preu normal, i l'hora de matinada on el compromís no utilitzat es paga igual i fa que aquella hora costi un 70 % més del que hauria costat sense el pla. D'aquí la regla que ho governa tot: es dimensiona pel mínim sostingut de l'hora més fluixa de la setmana, mai per la mitjana i moltíssim menys pel pic.

Tens la taula de cobertura i la conclusió incòmoda que se'n deriva per a una arquitectura com aquesta: els 342,60 USD d'Aurora Serverless v2 i els 104,50 de Redshift Serverless no es poden comprometre de cap manera. I la seva interpretació correcta, que no és una queixa: serverless ja va cobrar aquest estalvi per endavant, escalant a zero quan no hi ha càrrega, i no es pot cobrar dues vegades el mateix estalvi.

Tens les instàncies reservades per al que els plans no abasten, amb les seves decisions —estàndard enfront de convertible, abast regional enfront de zonal, capacitat reservada, mercat de revenda només per a RI estàndard d'EC2— i Spot revisat des del cost, amb el criteri que decideix on entra i el detall que s'oblida: el consum Spot no consumeix compromís, així que es resta en calcular la base.

Tens l'anàlisi completa: el perfil horari de MercadoFresco amb el seu mínim sostingut de 0,214 USD/hora, la seva mitjana de 0,328 i el seu pic de 0,690; la regla del 70-85 % del mínim; i la raó per la qual es compren 0,17 i no els 0,29 recomanats per AWS, amb les quatre raons que fan que una recomanació automàtica sigui un punt de partida i mai una decisió, començant per la més determinant: dona per fet que el futur serà igual que el passat, i aquell passat incloïa un consum que les optimitzacions d'11-03 acabaven d'eliminar.

Tens el pla de compra amb el seu ADR: Compute Savings Plan de 0,17 USD/hora a un any sense pagament inicial des del compte de gestió, més dos nodes reservats d'ElastiCache a un any amb pagament parcial. I el resultat: 68,00 USD al mes, 816 USD a l'any, que deixen la factura en 1.681,60 USD i el cost per comanda en 0,00934 USD. Amb el balanç complet del mòdul —de 2.237,60 a 1.681,60 USD, un 24,8 % menys i 6.672 USD anuals— i la proporció que convé no oblidar mai: el 88 % de l'estalvi va venir d'apagar i netejar, i només el 12 % de comprometre.

I tens el seguiment: cobertura i utilització com a mètriques oposades, amb la regla que les ordena —la utilització ha de ser del 100 % i la cobertura no ho ha de ser—, el pressupost de tipus SAVINGS_PLANS_UTILIZATION amb operador LESS_THAN al 95 %, l'avís de venciment noranta dies abans perquè els plans no es renoven sols, el repartiment entre comptes amb la compartició de descomptes activada, i els tres errors cars: comprometre abans d'optimitzar, comprometre massa, i confondre cobertura amb utilització. Més el dany menys evident i més greu d'un compromís mal escollit: que condicioni decisions tècniques, convertint «no migrem per no malgastar el pla» en una frase que algú diu seriosament.

Amb això, el pilar d'optimització de costos que obria el pla de millora d'11-01 queda tancat: hi ha visibilitat, hi ha assignació, hi ha anàlisi, hi ha límits i hi ha compromisos. La factura és llegible, està controlada i costa un 24,8 % menys que fa dos mesos, amb el mateix servei i les mateixes garanties.

I amb això, MercadoFresco té l'arquitectura completa i governada: elàstica, segura, observable, desplegable, descrita en codi, repartida en cinc comptes, auditada amb mètode i ara també mesurada i pressupostada. Onze mòduls de decisions, cadascuna amb el seu perquè.

Queda una última cosa per fer, i no és aprendre un servei nou. A 11-06, el projecte final, es recorre l'arquitectura sencera de MercadoFresco associant cada peça al mòdul on es va aprendre, es tanca el balanç dels cinc problemes que van obrir el curs amb la seva mètrica, i es planteja el repte que ho integra tot: MercadoFresco obre a Portugal i França i llança una aplicació mòbil amb seguiment del repartiment en temps real. Amb el seu enunciat, la seva rúbrica, una solució de referència comentada, els camins de certificació, allò que aquest curs no ha tocat, i la neteja final de tot el que s'ha creat.