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

By Laurynas Brazys · 15 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 instancias EC2 y AMIs

Seleccionar la familia de instancias EC2 correcta es la base de una capa de cómputo bien diseñada, porque la familia, la generación y el tamaño determinan juntos la arquitectura de la CPU, la relación memoria-vCPU, el ancho de banda de la red y los aceleradores disponibles. Las instancias de propósito general (M6i, M7g, T-series) son adecuadas para niveles web equilibrados y cargas de trabajo mixtas. Las instancias optimizadas para cómputo (C7i, C7gn) se ajustan a simulaciones, codificación, procesamiento por lotes y front-ends web con uso intensivo de CPU. Las instancias optimizadas para memoria (R7i, X2idn) están dirigidas a bases de datos en memoria y cachés. Las instancias optimizadas para almacenamiento (I4i, D3) están dirigidas a NoSQL, HDFS y almacenamiento de datos. Las instancias aceleradas (P5, G5, Trn1, Inf) proporcionan GPU o silicio ML. Las instancias Graviton (sufijo g) suelen ofrecer un 20-40% más de rendimiento por precio para cargas de trabajo de escalado horizontal que se compilan limpiamente en ARM64.

La familia T es ráfaga y por defecto está en modo estándar, donde los créditos de CPU se acumulan mientras está inactiva y se agotan durante las ráfagas; cuando los créditos se agotan, el rendimiento se limita a la línea base. Para cargas de trabajo con picos impredecibles —niveles web pequeños, desarrollo/pruebas, o entornos de Elastic Beanstalk que respaldan un front-end con picos— las instancias T en modo ilimitado permiten que la instancia tome prestados créditos y facture un pequeño recargo por vCPU-hora de exceso, evitando la limitación visible para el usuario. Por eso, los entornos de Beanstalk con saturación breve de CPU suelen solucionarse habilitando el modo ilimitado en lugar de actualizar a una familia de cómputo optimizada más costosa. Es importante reservar las series T para cargas de trabajo genuinamente con picos y bajo promedio: el uso sostenido de la CPU en el modo estándar agota los créditos en cuestión de minutos.

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

Las AMIs doradas incorporan el código de la aplicación, el tiempo de ejecución y las dependencias en la instantánea raíz, lo que produce lanzamientos rápidos y deterministas, algo crítico cuando Auto Scaling reacciona a un pico. El arranque a través de datos de usuario en cada lanzamiento añade minutos de latencia en el momento equivocado.

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

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

Las instantáneas son incrementales e independientes una vez creadas, por lo que restaurar una a 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 tomar 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 cargan bloques de S3 de forma diferida en la primera lectura, lo que provoca una latencia de E/S significativa hasta que cada bloque se hidrata. La 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. Habilite FSR en la instantánea para las AZs 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 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 lograr cuando el controlador Elastic Network Adapter (ENA) está presente. ENA proporciona redes mejoradas basadas en SR-IOV, admitiendo hasta 200 Gbps en instancias más nuevas. Las AMIs modernas (Amazon Linux 2, Ubuntu reciente, Windows) se envían con ENA habilitado; verifique 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 más bajo y una mayor fluctuación, lo que socava cualquier diseño de baja latencia, independientemente de la elección del grupo de ubicación.

Para colectivos a escala de microsegundos —CFD, modelado meteorológico, dinámica molecular, entrenamiento de modelos grandes— añada Elastic Fabric Adapter (EFA). EFA expone un transporte de omisión de SO (Libfabric) a MPI y NCCL, evitando por completo la pila de red del kernel. EFA solo ofrece sus beneficios dentro de un grupo de ubicación de clúster en tipos de instancias 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

Grupos de ubicación (Placement Groups)

Los grupos de ubicación controlan la topología física de las instancias:

Elegir incorrectamente desperdicia la característica. Un grupo de clúster no puede abarcar AZs; está diseñado para ser intra-AZ. Spread no puede alojar cien servidores web debido al límite de siete por AZ. La ubicación por partición, no por dispersión, 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 fallo. Para una alta disponibilidad general, no confines un ASG a un solo grupo de ubicación en una sola AZ; distribuye el ASG entre varias AZs.

Para análisis de streaming o cargas de trabajo MPI que necesitan una latencia mínima entre nodos, la combinación correcta es un grupo de ubicación de clúster más instancias habilitadas para ENA; el clúster reduce el número de saltos y ENA ofrece la capacidad de paquetes por segundo necesaria para obtener ese beneficio de latencia.

Grupos de Auto Scaling y Plantillas de Lanzamiento

Un grupo de Auto Scaling (ASG) es la unidad de tiempo de ejecución que mantiene un número deseado de instancias EC2 en una o más AZs, definido por tres números enteros — MinSize, DesiredCapacity, MaxSize — y una lista de subredes. El ASG en sí no describe qué lanzar; esa es responsabilidad de una plantilla de lanzamiento, el reemplazo moderno de las configuraciones de lanzamiento. Las plantillas de lanzamiento admiten versionado, políticas de instancias mixtas, mezcla de Spot/On-Demand, aplicación de IMDSv2, reservas de capacidad e instancias T en modo ilimitado. Una plantilla de lanzamiento hace referencia a una AMI, tipo(s) de instancia, grupos de seguridad, perfil de instancia de IAM, datos de usuario y mapeos de dispositivos de bloque.

El patrón canónico de web sin estado es AMI + Plantilla de Lanzamiento + ASG + ALB. La AMI proporciona un arranque rápido; el ALB (o NLB para TCP/UDP) distribuye el tráfico y realiza comprobaciones de estado; el ASG registra nuevas instancias en el grupo de destino automáticamente y termina las que no están en buen estado. La implementación multi-AZ (mínimo dos AZs, tres para sistemas de quórum) es obligatoria; un ASG vinculado a una sola subred no puede sobrevivir a una interrupción de AZ porque el propio ASG no puede lanzar reemplazos mientras la AZ está deteriorada.

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: Seguimiento de Destino, Por Pasos, Programado, Predictivo

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

• El seguimiento de destino elige una métrica y la mantiene cerca de un punto de ajuste (por ejemplo, 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 predeterminada.
• El escalado por pasos añade o elimina capacidad en niveles graduados en función de lo lejos que esté una métrica del rango, útil cuando la magnitud de la reacción debe escalar con la gravedad de la alarma.
• El escalado simple es heredado: un solo ajuste por alarma, se bloquea durante el período de enfriamiento y no debe elegirse para nuevos diseños.
• El escalado programado cambia MinSize/DesiredCapacity/MaxSize en momentos cron.
• El escalado predictivo utiliza aprendizaje automático sobre hasta 14 días de historial para pronosticar las próximas 48 horas, preaprovisionando capacidad antes del aumento.

El escalado dinámico es inherentemente rezagado: reacciona solo después de que una métrica se incumple, y las nuevas instancias necesitan minutos para arrancar, registrarse y calentarse. Para una aplicación de fuerza laboral 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. Superpón acciones programadas 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 seguimiento de destino 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 día a día. Para apagados predecibles no productivos (entornos de desarrollo apagados por las noches y fines de semana), una acción programada a desired=0, min=0 el viernes por la noche y de nuevo el lunes por la mañana es la solución con menos sobrecarga: el propio ASG es el motor de programación, no se necesita pegamento de 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 ligadas a la CPU, pero para trabajadores impulsados por backlog que extraen de SQS, debes escalar en función de la profundidad de la cola, no de la CPU: un trabajador bloqueado en E/S puede mostrar un 10% de CPU mientras se acumulan millones de mensajes. Utiliza ApproximateNumberOfMessagesVisible por instancia, expuesto como una métrica personalizada o a través del objetivo SQSQueueBacklogPerInstance incorporado:

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, los niveles HTTP sensibles a la latencia deben rastrear TargetResponseTime o RequestCountPerTarget; las aplicaciones limitadas por memoria, disco o latencia descendente deben publicar una métrica personalizada que refleje el cuello de botella real. Escalar en función de la CPU cuando la CPU no es la restricción produce exactamente el modo de fallo en el que las instancias nunca escalan, las colas crecen sin límites y el ALB devuelve 5xx.

Comprobaciones de estado y Lifecycle Hooks

Los ASG utilizan por defecto las comprobaciones de estado de EC2, que detectan fallos del hipervisor pero no fallos 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. Establezca HealthCheckGracePeriod lo suficientemente largo 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 “sano”:

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 500s. Cambie a un ALB — o configure comprobaciones de estado HTTP en el NLB — para restaurar una señalización significativa.

Los Lifecycle hooks pausan las instancias en Pending:Wait o Terminating:Wait para que la automatización externa pueda actuar. En el lanzamiento, un hook le permite registrarse en un sistema de gestión de configuración, calentar cachés o extraer secretos antes de que el ALB envíe tráfico. Al terminar, un hook le permite drenar sesiones, vaciar registros y anular el registro de una malla de servicios. Los hooks emiten eventos de EventBridge; los manejadores deben llamar a CompleteLifecycleAction o el hook se agota en su valor predeterminado (CONTINUE o ABANDON).

Warm Pools e Hibernación

El tiempo de arranque en frío es un problema real para las aplicaciones que cargan modelos grandes, calientan cachés o compilan JIT antes de servir. Un warm pool es una reserva preinicializada adjunta al ASG: las instancias se lanzan, ejecutan el bootstrap, luego se detienen, se mantienen en ejecución o se hibernan, se mantienen en el pool hasta que el ASG escala. Extraer del pool 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 sistema operativo vuelvan a la reanudación. Requisitos: volumen raíz cifrado lo suficientemente grande como para contener la RAM, RAM de la instancia ≤ 150 GB en una familia compatible, y HibernationOptions.Configured = true en el lanzamiento. Un warm pool con PoolState: Hibernated combina ambos — las instancias no cuestan nada en cómputo mientras están detenidas y se reanudan en segundos con la memoria 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 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 — iniciar 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.

Dos patrones funcionan. Una alarma de CloudWatch en StatusCheckFailed_System emparejada con la acción de recuperación de EC2 preserva el ID de la instancia, la IP privada, la IP elástica y los adjuntos de EBS en caso de fallo del host subyacente. Más simple aún: un ASG con MinSize=MaxSize=1 que abarca múltiples AZs 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 de subredes

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

La ubicación de las subredes es donde las arquitecturas suelen fallar. Un ALB con acceso a Internet debe estar adjunto a subredes públicas — subredes con una ruta 0.0.0.0/0 a un Internet Gateway — una por AZ donde residen los destinos. Los destinos mismos permanecen en subredes privadas. Si el ALB se coloca en subredes privadas, o las subredes “públicas” carecen de una ruta predeterminada de IGW, los clientes verán tiempos de espera de conexión. La accesibilidad del destino requiere que el grupo de seguridad del destino permita la entrada 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)

Habilite 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 (predeterminado 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 a través de un registro de alias (o una política de ponderación/latencia a través de múltiples ALBs) — nunca apunte Route 53 a IPs individuales de EC2, porque una instancia fallida sigue recibiendo tráfico hasta que expire el TTL y el reemplazo del ASG tiene 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 de línea base en Instancias Reservadas o un Savings Plan, picos en On-Demand, 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 instancias 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 las instancias tengan menos probabilidades de ser reclamadas.

Spot es apropiado para cargas de trabajo sin estado, con puntos de control, reintentables o con redundancia horizontal: workers web detrás de un ALB, trabajos por lotes con reintento automático, ejecutores de Spark, runners de CI. No es apropiado como única capacidad para servicios críticos siempre activos, bases de datos primarias con estado o nodos líderes sin ruta de recuperación — un aviso de dos minutos no puede garantizar un apagado seguro, y la reclamación correlacionada de toda la flota de un tipo de instancia específico 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: se paga 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 capacidad en sí —no el precio— es la preocupación (pico impulsado por eventos, recuperación ante desastres), use una Reserva de Capacidad On-Demand: una garantía pura con alcance de AZ a tarifas On-Demand, combinable con un Savings Plan para el descuento.

Computación sin Servidor: Lambda y Fargate

Serverless traslada la gestión de la capacidad a la plataforma. Lambda se adapta a trabajos de corta duración y basados en eventos: triggers de ObjectCreated de S3, DynamoDB Streams, consumidores de SQS de bajo volumen, backends de API Gateway, lógica de pegamento. La memoria (128 MB – 10,240 MB) proporciona 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 de /tmp, 250 MB de despliegue descomprimido (o 10 GB a través de imagen de contenedor), 6 MB de carga útil síncrona. Usar Lambda para una transcodificación de video de 30 minutos, un ETL de varias horas o entrenamiento de GPU es arquitectónicamente incorrecto — la función se agota en medio del trabajo y la lógica de reintento simplemente multiplica el desperdicio. Para rutas sensibles a la latencia, mitigue los arranques en frío y el tiempo de inicialización de ENI adjunto a la VPC con Concurrencia Aprovisionada.

Fargate ejecuta contenedores sin gestionar hosts EC2. Es la elección correcta cuando las tareas superan los 15 minutos, necesitan tiempos de ejecución personalizados o se ajustan a 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 intermitente o impredecible, la facturación por segundo de Fargate es la ganadora.

Para la orquestación de muchas Lambdas, Step Functions es preferible a encadenar a través de SNS/SQS porque proporciona historial de ejecución visual, semántica de reintentos, manejo centralizado de errores y estado duradero. Los flujos de trabajo estándar se facturan por transición de estado y se ejecutan hasta 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 (fan-out) de miles de trabajos en contenedores parametrizados —genómica, Monte Carlo, ETL— AWS Batch maneja la cola, la resolución de dependencias, los reintentos y el aprovisionamiento en EC2 administrado, Spot o Fargate. Los trabajos hacen referencia a una definición de trabajo (contenedor + vCPU/memoria + rol de IAM) y Batch los empaqueta en instancias del tamaño adecuado. Step Functions con frecuencia orquesta Batch, Lambda y ECS dentro de una única máquina de estado.

Elastic Beanstalk

Beanstalk es un PaaS administrado que aprovisiona el ALB, ASG, instancias EC2 y, opcionalmente, RDS a partir de un paquete de aplicación. Admite despliegues rolling, rolling-with-additional-batch, inmutables y blue/green con integración de CloudWatch. Las políticas de escalado se exponen como opciones de entorno (métrica, umbrales, min/max). Debido a que Beanstalk utiliza por defecto tipos de instancias burstables, habilitar el modo T-unlimited es la solución de bajo esfuerzo para una breve saturación de CPU. Las acciones de escalado programadas se adjuntan al ASG administrado por Beanstalk como cualquier otra. Elija Beanstalk cuando el equipo quiera una topología de aplicación web estándar sin crear CloudFormation manualmente y cuando las actualizaciones continuas y los paquetes versionados coincidan con el ritmo de lanzamiento.

Gestión de flotas con Systems Manager

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

• Run Command ejecuta shell/PowerShell en flotas etiquetadas con salida consolidada.
• Session Manager abre shells interactivos a través de la API de AWS — sin entrada 22, sin bastión, autenticación IAM completa, sesiones registradas en S3 o CloudWatch Logs.
• Patch Manager aplica parches del sistema operativo en horarios usando 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 programada

Para EC2 y RDS no productivos que deben estar apagados fuera del horario comercial, 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 sin servidor, no tiene flota que parchear y escala por etiqueta. La solución AWS Instance Scheduler funciona de manera equivalente. Una sutileza: una instancia RDS detenida se inicia automáticamente después de siete días, por lo que el programa de detención debe repetirse para volver a detenerla. Combinado con ASG cuyas acciones programadas anulan la capacidad los fines de semana, el costo de las horas inactivas se acerca a cero.

Trampas de red en torno a la computación escalada

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

Instancias NAT. Una única NAT basada en EC2 se convierte en un cuello de botella de ancho de banda y PPS a medida que la flota crece, y es un SPOF. Los NAT Gateways administrados escalan hasta 100 Gbps por gateway. Para el tráfico de servicios de AWS, los VPC endpoints (Gateway para S3/DynamoDB, 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

• ASG de una sola AZ no pueden sobrevivir a una interrupción de AZ — siempre adjunte subredes de al menos dos AZs (tres para sistemas de quórum), y mantenga MinSize ≥ 2.
• Asumir que cada carga de trabajo escala horizontalmente. Las aplicaciones con estado, de un solo escritor o con licencia no agrupable empeoran bajo un ASG. Use la recuperación automática o refactorice primero.
• El escalado reactivo para picos predecibles produce el síntoma de “lentitud durante las primeras 2-3 horas”. Use el escalado programado o predictivo para precalentar.
• Escalar en CPU cuando la CPU no es la restricción. Publique una métrica que refleje el cuello de botella real: profundidad de cola, tiempo de respuesta, número de conexiones.
• El escalado simple y las configuraciones de lanzamiento son legados — prefiera el seguimiento de objetivos y las plantillas de lanzamiento.
• Las comprobaciones de estado solo de TCP en aplicaciones HTTP dejan instancias rotas en rotación. Use comprobaciones HTTP (a través de ALB o comprobaciones NLB en modo HTTP).
• Spot para cargas de trabajo con estado o que no deben interrumpirse — Spot exige trabajadores reemplazables y con puntos de control.
• Instancias reservadas o planes de ahorro en cargas de trabajo genuinamente variables — el compromiso no utilizado es un puro desperdicio; reduzca los costos con el dimensionamiento correcto y Spot en su lugar.
• Apuntar Route 53 a IPs individuales de EC2 — enrute al alias de ALB para que DNS refleje la rotación de la flota.
• Tratar el almacenamiento de instancias como duradero — los datos desaparecen al detener, terminar o fallar el host.
• Ignorar la latencia de carga diferida después de la restauración de instantáneas o el lanzamiento de AMI — habilite la Restauración rápida de instantáneas en las AZ de destino.

Todos los dominios · Contenedores y Orquestación →

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

Explorar Amazon →