Tanquem el Capítol 29 amb un aspecte crucial quan una empresa acumula moltes dades: el govern de dades (data governance). Tenir un data lake (subcapítol 29.1) ple d'informació valuosa està molt bé, però planteja preguntes serioses: qui pot veure quines dades? Com protegeixes la informació sensible? Com controles l'accés de forma centralitzada quan tens dades de tota l'empresa? Per respondre a això, AWS ofereix Lake Formation: un servei per construir, assegurar i governar el teu data lake de forma centralitzada.
El problema: un data lake sense control és un risc
Un data lake reuneix moltes dades de tota l'empresa en un lloc (S3). Això és potent, però també perillós si no controles bé qui accedeix a què:
Al data lake hi ha dades de tot tipus: - Dades públiques (catàleg de productes) - Dades internes (vendes) - Dades SENSIBLES (dades personals de clients, finances...) → NO tothom hauria de poder veure-HO TOT
Sense un bon control d'accés:
- Qualsevol amb accés al llac podria veure dades sensibles que no li corresponen (un risc greu, recorda la privacitat i el compliment del Capítol 23).
- Gestionar els permisos «a mà» sobre milions d'arxius a S3 seria inviable i propens a errors.
- Seria difícil demostrar (a auditors, per normativa) que les dades estan ben protegides.
Necessites una forma centralitzada i fina de governar qui accedeix a quines dades. Això és Lake Formation.
Què és Lake Formation
AWS Lake Formation és un servei que facilita construir, assegurar i governar un data lake de forma centralitzada. La seva funció més destacada és el control d'accés fi i centralitzat a les dades: definir, des d'un sol lloc, qui pot accedir a quines dades (fins al nivell de taules i columnes concretes), de manera senzilla.
Lake Formation (govern centralitzat del data lake): ├── construir el data lake més fàcilment ├── controlar l'accés de forma FINA i centralitzada │ "aquest equip veu la taula de vendes, però NO la columna de dades personals" └── auditar qui accedeix a què
Analogia: Lake Formation és com el sistema de control d'accessos i seguretat d'una gran biblioteca o arxiu nacional. No n'hi ha prou amb tenir tots els documents guardats (això és el data lake); necessites controlar qui pot entrar a quina secció: el públic general accedeix a la sala comuna, els investigadors acreditats als arxius especials, i només personal autoritzat als documents confidencials. Lake Formation és aquest sistema que, des d'un punt central, decideix i vigila qui accedeix a cada part de les teves dades.
Què t'aporta Lake Formation
- Construir el data lake més fàcil
Ajuda a muntar el data lake de manera més senzilla: facilita portar dades, organitzar-les i catalogar-les (treballa juntament amb Glue, subcapítol 29.1). Simplifica els passos de crear el llac.
- Control d'accés fi i centralitzat
Aquesta és la peça estrella. Des de un sol lloc, defineixes qui pot accedir a quines dades, amb molt detall:
Exemples de permisos fins amb Lake Formation:
- "L'equip de màrqueting pot veure la taula de clients,
però NO les columnes d'email i telèfon" (nivell columna)
- "L'equip de finances veu les dades de vendes completes"
- "Els analistes només veuen dades agregades, no individuals"En comptes de gestionar permisos arxiu per arxiu a S3 (un caos), defineixes regles clares a nivell de dades (bases de dades, taules, columnes), de forma centralitzada. Això connecta amb el mínim privilegi que vam veure a IAM (subcapítol 7.2): cadascú accedeix només a les dades que necessita.
- Protegir dades sensibles
Gràcies a aquest control fi, pots protegir la informació sensible (dades personals, financeres) assegurant que només qui ha de pot veure-la, mentre altres accedeixen a la resta. És clau per complir normatives de privacitat.
- Auditoria i compliment
Permet registrar i demostrar qui accedeix a quines dades, la qual cosa és essencial per a auditories i per complir regulacions (enllaça amb el compliment del Capítol 23). Tens una visió central de la seguretat de les teves dades.
Per què importa: del «caos de dades» al «data lake governat»
El gran valor de Lake Formation és convertir un data lake potencialment caòtic i insegur en un de governat: on saps exactament qui accedeix a què, protegeixes el que és sensible i pots demostrar-ho. Sense govern, un data lake ple de dades valuoses és també una bomba de rellotgeria de seguretat i compliment. Amb Lake Formation, és un actiu segur i ben controlat.
Sense govern: data lake = moltes dades + accés descontrolat = RISC Amb Lake Formation: data lake = moltes dades + accés controlat = ACTIU SEGUR
Exemple del món real: una empresa de salut té un data lake amb dades de pacients (molt sensibles), dades operatives i dades públiques. Usen Lake Formation per governar-lo. Defineixen, de forma centralitzada: els investigadors accedeixen a dades anonimitzades i agregades (sense veure identitats), el personal mèdic autoritzat accedeix a les dades completes dels seus pacients, i l'equip de màrqueting només accedeix a dades públiques. Les columnes amb dades personals identificables estan protegides i només visibles per a qui té autorització explícita. Quan arriba una auditoria de protecció de dades, l'empresa demostra fàcilment qui accedeix a què. El que sense govern seria un risc legal enorme, amb Lake Formation és un sistema controlat, segur i conforme a la normativa.
Com tanca el Capítol 29
Lake Formation completa la plataforma de dades que hem construït en aquest capítol:
S3 + Glue + Athena (29.1) → guardar i consultar el data lake Kinesis (29.2) → ingerir dades en temps real Redshift (29.3) → analítica ràpida a gran escala (data warehouse) Lake Formation (aquest) → GOVERNAR i ASSEGURAR tot (qui accedeix a què)
Les primeres peces construeixen i exploten les dades; Lake Formation s'assegura que tot això sigui segur, controlat i conforme. Una plataforma de dades completa necessita les dues coses: capacitat i govern.
El que has de recordar
- Un data lake reuneix moltes dades (incloses sensibles) de tota l'empresa; sense control d'accés, és un risc greu de seguretat i compliment, i gestionar permisos «a mà» sobre milions d'arxius és inviable.
- AWS Lake Formation facilita construir, assegurar i governar un data lake de forma centralitzada. Com el sistema de control d'accessos d'un gran arxiu.
- La seva peça estrella és el control d'accés fi i centralitzat: defineixes des d'un sol lloc qui accedeix a quines dades, fins a nivell de taules i columnes (en línia amb el mínim privilegi d'IAM), en comptes de gestionar arxius solts a S3.
- Aporta: construir el llac més fàcil, protegir dades sensibles (clau per a la privacitat) i auditoria/complement (demostrar qui accedeix a què).
- Converteix un data lake caòtic i insegur en un de governat i segur: la diferència entre un risc i un actiu. Capacitat (29.1-29.3) més govern (Lake Formation) = plataforma de dades completa.
Has completat el Capítol 29 i domines les plataformes de dades a AWS: data lakes, streaming, data warehouse i govern de dades! Al Capítol 30 tornarem al terreny de l'organització a gran escala: com estructurar múltiples comptes i landing zones per a empreses grans.
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
