Startmallar och ASG-konfiguration

En startmall är en versionshanterad ritning som anger för Auto Scaling Groups (och EC2 direkt) hur instanser ska startas. Den samlar AMI-ID, instanstyp, nyckelpar, säkerhetsgrupper och valfria användardata i ett enda återanvändbart dokument. Till skillnad från den äldre Launch Configuration stöder en startmall flera versioner och kan uppdateras utan att ASG:t behöver ersättas.

Du kan skapa en startmall med AWS CLI med hjälp av create-launch-template. Parametern --launch-template-data tar emot ett JSON-objekt som definierar alla inställningar för instansen. Versionshantering gör det möjligt att iterera på mallen utan att påverka körande instanser förrän du är redo att distribuera.

Alla startmallar börjar med version 1. När du skapar en ny version kan du endast åsidosätta de fält som har ändrats – alla andra inställningar ärvs från källversionen. ASG:t kan konfigureras att använda en $Latest-version (alltid den nyaste) eller en $Default-version (den som uttryckligen har angetts som standard). Med $Default får du kontrollerade utrullningar, medan $Latest är praktiskt i utvecklingsmiljöer.

En Auto Scaling Group (ASG) hanterar en flotta av EC2-instanser inom angivna gränser: minimum (lägsta antal), maximum (högsta antal) och desired capacity (målvärdet för antalet instanser vid varje tidpunkt). När instanser misslyckas med hälsokontroller eller när en skalningsprincip aktiveras startar eller avslutar ASG automatiskt instanser, så att flottan håller sig på det önskade antalet mellan minimi- och maximigränsen.

När du skapar en ASG refererar du till en Launch Template (inte direkt till en specifik AMI). Du anger också de VPC-subnät där instanserna ska startas. Genom att fördela instanser över flera subnät (ett per AZ) får du inbyggd redundans över flera AZ:er – om en AZ slutar fungera startar ASG automatiskt ersättningsinstanser i de återstående AZ:erna.

Som standard använder en ASG EC2-hälsokontroller, som endast markerar en instans som ohälsosam om den är stoppad, avslutad eller om hypervisorn rapporterar att den har slutat fungera. När du kopplar en lastbalanserare bör du byta till ELB-hälsokontroller, så att ASG ersätter instanser som körs men returnerar HTTP 5xx-fel. Detta är en vanlig tentafråga: välj alltid ELB-hälsokontroller när arkitekturen innehåller en lastbalanserare.

Det är avgörande att ange rätt kapacitetsgränser. Minimum säkerställer att din applikation alltid kan hantera trafik (den går aldrig under detta värde). Maximum förhindrar okontrollerad skalning som kan överskrida tjänstegränser eller budget. Desired capacity är det initiala målet, och skalningsprinciper justerar det dynamiskt. Om du anger min=max=desired fungerar ASG som en grupp med fast storlek, vilket är användbart vid distributioner med Launch Template eller när kapaciteten ska vara låst.

För applikationer i webbskiktet kopplar du ASG till en target group för Application Load Balancer. Varje ny instans som startas av ASG registreras automatiskt i target group, och avslutade instanser avregistreras automatiskt. Detta säkerställer att trafik endast går till friska instanser som körs. Du måste också ange hälsokontrolltypen till ELB, så att ASG känner till fel på lastbalanserarnivå.

User data är ett skalskript (Base64-kodat) som körs en gång när en instans startar för första gången. I en Launch Template är det rätt plats för att installera paket, konfigurera agenter (CloudWatch, SSM) och hämta applikationskod. Se till att user data är idempotent – skript som kan köras säkert flera gånger förebygger problem under instansuppdateringar. För komplexa konfigurationer bör du anropa AWS Systems Manager eller ett verktyg för konfigurationshantering i stället för att bädda in stora skript.

En Warm Pool initierar i förväg en uppsättning stoppade (eller körande) EC2-instanser i ett redo-läge utanför ASG. När ASG behöver skala ut hämtar den instanser från warm pool i stället för att starta instanser från grunden – vilket kraftigt minskar tiden det tar att lägga till kapacitet. Instanser i warm pool medför kostnader för stoppat tillstånd (endast EBS, inga CPU-kostnader), vilket gör detta mycket billigare än att hålla fullständigt körande reservinstanser.

När ASG skalar in måste den avgöra vilka instanser som ska avslutas. Standardinställningen för termination policy väljer först den AZ som har flest instanser (för att återställa balansen), sedan den äldsta Launch Template och därefter den instans som är närmast sin fakturerings timme. Du kan anpassa ordningen – välj till exempel OldestLaunchTemplate för att först ta bort instanser med gamla konfigurationer. ASG utför också automatiskt AZ-ombalansering när ett subnät blir tillgängligt eller efter manuella ändringar.

I den här lektionen har du lärt dig att Launch Templates tillhandahåller en versionshanterad och återanvändbar ritning för instanser som stöder flera versioner samt versionspekare som $Latest/$Default, att ASG-kapacitetsgränser (min/max/desired) styr flottans storlek med automatisk fördelning över flera AZ:er mellan subnät, och att ELB-hälsokontroller måste aktiveras när en ASG ligger bakom en lastbalanserare, så att fel på applikationsnivå utlöser ersättning. Nästa steg är att utforska skalningsprinciper, inklusive target tracking och step scaling.