En aquest subcapítol veiem dues funcions d’EC2 que resolen problemes concrets: les Elastic IPs (per tenir una adreça IP fixa) i els Placement Groups (per controlar on es col·loquen físicament les teves instàncies). La primera la faràs servir molt aviat; la segona és per a casos més especialitzats, però convé conèixer-la.

El problema de les IPs canviants

Cada instància EC2 té adreces IP per comunicar-se per la xarxa:

  • IP privada: per parlar amb altres recursos dins la teva xarxa (VPC). Es manté mentre l’instància existeixi.
  • IP pública: perquè internet hi pugui accedir. Aquí hi ha el problema: per defecte, aquesta IP pública canvia cada cop que pares i arranques la instància.

Per què és un problema: Imagina que apuntes el nom de la teva web (miweb.com) a la IP pública 54.12.34.56. Pares la instància a la nit per estalviar (subcapítol 4.3) i, en arrencar-la al matí, AWS li dóna una altra IP, per exemple 54.99.88.77. Ara la teva web «no funciona» perquè el nom segueix apuntant a la IP antiga.

La solució: Elastic IP

Una Elastic IP (EIP) és una adreça IP pública fixa que tu reserves i pots associar a una instància. A diferència de la IP pública normal, no canvia, encara que paris i arranquis la instància.

Analogia: Una IP pública normal és com un número de telèfon que et reassignen cada vegada. Una Elastic IP és com comprar el teu propi número fix: és teu i sempre et localitzen en ell.

Avantatges d’una Elastic IP:

  • És constant: ideal per apuntar noms de domini.
  • Pots moure-la d’una instància a una altra. Si una instància falla, associes l’EIP a una de recanvi i el trànsit segueix arribant al mateix lloc. Això és útil per a failover.

⚠️ Detall de costos (important): AWS et cobra per les Elastic IPs que reserves però NO utilitzes (les que no estan associades a una instància en execució). La lògica: les adreces IPv4 són un recurs escàs, així que AWS penalitza acaparar-les sense fer-les servir. Allibera les Elastic IPs que no necessitis per no pagar de més. Des de 2024, AWS també cobra per les IPv4 públiques en general, així que fes-les servir amb seny.

Nota moderna: En arquitectures actuals, moltes vegades no s’utilitzen Elastic IPs directament. En el seu lloc es posa un balancejador de càrrega (Capítol 13) o CloudFront (Capítol 16) al davant, que ofereixen un punt d’entrada estable sense lligar una IP a una instància concreta. Tot i així, has de conèixer les EIP perquè segueixen sent útils en molts casos.

Placement Groups: controlar la col·locació física

Per defecte, AWS decideix on col·locar físicament les teves instàncies dins d’un datacenter. Normalment això està bé. Però a vegades vols influir en aquesta col·locació per motius de rendiment o resiliència. Per això existeixen els Placement Groups (grups de col·locació).

Hi ha tres estratègies, i cadascuna resol una necessitat diferent:

  1. Cluster (agrupades) — màxim rendiment

Col·loca les instàncies molt juntes, al mateix lloc físic, perquè es comuniquin entre elles amb la menor latència i el major ample de banda possibles.

  • Per a què: aplicacions que requereixen comunicació ultraràpida entre instàncies (computació d’alt rendiment, big data, càlculs científics).
  • Risc: en estar totes juntes, una fallada física podria afectar-les alhora. Menys resiliència a canvi de més velocitat.

  1. Spread (separades) — màxima resiliència

Col·loca cada instància en maquinari físic diferent, el més separades possible.

  • Per a què: aplicacions crítiques on no vols que dues instàncies comparteixin el mateix punt de fallada. Si un servidor físic mor, només cau una instància.
  • Exemple: els pocs servidors que sostenen un sistema crític, on perdre dos alhora seria inacceptable.

  1. Partition (per particions) — equilibri a gran escala

Divideix les instàncies en grups (particions), cadascun en maquinari separat. Les instàncies d’una partició comparteixen infraestructura, però les particions entre si estan aïllades.

  • Per a què: sistemes distribuïts grans (com bases de dades tipus Hadoop, Cassandra, Kafka) que ja gestionen rèpliques i volen controlar quins grups poden fallar junts.

Comparativa ràpida

Estratègia Col·loca les instàncies… Prioritza Cas d’ús
Cluster Molt juntes Rendiment/latència HPC, big data
Spread Molt separades Resiliència Poques instàncies crítiques
Partition En grups aïllats Equilibri a escala Sistemes distribuïts grans

No et preocupis si els Placement Groups et semblen avançats: ho són. La majoria de projectes no els necessiten al principi. L’important ara és saber que existeixen i per a què serveix cada estratègia.

El que has de recordar

  • La IP pública normal d’una instància canvia en parar/arrencar; això trenca els dominis que apuntin a ella.
  • Una Elastic IP és una IP pública fixa que reserves i pots moure entre instàncies (útil per a failover).
  • Compte amb els costos: AWS cobra per les Elastic IPs reservades i no utilitzades. Allibera les que no necessitis.
  • En arquitectures modernes, un balancejador de càrrega o CloudFront sol substituir l’Elastic IP com a punt d’entrada estable.
  • Els Placement Groups controlen la col·locació física: Cluster (rendiment), Spread (resiliència) i Partition (equilibri a escala). Són per a casos avançats.

A l’últim subcapítol d’EC2 veurem una cosa que afecta directament la teva factura: els models de compra (On-Demand, Reserved, Savings Plans i Spot) i quan utilitzar cadascun.

Cloud, AWS & Terraform — De zero a expert

Capítol 1 · Què és el cloud computing

Capítol 2 · El mercat cloud i els grans proveïdors

Capítol 3 · Regions, zones de disponibilitat i edge

Capítol 4 · Càlcul: EC2

Capítol 5 · Emmagatzematge: S3

Capítol 6 · Xarxes: VPC

Capítol 7 · Identitat i accés: IAM

Capítol 8 · Bases de dades gestionades

Capítol 9 · Per què Infraestructura com a Codi

Capítol 10 · HCL: el llenguatge de Terraform

Capítol 11 · Providers i estat

Capítol 12 · La teva primera infraestructura real amb Terraform

Capítol 13 · Balanceig de càrrega i autoescalat

Capítol 14 · Serverless amb Lambda

Capítol 15 · Missatgeria i esdeveniments

Capítol 16 · Lliurament de contingut i DNS

Capítol 17 · Contenidors a AWS

Capítol 18 · Mòduls: reutilització i composició

Capítol 19 · Workspaces i gestió d'entorns

Capítol 20 · Backends remots i locking

Capítol 21 · Testing d'infraestructura

Capítol 22 · Terraform en CI/CD

Capítol 23 · Seguretat en profunditat

Capítol 24 · Observabilitat: logs, mètriques i traces

Capítol 25 · Optimització de costos

Capítol 26 · Alta disponibilitat i disaster recovery

Capítol 27 · Well-Architected Framework d'AWS

Capítol 28 · Arquitectures serverless a escala

Capítol 29 · Plataformes de dades a AWS

Capítol 30 · Multi-compte i landing zones

Capítol 31 · Platform Engineering i Internal Developer Platform

Capítol 32 · Certificacions AWS rellevants

Capítol 33 · Projectes per consolidar el que s'ha après

Capítol 34 · Recursos i comunitat

© Copyright 2024. Tots els drets reservats