Quan la Marta va crear el compte de MercadoFresco a la lliçó anterior, vam deixar apuntada una decisió sense justificar del tot: la regió serà eu-west-1. Aquesta lliçó explica per què, i per fer-ho hem d'obrir el capó i veure com està construït AWS per dins.

Entendre la infraestructura global no és cultura general: és la base de l'alta disponibilitat. El servidor de MercadoFresco cau els divendres perquè és un. La manera que això deixi de passar és repartir l'aplicació entre instal·lacions físicament separades que no fallen alhora. Per dissenyar aquest repartiment necessites saber què és una regió, què és realment una zona de disponibilitat, quins serveis són globals i quins no, i quant costa moure dades entre uns llocs i uns altres.

1. Les tres capes de la infraestructura d'AWS
2. Regions: què són, com s'anomenen i per què estan aïllades
3. Zones de disponibilitat: què és realment una AZ
4. Per què les lletres de les AZ es barregen entre comptes
5. Xarxa de vora: edge locations, PoP i regional edge caches
6. Infraestructura especialitzada: Local Zones, Wavelength i Outposts
7. Serveis globals, regionals i zonals
8. Com triar regió: els cinc criteris
9. Disseny multi-AZ: què falla i què sobreviu
10. Decisió de regió per a MercadoFresco
11. Cost del trànsit entre AZ i entre regions

La infraestructura d'AWS s'organitza en una jerarquia de tres nivells. Interioritza-la, perquè gairebé tota la resta se'n deriva.

Una regió d'AWS és una àrea geogràfica del món on AWS ha construït un grup de centres de dades. Exemples: Irlanda, Frankfurt, París, Espanya, Nord de Virgínia, Tòquio, São Paulo.

Els identificadors segueixen un patró fix, i convé saber-lo llegir perquè l'escriuràs centenars de vegades a la CLI i a les plantilles:

Regions europees que t'interessen com a professional a Espanya:

Compte amb us-east-1 (Nord de Virgínia): és la regió més antiga i gran, on AWS estrena gairebé tots els serveis, i on viuen forçosament algunes coses globals (com la mètrica de facturació que vam veure a 01-02, o els certificats de CloudFront). No la facis servir com a regió principal si els teus clients són a Europa.

Aquest és el punt conceptual més important: les regions són independents entre si. No és una frase de màrqueting, és una propietat de disseny amb conseqüències pràctiques molt concretes:

• Un recurs creat a eu-west-1 no existeix a eu-west-3. Si busques la teva instància a la regió equivocada, la consola et dirà que no hi ha res.
• Les dades no surten d'una regió tret que ho demanis explícitament (replicació entre regions, còpia d'una instantània, transferència). Aquesta és la base del compliment de l'RGPD.
• Una fallada greu en una regió no es propaga a les altres. És la unitat d'aïllament de fallades més gran que existeix.
• Els preus varien per regió. El mateix servidor pot costar un 20 % més a São Paulo que a Irlanda.
• Alguns serveis nous no estan disponibles a totes les regions.

Regla mental: pensa en cada regió com un núvol complet i separat que casualment comparteix la consola, l'API i el teu compte amb els altres.

Una zona de disponibilitat (Availability Zone, AZ) és un conjunt d'un o més centres de dades dins d'una regió, amb:

• Alimentació elèctrica independent: la seva pròpia escomesa i els seus propis generadors.
• Refrigeració independent.
• Connectivitat de xarxa independent.
• Separació física real: són a quilòmetres de distància les unes de les altres, prou lluny perquè una inundació, un incendi o un tall elèctric no n'afecti dues alhora, i prou a prop perquè la latència entre elles continuï sent mínima.

Aquesta doble condició —lluny per al risc, a prop per a la latència— és la clau de tot el disseny:

Que la latència entre AZ sigui d'1-2 mil·lisegons és el que fa possible que una base de dades RDS en mode Multi-AZ escrigui de manera síncrona a dues AZ alhora: cada transacció es confirma a totes dues abans de donar l'OK, i si una AZ desapareix, no es perd ni una comanda. Amb 40 ms això seria inviable.

Les AZ s'anomenen afegint una lletra a l'identificador de la regió: eu-west-1a, eu-west-1b, eu-west-1c.

Aquí hi ha un detall que confon molta gent i que convé entendre bé.

eu-west-1a no és el mateix centre de dades per a tots els comptes d'AWS. AWS assigna les lletres de manera aleatòria i independent per a cada compte. La eu-west-1a de MercadoFresco pot ser físicament la mateixa instal·lació que la eu-west-1c d'una altra empresa.

Per què? Per repartir la càrrega. Si les lletres fossin fixes, la majoria dels clients triaria "la a" per costum i aquella zona es congestionaria mentre les altres quedarien buides. L' aleatorització distribueix l'ús de manera uniforme.

Conseqüències pràctiques:

• No comparis lletres d'AZ entre comptes. Dir "desplega a la 1a" a un company d'una altra empresa no significa res.
• Per identificar la zona física real existeix l'AZ ID, que sí que és estable i global: euw1-az1, euw1-az2, euw1-az3. Aquest identificador és el mateix per a tots els comptes.

Pots veure la correspondència del teu compte amb aquesta comanda (la CLI s'instal·la i configura a la lliçó 01-05; aquí només en mostrem el resultat perquè el reconeguis):

Explicat línia a línia:

• aws ec2 describe-availability-zones: servei ec2, operació que llista zones.
• --region eu-west-1: sobre quina regió preguntem.
• --query '...': filtre JMESPath que es queda només amb tres camps i els posa nom.
• --output table: format de taula llegible en lloc de JSON.

Sortida aproximada:

Fixa-t'hi: en aquest compte, eu-west-1a correspon físicament a euw1-az2. En un altre compte la correspondència seria diferent.

A més de regions i AZ, AWS té una tercera capa molt més nombrosa i repartida: la xarxa de vora (edge network).

El flux és una jerarquia de memòries cau:

Per a MercadoFresco això té un efecte directe: les fotos de producte (milers d'imatges que gairebé no canvien) es poden servir des de l'edge de Madrid en pocs mil·lisegons, sense tocar l'origen a Irlanda. Això millora l'experiència del client i redueix càrrega i cost de sortida.

Els serveis que fan servir aquesta xarxa són CloudFront (xarxa de distribució de contingut), Route 53 (DNS), AWS Shield i AWS WAF (protecció) i Global Accelerator. Com es configura CloudFront és la lliçó 03-04; Route 53 és 03-05; Shield i WAF, 04-04 i 04-05. Aquí només et cal saber que aquesta capa existeix i que és fora de les regions.

A més del que hem vist, AWS ofereix tres extensions que probablement no faràs servir al principi, però que convé reconèixer pel nom.

MercadoFresco no necessita cap de les tres. La seva latència objectiu (una botiga web) es resol de sobres amb una regió europea més CloudFront.

Aquest és un dels punts on més s'equivoquen els principiants: no tots els serveis d'AWS tenen el mateix abast.

Casos que convé matisar perquè generen confusió:

• Amazon S3: el bucket és regional i les seves dades es repliquen automàticament entre diverses AZ, però el nom del bucket és únic a escala global. Ningú més al món no pot anomenar el seu bucket igual que tu.
• Amazon RDS: una instància individual és zonal. En mode Multi-AZ hi ha una rèplica en una altra AZ, amb commutació automàtica. L'endpoint de connexió no canvia en commutar.
• AWS Lambda: tu desplegues la funció en una regió i AWS s'encarrega d'executar-la en diverses AZ. És regional i no t'has de preocupar de la redundància.
• VPC: la VPC és regional, però cada subxarxa pertany a una única AZ. Aquesta és la peça que faràs servir per repartir els teus servidors (lliçó 03-01).

Regla pràctica: si el recurs és zonal, és responsabilitat teva tenir-ne un altre d'igual en una altra AZ.

Triar regió no és una qüestió de gust. Aquests són els cinc criteris, en ordre d'importància habitual.

Cada 1.000 km afegeixen aproximadament 10 ms d'anada i tornada per la velocitat de la llum a la fibra, més el retard dels salts de xarxa. Referències aproximades des de Madrid:

Per a una botiga en línia, la diferència entre 35 ms i 100 ms és perfectament perceptible: una pàgina que fa 20 peticions encadenades acumula més d'un segon de retard extra.

MercadoFresco tracta dades personals de clients espanyols: nom, adreça, telèfon, historial de compra. L'RGPD no prohibeix treure dades de la UE, però exigeix garanties addicionals i documentació quan es transfereixen a tercers països. La manera més simple de complir sense advocats és no treure-les: triar una regió de la Unió Europea.

Això descarta directament us-east-1 i, a la pràctica, també eu-west-2 (Londres), que va quedar fora de la UE després del Brexit.

No totes les regions ofereixen tots els serveis, ni tots els tipus d'instància. Les regions més antigues i grans (us-east-1, eu-west-1, eu-central-1) tenen el catàleg més complet; les més recents (com eu-south-2) van incorporant serveis progressivament.

Abans de comprometre't amb una regió, comprova a la pàgina de disponibilitat regional d'AWS que tots els serveis de la teva arquitectura hi són. Descobrir a mitja obra que et falta un servei és molt car.

El mateix recurs costa diferent segons la regió. Prenent us-east-1 com a índex 100, els ordres de magnitud aproximats són:

La diferència entre regions europees és d'un dígit percentual: no compensa sacrificar latència o compliment per estalviar un 5 %.

Si la teva aplicació depèn d'un sistema que ja és en un altre lloc (un ERP, un proveïdor extern, una base de dades heretada), col·locar-t'hi a prop redueix latència i cost de transferència. En el cas de MercadoFresco, el servidor de l'oficina desapareixerà en acabar la migració, així que aquest criteri no pesa.

Anem al que importa. Què passa exactament quan cau una AZ, i com se sobreviu?

Si eu-west-1a pateix un tall elèctric, MercadoFresco està caiguda al 100 %. És exactament la mateixa fragilitat del servidor de l'oficina, només que en un edifici més bonic. Molta gent migra al núvol i es queda aquí, sense adonar-se que no ha guanyat disponibilitat.

Ara simulem la caiguda completa d'eu-west-1a:

Resultat: en lloc d'una caiguda total d'hores, MercadoFresco té una degradació d'un o dos minuts. Aquesta és la diferència entre perdre la tarda del divendres i no assabentar-se'n.

1. Dimensiona per a N-1. Si necessites 4 servidors per atendre el pic i els reparteixes 2 i 2, en caure una AZ te'n queden 2 i no hi arribes. Reparteix 3 i 3, o fes servir escalat automàtic que reaccioni.
2. No posis estat al disc local d'una instància. Les fotos de producte no poden viure al disc d'un EC2: si aquella instància desapareix, desapareixen. Van a S3 (lliçó 02-03).
3. Prova la fallada. Una arquitectura multi-AZ que mai no s'ha provat és una hipòtesi. Apagar deliberadament una instància i comprovar que el servei continua dempeus és un exercici sa.

Repartir entre dues regions protegeix contra la fallada d'una regió sencera, però multiplica la complexitat: replicació de dades a desenes de mil·lisegons, DNS amb commutació, cost de transferència i el doble d'infraestructura. Per a MercadoFresco és innecessari avui. La regla general de la indústria és: multi-AZ des del principi, multiregió només quan el negoci ho justifiqui.

La Marta compara les tres candidates realistes amb els cinc criteris:

Decisió: eu-west-1 (Irlanda), amb aquest raonament explícit:

• La latència de 35-45 ms és perfectament acceptable per a una botiga web, i a més la major part del pes de la pàgina (fotos de producte) es servirà des de l'edge de Madrid via CloudFront, amb la qual cosa la latència percebuda serà molt menor que la latència a l'origen.
• El catàleg complet evita el risc de descobrir a mitja obra que falta un servei, cosa crítica quan el curs recorrerà onze mòduls de serveis diferents.
• És a la UE, amb la qual cosa l'RGPD es compleix sense transferències internacionals.
• És la regió amb més documentació i exemples, cosa que importa molt en un equip de tres persones sense especialista en AWS.

La Marta anota a més una revisió futura: quan eu-south-2 completi el seu catàleg i si la latència esdevé un factor competitiu, es reavaluarà. Documentar la decisió i la seva data de revisió és una bona pràctica d'arquitectura.

El preu de moure dades dins d'AWS sorprèn molts equips. Aquests són els ordres de magnitud que has de tenir al cap:

Exemple concret per a MercadoFresco: si els servidors d'aplicació d'eu-west-1a consulten la base de dades d'eu-west-1b, cada gigabyte de resultats travessa una frontera d'AZ i es factura. Amb 500 GB al mes de trànsit entre capes, serien uns 10 $/mes. No és dramàtic, però:

• Dissenya perquè el trànsit calent es quedi dins de l'AZ quan puguis.
• No ho facis a costa de la disponibilitat. Pagar 10 $ al mes per sobreviure a la caiguda d'un centre de dades és una de les millors compres que pot fer MercadoFresco.

I un advertiment important: el cost entre AZ no t'ha d'empènyer a posar-ho tot en una sola AZ. Aquest estalvi és exactament el que et costarà la tarda del divendres.

• Crear recursos a la regió equivocada. És l'error número u dels principiants: crees una instància, tanques el navegador, tornes l'endemà amb una altra regió seleccionada i "ha desaparegut". No ha desaparegut: continua facturant a l'altra regió. Ho veurem amb detall a la lliçó 01-04.
• Creure que "és a AWS" implica alta disponibilitat. Una única instància EC2 en una única AZ té, aproximadament, la mateixa disponibilitat que un servidor ben mantingut a l'oficina. La redundància s'ha de dissenyar.
• Suposar que eu-west-1a és el mateix en tots els comptes. Fes servir l'AZ ID (euw1-az1) quan necessitis parlar de la zona física, per exemple en compartir subxarxes entre comptes.
• Triar us-east-1 perquè "és la que surt a tots els tutorials". Si els teus usuaris i les teves dades són a Europa, és una mala elecció per latència i per compliment.
• Repartir en dues AZ però dimensionar només per al total. Si en perdre una AZ et quedes per sota de la capacitat necessària, el teu disseny multi-AZ només serveix per no caure del tot, no per continuar donant servei.
• Oblidar que hi ha recursos zonals sense rèplica. Un volum EBS viu en una AZ. La seva instantània, en canvi, es desa a S3 i és regional: per això les instantànies són la manera de moure un disc d'una AZ a una altra.
• Consell: documenta per escrit la regió triada, els motius i la data de revisió. Canviar de regió més endavant és un projecte de migració complet, no un ajust de configuració.
• Consell: quan dissenyis, pregunta't sempre "què passa si aquesta AZ desapareix ara mateix?". Si la resposta és "cau la botiga", tens feina a fer.

Respon raonadament:

1. Un company et diu: "he desplegat a eu-west-1a, desplega-hi tu també perquè estiguem junts". Treballeu en comptes d'AWS diferents. Què li contestes i quina dada li demanes?
2. Classifica com a global, regional o zonal: un usuari IAM, un bucket S3, una instància EC2, una funció Lambda, un volum EBS, una distribució de CloudFront, una subxarxa.
3. Per què és possible que una base de dades repliqui de manera síncrona entre dues AZ però no entre dues regions?

Per a cada escenari, tria regió i justifica-ho amb almenys tres dels cinc criteris:

Escenari A. MercadoFresco decideix obrir una filial a Mèxic amb clients exclusivament mexicans i catàleg propi. Les dades de clients mexicans no es barregen amb les espanyoles.

Escenari B. La Sara necessita un entorn on processar durant la nit els informes de vendes històrics, sense usuaris interactius, amb dades ja anonimitzades i sense dades personals. El cost és el criteri dominant.

MercadoFresco desplega a eu-west-1 amb aquesta configuració:

• 2 instàncies EC2 de la botiga: una a eu-west-1a, una altra a eu-west-1b. Cadascuna suporta com a màxim 600 comandes per hora.
• 1 base de dades RDS en mode Multi-AZ, amb la primària a eu-west-1a.
• Les fotos de producte a S3.
• Un Application Load Balancer davant de les instàncies.
• El pic del divendres és de 900 comandes per hora.

Respon:

1. Què passa exactament si eu-west-1a cau un dimarts a les 10:00 (200 comandes/hora)?
2. I si cau un divendres a les 19:00, en ple pic?
3. Proposa dos canvis concrets perquè l'escenari del divendres no degradi el servei, i indica quin dels dos preferiries per cost.

Solució 1

1. Li contestes que les lletres de les AZ no coincideixen entre comptes: la seva eu-west-1a pot ser una altra instal·lació física que la teva. Li demanes l'AZ ID (per exemple euw1-az2), que sí que és estable i global, i busques al teu compte quina lletra li correspon amb aws ec2 describe-availability-zones.

2. Recurs	Abast
   Usuari IAM	Global
   Bucket S3	Regional (amb nom únic global)
   Instància EC2	Zonal
   Funció Lambda	Regional
   Volum EBS	Zonal
   Distribució de CloudFront	Global
   Subxarxa	Zonal

3. Perquè la replicació síncrona exigeix esperar la confirmació del destí abans de donar per bona la transacció. Entre AZ, aquest viatge costa 1-2 ms, un sobrecost assumible per operació. Entre regions costa 30-40 ms o més, cosa que reduiria el rendiment d'escriptura en un ordre de magnitud i faria inviable l'aplicació. Per això entre regions es replica de manera asíncrona, acceptant una petita finestra de possible pèrdua de dades.

Solució 2

Escenari A: mx-central-1 (Mèxic) o, si no, us-east-1/us-west-2.

• Latència: una regió a Mèxic o al sud dels EUA és molt més a prop dels clients mexicans que qualsevol regió europea (que estaria a més de 150 ms).
• Compliment i residència de la dada: les dades de clients mexicans queden a la seva jurisdicció i, en no barrejar-se amb les europees, no es crea una transferència internacional innecessària.
• Disponibilitat de serveis: cal verificar que la regió triada ofereixi tots els serveis de l'arquitectura; si hi falten peces, una regió estatunidenca consolidada amb bona latència cap a Mèxic és l'alternativa raonable.
• Preu: sa-east-1 (São Paulo) quedaria descartada per ser notablement més cara i no aportar cap avantatge de latència respecte a les opcions nord-americanes.

Escenari B: eu-north-1 (Estocolm).

• Preu: habitualment és de les regions més econòmiques d'Europa, i el cost és el criteri dominant de l'enunciat.
• Latència: irrellevant, perquè és un procés per lots nocturn sense usuaris interactius.
• Compliment: és a la UE i, a més, les dades ja estan anonimitzades, amb la qual cosa el requisit és doblement folgat.
• Disponibilitat de serveis: cal comprovar que ofereix els serveis d'anàlisi necessaris; si en faltés algun, eu-west-1 seria l'alternativa per molt poca diferència de preu.

Un matís: si aquestes dades s'han de moure des d'eu-west-1, el cost de transferència entre regions podria anul·lar l'estalvi. Caldria calcular-ho abans de decidir.

Solució 3

1. Dimarts a les 10:00 (200 comandes/hora). L'ALB detecta que la instància d'1a no respon i deixa d'enviar-li trànsit en segons. RDS commuta la primària a eu-west-1b en 1-2 minuts, sense pèrdua de dades, i l'endpoint de connexió no canvia. La instància d'1b pot amb les 200 comandes/hora (el seu límit és 600). Les fotos a S3 no es veuen afectades. Impacte per al client: un o dos minuts d'errors en operacions d'escriptura, i després servei normal.

2. Divendres a les 19:00 (900 comandes/hora). El mateix tall d'1-2 minuts per la commutació de RDS, però després queda una sola instància amb capacitat per a 600 comandes/hora davant d'una demanda de 900. El sistema queda saturat: cues, temps de resposta alts i errors. Es perden aproximadament un terç de les comandes durant tot l'incident. El disseny evita la caiguda total, però no la degradació greu, perquè no està dimensionat per a N-1.

3. Dos canvis possibles:

   • Opció A: tres instàncies fixes (una a 1a, una a 1b i una tercera repartida), de manera que en perdre una AZ quedin 2 × 600 = 1 200 comandes/hora de capacitat, suficient per al pic de 900. Cost: una instància més encesa 24/7 tot el mes.
   • Opció B: grup d'escalat automàtic repartit en les dues AZ, amb mínim 2 instàncies i màxim 4, que escali per CPU o per nombre de peticions. En el pic del divendres hi hauria 3 o 4 instàncies; en caure una AZ, el grup llança reemplaçaments a l'AZ sana.

   Preferible: l'opció B per cost. Només es paga capacitat extra durant les hores del pic (unes poques al dia) en lloc de mantenir una instància addicional les 730 hores del mes, i a més reacciona automàticament a pics no previstos. L'únic inconvenient és el temps d'arrencada de les instàncies noves, que es mitiga amb una imatge preparada i amb un llindar d'escalat prou anticipat. L'escalat automàtic es tracta al mòdul 2 i el balanceig al 3.

Ja saps com està construït AWS per dins i, sobretot, per què aquesta estructura importa per a la teva arquitectura. Has vist les tres capes —regions, zones de disponibilitat i xarxa de vora—, la nomenclatura eu-west-1, l'aïllament entre regions que sosté el compliment de l'RGPD, i què és realment una AZ: instal·lacions amb energia, refrigeració i xarxa independents, separades quilòmetres però unides per fibra a 1-2 ms, que és just el que fa possible la replicació síncrona de bases de dades.

Has après a distingir serveis globals, regionals i zonals —la clau per saber quina redundància et dona AWS de franc i quina has de dissenyar tu—, a raonar l'elecció de regió amb cinc criteris (latència, compliment, catàleg, preu i proximitat), i a estimar el cost del trànsit entre AZ i entre regions. I MercadoFresco ja té la seva decisió presa i documentada: eu-west-1, amb desplegament repartit en dues zones de disponibilitat.

A la lliçó següent, 01-04 «Consola d'administració d'AWS», baixem al terreny: recorrerem la consola amb la qual treballaràs cada dia, aprendrem a no caure en el parany del selector de regió que acabem d'esmentar, veurem com etiquetar i localitzar recursos dispersos amb Tag Editor, i crearàs el teu primer recurs real al compte de MercadoFresco.