Launch Templates y configuración de ASG

Una Launch Template es un esquema versionado que indica a los grupos de Auto Scaling (y directamente a EC2) cómo lanzar instancias. Contiene el AMI ID, el tipo de instancia, el par de claves, los grupos de seguridad y los datos de usuario opcionales en un único documento reutilizable. A diferencia de la antigua Launch Configuration, una Launch Template admite varias versiones y puede actualizarse sin reemplazar el ASG.

Puede crear una Launch Template con la AWS CLI mediante create-launch-template. El parámetro --launch-template-data acepta un objeto JSON que define toda la configuración de la instancia. El control de versiones permite iterar sobre la plantilla sin afectar a las instancias en ejecución hasta que esté listo para implementarla.

Toda Launch Template comienza en la versión 1. Al crear una nueva versión, solo tiene que sobrescribir los campos que hayan cambiado; el resto de la configuración se hereda de la versión de origen. Puede indicar al ASG que use una versión $Latest (siempre la más reciente) o una versión $Default (designada explícitamente). Usar $Default proporciona implementaciones controladas, mientras que $Latest resulta práctico en entornos de desarrollo.

Un Auto Scaling Group (ASG) mantiene un conjunto de instancias EC2 dentro de unos límites definidos: mínimo (límite inferior), máximo (límite superior) y capacidad deseada (cantidad objetivo en cada momento). Cuando las instancias no superan las comprobaciones de estado o se activa la política de escalado, el ASG inicia o termina instancias automáticamente para mantener la cantidad deseada dentro de los límites mínimo y máximo.

Al crear un ASG, se hace referencia a una Launch Template (no a una AMI específica directamente). También se especifican las subredes de la VPC en las que se iniciarán las instancias. Distribuirlas entre varias subredes (una por AZ) proporciona redundancia integrada entre varias AZ: si una AZ falla, el ASG inicia automáticamente instancias de reemplazo en las AZ restantes.

De forma predeterminada, un ASG utiliza comprobaciones de estado de EC2, que solo marcan una instancia como no saludable si está detenida, terminada o si el hipervisor informa de un fallo. Cuando se asocia un balanceador de carga, debe cambiar a comprobaciones de estado de ELB para que el ASG reemplace las instancias que están en ejecución pero devuelven errores HTTP 5xx. Esta es una pregunta habitual de examen: elija siempre las comprobaciones de estado de ELB cuando haya un balanceador de carga en la arquitectura.

Configurar correctamente los límites de capacidad es fundamental. La capacidad mínima garantiza que la aplicación siempre pueda atender tráfico (nunca se desciende por debajo de este valor). La capacidad máxima evita un escalado descontrolado que podría agotar los límites de los servicios o el presupuesto. La capacidad deseada es el objetivo inicial; las políticas de escalado la ajustan dinámicamente. Si establece min=max=desired, el ASG funciona como un grupo de tamaño fijo, lo que resulta útil para implementaciones de plantillas de lanzamiento o para mantener una capacidad fija.

Para las aplicaciones de la capa web, asocie el ASG a un grupo de destino de Application Load Balancer. Cada instancia nueva que inicia el ASG se registra automáticamente en el grupo de destino, y las instancias terminadas se eliminan automáticamente del registro. Esto garantiza que el tráfico solo se dirija a instancias saludables y en ejecución. También debe establecer el tipo de comprobación de estado en ELB para que el ASG detecte los fallos del nivel del balanceador de carga.

Los datos de usuario son un script de shell (codificado en Base64) que se ejecuta una vez cuando una instancia arranca por primera vez. En una Launch Template, es el lugar adecuado para instalar paquetes, configurar agentes (CloudWatch, SSM) y obtener el código de la aplicación. Mantenga los datos de usuario idempotentes: los scripts que pueden ejecutarse varias veces de forma segura evitan problemas durante la actualización de instancias. Para configuraciones complejas, recurra a AWS Systems Manager o a una herramienta de gestión de configuración en lugar de incluir scripts de gran tamaño.

Un Warm Pool inicializa previamente un conjunto de instancias EC2 detenidas (o en ejecución) en un estado preparado, fuera del ASG. Cuando el ASG necesita escalar horizontalmente, obtiene instancias del grupo de calentamiento en lugar de iniciar instancias desde cero, lo que reduce drásticamente el tiempo necesario para añadir capacidad. Las instancias del grupo de calentamiento generan costes del estado detenido (solo EBS, sin cargos de CPU), por lo que resulta mucho más económico que mantener reservas completamente en ejecución.

Cuando el ASG reduce horizontalmente, debe decidir qué instancias terminar. La política de terminación predeterminada selecciona primero la AZ que tiene más instancias (para reequilibrar), después la plantilla de lanzamiento más antigua y, por último, la instancia más cercana a su hora de facturación. Puede personalizar este orden; por ejemplo, puede elegir OldestLaunchTemplate para eliminar primero las instancias que ejecutan configuraciones obsoletas. El ASG también realiza automáticamente el reequilibrio entre AZ después de que una subred vuelva a estar disponible o tras cambios manuales.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las Launch Templates proporcionan un plano versionado y reutilizable de las instancias, compatible con varias versiones y con los punteros de versión $Latest/$Default; que los límites de capacidad del ASG (mínimo/máximo/deseada) controlan el tamaño del conjunto con distribución automática entre varias AZ mediante subredes; y que las comprobaciones de estado de ELB deben habilitarse cuando un ASG se encuentra detrás de un balanceador de carga, para que los fallos a nivel de aplicación activen reemplazos. A continuación exploraremos las políticas de escalado, incluido el seguimiento de objetivos y el escalado por pasos.