En el subcapítol anterior vam veure per què les empreses separen els seus workloads en molts comptes. Però això planteja un repte immediat: si has de tenir desenes o centenars de comptes, com les crees i configures totes amb les mateixes bones pràctiques de seguretat i ordre, sense tornar-te boig fent-ho a mà una per una? Per això existeix AWS Control Tower, que automatitza la creació d’un entorn multi-compte ben configurat (una landing zone), i la seva Account Factory, que fabrica comptes noves amb tot a punt. És com tenir una fàbrica de comptes segures i conformes.
El problema: muntar i mantenir molts comptes a mà és inviable
Configurar un compte d’AWS amb totes les bones pràctiques (seguretat, xarxes, logs, permisos, regles...) ja porta feina. Fer-ho per a desenes o centenars de comptes, i mantenir-les totes coherents en el temps, és un malson si es fa manualment:
A mà, per cada compte nou: - configurar seguretat, xarxes, permisos... - aplicar les regles de l’empresa - connectar els logs centralitzats - assegurar-se que compleix els estàndards → repetir això 100 vegades, sense errors i mantenint-ho al dia = impossible
Necessites automatitzar la creació i configuració de comptes, garantint que totes neixen ben configurades i segueixen les normes. Això és el que fa Control Tower.
Què és una landing zone
Abans de Control Tower, un concepte: una landing zone (zona d’aterratge) és un entorn multi-compte ben dissenyat, segur i a punt per ser usat, que serveix de base sòlida sobre la qual l’empresa desplega les seves aplicacions. És el «ciment» preparat i conforme a bones pràctiques on «aterren» els teus workloads.
Landing zone = la base preparada de la teva organització a AWS: ├── estructura de comptes i OU ben organitzada (Cap. 23.1, 30.1) ├── seguretat i regles (SCP) aplicades ├── logs i auditoria centralitzats └── tot a punt perquè els equips despleguin a sobre amb confiança
Analogia: una landing zone és com la urbanització amb totes les infraestructures ja fetes abans de construir les cases: els carrers, l’aigua, la llum, el clavegueram i les normes de la comunitat ja estan preparats i compleixen la normativa. Quan arriba cada veí (cada equip), només ha de construir la seva casa sobre una base sòlida i ben planificada, sense preocupar-se dels fonaments comuns. Sense la urbanització preparada, cadascú improvisaria les seves pròpies canonades: un caos.
Què és AWS Control Tower
AWS Control Tower és un servei que crea i gestiona automàticament una landing zone amb bones pràctiques: munta l’estructura multi-compte, aplica regles de seguretat, configura els logs i l’auditoria centralitzats, i et dona un panell per governar-ho tot. En comptes de construir la landing zone a mà, Control Tower la munta per tu seguint les millors pràctiques d’AWS.
AWS Control Tower: ├── munta la landing zone automàticament (estructura + seguretat + logs) ├── aplica "guardrails" (barreres de seguretat) a tots els comptes ├── dona un panell central per veure i governar tota l’organització └── inclou l’Account Factory per crear comptes nous fàcilment
Analogia: Control Tower és com el constructor expert que prepara tota la urbanització (la landing zone) seguint les normes, i a més et deixa un sistema per afegir noves parcel·les urbanitzades quan ho necessitis. T’estalvia tota la feina de planificar i construir la base, i s’assegura que compleix els estàndards.
Els guardrails (barreres de seguretat)
Control Tower aplica guardrails: regles de seguretat i compliment que s’imposen als comptes per mantenir-los dins del permès (moltes s’implementen amb SCP, recorda el subcapítol 23.1, i amb Config, subcapítol 23.2). Per exemple, «cap compte pot desactivar els logs» o «només es permet operar en certes regions». Garanteixen que tots els comptes, facin el que facin, respecten unes normes mínimes.
Què és Account Factory
La Account Factory (fàbrica de comptes) és la part de Control Tower que permet crear comptes nous de forma automatitzada i estandarditzada. Quan un equip necessita un compte nou, en comptes de configurar-la a mà, l’Account Factory la fabrica ja configurada amb totes les bones pràctiques, regles i connexions de l’empresa aplicades des del primer moment.
Equip necessita un compte nou
→ Account Factory la crea automàticament, ja amb:
✓ seguretat i guardrails aplicats
✓ connectada als logs centralitzats
✓ seguint els estàndards de l’empresa
→ compte a punt per ser usada en minuts, ben configurada des de l’iniciAnalogia: l’Account Factory és com una cadena de muntatge que produeix comptes «clau en mà». Igual que una fàbrica de cotxes produeix vehicles idèntics i amb tots els controls de qualitat passats, l’Account Factory produeix comptes noves totes igual de ben configurades i conformes, sense que ningú hagi d’assemblar-les a mà. Demanes un compte i surt a punt per ser usada, complint tots els estàndards.
Per què importa: ordre i seguretat a escala des del dia u
El gran valor de Control Tower i l’Account Factory és permetre a les empreses escalar a molts comptes mantenint l’ordre, la seguretat i el compliment, sense esforç manual i sense errors. Cada compte neix ben configurada i l’organització sencera es governa des d’un panell central. Això enllaça directament amb el Well-Architected Framework (Capítol 27): és operar amb excel·lència operativa i seguretat a gran escala.
Sense Control Tower: 100 comptes configurades a mà = caos, errors, inseguretat Amb Control Tower: 100 comptes fabricades iguals i conformes = ordre i seguretat
Exemple del món real: una empresa en creixement sap que passarà de 5 a més de 50 comptes en un any (un equip nou o un projecte nou sol necessitar els seus comptes, subcapítol 30.1). Implanten AWS Control Tower, que els munta una landing zone sòlida: estructura d’OUs, seguretat, logs centralitzats i guardrails. A partir d’aquí, cada cop que un equip necessita un compte, la demanen per l’Account Factory i la reben en minuts, ja configurada amb totes les normes de l’empresa (seguretat, regions permeses, logs connectats). L’equip de plataforma no ha de configurar res a mà, i tenen la garantia que cap compte queda fora de les normes. Escalen a 50 comptes amb l’ordre i la seguretat del primer dia. Sense això, hauria estat un caos ingovernable.
El que has de recordar
- Crear i mantenir molts comptes a mà, totes coherents i amb bones pràctiques, és inviable; cal automatitzar.
- Una landing zone és un entorn multi-compte ben dissenyat, segur i a punt per ser usat, la base sòlida sobre la qual l’empresa desplega. Com una urbanització amb tota la infraestructura ja feta abans de construir les cases.
- AWS Control Tower crea i gestiona automàticament una landing zone amb bones pràctiques (estructura, seguretat, logs centralitzats) i aplica guardrails (barreres amb SCP i Config) a tots els comptes, governant-los des d’un panell central. Com el constructor expert que prepara la urbanització.
- L’Account Factory fabrica comptes noves estandarditzades, ja configurades amb les normes de l’empresa des del primer moment. Com una cadena de muntatge de comptes «clau en mà».
- El seu valor: escalar a molts comptes amb ordre, seguretat i compliment des del dia u, sense esforç manual ni errors (excel·lència operativa a escala).
En el següent subcapítol veurem com centralitzar la gestió de logs i seguretat a través de tots aquests comptes.
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
