En el subcapítulo 29.1 vimos el data lake (S3 + Glue + Athena) para guardar y consultar datos en bruto. Mencionamos que existe un concepto complementario: el data warehouse (almacén de datos), optimizado para análisis muy rápidos sobre datos estructurados. En AWS, ese servicio es Amazon Redshift. En este subcapítulo vemos qué es un data warehouse, qué hace Redshift y cuándo elegirlo frente a (o junto con) un data lake. Es la herramienta para hacer analítica seria y rápida sobre grandes volúmenes de datos.
El problema: analizar enormes cantidades de datos, muy rápido
Imagina una empresa que quiere responder, en segundos, preguntas complejas sobre años de datos de ventas: «¿cuáles fueron los 10 productos más vendidos por región y trimestre en los últimos 3 años, comparados con el año anterior?». Esto implica analizar millones o miles de millones de registros, cruzando y agregando datos.
Una base de datos normal (como las que vimos en el Capítulo 8, pensadas para gestionar las operaciones del día a día: registrar un pedido, consultar un cliente) no está optimizada para este tipo de análisis masivo. Haría esas consultas gigantes muy lentamente. Necesitas una herramienta especializada en análisis a gran escala: un data warehouse.
Qué es un data warehouse
Un data warehouse (almacén de datos) es una base de datos especializada en analizar enormes cantidades de datos estructurados de forma muy rápida. Está diseñada específicamente para consultas analíticas complejas (agregaciones, comparaciones, informes) sobre grandes volúmenes, normalmente datos históricos de toda la empresa.
Base de datos normal (Cap. 8): optimizada para OPERACIONES del día a día
(registrar/consultar cosas individuales, rápido)
Data warehouse: optimizado para ANÁLISIS a gran escala
(consultas complejas sobre millones de registros)Analogía: la diferencia es como entre la caja registradora de una tienda y el departamento de análisis de la central. La caja registradora (base de datos normal) está hecha para operaciones rápidas e individuales: cobrar una compra, devolver un producto. El departamento de análisis (data warehouse) está hecho para coger todas las ventas de todas las tiendas durante años y sacar conclusiones: tendencias, comparativas, informes. Son herramientas distintas para trabajos distintos.
Qué es Amazon Redshift
Amazon Redshift es el servicio de data warehouse de AWS: una base de datos analítica, gestionada y muy escalable, optimizada para ejecutar consultas complejas sobre enormes volúmenes de datos a gran velocidad. Es donde las empresas hacen su analítica e inteligencia de negocio (business intelligence) seria.
Grandes volúmenes de datos estructurados (ventas, finanzas...)
│
▼
Amazon Redshift (data warehouse)
│
▼
Consultas analíticas complejas respondidas RÁPIDO
(informes, paneles de BI, análisis de tendencias)Por qué Redshift es tan rápido en análisis
Sin entrar en tecnicismos, Redshift logra su velocidad porque está diseñado de raíz para análisis: organiza y almacena los datos de forma optimizada para consultas analíticas, y reparte el trabajo de una consulta entre muchos recursos en paralelo (procesamiento masivo en paralelo). Así, una consulta que cruzaría millones de registros se resuelve en segundos en vez de horas.
Analogía: Redshift es como tener un equipo enorme de analistas trabajando en paralelo en vez de uno solo. Si le pides analizar millones de registros, no lo hace una sola «persona» secuencialmente (lento); reparte el trabajo entre muchos que trabajan a la vez y juntan el resultado. Por eso responde rápido incluso a preguntas enormes.
Data lake vs data warehouse: ¿cuál uso?
Esta es la pregunta clave, y la respuesta suele ser «los dos, para cosas distintas». No compiten; se complementan:
| Data Lake (S3+Glue+Athena, 29.1) | Data Warehouse (Redshift) | |
|---|---|---|
| Guarda | Datos en bruto, cualquier formato | Datos estructurados y preparados |
| Estructura | Flexible (defines al consultar) | Definida y optimizada de antemano |
| Ideal para | Explorar, guardar todo, datos variados | Análisis rápido y repetido, informes de BI |
| Velocidad de consulta | Buena, flexible | Muy alta para análisis complejos |
| Coste | Muy barato (S3) | Mayor (más potencia analítica) |
Patrón habitual combinado:
Datos en bruto → DATA LAKE (S3) → se preparan los más importantes
│
▼
DATA WAREHOUSE (Redshift)
→ análisis rápido y repetido para informes💡 Patrón común: muchas empresas usan ambos: el data lake (S3) guarda todos los datos en bruto y baratos, y los datos más importantes y estructurados se cargan en Redshift para hacer análisis rápidos y recurrentes (los informes diarios de negocio, los paneles que la dirección consulta cada mañana). El lago es el «todo»; el almacén es lo «refinado y listo para análisis intensivo».
Ejemplo del mundo real: una cadena de tiendas guarda en su data lake (S3) absolutamente todos sus datos en bruto: ventas, inventario, logs web, datos de fidelización... baratos y completos. Cada noche, un proceso (con Glue, subcapítulo 29.1) prepara y carga los datos de ventas e inventario en Redshift. Allí, el equipo de análisis ejecuta cada mañana informes complejos —«ventas por categoría, región y semana, con comparativa interanual»— que Redshift responde en segundos pese a abarcar años de datos. La dirección consulta paneles de BI que beben de Redshift para tomar decisiones. El data lake guarda todo; Redshift potencia el análisis rápido del día a día. Juntos forman una plataforma de datos completa.
Lo que debes recordar
- Analizar enormes volúmenes de datos muy rápido (informes complejos sobre años de datos) no es para lo que sirve una base de datos normal (optimizada para operaciones del día a día); hace falta un data warehouse.
- Un data warehouse es una base de datos especializada en análisis a gran escala sobre datos estructurados, optimizada para consultas analíticas complejas. Como el departamento de análisis de la central frente a la caja registradora.
- Amazon Redshift es el data warehouse de AWS: gestionado, muy escalable y rapidísimo en análisis, porque está diseñado para ello y reparte el trabajo en paralelo (como un gran equipo de analistas trabajando a la vez).
- Data lake (29.1) y data warehouse (Redshift) se complementan, no compiten: el lago guarda todo en bruto (barato, flexible); el almacén guarda lo estructurado y refinado para análisis rápido y repetido.
- 💡 Patrón común: el data lake (S3) guarda todo, y los datos importantes se cargan en Redshift para los informes de negocio del día a día.
En el último subcapítulo del capítulo veremos cómo gobernar y asegurar todos estos datos de forma centralizada con Lake Formation.
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
