Introducción
Una aplicación puede necesitar más servidores y luego menos. Definirás dos políticas, ampliarás la flota de dos a tres y volverás a dos. Verificarás respuestas HTTP reales y cómo los límites impiden seguir aumentando o reduciendo.
Debes conocer plantillas, grupos Auto Scaling y comprobaciones ALB. Este entorno nuevo proporciona un grupo saludable independiente application-fleet de dos instancias, plantilla, red y balanceador. No reutiliza recursos anteriores.
Relación con certificaciones
Ofrece práctica introductoria de SAA-C03 Domain 2 y SOA-C03 Domain 2: capacidad Auto Scaling, acciones de escalado e integración del balanceador.
Definir políticas de escalado
Inspeccionarás la flota y crearás políticas sin cambiar capacidad.
Entra en el directorio y consulta la capacidad inicial:
cd /home/labex/project
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
TG_ARN=$(aws elbv2 \
describe-target-groups \
--names application-targets \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--names application-alb \
--query 'LoadBalancers[0].DNSName' \
--output text)
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Espera mínimo 2, deseado 2, máximo 3 y dos destinos saludables en AWS View. Una política de escalado define el ajuste. ChangeInCapacity cambia una cantidad absoluta: 1 añade un servidor; -1 quita uno.
Crea dos políticas SimpleScaling. El tiempo de espera normalmente permite estabilizar una acción antes de otra activada por alarma. Guarda 30 segundos:
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment 1 \
--cooldown 30
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment -1 \
--cooldown 30
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].{Name:PolicyName,Type:PolicyType,Adjustment:ScalingAdjustment,Cooldown:Cooldown}'
Crear políticas no las ejecuta. Aquí se invocan con --no-honor-cooldown para observar cambios controlados. No demuestra el cumplimiento temporal del cooldown ni alarmas CloudWatch. En producción, las políticas por métricas usan alarmas; target tracking sigue un valor objetivo. Aquí no se prueba retroalimentación automática ni carga CPU.
Ampliar a tres servidores
Ejecutarás la política positiva y verificarás que el servidor adicional atiende solicitudes reales.
Scale-out añade instancias. Ejecuta la política y espera la disponibilidad ALB:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
Espera capacidad 3 y tres IDs actuales. El grupo utiliza su plantilla para el nuevo servidor y lo registra automáticamente.
Ejecuta de nuevo la política en el máximo y consulta capacidad:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
La capacidad sigue 3; el ajuste no supera el máximo del grupo. El límite controla servidores, no solicitudes por servidor.
Envía nueve solicitudes y compara los IDs con los tres servidores actuales:
for request in 1 2 3 4 5 6 7 8 9; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Abre AWS View. Confirma deseado 3, tres destinos saludables y respuestas reales 200 de todos con Send request. Un recurso añadido en la API no demuestra que atienda tráfico.
Ejemplo: capacidad deseada tres y el servidor adicional devuelve HTTP 200. Tus IDs serán distintos.
Reducir y conservar el mínimo
Reducirás capacidad y confirmarás que dos servidores siguen disponibles.
Scale-in elimina instancias. Ejecuta la política negativa y espera destinos saludables:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
aws ec2 \
describe-instances \
--filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Espera dos IDs actuales y una instancia terminated. El grupo elige cuál quitar; no supongas que siempre elimina la más reciente. La eliminada no debe formar parte de los destinos activos.
Ejecuta de nuevo la política negativa en el mínimo y consulta capacidad:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
El deseado sigue 2; la política no reduce por debajo del mínimo. Envía seis solicitudes para probar la flota restante:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
En AWS View, confirma dos destinos saludables y respuestas 200 de ambos IDs actuales. El ID terminado no debe aparecer en nuevas respuestas. Se comprueba ciclo de vida y rutas, no tiempos de drenaje ni conservación de sesiones.
Eliminar políticas y conservar la flota
Eliminarás las políticas tras devolver la flota proporcionada a dos servidores.
Elimina ambas políticas y consulta el inventario restante:
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].PolicyName'
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize}'
La lista debe ser [] y el grupo debe conservar mínimo 2, deseado 2, máximo 3. Eliminar políticas no termina la flota existente. Conserva grupo, plantilla, balanceador y red; AWS View debe mostrar dos servidores saludables.
Resumen
Definiste políticas simples positivas y negativas, observaste ampliación real de dos a tres y reducción a dos, y probaste ambos límites. Verificaste HTTP real y terminación nativa, luego eliminaste políticas conservando la flota restaurada.
Ya puedes distinguir configuración, ejecución explícita y activación por métricas. El desafío aplica diagnóstico de rutas y salud a un servidor nuevo que no recibe tráfico.
