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:
- Primer la Network ACL de la subxarxa (el control del barri).
- 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/0cap 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
- 1.1 El model client-servidor tradicional
- 1.2 Problemes que venia a resoldre el núvol
- 1.3 On-premise vs cloud vs híbrid
- 1.4 Els tres models de servei: IaaS, PaaS, SaaS
- 1.5 Els cinc pilars del cloud (segons NIST)
- 1.6 Avantatges reals: elasticitat, pagament per ús, disponibilitat global
Capítol 2 · El mercat cloud i els grans proveïdors
- 2.1 AWS, Azure i GCP: diferències i quotes de mercat
- 2.2 Per què aprendre AWS primer
- 2.3 Conceptes que són universals entre proveïdors
Capítol 3 · Regions, zones de disponibilitat i edge
- 3.1 Què és una regió AWS i com triar-la
- 3.2 Availability Zones: alta disponibilitat des del disseny
- 3.3 Edge locations i CloudFront
- 3.4 Latència, resiliència i sobirania de dades
Capítol 4 · Càlcul: EC2
- 4.1 Instàncies: tipus, famílies i quan triar cadascuna
- 4.2 AMIs, key pairs i Security Groups
- 4.3 Cicle de vida d'una instància
- 4.4 Elastic IPs i Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítol 5 · Emmagatzematge: S3
- 5.1 Buckets, objectes i claus
- 5.2 Classes d'emmagatzematge (Standard, IA, Glacier…)
- 5.3 Versionat i cicle de vida d'objectes
- 5.4 Polítiques de bucket i ACLs
- 5.5 Hosting de llocs web estàtics
Capítol 6 · Xarxes: VPC
- 6.1 Què és una VPC i per què la necessites
- 6.2 Subxarxes públiques i privades
- 6.3 Internet Gateway i NAT Gateway
- 6.4 Route Tables i Network ACLs
- 6.5 VPC Peering i endpoints
Capítol 7 · Identitat i accés: IAM
- 7.1 Usuaris, grups, rols i polítiques
- 7.2 El principi de mínim privilegi
- 7.3 Polítiques basades en identitat vs en recurs
- 7.4 MFA i credencials temporals (STS)
- 7.5 Bones pràctiques de seguretat IAM
Capítol 8 · Bases de dades gestionades
- 8.1 RDS: motors, Multi-AZ i rèpliques de lectura
- 8.2 Aurora i els seus avantatges sobre RDS vanilla
- 8.3 DynamoDB: model clau-valor / documents
- 8.4 ElastiCache per a memòria cau en memòria
- 8.5 Quan utilitzar cada tipus de base de dades
Capítol 9 · Per què Infraestructura com a Codi
- 9.1 Problemes del provisionament manual
- 9.2 IaC declaratiu vs imperatiu
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El cicle plan → apply → destroy
Capítol 10 · HCL: el llenguatge de Terraform
- 10.1 Blocs resource, variable, output, locals
- 10.2 Tipus de dades: string, number, bool, list, map, object
- 10.3 Expressions, referències i funcions built-in
- 10.4 Condicionals i bucles (count, for_each, for)
Capítol 11 · Providers i estat
- 11.1 Com funciona el provider d'AWS
- 11.2 El fitxer terraform.tfstate i la seva importància
- 11.3 State local vs state remot (S3 + DynamoDB)
- 11.4 Comandes essencials: init, plan, apply, destroy, fmt, validate
Capítol 12 · La teva primera infraestructura real amb Terraform
- 12.1 Crear una VPC amb subxarxes des de zero
- 12.2 Posar en marxa una instància EC2 pública
- 12.3 Associar un Security Group i una Elastic IP
- 12.4 Outputs i referències entre recursos
- 12.5 Flux de treball en equip: PR review de plans
Capítol 13 · Balanceig de càrrega i autoescalat
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners i regles
- 13.3 Auto Scaling Groups: polítiques i mètriques
- 13.4 Warm pools i lifecycle hooks
Capítol 14 · Serverless amb Lambda
- 14.1 El model d'execució de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestió de dependències i capes (Layers)
- 14.4 Cold starts i estratègies per reduir-los
- 14.5 Límits i antipatrones
Capítol 15 · Missatgeria i esdeveniments
- 15.1 SQS: cues estàndard vs FIFO, DLQ
- 15.2 SNS: topics, subscripcions, fan-out
- 15.3 EventBridge: event buses i regles
- 15.4 Patrons: pub/sub, desacoblament, saga
Capítol 16 · Lliurament de contingut i DNS
- 16.1 Route 53: tipus de registres i routing policies
- 16.2 CloudFront: distribucions, memòries cau i origins
- 16.3 ACM: certificats SSL/TLS gratuïts
- 16.4 WAF integrat amb CloudFront
Capítol 17 · Contenidors a AWS
- 17.1 Docker: repàs exprés de conceptes clau
- 17.2 ECR: registre privat d'imatges
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: quan Kubernetes i quan no
Capítol 18 · Mòduls: reutilització i composició
- 18.1 Anatomia d'un mòdul Terraform
- 18.2 Variables d'entrada, outputs i dependències
- 18.3 Mòduls locals vs mòduls del Terraform Registry
- 18.4 Versionat de mòduls amb Git tags
- 18.5 Disseny de mòduls genèrics vs específics de domini
Capítol 19 · Workspaces i gestió d'entorns
- 19.1 Workspaces de Terraform: casos d'ús i limitacions
- 19.2 Estratègia de directoris per entorn (dev/stg/prod)
- 19.3 Terragrunt: DRY per a configuracions d'entorn
- 19.4 Variables d'entorn i fitxers .tfvars
Capítol 20 · Backends remots i locking
- 20.1 Configurar S3 + DynamoDB com a backend
- 20.2 State locking: evitar corrupció en equip
- 20.3 Migració d'estat entre backends
- 20.4 terraform import: portar recursos existents a l'estat
Capítol 21 · Testing d'infraestructura
- 21.1 Terraform validate i fmt en CI
- 21.2 Checkov i tfsec: anàlisi de seguretat estàtica
- 21.3 Terratest: tests d'integració en Go
- 21.4 Contract testing entre mòduls
Capítol 22 · Terraform en CI/CD
- 22.1 Pipeline bàsic: lint → plan → apply a GitHub Actions
- 22.2 Atlantis: GitOps per a Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection i reconciliació automàtica
Capítol 23 · Seguretat en profunditat
- 23.1 AWS Organizations i Service Control Policies
- 23.2 AWS Config: compliment continu
- 23.3 GuardDuty: detecció d'amenaces
- 23.4 Security Hub: visió centralitzada
- 23.5 KMS: gestió de claus i rotació
- 23.6 Secrets Manager vs Parameter Store
Capítol 24 · Observabilitat: logs, mètriques i traces
- 24.1 CloudWatch Logs, mètriques i alarmes
- 24.2 CloudWatch Dashboards i Contributor Insights
- 24.3 X-Ray: traçat distribuït
- 24.4 OpenTelemetry a AWS
- 24.5 Managed Grafana i Managed Prometheus
Capítol 25 · Optimització de costos
- 25.1 AWS Cost Explorer i pressupostos amb alertes
- 25.2 Trusted Advisor i Compute Optimizer
- 25.3 Rightsizing: com detectar sobredimensionament
- 25.4 Savings Plans vs Reserved Instances: decisió estratègica
- 25.5 FinOps: cultura i processos per controlar la despesa
Capítol 26 · Alta disponibilitat i disaster recovery
- 26.1 RTO i RPO: definir els objectius
- 26.2 Estratègies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks i failover automàtic
- 26.4 AWS Backup: política centralitzada de còpies
Capítol 27 · Well-Architected Framework d'AWS
- 27.1 Els sis pilars: excel·lència operacional, seguretat, fiabilitat, eficiència de rendiment, optimització de costos, sostenibilitat
- 27.2 Well-Architected Tool: revisions formals
- 27.3 Com aplicar el framework en decisions de disseny
Capítol 28 · Arquitectures serverless a escala
- 28.1 Event-driven architecture amb Lambda + EventBridge
- 28.2 Saga pattern per a transaccions distribuïdes
- 28.3 Step Functions: orquestració de workflows complexos
- 28.4 Lambda@Edge i CloudFront Functions
Capítol 29 · Plataformes de dades a AWS
- 29.1 Data Lake amb S3, Glue i Athena
- 29.2 Kinesis Data Streams i Firehose per a streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: govern del dada
Capítol 30 · Multi-compte i landing zones
- 30.1 Per què separar workloads en comptes diferents
- 30.2 AWS Control Tower i Account Factory
- 30.3 Gestió centralitzada de logs i seguretat
- 30.4 Terraform a escala multi-compte amb mòduls compartits
Capítol 31 · Platform Engineering i Internal Developer Platform
- 31.1 Golden paths i abstraccions sobre Terraform
- 31.2 Service Catalog d'AWS
- 31.3 Backstage com a portal de desenvolupadors
- 31.4 Mòduls Terraform com a producte intern
Capítol 32 · Certificacions AWS rellevants
- 32.1 Cloud Practitioner: val la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítol 33 · Projectes per consolidar el que s'ha après
- 33.1 Projecte 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Projecte 2: API REST amb ECS Fargate + RDS + ALB
- 33.3 Projecte 3: plataforma de dades amb Glue + Athena + Redshift
- 33.4 Projecte 4: landing zone multi-compte amb Terraform i Control Tower
