Amazon SOA-C02: Cómputo y Auto Scaling — Guía de estudio
Forma parte de la AWS SysOps Administrator Associate SOA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Este dominio cubre la gestión de instancias EC2 y Auto Scaling para ofrecer capacidad de cómputo fiable y rentable. Se centra en las operaciones del ciclo de vida de las instancias, estrategias de escalado, integración con balanceadores de carga, ubicación para rendimiento y resiliencia, y comportamientos de mantenimiento/terminación que afectan la disponibilidad y el estado. El dominio operativo significa elegir los tipos de instancia correctos, patrones de configuración de lanzamiento, políticas de escalado e integración de comprobaciones de estado para cumplir con los SLAs mientras se controla el costo.
Ciclo de vida y gestión de instancias EC2
La gestión del ciclo de vida de EC2 comienza en el punto de la configuración de lanzamiento: use plantillas de lanzamiento (Launch Templates) (aws ec2 create-launch-template / consola) para capturar la AMI, el tipo de instancia, el perfil de instancia de IAM, los user-data, las interfaces de red, el mapeo de EBS y las opciones de metadatos; las plantillas admiten el versionado, lo que facilita los despliegues inmutables. Los despliegues inmutables utilizan una nueva versión de la plantilla de lanzamiento (o una nueva plantilla de lanzamiento) y crean un nuevo Auto Scaling group o utilizan la actualización de instancias del ASG para reemplazar las instancias; evite las actualizaciones in-situ de instancias en ejecución cuando los cambios afecten el comportamiento en el arranque o los parches a nivel de AMI.
Los patrones operativos de CLI/consola incluyen
undefined
para lanzamientos únicos y
undefined
para lanzamientos gestionados por ASG. Decida entre la preparación de AMIs (Packer/CodeBuild) y los scripts de inicio de user-data basándose en el tiempo de arranque: prepare las dependencias pesadas en las AMIs para reducir la duración del arranque; use user-data para la configuración específica del entorno. Para el almacenamiento efímero, recuerde que los volúmenes de almacén de instancia se pierden en la terminación; configure los volúmenes raíz y de datos con
undefined
si requiere la persistencia de EBS después de la terminación de la instancia.
Grupos de Auto Scaling, políticas y hooks de ciclo de vida
Los Auto Scaling Groups (ASGs) se configuran con una plantilla de lanzamiento o una configuración de lanzamiento y controlan la capacidad deseada/mínima/máxima a través de las Zonas de Disponibilidad. Elija una plantilla de lanzamiento +
undefined
para flotas optimizadas en costos que combinan instancias On-Demand y Spot con una lista de tipos de instancia; use la ponderación de instancias y estrategias de asignación optimizadas para la capacidad para obtener una capacidad predecible. Para los despliegues, prefiera patrones inmutables: cree una nueva versión de la plantilla de lanzamiento y realice una actualización de instancias del ASG o un intercambio blue/green en lugar de reconfigurar las instancias existentes.
Las políticas de escalado se expresan como:
- Seguimiento de objetivo (
undefined
): establezca una métrica predefinida como
undefined
o el promedio de CPU del ASG y un valor objetivo; el ASG se encarga de los ajustes automáticamente.
- Escalado por pasos (
undefined
): defina alarmas de CloudWatch que activen pasos de ajuste específicos (p. ej., +2, +4) según la gravedad de la infracción; útil para cargas de trabajo con picos.
- Escalado simple (heredado): ajustes de un solo paso con un periodo de enfriamiento; generalmente reemplazado por el seguimiento de objetivo o el escalado por pasos.
Use hooks de ciclo de vida (
undefined
) para pausar la terminación/lanzamiento de instancias. Los hooks de ciclo de vida le permiten drenar conexiones, replicar estado (a S3/RDS) o notificar a sistemas de orquestación a través de SNS/SQS/Lambda antes de la finalización; siempre establezca un
undefined
y una acción predeterminada para evitar estados bloqueados.
Tipos de Elastic Load Balancing y comprobaciones de estado
Elija el tipo de balanceador de carga según el patrón de tráfico: Application Load Balancer (ALB) para HTTP/HTTPS con enrutamiento basado en contenido y reglas de host/ruta; Network Load Balancer (NLB) para un rendimiento extremo e IP estáticas para TCP/UDP; Classic Load Balancer (CLB) solo para stacks heredados. Cree ALBs y grupos de destino con
undefined
y
undefined
; registre los destinos del ASG utilizando la asociación del grupo de destino del ASG para una integración automática del estado del ciclo de vida.
La integración de las comprobaciones de estado requiere alinear las comprobaciones de estado del ASG y del ELB: establezca el
undefined
del ASG en
undefined
(
undefined
) para que una instancia se considere saludable solo después de que el balanceador de carga marque su destino como saludable. Tipos de comprobación de estado e implicaciones:
- Comprobación de estado del grupo de destino de ALB/NLB: admite HTTP/HTTPS/TCP y mide la disponibilidad a nivel de aplicación; recomendado para aplicaciones web.
- Comprobaciones de estado del ASG por sí solas: usar para comprobaciones simples a nivel de host (p. ej., comprobaciones de estado de EC2).
- HealthCheckGracePeriod: da tiempo a las nuevas instancias para arrancar, ejecutar user-data y pasar las comprobaciones a nivel de aplicación.
Implicaciones de la persistencia de sesión: la persistencia de sesión del grupo de destino del ALB utiliza afinidad basada en cookies de aplicación (basada en duración), lo que puede mejorar la afinidad de sesión pero reduce la distribución uniforme y complica las actualizaciones continuas. NLB admite la afinidad por IP del cliente; use la persistencia de sesión solo cuando el estado de la sesión no se pueda externalizar.
Ubicación de instancias, planificación de capacidad y métricas de escalado
Las decisiones de ubicación afectan la latencia y los dominios de fallo: los grupos de ubicación (placement groups) ofrecen estrategias de clúster (red de baja latencia), dispersión (spread, una instancia por rack para instancias críticas) y partición (partition, particiones aisladas de fallos). Los ASG equilibran las instancias entre Zonas de Disponibilidad (AZ) por defecto; prefiere una planificación de capacidad consciente de las AZ para evitar puntos calientes (hotspots) en una sola AZ. Para la CLI:
undefined
.
La planificación de capacidad considera los tipos de instancia, las opciones de compra y las métricas:
- Tipos de instancia: elige familias optimizadas para CPU/memoria/red (M/C/R/T/D/I) según la carga de trabajo; mide con pruebas de carga representativas.
- Opciones de compra: On-Demand para predictibilidad, Instancias Reservadas (Reserved) o Savings Plans para reducciones de costos en estado estable, Spot para eficiencia de costos en cargas transitorias; usa una MixedInstancesPolicy para combinar tipos y opciones de compra.
- Métricas de escalado: las métricas por defecto de un ASG usan el promedio de CPU del grupo; prefiere métricas a nivel de aplicación como RequestCountPerTarget de un ALB o métricas personalizadas de CloudWatch (p. ej., profundidad de la cola) para el seguimiento de objetivos (target tracking). Patrones comunes:
- Usa el seguimiento de objetivos (target tracking) con ALB/request-count-per-target cuando necesites un número estable de solicitudes por instancia.
- Usa el escalado por pasos (step scaling) para picos grandes y repentinos con pasos de recuperación definidos.
- Considera el escalado predictivo (Predictive Scaling) para cargas de trabajo con ciclos diarios.
Recuperación de instancias, comportamiento de terminación y mantenimiento
Planifica para fallos de instancia y mantenimiento habilitando la recuperación automática para problemas de hardware (alarma de CloudWatch con la acción EC2 Recover) y gestionando eventos programados (describe-instance-status). Configura los indicadores instance-initiated-shutdown-behavior y DeleteOnTermination de EBS para controlar el ciclo de vida del volumen; usa
undefined
para ajustarlo.
Comportamiento de terminación en ASG: las políticas de terminación de ASG deciden qué instancia terminar primero (Por defecto: la configuración de lanzamiento más antigua o heurísticas de estado de la instancia y balanceo entre AZ). Detalles operativos importantes:
- El estado local es efímero: los volúmenes de instance store y las cachés en memoria se pierden en la terminación. No asumas que el reemplazo preserva el estado local; persiste los datos críticos en EBS (con snapshots/backups apropiados), S3 o una caché externa (ElastiCache).
- Usa lifecycle hooks para drenar el tráfico y descargar el estado antes de la terminación.
- Usa instance refresh o despliegues blue/green para el mantenimiento y reemplazar instancias de forma segura;
undefined
.
Errores comunes y criterios de decisión
- Confiar en los periodos de enfriamiento (cooldowns) por defecto y en métricas basadas solo en CPU: elige métricas alineadas con el comportamiento de la aplicación (RequestCountPerTarget de ALB, profundidad de la cola); establece los cooldowns para acomodar el tiempo de arranque y el HealthCheckGracePeriod para evitar la oscilación.
- No usar lifecycle hooks para una terminación controlada (graceful termination): sin hooks, las solicitudes en curso y las cachés locales se pierden; implementa hooks con SNS/SQS/Lambda para drenar y persistir el estado.
- Asumir que el reemplazo de una instancia preserva el estado local: los volúmenes de instance store y las cachés en memoria son efímeros; diseña para instancias sin estado (stateless) o replica el estado en almacenamientos duraderos.
- Uso excesivo de la persistencia de sesión (stickiness): la persistencia de sesión aumenta la distribución desigual de la carga y complica el escalado y las actualizaciones; prefiere almacenes de sesión externos (ElastiCache, DynamoDB) para escalar horizontalmente (scale-out).
- Ignorar el balanceo entre AZ y los grupos de ubicación: ubicar demasiadas instancias en una sola AZ o en un grupo de clúster puede crear puntos únicos de fallo; usa la distribución multi-AZ de los ASG y estrategias de placement group apropiadas.
- Configurar incorrectamente la integración de las comprobaciones de estado (health checks): el health-check-type del ASG debe coincidir con los health checks del ELB/target group y el HealthCheckGracePeriod debe ser lo suficientemente largo para la inicialización de la aplicación, de lo contrario, se terminarán instancias sanas.
Problema práctico: Escenario de caso de uso
StreamingCo opera una API de miniaturas de video que experimenta picos de tráfico diarios y utiliza cachés en disco local en instancias EC2; recientemente, el escalado ascendente (scale-up) ha sido lento y las instancias terminadas pierden la caché, lo que provoca tiempos de respuesta deficientes.
- Migra la configuración de lanzamiento a una Launch Template y crea una AMI ligera (bake) con las dependencias de tiempo de ejecución; usa
undefined
y el versionado para despliegues inmutables. 2. Configura un ASG con una MixedInstancesPolicy que liste varios tipos de instancia y una asignación de Spot + On-Demand para equilibrar costo y capacidad. 3. Asocia un ALB y usa TargetTrackingScaling sobre la métrica RequestCountPerTarget del ALB con un HealthCheckGracePeriod ajustado al tiempo de arranque de la aplicación. 4. Implementa lifecycle hooks en las terminaciones del ASG para drenar conexiones y ejecutar un flujo con Lambda/SNS para persistir las claves de caché necesarias en ElastiCache o S3 antes de la terminación. 5. Externaliza el estado de sesión y caché a ElastiCache o S3 y usa grupos de ubicación (placement groups) y distribución entre AZ para cumplir con los requisitos de latencia y dominios de fallo.
Justificación: Usar launch templates y despliegues inmutables reduce la variabilidad en el arranque; el seguimiento de objetivos (target tracking) orientado al ALB vincula el escalado a la carga de solicitudes en lugar de a la CPU; los lifecycle hooks previenen la pérdida de datos en la terminación; externalizar la caché elimina la dependencia del estado local efímero, permitiendo un escalado rápido y seguro y un menor costo a través de estrategias mixtas de instancias y compra.
← Almacenamiento y Gestión de Datos · Todos los dominios · Bases de Datos y Almacenamiento en Caché →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →