Ja tens subxarxes i portes a internet. Però falta el que dirigeix el trànsit per la teva xarxa i el que el filtra a nivell de subxarxa. Aquests són les Route Tables (taules de rutes) i les Network ACLs. Són els components que fan que «públic» i «privat» signifiquin alguna cosa de veritat.

Route Tables: el GPS de la teva xarxa

Una Route Table (taula de rutes) és un conjunt de regles que decideixen cap a on va el trànsit segons el seu destí. Cada subxarxa està associada a una taula de rutes, que li diu: «si el trànsit va a tal lloc, envia'l per aquí».

Analogia: Una taula de rutes és com els senyals de trànsit i el GPS de la teva parcel·la. A cada cruïlla indiquen: «per anar al carrer X, gira aquí; per sortir a l'autopista (internet), segueix recte fins a la porta principal».

Com es veu una taula de rutes

Cada regla (ruta) diu: «el trànsit cap a aquest destí va per aquest camí (target)». Exemple d'una taula per a una subxarxa pública:

Destí Camí (target) Significa
10.0.0.0/16 local «El trànsit dins de la meva VPC es queda a la xarxa local»
0.0.0.0/0 Internet Gateway «Tot la resta (internet) surt per la porta principal»

I una taula per a una subxarxa privada:

Destí Camí (target) Significa
10.0.0.0/16 local «El trànsit dins de la meva VPC es queda local»
0.0.0.0/0 NAT Gateway «Per sortir a internet, faig servir el NAT (només sortida)»

Veus la diferència? El que converteix una subxarxa en pública o privada és precisament aquesta taula:

  • Si la ruta a 0.0.0.0/0 (tot internet) apunta a l'Internet Gateway → subxarxa pública.
  • Si apunta al NAT Gateway (o no existeix) → subxarxa privada.

Aquest és el «secret» de les subxarxes: una subxarxa no té una etiqueta màgica de «pública» o «privada». És pública o privada segons a on la mani la seva taula de rutes. La regla 0.0.0.0/0 → Internet Gateway és la que la fa pública.

La ruta local està sempre present i no es pot esborrar: garanteix que tots els recursos dins de la mateixa VPC poden comunicar-se entre ells.

Network ACLs: el firewall de la subxarxa

Ara el filtratge. Ja coneixes els Security Groups del Capítol 4 (el firewall de cada instància). Les Network ACLs (NACLs) són un altre firewall, però a nivell de subxarxa sencera, no d'instància individual.

Analogia: Si el Security Group és el porter de cada edifici (controla qui entra a cada instància), la Network ACL és el control d'accés de tot el barri (controla quin trànsit entra i surt de tota la subxarxa).

El trànsit que arriba a una instància passa dos controls:

  1. Primer la Network ACL de la subxarxa (el control del barri).
  2. Després el Security Group de la instància (el porter de l'edifici).

Security Group vs Network ACL: les diferències

Aquesta és una comparació clàssica que convé tenir clara:

Característica Security Group Network ACL
Nivell Instància Subxarxa
Regles Només «permetre» (allow) «Permetre» i «denegar» (allow/deny)
Estat Stateful (amb estat) Stateless (sense estat)
Avaluació Totes les regles alhora Per ordre numèric, s'atura a la primera coincidència
Per defecte Bloca tot el que no està permès La per defecte permet tot

Aclarim els dos conceptes que més confonen:

Stateful vs Stateless

  • Security Group (stateful): si permets una connexió d'entrada, la resposta de sortida es permet automàticament. «Recorda» la connexió. No has de crear una regla per a la resposta.
  • Network ACL (stateless): no recorda res. Si permets el trànsit d'entrada, has de permetre explícitament també el de sortida perquè la resposta pugui tornar. Cada direcció es configura per separat.

Per això les NACLs són més primmirades: un error típic és permetre l'entrada però oblidar permetre la sortida de resposta, i llavors «res funciona» encara que la regla d'entrada sembli correcta.

Allow i Deny

  • Els Security Groups només permeten llistes blanques (defineixes el que es permet; la resta es bloca). No pots escriure una regla «denegar».
  • Les Network ACLs permeten també regles de denegació explícita. Això és útil, per exemple, per blocar una IP concreta que t'està atacant, cosa que un Security Group no pot fer.

Quin faig servir? A la pràctica

Per a la majoria de casos:

Fes servir els Security Groups com la teva eina principal de seguretat de xarxa. Són més simples (stateful) i suficients per a gairebé tot. Deixa les Network ACLs amb la seva configuració per defecte (que permet tot) excepte que necessitis alguna cosa específica, com blocar una IP maliciosa a nivell de subxarxa.

Les NACLs són una capa addicional de defensa en profunditat, no la teva primera línia. Molts equips les fan servir poc i es recolzen en els Security Groups.

Com encaixa tot

Internet
   │
   ▼
[Network ACL de la subxarxa]   ← 1r filtre (nivell barri, stateless, allow/deny)
   │
   ▼
[Security Group de la instància]  ← 2n filtre (nivell edifici, stateful, només allow)
   │
   ▼
[La teva instància EC2]

   I les Route Tables decideixen PER ON va cada trànsit
   (a internet via IGW, via NAT, o local dins de la VPC).

El que has de recordar

  • Les Route Tables decideixen cap a on va el trànsit segons el seu destí. La ruta 0.0.0.0/0 cap a l'Internet Gateway és el que fa pública una subxarxa; cap al NAT (o absent), la fa privada.
  • Les Network ACLs són un firewall a nivell de subxarxa: stateless (configures entrada i sortida per separat) i permeten regles de denegació (útils per blocar IPs).
  • Els Security Groups són el firewall a nivell d'instància: stateful i només de tipus «permetre». Són la teva eina principal.
  • Fes servir Security Groups com a base; afegeix Network ACLs només per a necessitats concretes (defensa en profunditat).

A l'últim subcapítol de VPC veurem com connectar la teva VPC amb altres xarxes: VPC Peering (unir VPCs) i endpoints (arribar a serveis d'AWS de forma privada).

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