Semana 10 · Módulo 10 de 11

Resiliencia, operaciones y costes: Well-Architected, DR, observabilidad, IaC y FinOps

Cierras el temario técnico con lo transversal: el AWS Well-Architected Framework, el diseño multi-AZ y multirregión, las cuatro estrategias de recuperación ante desastres con su RTO/RPO, la observabilidad con CloudWatch, la infraestructura como código con CloudFormation, la operación con Systems Manager y la gestión y optimización de costes (Budgets, Cost Explorer, CUR, etiquetas, Savings Plans). Es el núcleo del task statement 2.2 y la parte común de los task statements 4.1 a 4.4.

Reparto de la semana

Por qué importa

El dominio 2 (Design Resilient Architectures) pesa un 26 % y el dominio 4 (Design Cost-Optimized Architectures) un 20 %: casi la mitad del examen. En los módulos anteriores has visto cada servicio; aquí aprendes a combinarlos para que una arquitectura sobreviva a fallos, se recupere de desastres, se opere sin sustos y cueste lo justo.

Las preguntas de este bloque se reconocen por sus palabras clave: highly available, fault tolerant, disaster recovery, RPO, RTO, single point of failure, without modifying the application, LEAST operational overhead, MOST cost-effective, track costs by department, alert when spending exceeds, steady-state workload. Además, la guía dice que el examen valida la capacidad de diseñar «según el AWS Well-Architected Framework»: es el marco mental con el que están escritas todas las preguntas.

AWS Well-Architected Framework

El Well-Architected Framework es el conjunto de buenas prácticas de AWS para diseñar y revisar cargas de trabajo. Se organiza en seis pilares, cada uno con principios de diseño, preguntas y buenas prácticas. La AWS Well-Architected Tool (en la consola, sin coste adicional) permite revisar una carga de trabajo respondiendo a esas preguntas, registrar riesgos (high/medium risk issues) y seguir un plan de mejora. Las lenses amplían el marco para dominios concretos (serverless, SaaS, analítica, IA generativa…).

Los seis pilares y sus principios de diseño

Principios verificados en la documentación oficial (septiembre de 2026):

1. Operational excellence (excelencia operativa): ejecutar y monitorizar sistemas y mejorar procesos.

• Organize teams around business outcomes (equipos organizados en torno a resultados de negocio).
• Implement observability for actionable insights (observabilidad que permita actuar).
• Safely automate where possible (automatizar con salvaguardas).
• Make frequent, small, reversible changes (cambios pequeños, frecuentes y reversibles).
• Refine operations procedures frequently (revisar los procedimientos a menudo).
• Anticipate failure (anticipar el fallo con simulacros).
• Learn from all operational events and metrics (aprender de cada incidente).
• Use managed services (usar servicios gestionados).

2. Security (seguridad): proteger datos, sistemas y activos.

• Implement a strong identity foundation (mínimo privilegio, separación de funciones, sin credenciales estáticas).
• Maintain traceability (trazabilidad: registrar, alertar y auditar).
• Apply security at all layers (defensa en profundidad).
• Automate security best practices.
• Protect data in transit and at rest.
• Keep people away from data (reducir el acceso manual a los datos).
• Prepare for security events (preparar la respuesta a incidentes).

3. Reliability (fiabilidad): que la carga cumpla su función de forma correcta y consistente, y se recupere de fallos.

• Automatically recover from failure (recuperación automática basada en KPI).
• Test recovery procedures (probar la recuperación).
• Scale horizontally to increase aggregate workload availability (muchos recursos pequeños mejor que uno grande).
• Stop guessing capacity (escalar según la demanda).
• Manage change through automation (cambios mediante automatización).

4. Performance efficiency (eficiencia del rendimiento): usar los recursos de forma eficiente según cambia la demanda.

• Democratize advanced technologies (consumir tecnología avanzada como servicio).
• Go global in minutes (desplegar en varias regiones).
• Use serverless architectures.
• Experiment more often.
• Consider mechanical sympathy (elegir la tecnología según el patrón de acceso).

5. Cost optimization (optimización de costes): entregar valor al menor precio.

• Implement Cloud Financial Management (FinOps).
• Adopt a consumption model (pagar por lo que usas; por ejemplo, apagar entornos de desarrollo fuera de horario puede ahorrar alrededor de un 75 %).
• Measure overall efficiency.
• Stop spending money on undifferentiated heavy lifting (dejar a AWS lo que no diferencia tu negocio).
• Analyze and attribute expenditure (atribuir el gasto a cada dueño: etiquetas).

6. Sustainability (sostenibilidad): minimizar el impacto ambiental.

• Understand your impact.
• Establish sustainability goals.
• Maximize utilization (dos hosts al 30 % son menos eficientes que uno al 60 %).
• Anticipate and adopt new, more efficient hardware and software offerings (por ejemplo, Graviton).
• Use managed services.
• Reduce the downstream impact of your cloud workloads.

Alta disponibilidad, tolerancia a fallos y recuperación ante desastres

Tres conceptos que el examen distingue con cuidado:

• Alta disponibilidad (high availability): el sistema sigue dando servicio ante el fallo de un componente, quizá con una breve interrupción o menos capacidad. Ejemplo: ALB + Auto Scaling group en tres AZ.
• Tolerancia a fallos (fault tolerance): el fallo de un componente no se nota porque hay redundancia completa y activa. Ejemplo: capacidad suficiente en cada AZ para absorber la pérdida de otra, almacenamiento con réplicas síncronas.
• Recuperación ante desastres (disaster recovery, DR): volver a dar servicio tras un evento grave (pérdida de una región, borrado masivo, ransomware, corrupción de datos). Se mide con dos objetivos:
  • RPO (Recovery Point Objective): cuántos datos puedes perder, medido en tiempo. RPO de 15 minutos = como mucho se pierden los últimos 15 minutos.
  • RTO (Recovery Time Objective): cuánto tiempo puede estar el servicio caído hasta recuperarse.

flowchart LR
  UB["Último backup o réplica"] -->|"RPO: datos perdidos"| D["Desastre"]
  D -->|"RTO: tiempo sin servicio"| R["Servicio recuperado"]

Métricas según los requisitos de negocio

El temario pide identifying metrics based on business requirements to deliver a highly available solution. Traduce el requisito a métricas medibles:

• Disponibilidad objetivo (por ejemplo, 99,9 % ≈ 8,8 horas de caída al año; 99,99 % ≈ 53 minutos). Cuantos más «nueves», más redundancia y más coste.
• SLI de usuario: tasa de errores 5xx del ALB, latencia p99 (TargetResponseTime), peticiones fallidas en API Gateway.
• Salud de la infraestructura: HealthyHostCount del target group, StatusCheckFailed de EC2, ReplicaLag de RDS, profundidad de cola (ApproximateNumberOfMessagesVisible) en SQS.
• KPI de negocio: pedidos por minuto, pagos completados. El pilar de fiabilidad recomienda que la recuperación automática se base en KPI de negocio, no solo en métricas técnicas.

Diseño resiliente: multi-AZ y multirregión

Eliminar puntos únicos de fallo capa a capa

¿Multi-AZ o multirregión?

• Multi-AZ protege frente al fallo de un centro de datos o una AZ. Es la base de cualquier producción y la respuesta a highly available dentro de una región. Las AZ están conectadas con baja latencia, así que se pueden usar réplicas síncronas.
• Multirregión protege frente a la caída de una región entera, cumple requisitos regulatorios (distancia mínima entre copias) y reduce la latencia para usuarios globales. La replicación entre regiones es asíncrona (RPO mayor que cero), cuesta más (transferencia entre regiones, infraestructura duplicada) y añade complejidad. Úsala cuando el enunciado hable de Region failure, DR in another Region o usuarios en varios continentes.

Estabilidad estática frente a recuperación dinámica

• Estabilidad estática (static stability): el sistema sigue funcionando ante un fallo sin tener que hacer cambios (sin lanzar recursos ni llamar a APIs del plano de control). Ejemplo: tres AZ con capacidad suficiente para que, si cae una, las otras dos aguanten el 100 % de la carga. Cuesta más porque hay capacidad sobrante, pero no depende de que Auto Scaling funcione durante el incidente.
• Recuperación dinámica: ante el fallo, el sistema reacciona creando capacidad (Auto Scaling lanza instancias, se promociona una réplica, se escala el entorno de DR). Más barato, pero depende del plano de control (control plane: las APIs que crean y configuran recursos), que tiene objetivos de disponibilidad menores que el plano de datos (data plane: lo que sirve el tráfico).

El whitepaper de DR de AWS recomienda usar operaciones del plano de datos en la conmutación: por ejemplo, health checks de Route 53 (plano de datos) en lugar de cambiar registros DNS a mano (plano de control).

Patrones de diseño distribuido

• Reintentos con exponential backoff y jitter (espera creciente y aleatoria) para errores transitorios y throttling. Los SDK de AWS ya lo hacen.
• Timeouts en todas las llamadas remotas.
• Idempotencia: procesar dos veces el mismo mensaje no debe duplicar el efecto (clave de idempotencia, colas FIFO con deduplicación).
• Circuit breaker: dejar de llamar a una dependencia que falla y devolver una respuesta degradada.
• Bulkheads (compartimentos) y cell-based architecture: aislar clientes o funciones para limitar el radio de impacto (blast radius).
• Queue-based load leveling: una cola SQS absorbe los picos y protege la base de datos.
• Health checks profundos o superficiales en ELB y Route 53.
• Degradación elegante: servir contenido en caché o funciones reducidas si falla un componente no crítico.

Infraestructura inmutable

Infraestructura inmutable: no modificas servidores en caliente; construyes una imagen nueva (AMI «dorada» con EC2 Image Builder o una imagen de contenedor) y reemplazas las instancias (actualización continua del Auto Scaling group, instance refresh, despliegues blue/green). Ventajas: entornos idénticos, sin deriva de configuración, rollback inmediato volviendo a la imagen anterior. Se apoya en infraestructura como código (CloudFormation) y es uno de los skills del temario: determining automation strategies to ensure infrastructure integrity (junto con la detección de deriva de CloudFormation y AWS Config).

Cuotas de servicio y throttling

Las service quotas (antes service limits) limitan cuántos recursos o llamadas puedes usar por cuenta y región (vCPU de EC2 On-Demand, conexiones, TPS de APIs…). Consecuencias de diseño:

• En un entorno de DR o standby en otra región, las cuotas son independientes: si solo tienes dos instancias en la región de DR, tu cuota allí puede ser insuficiente para escalar a producción en un desastre. Solicita el aumento por adelantado con Service Quotas (el whitepaper de DR lo recomienda expresamente).
• Crea alarmas de CloudWatch sobre las métricas de uso (AWS/Usage) para avisar antes de llegar al límite; Trusted Advisor también revisa límites.
• Cuando un servicio te limita (throttling), aplica reintentos con backoff, colas y caché. Tú también puedes limitar a tus clientes: API Gateway permite throttling por etapa y método y usage plans con claves de API.

Cómo se gestionan las cuotas en la práctica (consola Service Quotas):

• Cada cuota es por cuenta y por región (salvo las de servicios globales). Unas son ajustables (vCPU de EC2 On-Demand, concurrencia de Lambda, shards de Kinesis…) y otras fijas (por ejemplo, el tamaño máximo de un objeto de S3 o de un item de DynamoDB): contra las fijas solo cabe rediseñar.
• Las ampliaciones se piden desde Service Quotas (consola, CLI aws service-quotas request-service-quota-increase o API); unas se aprueban automáticamente y otras pasan a AWS Support, así que pídelas con días de antelación, no durante el incidente.
• Quota request templates (plantillas de solicitud de cuotas): en una organización de AWS Organizations con todas las funciones, defines hasta 10 cuotas con el valor deseado y, al asociar la plantilla, cada cuenta nueva de la organización pide esos aumentos automáticamente. Encaja con cuentas de DR o de standby creadas con Control Tower o Account Factory. Ojo: no actualiza las cuentas que ya existen y no funciona en regiones opt-in (como eu-south-2).
• Muchos servicios publican su uso frente a la cuota en CloudWatch (namespace AWS/Usage): crea una alarma al 80 % para enterarte antes de chocar con el límite. Trusted Advisor (categoría service limits) también avisa.
• Las API de AWS también tienen límites de peticiones por segundo (por ejemplo, las de KMS o las del plano de control de EC2). Si un despliegue masivo o un DR automatizado las satura, verás errores de throttling: los SDK reintentan con backoff, y conviene escalonar las operaciones.

Fiabilidad para aplicaciones heredadas sin cambiar código

Escenario frecuente: «la aplicación no se puede modificar» (when application changes are not possible). Opciones:

• Ponerla detrás de un ALB con un Auto Scaling group de tamaño mínimo y máximo 1 repartido en varias AZ: si la instancia o la AZ caen, se lanza otra automáticamente.
• Recuperación automática de EC2 (auto recovery) ante fallos del hardware subyacente, o una alarma de CloudWatch con la acción recover sobre StatusCheckFailed_System.
• Base de datos en RDS Multi-AZ y RDS Proxy para que el failover sea transparente y las conexiones no se agoten.
• EFS o FSx como almacenamiento compartido en lugar de un disco local.
• Route 53 failover hacia una página estática en S3 o hacia otra región.
• AWS Elastic Disaster Recovery (DRS, ver más abajo) para replicar servidores enteros a AWS sin tocar la aplicación.

Visibilidad de la carga de trabajo

Para operar sistemas distribuidos necesitas las tres señales: métricas (CloudWatch), logs (CloudWatch Logs) y trazas (AWS X-Ray, visto en el módulo 08: sigue una petición a través de API Gateway, Lambda, servicios y bases de datos, y muestra dónde está la latencia o el error). CloudWatch Application Signals y ServiceLens unen las tres vistas.

Estrategias de recuperación ante desastres

El whitepaper Disaster Recovery of Workloads on AWS describe cuatro estrategias, de menor a mayor coste y de mayor a menor RTO/RPO. Las cifras orientativas proceden de su figura comparativa (horas; decenas de minutos; minutos; casi tiempo real).

flowchart TB
  subgraph BR["Backup and restore"]
    P1["Región primaria activa"] -->|"copias periódicas"| B1["Región DR: solo backups"]
  end
  subgraph PL["Pilot light"]
    P2["Región primaria activa"] -->|"replicación continua de datos"| B2["Región DR: BD réplica + app apagada"]
  end
  subgraph WS["Warm standby"]
    P3["Región primaria activa"] -->|"replicación continua"| B3["Región DR: todo encendido a escala reducida"]
  end
  subgraph MS["Multi-site active/active"]
    P4["Región A: tráfico"] <-->|"replicación bidireccional"| B4["Región B: tráfico"]
  end

Diferencias finas que el examen pregunta

• Pilot light frente a warm standby: el pilot light no puede atender peticiones sin antes arrancar o desplegar servidores; el warm standby ya atiende tráfico, solo hay que escalarlo.
• Hot standby es active/passive con el entorno de DR a plena capacidad pero sin tráfico; active/active reparte tráfico entre regiones.
• Réplica continua ≠ copia de seguridad: la replicación también copia la corrupción o el borrado. Combina réplica (RPO bajo) con copias puntuales (point-in-time) y versionado de S3 para protegerte de errores humanos y ransomware.
• IaC imprescindible: con backup and restore, sin CloudFormation el RTO se dispara porque hay que reconstruir a mano.
• Prueba la recuperación: una estrategia que nunca se ha ensayado no cumple su RTO.

Piezas de AWS para DR

• AWS Backup: planes de copia centralizados (EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3, Storage Gateway…), copia entre regiones y entre cuentas, retención por reglas y AWS Backup Vault Lock (bóveda inmutable, modo WORM) contra borrados maliciosos. No restaura automáticamente de forma programada: se automatiza con la API (Lambda, Step Functions).
• Snapshots: EBS (copiables entre regiones con aws ec2 copy-snapshot), RDS (copia de snapshot entre regiones), Redshift (copia automática entre regiones).
• Replicación: S3 Cross-Region Replication (con Replication Time Control para un SLA de replicación), réplicas de lectura de RDS entre regiones (se promocionan en la conmutación), Aurora Global Database (réplica típica de menos de un segundo; una región secundaria se promociona en menos de un minuto según el whitepaper), DynamoDB global tables (multi-active, «el último que escribe gana»), ElastiCache Global Datastore, DocumentDB global clusters.
• Conmutación de tráfico: Route 53 con registros failover y health checks (plano de datos); Amazon Application Recovery Controller (ARC) para conmutaciones controladas manualmente con «interruptores»; Global Accelerator con IP estáticas anycast y traffic dials; CloudFront origin failover por petición.
• Escalado en DR: Auto Scaling (sube la capacidad deseada); cuotas ampliadas por adelantado.
• AWS Elastic Disaster Recovery (DRS): replica de forma continua, a nivel de bloque, servidores físicos, virtuales o en otras nubes (y EC2) a un área de staging barata en AWS; al conmutar lanza la capacidad completa. Implementa una estrategia de tipo pilot light con RPO de segundos y RTO de minutos. No figura en la lista de servicios in-scope de la guía, así que no profundizamos: si aparece en una opción, reconoce su papel («DR de servidores on-premises a AWS con mínima infraestructura»).
• AWS Resilience Hub: evalúa si una aplicación cumple su RTO/RPO objetivo y recomienda mejoras (tampoco figura en la lista in-scope).

Amazon CloudWatch

Amazon CloudWatch es el servicio de monitorización y observabilidad: recoge métricas, logs y eventos, dispara alarmas y muestra paneles.

Métricas

• Una métrica es una serie temporal identificada por namespace (por ejemplo, AWS/EC2), nombre y dimensiones (pares nombre/valor como InstanceId=i-123; hasta 30 por métrica).
• Las métricas son regionales; no se borran, caducan a los 15 meses sin datos nuevos.
• Retención según resolución: puntos de menos de 60 s (alta resolución) durante 3 horas; de 1 minuto, 15 días; de 5 minutos, 63 días; de 1 hora, 455 días (15 meses). Los datos antiguos se agregan a menor resolución.
• Resolución: estándar (1 minuto) o alta resolución (1 segundo) solo para métricas personalizadas.
• EC2: basic monitoring publica cada 5 minutos sin coste; detailed monitoring cada 1 minuto con coste. Las status checks son de 1 minuto y gratuitas.
• Lo que EC2 no envía por defecto: memoria, espacio en disco usado y procesos. Los ve el hipervisor desde fuera, no el sistema operativo. Para eso necesitas el CloudWatch agent (unificado), que también envía logs del sistema y de las aplicaciones.
• Métricas personalizadas: con la API PutMetricData (o el Embedded Metric Format en logs). Ejemplo: pedidos pendientes, usuarios conectados. Se cobran por métrica.
• Estadísticas y percentiles: media, suma, mínimo, máximo, p90/p99 (mejor que la media para latencia).
• Metric math, anomaly detection (bandas esperadas aprendidas con ML) y Metrics Insights (consultas SQL sobre métricas).

Alarmas

• Metric alarm: vigila una métrica o una expresión y compara con un umbral (estático o banda de anomalía) durante N periodos; se puede configurar M out of N (datapoints to alarm) para evitar falsas alarmas.
• Estados: OK, ALARM e INSUFFICIENT_DATA. Puedes decidir cómo tratar los datos que faltan (treat missing data).
• Acciones: notificar a un tema SNS (correo, SMS, Lambda, chat), acciones de EC2 (stop, terminate, reboot, recover), políticas de EC2 Auto Scaling, crear OpsItems o incidentes de Systems Manager e iniciar investigaciones.
• Composite alarm: combina el estado de otras alarmas con una regla lógica (AND, OR, NOT) para reducir el ruido; solo puede notificar, no ejecutar acciones de EC2 ni de Auto Scaling.
• Las acciones se disparan al cambiar de estado (salvo las de Auto Scaling, que se repiten mientras dura el estado).
• Alarmas de facturación: la métrica EstimatedCharges se publica en us-east-1 tras activar Receive CloudWatch Billing Alerts en las preferencias de facturación. Solo compara el gasto acumulado real; AWS Budgets además hace previsiones y tiene acciones.

CloudWatch Logs

• Log groups (por aplicación) y log streams (por instancia, contenedor o función). Retención configurable por grupo (por defecto, indefinida: configúrala para no pagar almacenamiento de más).
• Llegan logs de Lambda, API Gateway, ECS, VPC Flow Logs, Route 53, CloudTrail, el CloudWatch agent…
• Metric filters: convierten patrones de log en métricas (por ejemplo, contar ERROR) y así puedes poner alarmas.
• Subscription filters: envían los logs en tiempo casi real a Lambda, Data Firehose, Kinesis Data Streams u OpenSearch (por ejemplo, centralizar logs de muchas cuentas).
• Exportar a S3 para archivo barato y análisis con Athena.
• Cifrado con KMS y protección de datos (enmascarar datos sensibles).
• CloudWatch Logs Insights: lenguaje de consulta interactivo para buscar y agregar en logs. Ejemplo:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errores by bin(5m)
| sort errores desc

Logs Insights cobra por GB escaneado (la capa gratuita de CloudWatch incluye 5 GB de datos de logs al mes entre ingesta, archivo y escaneo, según la página de precios consultada el 30/09/2026). Existen también log alarms sobre consultas programadas de Logs Insights.

Dashboards y otras funciones

• Dashboards: paneles con gráficos de métricas, alarmas y resultados de logs; pueden mostrar datos de varias regiones y cuentas (observabilidad entre cuentas).
• Synthetics (canaries que prueban tu web o API cada pocos minutos), RUM (experiencia real de usuarios), Container Insights y Lambda Insights, Application Signals.
• Capa gratuita (página de precios, 30/09/2026): 10 métricas personalizadas o de monitorización detallada, 10 métricas de alarma, 3 dashboards personalizados de hasta 50 métricas y 5 GB de logs.

AWS Health Dashboard, Trusted Advisor, Managed Grafana y Managed Service for Prometheus

AWS Health Dashboard

El AWS Health Dashboard (antes Personal Health Dashboard y Service Health Dashboard) muestra el estado de los servicios de AWS y, sobre todo, los eventos que afectan a tus recursos: incidencias en tu región, mantenimientos programados (reinicio de instancias por mantenimiento del hardware, parches de RDS), notificaciones de fin de soporte, problemas de certificados, etc. Es gratuito, no requiere configuración, y los eventos se pueden consumir con Amazon EventBridge para automatizar respuestas (por ejemplo, avisar al canal de guardia o lanzar un runbook). Con AWS Organizations hay vista organizativa. La API de Health requiere un plan de soporte de nivel empresarial (Business Support+, Enterprise o equivalente).

Señal: «recibir aviso automático cuando AWS programe un mantenimiento que afecte a nuestras instancias» → AWS Health + EventBridge.

AWS Trusted Advisor

Trusted Advisor revisa tu cuenta contra buenas prácticas en seis categorías: cost optimization, performance, security, fault tolerance, service limits y operational excellence. Ejemplos: instancias EC2 infrautilizadas, volúmenes EBS sin adjuntar, Elastic IP sin asociar, buckets S3 con permisos abiertos, security groups con puertos abiertos al mundo, MFA en el usuario raíz, instancias RDS sin Multi-AZ, cuotas cerca del límite.

Con los planes de soporte Basic o Developer solo tienes las comprobaciones de service limits y unas pocas de seguridad y tolerancia a fallos (snapshots públicos de EBS y RDS, permisos de buckets S3, MFA en root, puertos específicos abiertos en security groups…). El conjunto completo y la API requieren planes superiores (la documentación de 2026 cita Business Support+, Enterprise y Unified Operations; los planes Developer y Business dejan de ofrecerse el 01/01/2027).

Amazon Managed Grafana

Servicio gestionado de Grafana (paneles de observabilidad de código abierto). Crea workspaces con autenticación mediante IAM Identity Center o SAML y se conecta a múltiples fuentes: CloudWatch, Amazon Managed Service for Prometheus, OpenSearch, X-Ray, Athena, Redshift y fuentes de terceros. Señal: «paneles operativos unificados de varias cuentas y fuentes de datos, con Grafana, sin gestionar servidores».

Amazon Managed Service for Prometheus (AMP)

Servicio gestionado y compatible con Prometheus para métricas de contenedores (sobre todo EKS y Kubernetes): ingiere, almacena y consulta con PromQL, escala solo y es multi-AZ. Señal: «ya usamos Prometheus en Kubernetes y queremos dejar de operar su almacenamiento» → AMP (y Managed Grafana para visualizar).

AWS CloudFormation

AWS CloudFormation es la infraestructura como código (IaC) nativa de AWS: describes los recursos en una plantilla YAML o JSON y CloudFormation los crea, actualiza y borra como una unidad llamada stack (pila), en el orden correcto de dependencias. Es gratuito para recursos de AWS (pagas los recursos creados).

Anatomía de una plantilla

AWSTemplateFormatVersion: "2010-09-09"
Description: Bucket versionado con alarma de ejemplo
Parameters:
  Entorno:
    Type: String
    AllowedValues: [dev, prod]
    Default: dev
Conditions:
  EsProd: !Equals [!Ref Entorno, prod]
Resources:
  Bucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    Properties:
      VersioningConfiguration:
        Status: Enabled
  Tema:
    Type: AWS::SNS::Topic
    Condition: EsProd
Outputs:
  NombreBucket:
    Value: !Ref Bucket

Funciones intrínsecas habituales: !Ref, !GetAtt, !Sub, !Join, !FindInMap, !If, !ImportValue. Pseudoparámetros: AWS::Region, AWS::AccountId, AWS::StackName. Referencias dinámicas para no escribir secretos en la plantilla: {{resolve:ssm:/ruta}} y {{resolve:secretsmanager:...}} (siempre dentro de la plantilla, nunca en texto plano).

Ciclo de vida y funciones clave

• Rollback automático: si falla la creación o actualización, CloudFormation deshace los cambios.
• Change sets: antes de actualizar, generas un conjunto de cambios que muestra qué recursos se añadirán, modificarán o reemplazarán (con posible pérdida de datos). Lo revisas y lo ejecutas. Respuesta a «previsualizar el impacto de un cambio en producción».
• Drift detection: detecta si alguien cambió recursos fuera de CloudFormation (a mano en la consola) y muestra las diferencias con la plantilla.
• StackSets: despliega el mismo stack en varias cuentas y regiones con una operación. Con permisos service-managed se integra con AWS Organizations y puede desplegar automáticamente en las cuentas nuevas de una OU (por ejemplo, un rol de auditoría o reglas de Config en toda la organización).
• Nested stacks: reutilizar componentes (una plantilla de VPC dentro de otras).
• DeletionPolicy (Retain, Snapshot, Delete) y UpdateReplacePolicy: conservar o hacer snapshot de un recurso al borrar el stack o al reemplazarlo. Clave para bases de datos.
• Stack policies (qué recursos pueden actualizarse) y termination protection (evitar borrados accidentales).
• CreationPolicy / WaitCondition con cfn-signal: esperar a que la instancia termine de configurarse; cfn-init aplica configuración declarada en Metadata.
• Importar recursos existentes a un stack.
• AWS CDK (fuera del temario) y AWS SAM generan plantillas de CloudFormation.

AWS Systems Manager

AWS Systems Manager (SSM) es el conjunto de herramientas para operar flotas de EC2, servidores locales y máquinas virtuales (managed nodes). Requisitos: SSM Agent instalado (viene en muchas AMI de AWS), un perfil de instancia con permisos (política gestionada AmazonSSMManagedInstanceCore) y conectividad con los endpoints de Systems Manager (por Internet/NAT o con interface VPC endpoints).

Estado real: Incident Manager y Change Manager están en mantenimiento desde el 07/11/2025 (no admiten clientes nuevos) y Application Manager desde el 30/06/2026; no los elijas como solución nueva.

AWS Service Catalog

AWS Service Catalog permite a los administradores publicar un catálogo de productos aprobados (plantillas de CloudFormation o Terraform: una VPC estándar, un entorno de desarrollo, una base de datos con cifrado) agrupados en portfolios. Los usuarios finales lanzan esos productos en autoservicio sin necesitar permisos directos sobre los servicios subyacentes: una launch constraint indica el rol de IAM con el que se crean los recursos. Otras restricciones limitan parámetros (tipos de instancia permitidos) y aplican etiquetas (TagOptions). Los portfolios se comparten con otras cuentas o con toda la organización.

Señal: «los desarrolladores deben poder desplegar solo configuraciones aprobadas y conformes, sin darles permisos amplios» → Service Catalog.

Gestión de costes: visibilidad y control

Los task statements 4.1 a 4.4 repiten dos puntos de conocimiento: AWS cost management service features (cost allocation tags, multi-account billing) y AWS cost management tools with appropriate use cases (AWS Cost Explorer, AWS Budgets, AWS Cost and Usage Report). Aquí están todos.

Facturación multicuenta (consolidated billing)

Con AWS Organizations, la cuenta de administración paga una única factura por todas las cuentas miembro. Ventajas:

• Descuentos por volumen agregados (por ejemplo, tramos de S3 o transferencia de datos se calculan con el uso sumado).
• Reserved Instances y Savings Plans compartidos entre cuentas de la organización (se puede desactivar el reparto).
• Visión global del gasto en Cost Explorer y presupuestos por cuenta.

AWS Cost Explorer

Herramienta para visualizar y analizar costes y uso: filtros y agrupaciones por servicio, cuenta, región, etiqueta o tipo de compra. Según la documentación actual muestra hasta 13 meses de histórico y previsión de los próximos 18 meses; los datos se refrescan al menos cada 24 horas. La consola es gratuita; la API cuesta 0,01 USD por petición paginada. Incluye informes de uso y cobertura de Reserved Instances y Savings Plans, recomendaciones de compra y de rightsizing.

Señal: «analizar qué servicios han disparado la factura en los últimos meses» o «prever el gasto» → Cost Explorer.

AWS Budgets

AWS Budgets fija presupuestos y avisa (por correo o tema SNS, y a través de SNS en aplicaciones de chat) cuando el gasto real o el previsto supera un umbral. Tipos:

• Cost budget (coste) y usage budget (uso: horas, GB).
• RI utilization / RI coverage y Savings Plans utilization / coverage: avisan si infrautilizas lo comprado o si baja la cobertura.
• Periodos mensuales, trimestrales, anuales o personalizados; plantilla zero spend budget para avisar en cuanto haya cualquier gasto.
• Budget actions: al superar el umbral, aplicar una política de IAM o una SCP que impida crear recursos, o detener instancias EC2 o RDS concretas; automáticamente o con aprobación manual.
• Los datos se actualizan hasta tres veces al día: hay retraso, no es un corte instantáneo.
• Precio (research del 30/09/2026): monitorizar y notificar es gratis; las dos primeras action-enabled budgets también; después, 0,10 USD al día por presupuesto con acciones.

Señal: «avisar cuando el gasto previsto del mes supere 1.000 USD» o «impedir automáticamente nuevos recursos si se supera el presupuesto» → Budgets (con budget actions).

AWS Cost and Usage Report y AWS Data Exports

El AWS Cost and Usage Report (CUR) es el conjunto de datos de facturación más detallado: cada línea de uso por recurso, por hora o día, con etiquetas, descuentos y amortizaciones. Hoy se genera con AWS Data Exports, que ofrece CUR 2.0 (el formato recomendado; el CUR anterior queda como legacy), exportaciones FOCUS, recomendaciones de Cost Optimization Hub y emisiones de carbono. Se entrega de forma periódica en Amazon S3 (CSV o Parquet) y se analiza con Athena, Redshift o Amazon Quick (incluye un panel de costes preconstruido).

Señal: «análisis personalizado y granular de la factura con SQL», «repartir costes internamente con el máximo detalle», «integrar la facturación en el data lake» → CUR / Data Exports + Athena.

Etiquetas de asignación de costes

Una etiqueta es un par clave-valor en un recurso (CentroCoste=Marketing, Proyecto=Tienda). Para que aparezca en la facturación hay que activarla como etiqueta de asignación de costes en la consola de Billing, desde la cuenta de administración (o la cuenta independiente). Hay dos tipos:

• User-defined (las que creas tú; prefijo user: en los informes).
• AWS-generated (por ejemplo, aws:createdBy; prefijo aws:).

Pueden tardar hasta 24 horas en aparecer y, en general, no son retroactivas (existe una función de backfill limitada). Se usan en Cost Explorer, Budgets y el CUR. Para imponer etiquetado: tag policies de Organizations, SCP que exijan etiquetas al crear recursos, AWS Config y Service Catalog (TagOptions). Complemento: AWS Cost Categories para agrupar costes con reglas.

Otras herramientas

• AWS Cost Anomaly Detection: detecta gastos anómalos con ML y avisa.
• AWS Pricing Calculator: estimar el coste de una arquitectura antes de construirla.
• Billing console / Bills: factura detallada por servicio y región.
• Free Tier usage alerts: aviso al acercarte a los límites gratuitos.

¿Qué herramienta de costes uso?

Optimización de costes: opciones de compra y right-sizing

Opciones de compra de cómputo (resumen)

Pagos de RI y Savings Plans: All Upfront, Partial Upfront o No Upfront (más descuento cuanto más adelantas). También hay reservas para RDS, ElastiCache, Redshift, OpenSearch y capacidad reservada de DynamoDB.

Savings Plans frente a Reserved Instances

Right-sizing y AWS Compute Optimizer

Right-sizing es ajustar el tamaño y tipo de cada recurso a su uso real: medir (CloudWatch, con el agente para memoria), analizar, cambiar y repetir. Antes de comprar compromisos, redimensiona: si compras RI para instancias sobredimensionadas, fijas el despilfarro durante años.

AWS Compute Optimizer analiza métricas de CloudWatch (por defecto, 14 días; hasta 93 días con enhanced infrastructure metrics, de pago) y recomienda tamaños o detecta recursos ociosos en: EC2, Auto Scaling groups, EBS, Lambda (memoria), ECS en Fargate, RDS y Aurora, NAT Gateway, DynamoDB, ElastiCache, licencias comerciales y otros. Hay que activarlo (opt in); a nivel de organización, desde la cuenta de administración.

Patrones de ahorro por capa

Almacenamiento (4.1) (a fondo en el módulo 03):

• Clase de S3 según el acceso; lifecycle hacia Standard-IA, Glacier Instant/Flexible Retrieval o Deep Archive; Intelligent-Tiering si el patrón es desconocido.
• Requester Pays cuando son otros quienes descargan tus datos.
• EBS: gp3 en lugar de gp2 (IOPS y rendimiento independientes del tamaño), st1/sc1 (HDD) para acceso secuencial o frío, borrar volúmenes sin adjuntar y snapshots antiguos (con Amazon Data Lifecycle Manager o AWS Backup), archivado de snapshots.
• EFS con clases IA y Archive y ciclo de vida; FSx con deduplicación y compresión.
• Subidas agrupadas (batch uploads) y multipart; transferencia más barata según volumen y plazo: Internet, DataSync, Direct Connect o transferencia offline.
• Estrategia de backup con retenciones distintas por criticidad (AWS Backup) y archivado en clases frías.

Cómputo (4.2) (módulos 02 y 08):

• Familia correcta (memoria, cómputo, almacenamiento, GPU) y Graviton (mejor precio-rendimiento).
• Auto Scaling para seguir la demanda; programar el apagado de entornos no productivos; hibernación para arranques rápidos sin pagar cómputo parado.
• Serverless (Lambda, Fargate) para cargas intermitentes; contenedores para mejor densidad.
• Spot para lo tolerante a interrupciones; Savings Plans para la base estable.
• Disponibilidad según la clase de carga: producción multi-AZ; desarrollo en una AZ y apagado por la noche.
• ALB (capa 7), NLB (capa 4) o GWLB (appliances) según necesidad: no pagues un balanceador que no aporta.

Bases de datos (4.3) (módulo 04):

• Aurora Serverless v2 o DynamoDB on-demand para tráfico variable; DynamoDB provisioned con auto scaling y capacidad reservada para tráfico estable.
• Caché (ElastiCache, DAX) para reducir lecturas y tamaño de la base de datos.
• Réplicas de lectura solo si hay carga de lectura; RDS Proxy para no sobredimensionar por conexiones.
• Retención de backups y frecuencia de snapshots acordes al RPO; TTL de DynamoDB para borrar datos caducados gratis.
• Motor adecuado: migrar de licencias comerciales a PostgreSQL/MySQL o Aurora con DMS y Schema Conversion; tipos específicos (series temporales, columnar para analítica en Redshift).

Red (4.4) (módulos 05 y 06):

• Gateway VPC endpoints (S3, DynamoDB) gratuitos en lugar de pasar por NAT Gateway; interface endpoints cuando compense.
• NAT Gateway por AZ (resiliencia) frente a uno compartido (más barato pero con tráfico entre AZ y punto único de fallo); NAT instance solo si el coste manda y aceptas gestionarla.
• Mantener el tráfico dentro de la misma AZ cuando sea posible; evitar transferencia entre regiones innecesaria.
• CloudFront para reducir la salida a Internet y la carga del origen.
• Direct Connect para grandes volúmenes constantes (transferencia de salida más barata); VPN para volúmenes bajos o como respaldo; elegir la velocidad de Direct Connect o varias VPN según el ancho de banda.
• Transit Gateway frente a VPC peering: peering no cobra por hora y es más barato para pocas VPC; Transit Gateway simplifica a gran escala.
• Throttling en API Gateway (y colas) para proteger los backends y no escalar sin control.
• Revisar periódicamente la red con Cost Explorer (tipo de uso DataTransfer), VPC Flow Logs y Trusted Advisor.

Migración a AWS

Las 7 R

Estrategias de migración según AWS Prescriptive Guidance:

AWS recomienda para migraciones grandes rehost, replatform, relocate y retire, y modernizar (refactor) después.

Herramientas

• AWS Application Migration Service (MGN): la herramienta recomendada para rehost. Instalas un agente en los servidores de origen (físicos, virtuales u otras nubes); replica de forma continua a nivel de bloque a un área de staging de bajo coste; lanzas instancias de prueba sin cortar el origen y, cuando validas, el cutover tarda minutos. La documentación de 2026 la llama ya AWS Transform MGN; la guía del examen mantiene el nombre AWS Application Migration Service. Sustituyó a Server Migration Service (cerrado en 2023).
• AWS DMS (módulo 04): migración de bases de datos homogénea o heterogénea con carga completa y CDC (replicación continua) para minimizar la parada; con Schema Conversion para cambiar de motor.
• AWS DataSync, Transfer Family, Snow Family (concepto), Storage Gateway para datos (módulo 03).
• Migrar a contenedores (task 2.1): contenerizar aplicaciones existentes (por ejemplo, con AWS App2Container para .NET y Java) y ejecutarlas en ECS, EKS o Fargate; es un replatform.
• AWS Migration Hub y AWS Application Discovery Service servían para seguir la migración y descubrir servidores y dependencias, pero están en mantenimiento (no admiten clientes nuevos desde octubre-noviembre de 2025) y no figuran en la lista in-scope. Si aparecen en una pregunta antigua, reconoce su función.

Trampas típicas del examen

• Multi-AZ no es DR entre regiones. «Sobrevivir a la caída de una región» exige otra región.
• Réplicas de lectura de RDS en la misma región mejoran lectura, no son la respuesta de alta disponibilidad de escritura (eso es Multi-AZ); una réplica entre regiones sí sirve para DR (se promociona).
• Pilot light vs warm standby: ¿el entorno de DR ya atiende tráfico? Si sí, warm standby.
• Backup and restore es la opción más barata, no la más rápida.
• Replicación sin backups no protege contra corrupción ni borrado.
• Cuotas en la región de DR: auméntalas antes del desastre.
• Memoria y disco en EC2 requieren el CloudWatch agent.
• Basic monitoring = 5 minutos; para 1 minuto, detailed monitoring.
• CloudTrail registra quién hizo qué llamada a la API; CloudWatch mide y alerta; Config registra configuraciones y cumplimiento; X-Ray traza peticiones.
• CloudFormation drift detecta cambios manuales en recursos del stack; AWS Config evalúa reglas de cumplimiento en toda la cuenta.
• Session Manager sustituye a bastion y claves SSH.
• Parameter Store para configuración barata; Secrets Manager cuando hace falta rotación automática de credenciales.
• Budgets avisa y actúa; Cost Explorer analiza y prevé; CUR da el detalle máximo.
• Etiquetas sin activar no aparecen en la facturación.
• Savings Plans no reservan capacidad; las RI zonales y las Capacity Reservations sí.
• Spot nunca para cargas que no toleran interrupciones (bases de datos principales, nodos core de EMR con datos en HDFS).
• Compute Optimizer recomienda tamaños; Trusted Advisor revisa buenas prácticas (y en planes básicos tiene pocas comprobaciones).
• Nombres: AWS Health Dashboard (antes Personal Health Dashboard), Application Migration Service / AWS Transform MGN (no SMS).

Resumen

• Well-Architected: seis pilares (excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes, sostenibilidad), cada uno con sus principios; la Well-Architected Tool sirve para revisar cargas.
• Alta disponibilidad = multi-AZ sin puntos únicos de fallo; DR = otra región con estrategia elegida por RTO, RPO y coste.
• DR de más barato a más rápido: backup and restore, pilot light, warm standby, multi-site active/active. Combina replicación con copias puntuales y prueba la recuperación.
• Estabilidad estática frente a recuperación dinámica; usa el plano de datos para conmutar; cuotas preparadas en la región de DR.
• CloudWatch: métricas (5 min básico, 1 min detallado, alta resolución personalizada), agente para memoria y disco, alarmas (con acción recover y compuestas), Logs con metric filters, Logs Insights y dashboards.
• CloudFormation: plantillas, stacks, change sets, drift, StackSets; Systems Manager para operar sin SSH y parchear; Service Catalog para autoservicio gobernado.
• Costes: Organizations (factura consolidada), Cost Explorer, Budgets (con acciones), CUR 2.0, etiquetas activadas, Savings Plans y RI, Spot, Compute Optimizer y right-sizing antes de comprometer.
• Migración: 7 R; Application Migration Service para rehost; DMS para bases de datos.

Cobertura del temario

Task 2.2: Design highly available and/or fault-tolerant architectures

Tasks 4.1-4.4: puntos transversales de costes

Task 2.1: puntos tratados aquí

Practica lo aprendido

Documentación oficial para ampliar

• AWS Well-Architected Framework – The pillars of the framework
• Disaster Recovery of Workloads on AWS – Disaster recovery options in the cloud
• Amazon CloudWatch – Metrics concepts
• Using Amazon CloudWatch alarms
• CloudFormation template sections
• CloudFormation StackSets
• AWS Systems Manager Session Manager
• Savings Plans types
• Managing your costs with AWS Budgets
• What is AWS Data Exports?
• AWS cost allocation tags
• What is AWS Compute Optimizer?
• AWS Prescriptive Guidance – Migration strategies (7 Rs)