Amazon SAA-C03: Cómputo, Auto Scaling y gestión de instancias — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Tipos de Instancia EC2 y AMIs

Seleccionar la familia de instancias EC2 correcta es la base de una capa de computación bien diseñada, porque la familia, la generación y el tamaño determinan conjuntamente la arquitectura de la CPU, la relación memoria-vCPU, el ancho de banda de red y los aceleradores disponibles. De propósito general (M6i, M7g, serie T) se adapta a niveles web equilibrados y cargas de trabajo mixtas. Optimizadas para computación (C7i, C7gn) son adecuadas para simulaciones, codificación, procesos por lotes (batch) y front-ends web que hacen un uso intensivo de la CPU. Optimizadas para memoria (R7i, X2idn) se dirigen a bases de datos en memoria y cachés. Optimizadas para almacenamiento (I4i, D3) se dirigen a NoSQL, HDFS y data warehousing. Aceleradas (P5, G5, Trn1, Inf) proporcionan GPUs o silicio especializado para ML. Las instancias Graviton (sufijo g) suelen ofrecer una relación precio-rendimiento entre un 20 y un 40 % mejor para cargas de trabajo de escalado horizontal (scale-out) que compilan sin problemas para ARM64.

La familia T es de capacidad de ráfaga (burstable) y por defecto opera en modo estándar, donde los créditos de CPU se acumulan durante los periodos de inactividad y se consumen durante las ráfagas; cuando se agotan los créditos, el rendimiento se limita al nivel de referencia (baseline). Para cargas de trabajo con picos impredecibles —pequeños niveles web, entornos de desarrollo/pruebas o entornos de Elastic Beanstalk que respaldan un front-end con picos de tráfico—, las instancias T en modo ilimitado permiten que la instancia tome créditos prestados y factura un pequeño recargo por vCPU-hora de excedente, evitando una limitación de rendimiento visible para el usuario. Esta es la razón por la que los entornos de Beanstalk con una saturación breve de la CPU suelen solucionarse habilitando el modo ilimitado en lugar de actualizar a una familia optimizada para computación más costosa. Es importante reservar la serie T para cargas de trabajo genuinamente irregulares y con un promedio de uso bajo: un uso sostenido de la CPU en el modo estándar agota los créditos en cuestión de minutos.

El escalado vertical (cambiar a un tamaño mayor dentro de la misma familia) está limitado por la instancia más grande disponible, fuerza un tiempo de inactividad para realizar el cambio, introduce un punto único de fallo y no puede distribuir la carga de trabajo entre Zonas de Disponibilidad. Siempre que la carga varíe significativamente, la respuesta correcta es el escalado horizontal con un grupo de Auto Scaling.

Las AMIs doradas (Golden AMIs) incorporan el código de la aplicación, el entorno de ejecución (runtime) y las dependencias en la instantánea raíz, produciendo lanzamientos rápidos y deterministas, algo crítico cuando Auto Scaling reacciona a un pico de demanda. El arranque mediante user-data en cada lanzamiento añade minutos de latencia justo en el peor momento.

Opciones de Almacenamiento: Instance Store vs EBS, Snapshots y Fast Snapshot Restore

Las instancias ofrecen dos sustratos de almacenamiento: almacenamiento de instancia (NVMe efímero conectado al host físico) y Amazon EBS (bloques conectados por red). El almacenamiento de instancia ofrece la latencia más baja posible, pero sus datos se destruyen al detener, hibernar, terminar la instancia o en caso de un fallo de hardware. Tratarlo como almacenamiento duradero es un error común y peligroso; solo es apropiado para espacio temporal (scratch), búferes, cachés o datos replicados, como un nodo de datos HDFS cuyas réplicas existen en otros nodos. Los datos duraderos deben residir en EBS, respaldados por instantáneas (snapshots) almacenadas en S3.

Las instantáneas son incrementales e independientes una vez creadas, por lo que restaurar una en un nuevo volumen nunca afecta al origen. La forma canónica de duplicar un gran conjunto de datos de producción en un entorno de prueba es crear una instantánea del volumen de origen y crear nuevos volúmenes a partir de esa instantánea. Sin embargo, los volúmenes restaurados a partir de instantáneas realizan una carga diferida (lazy-load) de los bloques desde S3 en la primera lectura, lo que provoca una latencia de E/S significativa hasta que cada bloque se hidrata. Esta misma carga diferida afecta a las nuevas instancias lanzadas desde AMIs cuyas instantáneas raíz son grandes: parecen lentas durante varios minutos después del lanzamiento.

EBS Fast Snapshot Restore (FSR) elimina esa penalización. Habilita FSR en la instantánea para las Zonas de Disponibilidad donde el ASG lanza instancias, y los volúmenes creados a partir de ella ofrecerán el rendimiento aprovisionado completo de inmediato:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Esto es esencial cuando los eventos de escalado horizontal (scale-out) deben añadir capacidad en segundos en lugar de minutos.

Redes Mejoradas con ENA y EFA

El rendimiento de red anunciado escala con el tamaño de la instancia, pero solo se puede alcanzar cuando el controlador Elastic Network Adapter (ENA) está presente. ENA proporciona redes mejoradas basadas en SR-IOV, soportando hasta 200 Gbps en las instancias más nuevas. Las AMIs modernas (Amazon Linux 2, Ubuntu reciente, Windows) vienen con ENA habilitado; verifícalo con:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Sin ENA, las instancias recurren silenciosamente a un rendimiento inferior y a un mayor jitter, socavando cualquier diseño de baja latencia independientemente de la elección del grupo de ubicación (placement group).

Para colectivos a escala de microsegundos —CFD, modelado meteorológico, dinámica molecular, entrenamiento de modelos grandes—, añade Elastic Fabric Adapter (EFA). EFA expone un transporte que omite el sistema operativo (OS-bypass) (Libfabric) a MPI y NCCL, evitando por completo la pila de red del kernel. EFA solo ofrece su beneficio dentro de un grupo de ubicación de clúster (cluster placement group) en tipos de instancia compatibles (c7gn, hpc7a, p5), y requiere el controlador EFA más una compilación compatible de MPI (Open MPI, Intel MPI) o NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Placement Groups

Los Placement Groups controlan la topología física de las instancias:

Elegir incorrectamente desperdicia la funcionalidad. Un grupo de tipo cluster no puede abarcar varias AZs; por diseño, es intra-AZ. Un grupo de tipo spread no puede alojar cien servidores web debido al límite de siete por AZ. La ubicación por partición (partition), no por distribución (spread), es la herramienta correcta para un clúster de Kafka de 40 nodos porque alinea la ubicación de las réplicas con los dominios de error. Para una alta disponibilidad general, no confines un ASG a un solo placement group en una sola AZ; distribuye el ASG entre múltiples AZs.

Para analíticas de streaming o cargas de trabajo MPI que necesitan una latencia mínima de nodo a nodo, la combinación correcta es un placement group de tipo cluster más instancias con ENA habilitado; el tipo cluster reduce el número de saltos y ENA proporciona la capacidad de paquetes por segundo necesaria para materializar ese beneficio de latencia.

Auto Scaling Groups y Launch Templates

Un Auto Scaling group (ASG) es la unidad en tiempo de ejecución que mantiene un número deseado de instancias EC2 a través de una o más AZs, definido por tres enteros (MinSize, DesiredCapacity, MaxSize) y una lista de subredes. El ASG en sí no describe qué lanzar; esa es la responsabilidad de un launch template, el reemplazo moderno de las launch configurations. Los launch templates soportan versionado, políticas de instancias mixtas, mezcla de Spot/On-Demand, forzado de IMDSv2, reservas de capacidad e instancias T en modo ilimitado. Un launch template hace referencia a una AMI, tipo(s) de instancia, security groups, perfil de instancia IAM, user data y mapeos de dispositivos de bloques.

El patrón canónico para aplicaciones web sin estado es AMI + Launch Template + ASG + ALB. La AMI proporciona un arranque rápido; el ALB (o NLB para TCP/UDP) distribuye el tráfico y gestiona los health checks; el ASG registra automáticamente las nuevas instancias en el target group y termina las que no están en buen estado. El despliegue Multi-AZ (un mínimo de dos AZs, tres para sistemas de quórum) es obligatorio: un ASG vinculado a una única subred no puede sobrevivir a una interrupción de AZ porque el propio ASG no puede lanzar reemplazos mientras la AZ está afectada.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Políticas de escalado: Target Tracking, Step, Scheduled, Predictive

El escalado de ASG tiene cuatro modos, cada uno resolviendo un problema diferente:

• Target tracking (seguimiento de objetivo) elige una métrica y la mantiene cerca de un punto de ajuste (p. ej., ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Se autoajusta: AWS gestiona las alarmas y ajusta la velocidad a medida que la métrica se desvía. Esta debería ser la opción por defecto.
• Step scaling (escalado por pasos) añade o elimina capacidad en niveles graduados según cuánto se desvíe una métrica de su rango, útil cuando la magnitud de la reacción debe escalar con la gravedad de la alarma.
• Simple scaling (escalado simple) es heredado: un solo ajuste por alarma, se bloquea durante el cooldown y no debe elegirse para nuevos diseños.
• Scheduled scaling (escalado programado) modifica MinSize/DesiredCapacity/MaxSize en momentos definidos por cron.
• Predictive scaling (escalado predictivo) utiliza machine learning sobre un historial de hasta 14 días para prever las próximas 48 horas, preaprovisionando capacidad antes del pico de demanda.

El escalado dinámico es inherentemente reactivo (va con retraso): reacciona solo después de que una métrica supera un umbral, y las nuevas instancias necesitan minutos para arrancar, registrarse y calentarse. Para una aplicación de empleados donde todos los usuarios llegan a las 09:00 y experimentan 2-3 horas de lentitud mientras el ASG se pone al día, el escalado dinámico por sí solo es la respuesta incorrecta. Añade acciones programadas (scheduled actions) antes del pico para aumentar MinSize y DesiredCapacity antes de que llegue la demanda:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Luego, deja que el target tracking absorba la variabilidad residual. El escalado predictivo es la elección correcta cuando la forma del pico es estable pero su momento exacto varía de un día para otro. Para paradas predecibles fuera de producción (entornos de desarrollo apagados por las noches y fines de semana), una acción programada para establecer desired=0, min=0 el viernes por la tarde y volver a levantarlo el lunes por la mañana es la solución con menos sobrecarga: el propio ASG actúa como motor de programación, sin necesidad de pegamento con Lambda o EventBridge.

La elección de la métrica importa tanto como la elección de la política. La CPU funciona para cargas de trabajo web limitadas por CPU, pero para trabajadores impulsados por un backlog que leen de SQS, debes escalar según la profundidad de la cola, no la CPU: un trabajador bloqueado en E/S puede mostrar un 10% de CPU mientras se acumulan millones de mensajes. Usa ApproximateNumberOfMessagesVisible por instancia, expuesto como una métrica personalizada o a través del objetivo integrado SQSQueueBacklogPerInstance:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

De manera similar, las capas HTTP sensibles a la latencia deberían seguir TargetResponseTime o RequestCountPerTarget; las aplicaciones limitadas por memoria, disco o latencia de sistemas posteriores deberían publicar una métrica personalizada que refleje el verdadero cuello de botella. Escalar por CPU cuando la CPU no es la restricción produce exactamente el modo de fallo en el que las instancias nunca escalan horizontalmente, las colas crecen sin límite y el ALB devuelve errores 5xx.

Comprobaciones de estado y enlaces de ciclo de vida

Los ASG utilizan por defecto las comprobaciones de estado de EC2, que detectan fallos del hipervisor pero no de la aplicación. Habilitar las comprobaciones de estado de ELB en el ASG delega la decisión de reemplazo a la sonda a nivel de aplicación del balanceador de carga, lo cual es esencial cuando el sistema operativo está bien pero el proceso está bloqueado. Establece HealthCheckGracePeriod con una duración suficiente para que los datos de usuario se completen; de lo contrario, las instancias nuevas se terminarán a mitad del arranque en un bucle.

La elección del balanceador de carga afecta el significado de “saludable”:

Una aplicación HTTP detrás de un NLB que solo realiza comprobaciones de estado TCP seguirá sirviendo tráfico desde una instancia que acepta conexiones pero devuelve errores 500. Cambia a un ALB —o configura comprobaciones de estado HTTP en el NLB— para restaurar una señalización significativa.

Los enlaces de ciclo de vida (lifecycle hooks) pausan las instancias en estado Pending:Wait o Terminating:Wait para que la automatización externa pueda actuar. En el lanzamiento, un enlace te permite registrarte en un sistema de gestión de configuración, precalentar cachés o extraer secretos antes de que el ALB envíe tráfico. En la terminación, un enlace te permite drenar sesiones, volcar registros y dar de baja la instancia de una malla de servicios (service mesh). Los enlaces emiten eventos de EventBridge; los manejadores deben llamar a CompleteLifecycleAction o el enlace expirará y tomará su acción por defecto (CONTINUE o ABANDON).

Grupos precalentados e hibernación

El tiempo de arranque en frío es un problema real para aplicaciones que cargan modelos grandes, precalientan cachés o compilan con JIT antes de servir. Un grupo precalentado (warm pool) es una reserva preinicializada adjunta al ASG: las instancias se lanzan, ejecutan el arranque, y luego se detienen, se mantienen en ejecución o se hibernan, manteniéndose en el grupo hasta que el ASG escala horizontalmente. Tomar una instancia del grupo evita minutos de arranque.

La hibernación suspende el sistema operativo en el volumen raíz EBS cifrado para que el heap de la JVM, los pesos de ML y la caché de páginas del SO se recuperen al reanudarse. Requisitos: un volumen raíz cifrado lo suficientemente grande para contener la RAM, RAM de la instancia ≤ 150 GB en una familia compatible, y HibernationOptions.Configured = true en el lanzamiento. Un grupo precalentado con PoolState: Hibernated combina ambos: las instancias no tienen costo de cómputo mientras están detenidas y se reanudan en segundos con la memoria ya poblada. Este es el patrón correcto cuando una aplicación “tarda mucho en cargar la memoria antes de ser productiva”.

Recuperación automática para cargas de trabajo no escalables

No todas las cargas de trabajo escalan horizontalmente. Las aplicaciones heredadas con licencias vinculadas a la MAC, bloqueos basados en archivos o estado de sesión en memoria sin un almacén compartido no pueden ejecutarse en más de una instancia; levantar nodos adicionales causa corrupción de datos o violaciones de licencia. Para estas, la resiliencia proviene de la recuperación automática, no del escalado horizontal.

Funcionan dos patrones. Una alarma de CloudWatch sobre StatusCheckFailed_System junto con la acción de recuperación de EC2 preserva el ID de la instancia, la IP privada, la IP elástica y los volúmenes EBS adjuntos a través del fallo del host subyacente. Aún más simple: un ASG con MinSize=MaxSize=1 que abarca múltiples AZ reemplaza una instancia fallida y, a diferencia de la acción de recuperación, puede sobrevivir a un fallo de AZ, siempre que el estado se externalice fuera del volumen raíz o la AMI sea reconstruible.

Balanceadores de carga y ubicación en subredes

El ALB opera en L7, terminando HTTP/HTTPS, ofreciendo enrutamiento por host/ruta/cabecera, HTTP/2, WebSockets e integración con WAF/Cognito/OIDC. El NLB opera en L4, preserva la IP del cliente, soporta IP estáticas y TLS passthrough, PrivateLink y mantiene millones de conexiones por segundo. El Gateway Load Balancer inserta dispositivos de terceros (firewalls, IDS) en la ruta del tráfico.

La ubicación en subredes es donde las arquitecturas fallan con más frecuencia. Un ALB de cara a internet debe estar asociado a subredes públicas —subredes con una ruta 0.0.0.0/0 hacia un Internet Gateway—, una por cada AZ donde residen los destinos (targets). Los destinos en sí permanecen en subredes privadas. Si el ALB se coloca en subredes privadas, o si las subredes “públicas” carecen de una ruta por defecto a un IGW, los clientes experimentarán tiempos de espera de conexión. La alcanzabilidad del destino requiere que el grupo de seguridad del destino permita el tráfico entrante desde el grupo de seguridad del ALB en el puerto de destino; no se necesita NAT entre el ALB y los destinos en la misma VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Habilita las comprobaciones de estado de ELB en el ASG para que los destinos no saludables sean reemplazados, no simplemente dados de baja. El balanceo de carga entre zonas (por defecto en ALB, opcional en NLB) iguala la distribución de solicitudes independientemente del número de instancias por AZ. Route 53 debe resolver al ALB mediante un registro de alias (o una política ponderada/de latencia entre múltiples ALBs); nunca apuntes Route 53 a las IP de instancias EC2 individuales, porque una instancia fallida seguirá recibiendo tráfico hasta que expire el TTL y el reemplazo del ASG tendrá una IP diferente.

Modelos de compra y flotas de instancias mixtas

La elección del modelo de compra es la palanca más importante para reducir el gasto en EC2, independientemente del patrón de arquitectura.

La estrategia racional: carga base en Instancias Reservadas o un Savings Plan, picos en Bajo Demanda, trabajo tolerante a fallos en Spot. En un ASG, esto se expresa como una política de instancias mixtas:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Diversificar los tipos de instancia profundiza el pool de Spot y reduce las interrupciones correlacionadas. price-capacity-optimized (o capacity-optimized) equilibra el precio con la profundidad del pool para que sea menos probable que las instancias sean reclamadas.

Spot es apropiado para cargas de trabajo sin estado, que permiten puntos de control (checkpointable), reintentables o redundantes horizontalmente: workers web detrás de un ALB, trabajos de Batch con reintento automático, ejecutores de Spark, runners de CI. No es apropiado como la única capacidad para servicios críticos siempre activos, bases de datos primarias con estado o nodos líderes sin una ruta de recuperación; un aviso de dos minutos no puede garantizar un apagado seguro, y la reclamación correlacionada de un tipo de instancia específico en toda la flota es un modo de fallo real. Cuando el requisito dice «no debe ser interrumpido», Spot queda descalificado.

La trampa inversa es aplicar RIs o Savings Plans a cargas de trabajo genuinamente variables: pagas el compromiso por hora, se use o no, por lo que una carga de trabajo que se ejecuta 40 horas a la semana bajo un compromiso de 168 horas desperdicia el 76 % de la reserva. Cuando la preocupación es la capacidad en sí misma —no el precio— (picos impulsados por eventos, recuperación de desastres), utiliza una Reserva de Capacidad Bajo Demanda: una garantía pura con alcance de AZ a tarifas de Bajo Demanda, combinable con un Savings Plan para obtener el descuento.

Cómputo sin servidor: Lambda y Fargate

El modelo sin servidor (serverless) traslada la gestión de la capacidad a la plataforma. Lambda se adapta a trabajos de corta duración e impulsados por eventos: triggers de ObjectCreated de S3, DynamoDB Streams, consumidores de SQS de bajo volumen, backends de API Gateway, lógica de cohesión (glue logic). La memoria (128 MB – 10,240 MB) aprovisiona la CPU proporcionalmente, por lo que ajustar la memoria hacia arriba a menudo reduce el costo al acortar la duración. Los límites estrictos definen su alcance: ejecución máxima de 15 minutos, 10 GB de memoria, 10 GB en /tmp, despliegue de 250 MB sin comprimir (o 10 GB a través de una imagen de contenedor), carga síncrona de 6 MB. Usar Lambda para una transcodificación de video de 30 minutos, un ETL de varias horas o un entrenamiento de GPU es arquitectónicamente incorrecto: la función expirará a mitad del trabajo y la lógica de reintentos solo multiplicará el desperdicio. Para rutas sensibles a la latencia, mitiga los arranques en frío (cold starts) y el tiempo de inicialización de la ENI adjunta a la VPC con Provisioned Concurrency.

Fargate ejecuta contenedores sin gestionar los hosts EC2. Es la elección correcta cuando las tareas superan los 15 minutos, necesitan runtimes personalizados o encajan en la orquestación de ECS/EKS pero el equipo no quiere gestionar la capacidad. Fargate es más caro por vCPU-hora que EC2 Spot, por lo que cuando la utilización en estado estable es alta y predecible, un ASG de instancias mixtas con Spot en ECS es más barato. Para tráfico con picos o impredecible, la facturación por segundo de Fargate es la ganadora.

Para la orquestación de muchas Lambdas, Step Functions es preferible a encadenarlas a través de SNS/SQS porque proporciona un historial de ejecución visual, semántica de reintentos, manejo de errores centralizado y estado duradero. Los flujos de trabajo estándar facturan por transición de estado y se ejecutan hasta por un año; los flujos de trabajo Express se optimizan para el procesamiento de eventos de alto volumen y corta duración.

Para la distribución masiva (fan-out) de miles de trabajos en contenedores parametrizados —genómica, Monte Carlo, ETL— AWS Batch se encarga de la gestión de colas, resolución de dependencias, reintentos y aprovisionamiento en EC2 gestionado, Spot o Fargate. Los trabajos hacen referencia a una definición de trabajo (contenedor + vCPU/memoria + rol de IAM) y Batch los empaqueta (bin-packs) en instancias de tamaño adecuado. Step Functions frecuentemente orquesta Batch, Lambda y ECS dentro de una única máquina de estados.

Elastic Beanstalk

Beanstalk es una PaaS gestionada que aprovisiona el ALB, ASG, instancias EC2 y, opcionalmente, RDS a partir de un paquete de aplicación. Soporta despliegues continuos (rolling), continuos con un lote adicional (rolling-with-additional-batch), inmutables y azul/verde (blue/green) con integración de CloudWatch. Las políticas de escalado se exponen como opciones del entorno (métrica, umbrales, mín/máx). Dado que Beanstalk utiliza por defecto tipos de instancia de rendimiento intermitente (burstable), habilitar el modo T-ilimitado es la solución de bajo esfuerzo para una saturación breve de la CPU. Las acciones de escalado programadas se adjuntan al ASG gestionado por Beanstalk como cualquier otro. Elige Beanstalk cuando el equipo desee una topología de aplicación web estándar sin crear manualmente CloudFormation y cuando las actualizaciones continuas y los paquetes versionados coincidan con la cadencia de lanzamientos.

Gestión de flotas con Systems Manager

Los patrones de SSH y bastiones son frágiles y costosos de asegurar. AWS Systems Manager los reemplaza. El SSM Agent (preinstalado en Amazon Linux 2, Ubuntu, Windows) junto con un perfil de instancia que otorga AmazonSSMManagedInstanceCore es todo lo que se necesita.

• Run Command ejecuta shell/PowerShell en flotas etiquetadas con una salida consolidada.
• Session Manager abre shells interactivos a través de la API de AWS: sin puerto 22 de entrada, sin bastión, autenticación completa con IAM, con sesiones registradas en S3 o CloudWatch Logs.
• Patch Manager aplica parches de sistema operativo según programaciones utilizando ventanas de mantenimiento.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Automatización de inicio/parada programados

Para instancias EC2 y RDS de entornos no productivos que deben estar apagadas fuera del horario laboral, el patrón de bajo mantenimiento es EventBridge Scheduler → Lambda. Una regla cron (cron(0 19 ? * MON-FRI *)) invoca una Lambda que detiene los recursos etiquetados; una segunda regla a las 07:00 los inicia.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Esto es serverless, no tiene una flota que parchar y escala por etiquetas. La solución AWS Instance Scheduler funciona de manera equivalente. Un detalle sutil: una instancia de RDS detenida se inicia automáticamente después de siete días, por lo que la programación de detención debe ser recurrente para volver a detenerla. Combinado con ASGs cuyas acciones programadas reducen la capacidad a cero los fines de semana, el costo en horas de inactividad se acerca a cero.

Errores comunes de red en computación escalada

Ubicación del NAT Gateway. Un NAT gateway reside en una única AZ. Una flota que se extiende por tres AZ y que enruta todo el tráfico de salida a través de un único NAT en us-east-1a paga por transferencia entre AZ en cada paquete desde us-east-1b/us-east-1c, y pierde por completo la salida cuando us-east-1a se degrada. El patrón correcto es un NAT gateway por AZ, con la tabla de rutas de cada subred privada apuntando al NAT en su propia AZ. Esto localiza el tráfico y elimina el modo de fallo de una única AZ.

Instancias NAT. Una única instancia NAT basada en EC2 se convierte en un cuello de botella de ancho de banda y PPS (paquetes por segundo) a medida que la flota crece, y es un punto único de fallo (SPOF). Los NAT Gateways administrados escalan hasta 100 Gbps por gateway. Para el tráfico de servicios de AWS, los VPC endpoints (de tipo Gateway para S3/DynamoDB, de tipo Interface para otros) evitan el NAT por completo, reduciendo costos y eliminando el riesgo de saturación durante eventos de escalado.

Trampas de diseño recurrentes

• Los ASG en una sola AZ no pueden sobrevivir a una interrupción de AZ: siempre asocia subredes de al menos dos AZ (tres para sistemas de quórum) y mantén MinSize ≥ 2.
• Asumir que toda carga de trabajo escala horizontalmente. Las aplicaciones que mantienen estado, son de escritura única o tienen licencias no clusterizables empeoran bajo un ASG. Usa la recuperación automática o refactoriza primero.
• El escalado reactivo para picos predecibles produce el síntoma de “lentitud durante las primeras 2-3 horas”. Usa el escalado programado o predictivo para precalentar.
• Escalar por CPU cuando la CPU no es la restricción. Publica una métrica que refleje el verdadero cuello de botella: profundidad de la cola, tiempo de respuesta, número de conexiones.
• El escalado simple y las configuraciones de lanzamiento (launch configurations) son heredados: prefiere el seguimiento de objetivos (target tracking) y las plantillas de lanzamiento (launch templates).
• Las comprobaciones de estado solo por TCP en aplicaciones HTTP dejan instancias defectuosas en rotación. Usa comprobaciones HTTP (a través de un ALB, o comprobaciones en modo HTTP de un NLB).
• Usar Spot para cargas de trabajo con estado o que no deben ser interrumpidas: Spot exige trabajadores que puedan guardar su estado (checkpointable) y ser reemplazables.
• Usar Reserved Instances o Savings Plans en cargas de trabajo genuinamente variables: el compromiso no utilizado es un desperdicio puro; reduce los costos con el dimensionamiento correcto (right-sizing) y Spot en su lugar.
• Apuntar Route 53 a IPs de EC2 individuales: enruta al alias del ALB para que el DNS refleje los cambios en la flota.
• Tratar el instance store como si fuera duradero: los datos desaparecen al detener, terminar o fallar el host.
• Ignorar la latencia de carga diferida (lazy-load) después de la restauración de un snapshot o el lanzamiento de una AMI: habilita Fast Snapshot Restore en las AZ de destino.

Todos los dominios · Contenedores y orquestación →

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

Explorar Amazon →