Auto Scaling en AWS

Auto Scaling en AWS

En junio de 2024, Nexiia Bank lanzó su nuevo asistente financiero impulsado por IA dentro de su app móvil. El interés superó todas las expectativas: en solo horas, cientos de miles de usuarios comenzaron a interactuar simultáneamente con la herramienta, generando una carga inesperada sobre los sistemas backend.

Lo que garantizó una experiencia fluida y sin interrupciones fue una infraestructura basada en AWS Auto Scaling, que permitió aprovisionar automáticamente nuevos recursos durante los picos de uso, y reducirlos dinámicamente cuando la demanda bajó. Así, Nexia Bank logró mantener la calidad del servicio sin incurrir en costos innecesarios en momentos de baja actividad.

Este caso es un claro ejemplo del poder del Auto Scaling en AWS: garantizar alto rendimiento en momentos críticos, sin sacrificar eficiencia operativa ni presupuesto.

Tipos de Auto Scaling en AWS

AWS ofrece diferentes mecanismos de Auto Scaling adaptados a distintos servicios y necesidades. Comprender sus diferencias es fundamental para implementar la estrategia correcta.

Auto Scaling Group (ASG) para EC2

El Auto Scaling Group es el servicio original de escalado automático en AWS, diseñado específicamente para instancias EC2:

• Características principales:
  • Mantiene un número específico de instancias EC2 en ejecución
  • Escala horizontal (añade/elimina instancias) según políticas definidas
  • Distribuye instancias entre zonas de disponibilidad
  • Reemplaza automáticamente instancias no saludables

# Estructura básica de un Auto Scaling Group
{
  "AutoScalingGroupName": "web-asg",
  "LaunchTemplate": {
    "LaunchTemplateId": "lt-0123456789abcdef0",
    "Version": "$Latest"
  },
  "MinSize": 2,
  "MaxSize": 10,
  "DesiredCapacity": 2,
  "AvailabilityZones": ["us-east-1a", "us-east-1b", "us-east-1c"],
  "HealthCheckType": "ELB",
  "HealthCheckGracePeriod": 300
}

Auto Scaling para ECS (Elastic Container Service)

ECS ofrece capacidades de Auto Scaling a nivel de servicio, lo que permite escalar el número de tareas (contenedores) en ejecución:

• Características principales:
  • Escala el número de tareas, no las instancias subyacentes
  • Soporta escalado basado en utilización de CPU/memoria o métricas personalizadas
  • Se integra con Application Auto Scaling (no con EC2 Auto Scaling)
  • Puede funcionar tanto en modo EC2 como en Fargate (serverless)

# Ejemplo de configuración de Auto Scaling para ECS
aws application-autoscaling register-scalable-target \\
  --service-namespace ecs \\
  --scalable-dimension ecs:service:DesiredCount \\
  --resource-id service/my-cluster/my-service \\
  --min-capacity 1 \\
  --max-capacity 10

Auto Scaling para EKS (Elastic Kubernetes Service)

EKS utiliza dos niveles de Auto Scaling:

• Cluster Autoscaler:
  • Escala los nodos de trabajo (instancias EC2) del clúster
  • Integrado con EC2 Auto Scaling Groups
  • Añade/elimina nodos cuando hay pods pendientes o recursos infrautilizados
• Horizontal Pod Autoscaler (HPA):
  • Escala el número de pods (no las instancias)
  • Basado en utilización de CPU/memoria o métricas personalizadas
  • Nativo de Kubernetes, no específico de AWS

# Ejemplo de Horizontal Pod Autoscaler en EKS
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Comparativa de los diferentes tipos de Auto Scaling

Políticas de Escalado

Las políticas de escalado definen cómo y cuándo se ajusta la capacidad. AWS ofrece varios tipos de políticas para adaptarse a diferentes necesidades.

Política Simple

La política simple ajusta la capacidad en un número específico o porcentaje cuando se supera un umbral:

• Características:
  • Ajuste fijo (añadir/eliminar N instancias o X%)
  • Requiere alarmas de CloudWatch
  • Incluye período de enfriamiento (cooldown)

# Ejemplo de política simple
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name scale-out-policy \\
  --scaling-adjustment 1 \\
  --adjustment-type ChangeInCapacity \\
  --cooldown 300

Política Step (Escalado por pasos)

La política step permite definir múltiples ajustes basados en la magnitud de la alarma:

• Características:
  • Diferentes ajustes según la magnitud de la métrica
  • Mayor precisión que la política simple
  • Cada paso puede tener su propio período de enfriamiento

# Ejemplo de política step
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name cpu-scale-out-policy \\
  --policy-type StepScaling \\
  --adjustment-type ChangeInCapacity \\
  --step-adjustments MetricIntervalLowerBound=0.0,MetricIntervalUpperBound=20.0,ScalingAdjustment=1 \\
                     MetricIntervalLowerBound=20.0,MetricIntervalUpperBound=40.0,ScalingAdjustment=2 \\
                     MetricIntervalLowerBound=40.0,ScalingAdjustment=3

Política Target Tracking (Seguimiento de objetivo)

La política target tracking mantiene una métrica cerca de un valor objetivo específico:

• Características:
  • Ajuste automático para mantener la métrica en el valor objetivo
  • No requiere crear alarmas manualmente
  • Más simple de configurar y mantener
  • Ideal para métricas que escalan linealmente con la capacidad

# Ejemplo de política target tracking
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name cpu-target-tracking-policy \\
  --policy-type TargetTrackingScaling \\
  --target-tracking-configuration file://config.json

# Contenido de config.json
{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

Política Scheduled (Programada)

La política scheduled permite ajustar la capacidad en momentos específicos:

• Características:
  • Basada en patrones temporales predecibles
  • Puede ser recurrente (cron) o única
  • Ideal para patrones de tráfico conocidos

# Ejemplo de política programada
aws autoscaling put-scheduled-update-group-action \\
  --auto-scaling-group-name web-asg \\
  --scheduled-action-name increase-capacity-weekdays \\
  --recurrence "0 8 * * MON-FRI" \\
  --min-size 5 \\
  --max-size 15 \\
  --desired-capacity 10

Política Predictiva

La política predictiva utiliza machine learning para predecir patrones de tráfico:

• Características:
  • Analiza patrones históricos para predecir demanda futura
  • Escala proactivamente antes de que ocurra el pico de demanda
  • Requiere al menos 24 horas de datos históricos
  • Solo disponible para EC2 Auto Scaling

# Ejemplo de política predictiva
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name predictive-scaling-policy \\
  --policy-type PredictiveScaling \\
  --predictive-scaling-configuration file://predictive-config.json

# Contenido simplificado de predictive-config.json
{
  "MetricSpecifications": [
    {
      "TargetValue": 70.0,
      "PredefinedMetricPairSpecification": {
        "PredefinedMetricType": "ASGCPUUtilization"
      }
    }
  ],
  "Mode": "ForecastAndScale",
  "SchedulingBufferTime": 300
}

Launch Configuration vs. Launch Template

Tanto Launch Configuration como Launch Template definen la configuración de las instancias que lanzará el Auto Scaling Group, pero con diferencias importantes.

Launch Configuration (Legacy)

• Características:
  • Inmutable (no se puede modificar después de crear)
  • No soporta versionamiento
  • No se puede usar fuera de Auto Scaling
  • Soporte limitado para características nuevas de EC2

# Ejemplo de Launch Configuration
aws autoscaling create-launch-configuration \\
  --launch-configuration-name web-lc \\
  --image-id ami-0abcdef1234567890 \\
  --instance-type t3.micro \\
  --security-groups sg-0123456789abcdef0 \\
  --user-data file://user-data.sh

Launch Template (Recomendado)

• Características:
  • Soporta versionamiento (múltiples versiones de la misma plantilla)
  • Se puede modificar (creando nuevas versiones)
  • Puede usarse fuera de Auto Scaling (EC2 RunInstances, Spot Fleet)
  • Soporta todas las características nuevas de EC2
  • Permite configuración parcial

# Ejemplo de Launch Template
aws ec2 create-launch-template \\
  --launch-template-name web-lt \\
  --version-description "Initial version" \\
  --launch-template-data '{
    "ImageId": "ami-0abcdef1234567890",
    "InstanceType": "t3.micro",
    "SecurityGroupIds": ["sg-0123456789abcdef0"],
    "UserData": "IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8gV29ybGQi"
  }'

Versionamiento de Launch Templates

El versionamiento es una de las principales ventajas de Launch Templates:

• Versiones numeradas: cada modificación crea una nueva versión numerada
• Versiones especiales:
  • $Latest: siempre apunta a la versión más reciente
  • $Default: versión marcada como predeterminada

# Crear nueva versión de Launch Template
aws ec2 create-launch-template-version \\
  --launch-template-id lt-0123456789abcdef0 \\
  --version-description "Updated AMI" \\
  --source-version 1 \\
  --launch-template-data '{"ImageId": "ami-0fedcbabcdef12345"}'

# Establecer versión predeterminada
aws ec2 modify-launch-template \\
  --launch-template-id lt-0123456789abcdef0 \\
  --default-version 2

Migración de Launch Configuration a Launch Template

AWS recomienda migrar de Launch Configuration a Launch Template:

1. Crear Launch Template basado en la configuración existente
2. Actualizar Auto Scaling Group para usar el nuevo Launch Template
3. Verificar funcionamiento y eliminar Launch Configuration antigua

Escalado basado en métricas de CloudWatch

CloudWatch proporciona las métricas que impulsan las decisiones de Auto Scaling. Comprender estas métricas es crucial para implementar políticas efectivas.

Métricas predefinidas comunes

• CPU Utilization: porcentaje de uso de CPU (la más común)
• Network In/Out: bytes transferidos por la red
• ALB Request Count Per Target: número de solicitudes por instancia
• Custom CloudWatch Metrics: métricas personalizadas específicas de la aplicación

# Política basada en CPU
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name cpu-policy \\
  --policy-type TargetTrackingScaling \\
  --target-tracking-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    }
  }'

# Política basada en ALB Request Count
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name request-count-policy \\
  --policy-type TargetTrackingScaling \\
  --target-tracking-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/1234567890123456/targetgroup/my-target-group/abcdef1234567890"
    }
  }'

Métricas personalizadas

Para casos donde las métricas predefinidas no son suficientes, se pueden usar métricas personalizadas:

1. Publicar métricas personalizadas en CloudWatch desde la aplicación
2. Crear alarmas de CloudWatch basadas en estas métricas
3. Configurar políticas de escalado que respondan a estas alarmas

# Publicar métrica personalizada
aws cloudwatch put-metric-data \\
  --namespace "MyApplication" \\
  --metric-name "ActiveUsers" \\
  --value 42 \\
  --dimensions "Service=UserService,Environment=Production"

# Política basada en métrica personalizada
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name web-asg \\
  --policy-name custom-metric-policy \\
  --policy-type TargetTrackingScaling \\
  --target-tracking-configuration '{
    "TargetValue": 100.0,
    "CustomizedMetricSpecification": {
      "MetricName": "ActiveUsers",
      "Namespace": "MyApplication",
      "Dimensions": [
        {"Name": "Service", "Value": "UserService"},
        {"Name": "Environment", "Value": "Production"}
      ],
      "Statistic": "Average"
    }
  }'

Consideraciones para la selección de métricas

• Correlación con capacidad: la métrica debe escalar linealmente con la capacidad
• Granularidad: frecuencia de recopilación (1 minuto recomendado)
• Volatilidad: métricas muy volátiles pueden causar oscilaciones
• Representatividad: debe reflejar la carga real del sistema

Lifecycle Hooks y Notificaciones

Los lifecycle hooks permiten ejecutar acciones personalizadas durante eventos de escalado, mientras que las notificaciones informan sobre estos eventos.

Lifecycle Hooks

Los lifecycle hooks interceptan instancias en transición para realizar acciones personalizadas:

• Tipos de hooks:
  • autoscaling:EC2_INSTANCE_LAUNCHING: antes de que una instancia entre en servicio
  • autoscaling:EC2_INSTANCE_TERMINATING: antes de que una instancia sea terminada
• Estados de transición:
  • Pending: esperando acción personalizada durante lanzamiento
  • Terminating: esperando acción personalizada durante terminación
• Acciones posibles:
  • CONTINUE: proceder con el ciclo de vida normal
  • ABANDON: si es lanzamiento, terminar la instancia; si es terminación, proceder

# Crear lifecycle hook
aws autoscaling put-lifecycle-hook \\
  --auto-scaling-group-name web-asg \\
  --lifecycle-hook-name instance-prep-hook \\
  --lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \\
  --heartbeat-timeout 300 \\
  --default-result ABANDON \\
  --notification-target-arn arn:aws:sns:us-east-1:123456789012:my-topic \\
  --role-arn arn:aws:iam::123456789012:role/AutoScalingNotificationRole

Casos de uso comunes para Lifecycle Hooks

• Durante lanzamiento:
  • Instalación y configuración de software
  • Registro en servicios externos
  • Descarga de datos o configuraciones
  • Validaciones de seguridad
• Durante terminación:
  • Drenaje de conexiones activas
  • Backup de datos locales
  • Notificación a otros servicios
  • Limpieza de recursos externos

# Ejemplo de script de user data que completa un lifecycle hook
#!/bin/bash
# Instalar software y configurar
yum update -y
yum install -y httpd
systemctl start httpd

# Señalizar que la instancia está lista
aws autoscaling complete-lifecycle-action \\
  --lifecycle-hook-name instance-prep-hook \\
  --auto-scaling-group-name web-asg \\
  --lifecycle-action-result CONTINUE \\
  --instance-id $(curl -s <http://169.254.169.254/latest/meta-data/instance-id>) \\
  --region us-east-1

Notificaciones de Auto Scaling

Las notificaciones permiten monitorear eventos de Auto Scaling:

• Tipos de eventos:
  • Lanzamiento/terminación de instancias
  • Inicio/fin de actividades de escalado
  • Fallos en actividades de escalado
  • Cambios en límites de capacidad
• Destinos de notificación:
  • Amazon SNS (Simple Notification Service)
  • Amazon EventBridge

# Configurar notificaciones
aws autoscaling put-notification-configuration \\
  --auto-scaling-group-name web-asg \\
  --topic-arn arn:aws:sns:us-east-1:123456789012:my-topic \\
  --notification-types "autoscaling:EC2_INSTANCE_LAUNCH" "autoscaling:EC2_INSTANCE_TERMINATE" "autoscaling:EC2_INSTANCE_LAUNCH_ERROR" "autoscaling:EC2_INSTANCE_TERMINATE_ERROR"

Integración con EventBridge

EventBridge ofrece capacidades avanzadas para reaccionar a eventos de Auto Scaling:

• Ventajas:
  • Filtrado avanzado de eventos
  • Múltiples destinos por evento
  • Integración con más de 20 servicios AWS

# Regla de EventBridge para eventos de Auto Scaling
{
  "source": ["aws.autoscaling"],
  "detail-type": ["EC2 Instance Launch Successful"],
  "detail": {
    "AutoScalingGroupName": ["web-asg"]
  }
}

Consideraciones Finales

Auto Scaling es una pieza fundamental en arquitecturas cloud modernas, permitiendo que las aplicaciones respondan automáticamente a cambios en la demanda. Al implementar Auto Scaling en AWS, es importante considerar:

• Selección del tipo adecuado: EC2 Auto Scaling, ECS Service Auto Scaling o Kubernetes HPA según el caso de uso
• Políticas apropiadas: simple para casos básicos, target tracking para la mayoría de aplicaciones, predictive para patrones recurrentes
• Métricas relevantes: que reflejen realmente la carga del sistema
• Launch Templates: aprovechar el versionamiento para facilitar actualizaciones y rollbacks
• Lifecycle hooks: para integraciones complejas y transiciones suaves

Una implementación bien diseñada de Auto Scaling no solo optimiza costos al eliminar capacidad innecesaria, sino que también mejora la disponibilidad al añadir recursos automáticamente durante picos de demanda. Esto convierte a Auto Scaling en una herramienta esencial para cumplir con los principios de optimización de costos y fiabilidad del AWS Well-Architected Framework.