Amb les etiquetes activades i l'informe de costos i ús lliurant-se cada dia a mercadofresco-informes-analitica, MercadoFresco ja pot repartir la seva factura. Falta l'altra meitat: mirar-la de debò. No el total, no una taula resumida, sinó el desglossament complet per servei, entrar a les tres o quatre línies que gairebé ningú no entén, i sortir-ne amb una llista d'accions concretes i el seu estalvi calculat.

Aquesta lliçó fa aquest recorregut. Veuràs què és el Cost Explorer i amb quines dades treballa, els conceptes de facturació que cal entendre abans de mirar un gràfic —perquè, si no, els números no quadren i es perd la confiança en l'eina—, la factura real de MercadoFresco servei per servei fins als 2.237,60 USD, les tres sorpreses que apareixen gairebé sempre, la detecció d'anomalies de cost, les recomanacions automàtiques i la seva relació amb Compute Optimizer i Trusted Advisor, la consulta des de boto3 per publicar la despesa al costat del negoci, i les deu optimitzacions que MercadoFresco executa amb el seu estalvi una per una.

Avís de cost. La interfície del Cost Explorer és gratuïta. El que sí que costa és l'API: cada crida paginada a GetCostAndUsage i companyia es factura a 0,01 USD. Un tauler que consulti l'API cada cinc minuts són uns 90 USD al mes, un error car i sorprenentment freqüent. La detecció d'anomalies és gratuïta. Dades, comptes i identificadors ficticis; els preus són orientatius i varien segons la regió i la data.

1. Què és el Cost Explorer i amb quines dades treballa
2. Conceptes de facturació: no combinat, amortitzat i net
3. Càrrecs, crèdits, reemborsaments i impostos: per què la suma no quadra
4. Facturació consolidada entre els sis comptes
5. La factura de MercadoFresco, servei per servei
6. Sorpresa 1: els NAT Gateway
7. Sorpresa 2: la transferència de dades entre zones
8. Sorpresa 3: CloudWatch
9. Filtres, agrupacions i informes desats
10. El tauler de cost que revisa la Marta cada mes
11. Detecció d'anomalies de cost
12. El cas de la càrrega nocturna a Redshift
13. Recomanacions de reducció i recursos orfes
14. Compute Optimizer i Trusted Advisor
15. Previsió de despesa i com interpretar-la
16. Consultar el Cost Explorer des de boto3
17. Publicar la despesa diària com a mètrica de negoci
18. Les deu optimitzacions de MercadoFresco
19. Errors habituals i consells
20. Exercicis
21. Conclusió

L'AWS Cost Explorer és l'eina d'anàlisi interactiva de la factura: gràfics, filtres, agrupacions i previsions sobre la despesa i l'ús. S'activa una sola vegada des del compte de gestió i, a partir d'aquell moment, comença a preparar les dades.

El que cal saber abans de fiar-se d'un número:

La primera regla operativa que evita disgustos: no treguis mai conclusions del dia en curs. Amb el retard d'actualització, la despesa d'avui sempre sembla menor del que serà, i més d'un equip ha celebrat un estalvi que era simplement una dada incompleta.

Abans de mirar un gràfic cal entendre què s'està mesurant, perquè el Cost Explorer ofereix diverses mètriques de cost i donen resultats diferents per al mateix mes. És la causa número u de desconfiança en l'eina.

La diferència es veu millor amb un exemple que MercadoFresco viurà a 11-05. Suposem un Savings Plan d'1 any amb pagament total per avançat de 1.200 USD contractat l'1 de març:

Amb el cost no combinat, el gràfic mostra un pic enorme al març i una caiguda a zero després, cosa que és certa per a la tresoreria i absolutament inútil per analitzar l'eficiència. Amb l'amortitzat, cada mes carrega els 100 USD que li corresponen i el gràfic reflecteix el cost real d'operar.

La recomanació pràctica: fes servir el no combinat per quadrar amb la factura i el net amortitzat per analitzar. I digues sempre quin fas servir quan presentis un número, perquè dues persones mirant la mateixa pantalla amb mètriques diferents discutiran durant mitja hora sense adonar-se que totes dues tenen raó.

MercadoFresco, que encara no té cap compromís comprat, veu exactament el mateix número a les quatre mètriques. Això canvia a 11-05, i convé saber-ho per endavant.

La segona font de desconfiança és que la suma del Cost Explorer no coincideix amb l'import cobrat a la targeta. No és cap error: és que la factura conté tipus de línia que el Cost Explorer, per defecte, filtra o mostra per separat.

La factura de MercadoFresco d'agost, completa:

D'aquí surten dues regles que convé fixar a l'equip:

1. El número de treball és el cost de serveis: 2.237,60 USD. És el que es pot reduir amb decisions d'enginyeria. Els impostos no s'optimitzen, es paguen.
2. Els crèdits enganyen. Mentre durin, la despesa sembla menor del que és, i el dia que s'esgoten apareix un salt que ningú no ha provocat. MercadoFresco els exclou de l'anàlisi i els tracta pel que són: un descompte temporal.

L'organització o-a1b2c3d4e5 té la facturació consolidada activada, que és el comportament per defecte d'AWS Organizations (09-04). Implica tres coses que afecten directament aquesta anàlisi:

• Una sola factura i un sol mètode de pagament, emesos des del compte de gestió 999988887777. Els comptes membre no reben factura pròpia.
• Agregació d'ús per als trams per volum. Els 40 GB d'S3 de producció, els 12 de preproducció i els 8 de desenvolupament compten com a 60 GB a efectes de trams de preu. Amb volums petits l'estalvi és simbòlic, però amb transferència de dades o S3 a gran escala arriba a ser rellevant.
• Els compromisos es comparteixen. Un Savings Plan comprat en qualsevol compte cobreix l'ús de tots els altres, tret que se'n desactivi la compartició. És un punt central d'11-05.

Al Cost Explorer, el compte de gestió ho veu tot; un compte membre només es veu a si mateix, i únicament si l'accés està habilitat. La Marta treballa sempre des del compte de gestió amb el rol de només lectura de facturació, i el Luis i la Sara veuen el seu propi compte.

Aquest és el desglossament complet del mes d'agost, agrupat per servei, amb cost no combinat i els sis comptes consolidats:

El primer que cal fer amb una taula així és llegir-la al revés de com la mira tothom. La reacció típica és fixar-se en Aurora, que és la línia més gran, i començar a discutir si calen dos lectors. Però Aurora hi és per una decisió conscient, documentada i signada per gerència (l'ADR-014 d'11-01). El que és interessant són les línies que ningú no va decidir: el NAT, la transferència entre zones, CloudWatch i l'EC2 residual. Sumen 611,20 USD al mes, un 27,3 % de la factura, i cap d'elles no ha estat mai objecte d'una decisió explícita.

243,80 USD al mes, la tercera línia de la factura, per un component que ningú no recorda haver triat. És la troballa més repetida en totes les revisions de cost del sector.

El NAT Gateway es factura per dos conceptes:

El desglossament de MercadoFresco:

Dues observacions que canvien la conversa:

1. El 81 % del cost és el càrrec fix per hora, no el trànsit. Optimitzar el trànsit no arregla el problema; reduir el nombre de NAT sí.
2. Preproducció i desenvolupament paguen 143,80 USD al mes per sortir a internet, en entorns on no hi ha ni un sol client i on una hora sense sortida a internet no li importa a ningú. Dos NAT en desenvolupament són alta disponibilitat per a un entorn que ningú no considera crític.

I hi ha una tercera observació que connecta amb 10-02: bona part dels 756 GB de producció són descàrregues d'imatges d'ECR, crides a l'API d'S3 i enviament de registres a CloudWatch, és a dir, trànsit cap a serveis d'AWS que podria no passar pel NAT si hi hagués punts d'enllaç. MercadoFresco ja va posar quatre punts d'enllaç del camí crític; l'anàlisi pendent és si compensa posar-ne més, i la resposta —com es va veure a 10-02— és que set punts d'enllaç en dues AZ surten més cars que el NAT.

Dins dels 118,60 USD de la línia de VPC hi ha dues coses molt diferents:

La transferència entre zones és el cost més invisible d'AWS, perquè no té cap recurs a qui culpar: no apareix sota cap etiqueta, no hi ha cap tauler que la mostri i no es pot apagar. Apareix tota sola tan bon punt una arquitectura és Multi-AZ, que és justament el que es recomana per fiabilitat.

D'on surten aquests 54,40 USD a MercadoFresco:

• L'ALB reparteix entre dues AZ. Amb cross-zone load balancing activat —que en un ALB està sempre actiu i és gratuït per a l'ALB, però no per a l'NLB— una petició que arriba a l'AZ a pot acabar en una tasca de l'AZ b.
• Aurora replica de l'escriptor als dos lectors, i un d'ells és a l'altra zona. Cada byte escrit creua la zona.
• ElastiCache replica del primari a la rèplica, que és a l'altra AZ.
• Les tasques de Fargate llegeixen de l'escriptor d'Aurora, que és en una zona concreta; la meitat de les tasques creuen.

I aquí ve el més important: gairebé tot aquest cost és el preu de l'alta disponibilitat, i no s'ha d'eliminar. Aquest és el cas exemplar del compromís entre pilars d'11-01: es podria estalviar concentrant-ho tot en una zona, i es perdria exactament la propietat per la qual es va muntar Multi-AZ. El que sí que té sentit és reduir el creuament innecessari: dirigir les lectures al lector de la mateixa zona quan es pugui, i no moure volums grans de dades entre zones per costum.

L'acció correcta amb aquesta línia no és retallar-la, sinó saber que existeix, entendre-la i no descobrir-la el dia que la factura pugi un 40 % per un canvi de topologia.

214,90 USD, quarta línia de la factura. És la sorpresa que més incomoda, perquè l'observabilitat és una virtut i aquí apareix com una despesa considerable. El desglossament:

Les dues línies que dominen són ingesta i emmagatzematge de registres, i totes dues tenen la mateixa arrel: ningú no va decidir mai quant retenir ni què registrar. Concretant:

• Les aplicacions registren en nivell DEBUG a preproducció i a producció, perquè es va activar per depurar un incident a l'abril i no es va tornar a abaixar.
• Els registres d'accés de l'ALB i els del WAF van a CloudWatch Logs a més de a S3, i dupliquen el cost.
• Cap grup de registres no té retentionInDays configurat, cosa que significa retenció indefinida. Un grup creat fa un any continua guardant-ho tot.

Aquesta és la partida amb millor relació entre esforç i estalvi de tota la factura, i apareix a la llista d'optimitzacions de més avall.

La utilitat del Cost Explorer és creuar dimensions. Les agrupacions disponibles i per a què serveix cadascuna:

El tipus d'ús és la dimensió més infravalorada i la que resol més misteris. «Amazon Virtual Private Cloud: 362,40 USD» no diu res; agrupat per tipus d'ús apareixen EUW1-NatGateway-Hours: 198,00, EUW1-NatGateway-Bytes: 45,80, EUW1-VpcEndpoint-Hours: 64,20 i EUW1-DataTransfer-Regional-Bytes: 54,40, i de cop se sap exactament què cal fer.

Els informes desats són consultes amb els seus filtres i agrupacions, amb nom i compartides al compte de gestió. Els cinc de MercadoFresco:

L'últim és el més útil dels cinc: en una vista diària de desenvolupament, un recurs encès un dissabte es veu a primera ullada.

La Marta bloqueja 45 minuts el dia 5 de cada mes —quan les dades del mes anterior ja estan tancades— i segueix sempre el mateix guió. La disciplina de mirar sempre el mateix, en el mateix ordre, és el que converteix el soroll en tendència:

1. Total del mes enfront de l'anterior i enfront del mateix mes de l'any passat. Si la variació supera el ±10 %, s'explica abans de continuar.
2. Cost per comanda. És el primer número que es diu en veu alta, abans que el total (11-02).
3. Les cinc línies que més han pujat en valor absolut, no en percentatge. Un servei que passa de 0,40 a 1,20 USD ha pujat un 200 % i no importa.
4. Repartiment per entorn. Objectiu declarat: que el que no és productiu no superi el 25 % del total.
5. Cost sense etiquetar. Ha de tendir a zero; si puja, hi ha recursos nous creats fora del pipeline.
6. Anomalies detectades des de l'última revisió i què se n'ha fet, de cadascuna.
7. Previsió del mes en curs i comparació amb el pressupost (11-04).
8. Una acció concreta amb propietari i data. Només una. Una reunió mensual que produeix dotze accions a l'any executades val més que una que en produeix quaranta d'abandonades.

Mirar la factura un cop al mes té un problema evident: un error comès el dia 6 es descobreix el dia 5 del mes següent, amb trenta dies de despesa acumulada. L'AWS Cost Anomaly Detection cobreix aquest buit amb aprenentatge automàtic sobre el patró històric de despesa, i és gratuït.

Els conceptes:

• Un monitor defineix què es vigila: tots els serveis, un compte, una etiqueta o una categoria de cost.
• Una subscripció defineix a qui s'avisa, amb quin llindar i amb quina freqüència.
• Els llindars poden ser absoluts (més de X USD d'impacte) o percentuals (més d'un X % sobre el que s'espera). Es poden combinar amb AND/OR.

Els tres monitors de MercadoFresco:

Comentaris sobre les decisions preses aquí:

• MonitorType: DIMENSIONAL amb SERVICE crea automàticament un monitor per a cada servei que es faci servir. És l'opció per defecte assenyada i no s'ha de mantenir.
• El segon monitor existeix perquè els entorns no productius tenen un patró molt més pla: qualsevol pujada és sospitosa, mentre que a producció una pujada pot ser simplement un divendres bo.
• Frequency: IMMEDIATE només funciona amb SNS; el correu admet DAILY o WEEKLY. Per a l'avís immediat cal passar per SNS, que a més ja està integrat amb Chatbot i arriba al canal de l'equip.
• Els llindars combinats amb Or eviten les dues errades clàssiques: un llindar només percentual dispara constantment en serveis barats, i un de només absolut no detecta que un servei petit s'ha multiplicat per deu.

Un consell de calibratge: comença amb llindars alts i abaixa'ls. Un detector d'anomalies que avisa tres vegades per setmana se silencia en quinze dies i ja no serveix de res.

El 14 d'agost a les 09:12, alertas-mercadofresco rep aquest avís:

La investigació de la Sara segueix tres passos que serveixen de plantilla per a qualsevol anomalia de cost:

Els tres passos, amb el seu resultat concret:

1. Agrupar per tipus d'ús al Cost Explorer, filtrant a Redshift i als últims 14 dies. El resultat assenyala RPU-Hours, no l'emmagatzematge: el problema és computació, no dades.
2. Vista horària d'aquells dies. El patró és inequívoc: abans, un pic de 40 minuts a les 02:00; ara, activitat contínua des de les 02:00 fins a les 08:00.
3. CloudTrail i els registres de consultes. El 7 d'agost es va desplegar un informe nou amb una consulta que fa un producte cartesià per un JOIN sense condició. La consulta no falla: simplement triga sis hores, i mentrestant el grup de treball Serverless no es pausa mai.

El cost real de l'incident: 68,40 USD en set dies, que a aquest ritme serien uns 340 USD al mes, un 15 % de la factura, per un JOIN mal escrit.

Les tres accions que es prenen, i cap no és «arreglar la consulta» i prou:

La lliçó general: una anomalia de cost gairebé sempre és un error tècnic, no un problema de diners. L'avís de facturació va ser, en aquest cas, el sistema de detecció d'errors més eficaç que tenia l'equip.

El Cost Explorer inclou una secció de Rightsizing recommendations que analitza l'ús de CPU i memòria dels últims 14 dies i proposa reduir o apagar. Convé conèixer-ne els límits: només cobreix EC2 (no Fargate, no Lambda, no Aurora) i assumeix que el patró de les dues últimes setmanes es repetirà.

Per a MercadoFresco, que ja té gairebé tota la computació a Fargate, aquesta secció aporta poc. El que sí que aporta molt és la caça de recursos orfes, que no requereix cap eina especial:

Sumen 114,30 USD al mes en coses que ningú no fa servir, és a dir, un 5,1 % de la factura llençat. I són, sense excepció, restes de feina legítima: una prova que es va fer, un entorn que es va aixecar, una instància que es va aturar en lloc d'acabar-la.

L'script que MercadoFresco executa cada dilluns per detectar-los:

Dues decisions de disseny d'aquest script mereixen comentari. Només informa, mai no esborra: un volum available pot ser la còpia que algú va separar expressament abans d'una migració, i un esborrat automàtic destruiria dades. I s'executa setmanalment, no cada dia, perquè els orfes apareixen a poc a poc i un informe diari que gairebé sempre està buit es deixa de llegir.

Tres eines se solapen aquí i convé saber quina fer servir per a què:

Per a MercadoFresco, la més útil de les tres és Compute Optimizer, precisament perquè cobreix el que el Cost Explorer no veu:

• Lambda: recomana memòria per funció. La funció mercadofresco-generar-miniaturas està a 1.024 MB i fa servir 340 MB de pic; abaixar-la a 512 MB estalvia poc en diners però també redueix el temps, perquè la CPU escala amb la memòria. Aquí cal anar amb compte: abaixar la memòria d'una Lambda pot fer-la més lenta i més cara, i s'ha de mesurar amb l'ajust de potència, no suposar-ho.
• ECS a Fargate: valida el dimensionament per percentil que es va fer a 10-02, i assenyala que svc-mercadofresco-trabajadores està sobredimensionat en memòria.
• EBS: proposa passar els volums gp2 restants a gp3, un 20 % més barat amb el mateix rendiment base.

El repartiment de papers que funciona: Trusted Advisor per al que és evident i transversal, Compute Optimizer per al dimensionament fi, Cost Explorer per entendre els diners i decidir. Cap de les tres no substitueix la revisió mensual amb criteri humà, perquè cap no sap que un entorn de preproducció s'ha d'assemblar a producció encara que estigui infrautilitzat.

El Cost Explorer projecta la despesa futura amb un interval de confiança. Per a MercadoFresco, la previsió d'agost a mitjan mes era de 2.180 USD amb un interval del 80 % entre 2.050 i 2.310; el tancament real va ser de 2.237,60 USD, dins de l'interval.

Tres advertiments sobre la previsió, en ordre d'importància:

1. Extrapola el passat. No sap que l'1 de setembre s'apaga l'entorn de desenvolupament a les nits, ni que al desembre hi ha campanya. Tota decisió ja presa invalida la previsió.
2. L'interval de confiança forma part del número. Presentar «2.180 USD» sense dir «entre 2.050 i 2.310» converteix una estimació en una promesa, i algú la tractarà com a tal.
3. És molt dolenta a principi de mes. Amb tres dies de dades, la previsió de MercadoFresco va oscil·lar entre 1.900 i 2.600 USD. A partir del dia 10 s'estabilitza.

El seu ús legítim és com a entrada dels pressupostos amb llindar sobre cost previst d'11-04: assabentar-se el dia 8 que se superarà el pressupost és molt més útil que assabentar-se'n el dia 30, quan ja s'ha superat.

Tot el que hem vist es pot automatitzar amb l'API. L'exemple complet que MercadoFresco executa cada dia:

Els detalls que calen perquè això funcioni i no surti car:

• El client es crea a us-east-1. L'endpoint del Cost Explorer és global i viu allà; crear-lo a eu-west-1 produeix un error de connexió que despista bastant.
• RECORD_TYPE = Usage exclou impostos, crèdits i quotes, perquè la suma coincideixi amb el cost de serveis i no amb el total facturat.
• Cada crida costa 0,01 USD. Aquest script s'executa un cop al dia: 0,30 USD al mes. Executat cada cinc minuts des d'un tauler serien 87 USD al mes, més del que costa ElastiCache a preproducció.
• GroupBy admet un màxim de dues dimensions. Per a creuaments més rics, el camí és el CUR amb Athena d'11-02.
• La resposta ve paginada amb NextPageToken quan hi ha molts grups; en producció cal recórrer-la, i cada pàgina és una altra petició facturada.

El pas que converteix l'anàlisi en una cosa que es mira sense voler: portar la despesa al tauler on ja viu el negoci.

Per què això importa més del que sembla:

• Fa servir la dada de fa dos dies, no la d'ahir, pel retard d'actualització. Publicar la d'ahir produeix una sèrie amb valls falses que confonen més del que informen.
• Publica una sèrie per entorn i una de total, cosa que permet posar al tauler mercadofresco-negocio un gràfic amb CosteDiario al costat de PedidosConfirmados. Veure les dues línies juntes és la manera més directa d'entendre el cost unitari sense calcular res.
• Permet alarmes de CloudWatch sobre el cost, amb tota la maquinària del mòdul 5: llindars, dades absents, accions i silenciament. Una alarma de CosteDiario a desenvolupament per damunt de 10 USD avisa en hores, no en setmanes.
• Aquest script viu en una Lambda amb EventBridge Scheduler executant-se a les 06:00, i el seu cost total és de cèntims.

Amb tota l'anàlisi feta, la Marta i el Luis dediquen dos dies a executar. Aquestes són les deu accions, ordenades per estalvi:

El detall de les tres primeres, que són les que més aporten.

1. Apagada nocturna (118,00 USD). Preproducció i desenvolupament funcionen 24×7 per a un equip que treballa de 8 a 19 de dilluns a divendres. Encesos de 07:30 a 20:30 en dies laborables són 65 de les 168 hores setmanals: un 61 % de reducció en el que es pot apagar. Amb EventBridge Scheduler:

La zona horària explícita Europe/Madrid no és un detall menor: sense ella, l'horari d'estiu desplaça l'apagada una hora i, dues vegades l'any, algú troba l'entorn apagat a les 19:30. El que s'apaga: tasques de Fargate a zero, instàncies d'Aurora aturades —recordant que RDS i Aurora arrenquen sols als 7 dies d'estar aturats, així que cal un planificador que els torni a aturar—, i el grup de treball de Redshift, que es pausa sol.

2. Retenció de registres (74,00 USD). Dos canvis independents. El primer, posar retenció als 84 grups de registres:

El segon, abaixar el nivell de registre de DEBUG a INFO a producció, cosa que redueix la ingesta de 61 a uns 38 GB al mes. I una decisió d'arquitectura que es pren de passada: els registres d'accés de l'ALB i del WAF deixen de duplicar-se a CloudWatch Logs i es queden només a S3, on ja es consulten amb Athena i costen vint vegades menys.

3. De 2 NAT a 1 (66,00 USD). A preproducció i desenvolupament s'elimina un NAT per entorn i s'encamina el trànsit de les dues subxarxes privades pel que queda. La conseqüència real, escrita perquè ningú no se sorprengui: si cau l'AZ del NAT supervivent, aquell entorn es queda sense sortida a internet. A desenvolupament, això significa que el Luis no pot descarregar dependències durant una estona. A producció no es toca, i aquesta asimetria és exactament el que significa tractar els entorns segons la seva criticitat en lloc de per costum.

El resultat global:

I una observació honesta sobre aquesta llista: cap de les deu accions no ha degradat la producció. No s'ha tret cap lector d'Aurora al pic, no s'ha reduït l'observabilitat de producció per sota del que cal i no s'ha tocat la redundància de sortida a internet on hi ha clients. Un estalvi del 22 % sense tocar la qualitat del servei és el normal a la primera passada d'optimització d'una arquitectura que no s'ha revisat mai. La segona passada ja costa molta més feina per cada dòlar.

Error: comparar el mes en curs amb el mes anterior complet. El dia 12 sembla que s'ha estalviat un 60 %. Consell: compara períodes equivalents —dia 1 a 12 enfront de dia 1 a 12— o fes servir la previsió, mai un mes parcial contra un de tancat.

Error: treure conclusions de la despesa d'avui. Amb fins a 24 hores de retard, el dia en curs sempre sembla barat. Consell: treballa amb dades de fa dos dies com a mínim, i publica les mètriques amb aquest desfasament.

Error: barrejar cost no combinat i amortitzat en la mateixa conversa. Dues persones veuen números diferents i discuteixen mitja hora. Consell: digues sempre quina mètrica fas servir. No combinat per quadrar amb la factura, net amortitzat per analitzar.

Error: perseguir la línia més gran de la factura. Aurora és la més gran i és una decisió conscient i signada; els diners mal gastats són a les línies mitjanes que ningú no va decidir. Consell: ordena per «cost que ningú no ha decidit», no per import.

Error: consultar l'API del Cost Explorer des d'un tauler que es refresca cada minut. A 0,01 USD per petició, l'anàlisi de costos acaba sent una partida de la factura. Consell: consulta un cop al dia i publica el resultat com a mètrica de CloudWatch; els taulers llegeixen la mètrica, no l'API.

Error: activar la granularitat horària i oblidar-la. Té cost per registres consultats i es paga encara que gairebé no es faci servir. Consell: activa-la per a l'anàlisi concreta que la necessiti —el pic del divendres, la base estable d'11-05— i revisa si continua fent falta.

Error: llindars d'anomalia massa sensibles. Tres avisos per setmana i el canal se silencia. Consell: comença alt —25 USD o 40 %— i abaixa segons l'experiència real, amb llindars combinats absolut i percentual.

Error: esborrar orfes automàticament. Un volum available pot ser la còpia que algú va apartar abans d'una migració. Consell: el detector informa, la persona decideix. I abans d'esborrar, etiqueta amb FechaBaja i espera una setmana.

Error: apagar entorns sense avisar. L'equip es troba l'entorn caigut a les 20:31 enmig d'una prova. Consell: anuncia-ho, deixa un procediment d'encesa manual documentat i comença per desenvolupament abans que per preproducció.

Consell: la primera anàlisi d'una factura mai revisada rendeix entre un 15 i un 30 %. No cal ser brillant, cal mirar. El difícil és la segona passada.

Consell: converteix cada troballa en una comprovació permanent. La retenció de registres no és una tasca, és una regla de Config; el cicle de vida d'ECR no és un esborrat, és una política; l'apagada nocturna no és un recordatori, és un planificador.

El 3 d'octubre, alertas-mercadofresco rep un avís: Amazon S3 al compte 111122223333 ha passat de 4,20 a 19,80 USD diaris des del 28 de setembre. Impacte acumulat: 78,00 USD.

1. Enumera quatre hipòtesis ordenades de més a menys probable.
2. Indica quina agrupació i quin filtre faries servir al Cost Explorer per descartar-les.
3. Si la causa resulta ser que es va activar el registre d'accés al bucket mercadofresco-catalogo-fotos i aquests registres s'escriuen al mateix bucket, quines tres accions prendries?

Disposes d'un sol dia de feina i d'aquesta llista d'accions possibles sobre la factura de MercadoFresco:

1. Tria què faries en aquest dia i justifica-ho.
2. Per què F és perillosa ara mateix, si és la de més estalvi i menys esforç?
3. Calcula l'estalvi aconseguit i el percentatge sobre els 2.237,60 USD.

El Cost Explorer, filtrat a Amazon CloudWatch i agrupat per tipus d'ús, retorna per a un mes:

1. Tradueix cada línia al que significa a la pràctica.
2. Quines atacaries primer i amb quina acció concreta?
3. Estima l'estalvi si la ingesta baixa de 61 a 38 GB al mes i la retenció passa d'indefinida a 30/90 dies, sabent que l'emmagatzematge s'estabilitzaria al voltant dels 130 GB.

Solució a l'exercici 1

(1) Quatre hipòtesis, de més a menys probable:

1. S'ha activat un registre que escriu a S3 —accés al bucket, registres de l'ALB, del WAF, del CUR o de flux de la VPC— i el volum de peticions PUT s'ha disparat. És la causa més freqüent d'un salt brusc a S3, perquè el cost no és als bytes sinó a les peticions.
2. S'ha pujat un volum gran de dades: una càrrega inicial, una còpia de seguretat manual, una exportació de la base de dades.
3. Un procés en bucle que reescriu els mateixos objectes, o versionatge activat sense cicle de vida que conserva totes les versions antigues.
4. Transferència de sortida cap a internet o cap a una altra regió, si algun consumidor extern va començar a llegir directament del bucket saltant-se CloudFront.

(2) Com descartar-les. Filtre: servei = Amazon S3, compte = 111122223333, últims 30 dies, granularitat diària. Agrupació: tipus d'ús. Aquesta única vista discrimina les quatre hipòtesis en una ullada, perquè els tipus d'ús són diferents: Requests-Tier1 (peticions PUT) assenyala la primera o la tercera; TimedStorage-ByteHrs assenyala la segona; DataTransfer-Out-Bytes assenyala la quarta. Si Requests-Tier1 domina, un segon pas amb el CUR agrupant per line_item_resource_id dona el bucket exacte.

(3) Tres accions si és el registre d'accés escrivint al mateix bucket:

1. Moure el destí dels registres a mercadofresco-registros-web, mai al mateix bucket que s'està registrant. Escriure els registres d'accés al mateix bucket crea un bucle: cada escriptura de registre genera un accés, que genera un registre. És un error clàssic i pot créixer sense límit.
2. Posar cicle de vida a aquests registres: 30 dies a Standard, després Glacier Instant Retrieval, esborrat als 180. Els registres d'accés gairebé mai no es consulten passat el primer mes.
3. Preguntar-se si calen. Si l'objectiu era auditoria, els esdeveniments de dades de CloudTrail (05-03) ja cobreixen l'accés a S3 amb millor format i millor integració, i probablement ja estiguin actius. Un registre duplicat es paga dues vegades.

Solució a l'exercici 2

(1) Què faria en un dia (8 hores): B (1 h) + D (2 h) + E (2 h) = 5 hores, i amb les 3 hores restants començar A, deixant el planificador escrit i provat a desenvolupament però sense aplicar-lo encara a preproducció.

El raonament: B, D i E són de risc baix, esforç baix i efecte immediat, i juntes sumen 181 USD al mes en cinc hores de feina. A és la de més estalvi però necessita sis hores de rellotge més un avís a l'equip, així que partir-la és el més assenyat. C queda per a una altra setmana: vuit hores per 27 USD al mes és la pitjor relació de la llista, i a més té risc mitjà perquè exigeix provar la imatge arm64 a preproducció abans.

(2) Per què F és perillosa. Per una raó d'ordre que 11-05 desenvolupa i que convé interioritzar ara: comprometre capacitat abans d'optimitzar és comprar el que estàs a punt de deixar de fer servir. Si es compra un Savings Plan a tres anys dimensionat sobre el consum actual i la setmana següent s'executen les accions A a E, el consum baixa un 22 % i el compromís sobrant es paga igualment durant tres anys. A això s'hi sumen dos agreujants: tres anys és un horitzó en què l'arquitectura gairebé segur que canvia, i un Savings Plan no es pot cancel·lar. L'ordre correcte és sempre: primer apagar el que sobra, després dimensionar el que queda, i només aleshores comprometre.

(3) Estalvi aconseguit:

Vuit per cent de la factura en cinc hores de feina. És un rendiment que cap altra activitat tècnica no iguala, i és exactament per això que el pla de millora d'11-01 començava pel pilar de costos.

Solució a l'exercici 3

(1) Traducció de cada línia:

(2) Què atacar primer. Les dues línies de registres, que són el 71 % del total, i en aquest ordre:

1. Retenció (TimedStorage), perquè és el canvi de menys risc: una ordre per grup, cap efecte sobre l'aplicació i l'estalvi comença el mes següent. Només cal decidir amb criteri els grups d'auditoria, que han de conservar més temps.
2. Ingesta (DataProcessing), abaixant el nivell a INFO a producció i deixant de duplicar els registres de l'ALB i del WAF a CloudWatch quan ja són a S3.
3. En un tercer pla, revisar les 90 mètriques personalitzades i les 84 alarmes: gairebé sempre hi ha mètriques que ningú no grafica i alarmes que ningú no atén. Són 35 USD al mes i, més important, cada alarma que ningú no mira degrada la credibilitat de les que sí que importen.

(3) Estimació de l'estalvi:

Coincideix amb els 74 USD de l'acció 2 de la llista d'optimitzacions. Dos matisos per no prometre de més: l'estalvi de l'emmagatzematge no és immediat, perquè els registres existents van caducant al llarg de les setmanes següents segons la seva antiguitat, així que l'efecte complet es veu el segon o tercer mes; i baixar de DEBUG a INFO té un cost real que cal acceptar per escrit, que és tenir menys detall disponible el dia que calgui investigar un incident estrany a producció. La mitigació és deixar el nivell DEBUG activable sota demanda mitjançant un paràmetre a /mercadofresco/produccion/... sense necessitat de desplegar.

MercadoFresco ha obert la seva factura i n'ha sortit amb un 22 % menys de despesa i cap degradació del servei.

Saps què és el Cost Explorer i amb quines dades treballa: 13 mesos d'històric, granularitat diària gratuïta i horària de pagament, fins a 24 hores de retard —d'aquí la regla de no treure mai conclusions del dia en curs— i una interfície gratuïta amb una API que costa 0,01 USD per petició, que és l'error car que converteix un tauler de costos en una partida de la factura.

Tens els conceptes de facturació que cal entendre abans de mirar un gràfic: no combinat per quadrar amb la factura, amortitzat per analitzar quan hi ha compromisos —amb l'exemple del Savings Plan de 1.200 USD que es veu com un pic al març o com 100 USD al mes segons la mètrica—, i les variants netes que descompten crèdits. Més la raó per la qual la suma mai no quadra amb el que es cobra: els tipus de línia Tax, Credit, Refund i les quotes, amb la regla de treballar sempre sobre el cost de serveis, que és l'únic que s'optimitza amb enginyeria. I la facturació consolidada entre els sis comptes, amb les seves tres conseqüències: una sola factura, agregació de trams per volum i compromisos compartits.

Tens la factura completa de MercadoFresco: 27 línies fins als 2.237,60 USD, encapçalades per Aurora (342,60), Fargate (262,40), NAT Gateway (243,80) i CloudWatch (214,90). I la manera correcta de llegir-la, que no és de més gran a més petit sinó separant el que s'ha decidit del que no: Aurora hi és per un ADR signat, mentre que els 611,20 USD del NAT, la transferència entre zones, CloudWatch i l'EC2 residual —el 27,3 % de la factura— no els ha decidit mai ningú.

Tens les tres sorpreses desmuntades amb el seu origen concret. El NAT Gateway, del qual el 81 % és càrrec fix per hora i no trànsit, amb 143,80 USD al mes pagats per entorns sense ni un sol client. La transferència entre zones, el cost més invisible d'AWS perquè no té cap recurs a qui culpar, que neix de l'ALB repartint entre AZ, de la rèplica d'Aurora i de la d'ElastiCache, i que no s'ha d'eliminar perquè és el preu de l'alta disponibilitat. I CloudWatch, on el 71 % són registres i l'arrel és la mateixa a totes dues línies: ningú no va decidir mai què registrar ni quant retenir.

Tens les eines de vigilància: filtres i agrupacions —amb el tipus d'ús com la dimensió més infravalorada, la que converteix «VPC: 362,40 USD» en quatre línies accionables—, els cinc informes desats, el guió de vuit passos de la revisió mensual de la Marta que acaba sempre amb una sola acció amb propietari i data, i la detecció d'anomalies amb monitors dimensionals, llindars combinats absolut i percentual, i avís immediat per SNS. Amb el cas real de la càrrega nocturna a Redshift —un JOIN sense condició que costava 340 USD al mes i es va detectar per la factura— i la seva lliçó: una anomalia de cost gairebé sempre és un error tècnic, no un problema de diners.

Tens la caça de recursos orfes, 114,30 USD al mes en coses que ningú no fa servir, amb l'script setmanal que informa i mai no esborra; el repartiment de papers entre Cost Explorer, Compute Optimizer i Trusted Advisor, sabent que només Compute Optimizer veu Fargate i Lambda; la previsió amb els seus tres advertiments, començant perquè extrapola el passat i per tant qualsevol decisió ja presa la invalida; i la consulta des de boto3 amb get_cost_and_usage, el client a us-east-1, el filtre RECORD_TYPE=Usage i l'script que publica CosteDiario a MercadoFresco/Tienda amb dos dies de desfasament, perquè la despesa visqui per fi al mateix tauler que les comandes.

I tens les deu optimitzacions executades amb el seu estalvi: apagada nocturna (118), retenció de registres (74), de dos NAT a un en el que no és productiu (66), autoescalat de lectors d'Aurora (54), cicle de vida a S3 (38), orfes (41), punts d'enllaç de preproducció (32), arm64 als treballadors (27), límits a Redshift (27) i cicle de vida a ECR (11). 488,00 USD al mes, un 21,8 %, que deixen la factura en 1.749,60 USD i el cost per comanda en 0,00972 USD. Amb l'observació honesta que cap de les deu no ha degradat la producció, i amb l'advertiment sobre el que ve després: la primera passada d'optimització d'una arquitectura mai revisada rendeix entre un 15 i un 30 % sense ser brillant; la segona ja costa molta més feina per cada dòlar.

Queda un problema que aquesta anàlisi no resol. Tot l'anterior és mirar cap enrere: es descobreix el que ja s'ha gastat. El detector d'anomalies avisa en un dia o dos, cosa que està bé, però encara ningú no ha posat cap límit. Si demà el Luis aixeca un clúster d'EKS de proves al compte de desenvolupament i se n'oblida, o si una consulta nova es dispara un divendres a la nit, la factura creixerà sense que res s'hi interposi. I el presupuesto-mensual-mercadofresco de 10 USD creat a 01-02 fa vint-i-tants mesos que salta tots els dies 2, fins al punt que ja ningú no llegeix els seus correus.

A 11-04, «AWS Budgets», es passa d'analitzar a controlar: pressupostos per compte, per servei, per etiqueta i per categoria de cost, amb llindars sobre cost real i previst, amb avisos escalonats i amb accions automàtiques capaces de congelar el compte de desenvolupament quan arriba al seu límit. Més la rutina FinOps que sosté tot el cicle.