AWS Config va tancar la lliçó anterior amb una limitació honesta: comprova les regles que tu li has dit. És exacte i és potent, però no et pot avisar del que no se t'ha acudit preguntar.

Ningú no ha escrit una regla que digui «avisa'm si tinc volums EBS orfes costant diners», perquè per escriure-la primer caldria sospitar que existeixen. Ningú no ha escrit una regla sobre les IP elàstiques sense associar, que es facturen precisament per no fer-se servir. I no cal dir que ningú no ha escrit una regla sobre el límit de vCPU del compte, que —com veurem en aquesta lliçó— és la raó real per la qual asg-mercadofresco-tienda no pot passar de quatre instàncies.

AWS Trusted Advisor fa aquest repàs. Compara el teu compte amb un catàleg de bones pràctiques que AWS ha destil·lat de milions de clients, i et diu el que no havies pensat a preguntar. No és una eina de detecció en temps real ni un substitut de res del que hem vist: és el repàs automàtic, l'equivalent que algú amb molta experiència miri el teu compte un cop al mes i t'assenyali les coses òbvies que fa mesos que no veus perquè hi ets massa a prop.

Amb aquesta lliçó es tanca el mòdul 5, i amb ell la capa d'observabilitat de MercadoFresco.

1. Què és Trusted Advisor i en què es diferencia de Config
2. I en què es diferencia de Well-Architected
3. Les cinc categories
4. Què comprova cada categoria
5. Què veus segons el pla de suport
6. Com suplir el que el pla Basic no dona
7. Recorregut comentat d'un informe de MercadoFresco
8. Quotes de servei: el límit invisible
9. El cas de l'ASG que no passa de quatre instàncies
10. Sol·licitar un augment de quota
11. Alarmar abans de xocar amb una quota
12. Automatització: API, exportació i notificacions
13. Integració amb EventBridge
14. Compute Optimizer i Cost Optimization Hub
15. La rutina de revisió mensual de la Marta
16. Tancament del mòdul: la capa d'observabilitat completa
17. Les cinc preguntes del mòdul 4, respostes
18. Cost total afegit
19. El que ve: el coll d'ampolla s'ha mogut

La diferència de fons: Config respon preguntes; Trusted Advisor les fa.

Un exemple que ho aclareix. MercadoFresco té una regla de Config que comprova que tots els volums EBS estan xifrats. Perfecte. Però cap regla no comprova si un volum serveix per a alguna cosa, perquè a ningú se li va acudir. Trusted Advisor ho assenyala sense que ningú ho demani: «tens 3 volums en estat available, sense connectar a res, que fa des del març que costen 24 USD al mes».

No competeixen. Trusted Advisor et dona la troballa; Config la converteix en una regla permanent. El flux natural és: Trusted Advisor descobreix un problema que no havies previst → escrius una regla de Config perquè no torni a passar → la remediació ho corregeix sola. Aquest és el cicle complet.

Trusted Advisor mira cap avall, als recursos. Well-Architected mira cap amunt, a les decisions. Trusted Advisor et diu que una instància està infrautilitzada; Well-Architected et pregunta si la teva estratègia d'escalat és adequada per al teu patró de trànsit. Tots dos fan servir els mateixos cinc o sis pilars com a marc conceptual, i de fet les categories de Trusted Advisor són gairebé els pilars de Well-Architected, però operen a altures diferents.

Well-Architected s'estudia a 11-01, obrint el mòdul de bones pràctiques i costos.

Els tres estats possibles de cada comprovació:

I un advertiment que estalvia frustracions: el groc no sempre és un problema. Trusted Advisor no coneix el teu context. Una instància al 5 % de CPU pot ser un servidor de reserva perfectament justificat. Un bucket sense versionatge pot ser un bucket de fitxers temporals. Les troballes són hipòtesis que cal avaluar, no ordres.

Optimització de costos:

Rendiment:

Seguretat:

Tolerància a errors:

Límits de servei (quotes):

Comprova l'ús enfront de la quota de desenes de serveis i avisa quan se supera el 80 %. És la categoria més infravalorada i la que més caigudes ha causat en la història d'AWS. Té secció pròpia més avall.

Aquí toca ser completament honest, perquè és on hi ha més decepcions:

El que MercadoFresco veu amb el pla Basic (0 USD):

És a dir: amb el pla Basic, MercadoFresco veu seguretat bàsica i límits de servei, que no és poc —són les dues categories que més caigudes eviten— però no veu res de cost, rendiment ni tolerància a errors, ni té API per automatitzar.

Val la pena pujar a Business? El càlcul honest per a MercadoFresco:

Amb 600 USD de despesa, pagar 100 USD per Trusted Advisor no surt a compte només per les recomanacions. Però el pla Business inclou molt més que Trusted Advisor: suport tècnic 24×7 amb resposta en una hora per a producció caiguda, accés a arquitectes de solucions, i la possibilitat d'obrir casos tècnics. Aquesta és la raó real per contractar-lo, i cal decidir-ho amb aquest criteri, no per les comprovacions.

La decisió de MercadoFresco: continuar en Basic de moment i suplir el que falta amb el que ja s'ha après, amb revisió de la decisió quan la despesa superi els 2.000 USD mensuals o quan la botiga sigui crítica per al negoci fins al punt de necessitar suport amb SLA. Està anotat al registre de decisions, amb data, igual que la decisió sobre Shield Advanced a 04-04.

Aquí és on el mòdul sencer es paga. Cada comprovació que Trusted Advisor no dona en Basic es pot reproduir amb el que ja saps:

Els scripts concrets. Volums orfes, amb Config:

IP elàstiques sense associar, que es facturen per no fer-se servir:

Balancejadors sense trànsit en els últims 7 dies:

Certificats d'ACM a punt de caducar (recorda: els de CloudFront són a us-east-1):

Els certificats emesos per ACM i validats per DNS es renoven sols (03-03), però els importats no, i un certificat caducat tomba la botiga sencera. Aquesta comprovació mereix estar a la rutina mensual.

La conclusió que importa: amb Config, CloudWatch i un grapat de scripts, MercadoFresco reprodueix la major part del que donaria el pla Business, gratis. El que no pot reproduir és el suport tècnic amb SLA, i aquest és el veritable producte que es compra.

Aquest és l'informe complet, incloent-hi les comprovacions que MercadoFresco no veu amb Basic però que hem reproduït amb les tècniques de la secció anterior. Comentat troballa a troballa.

Comentari. El vermell del port 22 és exactament la mateixa troballa que va donar la regla mercadofresco-ssh-restringido de Config a 05-04. Dues eines independents assenyalant el mateix és la millor confirmació possible que és real. La diferència: Config ho remeia sol; Trusted Advisor només ho assenyala.

La clau de 412 dies és la de l'usuari integracion-proveedor de l'exercici 2 de 05-03. L'arranjament de fons no és rotar-la: és substituir-la per un rol assumible amb sts:ExternalId (04-01).

Comentari. Els tres grocs són exemples perfectes de troballes que cal avaluar, no obeir:

• Els 2 volums sense instantània són els volums arrel de les instàncies de l'ASG. No necessiten còpia: són efímers per disseny, es recreen des de lt-mercadofresco-tienda, i fer-los instantànies seria pagar per copiar una cosa que ja és a l'AMI. Es marca com a acceptat i es documenta.
• Els 2 buckets sense versionatge són mercadofresco-registros-web (registres de l'ALB) i mercadofresco-catalogo-fotos. El primer, correcte: els registres no se sobreescriuen. El segon sí que és una troballa real: si algú puja una foto equivocada sobre una de bona, no hi ha marxa enrere. Es corregeix.
• Les comprovacions d'estat de Route 53 són una troballa real i valuosa. MercadoFresco té un registre àlies cap a CloudFront (03-05) sense comprovació d'estat. No hi ha commutació per error configurada cap a res. És una decisió pendent que mereix discussió, no una correcció immediata.

Comentari. El groc de la compressió és diner directe: activar la compressió automàtica a CloudFront per a les respostes de l'API redueix la transferència de sortida, que és la partida més cara de CloudFront. És un canvi d'una casella. Es corregeix el mateix dia.

Comentari, troballa per troballa:

• Els 3 volums orfes van quedar d'instàncies acabades manualment durant les proves de 02-01 i 02-02. Ningú no els va esborrar perquè en acabar una instància, els volums addicionals no s'esborren llevat que DeleteOnTermination estigui actiu. És la troballa de cost més comuna d'AWS. S'esborren, després de comprovar que no contenen res.
• Les 2 IP elàstiques són de les proves del NAT i de la instància inicial. Una IP elàstica és gratis mentre estigui associada a una instància en execució; quan no ho està, es factura precisament per desincentivar l'acaparament. S'alliberen.
• mercadofresco-tienda-01 al 4 % és una troballa especialment interessant. Aquesta instància és l'original de 02-01, anterior a l'ASG. Ja no serveix per a res: el trànsit va a l'ALB i d'allà al grup. Està encesa des de llavors perquè ningú no es va recordar d'apagar-la. És exactament el tipus de cosa que només es detecta amb un repàs automàtic.
• Les 4 instantànies manuals de més de 6 mesos són de les proves de 02-04. Aquí cal aplicar criteri: abans d'esborrar-les convé comprovar que no hi ha cap obligació de conservació, i aquesta comprovació és la regla personalitzada de l'exercici 2 de 05-04.
• La recomanació de Savings Plans és la de més impacte de tot l'informe, i deliberadament no es tracta aquí: l'anàlisi de compromisos d'ús és la lliçó 11-05. Trusted Advisor ho assenyala; la decisió es pren amb Cost Explorer al davant.

El vermell de les IP elàstiques al 100 % és la troballa més urgent de l'informe, i és doblement interessant: és la mateixa causa que la troballa de cost. Les 2 IP sense associar estan consumint 2 de les 5 places de la quota. Si demà calgués una tercera passarel·la NAT o una IP per a alguna cosa, la crida a l'API fallaria amb AddressLimitExceeded i ningú no entendria per què. Alliberar-les resol les dues coses alhora.

I la fila de vCPU és la que porta al cas següent.

Tot compte d'AWS té quotes (abans «límits de servei») en pràcticament tot: quantes vCPU pots tenir corrent, quantes VPC, quantes regles per grup de seguretat, quanta concurrència de Lambda.

Existeixen per protegir AWS d'un ús descontrolat —accidental o maliciós— i per protegir-te a tu d'una factura sorpresa. La majoria són ajustables; algunes no.

El que fa perilloses les quotes és quan te n'assabentes: quan ja hi has xocat, en el pitjor moment possible. Un compte que funciona perfectament durant mesos pot fallar de cop el divendres en què necessita escalar.

Service Quotas és la consola on es veuen i es gestionen:

Les quotes que MercadoFresco vigila i per què:

Aquí hi ha el cas concret que anunciàvem, i és un exemple perfecte de per què aquesta categoria importa.

asg-mercadofresco-tienda està configurat amb mínim 2, desitjat 2, màxim 4. La Marta sempre havia assumit que aquell 4 era una decisió de disseny. En mirar les quotes descobreix que no del tot:

• Les instàncies són t3.large: 2 vCPU cadascuna.
• La quota de vCPU sota demanda estàndard del compte és 16.
• Altres càrregues del compte consumeixen 8 vCPU.
• Queden 8 vCPU disponibles = 4 instàncies t3.large.

El màxim de l'ASG no està limitat pel disseny: està limitat per la quota. I això té una conseqüència molt concreta i molt lletja.

El divendres a les 19:00, amb 900 comandes per hora i una capacitat de 600 comandes per hora per instància, MercadoFresco necessita almenys 2 instàncies només per al trànsit normal. Si arriba un pic del doble —una campanya, una menció a les xarxes, un divendres de pont— l'ASG intenta escalar. I si una altra cosa del compte hagués consumit vCPU entremig:

L'ASG no escala. Els clients veuen errors. I la causa no és a cap alarma de CloudWatch, ni a cap regla de Config, ni a cap traça d'X-Ray. És en una quota del compte que ningú no ha mirat mai.

Pitjor encara: la fallada es produeix en el pitjor moment possible, perquè és precisament quan escales que xoques amb el límit. És la fallada latent perfecta.

L'alarma mercadofresco-asg-al-maximo de 04-04 avisa quan el grup arriba al seu màxim, que és un bon senyal que fa falta més capacitat. Però avisa quan ja ets al sostre; no avisa que el sostre és més baix del que et pensaves.

Els estats possibles: PENDING, CASE_OPENED, APPROVED, DENIED, CASE_CLOSED.

Consells pràctics, apresos a base de disgustos:

1. Sol·licita amb antelació. Els augments petits s'aproven automàticament en minuts; els grans passen a un cas de suport i poden trigar dies. Sol·licitar el divendres a la tarda perquè hi estàs xocant ara mateix és exactament l'escenari que cal evitar.
2. Demana amb marge, però raonable. Demanar 64 vCPU quan en fas servir 8 és raonable si esperes créixer. Demanar-ne 10.000 sense justificació es denega.
3. Justifica. Si l'augment passa a suport, explicar el cas d'ús —«botiga de comerç electrònic amb pics els divendres, ASG que necessita escalar a 12 instàncies»— accelera molt.
4. Les quotes són per regió. Pujar-la a eu-west-1 no la puja a us-east-1. Si tens pla de recuperació davant de desastres en una altra regió, puja-la també allà, o descobriràs el problema el dia del desastre.
5. Algunes quotes són per compte, no per regió: IAM, S3, CloudFront.
6. Sol·licita amb Organizations quan tinguis diversos comptes (09-04): les plantilles de quota apliquen valors per defecte als comptes nous.

I l'aritmètica que cal fer abans de decidir el valor:

Fixa't en la quarta fila: un desplegament blau/verd duplica temporalment el nombre d'instàncies. És un cas que s'oblida sistemàticament en calcular quotes, i és la causa que molts primers desplegaments sense interrupció fallin. S'estudia a 08-03.

Service Quotas publica mètriques d'ús a CloudWatch a l'espai AWS/Usage. Això permet alarmar abans d'arribar al límit, que és el que converteix una quota de parany en una dada gestionada.

Aquell llindar d'11 és el 70 % de 16. La manera elegant d'expressar-ho, que s'ajusta sola si la quota canvia, és una expressió de mètrica amb la funció SERVICE_QUOTA():

SERVICE_QUOTA() és la funció que fa que això funcioni bé: retorna el valor actual de la quota per a aquesta mètrica. Si demà AWS aprova l'augment a 64, l'alarma es recalibra sola sense que ningú toqui res. És exactament el tipus de detall que separa una alarma que envelleix bé d'una que s'ha de mantenir.

La mateixa tècnica per a la concurrència de Lambda, que és l'altra quota que pot mossegar MercadoFresco al pic de pujada de fotos al catàleg:

Cost: 0,10 USD per alarma. Dues alarmes de quota, 0,20 USD al mes, per evitar una fallada d'escalat al pic d'un divendres. És probablement la millor relació cost-benefici de tot el mòdul.

Important: l'API de Trusted Advisor (support i trustedadvisor) requereix pla Business o superior. Amb Basic, aquestes ordres retornen un error de subscripció. S'inclouen perquè és el que faràs servir tan bon punt la teva organització tingui aquest pla.

L'API de support només és a us-east-1. És global i s'atén des d'allà, igual que ACM per a CloudFront (03-04) o les Web ACL de CloudFront (04-05). És un patró recurrent a AWS que ja reconeixes.

Un script que exporta l'informe complet a CSV per a la revisió mensual:

Notificacions setmanals per correu: amb pla Business o Enterprise, Trusted Advisor envia un resum setmanal als contactes configurats. S'activen a les preferències de la consola, i els destinataris són els contactes alternatius del compte —el contacte d'operacions, el de seguretat, el de facturació—, que vam configurar a 01-02. Si llavors no els vas configurar, aquest és el moment: [email protected].

Trusted Advisor emet esdeveniments quan l'estat d'una comprovació canvia. Amb EventBridge (07-03) es pot reaccionar automàticament:

Dos detalls: els esdeveniments de Trusted Advisor s'emeten a us-east-1, així que la regla va allà; i el filtre per check-name és imprescindible, perquè sense ell rebries un avís cada vegada que canvia qualsevol de les ~115 comprovacions.

El que EventBridge habilita, i que és el patró a copiar: no només notificar, sinó actuar. Una regla pot invocar una Lambda que, davant d'una troballa de «clau d'accés exposada», desactivi la clau immediatament. Quan una clau apareix en un repositori públic, cada minut compta. El detall complet d'EventBridge —patrons, objectius, busos, reintents— és la lliçó 07-03.

Dos serveis complementaris que s'esmenten aquí i es desenvolupen al mòdul 11:

AWS Compute Optimizer analitza les mètriques de CloudWatch dels últims 14 dies —més si actives les mètriques de memòria de l'agent que vam instal·lar a 05-01— i recomana el tipus d'instància òptim per a cada càrrega. És gratis per a les recomanacions bàsiques.

Sortida típica per a MercadoFresco:

I aquí convé un advertiment important: Compute Optimizer no sap que mercadofresco-tienda-01 no hauria d'existir. Recomana reduir-la a t3.small i estalviar 20 USD. La resposta correcta és apagar-la, i estalviar-ne 60. Les eines automàtiques optimitzen el que hi ha; la pregunta de si hi ha de ser la continua fent una persona.

Compute Optimizer analitza també volums EBS, funcions Lambda —recomanant la memòria òptima, que a Lambda determina també la CPU— i serveis d'ECS a Fargate (mòdul 10).

Cost Optimization Hub consolida en un sol lloc les recomanacions de cost de Compute Optimizer, Trusted Advisor, Cost Explorer i les recomanacions de reserves, amb l'estalvi estimat agregat i sense duplicar. És la lliçó 11-03.

Aquesta lliçó no entra en costos. El mòdul 11 sencer hi està dedicat: etiquetatge i assignació (11-02), Cost Explorer (11-03), Budgets (11-04) i Savings Plans (11-05).

Aquesta és la llista de comprovació concreta que la Marta executa el primer dilluns de cada mes, en una hora. És el producte operatiu de tot el mòdul 5.

Seguretat (15 minuts)

• [ ] Trusted Advisor, categoria de seguretat: cap vermell.
• [ ] Quadre de compliment de Config: nombre de regles no conformes enfront del mes passat.
• [ ] aws cloudtrail validate-logs sobre el mes anterior; desar-ne la sortida.
• [ ] Consulta d'Athena: IP d'origen desconegudes i AccessDenied agrupats (05-03).
• [ ] Revisar usuaris IAM amb claus de més de 90 dies.
• [ ] Comprovar que no hi ha activitat del compte arrel.

Cost (10 minuts)

• [ ] Volums EBS available (consulta de Config).
• [ ] IP elàstiques sense associar.
• [ ] Balancejadors sense trànsit en 7 dies.
• [ ] Recomanacions de Compute Optimizer.
• [ ] Comparar la factura del mes amb la de l'anterior; investigar qualsevol desviació superior al 20 %.
• [ ] Instantànies manuals d'RDS i EBS de més de 6 mesos.

Fiabilitat (10 minuts)

• [ ] Trusted Advisor, tolerància a errors.
• [ ] Quotes de servei: res per damunt del 70 %.
• [ ] Certificats d'ACM: cap a menys de 60 dies de caducar (a les dues regions).
• [ ] Comprovar que el canari canario-mercadofresco-compra no ha fallat.
• [ ] Revisar que les polítiques de DLM han creat les instantànies previstes (02-02).

Observabilitat (15 minuts) — el més important i el que més se salta

• [ ] Simulacre trimestral: set-alarm-state sobre una alarma crítica i confirmar que l'avís arriba al telèfon de guàrdia.
• [ ] Subscripcions d'SNS: cap en PendingConfirmation.
• [ ] Grups de registres sense retenció (regla de Config, hauria de donar zero).
• [ ] Cost de CloudWatch del mes: ha crescut? Per què?
• [ ] Alarmes que han saltat aquest mes: alguna va ser un fals positiu? Ajustar llindar o esborrar-la.
• [ ] Alarmes que no van saltar quan tocava: afegir la que falta.

Aquest penúltim punt és el que manté viu el sistema. Una alarma que dona falsos positius repetits acaba sent ignorada, i el dia que sigui real ningú no la mirarà. Una alarma que s'ignora és pitjor que no tenir alarma, perquè dona una falsa sensació de cobertura. Esborrar alarmes és tan important com crear-les.

Deute tècnic (10 minuts)

• [ ] Revisar el registre de decisions: alguna amb data de revisió vençuda? (Shield Advanced a 04-04, pla de suport en aquesta lliçó, migració a ADOT a 05-02).
• [ ] Regles de WAF marcades com a temporals durant un incident (04-05).
• [ ] Excepcions acceptades de Config i de Trusted Advisor: continuen sent vàlides?

Les cinc peces i què respon cadascuna, que és el resum que cal endur-se:

I les connexions entre elles, que són el que converteix cinc serveis en un sistema:

• CloudTrail dispara l'enregistrament de Config: sense CloudTrail, Config no s'assabenta dels canvis.
• CloudWatch rep els esdeveniments de CloudTrail i els converteix en alarmes de seguretat.
• ServiceLens uneix les mètriques de CloudWatch amb les traces d'X-Ray i els registres.
• Trusted Advisor descobreix el que no se't va acudir; Config ho converteix en regla permanent.
• Config remeia; CloudTrail registra la remediació; CloudWatch avisa que ha passat.

El camí complet d'un incident, que ara MercadoFresco té sencer:

Alarma de CloudWatch → ServiceLens → traça d'X-Ray → subsegment culpable → registre correlacionat → CloudTrail si hi va haver intervenció humana → regla de Config perquè no torni.

El mòdul 4 es va tancar amb cinc preguntes obertes. Aquestes són les respostes, amb nom i cognoms:

1. «Ningú no ha comprovat que un avís d'SNS arribi a un telèfon a les 4 de la matinada.»

Resposta a 05-01. Es van comprovar les subscripcions d'alertas-mercadofresco buscant el temut PendingConfirmation, es va subscriure el correu [email protected] i el telèfon de guàrdia, i es va fer el simulacre amb set-alarm-state, que dispara les accions reals sense tocar la mètrica. A més es va descobrir que el «no molestis» del mòbil silenciava els SMS de números curts: la cadena d'avís inclou el telèfon, i el telèfon també s'ha de provar. Queda com a simulacre trimestral a la rutina mensual.

2. «Els registres de WAF, VPC, ALB i Lambda s'acumulen en cinc llocs sense correlacionar.»

Resposta a 05-01. Centralització a CloudWatch Logs del que es pot centralitzar —aplicació, nginx, Lambdas, WAF (aws-waf-logs-mercadofresco), flow logs (flowlogs-mercadofresco) i PostgreSQL— amb retenció per grup des del primer dia, i amb l'honestedat de reconèixer el que no hi va: els accessos de l'ALB i de CloudFront viuen a S3 i es consulten amb Athena. Logs Insights consulta fins a 50 grups alhora, i això és el que fa possible la correlació.

3. «Si un client diu que la seva comanda triga 8 segons, la Marta no sap si el problema és a la botiga, a la Lambda o a la base de dades.»

Resposta dues vegades. Primer a 05-01, amb quatre consultes de Logs Insights sobre quatre grups i una cronologia muntada a mà: 7.402 ms dins de PostgreSQL. Després a 05-02, en una sola cerca —annotation.pedido_id = "48213"— i una vista de cascada on el problema es llegeix en dos segons: 39 subsegments de 190 ms en sèrie, el 91 % del temps, un patró N+1. Corregit amb WHERE id = ANY(...): p95 de 6,8 s a 0,44 s, i DatabaseConnections de 185 a 96 al pic del divendres.

4. «Ningú no sap qui va desxifrar l'última còpia.»

Resposta a 05-03. Tres esdeveniments de kms:Decrypt sobre mercadofresco-pedidos: RDS xifrant la seva còpia automàtica, una instància de l'ASG des de 10.0.11.24, i rol-restauracion-copias a les 03:42 des de 198.51.100.77, sense MFA, sobre snapshot-2026-07-27. La investigació completa —congelar l'evidència, trobar l'AssumeRole real, reconstruir la sessió per accessKeyId— va portar al Luis provant una restauració de matinada. Intenció correcta, procediment incorrecte. Amb accions correctives i dates, i una alarma per a la propera vegada.

5. «Res no avisa si algú desactiva el xifratge d'un bucket o obre un SG al món.»

Resposta a 05-04. I no només avisa: ho corregeix. Cronologia completa: T+0 algú desactiva el xifratge, T+3 min Config crea el CI i avalua NON_COMPLIANT, T+4 min la remediació executa AWS-EnableS3BucketEncryption, T+8 min conforme un altre cop. Sense intervenció humana, amb el rastre complet a CloudTrail. I el quadre de compliment inicial va trobar catorze recursos que feia mesos que incomplien sense que res els detectés, perquè no eren esdeveniments: eren estats.

I una sisena, que ningú no havia formulat i que apareix en aquesta lliçó: l'ASG no pot passar de quatre instàncies per una quota de vCPU del compte que ningú no havia mirat mai. Aquest és exactament el tipus de problema que només troba un repàs automàtic, i és el millor argument a favor de Trusted Advisor i de Service Quotas.

Posat en context:

L'observabilitat és el 9,9 % de la despesa total. És una proporció alta comparada amb la seguretat, i val la pena dir per què és raonable: el 70 % d'aquesta xifra són CloudWatch i el canari, és a dir, la ingesta de registres i la comprovació contínua que es pot comprar. I enfront del que costa: la correcció de l'N+1 que va trobar X-Ray per 10,60 USD al mes va reduir a la meitat la pressió sobre la base de dades, evitant una ampliació d'instància RDS que hauria costat 80 USD mensuals. L'observabilitat es va pagar sola el primer mes.

I les cinc decisions que mantenen aquesta xifra en 62 USD en lloc de en 600:

1. Retenció a cada grup de registres el dia que es crea (05-01).
2. Cap dimensió de cardinalitat alta en mètriques personalitzades (05-01).
3. Mostreig d'X-Ray al 0 % a /salud i estàtics, 100 % a comandes (05-02).
4. Selectors d'esdeveniments de dades per prefix i readOnly: false (05-03).
5. recordingFrequency: DAILY per a instàncies i volums a Config (05-04).

Cinc línies de configuració que separen 62 USD de més de 600.

1. Esperar que Trusted Advisor ho vegi tot amb el pla Basic. Amb Basic veus seguretat bàsica i límits de servei. Res de cost, rendiment ni tolerància a errors, i sense API.

2. Obeir els grocs sense criteri. Trusted Advisor no coneix el teu context. Un volum arrel d'una instància efímera no necessita instantànies. Cada troballa és una hipòtesi; documenta les que acceptes i per què.

3. Ignorar la categoria de límits de servei. És la que més caigudes ha causat, i és de les poques disponibles al pla gratuït. Revisa-la sempre.

4. Sol·licitar un augment de quota quan ja hi estàs xocant. Els augments grans passen a un cas de suport i triguen dies. Alarma al 70 % i demana amb antelació.

5. Oblidar que les quotes són per regió. Pujar-la a eu-west-1 no la puja a eu-central-1. Si tens pla de recuperació en una altra regió, puja-la també allà.

6. No comptar el desplegament blau/verd en calcular vCPU. Duplica temporalment les instàncies. És la causa més freqüent que un primer desplegament sense interrupció falli (08-03).

7. Confondre Trusted Advisor amb Config. Config comprova les teves regles i remeia; Trusted Advisor comprova les d'AWS i només assenyala. El cicle bo és: Trusted Advisor descobreix → Config converteix en regla → la remediació ho corregeix.

8. Refrescar comprovacions a mà constantment. Es refresquen soles cada 24 hores. Refrescar manualment abans d'una revisió concreta està bé; fer-ho cada hora no aporta res.

9. Contractar el pla Business només per Trusted Advisor. Fes el càlcul: si l'estalvi detectat no cobreix el cost, la raó per contractar-lo és el suport tècnic amb SLA, no les comprovacions. Decideix-ho amb aquest criteri.

10. Deixar que les troballes s'acumulin. Un informe amb 40 troballes permanents deixa de llegir-se. Resol-les, accepta-les formalment amb justificació, o treu-les de l'abast. Un informe net és un informe que algú mira.

11. No revisar les alarmes que donen falsos positius. Una alarma ignorada és pitjor que no tenir alarma. La revisió mensual inclou esborrar alarmes, no només crear-ne.

12. Optimitzar una instància que no hauria d'existir. Compute Optimizer recomana reduir mercadofresco-tienda-01 a t3.small. La resposta correcta és apagar-la. Les eines optimitzen el que hi ha; la pregunta de si hi ha de ser la fa una persona.

Consell final del mòdul: l'observabilitat no s'«acaba». Es manté. El sistema que has muntat en aquestes cinc lliçons es degrada sol si ningú no en té cura: apareixen alarmes sorolloses, registres sense retenció, regles no conformes que es normalitzen, quotes que s'acosten. L'hora mensual de la rutina de la Marta és el que manté viu tot el que hi ha. Sense ella, en sis mesos tens un tauler que ningú no mira i un munt de serveis facturant.

MercadoFresco creix. Dades actuals:

Plans disponibles: Basic (0 USD), Developer (29 USD/mes o 3 % de la despesa, el que sigui més gran), Business (100 USD/mes o del 3 al 10 % de la despesa segons trams, el que sigui més gran).

Calcula el cost real de cada pla amb aquesta despesa. Estima el cost d'una caiguda de 95 minuts un divendres en hora punta. Decideix quin pla contractaries, justificant-ho amb números i no només amb les comprovacions de Trusted Advisor. Indica què faries amb el que el pla escollit no cobreix.

MercadoFresco espera per al Black Friday un pic de 5 vegades el trànsit habitual durant 6 hores. Situació actual:

A més, l'equip vol fer un desplegament blau/verd la setmana anterior per publicar la campanya.

Calcula: quantes instàncies calen al pic, quantes vCPU, quines quotes es queden curtes i en quant. Escriu les sol·licituds d'augment amb els valors que demanaries i la seva justificació. Dissenya les alarmes de quota que muntaries. Indica quins altres límits que no són d'AWS revisaries, i amb quanta antelació faries cada cosa.

És el primer dilluns d'octubre. La Marta executa la seva rutina i troba això:

Seguretat

• Trusted Advisor: 1 vermell — «Grups de seguretat: ports específics sense restricció».
• Config: 3 regles no conformes (el mes passat n'eren 0).
• validate-logs: falta un fitxer de resum del 14 de setembre.
• Athena: 2.400 AccessDenied de rol-mercadofresco-tienda sobre s3:GetObject.

Cost

• Factura de CloudWatch: de 44 a 71 USD.
• 1 volum EBS available de 200 GiB, creat el 22 de setembre.
• Compute Optimizer: les instàncies de l'ASG marcades com a under-provisioned.

Fiabilitat

• Quota de vCPU al 75 %.
• El canari canario-mercadofresco-compra ha fallat 14 vegades, totes entre les 03:00 i les 03:20.

Observabilitat

• L'alarma mercadofresco-pedidos-fallidos ha saltat 23 vegades aquest mes; 21 van ser falsos positius.
• Una subscripció d'SNS en PendingConfirmation: el correu de la persona nova.

Per a cadascuna de les onze troballes: digues què significa amb tota probabilitat, quina prioritat li dones (crítica, alta, mitjana, baixa), quina acció concreta prendries, i de quina lliçó del curs prové el coneixement necessari. Identifica quines d'aquestes troballes estan relacionades entre si, que és la part que distingeix una revisió mecànica d'una revisió útil.

Solució 1

Cost real de cada pla amb 2.400 USD de despesa mensual:

Compte amb el càlcul de Developer i Business: és el més gran entre el mínim i el percentatge. Amb 2.400 USD de despesa, Business costa 240 USD, no 100.

Cost d'una caiguda de 95 minuts un divendres en hora punta:

Dues caigudes l'any ≈ 700-900 EUR de marge perdut, més el dany d'imatge en una botiga de producte fresc, on la confiança en el lliurament en 24 h és el producte.

La decisió: Business, 240 USD/mes. I la justificació no són les comprovacions de Trusted Advisor:

El número que tanca la decisió: 240 USD/mes són 2.880 USD/any. Si el suport amb SLA redueix la durada d'una sola caiguda de 95 a 30 minuts, s'estalvien uns 240 EUR de marge. Amb dues caigudes l'any, no arriba a pagar-se només per això.

Però l'equip són tres persones, una guàrdia informal i cap possibilitat d'escalar a ningú a les 4 de la matinada. L'argument real és de risc, no d'estalvi: amb 185.000 EUR mensuals depenent de la plataforma, no tenir a qui trucar quan alguna cosa greu falli és un risc desproporcionat enfront de 2.880 USD anuals. És el mateix tipus de raonament que a 04-04 va portar a no contractar Shield Advanced —allà el cost era 100 vegades més gran i el risc molt menor—, aplicat en sentit contrari. La conclusió diferent amb el mateix mètode és el que demostra que el mètode és bo.

El que Business no cobreix i cal continuar fent:

I una condició perquè la decisió sigui bona: contractar Business i no canviar res més seria llençar els diners. La decisió inclou establir torns de guàrdia formals entre les tres persones, amb el simulacre de set-alarm-state verificat per a cada telèfon (05-01). El suport d'AWS respon en una hora; algú de MercadoFresco ha d'estar despert per llegir aquesta resposta.

Solució 2

Càlcul de capacitat.

El marge del 50 % no és paranoia: el número de 600 comandes/hora per instància es va mesurar en condicions normals. Al Black Friday la cistella mitjana és més gran, hi ha més cerques per comanda i més abandonaments amb reintents. La capacitat per instància baixarà, no pujarà.

Quotes que es queden curtes:

Sol·licituds d'augment:

Justificació per al cas de suport, si escala: «Botiga de comerç electrònic d'alimentació. Campanya de Black Friday amb pic previst de 5× el trànsit habitual durant 6 hores el 27 de novembre. Necessitem escalar el grup d'autoescalat a 12 instàncies t3.large i fer un desplegament blau/verd previ que duplica temporalment la capacitat. Sol·licitem 64 vCPU amb marge.»

La fila més important de la taula de quotes és la que no és una quota d'AWS: les connexions d'RDS. Amb 12 instàncies × 40 connexions d'agrupació = 480 connexions, contra un max_connections de 200. La base de dades es converteix en el coll d'ampolla abans que EC2. I aquesta no s'arregla amb una sol·licitud a AWS: s'arregla amb arquitectura.

Altres límits que no són quotes d'AWS i que cal revisar:

La cinquena fila és la que un perfil tècnic oblida i la que surt més cara: escalar la botiga per acceptar 4.500 comandes/hora que el magatzem no pot preparar converteix un èxit comercial en una catàstrofe de servei al client. El límit real de MercadoFresco pot ser a la nau, no a AWS.

Alarmes de quota a muntar:

La tercera és especialment astuta: instàncies encallades en Pending durant 15 minuts és exactament el que es veu quan els llançaments fallen per quota.

Cronograma, amb antelació realista:

La prova de càrrega de la quarta fila és el que converteix tot l'anterior en un pla i no en una esperança. Si no ho has provat, no saps si escala.

Solució 3

Troballes, amb prioritat i relacions.

La troballa 3 és la més greu de totes i cal dir per què. Un fitxer de resum absent significa que la cadena d'integritat de CloudTrail està trencada el 14 de setembre. Pot ser un problema de lliurament d'AWS —passa, rarament— o pot significar que algú va esborrar fitxers de registre per amagar activitat. No es pot distingir sense investigar, i fins que no es descarti cal tractar-ho com un possible incident de seguretat:

Si l'Object Lock en mode COMPLIANCE de 05-04 estava actiu, ningú no va poder esborrar res i l'explicació és un problema de lliurament d'AWS: s'obre un cas de suport i es documenta. Si no ho estava, cal investigar de debò. Aquesta és la millor demostració pràctica de per què l'Object Lock importava.

Relacions entre troballes, que és la part que distingeix una revisió útil:

Grup A: troballes 1, 2 i 3 — probablement el mateix incident.

Tres regles de Config que van passar de conformes a no conformes, un port obert, i un forat a l'auditoria. És massa coincidència. La línia temporal de Config dirà exactament quan es van tornar no conformes les regles, i si aquesta data és el 14 de setembre, ja no és una coincidència: és un incident que cal reconstruir sencer.

Grup B: troballes 4 i 5 — el mateix desplegament.

2.400 AccessDenied sobre s3:GetObject signifiquen que hi ha una funcionalitat trencada que cap client no ha reportat. I cada fallada genera una línia d'error al registre, cosa que explica en bona part l'augment de CloudWatch de 44 a 71 USD. Un problema de permisos s'ha manifestat com un problema de cost. Arreglar el permís arregla les dues coses.

Grup C: troballes 7 i 8 — el mateix problema de capacitat.

Compute Optimizer diu que les instàncies es queden curtes, i la quota de vCPU és al 75 %. Són les dues cares del mateix: MercadoFresco ha crescut i la capacitat no ha seguit. I hi ha un parany: si es resol la 7 escalant a més instàncies, s'agreuja la 8. La seqüència correcta és primer sol·licitar l'augment de quota, després escalar. A l'inrevés, l'ASG intentarà llançar i fallarà.

Grup D: troballes 9 i 6 — la finestra de manteniment.

El canari falla entre les 03:00 i les 03:20. Què passa a aquella hora? La finestra de manteniment d'RDS i la de còpies automàtiques (02-04). Durant una commutació Multi-AZ hi ha uns segons d'indisponibilitat, i el canari ho detecta. I això és una bona notícia disfressada de problema: el canari funciona i està mesurant un impacte real que els clients també pateixen, encara que de matinada afecti poca gent. Accions: comprovar si l'aplicació reintenta correctament les connexions perdudes (patró de 07-05), i valorar moure la finestra a una hora amb encara menys trànsit.

El volum orfe del 22 de setembre probablement vingui d'una instància acabada en aquell mateix treball de manteniment.

Grup E: troballes 10 i 11 — la salut del sistema d'avisos, i són les més urgents del que sembla poc urgent.

• 21 falsos positius de 23 signifiquen que mercadofresco-pedidos-fallidos ja no la mira ningú. El seu llindar fix de 10 errors en 5 minuts no aguanta el creixement del trànsit: amb més comandes hi ha més errors absoluts encara que la proporció sigui la mateixa. La correcció és la de la solució 1 de 05-01: alarmar sobre el percentatge, no sobre el número absolut, amb una expressió de mètrica.
• La subscripció pendent significa que la persona nova no ha rebut ni un sol avís des que va entrar. Si estava de guàrdia alguna nit, no hi havia ningú de guàrdia. Es reenvia la confirmació i es fa un simulacre amb set-alarm-state contra el seu telèfon, que és exactament el protocol d'incorporació de 05-01.

Ordre d'actuació recomanat:

La lliçó de l'exercici: onze troballes aïllades semblen una llista de tasques. Agrupades en cinc grups relacionats, són cinc problemes reals: un possible incident de seguretat, un desplegament amb permisos incomplets, un problema de capacitat amb un parany d'ordre, una finestra de manteniment amb impacte mesurable, i un sistema d'avisos que s'ha degradat en silenci. Aquesta diferència és exactament el que aporta que la revisió la faci una persona amb context i no un informe automàtic.

MercadoFresco té l'última peça. Saps què és Trusted Advisor i en què es diferencia de tot l'anterior: Config comprova les teves regles, Trusted Advisor comprova les d'AWS; Config respon preguntes, Trusted Advisor les fa. I saps que el cicle bo és encadenar-los: Trusted Advisor descobreix el que no havies previst, escrius una regla de Config perquè no torni, i la remediació ho corregeix sola. Enfront de Well-Architected (11-01), la distinció és d'altura: Trusted Advisor mira cap avall, als recursos; Well-Architected mira cap amunt, a les decisions.

Coneixes les cinc categories —optimització de costos, rendiment, seguretat, tolerància a errors i límits de servei— i què comprova cadascuna, amb els tres estats i l'advertiment que un groc és una hipòtesi, no una ordre: els volums arrel de les instàncies de l'ASG no necessiten instantànies, i acceptar formalment aquesta troballa amb la seva justificació és la resposta correcta.

Tens la taula honesta del que veu MercadoFresco amb el pla Basic: seguretat bàsica i límits de servei, que no és poc, i res de cost, rendiment, tolerància a errors ni API. I saps suplir el que falta amb el que ja has après: els volums orfes amb una consulta avançada de Config, les IP elàstiques amb describe-addresses, els balancejadors inactius amb RequestCount, les instàncies infrautilitzades amb Compute Optimizer, el Multi-AZ amb una regla de Config. Gairebé tot el que donaria el pla Business, gratis. El que no es pot reproduir és el suport tècnic amb SLA, i aquesta és la raó real per la qual es contracta.

Has recorregut un informe complet de l'arquitectura de MercadoFresco i has trobat el que feia mesos que hi era: 3 volums EBS orfes de les proves de 02-01, 2 IP elàstiques sense associar que es facturen precisament per no fer-se servir i que a més consumien 2 de les 5 places de la quota, mercadofresco-tienda-01 al 4 % de CPU des que vam muntar l'ASG i que ningú no va apagar, el mateix port 22 obert que ja havia assenyalat Config —dues eines independents confirmant-se—, i la troballa de compressió de CloudFront que s'arregla amb una casella.

I has descobert la quota que ningú no havia mirat: asg-mercadofresco-tienda no pot passar de quatre instàncies perquè la quota de vCPU del compte és 16 i altres càrregues en consumeixen 8. El màxim de l'ASG no era una decisió de disseny: era un límit invisible. Una fallada latent perfecta, que es manifestaria exactament en el pitjor moment —el divendres en què calgués escalar— i que no apareixeria en cap alarma de CloudWatch, cap regla de Config ni cap traça d'X-Ray. Saps gestionar Service Quotas: veure l'ús, sol·licitar augments amb antelació perquè els grans triguen dies, recordar que són per regió, comptar el desplegament blau/verd que duplica les instàncies, i sobretot alarmar al 70 % amb SERVICE_QUOTA(), la funció que fa que l'alarma es recalibri sola quan la quota canviï. Dues alarmes, 0,20 USD al mes, per no quedar-te sense escalar un divendres.

Coneixes l'API de Trusted Advisor (Business, i només a us-east-1, el mateix patró d'ACM i les Web ACL de CloudFront), l'exportació de recomanacions a CSV, les notificacions setmanals als contactes alternatius de 01-02, i la integració amb EventBridge (07-03) que permet no només notificar sinó actuar —desactivar automàticament una clau d'accés que ha aparegut en un repositori públic—. I saps on encaixen Compute Optimizer i Cost Optimization Hub, amb l'advertiment que resumeix la relació entre eines i persones: Compute Optimizer recomana reduir mercadofresco-tienda-01 a t3.small; la resposta correcta és apagar-la. Les eines optimitzen el que hi ha; la pregunta de si hi ha de ser la fa una persona.

I tens la rutina mensual de la Marta: una hora, el primer dilluns, amb la seva llista de comprovació de seguretat, cost, fiabilitat, observabilitat i deute tècnic. Amb el punt que més se salta i més importa: revisar les alarmes que van donar falsos positius i esborrar-les o recalibrar-les, perquè una alarma que s'ignora és pitjor que no tenir alarma.

Amb això es tanca el mòdul 5. La capa d'observabilitat de MercadoFresco està completa: mètriques i taulers amb mercadofresco-produccion, MercadoFresco/Tienda i tretze alarmes verificades amb simulacre; traces d'extrem a extrem amb mostreig al 100 % a les comandes i al 0 % a la comprovació d'estat; auditoria inalterable a trail-mercadofresco amb set anys de retenció i consultes SQL sobre cada crida a l'API; compliment continu amb 29 regles de Config i remediació automàtica que restaura el xifratge d'un bucket en vuit minuts; i el repàs automàtic que troba el que a ningú se li va acudir preguntar. Les cinc preguntes del mòdul 4 tenen resposta —l'avís arriba, els registres es correlacionen, la comanda de vuit segons era un N+1, la còpia la va desxifrar el Luis provant una restauració de matinada, i el xifratge es restaura sol— i per 62,47 USD al mes, el 9,9 % de la factura, amb cinc línies de configuració separant-la de més de 600.

I ara, amb la casa per fi vigilada, la vigilància comença a ensenyar una cosa incòmoda. El tauler de la Marta ho porta dient des que el vam muntar, i les dades d'aquest mòdul ho confirmen des de tres angles diferents: el següent coll d'ampolla és la base de dades.

mercadofresco-pedidos és una única instància de PostgreSQL que ho fa tot, i ho fa malament per raons diferents en cada cas. La cistella castiga una taula de sessions amb escriptures constants de dades que no tenen cap necessitat de ser transaccionals ni de viure per sempre. Els informes de la Sara, amb les seves agregacions sobre mesos d'història, bloquegen la producció quan els executa en hores de feina —i la rèplica de lectura només desplaça el problema, no el resol—. El catàleg es consulta milers de vegades per minut per retornar sempre el mateix: preus i descripcions que canvien un cop al dia. I el mateix X-Ray va ensenyar que fins i tot després de corregir l'N+1, la latència de la botiga continua dominada per consultes a la base de dades.

Tot això és en una sola instància perquè, quan vam començar a 02-04, PostgreSQL era la resposta òbvia. I ho era. Però una base de dades relacional no és l'eina correcta per a tots els treballs, i forçar-la a ser-ho és la causa més comuna d'arquitectures que no escalen.

Al mòdul 6, «Bases de dades», començant per 06-01, «Com triar la base de dades adequada», veurem el model de decisió: relacional enfront de clau-valor, documental, en memòria, de sèries temporals i de grafs, amb els criteris reals —patró d'accés, consistència, latència, volum i cost— per triar cadascuna. Després DynamoDB per a la taula de sessions i la cistella, Aurora com l'evolució natural de PostgreSQL quan cal més, Redshift perquè els informes de la Sara deixin de tocar producció, i ElastiCache perquè el catàleg se serveixi des de memòria en microsegons. I tot plegat amb l'avantatge que, per primera vegada al curs, cada canvi que fem es podrà mesurar: tenim les mètriques, les traces i els taulers per demostrar si una decisió d'arquitectura va ser bona o no.