Tanquem el mòdul amb la peça que falta. Fins ara, tot el que ha muntat MercadoFresco parteix de la mateixa idea: hi ha un servidor encès esperant feina. La instància EC2 de la botiga està encesa encara que sigui dimarts a les 4 de la matinada. La instància RDS també. I es paguen les 730 hores del mes.

Però hi ha tasques que no encaixen en aquest model. Generar la miniatura d'una foto quan el Luis la puja passa vint vegades al dia i dura dos segons. Consultar l'estat d'una comanda és una crida puntual. Processar un fitxer de rutes de repartiment passa un cop cada matí. Tenir un servidor encès 730 hores per a 40 minuts de feina mensual és absurd.

AWS Lambda executa codi només quan passa alguna cosa i només cobra mentre s'executa, amb precisió de mil·lisegons. En aquesta lliçó connectem per fi l'esdeveniment d'S3 que vam deixar configurat a 02-03 i escrivim la funció que genera les miniatures del catàleg de MercadoFresco.

1. Què és la computació sense servidor i en què es diferencia d'EC2
2. Model d'execució: gestor, esdeveniment, context i resposta
3. Arrencada en fred i arrencada en calent
4. Concurrència: reservada, provisionada i el límit del compte
5. Configuració: memòria, CPU, temps d'espera, variables i arquitectura
6. La funció de les miniatures: el codi
7. Empaquetatge amb dependències i capes
8. Desplegar per consola i per CLI
9. Permisos: el rol d'execució i el mínim privilegi
10. Registres a CloudWatch Logs i depuració
11. Orígens d'esdeveniments habituals
12. Segona funció: consultar l'estat d'una comanda per HTTP
13. Límits reals que cal conèixer
14. Preus, amb el càlcul concret de MercadoFresco
15. Errors, reintents i cues de missatges fallits
16. Recapitulació del mòdul: què hi ha ja a AWS i què falta

«Sense servidor» (serverless) no vol dir que no hi hagi servidors: vol dir que no són teus, no els veus i no els pagues quan no treballen. AWS aprovisiona la capacitat, l'escala i la retira, tot plegat invisible.

Els criteris de tria, en ordre d'utilitat pràctica:

1. La tasca dura menys de 15 minuts? Si no, Lambda queda descartada.
2. El trànsit és irregular o per esdeveniments? Lambda guanya de llarg. Si és sostingut i constant 24×7, un contenidor o una EC2 surten més barats.
3. Necessites control del sistema operatiu o estat en disc? Llavors EC2 o contenidors.
4. Quant temps del teu equip vols dedicar a infraestructura? Lambda és el mínim possible.

Per a MercadoFresco, la generació de miniatures compleix els quatre criteris de manera perfecta: segons de durada, disparada per esdeveniments esporàdics, sense estat, i sense res a administrar.

Una funció Lambda és una funció normal del teu llenguatge amb una signatura concreta:

El cicle de vida complet, que cal entendre bé perquè d'ell depenen el rendiment i el cost:

D'aquí surt l'optimització més rendible de Lambda, i és una línia de codi:

I d'aquí surt també el parany corresponent: l'entorn es reutilitza, així que les variables globals persisteixen entre invocacions. És útil per a memòries cau, però desastrós si acumules estat per descuit:

L'arrencada en fred és el temps que triga AWS a preparar un entorn nou: crear la microVM, descarregar el codi i les capes, inicialitzar l'intèrpret i executar el codi global.

Quan importa de debò: si la Lambda respon a una petició síncrona d'un usuari (una API), 1,5 segons extra són inacceptables. Si processa un esdeveniment asíncron (la miniatura d'una foto), a ningú no li importa.

Estratègies de mitigació, de menor a major cost:

1. Moure feina al codi global i mantenir el paquet petit. Gratis.
2. Triar un llenguatge lleuger. Python o Node per a funcions de latència crítica.
3. Pujar la memòria. Més CPU accelera la inicialització, i sovint el cost total no puja perquè l'execució dura menys.
4. Concurrència provisionada. AWS manté N entorns sempre llestos. Elimina l'arrencada en fred del tot, però es paga encara que no s'utilitzi.

Lambda no encua peticions: crea entorns nous. Si arriben 100 esdeveniments simultanis, s'executen 100 instàncies de la funció alhora. Aquest és el seu gran avantatge i també el seu risc.

La concurrència reservada té un doble efecte que convé entendre:

• Garanteix que aquella funció sempre podrà fer servir aquella quantitat, encara que d'altres estiguin saturant el compte.
• Limita aquella funció a aquest màxim. És un fre.

Aquest fre és exactament el que MercadoFresco necessita per protegir la base de dades:

Sense aquest límit, un pic de trànsit podria obrir centenars de connexions a mercadofresco-pedidos i tombar la base de dades. És un cas real i freqüent: Lambda escala, RDS no.

Aquest és el paràmetre que més gent configura malament. A Lambda només s'assigna memòria, de 128 MB a 10.240 MB, i la CPU s'assigna proporcionalment:

La conseqüència és contraintuïtiva i mereix un càlcul. Una funció que processa una imatge:

Més memòria pot sortir igual de barat o més barat, i vuit vegades més ràpid. Posar 128 MB «per estalviar» acostuma a ser un error: la funció triga tant que el cost no baixa i la latència es dispara. L'eina AWS Lambda Power Tuning automatitza aquesta anàlisi.

D'1 segon a 15 minuts (900 s), amb 3 segons per defecte. Regla: posa'l una mica per damunt del que la funció triga realment, mai al màxim. Un temps d'espera de 900 s en una funció que hauria de trigar 2 s vol dir que una penjada es pagarà durant 15 minuts.

Es xifren en repòs automàticament, però són visibles a la consola per a qualsevol amb permís de lectura. No hi posis mai contrasenyes: fes servir Secrets Manager o Parameter Store (lliçó 04-03), com vam fer amb RDS a 02-04.

Tria arm64 llevat que una dependència t'ho impedeixi. És un 20 % d'estalvi per canviar un paràmetre. L'única precaució és que les biblioteques amb codi natiu —com Pillow, que farem servir ara— s'han d'empaquetar per a l'arquitectura correcta.

Arribem a l'objectiu. A la lliçó 02-03 vam configurar la notificació del bucket mercadofresco-catalogo-fotos perquè cada .jpg pujat sota productos/ disparés la funció mercadofresco-generar-miniaturas. L'escriurem.

Els detalls del codi que marquen la diferència entre un exemple de tutorial i una cosa que aguanta en producció:

• unquote_plus sobre la clau. S3 codifica els noms a l'esdeveniment. Sense aquesta línia, qualsevol foto amb espais, accents o enyes donaria NoSuchKey. És l'errada número u de les Lambdes d'S3.
• event["Records"] és una llista. Un sol esdeveniment pot portar diversos registres. Processar-lo amb event["Records"][0] funciona a les proves i falla en producció.
• Prefix de sortida diferent del d'entrada, més la comprovació explícita. Doble protecció contra el bucle recursiu.
• raise als errors recuperables. Lambda reintenta automàticament les invocacions asíncrones; empassar-se l'excepció amb un return faria que l'errada passés desapercebuda.
• NoSuchKey es tracta a part. És un error no recuperable: reintentar-lo tres vegades és temps i diners perduts.
• Etiquetatge de l'objecte amb l'esquema del projecte, coherent amb el que anem fent.

Pillow no ve inclòs a l'entorn de Lambda: cal aportar-lo. Hi ha tres maneres i convé saber quan fer servir cadascuna.

Per a MercadoFresco, una capa amb Pillow és la tria correcta: la compartiran la funció de miniatures i les que vinguin després, i manté el paquet de codi petit (arrencades en fred més ràpides i edició possible a la consola).

L'estructura de directoris de la capa no és negociable: Python busca les biblioteques a /opt/python, i AWS descomprimeix la capa a /opt. Per això tot ha de penjar d'un directori anomenat exactament python/. Cada llenguatge té la seva ruta (nodejs/node_modules per a Node.js).

1. Consola → Lambda → regió Irlanda → Crear funció.
2. Crear des de zero. Nom: mercadofresco-generar-miniaturas. Temps d'execució: Python 3.12. Arquitectura: arm64.
3. Canviar el rol d'execució → crear-ne un de nou (l'ajustarem a l'apartat següent).
4. Enganxa el codi a l'editor o puja el ZIP.
5. Configuració → Configuració general: memòria 1.024 MB, temps d'espera 30 s.
6. Configuració → Variables d'entorn: les quatre que hem definit abans.
7. Capes → Afegir una capa → mercadofresco-imagen.
8. Disparadors → Afegir disparador → S3 → bucket mercadofresco-catalogo-fotos, esdeveniment Tots els esdeveniments de creació d'objectes, prefix productos/, sufix .jpg.
9. Etiquetes: l'esquema obligatori del projecte.

Actualitzar el codi després d'un canvi:

--publish crea una versió immutable numerada. Combinada amb àlies (produccion, pruebas), permet desplegaments graduals dirigint, per exemple, el 10 % del trànsit a la versió nova. És una altra peça contra el problema 4 de MercadoFresco, els desplegaments arriscats, que s'aborda de ple al mòdul 8.

Provar sense pujar res a S3:

--log-type Tail retorna els últims 4 KB del registre codificats en base64: la manera més ràpida de depurar sense sortir del terminal.

Avís de cost. El nivell gratuït de Lambda és permanent, no de 12 mesos: 1 milió de peticions i 400.000 GB-segon al mes, per sempre. Aquesta pràctica no et costarà res. Tot i així, esborra la funció en acabar si no hi continues: aws lambda delete-function --function-name mercadofresco-generar-miniaturas. I recorda eliminar també la notificació del bucket i la capa si no les fas servir.

Una funció Lambda no té credencials pròpies: assumeix un rol d'execució d'IAM, i els permisos d'aquest rol són exactament el que la funció pot fer. Ni més, ni menys.

La política de confiança, que defineix qui pot assumir el rol:

I la política de permisos, que defineix què pot fer. Aquí hi ha el principi de mínim privilegi aplicat amb rigor:

Quatre decisions deliberades, i cadascuna evita un problema real:

1. s3:GetObject només sota productos/. Si la funció es veu compromesa, no pot llegir els informes de vendes ni les còpies de la base de dades.
2. s3:PutObject només sota miniaturas/. Encara que hi hagués una errada lògica, la funció no pot sobreescriure les fotos originals. És l'última defensa contra el bucle recursiu: fins i tot si el filtre del bucket fallés, l'escriptor no té permís sobre el prefix d'entrada.
3. Sense s3:DeleteObject. La funció no necessita esborrar res, així que no pot.
4. Els registres acotats al seu propi grup de registres, no a *.

Comparat amb la pràctica habitual d'adjuntar AmazonS3FullAccess «perquè funcioni», la diferència entre un incident menor i una filtració completa és en aquestes tres instruccions. La lògica completa d'IAM, els rols, les polítiques i la seva avaluació és la lliçó 04-01.

Cada funció escriu automàticament en un grup de registres anomenat /aws/lambda/<nom-de-la-funció>. Tot el que imprimeixis amb print() o logger.info() acaba allà.

Al final de cada invocació, Lambda escriu una línia REPORT que és or pur per ajustar la configuració:

Com es llegeix:

En aquest cas la temptació és baixar la memòria a 256 MB. Compte: recorda que la CPU és proporcional. Amb 256 MB la funció trigaria uns 7 segons en lloc d'1,8, i el cost seria pràcticament el mateix amb quatre vegades més latència. La decisió correcta és provar 512 MB i mesurar.

Altres dues capacitats bàsiques de depuració:

• Mètriques automàtiques a CloudWatch: Invocations, Errors, Duration, Throttles, ConcurrentExecutions. Una alarma sobre Errors > 0 és el mínim exigible en producció.
• Registres estructurats en JSON: configurant el format de registre en JSON, els camps es poden consultar amb CloudWatch Logs Insights sense analitzar text.

El monitoratge a fons —taulers, alarmes, retenció, Logs Insights— és la lliçó 05-01, i el traçat distribuït d'una petició que travessa diverses funcions i serveis és 05-02.

Lambda s'integra amb més de 200 serveis. Aquests són els que importen en començar:

Les tres formes d'invocació tenen conseqüències molt diferents en el comportament davant d'errors:

La primera funció reaccionava a un esdeveniment intern. Ara exposarem una funció a internet perquè l'aplicació mòbil de MercadoFresco consulti l'estat d'una comanda.

Hi ha dues maneres de posar HTTP davant d'una Lambda:

Comencem amb Function URL per simplicitat, sabent que producció demanarà API Gateway.

Quatre decisions de disseny que mereixen atenció:

• La connexió a la base de dades viu a l'àmbit global i es reutilitza. Obrir una connexió a PostgreSQL costa desenes de mil·lisegons; fer-ho a cada invocació multiplicaria la latència i saturaria RDS.
• Concurrència reservada de 20 com a sostre de connexions. Sense això, un pic podria obrir centenars de connexions i tombar mercadofresco-pedidos. És la lliçó de 02-04 aplicada: Lambda escala, RDS no. (Per a casos exigents existeix RDS Proxy, que agrupa connexions; queda fora de l'abast d'aquesta lliçó.)
• Consulta parametritzada amb %s, mai concatenació de cadenes. Injecció SQL evitada.
• Els errors interns no es detallen al client: es registren a CloudWatch i es retorna un missatge genèric.

El límit dels 15 minuts és el que més decisions d'arquitectura condiciona. Si el procés nocturn que recomprimeix les 40.000 fotos del catàleg triga 3 hores, no és una feina per a una sola Lambda: o es reparteix en 40.000 invocacions de dos segons (que sí que encaixen perfectament), o s'executa en una tasca de contenidor. Repartir és gairebé sempre la resposta correcta amb Lambda.

Lambda cobra dos conceptes:

1. Peticions: 0,20 USD per milió.
2. Durada: 0,0000166667 USD per GB-segon (x86_64; arm64 és un 20 % menys).

I el nivell gratuït és permanent, no de 12 mesos: 1 milió de peticions i 400.000 GB-segon al mes, sempre.

Cas 1: la funció de miniatures. El Luis puja unes 20 fotos al dia (600 al mes), la funció fa servir 1.024 MB i triga 1,8 segons:

Cost zero. L'equivalent en una EC2 t3.micro encesa per fer el mateix serien uns 7,50 USD al mes. Aquest és exactament el cas d'ús per al qual existeix Lambda.

Cas 2: el punt d'enllaç d'estat de comandes, en l'escenari realista. MercadoFresco rep unes 900.000 consultes al mes, la funció fa servir 512 MB i triga 120 ms, en arm64:

Cas 3: creixement a tres ciutats més (problema 3). Deu vegades el trànsit: 9 milions de consultes al mes:

Menys de 4 dòlars al mes per servir 9 milions de peticions, sense cap servidor per administrar, apedaçar o vigilar. Quan la càrrega és irregular i per esdeveniments, el model sense servidor és difícilment batible.

El punt d'equilibri, per tenir-lo present: a partir d'una utilització sostinguda superior al 50-60 % d'un servidor, un contenidor o una EC2 reservada surten més barats. Lambda és cara si la fas servir com si fos un servidor sempre encès.

Què passa quan la funció falla depèn del mode d'invocació:

«L'esdeveniment es descarta» és la frase perillosa. Si la funció de miniatures falla tres vegades amb una foto concreta, aquella foto es queda sense miniatura i ningú no se n'assabenta. La protecció és una destinació d'error o una cua de missatges fallits (dead-letter queue, DLQ): un lloc on acaben els esdeveniments que no s'han pogut processar, per revisar-los i reprocessar-los.

Tres principis que cal respectar des del primer dia:

1. Idempotència. El lliurament és «almenys una vegada»: la mateixa foto es pot processar dues vegades. La nostra funció ho compleix perquè regenerar una miniatura sobre si mateixa dóna el mateix resultat. Si la funció incrementés un comptador o cobrés un pagament, caldria protegir-la explícitament.
2. Distingir errors recuperables dels que no ho són. Un temps d'espera de xarxa mereix reintent; un NoSuchKey no. Reintentar allò irrecuperable és temps i diners llençats.
3. Vigilar la DLQ. Una cua de fallits que ningú no mira és el mateix que no tenir-ne. Una alarma sobre ApproximateNumberOfMessagesVisible > 0 és obligatòria.

Aquí només deixem plantejat el concepte. SQS s'estudia a la lliçó 07-01, i els patrons complets d'idempotència, reintents i cues de missatges fallits són la lliçó 07-05.

Aquest és el punt del curs on convé aixecar la vista. MercadoFresco va començar el mòdul 2 amb un servidor físic a l'oficina; l'acaba amb això:

El que està resolt i el que no:

I el que encara no existeix, que és molt:

• Xarxa pròpia. Tot està a la VPC per defecte, amb les instàncies exposades. Falta dissenyar subxarxes públiques i privades, taules de rutes, i treure la base de dades a una subxarxa sense sortida a internet. Mòdul 3.
• Balancejador de càrrega. Les quatre instàncies de l'ASG no reben trànsit repartit, i no hi ha HTTPS ni domini propi. 03-03 i 03-05.
• Distribució de contingut. El 97 % de la factura d'S3 era transferència de sortida: CloudFront ho arregla. 03-04.
• Identitat i secrets amb rigor. Hem fet servir rols i Secrets Manager de passada; falta l'estructura completa d'IAM, el xifratge amb claus pròpies i la protecció davant d'atacs. Mòdul 4.
• Observabilitat. Tenim mètriques soltes i algun registre. Falta un sistema de taulers, alarmes, traces i auditoria de qui va fer què. Mòdul 5.
• Infraestructura com a codi. Tot ho hem creat a mà o amb comandes soltes: no és reproduïble ni revisable. Mòdul 9.

• Crear els clients de boto3 dins del gestor. Es paguen 100-300 ms a cada invocació. Sempre a l'àmbit global.
• No descodificar la clau d'S3 amb unquote_plus. Qualsevol foto amb espais o enyes fallarà amb NoSuchKey. És l'errada número u de les Lambdes disparades per S3.
• Processar només event["Records"][0]. Un esdeveniment pot portar diversos registres. Itera sempre.
• Escriure al mateix prefix que dispara la funció. Bucle infinit. Filtra per prefix i restringeix els permisos d'escriptura del rol, com a defensa doble.
• Assignar 128 MB «per estalviar». La CPU és proporcional a la memòria: la funció triga tant que el cost no baixa i la latència es dispara. Mesura amb Max Memory Used i prova diversos valors.
• Posar el temps d'espera a 900 s per defecte. Una penjada es pagarà durant 15 minuts.
• Desar estat en variables globals sense control. L'entorn es reutilitza i una llista global creix fins a esgotar la memòria.
• Donar AdministratorAccess al rol d'execució. Concedeix només les accions i els recursos exactes que la funció necessita.
• Oblidar lambda:add-permission per a l'origen de l'esdeveniment. El disparador no funciona i no apareix cap error visible enlloc.
• Obrir una connexió a RDS per invocació sense límit de concurrència. Un pic de trànsit tomba la base de dades. Connexió a l'àmbit global i concurrència reservada.
• No configurar destinació d'error ni DLQ en invocacions asíncrones. Els esdeveniments fallits es descarten en silenci.
• Retornar fitxers grans a la resposta. El límit síncron és de 6 MB. Desa a S3 i retorna una URL prefirmada.
• Consell: comença en arm64 llevat que una dependència ho impedeixi. És un 20 % d'estalvi per canviar un paràmetre.

Per a cada càrrega de MercadoFresco, decideix entre Lambda, EC2/contenidor o una combinació, i justifica-ho amb els criteris de la lliçó:

• A) La botiga web PHP, que atén trànsit de manera contínua amb un pic els divendres.
• B) Generar el PDF de la factura quan una comanda es marca com a lliurada (unes 900 al dia, 1,5 s cadascuna).
• C) Recomprimir les 40.000 fotos del catàleg, un procés que avui triga 3 hores seguides.
• D) Una feina que cada nit a les 3:00 exporta les comandes del dia a S3; triga 90 segons.
• E) Un servei de recomanació que carrega un model de 4 GB a memòria i respon en menys de 50 ms.

La funció de miniatures està configurada amb 1.024 MB i triga 1.800 ms. Les proves amb AWS Lambda Power Tuning donen aquests resultats:

MercadoFresco creix i ara es processen 200.000 fotos al mes (ja fora del nivell gratuït de durada). Calcula el cost de durada de cada configuració en arm64 (0,0000133334 USD per GB-segon) i decideix quina triaries, tenint en compte també la latència.

MercadoFresco afegeix una tercera funció, mercadofresco-exportar-pedidos, que cada nit:

1. Llegeix les comandes del dia de la rèplica de lectura de RDS.
2. Obté les credencials de la base de dades de Secrets Manager.
3. Escriu un fitxer CSV a s3://mercadofresco-informes-analitica/informes/AAAA/MM/.
4. Envia una notificació a un tema d'SNS quan acaba.
5. Escriu els seus registres a CloudWatch Logs.

Escriu la política de permisos del rol d'execució aplicant el mínim privilegi, i explica dos permisos que deliberadament no hi inclous encara que podrien semblar necessaris.

Solució 1.

Solució 2.

Cost de durada en arm64, per a 200.000 invocacions:

Resultat revelador: les tres primeres configuracions costen exactament el mateix, zero, perquè totes caben al nivell gratuït de 400.000 GB-segon. La decisió, per tant, no és econòmica sinó de latència i de marge.

Tria: 1.769 MB. Raons:

• És la més ràpida de les tres gratuïtes: 1,15 s davant de 3,4 s, gairebé tres vegades millor.
• 1.769 MB correspon a un vCPU complet, el punt on Pillow deixa d'estar limitat per CPU.
• Es queda en 397.900 GB-segon, molt just respecte al límit. Si el volum creix, començarà a costar: a 300.000 fotos serien 596.850 GB-segon, és a dir 2,62 USD al mes. Continua sent irrellevant.
• 3.008 MB es descarta: només millora 100 ms sobre 1.769 MB (la funció ja no està limitada per CPU) i multiplica el consum de GB-segon, sortint-se del nivell gratuït.

La lliçó general: per damunt d'un vCPU, continuar pujant memòria deixa d'accelerar i comença a costar. El punt òptim acostuma a ser a prop de 1.769 MB per a feines d'un sol fil.

Solució 3.

Dos permisos que deliberadament NO s'inclouen:

1. s3:GetObject i s3:DeleteObject sobre el bucket d'informes. La funció només escriu: no necessita llegir ni esborrar res. Excloure'ls significa que, si la funció es veiés compromesa per una dependència maliciosa, no podria exfiltrar els informes històrics de vendes ni destruir-los. És el mateix raonament que vam aplicar a la funció de miniatures.

2. Qualsevol permís de rds:*. Resulta contraintuïtiu, perquè la funció consulta la base de dades, però connectar-se a PostgreSQL amb usuari i contrasenya no passa per IAM: és una connexió TCP autenticada pel motor mateix. Els permisos rds:* serveixen per administrar instàncies (crear-les, esborrar-les, modificar-les), i la funció no ha de poder fer res d'això. Concedir-los seria donar permís per esborrar la base de dades a un procés que només necessita llegir una taula. (L'excepció seria l'autenticació IAM de RDS, que sí que requereix rds-db:connect sobre un recurs d'usuari concret.)

Detalls addicionals del disseny: l'ARN del secret porta un comodí final perquè Secrets Manager afegeix un sufix aleatori de sis caràcters al nom; i els permisos d'ec2:*NetworkInterface són obligatoris i amb Resource: "*" quan la funció es connecta a recursos dins d'una VPC —és una de les poquíssimes excepcions legítimes al mínim privilegi, imposada pel servei mateix.

Amb aquesta lliçó MercadoFresco tanca el seu primer mòdul de serveis reals. Saps què és la computació sense servidor i, més important, quan no fer-la servir: has comparat Lambda amb EC2 i amb contenidors en una taula de criteris i has aplicat la regla que per damunt del 50-60 % d'utilització sostinguda el model deixa de compensar. Domines el model d'execució —gestor, esdeveniment, context, resposta— i el cicle de vida de l'entorn, del qual es deriva l'optimització més rendible que existeix a Lambda: crear els clients de boto3 a l'àmbit global, fora del gestor, perquè l'entorn es reutilitza. Coneixes l'arrencada en fred, què l'allarga i les quatre maneres de mitigar-la, i saps que la concurrència reservada és alhora una garantia i un fre, el fre que protegeix RDS de la capacitat de Lambda d'escalar sense límit.

Has entès la relació memòria-CPU-cost, que és el paràmetre que més gent configura malament, i l'has calculat amb números: assignar 128 MB «per estalviar» acostuma a sortir igual de car i vuit vegades més lent. Saps triar arm64 per un 20 % d'estalvi, posar un temps d'espera ajustat i no desar contrasenyes a variables d'entorn.

I has escrit la funció que tanca el cercle obert a la lliçó 02-03: mercadofresco-generar-miniaturas es dispara amb l'esdeveniment s3:ObjectCreated del bucket mercadofresco-catalogo-fotos, descodifica correctament la clau amb unquote_plus, itera sobre tots els registres de l'esdeveniment, escriu en un prefix diferent del d'entrada per no crear un bucle infinit, distingeix els errors recuperables dels que no ho són i etiqueta el que produeix. L'has empaquetada amb Pillow en una capa compilada per a la plataforma correcta, l'has desplegada per consola i per CLI amb create-function i update-function-code --publish, i li has donat un rol d'execució de mínim privilegi que només pot llegir sota productos/, només pot escriure sota miniaturas/ i no pot esborrar res. Has afegit una segona funció, mercadofresco-estado-pedido, exposada per Function URL, amb la connexió a RDS reutilitzada entre invocacions, consultes parametritzades, concurrència limitada a 20 i errors que no filtren informació al client. Saps llegir la línia REPORT de CloudWatch Logs per ajustar la memòria, has recorregut els orígens d'esdeveniments habituals assenyalant on s'estudia cadascun, coneixes els límits reals —15 minuts, 250 MB, 512 MB a /tmp, 6 MB de payload síncron— i has fet el càlcul de preus que demostra que servir 9 milions de peticions costa menys de 4 dòlars al mes. Finalment, saps què passa quan una funció falla en cada mode d'invocació i per què una cua de missatges fallits sense vigilància és el mateix que no tenir-ne.

Recapitulant el mòdul sencer: MercadoFresco té ja a eu-west-1 un grup d'Auto Scaling de la botiga repartit en dues zones de disponibilitat, discs EBS amb còpies automàtiques gestionades per Data Lifecycle Manager, el catàleg de fotos a S3 amb versionatge i regles de cicle de vida, la base de dades de comandes a RDS PostgreSQL amb Multi-AZ, rèplica de lectura i restauració a un punt en el temps, i dues funcions Lambda que reaccionen a esdeveniments i responen per HTTP. El problema 2, les còpies de seguretat no fiables, està resolt de cap a peus. Els altres tres estan encaminats però incomplets.

I el que falta és, precisament, el que sosté tota la resta. Tot això viu a la VPC per defecte: les instàncies estan exposades on no haurien d'estar-ho, la base de dades comparteix espai de xarxa amb la botiga, no hi ha res que reparteixi el trànsit entre les quatre instàncies del divendres, no hi ha HTTPS ni domini propi, i el 97 % de la factura d'S3 continua sent transferència de sortida sense memòria cau. Al mòdul 3, «Xarxes i lliurament de contingut», començant per la lliçó 03-01 «Amazon VPC», construirem la xarxa pròpia de MercadoFresco: subxarxes públiques i privades en dues zones de disponibilitat, taules de rutes, passarel·les i una base de dades que deixa de ser abastable des d'internet. Sobre aquesta xarxa muntarem després els grups de seguretat, el balancejador que completa la solució al pic dels divendres, CloudFront per abaratir i accelerar les fotos, i Route 53 perquè mercadofresco.example apunti per fi al núvol.