Salta el contingut

U3 - 🔐 Xarxes virtuals i serveis de còmput

🎯 RA's vinculats: RA2, RA3

VPC i subxarxes: concepte i desplegament bàsic

Repàs de xarxes

Aquesta unitat dona per assolits els coneixements respecte a xarxes, subxarxes i direccionament. Pots trobar un repàs ací.

Què és una VPC (Virtual Private Cloud)

En AWS, una VPC és una xarxa virtual aïllada dins del núvol on pots definir rangs d’adreces IP, subxarxes, rutes i policies de seguretat. És l’equivalent d’un centre de dades virtual, però amb la flexibilitat d’escala, integració i gestió que ofereix el núvol.

Les VPC serveixen per:

  • Aïllar recursos (servidors, bases de dades, serveis) en capes segons les necessitats de seguretat i accés.

  • Controlar el tràfic entre recursos i vers l’Internet.

  • Aplicar polítiques de seguretat (SG, NACL) a nivell de màquina o de subxarxa.

Subxarxes (Subnets)

Una vegada definida una VPC amb un rang CIDR (per exemple 10.0.0.0/16), aquesta es pot subdividir en subxarxes (subnets).

  • Subxarxa pública: aquella que està associada a una ruta que passa per un Internet Gateway, de manera que les instàncies amb IP pública poden comunicar-se amb Internet.

  • Subxarxa privada: no té ruta directa a Internet (o només surt via un NAT / instància NAT) i és ideal per recursos que no han d’estar exposats públicament, com aplicacions, lògica de backend o bases de dades.

Cal decidir quantes subxarxes i quins rangs reservar per a cada funció (web, app, base de dades, etc.).

Internet Gateway (IGW) i rutes

Un Internet Gateway (IGW) és un component que es connecta a la VPC i permet que les instàncies dins de subxarxes públiques facen tràfic cap a Internet (i reben tràfic, si tenen IP pública). Sense un Internet Gateway, les VPC's no tenen accés a Internet.

VPC default

La VPC que ve per defecte en AWS sí que ens permet accés a internet perquè ja te un IGW adjunt, no hem hagut de crear-lo explicitament però sí que està.

Els IGW van associats als VPC per possibilitar-los la comunicació a internet (que els permeta no vol dir que ho tinguen, cal habilitar-ho també a les instàncies.)

u3_4

Per poder fer-ho, cada subxarxa d'AWS té associada una Route table que determinen com trauen el tràfic. Molt similar a l'enrutament que coneguem del curs passat.

Les taules de rutes (route tables) defineixen quin “destí” (CIDR) es dirigeix a quin “objectiu” (porta de sortida):

  • Exemple: la subxarxa pública tindrà una ruta 0.0.0.0/0 → IGW (apareixerà com a igw-xxx) per enviar tot el tràfic no local a Internet.

  • La subxarxa privada pot tenir només rutes internes (cap a altres subnets).

Pràctica sugerida

En aquest punt dels continguts, es recomana fer la pràctica 1 de la unitat 3.

IP elàstica (Elastic IP)

Una Elastic IP (EIP) és una adreça IP pública estàtica assignada a la teua compte d’AWS. A diferència de les IP públiques normals que s’assignen automàticament a les instàncies EC2 (i que canvien cada vegada que les pares o elimines), una IP elàstica es manté constant fins que tu l'alliberes manualment.

Per què són útils?

Les IP elàstiques resulten molt útils quan vols:

  • Tindre una IP pública fixa per a una instància o servei.

  • Substituir una instància sense canviar la seua adreça pública (pots desassociar-la d’una instància i associar-la a una altra).

  • Associar-la a una NAT Gateway, ja que aquesta necessita una IP pública estàtica per a eixir a Internet.

Això permet mantindre la connectivitat externa estable, per exemple si tens un domini, una API o un servei que depén d’una IP concreta.

Funcionament bàsic

Quan crees una Elastic IP:

  • AWS te n’assigna una i la reserva per al teu compte.

  • Pots associar-la a una instància EC2, a una NAT Gateway o a altres serveis.

  • Aquesta adreça es manté associada fins que la desassocies o l'alliberes.

IMPORTANT 🤑

La IP elàstica consumix diners soles pel fet d'existir, encara que no estiga associada a cap recurs.

Tipus d’adreça Canvia al reiniciar EC2 Es pot reassignar Cost si està inactiva
IP pública automàtica ✅ Sí ❌ No ❌ No
Elastic IP ❌ No ✅ Sí ✅ Sí (si està lliure)

Creació i assignació d'una IP Elàstica

  • Podem crear la IP elàstica tant des de EC2 com des de VPC. Alhora, també es pot crear la IP elàstica durant la creació de certs servicis com la NAT Gateway que s'estudia més endavant.
  • Seleccionarem l'opció Allocate Elastic IP i deixarem tot per defecte i li donarem a crear

  • Una vegada creada, es pot assignar a recursos com el EC2, per exemple.

    • Desde la secció de les IP elàstiques, seleccionem la IP que volem assignar
    • Actions->Associate Elastic IP Address

    u3_5

    • Seleccionem la instància o la interfície de xarxa a la que li volem assignar la IP
    • Deixem l'adreça privada que ve per defecte.
    • Si volem que després puga ser reassociada a altre recurs, marquem l'opció.
    • Guardem els canvis.

    u3_6

    NAT Gateway (Network Address Translation)

Una NAT Gateway és un component que permet que les instàncies dins de subxarxes privades puguen accedir a Internet, però sense que aquestes instàncies siguen accessibles des de fora. Això és molt útil quan volem que un servidor de la subxarxa privada descarregue actualitzacions, paquets o programes (per exemple, instal·lar MySQL), però sense exposar-lo directament a Internet amb una IP pública.

Diferència amb l’Internet Gateway

  • Internet Gateway (IGW): dona accés a Internet a subxarxes públiques (si les instàncies tenen IP pública).

  • NAT Gateway: dona accés a Internet a subxarxes privades, però de forma unidireccional (les instàncies poden eixir a Internet, però Internet no pot iniciar connexions cap a elles).

Funcionament bàsic

La NAT Gateway s’ubica dins d’una subxarxa pública i utilitza una Elastic IP per identificar-se davant d’Internet. Les instàncies de la subxarxa privada, quan volen eixir a Internet, redirigeixen el tràfic cap a la NAT Gateway. Aquesta fa la traducció i envia el tràfic cap a fora a través de l’IGW.

D’aquesta manera:

  • Les instàncies de la subxarxa privada tenen connexió a Internet.

  • No necessiten IP pública pròpia.

  • No són accessibles des de l’exterior, millorant la seguretat.

u3_3

Taules de rutes i NAT Gateway

Igual que amb l’IGW, les route tables són fonamentals:

  • La subxarxa pública tindrà una ruta 0.0.0.0/0 → IGW (com ja hem vist).

  • La subxarxa privada tindrà una ruta 0.0.0.0/0 → NAT Gateway (apareixerà com a nat-xxx).

Amb aquesta configuració, el tràfic cap a Internet des de la subxarxa privada no ix directament, sinó que passa primer per la NAT Gateway, que ja està en una subxarxa pública amb connexió a l’IGW.

Exemple pràctic

  • EC2 de la subxarxa privada vol instal·lar MySQL:

  • Fa la petició a Internet.

  • La ruta 0.0.0.0/0 la redirigeix a la NAT Gateway.

  • La NAT Gateway envia la petició cap a Internet a través de l’IGW.

  • La resposta torna per la mateixa via, però l’EC2 privat mai ha quedat exposat.

Pràctica sugerida

En aquest punt dels continguts, es recomana fer la pràctica 2 de la unitat 3.

Curs AWS Academy Cloud Foundations

Una vegada feta les pràctica 2 s'ha de realitzar el mòdul 5 fins al laboratori 2 (Redes y entrega de contenido) del curs d' AWS Academy Cloud Foundations.

Grups de seguretat (SG) i NACL's

Security Groups (Grups de Seguretat)

Els grups de seguretat ja s'estudiaren en la unitat 2. Un xicotet repàs:

  • Funcionen com un tallafoc virtual a nivell de instància.

  • Stateful: si es permet una connexió entrant, la resposta està implícita per a la connexió sortint.

  • Es defineixen regles d’entrada (inbound) i regles de sortida (outbound).

  • No hi ha ordre de prioritat: es combinen totes les regles per determinar si un paquet és permès o no.

  • Exemples típics: permetre SSH (port 22) només des d’adreça IP fixa, permetre HTTP (port 80 / 443) des de qualsevol lloc.

Network Access Control Lists (NACLs)

Les NACLs actuen a nivell de subxarxa, no d’instància, i són stateless. Açò significa que cal configurar tant les regles d’entrada com les de sortida de manera explícita. A més, les regles tenen un número de prioritat i s’apliquen en ordre.

Les NACLs permeten tindre un control més fi i, sobretot, aplicar polítiques generals a tota una subxarxa. Per exemple, podries bloquejar tot el tràfic ICMP (ping) cap a les subxarxes públiques.

Els NACL's permeten fer bloqueig explícit d'una IP mentre que el SG no ho permet.

Característica Security Groups (SG) Network ACLs (NACLs)
Nivell d'aplicació S'apliquen a instàncies (nivell de NIC/ENI) S'apliquen a subxarxes senceres
Tipus de filtre Stateful: si es permet l'entrada, la resposta ix automàticament Stateless: cada regla d'entrada i eixida s'ha de definir explícitament
Regles per defecte Tot el tràfic denegat fins que s'afegeixen regles Tot permés per defecte, però es pot denegar
Direccionalitat Inbound i Outbound Inbound i Outbound (independents)
Prioritat No hi ha ordre: totes les regles s'avaluen conjuntament Les regles es processen en ordre numèric (de menor a major)
Granularitat típica Més precís: es pot aplicar a grup d'instàncies (p.ex. SG-Web, SG-DB) Més global: afecta totes les instàncies dins la subnet
Flexibilitat Fàcil de reusar: pots assignar el mateix SG a moltes instàncies Menys flexible: una subnet només pot tindre un NACL actiu
Casos d'ús típics Definir accessos de serveis (ex. Web 80/443, SSH restringit) “Capa extra” de seguretat: bloquejar IPs concretes, filtres generals de subnet
Exemple pràctic Permetre SSH (22) només des de 203.0.113.5 Denegar tràfic d'una IP sospitosa a tota la subnet

Defensa en capes (Defense in depth)

El més recomanable és utilitzar ambdós mecanismes: SG per protegir cada instància i NACL per filtrar a nivell de subxarxa. D’aquesta manera, si una capa falla, encara tens l’altra.

u3_1

Exemple pràctic d'ús conjunt de SG i NACL's:
Arquitectura de 3 capes (Web — App — DB)

  • Capa Web (subxarxa pública)

    • SG-Web: permet només HTTP/HTTPS (80, 443) des de qualsevol lloc, i SSH només des d’una IP concreta del professor/admin.
    • NACL pública: denega tràfic de certes IPs sospitoses/blocs de països, independentment de SG.

  • Capa App (subxarxa privada)

    • SG-App: permet tràfic només des de SG-Web al port 8080 (comunicació web → app).
    • NACL privada (app): denega qualsevol tràfic entrant que no vinga de la subnet pública legítima.

  • Capa DB (subxarxa privada)

    • SG-DB: només permet MySQL (3306) des de SG-App.
    • NACL privada (db): segona capa que bloqueja qualsevol cosa que no siga 3306 des de la subnet app.

Exercici sugerit

Dibuixa com seria aquesta infraestructura. Per fer-ho, pots gastar draw.io.

Pràctica sugerida

En aquest punt dels continguts, es recomana fer la pràctica 3 i 4 de la unitat 3.

Entregable

En aquest punt es recomana realitzar l'exercici 1 de l'entregable d'aquesta unitat disponile a Aules.

Introducció a AWS Lambda

Lambda és la porta d’entrada al món serverless: en lloc de pensar en servidors que cal encendre, configurar i mantenir, definim funcions petites —trossets de codi— que s’executen en resposta a esdeveniments. Aquest model és molt potent per a tasques curtes i puntuals: processar una imatge quan s’ha pujat a un bucket, respondre una crida HTTP lleugera, o executar treballs programats.

A diferència d’una màquina virtual (EC2), Lambda s’encarrega automàticament de l’escalat, de la gestió de la infraestructura i del pagament per ús. Això simplifica molt el treball del desenvolupador, però també obliga a pensar de manera diferent: la lògica ha de ser eficient, les funcions són efímeres i hi ha limitacions en temps d’execució i recursos (per això cal dividir problemes en tasques petites i responsabilitats clares).

u3_2

Què és Lambda i per a què serveix

Lambda permet executar codi en resposta a events (esdeveniments). Un esdeveniment pot ser, per exemple:

  • La pujada d’un fitxer a S3

  • La crida d’una API mitjançant API Gateway

  • Un esdeveniment programat (cron) amb EventBridge

  • Una notificació des d’un altre servei.

Els punts forts de Lambda són clars: no cal gestionar servidors, escales de forma automàtica, pagues només pel temps d’execució i integres fàcilment amb molts serveis AWS. Això el fa ideal per a microtasques, processament asincrònic, pipelines de dades lleugeres i lògica de backend puntual.

També cal conèixer algunes característiques que condicionen el disseny:

  • Les funcions són estateless (l’estat no es garanteix entre invocacions; si necessites estat, utilitza S3, DynamoDB, RDS, etc.);

  • El temps d’execució és limitat (pensa les funcions com a tasques curtes);

  • Hi ha consideracions de cold start (la primera invocació pot tardar una mica més, especialment amb runtimes grans o si utilitzes arquitectura ARM vs x86).

Integracions habituals

Lambda s’integra amb molts serveis. Els més rellevants per a nosaltres (visió bàsica):

  • S3 — Lambda pot ser cridat quan es puja un objecte a un bucket (útil per processar imatges, generar miniatures, indexar fitxers).

  • API Gateway — Serveix per exposar una funció Lambda com a endpoint HTTP/REST o HTTP API (per crear APIs sense servidor).

  • EventBridg — Per executar funcions en horaris programats o en reacció a esdeveniments del sistema.

  • CloudWatch — Guardarà els logs de la funció i pot activar alarmes si cal.

No aprofundirem ara en totes aquestes integracions; l’objectiu és entendre el concepte i veure’n un cas pràctic senzill.

Seguretat: rol d’execució

Quan Lambda necessita accedir a altres serveis (per exemple, escriure en CloudWatch Logs, llegir d’un bucket S3, accedir a Secrets Manager), ho fa en nom seu mitjançant un rol d’execució (execution role). Aquest rol és una identitat IAM que atorga permisos perquè la funció puga fer accions concretes.

Rol laboratori

Com que AWS Academy no ens permet crear nous rols IAM, gastarem els que du per defecte el laboratori.

Pràctica sugerida

En aquest punt dels continguts, es recomana fer la pràctica 5 de la unitat 3.

Curs AWS Academy Cloud Foundations

Una vegada feta les pràctica 5 s'ha de realitzar la secció 7 i l'activitat que la segueix del mòdul 6 (Informàtica) del curs d' AWS Academy Cloud Foundations.