Tanquem la Part I unint tot el que has après sobre la geografia d’AWS —regions, zones de disponibilitat i edge locations— sota tres conceptes que guiaran moltíssimes de les teves decisions d’arquitectura: latència, resiliència i sobirania de dades. Són les tres preguntes que et faràs cada cop que dissenyis alguna cosa al núvol.

La latència és el temps que triguen les dades a anar d’un punt a un altre i tornar. Es mesura en mil·lisegons (ms). Com més baixa sigui la latència, més ràpida i fluida es percep la teva aplicació.

La latència depèn molt de la distància física: les dades viatgen ràpid, però no infinitament ràpid. Creuar un oceà sempre afegeix retard.

Exemple: Un usuari a Madrid accedint a un servidor a Madrid pot tenir ~5 ms de latència. El mateix usuari accedint a un servidor a Tòquio pot tenir ~250 ms. Aquesta diferència és perceptible: la web «va a batzegades» amb l’opció llunyana.

Com reduir la latència amb el que has après:

• Tria una regió propera als teus usuaris (subcapítol 3.1).
• Fes servir CloudFront i edge locations per servir contingut des del punt més proper (subcapítol 3.3).

Dada: Per a serveis on cada mil·lisegon compta (videojocs en línia, trading financer, videotrucades), la latència és la prioritat de disseny.

La resiliència és la capacitat del teu sistema de seguir funcionant malgrat les fallades. Com hem vist, al núvol s’assumeix que el maquinari fallarà, així que dissenyem perquè això no tombi el servei.

Com aconseguir resiliència amb el que has après:

La paraula clau aquí és redundància: tenir còpies o components de recanvi repartits, de manera que la caiguda d’un no impliqui la caiguda de tot.

Exemple real: Una passarel·la de pagaments no pot caure mai. La dissenyen multi-AZ per sobreviure a fallades de datacenter, i repliquen dades en una segona regió per si una regió sencera tingués un problema catastròfic. Així garanteixen que els pagaments segueixen funcionant passi el que passi.

Veurem la resiliència en profunditat al Capítol 26 (alta disponibilitat i recuperació davant desastres), amb conceptes com RTO i RPO.

La sobirania de dades es refereix a les lleis i regulacions que determinen on es poden emmagatzemar i processar certes dades, i quines lleis se’ls apliquen segons el país on es troben.

No és un tema tècnic, sinó legal, però condiciona decisions tècniques (quina regió tries).

Exemple real — el RGPD: El Reglament General de Protecció de Dades de la Unió Europea regula com es tracten les dades personals de ciutadans europeus. Moltes empreses, per complir-lo amb tranquil·litat, decideixen emmagatzemar les dades dels seus clients europeus en regions d’AWS dins la UE (Espanya, Irlanda, Frankfurt…).

Altres exemples de requisits de sobirania:

• Dades de sanitat que per llei han de romandre al país.
• Dades d’administracions públiques amb exigències de localització.
• Sectors financers amb normatives estrictes sobre on resideixen les dades.

Com ho gestiones amb el que has après: triant la regió adequada (subcapítol 3.1). Com que les regions estan aïllades i saps exactament en quin país es troba cadascuna, pots garantir que les dades no surten d’on han d’estar.

Quan dissenyis qualsevol sistema a AWS, aquests tres conceptes es tradueixen en tres preguntes:

1. Latència: On són els meus usuaris? → Tria regió propera + CloudFront.
2. Resiliència: Què passa si falla un datacenter o una regió? → Multi-AZ i, si és crític, multi-regió.
3. Sobirania: Hi ha lleis sobre on han d’estar les meves dades? → Tria regió que compleixi la normativa.

A vegades aquestes tres forces entren en tensió i cal equilibrar-les:

Exemple de compromís: Els teus usuaris més ràpids estarien servits des de Virgínia (latència baixa per a Amèrica), però la llei t’obliga a guardar dades europees a la UE (sobirania). Solució típica: allotges les dades a Europa (compleixes la llei) i fas servir CloudFront per accelerar l’entrega globalment (mitigues la latència).

• Latència: temps de resposta; es redueix apropant la regió i usant edge locations/CloudFront.
• Resiliència: capacitat de seguir funcionant davant fallades; s’aconsegueix amb redundància multi-AZ i, si és crític, multi-regió.
• Sobirania de dades: requisits legals sobre on resideixen les dades; es compleix triant la regió adequada.
• Gairebé tota decisió d’arquitectura geogràfica neix d’equilibrar aquestes tres forces.

Amb això tanques la Part I. Ja domines els fonaments conceptuals del núvol. A la Part II deixem la teoria i entrem en la pràctica: els serveis essencials d’AWS, començant pel còmput amb EC2.