Tras la Cloud Practitioner (subcapítulo 32.1), el siguiente paso natural es la certificación técnica más popular y demandada de todo el ecosistema AWS: la de Solutions Architect (Arquitecto de Soluciones). Existe en dos niveles —Associate (asociado) y Professional (profesional)—, y representan una de las rutas profesionales más valoradas. En este subcapítulo vemos qué son, en qué se diferencian y cómo abordarlas. Es, probablemente, la certificación que más impulsa una carrera en la nube.
Qué es un Solutions Architect
Un Solutions Architect (Arquitecto de Soluciones) es quien diseña arquitecturas en AWS: decide qué servicios usar y cómo combinarlos para construir sistemas que cumplan los requisitos (que sean seguros, fiables, eficientes en coste...). Es, esencialmente, lo que has estado aprendiendo a hacer a lo largo de este libro, especialmente con el Well-Architected Framework (Capítulo 27).
El Solutions Architect responde preguntas como:
"Necesito un sistema que aguante mucho tráfico, sea seguro
y no cueste demasiado. ¿Qué servicios de AWS uso y cómo los combino?"
→ diseña la solución (la arquitectura)Por eso esta certificación es tan valorada: acredita que sabes diseñar bien en AWS, una habilidad central y muy demandada.
Analogía: un Solutions Architect es como un arquitecto de edificios, pero para sistemas en la nube. Un arquitecto de edificios decide cómo combinar materiales y estructuras para construir algo que cumpla su función, sea seguro, eficiente y se ajuste al presupuesto. El Solutions Architect hace lo mismo con los servicios de AWS: los combina para «construir» sistemas que cumplan los requisitos. La certificación es el «título de arquitecto» que lo acredita.
Los dos niveles: Associate y Professional
La certificación de Solutions Architect tiene dos niveles, que forman una progresión:
Solutions Architect Associate (el nivel asociado)
La AWS Certified Solutions Architect – Associate valida que sabes diseñar arquitecturas en AWS siguiendo las buenas prácticas. Es de nivel intermedio y una de las certificaciones más populares del mundo, muy reconocida por las empresas. Demuestra una competencia técnica sólida y práctica.
Solutions Architect ASSOCIATE: - nivel intermedio - diseñar arquitecturas bien (seguras, fiables, eficientes) - una de las certificaciones MÁS valoradas y populares - un gran objetivo tras dominar los fundamentos
Solutions Architect Professional (el nivel profesional)
La AWS Certified Solutions Architect – Professional es el nivel avanzado: valida que sabes diseñar arquitecturas complejas en AWS, tomando decisiones sofisticadas en escenarios reales y difíciles. Es mucho más exigente que la Associate, y demuestra un dominio profundo.
Solutions Architect PROFESSIONAL: - nivel avanzado (mucho más exigente) - arquitecturas complejas, decisiones sofisticadas - escenarios reales y difíciles - demuestra un dominio PROFUNDO y experto
La progresión: de Associate a Professional
El camino habitual es primero la Associate y, después, la Professional:
Cloud Practitioner (32.1) → empiezas, fundamentos
│
▼
Solutions Architect ASSOCIATE → diseñar bien (intermedio, muy valorada)
│ (con experiencia práctica de por medio)
▼
Solutions Architect PROFESSIONAL → arquitecturas complejas (avanzado, experto)💡 Importante: entre la Associate y la Professional, lo más valioso es ganar experiencia práctica real. La Professional pregunta sobre escenarios complejos que se entienden mejor habiéndolos vivido (o practicado a fondo). No tengas prisa por saltar; consolida con práctica.
Qué cubren (y cómo conecta con el libro)
Estas certificaciones cubren, en distinta profundidad, todo lo que has aprendido en el libro: redes (Capítulo 6), cómputo (servidores, contenedores, serverless), almacenamiento y bases de datos, seguridad (Capítulos 7 y 23), alta disponibilidad y disaster recovery (Capítulo 26), optimización de costes (Capítulo 25), y sobre todo el Well-Architected Framework (Capítulo 27), que es el corazón del pensamiento de un arquitecto.
Lo que has aprendido en el libro ≈ lo que evalúan estas certificaciones (redes, cómputo, almacenamiento, seguridad, HA/DR, costes, Well-Architected)
La Associate evalúa que sabes aplicar estos conceptos para diseñar soluciones sólidas; la Professional, que sabes hacerlo en escenarios complejos y con decisiones avanzadas.
Cómo prepararlas
- Domina el Well-Architected Framework (Capítulo 27): es la mentalidad central del arquitecto, y muchas preguntas giran en torno a sus pilares (equilibrar seguridad, fiabilidad, coste, rendimiento...).
- Practica diseñando: ante un requisito, piensa qué servicios usarías y por qué. Las preguntas suelen ser escenarios donde eliges la mejor solución.
- Gana experiencia real (sobre todo para la Professional): construir cosas de verdad consolida el conocimiento mejor que solo estudiar.
- Usa recursos oficiales y exámenes de práctica (Capítulo 34): para familiarizarte con el estilo de las preguntas.
Ejemplo del mundo real: un desarrollador que ya domina los fundamentos quiere dar el salto a roles de arquitectura cloud, mejor pagados y más estratégicos. Se saca la Solutions Architect Associate: estudia el diseño de arquitecturas, practica resolviendo escenarios, y aprueba. Inmediatamente, su perfil se vuelve mucho más atractivo y consigue un puesto con más responsabilidad de diseño. Tras un par de años diseñando sistemas reales (ganando esa experiencia valiosa), se presenta a la Professional y la aprueba, consolidándose como arquitecto senior. Esa progresión —Associate, experiencia, Professional— impulsó enormemente su carrera. La Solutions Architect es, para muchos, la certificación que cambia su trayectoria profesional.
Lo que debes recordar
- Un Solutions Architect diseña arquitecturas en AWS (qué servicios usar y cómo combinarlos para cumplir requisitos), justo lo que enseña este libro, especialmente el Well-Architected Framework. Como un arquitecto de edificios, pero para la nube.
- La certificación tiene dos niveles:
- Solutions Architect Associate: nivel intermedio, valida que sabes diseñar bien; una de las certificaciones más populares y valoradas del mundo.
- Solutions Architect Professional: nivel avanzado, valida que diseñas arquitecturas complejas con decisiones sofisticadas; mucho más exigente, demuestra dominio profundo.
- La progresión habitual: Cloud Practitioner → Associate → (ganar experiencia práctica) → Professional. 💡 No tengas prisa en saltar; la experiencia real es clave para la Professional.
- Cubren todo lo del libro (redes, cómputo, almacenamiento, seguridad, HA/DR, costes) con el Well-Architected Framework como corazón. Prepáralas dominando ese framework, practicando diseños, ganando experiencia y con exámenes de práctica.
En el siguiente subcapítulo veremos la certificación orientada específicamente a la cultura y prácticas que recorre todo este libro: la DevOps Engineer Professional.
Cloud, AWS & Terraform — De cero a experto
Capítulo 1 · Qué es el cloud computing
- 1.1 El modelo cliente-servidor tradicional
- 1.2 Problemas que venía a resolver la nube
- 1.3 On-premise vs cloud vs híbrido
- 1.4 Los tres modelos de servicio: IaaS, PaaS, SaaS
- 1.5 Los cinco pilares del cloud (según NIST)
- 1.6 Ventajas reales: elasticidad, pago por uso, disponibilidad global
Capítulo 2 · El mercado cloud y los grandes proveedores
- 2.1 AWS, Azure y GCP: diferencias y cuotas de mercado
- 2.2 Por qué aprender AWS primero
- 2.3 Conceptos que son universales entre proveedores
Capítulo 3 · Regiones, zonas de disponibilidad y edge
- 3.1 Qué es una región AWS y cómo elegirla
- 3.2 Availability Zones: alta disponibilidad desde el diseño
- 3.3 Edge locations y CloudFront
- 3.4 Latencia, resiliencia y soberanía de datos
Capítulo 4 · Cómputo: EC2
- 4.1 Instancias: tipos, familias y cuándo elegir cada una
- 4.2 AMIs, key pairs y Security Groups
- 4.3 Ciclo de vida de una instancia
- 4.4 Elastic IPs y Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítulo 5 · Almacenamiento: S3
- 5.1 Buckets, objetos y claves
- 5.2 Clases de almacenamiento (Standard, IA, Glacier…)
- 5.3 Versionado y ciclo de vida de objetos
- 5.4 Políticas de bucket y ACLs
- 5.5 Hosting de sitios web estáticos
Capítulo 6 · Redes: VPC
- 6.1 Qué es una VPC y por qué la necesitas
- 6.2 Subredes públicas y privadas
- 6.3 Internet Gateway y NAT Gateway
- 6.4 Route Tables y Network ACLs
- 6.5 VPC Peering y endpoints
Capítulo 7 · Identidad y acceso: IAM
- 7.1 Usuarios, grupos, roles y políticas
- 7.2 El principio de mínimo privilegio
- 7.3 Políticas basadas en identidad vs en recurso
- 7.4 MFA y credenciales temporales (STS)
- 7.5 Buenas prácticas de seguridad IAM
Capítulo 8 · Bases de datos gestionadas
- 8.1 RDS: motores, Multi-AZ y réplicas de lectura
- 8.2 Aurora y sus ventajas sobre RDS vanilla
- 8.3 DynamoDB: modelo clave-valor / documentos
- 8.4 ElastiCache para caché en memoria
- 8.5 Cuándo usar cada tipo de base de datos
Capítulo 9 · Por qué Infraestructura como Código
- 9.1 Problemas del aprovisionamiento manual
- 9.2 IaC declarativo vs imperativo
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El ciclo plan → apply → destroy
Capítulo 10 · HCL: el lenguaje de Terraform
- 10.1 Bloques resource, variable, output, locals
- 10.2 Tipos de datos: string, number, bool, list, map, object
- 10.3 Expresiones, referencias y funciones built-in
- 10.4 Condicionales y bucles (count, for_each, for)
Capítulo 11 · Providers y estado
- 11.1 Cómo funciona el provider de AWS
- 11.2 El fichero terraform.tfstate y su importancia
- 11.3 State local vs state remoto (S3 + DynamoDB)
- 11.4 Comandos esenciales: init, plan, apply, destroy, fmt, validate
Capítulo 12 · Tu primera infraestructura real en Terraform
- 12.1 Crear una VPC con subredes desde cero
- 12.2 Levantar una instancia EC2 pública
- 12.3 Asociar un Security Group y una Elastic IP
- 12.4 Outputs y referencias entre recursos
- 12.5 Flujo de trabajo en equipo: PR review de planes
Capítulo 13 · Balanceo de carga y autoescalado
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners y reglas
- 13.3 Auto Scaling Groups: políticas y métricas
- 13.4 Warm pools y lifecycle hooks
Capítulo 14 · Serverless con Lambda
- 14.1 El modelo de ejecución de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestión de dependencias y capas (Layers)
- 14.4 Cold starts y estrategias para reducirlos
- 14.5 Límites y antipatrones
Capítulo 15 · Mensajería y eventos
- 15.1 SQS: colas estándar vs FIFO, DLQ
- 15.2 SNS: topics, suscripciones, fan-out
- 15.3 EventBridge: event buses y reglas
- 15.4 Patrones: pub/sub, desacoplamiento, saga
Capítulo 16 · Entrega de contenido y DNS
- 16.1 Route 53: tipos de registros y routing policies
- 16.2 CloudFront: distribuciones, cachés y origins
- 16.3 ACM: certificados SSL/TLS gratuitos
- 16.4 WAF integrado con CloudFront
Capítulo 17 · Contenedores en AWS
- 17.1 Docker: repaso exprés de conceptos clave
- 17.2 ECR: registro privado de imágenes
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: cuándo Kubernetes y cuándo no
Capítulo 18 · Módulos: reutilización y composición
- 18.1 Anatomía de un módulo Terraform
- 18.2 Variables de entrada, outputs y dependencias
- 18.3 Módulos locales vs módulos del Terraform Registry
- 18.4 Versionado de módulos con Git tags
- 18.5 Diseño de módulos genéricos vs específicos de dominio
Capítulo 19 · Workspaces y gestión de entornos
- 19.1 Workspaces de Terraform: casos de uso y limitaciones
- 19.2 Estrategia de directorios por entorno (dev/stg/prod)
- 19.3 Terragrunt: DRY para configuraciones de entorno
- 19.4 Variables de entorno y archivos .tfvars
Capítulo 20 · Backends remotos y locking
- 20.1 Configurar S3 + DynamoDB como backend
- 20.2 State locking: evitar corrupción en equipo
- 20.3 Migración de estado entre backends
- 20.4 terraform import: traer recursos existentes al estado
Capítulo 21 · Testing de infraestructura
- 21.1 Terraform validate y fmt en CI
- 21.2 Checkov y tfsec: análisis de seguridad estático
- 21.3 Terratest: tests de integración en Go
- 21.4 Contract testing entre módulos
Capítulo 22 · Terraform en CI/CD
- 22.1 Pipeline básico: lint → plan → apply en GitHub Actions
- 22.2 Atlantis: GitOps para Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection y reconciliación automática
Capítulo 23 · Seguridad en profundidad
- 23.1 AWS Organizations y Service Control Policies
- 23.2 AWS Config: compliance continuo
- 23.3 GuardDuty: detección de amenazas
- 23.4 Security Hub: visión centralizada
- 23.5 KMS: gestión de claves y rotación
- 23.6 Secrets Manager vs Parameter Store
Capítulo 24 · Observabilidad: logs, métricas y trazas
- 24.1 CloudWatch Logs, métricas y alarmas
- 24.2 CloudWatch Dashboards y Contributor Insights
- 24.3 X-Ray: trazado distribuido
- 24.4 OpenTelemetry en AWS
- 24.5 Managed Grafana y Managed Prometheus
Capítulo 25 · Optimización de costes
- 25.1 AWS Cost Explorer y presupuestos con alertas
- 25.2 Trusted Advisor y Compute Optimizer
- 25.3 Rightsizing: cómo detectar sobredimensionamiento
- 25.4 Savings Plans vs Reserved Instances: decisión estratégica
- 25.5 FinOps: cultura y procesos para controlar el gasto
Capítulo 26 · Alta disponibilidad y disaster recovery
- 26.1 RTO y RPO: definir los objetivos
- 26.2 Estrategias: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks y failover automático
- 26.4 AWS Backup: política centralizada de copias
Capítulo 27 · Well-Architected Framework de AWS
- 27.1 Los seis pilares: excelencia operacional, seguridad, fiabilidad, eficiencia de rendimiento, optimización de costes, sostenibilidad
- 27.2 Well-Architected Tool: revisiones formales
- 27.3 Cómo aplicar el framework en decisiones de diseño
Capítulo 28 · Arquitecturas serverless a escala
- 28.1 Event-driven architecture con Lambda + EventBridge
- 28.2 Saga pattern para transacciones distribuidas
- 28.3 Step Functions: orquestación de workflows complejos
- 28.4 Lambda@Edge y CloudFront Functions
Capítulo 29 · Plataformas de datos en AWS
- 29.1 Data Lake con S3, Glue y Athena
- 29.2 Kinesis Data Streams y Firehose para streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: gobierno del dato
Capítulo 30 · Multi-cuenta y landing zones
- 30.1 Por qué separar workloads en cuentas distintas
- 30.2 AWS Control Tower y Account Factory
- 30.3 Gestión centralizada de logs y seguridad
- 30.4 Terraform a escala multi-cuenta con módulos compartidos
Capítulo 31 · Platform Engineering e Internal Developer Platform
- 31.1 Golden paths y abstracciones sobre Terraform
- 31.2 Service Catalog de AWS
- 31.3 Backstage como portal de desarrolladores
- 31.4 Módulos Terraform como producto interno
Capítulo 32 · Certificaciones AWS relevantes
- 32.1 Cloud Practitioner: ¿vale 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ítulo 33 · Proyectos para consolidar lo aprendido
- 33.1 Proyecto 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Proyecto 2: API REST con ECS Fargate + RDS + ALB
- 33.3 Proyecto 3: plataforma de datos con Glue + Athena + Redshift
- 33.4 Proyecto 4: landing zone multi-cuenta con Terraform y Control Tower
