Vam tancar el mòdul anterior amb MercadoFresco a punt: compte segur, regió triada, consola dominada i CLI configurada amb el perfil mercadofresco-dev. Tot allò era la bastida. Ara comença l'obra. En aquesta lliçó aixequem el primer servidor real de MercadoFresco al núvol amb Amazon EC2 (Elastic Compute Cloud), el servei que proporciona màquines virtuals sota demanda i la peça sobre la qual s'aguanta bona part del que ve després.

EC2 és el servei amb què gairebé tothom entra a AWS, i també on més diners es llencen per descuit. Per això no farem un passeig per la pantalla de creació: entendrem què és realment una instància, com se'n tria la mida sense endevinar, què són els crèdits de CPU (que seran decisius per al pic dels divendres), com s'automatitza l'arrencada del servidor amb user data, i com un grup d'Auto Scaling converteix el problema 1 de MercadoFresco —les caigudes dels divendres— en un problema resolt per configuració.

1. Què és una instància EC2 i quin problema resol
2. AMI: la plantilla de la qual neix la instància
3. Famílies i tipus d'instància: com llegir t3.micro
4. Com triar la mida sense endevinar
5. Instàncies burstable i crèdits de CPU
6. Models de compra: sota demanda, spot, reservades i Savings Plans
7. Cicle de vida d'una instància: aturar no és terminar
8. Accés a la instància: parells de claus, SSH, Instance Connect i Session Manager
9. user data: que la instància s'instal·li sola
10. Metadades d'instància i IMDSv2
11. Crear la instància per consola, pas a pas
12. Crear la instància per CLI amb l'esquema d'etiquetatge
13. Plantilles de llançament i Auto Scaling: la solució al pic dels divendres
14. Apagar i esborrar-ho tot per no gastar

Una instància EC2 és una màquina virtual que s'executa sobre la infraestructura física d'AWS. Té CPU, memòria, xarxa, un disc d'arrencada i un sistema operatiu complet: per al teu programari és indistingible d'un servidor de veritat. Hi pots instal·lar el que vulguis, obrir una sessió SSH, mirar els registres i reiniciar-la.

La diferència amb el servidor de l'oficina de MercadoFresco no és en allò que la màquina és, sinó en com s'obté i es retorna:

Aquesta darrera fila és la clau conceptual de tot el mòdul: a AWS, crear i destruir són operacions simètriques i barates. Quan la Marta necessiti quatre servidors de botiga el divendres a les 17:00 i només un el dissabte al matí, això deixa de ser una fantasia per convertir-se en una línia de configuració.

Nota sobre allò que EC2 no cobreix en aquesta lliçó. Tota instància viu dins d'una xarxa virtual (VPC) i està protegida per un grup de seguretat, que és el seu tallafocs. Aquí farem servir la VPC per defecte i crearem un grup de seguretat mínim, sense entrar en detall: les xarxes són el mòdul 3 sencer (03-01 VPC, 03-02 grups de seguretat i NACL). El disc de la instància es gestiona amb EBS, que és la lliçó 02-02.

Una AMI (Amazon Machine Image) és una imatge de disc congelada: sistema operatiu, paquets instal·lats, configuració i fitxers. Quan llances una instància, AWS copia l'AMI a un volum nou i arrenca la màquina des d'allà. L'AMI és la plantilla; la instància és la còpia viva.

Hi ha quatre orígens possibles:

Per a MercadoFresco farem servir Amazon Linux 2023: és gratuïta, està optimitzada per a EC2, inclou l'AWS CLI v2 preinstal·lada i l'agent de Systems Manager ja actiu (important per a Session Manager, més avall).

Un detall que confon al principi: l'identificador d'una AMI és diferent a cada regió. La mateixa Amazon Linux 2023 té un ami-0abc… a eu-west-1 i un altre de diferent a eu-central-1. Per això no s'escriu mai a mà en un script; es consulta. La manera robusta és preguntar-ho al magatzem de paràmetres públic d'AWS:

Sortida (exemple; el teu serà diferent):

Desglossament de la comanda:

• aws ssm get-parameter: Systems Manager Parameter Store desa parells clau/valor. AWS hi publica els ID de les seves AMI perquè no els hagis de buscar.
• --query 'Parameter.Value': JMESPath, tal com vam veure a 01-05, per quedar-nos només amb el valor.
• --output text: sense cometes, a punt per posar-lo en una variable de shell.

Desa'l en una variable, perquè el farem servir diverses vegades:

El tipus d'instància defineix quanta CPU, memòria, xarxa i disc té la màquina. AWS n'ofereix centenars, però el nom és un codi llegible que es desxifra per parts:

Un altre exemple: m6g.large = família m (equilibrada), generació 6, g de Graviton (processador ARM d'AWS), mida large.

Les famílies que necessites conèixer:

I les mides, que en general dupliquen recursos i preu a cada esglaó:

Aquesta linealitat té una conseqüència important i contraintuïtiva: dues instàncies large costen el mateix que una xlarge, però dues instàncies sobreviuen a la caiguda d'una zona de disponibilitat i una xlarge no. És el primer argument del disseny multi-AZ que vam veure a 01-03, i una de les raons per les quals preferirem escalar horitzontalment (més màquines) abans que verticalment (màquines més grans).

El mètode professional no és intuir, és mesurar. Per a MercadoFresco:

1. Parteix de la dada coneguda. Una instància de la botiga suporta 600 comandes/hora. El pic dels divendres és de 900 comandes/hora. Amb una sola màquina, el 33 % de les comandes del pic es perd: això són les caigudes del problema 1.
2. Comença petit. Al núvol, canviar de mida costa un reinici. Començar gros "per si de cas" costa diners cada hora, per sempre.
3. Mesura amb CloudWatch (lliçó 05-01): CPU, memòria (requereix l'agent), xarxa i latència durant almenys una setmana sencera, incloent-hi un divendres.
4. Aplica la regla del 40-60 %. Si la CPU mitjana està per sota del 40 %, sobra màquina. Si supera el 70 % de manera sostinguda, en falta.
5. Consulta Compute Optimizer, el servei gratuït d'AWS que analitza les teves mètriques i recomana tipus i mida.

Per al nostre punt de partida triem t3.micro per dues raons: entra a la capa gratuïta (750 hores al mes durant 12 mesos) i el seu comportament burstable ens permet explicar els crèdits de CPU, que són justament allò que fa fracassar molta gent en el seu primer pic de trànsit.

Aquí hi ha el concepte que més disgustos dona a qui comença, i el que més importa per al divendres de MercadoFresco.

Les instàncies de la família T no et donen la CPU sencera tota l'estona. Et donen una línia base —un percentatge del nucli— i acumulen crèdits de CPU quan consumeixes menys d'aquesta línia. Quan en necessites més, gastes crèdits per arribar al 100 %. Si se t'acaben, la instància s'estrangula (throttling) i baixa bruscament a la línia base, encara que la CPU física estigui lliure.

Un crèdit = un minut d'una vCPU al 100 %.

Fem el càlcul real de MercadoFresco. Un t3.micro acumula 12 crèdits/hora, amb un màxim de 288 (equivalent a 24 hores d'acumulació). El pic dels divendres dura de 17:00 a 21:00, quatre hores, i en aquesta estona la botiga estaria al 100 % de CPU amb les seves 2 vCPU:

És a dir: el t3.micro aguanta menys de tres hores del pic i després s'estrangula al 10 % de CPU. La botiga no cau per falta de servidor, cau per falta de crèdits, i al tauler de CloudWatch la CPU apareix plana i baixa, cosa que despista moltíssim si no coneixes el mecanisme.

Hi ha dues sortides, i convé entendre que només una és bona:

• Mode unlimited (activat per defecte a T3): quan s'acaben els crèdits, AWS deixa que continuïs al 100 % i et cobra un extra per cada vCPU-hora sobrera. Evita la caiguda, però la factura es dispara si el pic és habitual. Es pot forçar el mode standard perquè mai no cobri de més, a canvi d'acceptar l'estrangulament.
• Escalar horitzontalment: afegir instàncies durant el pic. És la solució correcta, i la veurem al final d'aquesta lliçó amb Auto Scaling.

Consultar el saldo de crèdits (mètrica CPUCreditBalance, a CloudWatch):

Regla pràctica. Les instàncies T són excel·lents per a càrregues irregulars amb valls llargues (desenvolupament, entorns de proves, serveis interns). Per a una càrrega sostinguda i previsible, una M surt més barata i més previsible que una T en mode unlimited.

La mateixa instància pot costar quatre preus diferents segons el compromís que adquireixis. Aquí només els comparem perquè sàpigues que existeixen i quan es fa servir cadascun; l'anàlisi econòmica completa, amb càlculs d'amortització, és la lliçó 11-05.

Tres idees per quedar-te:

• Spot no vol dir "barat i pitjor": és exactament la mateixa màquina, amb la condició que AWS pot recuperar-la. Només serveix per a càrregues que toleren ser interrompudes i reintentades.
• Reservades i Savings Plans no són màquines, són descomptes de facturació que s'apliquen automàticament al consum que ja tens.
• No compris compromisos fins a tenir tres mesos de dades reals. La Marta no reservarà res fins al mòdul 11.

Una instància passa per estats ben definits, i confondre'n dos —stopped i terminated— és l'error més car i més irreversible d'EC2.

Què passa exactament a cada transició:

Els quatre matisos que cal memoritzar:

1. Aturar no esborra res. El volum EBS arrel continua existint i continua costant diners (uns 0,08 USD per GB i mes amb gp3). Una instància aturada és gairebé gratis, però no del tot.
2. Terminar és definitiu. No hi ha paperera. El volum arrel s'elimina llevat que hagis desactivat DeleteOnTermination. Si hi desaves dades, han desaparegut.
3. La IP pública automàtica es perd en aturar. En arrencar de nou en reps una altra de diferent. Si necessites una IP estable, es fa servir una Elastic IP (mòdul 3) o, millor, un nom DNS (03-05).
4. La IP privada sí que es conserva mentre la instància existeixi.

Per a producció, la Marta activarà sempre la protecció contra la terminació:

Per tornar a permetre l'esborrat cal executar la comanda amb --no-disable-api-termination. És una fricció deliberada: dos passos conscients en comptes d'un clic irreversible.

Un parell de claus és una parella de claus criptogràfiques. AWS desa la pública i la col·loca dins de la instància en arrencar (a ~/.ssh/authorized_keys); tu et quedes la privada en un fitxer .pem. AWS no guarda còpia de la clau privada: si la perds, no hi ha recuperació possible per part del suport.

Notes de la comanda:

• --key-type ed25519 és més modern i curt que RSA; tots dos serveixen, però ed25519 és l'elecció per defecte avui (Windows amb instàncies antigues pot requerir rsa).
• La sortida de KeyMaterial només es mostra una vegada. Si no la rediriges a un fitxer, l'has perduda.

Connexió, un cop la instància estigui en running:

L'usuari per defecte depèn de l'AMI: ec2-user a Amazon Linux, ubuntu a Ubuntu, admin a Debian. Connectar-se com a root està deshabilitat expressament.

Existeixen dues alternatives que eviten gestionar fitxers .pem, i convé conèixer-les:

Session Manager (part d'AWS Systems Manager) és l'opció que farà servir MercadoFresco en producció: la instància no necessita IP pública ni port SSH obert, perquè és ella qui inicia la connexió sortint cap a AWS. Menys superfície d'atac i auditoria completa de qui va entrar i què va teclejar.

Els permisos IAM que això requereix es detallen a la lliçó 04-01; els grups de seguretat que controlen el port 22, a la 03-02.

El camp user data és un script que la instància executa com a root, una sola vegada, a la seva primera arrencada. És la diferència entre "he creat un servidor" i "he creat un servidor que ja està servint la botiga".

Aquest és l'script de MercadoFresco. Desa'l com a user-data-tienda.sh:

Com es comporta i com es depura:

• S'executa només a la primera arrencada. Si atures i arrenques la instància, no es repeteix.
• La sortida completa queda a /var/log/cloud-init-output.log dins de la instància. Quan alguna cosa "no funciona i no sé per què", aquest fitxer és la primera parada.
• Ha de ser idempotent i sense interacció: res d'apt install sense -y, res d'esperar una pulsació de tecla.
• No posis mai credencials al user data: qualsevol que tingui accés a la instància pot llegir-lo amb curl a les metadades. Per als secrets es fa servir Secrets Manager (lliçó 04-03).

Cada instància es pot preguntar a si mateixa qui és, consultant una adreça especial que només respon des de dins: 169.254.169.254. Allà hi viuen les metadades d'instància: el seu ID, el seu tipus, la seva AZ, les seves IP, les seves etiquetes (si ho habilites) i —molt important— les credencials temporals del rol IAM associat.

Aquesta darrera part explica per què la seguretat d'aquest punt d'enllaç importa tant. La versió 1 (IMDSv1) responia a qualsevol GET, cosa que permetia que una vulnerabilitat de tipus SSRF a l'aplicació web fes que el mateix servidor filtrés les seves credencials. IMDSv2 exigeix obtenir abans un testimoni per PUT, cosa que un SSRF simple no pot fer.

Rutes útils en el dia a dia:

Política de MercadoFresco: exigir IMDSv2 sempre. Es força en llançar la instància amb --metadata-options "HttpTokens=required", tal com farem a la comanda de creació.

Farem primer el camí visual, perquè ensenya el vocabulari, i després el mateix resultat per CLI, que és el que s'automatitza.

1. Consola → busca EC2 → comprova a dalt a la dreta que la regió és Irlanda (eu-west-1). Aquesta comprovació no és opcional: és el parany que vam veure a 01-04.
2. Instàncies → Llançar instàncies.
3. Nom i etiquetes: mercadofresco-tienda-01. Prem Afegir etiquetes addicionals i completa l'esquema obligatori del projecte:
   • Proyecto = mercadofresco
   • Entorno = desarrollo
   • Componente = tienda
   • Propietario = luis
   • CentroCoste = operaciones
4. Imatge (AMI): Amazon Linux 2023, arquitectura x86_64. Fixa't en l'etiqueta Apte per a la capa gratuïta.
5. Tipus d'instància: t3.micro.
6. Parell de claus: selecciona mercadofresco-tienda (el que has creat abans) o crea'l aquí i descarrega el .pem.
7. Configuració de xarxa: deixa la VPC per defecte i crea un grup de seguretat anomenat sg-mercadofresco-tienda amb dues regles d'entrada: HTTP (80) des de 0.0.0.0/0 i SSH (22) des de La meva IP. Mai SSH obert al món. El detall d'això és la lliçó 03-02.
8. Emmagatzematge: 8 GiB gp3, el valor per defecte. Els discs són la lliçó 02-02.
9. Detalls avançats → desplega fins al final i enganxa el contingut de user-data-tienda.sh al camp Dades d'usuari. Al mateix bloc, verifica que Versió d'IMDS estigui en V2 obligatori.
10. Revisa el tauler de resum de la dreta i prem Llançar instància.

En 30-60 segons l'estat passarà a running i les comprovacions d'estat (2/2) es posaran en verd. Copia la IP pública i obre-la al navegador: veuràs la pàgina de MercadoFresco amb l'ID de la instància i la seva zona de disponibilitat.

Avís de cost. Un t3.micro està dins de la capa gratuïta durant els 12 primers mesos (750 h/mes). Si ja l'has exhaurida, costa de l'ordre de 0,01 USD/hora a eu-west-1. L'apartat final explica com esborrar-ho tot.

El mateix resultat, en una sola comanda reproduïble. Primer el grup de seguretat mínim (es detalla a 03-02; aquí és només instrumental):

I ara la instància:

Paràmetre a paràmetre, perquè cadascun té el seu perquè:

• --user-data file://…: el prefix file:// és obligatori; sense ell, la CLI enviaria la cadena literal user-data-tienda.sh com a script. La CLI v2 codifica el fitxer en base64 per tu.
• --metadata-options HttpTokens=required: força IMDSv2. HttpPutResponseHopLimit=1 impedeix que un contenidor dins de la instància arribi a les metadades de l'amfitrió.
• --credit-specification CpuCredits=standard: en proves preferim que la instància s'estranguli abans que generar càrrecs inesperats per unlimited.
• --tag-specifications: es passa dues vegades, una per a la instància i una altra per al volum. Aquest és l'error d'etiquetatge més freqüent: s'etiqueta la instància, s'oblida el disc, i al mòdul 11 apareix una despesa d'EBS que no se sap a qui imputar.

Comprovar el resultat amb una consulta llegible:

Ja tenim un servidor. Però un servidor no resol el problema 1: els divendres de 17:00 a 21:00 arriben 900 comandes/hora i una instància en suporta 600. I comprar una màquina més gran "per al divendres" significa pagar-la les 168 hores de la setmana per fer-la servir 4.

La resposta d'AWS són dues peces que treballen juntes.

És la recepta versionada de com ha de ser una instància de la botiga: AMI, tipus, parell de claus, grup de seguretat, user data, etiquetes. Deixa d'haver-hi "la instància que va muntar el Luis a mà"; hi ha una definició que qualsevol pot reproduir idèntica.

Les plantilles són versionades: en canviar el user data crees la versió 2 i pots tornar a la 1 si alguna cosa surt malament. Aquesta capacitat de revertir és el primer pas cap al problema 4 (desplegaments arriscats), que es resoldrà del tot al mòdul 8.

Un ASG manté un nombre d'instàncies sanes repartides entre diverses zones de disponibilitat, i l'ajusta segons la demanda. Té tres números:

El dimensionament surt de les xifres reals:

• --vpc-zone-identifier: dues subxarxes en dues AZ diferents (eu-west-1a i eu-west-1b), tal com vam decidir a 01-03. Substitueix els ID pels de la teva VPC per defecte.
• --health-check-grace-period 120: dona 2 minuts al user data abans de jutjar si la instància està sana. Sense aquesta espera, l'ASG mata instàncies que encara s'estaven instal·lant.
• PropagateAtLaunch=true: les etiquetes es copien a cada instància nova. Sense això, les màquines creades per l'ASG apareixerien sense etiquetar a la factura.

I la política que fa la feina automàticament:

El target tracking és la política recomanada: declares l'objectiu i AWS calcula sol quan afegir i quan treure màquines. Alternatives: escalat per passos (llindars manuals) i escalat programat, que per a MercadoFresco té molt sentit perquè el pic és a una hora coneguda:

El flux complet:

Falta una peça perquè això funcioni de veritat: alguna cosa que reparteixi el trànsit entre les instàncies. Això és l'Elastic Load Balancing, la lliçó 03-03. Aquí hem muntat el motor; al mòdul 3 li connectarem la direcció.

Regla d'or del curs: allò que crees en una lliçó, ho esborres en acabar-la.

Si vols conservar la instància per a la lliçó següent sense pagar còmput, atura-la en comptes de terminar-la (continuaràs pagant només el volum de 8 GiB, uns 0,64 USD al mes):

I recorda revisar el pressupost presupuesto-mensual-mercadofresco que vas configurar a 01-02: és la teva xarxa de seguretat si alguna cosa es queda encesa.

• Terminar creient que s'atura. L'error irreversible per excel·lència. Activa sempre --disable-api-termination en qualsevol instància amb dades.
• Perdre el fitxer .pem. AWS no en té còpia. Si el perds, l'única sortida és desconnectar el volum i muntar-lo en una altra instància. Desa'l al gestor de contrasenyes i tingues habilitat Session Manager com a pla B.
• Obrir el port 22 a 0.0.0.0/0. Rebràs intents d'accés automatitzats en qüestió de minuts. Sempre <la-teva-ip>/32, o millor, cap port SSH i Session Manager.
• Sorprendre't perquè la CPU es queda plana al 10 %. Són els crèdits burstable exhaurits. Mira la mètrica CPUCreditBalance abans de culpar l'aplicació.
• Oblidar file:// a --user-data. La instància arrenca "bé" però no instal·la res. Si el servidor web no respon, entra-hi i llegeix /var/log/cloud-init-output.log.
• Etiquetar la instància i no el volum. Passa --tag-specifications per a instance i per a volume, sempre.
• Esperar que el user data s'executi a cada arrencada. Només corre la primera vegada. Per a tasques de cada arrencada, fes servir una unitat de systemd creada pel mateix user data.
• Confondre la IP pública amb alguna cosa estable. Canvia en aturar i arrencar. Fes servir DNS (03-05).
• Deixar l'ASG amb un min-size alt "per si de cas". És la manera més silenciosa de multiplicar la factura: cada instància del mínim es paga 24×7.
• Consell d'or: comença petit i mesura. És infinitament més barat pujar de mida una instància infradimensionada que descobrir al mòdul 11 que fa sis mesos que pagues el doble.

MercadoFresco vol obrir en dues ciutats més (problema 3). La previsió és que el pic dels divendres passi de 900 a 2.100 comandes/hora. Cada instància continua suportant 600 comandes/hora i la política de la Marta exigeix que el servei continuï funcionant encara que caigui una zona de disponibilitat sencera.

Calcula el mínim, el desitjat i el màxim de l'ASG, justificant cada número, i escriu la comanda aws autoscaling update-auto-scaling-group corresponent.

El Luis llança una instància amb l'script de la lliçó, la instància apareix running amb 2/2 comprovacions en verd, però en obrir la IP pública el navegador es queda esperant indefinidament (no dona "connexió rebutjada", simplement no respon).

Enumera, en ordre de cost creixent d'investigació, els passos que faries i què comprovaries a cadascun. Indica quina és la causa més probable atesa la pista del "es queda esperant".

Per a cadascuna d'aquestes tres càrregues de MercadoFresco, tria família, mida aproximada i model de compra, i justifica-ho en una frase:

• A) Servidor de la botiga en producció, trànsit sostingut les 24 hores, 4 GiB de RAM suficients, CPU al 55 % de mitjana.
• B) Procés nocturn que recomprimeix les 40.000 fotos del catàleg; triga 3 hores, satura la CPU, i si s'interromp pot reprendre's des d'on anava.
• C) Entorn de desenvolupament del Luis, encès de 9:00 a 18:00 de dilluns a divendres, gairebé sempre inactiu amb ràfegues en compilar.

Solució 1.

• Mínim = 2. En vall no en cal més, però mai menys de 2 per tenir una instància a cada AZ i no dependre d'una de sola.
• Desitjat = 2. És el punt de partida; la política de seguiment d'objectiu el pujarà sola. Es pot combinar amb una acció programada que el porti a 4 els divendres a les 16:45.
• Màxim = 8. Cobreix les 4 necessàries més el marge perquè, si cau una AZ, les 4 restants puguin llançar-se a la que continua dempeus. El màxim també actua com a sostre de despesa: si un atac o un error dispara la CPU, mai no es passarà de 8 instàncies.

Solució 2.

El matís clau: "es queda esperant" ≠ "connexió rebutjada". Si nginx estigués caigut però la xarxa hi arribés, el sistema operatiu retornaria un rebuig immediat. Un temps d'espera exhaurit indica que els paquets no arriben a la instància, és a dir, un problema de xarxa, no de programari.

Passos per cost creixent:

1. Grup de seguretat (30 segons, sense entrar a la màquina): comprovar que existeix una regla d'entrada TCP 80 des de 0.0.0.0/0. Aquesta és la causa més probable.

   aws ec2 describe-security-groups --group-ids "$SG_ID" \\
     --query 'SecurityGroups[].IpPermissions' \\
     --profile mercadofresco-dev --region eu-west-1
   

2. IP pública: verificar que la instància en té una (PublicIpAddress no nul) i que estàs fent servir aquesta i no la privada 172.31.x.x.
3. Subxarxa pública: la subxarxa ha de tenir ruta cap a una passarel·la d'internet (això s'entén del tot a 03-01).
4. Entrar per Session Manager (no requereix el port 22, útil precisament quan la xarxa falla) i:

   sudo systemctl status nginx
   sudo tail -50 /var/log/cloud-init-output.log
   curl -s localhost   # si això respon, el servidor està bé i el problema és de xarxa
   

Solució 3.

MercadoFresco ja té el seu primer servidor a AWS, i sobretot té el vocabulari i els mecanismes per raonar-hi. Saps que una AMI és la plantilla i la instància la còpia viva, i que l'ID d'una AMI canvia amb la regió, per la qual cosa es consulta i no es copia. Saps desxifrar t3.micro i triar entre les famílies T, M, C i R en funció de si la càrrega és irregular, equilibrada, intensiva en CPU o intensiva en memòria. Has vist per dins el mecanisme dels crèdits de CPU i has calculat que un t3.micro no sobreviu a les quatre hores del pic dels divendres: una dada concreta, no una intuïció.

Coneixes els quatre models de compra i en quin cas encaixa cadascun, i domines el cicle de vida amb la distinció que surt més cara: aturar conserva el disc, terminar el destrueix per sempre. Saps accedir a la màquina amb un parell de claus i també sense, mitjançant EC2 Instance Connect o Session Manager, que és l'opció que MercadoFresco farà servir en producció per no requerir cap port obert. Has automatitzat la instal·lació completa de la botiga amb user data, saps on llegir-ne el registre quan falla, i has protegit les metadades exigint IMDSv2. Has creat la instància per consola i per CLI aplicant l'esquema d'etiquetatge del projecte tant a la instància com al seu volum.

I, sobretot, has posat la primera peça real contra el problema 1: una plantilla de llançament versionada i un grup d'Auto Scaling de 2 a 4 instàncies amb seguiment d'objectiu i escalat programat, dimensionat amb les xifres reals de MercadoFresco (900 comandes/h davant de 600 per instància). Falta el balancejador que reparteixi el trànsit entre elles, i això és la lliçó 03-03.

Abans d'això hi ha una pregunta que l'Auto Scaling deixa al descobert: si les instàncies neixen i moren soles, on viuen les dades? Les fotos de producte que avui són a /var/www/fotos no poden estar dins d'un disc que es destrueix amb la màquina. A la lliçó 02-02, «Emmagatzematge de blocs i de fitxers: EBS i EFS», veurem els volums que sobreviuen a la instància, com s'amplien en calent, com es comparteixen entre diverses màquines i com les instantànies automatitzades amb Data Lifecycle Manager tanquen d'una vegada el problema 2 de MercadoFresco: les còpies de seguretat que mai no van ser fiables.