Semana 2 · Módulo 2 de 11

Cómputo con EC2: instancias, EBS, compra, balanceo y escalado

Amazon EC2 de principio a fin: familias y tamaños, AMI, user data, IMDSv2, placement groups e hibernación; EBS e instance store; opciones de compra con sus descuentos; Elastic Load Balancing (ALB, NLB, GWLB) y EC2 Auto Scaling con todas sus políticas. Cubre las tareas 3.2 y 4.2 y buena parte de la 2.2.

Reparto de la semana

Por qué importa

EC2 es el servicio del que depende medio examen: aunque la respuesta final sea Lambda o Fargate, muchas preguntas parten de «una aplicación en EC2 que…». Esta semana cubre tres task statements casi enteros:

• 3.2 Design high-performing and elastic compute solutions: elegir tipo de instancia, escalar según métricas, desacoplar.
• 4.2 Design cost-optimized compute solutions: Spot, Savings Plans, Reserved Instances, tamaño correcto, balanceador adecuado, hibernación.
• 2.2 Design highly available and/or fault-tolerant architectures: multi-AZ con ELB y Auto Scaling, health checks, infraestructura inmutable.

Calificadores que vas a ver una y otra vez: MOST cost-effective (Spot, Savings Plans, tamaño correcto), can be interrupted / fault-tolerant batch (Spot), steady-state for 3 years (Savings Plans o RI), unpredictable traffic (Auto Scaling, serverless), static IP / millions of requests per second / TCP/UDP (NLB), path-based routing (ALB), third-party firewall appliances (GWLB), lowest latency between nodes (cluster placement group), BYOL per-socket licenses (Dedicated Hosts).

1. Amazon EC2 a fondo

Amazon Elastic Compute Cloud (EC2) ofrece máquinas virtuales (instancias) que lanzas en minutos y pagas por segundo (con un mínimo de 60 segundos en Linux, Windows, RHEL y Ubuntu, según la página de precios). Una instancia se define por:

• AMI (Amazon Machine Image): la plantilla con el sistema operativo y el software.
• Tipo de instancia: CPU, memoria, red y almacenamiento local.
• Almacenamiento: volúmenes EBS y, en algunos tipos, instance store.
• Red: subred (y por tanto AZ), security groups, IP pública o Elastic IP.
• Rol de IAM (perfil de instancia) y user data.

Estados y cobro: pending → running (se cobra) → stopping/stopped (no se cobra la instancia, sí los volúmenes EBS y las IPv4 públicas asociadas como Elastic IP) → terminated (desaparece). Un reboot conserva IP, disco e instance store; un stop/start mueve la instancia a otro host (pierdes instance store y la IPv4 pública automática cambia).

1.1 Tipos de instancia: familias, generaciones y tamaños

El nombre se lee así (convención oficial): c7gn.xlarge = serie c (optimizada para cómputo), generación 7, opciones g (procesador AWS Graviton) y n (optimizada para red y EBS), tamaño xlarge. Opciones frecuentes: a AMD, g Graviton (Arm), i Intel, d con discos instance store, n red mejorada, e memoria o almacenamiento extra, z alta frecuencia de CPU, flex instancias Flex. El sufijo .metal indica bare metal (sin hipervisor, acceso directo al hardware).

Burstable (T): acumulan créditos de CPU mientras están por debajo de su baseline (por ejemplo, un t3.micro tiene un 10 % por vCPU) y los gastan al superarlo. En modo standard, al agotar los créditos bajan a la baseline; en modo unlimited pueden seguir por encima pagando un recargo si la media de 24 h supera la baseline. T3, T3a y T4g se lanzan en modo unlimited por defecto (T2, en standard). Si ves CPUCreditBalance a cero y la aplicación lenta, la instancia T no es la adecuada para esa carga sostenida: pasa a M o C.

Graviton (procesadores Arm de AWS, sufijo g): AWS los posiciona con mejor relación precio-rendimiento que x86 equivalentes; requieren software compatible con Arm (la mayoría de lenguajes interpretados y contenedores multiarquitectura lo son).

Virtualización y sistema Nitro: las instancias actuales se ejecutan sobre AWS Nitro System, que descarga red, almacenamiento y seguridad en hardware dedicado. Algunas funciones solo existen en Nitro (por ejemplo, el máximo de IOPS de io2 Block Express o Multi-Attach). Las .metal permiten ejecutar tu propio hipervisor o software que exige hardware físico.

Escalado vertical frente a horizontal:

Tamaño correcto (rightsizing): empieza pequeño, mide con CloudWatch y ajusta. AWS Compute Optimizer (sección 6.3) automatiza las recomendaciones.

1.2 AMI (Amazon Machine Image)

Una AMI contiene los snapshots de los volúmenes (o la plantilla del instance store), los permisos de lanzamiento y el mapeo de dispositivos de bloque.

• Son regionales: para usarlas en otra región, cópialas (aws ec2 copy-image); al copiar puedes cifrarlas.
• Se pueden compartir con otras cuentas o con la organización, y publicar en AWS Marketplace (AMI de terceros con licencia incluida).
• Golden AMI (AMI «dorada» con todo preinstalado) frente a user data (configuración al arrancar): la AMI arranca más rápido (clave para escalar deprisa); el user data es más flexible. Lo habitual es combinarlos: AMI con lo pesado y user data para lo que cambia. EC2 Image Builder automatiza la creación y el parcheo de AMI.
• Las AMI de Amazon Linux 2023 se localizan con parámetros públicos de SSM, por ejemplo /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64, que puedes usar directamente al lanzar con resolve:ssm:.

1.3 User data

Script (o directivas #cloud-config) que la instancia ejecuta como root en el primer arranque (por defecto solo entonces). Límite: 16 KB antes de codificar en base64. La CLI con run-instances codifica por ti; en una launch template creada con la API debes pasarlo en base64. El registro está en /var/log/cloud-init-output.log. El user data no se copia al crear una AMI desde la instancia y no es un lugar para secretos: cualquiera con acceso a los metadatos de la instancia lo puede leer (usa Secrets Manager o Parameter Store, módulo 07).

#!/bin/bash
dnf install -y nginx
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
AZ=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/availability-zone)
echo "Hola desde $AZ" > /usr/share/nginx/html/index.html
systemctl enable --now nginx

1.4 Metadatos de instancia e IMDSv2

El Instance Metadata Service (IMDS) responde en 169.254.169.254 (o [fd00:ec2::254] en IPv6 en instancias Nitro) con datos de la instancia: ID, AZ, IP, user data y, muy importante, las credenciales temporales del rol del perfil de instancia (/latest/meta-data/iam/security-credentials/<rol>).

• IMDSv1: petición/respuesta sin sesión. Vulnerable si un atacante consigue que la aplicación haga peticiones por él (SSRF, proxies inversos mal configurados).
• IMDSv2: orientado a sesión. Primero un PUT a /latest/api/token con la cabecera X-aws-ec2-metadata-token-ttl-seconds (de 1 segundo a 6 horas) devuelve un token; luego cada GET lleva la cabecera X-aws-ec2-metadata-token. Los PUT con cabecera X-Forwarded-For se rechazan y la respuesta al PUT tiene por defecto un hop limit de 1, así que no sale de la instancia (súbelo a 2 si usas contenedores que deben acceder al IMDS).
• Buena práctica: exigir IMDSv2 (HttpTokens=required) en las launch templates y en la configuración por defecto de la cuenta. Con required, una petición sin token recibe 401 Unauthorized.

aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-put-response-hop-limit 1

1.5 Placement groups

Controlan cómo se reparten las instancias sobre el hardware (documentación). No tienen coste.

También existen los precision time placement groups (sincronización horaria de microsegundos), que no son materia habitual del examen.

1.6 Hibernación

Al hibernar, EC2 guarda el contenido de la RAM en el volumen raíz EBS y detiene la instancia; al arrancar, restaura la memoria: los procesos siguen donde estaban y la «precarga» (cachés calientes) no se pierde. Mientras está hibernada, solo pagas EBS (y las IP que tenga asociadas).

Requisitos verificados (documentación):

• Se habilita al lanzar la instancia; no puedes activarla en una instancia existente.
• RAM inferior a 150 GiB en Linux (hasta 16 GiB en Windows).
• Volumen raíz EBS (no instance store), de un tipo gp2, gp3, io1 o io2, cifrado y con espacio para la RAM.
• Familias compatibles (M, C, R, T, I… de las generaciones listadas; no bare metal) y AMI compatibles (Amazon Linux 2023, Amazon Linux 2, Ubuntu, RHEL, Windows…).
• Disponible para On-Demand y Spot (con solicitud persistent).

Casos de uso: aplicaciones que tardan mucho en arrancar o en calentar cachés, y ahorro apagando por la noche instancias de desarrollo sin perder el estado. La guía del examen la cita expresamente en la tarea 4.2 (scaling strategies… hibernation).

1.7 Red de la instancia, en breve

• ENI (Elastic Network Interface): la tarjeta de red virtual; se puede mover entre instancias de la misma AZ (útil para failover con IP privada fija).
• IPv4 pública automática (cambia al parar/arrancar) frente a Elastic IP (fija hasta que la liberas). Toda IPv4 pública cuesta (0,005 USD/h en eu-south-2, en uso o no).
• Enhanced networking (ENA): más ancho de banda y paquetes por segundo, menor latencia; EFA (Elastic Fabric Adapter): para HPC y ML con MPI/NCCL, se suele combinar con cluster placement groups.
• Security groups: cortafuegos stateful por ENI (módulo 05).
• Acceso sin SSH: EC2 Instance Connect o AWS Systems Manager Session Manager (sin puertos de entrada abiertos, con auditoría). Es la opción preferida en el examen si se pide without opening inbound ports.

2. Almacenamiento de bloque: EBS e instance store

2.1 Amazon EBS

Amazon Elastic Block Store (EBS) son discos de red persistentes para EC2:

• Viven en una AZ y solo se conectan a instancias de esa AZ. Se replican dentro de la AZ.
• Persisten independientemente de la instancia. El volumen raíz tiene DeleteOnTermination activado por defecto; los adicionales, no (se quedan y siguen cobrando).
• Elastic Volumes: cambias tamaño, tipo, IOPS y rendimiento en caliente (después amplías el sistema de ficheros).
• Cifrado con AWS KMS: cifra datos en reposo, en tránsito entre instancia y volumen, y snapshots. Puedes activar el cifrado por defecto por región. Un snapshot de un volumen cifrado da volúmenes cifrados; para cifrar un volumen existente sin cifrar, haz snapshot → copia cifrada → volumen nuevo.
• Se paga por GB aprovisionado al mes (más IOPS y rendimiento extra en gp3/io1/io2), se use o no. Estimación en eu-south-2 (API pública de precios, septiembre de 2026): gp3 0,088 USD por GB-mes y gp2 0,11 USD por GB-mes; comprueba siempre la página de precios de EBS.

Snapshots:

• Copias incrementales a nivel de bloque, almacenadas de forma regional y duradera (AWS usa S3 por debajo, pero no los ves como objetos).
• Sirven para copiar datos entre AZ (snapshot → volumen nuevo en otra AZ) y entre regiones o cuentas (copiar o compartir el snapshot).
• EBS Snapshots Archive: nivel de archivo hasta un 75 % más barato para snapshots que guardas 90 días o más y rara vez restauras (al archivar, el snapshot pasa a ser completo).
• Recycle Bin: reglas de retención para recuperar snapshots y AMI borrados por error.
• Fast Snapshot Restore (FSR): volúmenes creados desde el snapshot rinden al máximo desde el primer momento (sin «calentamiento»), con coste adicional.
• Automatización: Amazon Data Lifecycle Manager o AWS Backup (módulo 03).

2.2 Tipos de volumen EBS (cifras verificadas)

Fuente: Amazon EBS volume types, consultada el 30/09/2026.

Detalles que caen en el examen:

• gp3 es el SSD más barato y la opción por defecto: incluye 3.000 IOPS y 125 MiB/s sin importar el tamaño, y puedes subir IOPS (hasta 500 por GiB, 80.000 como máximo a partir de 160 GiB) y rendimiento (0,25 MiB/s por IOPS, 2.000 MiB/s como máximo) por separado del tamaño. Es un 20 % más barato por GiB que gp2. Migrar de gp2 a gp3 con Elastic Volumes no requiere parada.
• gp2: el rendimiento crece con el tamaño (3 IOPS por GiB; 16.000 IOPS a partir de 5.334 GiB). Los volúmenes pequeños dependen de créditos de ráfaga (métrica BurstBalance). Un clásico: «aumentamos el tamaño de un gp2 solo para tener más IOPS» → hoy se resuelve con gp3.
• io2 Block Express: latencia media inferior a 500 microsegundos, la mayor durabilidad y hasta 256.000 IOPS en instancias Nitro (en otras, se pueden adjuntar volúmenes de hasta 64.000 IOPS pero solo se alcanzan 32.000). Desde el 30/04/2025, todos los volúmenes io2 son Block Express. Para bases de datos críticas (Oracle, SAP HANA, SQL Server) que necesitan más de 80.000 IOPS o latencia submilisegundo sostenida.
• io1: generación anterior; hasta 64.000 IOPS con relación máxima 50:1. Casi siempre io2 es mejor.
• st1: big data, data warehouses, procesamiento de logs: E/S secuencial grande. sc1: datos fríos de acceso poco frecuente con el menor coste por GB. Ninguno de los dos sirve como volumen de arranque.
• El volumen no es lo único que limita: la instancia también tiene un máximo de ancho de banda hacia EBS (instancias EBS-optimized).

flowchart TD
  A["¿Qué necesita el volumen?"] --> B{"¿E/S aleatoria pequeña (IOPS) o secuencial grande (MiB/s)?"}
  B -->|"Aleatoria / transaccional"| C{"¿Más de 80.000 IOPS, latencia submilisegundo o durabilidad 99,999 %?"}
  C -->|Sí| IO2["io2 Block Express"]
  C -->|No| GP3["gp3 (por defecto)"]
  B -->|"Secuencial / streaming"| D{"¿Se accede a menudo?"}
  D -->|"Sí: big data, logs, DW"| ST1["st1"]
  D -->|"No: datos fríos, mínimo coste"| SC1["sc1"]
  A --> E{"¿Varias instancias escriben el mismo volumen en una AZ?"}
  E -->|Sí| MA["io2 con Multi-Attach (o mejor EFS/FSx si basta un sistema de ficheros compartido)"]

2.3 Multi-Attach

Permite conectar un volumen io1 o io2 a hasta 16 instancias Nitro de la misma AZ, todas con lectura y escritura (documentación). Exige un sistema de ficheros de clúster (XFS o ext4 no están diseñados para ello) y que la aplicación ordene las escrituras; no sirve como volumen de arranque. Para compartir ficheros entre muchas instancias y AZ, la respuesta es Amazon EFS o FSx (módulo 03), no Multi-Attach.

2.4 Instance store

Discos físicamente conectados al host de la instancia. Muy rápidos (NVMe en muchas familias con sufijo d, I o D) e incluidos en el precio de la instancia, pero efímeros:

No se pueden separar ni mover a otra instancia. Úsalo para cachés, búferes, datos temporales o datos replicados en varias instancias (por ejemplo, un clúster Cassandra con factor de replicación). Nunca para el único ejemplar de un dato.

2.5 ¿EBS, instance store, EFS o S3?

3. Opciones de compra de EC2

Descuentos máximos verificados en las páginas oficiales de precios de EC2, Savings Plans y Reserved Instances (30/09/2026). Son «hasta»: el descuento real depende de tipo, región, plazo y forma de pago.

Matices importantes:

• RI zonales frente a regionales: una RI zonal reserva capacidad en una AZ; una regional no reserva capacidad, pero su descuento se aplica en cualquier AZ de la región y a distintos tamaños de la familia (flexibilidad de tamaño). Formas de pago de RI: All Upfront, Partial Upfront, No Upfront (más pago por adelantado, más descuento).
• Savings Plans frente a RI: hoy los Savings Plans son la opción recomendada y más flexible; las RI siguen en el examen. Si el enunciado habla de «cambiar de familia de instancia o mover cargas a Fargate/Lambda» → Compute Savings Plans.
• Spot:
  • AWS envía el aviso de interrupción 2 minutos antes (salvo con comportamiento hibernate, que empieza en el acto), como evento de Amazon EventBridge y en los metadatos (/latest/meta-data/spot/instance-action). Comportamientos al interrumpir: terminate, stop o hibernate.
  • La recomendación de reequilibrio (rebalance recommendation) avisa antes cuando el riesgo de interrupción sube; Auto Scaling puede usarla con Capacity Rebalancing.
  • Diversifica tipos de instancia y AZ (EC2 Fleet, Auto Scaling con mixed instances policy) para reducir interrupciones.
• Capacity Blocks for ML: reservas de GPU por periodos cortos para entrenamiento (no admiten placement groups).
• Plan gratuito: no incluye Savings Plans ni Reserved Instances.

4. Elastic Load Balancing (ELB)

Un balanceador reparte el tráfico entre destinos sanos (instancias, IP, contenedores, funciones Lambda) en varias AZ, hace health checks y escala solo. Es la pieza que convierte varias instancias en un servicio altamente disponible y escalable en horizontal.

4.1 Conceptos comunes

• Listener: protocolo y puerto en los que escucha (HTTP 80, HTTPS 443, TCP 5432…). Tiene reglas que envían a target groups.
• Target group: conjunto de destinos con su protocolo, puerto y health check (ruta, intervalo, umbrales). Un destino puede estar en varios target groups.
• Nodos por AZ: al habilitar una AZ, ELB crea un nodo en ella. El nombre DNS del balanceador (TTL de 60 s) resuelve a los nodos. El ALB exige al menos dos AZ.
• Cross-zone load balancing (reparto entre zonas) verificado: en el ALB está siempre activado a nivel de balanceador (se puede desactivar por target group); en NLB y GWLB está desactivado por defecto. Sin él, cada nodo solo reparte entre los destinos de su AZ: con 2 destinos en una AZ y 8 en otra, cada uno de los 2 recibe el 25 % y cada uno de los 8, el 6,25 %.
• Esquema: internet-facing (nodos con IP públicas) o internal (solo IP privadas). Los destinos no necesitan IP pública en ningún caso.
• Deregistration delay (antes connection draining): tiempo que el balanceador sigue atendiendo las peticiones en curso de un destino que se da de baja; por defecto 300 segundos.
• Terminación TLS: el listener HTTPS/TLS usa certificados de AWS Certificate Manager (ACM) y descifra en el balanceador (SSL offloading); con SNI sirve varios certificados en un mismo listener.
• Sticky sessions (afinidad de sesión): envían al mismo cliente al mismo destino (cookie). Parche para aplicaciones con estado; mejor hacerlas stateless.

4.2 Los tres balanceadores actuales

El Classic Load Balancer es la generación anterior: no lo elijas en diseños nuevos (ALB y NLB lo superan en funciones).

flowchart TD
  Q["¿Qué balanceador?"] --> H{"¿Tráfico HTTP/HTTPS y decisiones por URL, host o cabeceras?"}
  H -->|Sí| ALB["ALB (capa 7)<br/>microservicios, WAF, Lambda como destino"]
  H -->|No| T{"¿TCP/UDP, IP estática, millones de peticiones/s o PrivateLink?"}
  T -->|Sí| NLB["NLB (capa 4)"]
  T -->|No| G{"¿Insertar appliances de red de terceros (firewall, IDS/IPS)?"}
  G -->|Sí| GWLB["GWLB (capa 3, GENEVE 6081)"]

4.3 Arquitectura multicapa típica

• ALB internet-facing en subredes públicas de 2-3 AZ → Auto Scaling group de servidores web en subredes privadas → ALB o NLB internal → capa de aplicación → base de datos Multi-AZ.
• Los security groups de los destinos solo admiten tráfico desde el security group del balanceador (referencia entre security groups), no desde 0.0.0.0/0.
• Para acelerar tráfico global con IP estáticas, delante de ALB/NLB de varias regiones va AWS Global Accelerator (módulo 06).

5. EC2 Auto Scaling y AWS Auto Scaling

5.1 El Auto Scaling group

Un Auto Scaling group (ASG, grupo de escalado automático) mantiene un número de instancias entre mínimo y máximo, con una capacidad deseada (desired capacity) que ajustan las políticas. Aporta:

• Alta disponibilidad: reparte instancias entre las AZ de las subredes que le indiques y reequilibra si una AZ se descompensa.
• Autorreparación: sustituye instancias que fallan los health checks.
• Elasticidad: añade y quita capacidad según la demanda (y así ahorras).

Se define con una launch template (plantilla de lanzamiento: AMI, tipo, security groups, perfil de instancia, user data, opciones de metadatos, etiquetas…), versionada. Las antiguas launch configurations ya no se pueden crear en cuentas creadas desde el 01/10/2024: si ves una en material antiguo, piensa en launch templates.

Otras capacidades:

• Mixed instances policy: varios tipos de instancia y mezcla de On-Demand (base + porcentaje) y Spot en el mismo grupo, con estrategias de asignación. Es la forma estándar de usar Spot en un ASG.
• Capacity Rebalancing: sustituye de forma proactiva las instancias Spot que reciben una recomendación de reequilibrio.
• Instance refresh: sustituye instancias por lotes para aplicar una nueva versión de la launch template (despliegues inmutables).
• Warm pools: instancias ya inicializadas y paradas (o hibernadas) listas para entrar en servicio rápido cuando la aplicación tarda mucho en arrancar.
• Maximum instance lifetime: recicla instancias tras un tiempo máximo.
• Scale-in protection y termination policies para controlar qué instancias se eliminan primero.

5.2 Health checks

• EC2 (por defecto): la instancia está running y pasa las comprobaciones de estado del sistema y de la instancia.
• ELB (opcional, recomendado detrás de un balanceador): además, el target group la considera sana. Sin activarlo, una instancia con la aplicación caída pero el sistema operativo vivo no se sustituye.
• También hay comprobaciones de VPC Lattice, de EBS y personalizadas (set-instance-health).
• Health check grace period (periodo de gracia): tiempo tras entrar en servicio en el que el ASG no la marca como no sana. Por defecto 300 segundos si creas el grupo en la consola y 0 con la CLI o un SDK. Si usas un lifecycle hook de lanzamiento para esperar a que la app esté lista, puedes dejarlo en 0.

5.3 Políticas de escalado

Varias políticas a la vez: el ASG elige la que da mayor capacidad (prioriza la disponibilidad); con varias de target tracking, escala hacia fuera si cualquiera lo pide y hacia dentro solo si todas lo permiten.

Escalar con colas SQS: la métrica ApproximateNumberOfMessagesVisible sola no vale para target tracking (no es proporcional al tamaño del grupo). Lo correcto es una métrica personalizada de mensajes pendientes por instancia (backlog per instance) comparada con los que una instancia puede procesar en tu latencia aceptable. Es el patrón de desacoplamiento del módulo 08.

Métricas cada minuto: por defecto EC2 publica métricas cada 5 minutos; activa la monitorización detallada (1 minuto) para que las políticas reaccionen antes.

5.4 Cooldown frente a instance warm-up

• Cooldown (enfriamiento): tras una actividad de escalado simple, el grupo espera (por defecto 300 segundos) antes de otra. No aplica a target tracking, step ni scheduled, ni retrasa la sustitución de instancias no sanas.
• Instance warm-up (calentamiento; recomendado configurar el default instance warmup del grupo): durante ese tiempo una instancia nueva no cuenta en las métricas agregadas del grupo, para no reducir capacidad antes de que la nueva esté realmente sirviendo. Mientras hay instancias calentándose, se bloquean las reducciones de target tracking y step.

5.5 Lifecycle hooks

Pausan una instancia en un estado de espera para ejecutar acciones propias (documentación):

stateDiagram-v2
  [*] --> Pending
  Pending --> PendingWait: hook de lanzamiento
  PendingWait --> PendingProceed: complete-lifecycle-action o timeout
  PendingProceed --> InService
  Pending --> InService: sin hook
  InService --> Terminating: scale in o instancia no sana
  Terminating --> TerminatingWait: hook de terminación
  TerminatingWait --> TerminatingProceed
  TerminatingProceed --> Terminated
  Terminated --> [*]

• Lanzamiento (Pending:Wait): instalar software, descargar configuración, registrar en un sistema externo; así la instancia solo se registra en el balanceador cuando está lista.
• Terminación (Terminating:Wait): copiar logs, vaciar colas, desregistrar la instancia de sistemas externos, hacer un snapshot.
• Tiempo de espera por defecto: 1 hora (heartbeat timeout); puedes ampliarlo enviando heartbeats, hasta un máximo global de 48 horas o 100 veces el heartbeat timeout (lo menor).
• Resultado: CONTINUE o ABANDON (en el lanzamiento, ABANDON termina y sustituye la instancia).
• Notificación: EventBridge (y SNS o SQS configurados por CLI); la acción suele ser una función Lambda o un comando de Systems Manager.
• En Spot, un hook no impide la interrupción con 2 minutos de aviso.

5.6 AWS Auto Scaling (el servicio)

AWS Auto Scaling ofrece scaling plans para configurar en un solo sitio el escalado de varios recursos relacionados: grupos de EC2 Auto Scaling, servicios de Amazon ECS, tablas e índices de Amazon DynamoDB, réplicas de Amazon Aurora y Spot Fleets, con estrategias recomendadas (optimizar disponibilidad, coste o equilibrio). Por debajo usa EC2 Auto Scaling y Application Auto Scaling. AWS recomienda que, si solo quieres escalado predictivo para un ASG, lo configures directamente en el ASG.

5.7 Métricas para escalar según el negocio

Elige la métrica que representa la carga de tu aplicación:

6. Otros servicios de cómputo del temario

6.1 AWS Elastic Beanstalk

PaaS (plataforma como servicio): subes el código (Java, .NET, Node.js, Python, PHP, Ruby, Go, Docker…) y Beanstalk crea y gestiona EC2, Auto Scaling, balanceador, monitorización y parches de la plataforma. Tú mantienes el control de los recursos subyacentes. Entornos web server (detrás de un balanceador) o worker (consumen una cola SQS).

Políticas de despliegue (documentación):

6.2 AWS Batch

Servicio gestionado para ejecutar trabajos por lotes (batch jobs) a cualquier escala: defines job definitions (contenedor, vCPU, memoria), los envías a job queues y Batch aprovisiona los compute environments (EC2 On-Demand, Spot, o Fargate), programa los trabajos y escala a cero al terminar. Admite dependencias entre trabajos y array jobs. No pagas Batch en sí, solo los recursos.

Frente a Lambda: Lambda tiene un límite de ejecución de 15 minutos y recursos acotados; Batch es para trabajos largos, pesados o con GPU. Frente a Amazon EMR (módulo 09): EMR es para frameworks de big data (Spark, Hadoop); Batch, para cualquier contenedor por lotes.

6.3 AWS Compute Optimizer

Analiza configuración y métricas de CloudWatch (por defecto los últimos 14 días; hasta 93 días con la función de pago enhanced infrastructure metrics) y recomienda el tamaño y tipo adecuados o detecta recursos ociosos (documentación). Cubre instancias EC2, grupos de Auto Scaling, volúmenes EBS, funciones Lambda (memoria), servicios ECS en Fargate, licencias comerciales, RDS/Aurora, NAT Gateway y otros. Hay que activarlo (opt in); en una organización, desde la cuenta de administración para verlo todo.

6.4 AWS License Manager

Centraliza la gestión de licencias de software (Microsoft, Oracle, SAP, IBM…) en varias cuentas y regiones: defines reglas por vCPU, núcleos, sockets o nº de máquinas, con límites estrictos o flexibles que pueden impedir lanzar instancias que incumplirían la licencia. Se integra con EC2 (incluidos Dedicated Hosts y host resource groups para BYOL), RDS, Systems Manager (licencias en servidores locales) y Organizations. Es la respuesta cuando el enunciado habla de track license usage o prevent license overages en un modelo BYOL.

6.5 VMware Cloud on AWS

Servicio para ejecutar entornos VMware (vSphere, vSAN, NSX) sobre infraestructura bare metal de AWS, gestionados con las herramientas VMware que ya conoces: migración «tal cual» de centros de datos VMware, extensión híbrida y recuperación ante desastres sin refactorizar. Estado real: desde mayo de 2024 lo vende exclusivamente Broadcom (AWS dejó de revenderlo). La página actual de AWS para VMware promociona Amazon Elastic VMware Service (Amazon EVS) como vía para ejecutar VMware Cloud Foundation en AWS, aunque la guía del examen sigue citando VMware Cloud on AWS. En el examen: migrate VMware workloads to AWS with minimal changes using existing VMware tools → VMware Cloud on AWS.

6.6 AWS Outposts y cómputo híbrido

Recuerda del módulo 01: Outposts lleva EC2, EBS y otros servicios a tu centro de datos con las mismas API. En cómputo, es la respuesta cuando hay latencia mínima con sistemas locales, procesamiento local de datos o residencia en las instalaciones. Para cómputo en el borde cerca de usuarios, Local Zones y Wavelength; para contenido, CloudFront (edge processing con CloudFront Functions y Lambda@Edge, módulo 06).

6.7 ¿EC2, contenedores o serverless?

Adelanto del módulo 08 para las preguntas de coste de la tarea 4.2:

7. Coste y disponibilidad según la clase de carga

La tarea 4.2 pide determining the required availability for different classes of workloads. Una misma empresa no necesita lo mismo en producción que en desarrollo:

Service quotas (cuotas): EC2 limita las instancias On-Demand en ejecución por vCPU y grupo de familias (por ejemplo, Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances), y Spot tiene sus propias cuotas. Consulta y amplía en Service Quotas. En un diseño de DR con un entorno en espera (pilot light, warm standby), amplía antes las cuotas en la región de recuperación: si no, el día del desastre el ASG no podrá lanzar las instancias que necesita.

Infraestructura inmutable: en vez de parchear servidores en marcha, construyes una AMI nueva y sustituyes instancias (instance refresh, despliegue immutable de Beanstalk, blue/green). Reduce la deriva de configuración y facilita volver atrás.

Trampas típicas del examen

• Cluster placement group para alta disponibilidad: no; vive en una AZ. Para HA, spread (pocas instancias) o simplemente varias AZ.
• Spot para una base de datos o un proceso que no admite interrupciones: nunca. Spot es para cargas tolerantes.
• Capacity Reservation para ahorrar: no da descuento; reserva capacidad. El descuento viene de combinarla con Savings Plans o RI regionales.
• RI regional para garantizar capacidad: no reserva capacidad; la RI zonal o la Capacity Reservation sí.
• Dedicated Instance frente a Dedicated Host: BYOL por socket/núcleo o visibilidad del hardware → Host.
• Aumentar el tamaño de un gp2 para tener IOPS: hoy se cambia a gp3 y se aprovisionan las IOPS.
• st1/sc1 como volumen de arranque: no se puede.
• Instance store para datos que deben sobrevivir a una parada: se pierden.
• Multi-Attach para compartir ficheros entre AZ: no; es una sola AZ y exige sistema de ficheros de clúster. Usa EFS.
• NLB para enrutar por ruta URL: no; eso es ALB. ALB con IP fija: no; eso es NLB (o Global Accelerator delante del ALB).
• ASG sin health check de ELB detrás de un balanceador: las instancias con la aplicación caída no se sustituyen.
• Health check grace period demasiado corto: el ASG termina instancias que aún están arrancando (bucle de sustituciones).
• Cooldown con target tracking: no aplica; lo que importa es el warm-up.
• Escalado predictivo para reducir capacidad: solo escala hacia fuera; combínalo con una política dinámica.
• Launch configurations en respuestas modernas: usa launch templates.
• Secretos en user data: legibles desde el IMDS; usa Secrets Manager/Parameter Store y un rol.
• IMDSv1 en un escenario de seguridad: exige IMDSv2.

Resumen

• Familias: M/T general, C cómputo, R/X/U memoria, I/D almacenamiento local, P/G/Inf/Trn aceleradas. T3/T4g: créditos de CPU, unlimited por defecto. Graviton = mejor precio-rendimiento.
• AMI regionales (se copian); user data en el primer arranque (16 KB, como root); IMDSv2 obligatorio como buena práctica.
• Placement groups: cluster (latencia, 1 AZ), partition (7 por AZ, topología), spread (7 instancias por AZ, hardware distinto). Hibernación: RAM a EBS cifrado, menos de 150 GiB, se activa al lanzar.
• EBS: gp3 por defecto (3.000 IOPS/125 MiB/s incluidos, hasta 80.000 IOPS y 2.000 MiB/s), io2 Block Express para lo crítico (256.000 IOPS, 99,999 %), st1/sc1 HDD secuencial/frío. Snapshots incrementales y regionales; archivo 75 % más barato. Instance store efímero.
• Compra: Spot hasta 90 % (2 min de aviso), Savings Plans hasta 72 % (Compute hasta 66 %, cubre Fargate y Lambda), RI Standard hasta 72 %/Convertible hasta 66 %, Dedicated Hosts para BYOL, Capacity Reservations para capacidad sin descuento.
• ELB: ALB (capa 7, rutas, WAF, Lambda), NLB (capa 4, IP estática, millones de peticiones/s, PrivateLink), GWLB (capa 3, appliances, GENEVE 6081).
• Auto Scaling: launch templates, multi-AZ, health checks EC2+ELB, target tracking por defecto, scheduled para picos conocidos, predictive para ciclos, step para control fino; warm-up mejor que cooldown; lifecycle hooks para preparar o drenar instancias.
• Beanstalk (PaaS), Batch (lotes), Compute Optimizer (rightsizing), License Manager (BYOL), VMware Cloud on AWS (VMware tal cual), Outposts (local).

Cobertura del temario

Task statements principales: 3.2 y 4.2 (completos), 2.2 (los puntos de cómputo; DR, Route 53, RDS Proxy y X-Ray se completan en los módulos 04, 06, 08 y 10). También se cubren puntos de 2.1 y 3.4 relativos a escalado y balanceo.

Practica lo aprendido

Documentación oficial para ampliar

• Amazon EC2 instance types
• Amazon EBS volume types
• Placement strategies for your placement groups
• Use the Instance Metadata Service (IMDSv2)
• Amazon EC2 pricing
• Savings Plans pricing
• How Elastic Load Balancing works
• Amazon EC2 Auto Scaling User Guide
• What is AWS Compute Optimizer?
• AWS Elastic Beanstalk: deployment policies