Amazon SAP-C02: Cómputo y Auto Scaling — Guía de estudio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Diseño, almacenamiento y redes de instancias EC2

El diseño de instancias EC2 comienza por hacer coincidir las características de la carga de trabajo con las familias de instancias, equilibrando vCPU, memoria, red y almacenamiento local. Elija tipos optimizados para computación (C), optimizados para memoria (R/X), optimizados para almacenamiento (I/D) o con GPU (P/G) basándose en el análisis de perfiles. Aproveche las instancias basadas en Nitro y ENA/SR-IOV para obtener un alto rendimiento de red y baja latencia. Para datos temporales sensibles a la latencia o con altos IOPS, considere el almacenamiento de instancia (efímero) en SSD I3/I4 o Nitro; para almacenamiento de bloques duradero, use EBS con IOPS aprovisionadas (io2/io2 Block Express) y habilite el cifrado de EBS con KMS para la gestión de claves. Cuando las instancias están en VPC detrás de Application Load Balancers, asegúrese de que los ALB orientados a Internet se coloquen en subredes públicas y los destinos residan en subredes privadas; colocar incorrectamente los ALB o configurar mal los grupos de seguridad es una trampa común. Use Grupos de Colocación (clúster para HPC de baja latencia, partición para sistemas distribuidos con estado a gran escala, dispersión para aislamiento de fallos) para influir en la ubicación, pero aceptando las contrapartidas: clúster ofrece el mejor rendimiento, pero reduce la tolerancia a fallos a nivel de AZ. Para datos cifrados en tránsito, use TLS que termina en el ALB o TLS de extremo a extremo con paso directo (passthrough) del NLB. Los criterios de decisión sopesan el costo frente al rendimiento: los tipos de instancia más densos reducen el costo, pero pueden aumentar el radio de impacto (blast radius) y los costos de licenciamiento; prefiera el dimensionamiento correcto (right-sizing) impulsado por CloudWatch, AWS Compute Optimizer y pruebas de carga en lugar de reglas generales.

Grupos de Auto Scaling, políticas y gestión del ciclo de vida

Los Grupos de Auto Scaling (ASG) deben diseñarse para la elasticidad, la resiliencia y la eficiencia de costos usando una combinación de plantillas de lanzamiento, políticas de instancias mixtas, ganchos de ciclo de vida y políticas de escalado. Use plantillas de lanzamiento para versionar la AMI, las anulaciones de tipo de instancia, las configuraciones de EBS y los datos de usuario (user-data); las instancias mixtas con una asignación de Spot optimizada para la capacidad o una estrategia diversificada reducen el riesgo de interrupción y disminuyen el costo. Para el comportamiento de escalado, prefiera las políticas de seguimiento de objetivos para métricas predecibles (CPU, número de solicitudes por destino) y el escalado por pasos cuando se necesitan acciones de varias etapas impulsadas por umbrales; el escalado predictivo puede preaprovisionar capacidad para patrones diurnos conocidos. Implemente ganchos de ciclo de vida para ejecutar tareas de inicialización personalizadas o de drenaje antes de la terminación; combine grupos calientes (warm pools) para reducir el tiempo de servicio y el escalado programado para las bases de referencia en horario comercial. Las comprobaciones de estado deben integrar las comprobaciones de estado de ELB y EC2 para evitar el reemplazo prematuro. Esté atento a trampas como la rotación (churn) en el escalado hacia adentro causada por enfriamientos (cooldowns) agresivos, la ponderación incorrecta de instancias en ASG mixtos y no tener en cuenta el calentamiento de la aplicación. Para servicios con estado, evite el escalado rápido hacia adentro que provoca la pérdida de cachés en memoria; para costo vs. resiliencia, la capacidad respaldada por Spot con respaldo (fallback) a Instancias bajo demanda ofrece ahorros, pero requiere manejo de interrupciones, mientras que el 100% de Instancias bajo demanda maximiza la previsibilidad a un costo mayor.

Contenedores y orquestación: opciones de ECS, EKS y Fargate

La elección entre Amazon ECS, EKS y Fargate depende del modelo operativo, las necesidades de control y los patrones de la carga de trabajo. Fargate elimina la gestión de nodos y es ideal para equipos que priorizan la simplicidad operativa, pero tiene precios más altos por vCPU y límites de almacenamiento efímero; admite Fargate Spot para ahorrar costos. ECS proporciona una estrecha integración con AWS y simplicidad para los clientes que desean orquestación de contenedores sin la complejidad de Kubernetes. EKS es apropiado cuando se requiere el ecosistema de Kubernetes, portabilidad o programación avanzada; considere los grupos de nodos gestionados o los autogestionados + Karpenter para un dimensionamiento correcto (right-sizing) dinámico. Los límites de red (densidad de ENI/pod) y el comportamiento del CNI influyen en la densidad de pods y el tamaño de los nodos; en EKS, los roles de IAM para cuentas de servicio y el CSI de EBS para volúmenes persistentes reducen la proliferación de credenciales y habilitan el almacenamiento por pod. Para sistemas de archivos compartidos, use EFS (NFS) o FSx (Lustre) según las necesidades de rendimiento y latencia; evite los contenedores respaldados por NFS para operaciones con muchos metadatos; prefiera EFS con modos de rendimiento ajustados a la carga de trabajo. Implemente el cluster autoscaler o Karpenter para el escalado de nodos y el autoescalado de servicios con métricas de servicio de ALB/ECS. Las trampas comunes incluyen ignorar los presupuestos de interrupción de pods (pod disruption budgets), subestimar la cuota del plano de control de Kubernetes y sobreaprovisionar nodos en lugar de usar estrategias de empaquetado (bin-packing); las contrapartidas entre control, costo y sobrecarga operativa deben guiar la selección.

Patrones de computación sin servidor, restricciones de Lambda y diseño orientado a eventos

El modelo sin servidor (serverless) reduce la sobrecarga operativa, pero requiere patrones de arquitectura que aborden la concurrencia, el estado y los límites de los sistemas dependientes (downstream). Lambda es excelente para tareas de corta duración orientadas a eventos, backends de API a través de API Gateway o ALB, y procesamiento asíncrono con SQS o SNS. Utilice Step Functions para orquestar flujos de trabajo de larga duración y DynamoDB o RDS Proxy para el acceso a bases de datos para mitigar las tormentas de conexiones. Tenga en cuenta la sobrecarga del arranque en frío (cold-start) de Lambda en una VPC, causada por la creación de ENI; mitíguelo con concurrencia aprovisionada para puntos de conexión (endpoints) sensibles a la latencia o use VPC endpoints y RDS Proxy para limitar las conexiones. Implemente el patrón fan-out/fan-in a través de SNS + SQS, o Kinesis/MKS para el procesamiento ordenado de flujos (streams); utilice colas de mensajes fallidos (dead-letter queues) de SQS y manejadores (handlers) idempotentes para gestionar reintentos y duplicados. Los límites de concurrencia, la concurrencia reservada y la limitación de peticiones (throttling) deben planificarse para evitar fallos en cascada; diseñe para la contrapresión (backpressure) usando throttles, reintentos con jitter y patrones circuit breaker (con API Gateway o personalizados). Las compensaciones entre costo y rendimiento son claras: Lambda es rentable para cargas de trabajo con picos y de corta duración, mientras que Fargate o EC2 son mejores para tareas sostenidas de alta CPU o de larga duración. Las trampas comunes incluyen depender de reintentos síncronos que sobrecargan los sistemas dependientes, almacenar estado en el directorio local /tmp esperando persistencia y no aprovisionar para arranques en frío en flujos críticos de latencia.

Problema práctico: Migración del contact center de NovaTel Enterprise

Escenario: NovaTel Enterprise opera un contact center híbrido con enrutamiento de llamadas on-premises y una conexión Direct Connect a AWS. Ejecutan session brokers en EC2 en dos Zonas de Disponibilidad y desean migrar a un contact center gestionado por AWS con alta disponibilidad y latencia predecible entre la PBX on-premises y los servicios en la nube.

Desafío: Necesitan conectividad de baja latencia para el tráfico SIP, una capa de computación escalable para el manejo de voz que tolere interrupciones de instancias Spot, y una estrategia de recuperación ante desastres (DR) entre Regiones sin aumentar la complejidad operativa.

Enfoque recomendado:

Aprovisionar Amazon Connect para la funcionalidad del contact center y usar una Site-to-Site VPN o Direct Connect con un AWS Transit Gateway para el troncal SIP (SIP trunking) de baja latencia, terminando en un NLB con TLS passthrough frente a los session brokers.
Ejecutar los componentes de procesamiento de sesiones como un Auto Scaling Group mixto con plantillas de lanzamiento (launch templates) que usen instancias Spot optimizadas para capacidad (capacity-optimized) más un respaldo de instancias On-Demand, y usar Placement Groups (de tipo spread) para el aislamiento de fallos de los brokers críticos.
Para los medios de llamada con estado (stateful) que requieren almacenamiento efímero de baja latencia, usar instancias respaldadas por instance store (Nitro) para el búfer de medios y replicar los metadatos de la sesión en DynamoDB o ElastiCache con replicación multi-AZ; emplear RDS (Multi-AZ) o Aurora Global DB para los datos persistentes con réplicas de lectura entre Regiones para DR.
Implementar lifecycle hooks y warm pools para minimizar el arranque en frío de los brokers, failover ponderado de Route 53 para DR entre Regiones, y CloudWatch + SNS/SQS para alertas y runbooks de failover automatizados.

Justificación: El uso de servicios de contact center gestionados reduce la carga operativa, mientras que los ASG mixtos con instancias Spot optimizan los costos; aislar los medios efímeros en instance stores preserva el rendimiento, y la replicación de estado duradero en DynamoDB/ElastiCache más RDS/Aurora multi-AZ proporciona resiliencia y un failover rápido, en consonancia con las mejores prácticas de arquitectura profesional.

← Seguridad · Todos los dominios · Almacenamiento y Gestión de Datos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →