A la lliçó 02-01 vam dimensionar el grup d'Auto Scaling asg-mercadofresco-tienda per al pic dels divendres: mínim 2, desitjat 2, màxim 4, amb la política cpu-objetivo-60 i l'acció programada pico-viernes-tarde. Els números sortien: el pic dels divendres de 17:00 a 21:00 són 900 comandes per hora, cada instància aguanta 600 comandes per hora, i amb dues instàncies hi ha capacitat de sobres. A 03-01 i 03-02 els hem donat una xarxa pròpia i un tallafocs que les protegeix.

I tanmateix, MercadoFresco continua caient els divendres. Perquè l'ASG pot llançar quatre instàncies, però ningú no envia trànsit a les tres últimes. El domini apunta a una IP concreta, la de la primera màquina, i les altres es queden enceses i ocioses mentre aquella s'ofega. Falta la peça central: alguna cosa que rebi tot el trànsit i el reparteixi.

Això és un balancejador de càrrega. En aquesta lliçó la Marta munta alb-mercadofresco-tienda, el connecta al grup d'Auto Scaling i acaba de resoldre el problema 1 del curs: les caigudes dels divendres. Pel camí apareixen les comprovacions d'estat, que són la part que més aplicacions ha tombat per estar mal configurada.

1. Per què cal un balancejador
2. Els tipus de balancejador: ALB, NLB, GWLB i el CLB heretat
3. Anatomia d'un ALB: oients, regles i grups de destinació
4. Comprovacions d'estat: la part perillosa
5. Integració amb el grup d'Auto Scaling
6. Drenatge de connexions i desplegaments sense talls
7. Encaminament avançat per ruta i per host
8. Redireccions i respostes fixes
9. HTTPS al balancejador: ACM, polítiques TLS i SNI
10. Sessions enganxoses i per què és millor no necessitar-les
11. Registres d'accés i mètriques
12. Creació completa per CLI
13. Cost de l'ALB i neteja
14. El trànsit del divendres, d'extrem a extrem

Un balancejador de càrrega és un servei gestionat que es col·loca davant d'un conjunt de servidors, rep totes les peticions i les distribueix entre ells. El que aporta va bastant més enllà del repartiment:

• Una única porta d'entrada. El domini mercadofresco.example apunta al balancejador, no a cap instància. Les instàncies poden crear-se, morir o canviar d'IP sense que ningú se n'assabenti.
• Comprovacions d'estat. El balancejador pregunta periòdicament a cada instància si està bé, i deixa d'enviar-li trànsit si no respon. Una fallada deixa de ser una caiguda.
• Alta disponibilitat entre zones. En ser a les dues subxarxes públiques, si eu-west-1a cau sencera, el trànsit continua entrant per eu-west-1b.
• Terminació TLS. El certificat viu al balancejador, no a cada instància. Un sol lloc per renovar.
• Escalat elàstic real. L'ASG registra les instàncies noves automàticament, així que la capacitat afegida a les 17:00 del divendres comença a rebre trànsit sola.
• Aïllament. Les instàncies passen a subxarxes privades sense IP pública: només el balancejador hi parla.

Sense balancejador, cadascun d'aquests sis punts s'ha de resoldre a mà, i cap no es resol bé.

AWS ofereix tres balancejadors moderns i un d'heretat. Triar malament no trenca res, però costa diners o funcionalitat.

L'elecció de MercadoFresco és l'ALB, i les raons són concretes:

1. El trànsit és HTTP/HTTPS. És exactament per al que existeix l'ALB.
2. Caldrà encaminar per ruta: /api/* cap al servei de comandes i la resta cap a la botiga. Un NLB no pot fer-ho perquè no llegeix la petició HTTP.
3. Es necessita redirecció automàtica d'HTTP a HTTPS, que l'ALB fa de forma nativa.
4. Els mil·lisegons de latència addicional són irrellevants per a una botiga; per a un videojoc en temps real no ho serien, i llavors la resposta seria NLB.

Sobre el CLB: és la primera generació, continua existint per compatibilitat i no s'ha de fer servir en res nou. Si te'n trobes un, la migració a ALB és gairebé sempre directa.

Un patró que convé conèixer encara que no el fem servir: NLB davant d'ALB. Serveix per obtenir una IP fixa (per exemple, perquè un proveïdor de pagaments exigeix una llista blanca d'IP) mantenint l' encaminament per ruta de l'ALB.

Un ALB té quatre peces i cal tenir-les clares perquè la CLI les crea una a una:

Dos conceptes que la gent confon:

• El grup de destinació té el seu propi protocol i port, independents de l'oient. L' oient pot rebre HTTPS al 443 i reenviar a les instàncies en HTTP pel 8080. Això és la terminació TLS.
• La comprovació d'estat es defineix al grup de destinació, no al balancejador. Un mateix balancejador pot tenir grups amb comprovacions molt diferents.

Els tipus de destinació disponibles:

I els algorismes de repartiment d'un grup de destinació:

Per a MercadoFresco, least_outstanding_requests: no dura el mateix carregar la portada que confirmar una comanda amb passarel·la de pagament.

El balancejador envia periòdicament una petició a cada destinació registrada. Si respon bé un nombre de vegades seguides, la marca sana (healthy) i li envia trànsit. Si falla, la marca no sana (unhealthy) i deixa d'enviar-n'hi.

Paràmetres i valors recomanats per a MercadoFresco:

Amb aquests valors, una instància caiguda triga com a màxim 3 × 15 = 45 segons a deixar de rebre trànsit.

Aquesta és la seqüència exacta, i val la pena detallar-la perquè hi ha un efecte en cadena que sorprèn:

1. L'ALB deixa d'enviar-li peticions noves. Les que ja estaven en curs es completen.
2. La instància continua encesa i continua costant diners. L'ALB no l'apaga.
3. La mètrica HealthyHostCount del grup de destinació baixa en un.
4. Tot el trànsit es reparteix entre les instàncies restants. Si n'eren dues i en queda una, aquella rep el doble.
5. Si l'ASG té la comprovació d'estat del balancejador activada (--health-check-type ELB), l'ASG acaba la instància i en llança una de nova.

El pas 4 és el perill. Imagina't un /salud que consulta la base de dades. Si la base de dades es posa lenta un moment, totes les instàncies fallen la comprovació alhora, l'ALB les marca totes com a no sanes i respon 503 Service Unavailable a tots els clients. L'aplicació funcionava; el health check l'ha tombada.

Encara pitjor amb l'ASG en mode ELB: l'ASG acaba totes les instàncies i en llança de noves, que també fallen perquè la base de dades continua lenta, i entra en un bucle de reemplaçament perpetu.

La regla: la comprovació d'estat ha de verificar que AQUESTA instància pot servir trànsit, no que tot el sistema funciona.

La diferència entre els dos punts d'enllaç és tota la lliçó:

• /salud respon en microsegons, no depèn de res extern i només pot fallar si aquesta instància està trencada. Si falla, retirar-la és sempre la decisió correcta.
• /salud/profunda sí que comprova dependències, però la seva fallada ha de generar una alarma perquè algú ho miri, no la retirada automàtica de servidors sans.

El 503 durant l'arrencada és igualment important: fa que l'ALB no enviï trànsit a una instància que encara està descarregant l'aplicació al user-data-tienda.sh.

Connectar asg-mercadofresco-tienda amb el grup de destinació es fa amb una sola comanda, i a partir d'aquí tot és automàtic:

El que passa a partir d'aquell moment:

El segon canvi important és el tipus de comprovació d'estat de l'ASG:

El --health-check-grace-period 300 és tan important com el tipus: són els segons que l'ASG espera des que la instància arrenca abans de fer cas al balancejador. El user-data-tienda.sh de MercadoFresco triga uns dos minuts a instal·lar i arrencar l'aplicació; sense marge de gràcia, l'ASG mataria la instància just abans que acabés d'arrencar, i ho faria en bucle. Cinc minuts donen prou folgança.

Quan una instància es dona de baixa, l'ALB no talla les connexions obertes de cop: la posa en estat draining. Durant el retard de baixa de registre (deregistration_delay.timeout_seconds, 300 segons per defecte) no rep peticions noves, però acaba les que tenia en curs.

Com triar el valor: el temps de la petició més llarga que serveix la teva aplicació, més un marge.

Els 60 segons de MercadoFresco cobreixen el pitjor cas: un client que ha premut «confirmar comanda» i està esperant la resposta de la passarel·la. Amb el valor per defecte de 300 s, reduir capacitat després del pic del divendres trigaria cinc minuts de més pagant instàncies ocioses; amb 5 s, es tallaria un pagament a mitges.

Aquí és on l'ALB es guanya el nom: llegeix la petició HTTP i decideix en funció del seu contingut. MercadoFresco necessita tres destinacions diferents sota el mateix balancejador.

Les condicions disponibles i un exemple de cadascuna:

Regles d'avaluació que cal conèixer:

• Les regles s'avaluen per prioritat ascendent i s'aplica la primera que coincideix. Deixa buits entre prioritats (10, 20, 30) per poder inserir-ne.
• Si no en coincideix cap, s'aplica l'acció per defecte de l'oient.
• Els patrons de ruta distingeixen majúscules i minúscules i admeten * i ?.
• Una regla pot combinar fins a 5 condicions, i totes s'han de complir (AND).
• Un ALB admet fins a 100 regles per oient.

A més de reenviar, un oient pot respondre per si mateix, sense tocar cap instància.

Redirecció d'HTTP a HTTPS, la configuració estàndard de l'oient del port 80:

Els marcadors #{host}, #{path} i #{query} conserven el que va demanar el client: qui entri a http://mercadofresco.example/producto/tomate?origen=email acaba a la mateixa pàgina per HTTPS. Un 301 és permanent i el navegador el desa a la memòria cau, amb la qual cosa la segona visita ja no passa pel port 80. Si estiguessis provant i no volguessis que es desés a la memòria cau, faries servir HTTP_302.

Resposta fixa, útil per bloquejar rutes o donar manteniment:

Aquella regla, amb prioritat 5 (la més alta), talla al balancejador els intents automatitzats de llegir fitxers de configuració. No arriben ni a tocar una instància. És un filtratge tosc: el filtratge seriós de peticions malicioses és AWS WAF, a 04-05.

MercadoFresco encara serveix per HTTP. Posar-li HTTPS amb AWS és gratis i són dos passos.

AWS Certificate Manager (ACM) emet certificats TLS públics sense cost i els renova automàticament mentre estiguin associats a un recurs d'AWS. Això elimina de cop el problema clàssic del certificat que caduca un diumenge.

Dos detalls:

• El comodí *.mercadofresco.example cobreix www, admin, api i qualsevol subdomini futur amb un sol certificat.
• La regió importa: per a un ALB, el certificat ha d'estar a la mateixa regió que l'ALB (eu-west-1). Per a CloudFront ha d'estar a us-east-1, un parany que veurem a 03-04.

El certificat queda en estat PENDING_VALIDATION fins que es demostri que el domini és teu creant un registre CNAME que ACM indica. Aquesta validació per DNS es completa a la lliçó 03-05, quan tinguem la zona allotjada de Route 53. Fins llavors, per practicar pots crear l' oient HTTPS amb un certificat autosignat importat, o treballar només amb el port 80.

L'oient HTTPS, un cop emès el certificat:

Les polítiques de seguretat TLS defineixen quines versions i xifratges s'accepten:

Terminació TLS significa que l'ALB desxifra el trànsit i decideix què fer amb la petició ja en clar. És l'única manera d'encaminar per ruta o per capçalera: per llegir /api/* cal poder llegir la petició. De l'ALB a les instàncies, el trànsit pot anar en clar (més ràpid, i viatja per la xarxa privada d'AWS dins de la teva VPC) o tornar-se a xifrar. MercadoFresco el torna a xifrar: el grup de destinació fa servir HTTPS al 443, perquè la política interna exigeix xifratge extrem a extrem encara que el tram sigui privat.

SNI (Server Name Indication) permet allotjar diversos certificats en un mateix oient: el client indica quin domini vol a la salutació TLS i l'ALB presenta el certificat adequat. Així, un únic ALB pot servir mercadofresco.example i, en el futur, mercadofresco.pt amb certificats diferents, sense balancejadors addicionals.

Les sessions enganxoses (stickiness) fan que un mateix client vagi sempre a la mateixa instància. L'ALB insereix una galeta (AWSALB, o una de pròpia de l'aplicació) i la fa servir per dirigir les peticions següents.

Serveix quan l'aplicació guarda l'estat de la sessió a la memòria del servidor: la cistella de la compra, per exemple. I porta quatre problemes seriosos:

Per això MercadoFresco té stickiness.enabled=false i l'aplicació és sense estat (stateless): la sessió es guarda fora de la instància. Les opcions:

MercadoFresco acabarà fent servir ElastiCache. Mentrestant, les sessions enganxoses són un pedaç acceptable si es documenta com a deute tècnic; el que no és acceptable és activar-les i oblidar per què.

Registres d'accés. L'ALB pot abocar a S3 una línia per petició, amb la IP del client, la ruta, el codi de resposta, els temps de processament i la destinació que la va atendre. Estan desactivats per defecte.

El bucket mercadofresco-registros-web necessita una política que autoritzi el servei a escriure-hi; sense ella la comanda sembla funcionar però no apareix cap fitxer. Un avís de cost discret: en una botiga amb trànsit, aquests registres creixen de pressa. Aplica la regla de cicle de vida que vam veure a 02-03 per moure'ls a Glacier als 30 dies.

Mètriques clau de l'ALB a CloudWatch:

La distinció entre HTTPCode_Target_5XX_Count i HTTPCode_ELB_5XX_Count és la més útil del quadre: el primer significa «l'aplicació va retornar un error», el segon «no hi havia a qui preguntar». La creació d'alarmes i taulers sobre aquestes mètriques s'estudia a 05-01; aquí n'hi ha prou de saber què mirar.

Partim de les variables de 03-01 i 03-02 ($VPC_ID, $PUB_A, $PUB_B, $SG_ALB, $SG_TIENDA).

L'última comanda retorna una cosa com alb-mercadofresco-tienda-1234567890.eu-west-1.elb.amazonaws.com. Aquell nom és la nova porta d' entrada de MercadoFresco. Que mercadofresco.example hi apunti és exactament la feina de la lliçó 03-05.

Comprovació de l'estat de les destinacions, la comanda que més es fa servir cada dia:

Els motius que més apareixen i què signifiquen de debò:

Target.Timeout és gairebé sempre el mateix: el grup sg-mercadofresco-tienda no accepta el 443 des de sg-mercadofresco-alb. Si vas seguir la lliçó 03-02, ja està resolt.

⚠️ Avís de cost: l'ALB cobra per hora encara que no rebi ni una petició

A eu-west-1 el preu té dos components:

• Hora de balancejador: ≈ 0,027 USD/h → ≈ 20 USD al mes només per existir.
• LCU (Load Balancer Capacity Unit): ≈ 0,008 USD/LCU-hora.

Una LCU és el màxim de quatre dimensions mesurades per hora: 25 connexions noves per segon, 3.000 connexions actives per segon, 1 GB/hora processat, o 1.000 avaluacions de regla per segon. Es factura només la dimensió més alta, no la suma.

Estimació per a MercadoFresco: unes 2 LCU de mitjana → 2 × 0,008 × 730 ≈ 12 USD/mes. Total, uns 32 USD al mes. Comparat amb els 70 USD dels dos NAT Gateway de 03-01, és barat per al que aporta, però no és a la capa gratuïta.

Per practicar: munta l'ALB, verifica que reparteix i esborra'l el mateix dia. Un ALB oblidat costa 20 USD al mes indefinidament i farà saltar el pressupost de 10 USD que vam configurar a 01-02 cap a [email protected].

Neteja, en ordre:

El certificat d'ACM no costa res, així que es pot deixar.

I els comptes del divendres, ara complets:

La penúltima fila és la que justifica tota la feina de les tres lliçons: perdre una zona de disponibilitat completa en ple pic del divendres ja no tomba MercadoFresco. El problema 1 queda resolt.

Posar el balancejador en una sola subxarxa. AWS l'exigeix en dues AZ com a mínim, però si registres instàncies només en una, perds tota la redundància sense cap avís.

Fer servir / com a ruta de comprovació d'estat. La portada consulta la base de dades, carrega el catàleg i triga centenars de mil·lisegons. Si la base de dades s'alenteix, totes les instàncies fallen alhora i l'ALB retorna 503 amb l'aplicació sana. Fes servir un /salud local i trivial.

Posar un marge de gràcia massa curt a l'ASG. Amb --health-check-grace-period 60 i un arrencada de dos minuts, l'ASG mata cada instància just abans que acabi d'arrencar, en bucle, gastant diners sense servir res.

Deixar el retard de baixa de registre en 300 segons. Reduir capacitat després del pic triga cinc minuts de més. Ajusta'l a la durada de la teva petició més llarga.

Activar sessions enganxoses per «arreglar» un problema de sessió. Funciona avui i trenca l' escalat demà. És deute tècnic: documenta'l i planifica treure la sessió de la instància.

Oblidar la política del bucket de registres. La comanda d'activació no dona error, però no apareix cap fitxer a mercadofresco-registros-web.

Confondre HTTPCode_ELB_5XX_Count amb HTTPCode_Target_5XX_Count. El primer significa que no hi ha destinacions sanes; el segon, que l'aplicació retorna errors. Són incidències diferents i s' arreglen en llocs diferents.

Demanar el certificat d'ACM a la regió equivocada. Per a un ALB, a la regió de l'ALB. Per a CloudFront, sempre a us-east-1. Ho veurem a 03-04.

Deixar un ALB de proves encès. 20 USD al mes per un recurs que no fa servir ningú. Revisa describe-load-balancers a totes les regions on hagis practicat.

Consell d'or: abans de connectar l'ASG, registra una instància a mà al grup de destinació i comprova que passa a healthy. Si no ho fa, el problema és el grup de seguretat o el health check, i és molt més fàcil de diagnosticar amb una sola instància que amb quatre.

La Marta desplega l'ALB i en obrir el seu nom DNS rep 503 Service Unavailable. A describe-target-health les dues instàncies apareixen com a unhealthy amb motiu Target.Timeout. Enumera almenys cinc causes possibles, ordenades de més a menys probable, i la comanda concreta que confirma o descarta cadascuna.

MercadoFresco necessita, sota un únic ALB: la botiga a l'arrel; l'API a /api/* amb un grup de destinació propi; el tauler a admin.mercadofresco.example accessible només des de la IP de l'oficina 81.45.20.7; un 410 Gone per a la ruta antiga /tienda-antigua/*; i redirecció de tot el trànsit HTTP a HTTPS. Escriu les regles amb les seves prioritats i justifica'n l'ordre.

Amb les dades de MercadoFresco (2 instàncies en horari normal, 4 els divendres de 17:00 a 21:00, 900 comandes/hora al pic, 600 comandes/hora per instància), calcula: el cost mensual de l'ALB suposant 3 LCU de mitjana, quantes instàncies caldrien si el negoci creixés fins a 3.000 comandes/hora, i si l'ASG actual ho suportaria.

Solució 1

Causes, de més a menys probable:

1. El grup de seguretat de les instàncies no accepta trànsit del balancejador. És la causa número u de Target.Timeout.

Hi ha d'aparèixer el port 443 amb $SG_ALB a UserIdGroupPairs.

2. L'aplicació no escolta al port del grup de destinació. El grup apunta al 443 però l' aplicació escolta al 8080.

3. La ruta /salud no existeix. Donaria Target.ResponseCodeMismatch amb un 404, però si el servidor no respon en absolut a aquella ruta, es manifesta com a Target.Timeout.

4. Les instàncies són en subxarxes sense ruta i l'ALB no hi arriba. Comprovar que les subxarxes de l'ASG són a la mateixa VPC que el balancejador i que les AZ de l'ALB inclouen les de les instàncies.

5. Una NACL bloqueja el trànsit de tornada. Falta el rang de ports efímers a la sortida de la subxarxa d'aplicació (lliçó 03-02). Es confirma als Flow Logs amb ACCEPT d'entrada i REJECT de sortida.

6. Menys probable però real: el marge de gràcia de l'ASG és curt i les instàncies s'estan reemplaçant abans d'arrencar; es veu a describe-scaling-activities amb reemplaçaments continus.

Solució 2

Justificació de l'ordre: la clau és al parell 10/20. Les regles s'avaluen per prioritat ascendent i guanya la primera que coincideix; si la 20 tingués prioritat menor, capturaria també el trànsit legítim de l'oficina i el tauler seria inaccessible per a tothom. La condició de la regla 10 combina dos camps amb AND, que és com funcionen les condicions múltiples d'un ALB.

L'oient del 80 es queda amb la redirecció 301 com a acció per defecte, sense regles: així tot el trànsit HTTP, inclòs el del tauler, acaba en HTTPS.

Matís honest: filtrar per source-ip a l'ALB funciona, però si demà es posa CloudFront al davant (lliçó 03-04), l'ALB veurà la IP de CloudFront i no la del client. Llavors caldria filtrar a WAF (04-05) o per la capçalera X-Forwarded-For.

Solució 3

Cost mensual de l'ALB:

• Hores: 0,027 USD/h × 730 h = 19,71 USD
• LCU: 3 LCU × 0,008 USD × 730 h = 17,52 USD
• Total ≈ 37,23 USD/mes

Comparat amb la infraestructura de xarxa completa: ALB ≈ 37 USD + 2 NAT Gateway ≈ 70 USD = 107 USD al mes només en xarxa, sense comptar instàncies ni base de dades. És l'argument per revisar a 11-03 si els dos NAT compensen.

Instàncies necessàries per a 3.000 comandes/hora:

• Capacitat estricta: 3.000 ÷ 600 = 5 instàncies.
• Però cal sobreviure a la caiguda d'una zona de disponibilitat completa. Amb instàncies repartides en 2 AZ, perdre'n una deixa la meitat. Perquè la meitat supervivent aguanti 3.000 com/h calen 10 instàncies, 5 per AZ.
• Un compromís raonable, acceptant degradació en el pitjor cas: 8 instàncies (4 per AZ). Amb una AZ caiguda queden 4 × 600 = 2.400 com/h, un 80 % de la demanda: la botiga va lenta però no cau.

Ho suportaria l'ASG actual? No. asg-mercadofresco-tienda té màxim 4, és a dir, 2.400 comandes/hora. Amb 3.000 de demanda es quedaria curt en un 20 % fins i tot sense fallades. Els canvis necessaris:

I abans de donar el canvi per bo, cal comprovar tres coses més: que RDS aguanta 10 instàncies obrint connexions (o cal un pool, o Aurora, que es veu a 06-03), que les subxarxes tenen IP lliures (amb /20 en sobren) i que la quota d'instàncies del compte ho permet. Escalar la capa web és la part fàcil; el coll d'ampolla es trasllada a la base de dades.

MercadoFresco té per fi una porta d'entrada única. Saps per què cal un balancejador més enllà del repartiment: comprovacions d'estat, alta disponibilitat entre zones, terminació TLS en un sol lloc i la possibilitat que les instàncies visquin en subxarxes privades sense IP pública. Distingeixes els quatre tipus —ALB per a HTTP i HTTPS amb encaminament per contingut, NLB per a capa 4, latència de microsegons i IP fixa, GWLB per a aplicacions virtuals de seguretat, i el CLB que només s'hereta— i saps justificar per què MercadoFresco necessita un ALB.

Coneixes la seva anatomia —balancejador, oients, regles i grups de destinació— i el detall que la comprovació d'estat viu al grup de destinació, no al balancejador. I sobretot has entès la part perillosa: un health check que consulta la base de dades pot marcar totes les instàncies com a no sanes alhora i retornar 503 amb l'aplicació perfectament sana, o ficar l'ASG en un bucle de reemplaçament. Per això /salud és local i trivial, /salud/profunda és per a la monitorització, i el marge de gràcia de l'ASG és de 300 segons.

Has connectat asg-mercadofresco-tienda al grup tg-mercadofresco-tienda perquè el registre i la baixa siguin automàtics, has canviat la comprovació de l'ASG a ELB perquè detecti aplicacions mortes i no només màquines mortes, i has ajustat el drenatge de connexions a 60 segons, el temps de la comanda més llarga. Saps encaminar per ruta i per host, combinar condicions, fer servir respostes fixes per tallar peticions malicioses al balancejador i redirigir HTTP a HTTPS amb un 301 que conserva la ruta. Has demanat un certificat gratuït a ACM amb comodí, has triat la política TLS 1.2/1.3 i entens què és la terminació TLS i per a què serveix SNI —sabent que la validació per DNS queda pendent de la propera lliçó. Saps per què les sessions enganxoses són un pedaç que trenca l'escalat i on ha de viure la sessió de debò. Has activat els registres d'accés cap a mercadofresco-registros-web i saps què signifiquen RequestCount, TargetResponseTime, HealthyHostCount i la diferència entre els 5XX de la destinació i els del balancejador.

I els comptes tanquen: amb quatre instàncies sanes repartides en dues zones, MercadoFresco aguanta les 900 comandes per hora del divendres fins i tot perdent una zona de disponibilitat sencera. El problema 1, les caigudes dels divendres, queda resolt.

Queden els diners. A la lliçó 02-03 vam fer un càlcul que va doldre: el 97 % del cost d'S3 és transferència de sortida, perquè cada foto del catàleg es descarrega íntegra des d'Irlanda cada vegada que algú la mira, i ara a més tot el trànsit dinàmic passa per un ALB que cobra per GB processat. A la lliçó 03-04, «Amazon CloudFront», posarem una xarxa de distribució de contingut davant de tot: les fotos se serviran des de l'edge location més propera al client, el bucket mercadofresco-catalogo-fotos deixarà de ser accessible directament gràcies a l'Origin Access Control, i veurem amb números quant baixa la factura. L'ALB que acabes de muntar continuarà allà darrere, però rebent només allò que de debò no es pot desar a la memòria cau.