Fins ara hem vist certificacions de coneixement general d’AWS: la Cloud Practitioner (fonaments), la Solutions Architect (disseny) i la DevOps Engineer (automatització i operació). Però AWS és enorme, i hi ha àrees tan profundes que mereixen una certificació pròpia i especialitzada. Aquestes són les certificacions Specialty (d’especialitat): títols que demostren un domini profund d’una àrea concreta d’AWS. En aquest subcapítol veiem què són, quines àrees cobreixen i quan té sentit buscar-les.
El problema: AWS és massa ampli per saber-ho tot a fons
AWS té centenars de serveis i abasta camps molt diferents: xarxes avançades, seguretat, machine learning, big data, bases de dades... Ningú pot ser expert profund en tot. Les certificacions generals (com la Solutions Architect) cobreixen molt, però en amplitud, no en la màxima profunditat de cada àrea. Per acreditar que ets un expert especialitzat en un camp concret, existeixen les Specialty.
Certificacions generals (SA, DevOps): AMPLITUD (saber de tot força) Certificacions Specialty: PROFUNDITAT (expert en una àrea)
Què són les certificacions Specialty
Les certificacions Specialty són títols d’AWS que validen un coneixement profund i especialitzat en una àrea tècnica concreta. Estan pensades per a professionals que s’han especialitzat en un camp i volen demostrar aquest domini expert. Solen ser exigents, perquè van molt més a fons en el seu tema que les certificacions generals.
Una certificació Specialty diu: "No només sé d’AWS en general; sóc EXPERT en [xarxes / seguretat / ML / ...]"
Analogia: les certificacions generals són com ser un metge de capçalera (sap de tot una mica, atén moltes coses), i les Specialty són com ser un metge especialista (cardiòleg, neuròleg...): algú que ha aprofundit enormement en una àrea concreta i és la referència experta en ella. Tots dos són valuosos; l’especialista és a qui acudeixes per als problemes profunds del seu camp. A AWS, les Specialty t’acrediten com aquest especialista.
Les àrees d’especialització
AWS ofereix certificacions Specialty en diverses àrees tècniques de gran profunditat. Les principals inclouen:
Àrees Specialty (exemples): 🌐 Advanced Networking → xarxes avançades i complexes a AWS 🔒 Security → seguretat en profunditat (connecta amb el Cap. 23) 🤖 Machine Learning → intel·ligència artificial i ML a AWS 📊 Data / Analytics → big data i analítica (connecta amb el Cap. 29) ... (l’oferta evoluciona amb el temps)
Cadascuna correspon a un camp on l’especialització aporta un valor enorme i on el coneixement general no n’hi ha prou. Per exemple:
- La de Seguretat aprofundeix moltíssim en tot el que vam veure al Capítol 23 (i més): és per a qui es dedica a la seguretat cloud.
- La de Xarxes Avançades va molt més enllà del bàsic de xarxes (Capítol 6): per a especialistes en connectivitat complexa.
- La de Machine Learning o Data són per a qui es dedica a la IA o a les plataformes de dades (Capítol 29).
⚠️ L’oferta concreta de certificacions Specialty canvia amb el temps (AWS afegeix, retira o reanomena certificacions segons evoluciona la tecnologia). L’important és el concepte: existeixen certificacions especialitzades per acreditar domini expert en àrees concretes. Consulta el web oficial d’AWS per a la llista actual.
Quan buscar una Specialty?
Les Specialty no són el primer pas ni per a tothom. Tenen sentit quan:
- T’has especialitzat (o vols especialitzar-te) en una àrea concreta (seguretat, xarxes, dades, ML...).
- La teva feina se centra en aquest camp i vols acreditar el teu domini expert.
- Ja tens una base sòlida (idealment, experiència i potser una certificació Associate o Professional) i vols aprofundir en la teva especialitat.
Ruta típica:
Fonaments (Cloud Practitioner)
→ certificació general (Associate / Professional)
→ experiència i especialització en una àrea
→ certificació SPECIALTY d’aquella àrea (expert)💡 No tinguis pressa amb les Specialty. Primer domina els fonaments i aconsegueix una certificació general; les Specialty arriben quan ja t’has orientat cap a un camp concret i vols ser una referència experta en ell. Són la cirereta d’un perfil especialitzat, no el punt de partida.
El valor d’especialitzar-se
En un mercat on molta gent té coneixements generals, especialitzar-se et diferencia. Un expert certificat en una àrea d’alta demanda (com seguretat o machine learning) és un perfil molt buscat i valorat. Les Specialty acrediten aquesta especialització i poden obrir portes a rols molt concrets i ben remunerats.
Exemple del món real: una enginyera porta diversos anys treballant en seguretat cloud. Ja té la Solutions Architect Associate i molta experiència pràctica en protegir entorns AWS (IAM, xifratge, detecció d’amenaces... tot el del Capítol 23 i més). Vol posicionar-se com a especialista en seguretat i diferenciar-se. Es treu la certificació Specialty de Seguretat, que aprofundeix enormement en el seu camp. Amb aquest títol, el seu perfil esdevé el d’una experta acreditada en seguretat AWS, un rol molt demandat i escàs. Passa a liderar la seguretat cloud de la seva empresa i a ser una referència. L’especialització, recolzada per la Specialty, la va posicionar com a experta on abans era «una més». Per a ella, aquesta va ser la certificació que la va convertir en especialista.
El que has de recordar
- AWS és tan ampli que ningú és expert profund en tot; les certificacions generals cobreixen amplitud, i les Specialty cobreixen profunditat en una àrea.
- Les certificacions Specialty validen un coneixement profund i especialitzat en una àrea tècnica concreta (xarxes avançades, seguretat, machine learning, dades...). Són exigents. Com ser un metge especialista davant d’un de capçalera.
- Cada àrea connecta amb temes del llibre portats a la seva màxima profunditat: Seguretat (Cap. 23), Dades (Cap. 29), Xarxes (Cap. 6)... ⚠️ L’oferta concreta canvia amb el temps; consulta el web oficial d’AWS.
- No són el primer pas: tenen sentit quan t’has especialitzat en un camp, la teva feina se centra en ell i ja tens una base sòlida. 💡 Primer fonaments i una certificació general; les Specialty són la cirereta d’un perfil especialitzat.
- Especialitzar-se et diferencia: un expert certificat en una àrea demandada és un perfil molt buscat i valorat.
A l’últim subcapítol del capítol veurem una certificació clau per al tema central d’aquest llibre, però que no és d’AWS sinó de HashiCorp: la Terraform Associate.
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
