Upgrade EC2 instance types for Amazon EC2 Auto Scaling groups

This guide walks you through upgrading EC2 instance types for Amazon EC2 Auto Scaling groups (ASGs) behind a load balancer. You’ve got two main paths:

• Option 1 (recommended for traffic-facing apps): Blue/Green deployment Create a parallel “green” environment with new instance types, validate it, then cut over via DNS.
• Option 2: Instance Refresh deployment Update an existing ASG in place using Instance Refresh and a new Launch Template version.

---

​

Before you start

Make sure:

• You can log in to the AWS Console and have IAM permissions for:
  • EC2, Auto Scaling, ELB/ALB/NLB, IAM, and Route 53 (if you manage DNS).
• You understand your app’s ingress:
  • Which load balancer you use: ALB / NLB / Classic.
  • Which Target Group(s) your ASGs register into and what health checks they use.
  • Where your DNS (e.g., api.example.com) points today.

---

​

Option 1 · Blue/Green deployment (recommended for traffic-facing apps)

You’ll create a parallel green environment (new Target Group, Load Balancer, ASG with new instance types), validate it, then update DNS to send traffic to green. Rollback is just switching DNS back.

​

Step 1 · Create the parallel (green) environment

​

1.1 Create a new Target Group (green)

In the Target Groups section (EC2 console):

• Target type
  • Usually instance for Auto Scaling Groups.
• Health checks
  • Protocol/port: match your app (e.g., HTTP:80 or HTTPS:443).
  • Path: realistic health endpoint (e.g., /health, /status).
  • Thresholds: set conservative values for prod (e.g., slightly more lenient than default until you’re confident).
• Deregistration delay
  • Typical values: 60–300 seconds.
  • This controls how long in-flight connections are allowed to drain after instance removal.

This is your green Target Group.

​

1.2 Create a new Load Balancer (green)

In the Load Balancers section:

• Choose ALB (HTTP/HTTPS) or NLB (TCP/UDP/HTTPS) to match your app.
• Subnets
  • Use the same subnets/AZs as your current (blue) environment for high availability.
• Security group
  • For ALB: mirror rules from the blue ALB; review any source IP allowlists or security boundaries.
• Listeners & routing
  • Recreate the listeners you have on the blue LB (ports, protocols, SSL certs).
  • Forward listener traffic to the green Target Group you created above.
  • Any path-based routing rules from blue should be mirrored.

This LB + Target Group pair forms the front door of your green environment.

​

1.3 Create or update a Launch Template

You’ll now create a new Launch Template version for the new instance type.

1. Go to EC2 → Launch Templates.
2. Find your current template used by the blue ASG.
3. Choose Create new version.

In the new version:

• Instance type
  • Set this to the new instance type, for example:
    m6a.xlarge
    
  • If a MilkStraw AI task sent you here, use the instance type that the task recommends.
• Root volume size
  • Adjust if your application needs more disk space:
    • Typical: 50–100 GiB.
    • More if you store large logs/cache/data on the instance.
• User data
  • Adjust only if needed (e.g., different bootstrap logic, AMI, or agent configuration).
  • Keep it as close as possible to the blue environment to reduce variables.

Save this as Launch Template Version N+1.

​

1.4 Create a new Auto Scaling Group (green)

1. Go to EC2 → Auto Scaling Groups.
2. Click Create Auto Scaling group.

Configure:

• Name
  • Use your naming convention, e.g.:
    production-api-asg-v2
    
• Launch template
  • Select your existing Launch Template and explicitly choose Version N+1 (the one with the new instance type).
• VPC & Subnets
  • Use the same VPC and subnets as the current (blue) ASG.
• Attach to load balancer
  • Attach the new ASG to the green Target Group you created in Step 1.1.
  • Make sure it’s not accidentally pointing to blue’s Target Group.
• Scaling settings
  • Example for prod:
    Desired capacity: 2
    Minimum capacity: 1
    Maximum capacity: 10
    
  • Align with your expected load and existing scaling policies.
• Health checks
  • Enable ELB / Target Group health checks.
  • Set Health check grace period realistically (e.g., 60–120s) to allow app startup.
• (Optional) Instance warm-up
  • Set a value close to your real cold-start time (e.g., app launch + cache warm).
• (Optional) Mixed instances / Spot
  • Only use mixed instances or Spot if you understand interruption behavior and scaling policies.

Create the ASG and wait for instances to launch and register as healthy in the green Target Group.

​

1.5 Validate the green environment

Use the green ALB’s DNS name directly (e.g., internal-xyz-green-123456.elb.amazonaws.com) to test. Validate:

• Application behavior
  • Run smoke tests and key user flows.
• Target Group health
  • All expected instances show as healthy.
• Metrics
  • HTTP 5xx rate.
  • Latency and throughput.
  • CPU/memory (CloudWatch).
• Network & security
  • TLS certificates and ciphers (if HTTPS).
  • Redirects (HTTP → HTTPS, domain redirects).
  • WAF rules (if present).
  • Access logs, if configured.

Only proceed once the green environment is stable and looks production-ready.

---

​

Step 2 · DNS preparations

You’ll cut over by changing DNS to point to the green ALB.

1. In Route 53 (or your DNS provider):
   • Find the public record, for example api.example.com.
   • Lower the TTL to 60–300 seconds.
   • Do this at least 15–30 minutes before the cutover so cached entries expire quickly.
2. If you front the ALB with CloudFront or another CDN:
   • Plan to update the Origin or CNAME there as well.
   • Allow for CDN cache and DNS TTLs in your timing.

---

​

Step 3 · DNS cutover to green

Once validation is complete and TTLs are lowered:

1. Update the DNS CNAME for your public hostname (e.g., api.example.com) to point to the green ALB’s DNS name.
2. Wait a few TTLs for propagation.
3. Confirm traffic is hitting green:
   • Check green Target Group request counts.
   • Compare logs and metrics against blue’s previous baseline.

Rollback is simply:

• Change the CNAME back to the blue ALB.
• Wait for TTL to expire.
• Confirm traffic is back on blue.

Keep the blue environment running for a bake period so you can easily revert if needed.

---

​

Step 4 · Remove the blue environment

After the bake period:

1. Set the blue ASG’s Desired capacity and Minimum capacity to 0.
2. Delete the blue ASG, its load balancer, and its Target Group.

Until you remove the blue environment, you pay for both environments, and the MilkStraw AI task for the old group stays open.

---

​

Option 2 · Instance Refresh deployment (in-place ASG rollout)

If you don’t want to create a second ASG and LB, you can use Instance Refresh to roll the existing ASG to a new instance type by updating the Launch Template version. This is often suitable for:

• Worker fleets.
• Internal services.
• Apps where a controlled, in-place rollout is acceptable.

​

Step 1 · Prepare a new Launch Template version

Just like in Option 1:

1. Go to EC2 → Launch Templates.
2. Find the template used by your existing ASG.
3. Create new version:
   • Set Instance type to the new value (e.g., m6a.xlarge).
   • Adjust root volume size and user data if needed.
4. Save as Version N+1.

Update your ASG to use Launch Template Version N+1 as its default (in the ASG settings). If your ASG uses a mixed instances policy or a launch configuration, see the note in Option 1, step 1.3.

​

Step 2 · Start Instance Refresh

1. In Auto Scaling Groups, select the ASG.
2. Choose Instance refresh → Start instance refresh.

Configure:

• Min healthy percentage
  • Example: 90–100% for a cautious rollout.
  • This means the ASG will ensure 90–100% of the desired capacity stays healthy during the refresh.
  • Lower only if your app can handle reduced capacity during rotation.
• Warm-up time
  • Use your app’s realistic startup time + load balancer health check grace period.
  • Example: 120 seconds or more for heavier apps.
• (Optional) Skip matching
  • Turn this on to replace only the instances that don’t match Version N+1. Instances that already match are skipped.
  • Leave it off to replace all instances, even those that already match the new template.

Start the refresh.

​

Step 3 · Monitor and validate

While Instance Refresh runs:

• Monitor:
  • ASG health status.
  • Load balancer Target Group health.
  • Application errors and latency.
  • Capacity and scaling alarms.

If issues appear:

• You can Cancel instance refresh.
• Any instances already replaced remain, but the ASG stops further replacements.
• If needed, revert the ASG back to the previous Launch Template version and plan a new rollout.

Once the refresh completes:

• Confirm all instances are running the new instance type.
• Run smoke tests and verify that error rates and performance look good.

---

​

Extra resources

• Auto Scaling Instance Refresh — AWS Instance Refresh documentation
• Launch Templates — AWS Launch Template documentation
• Blue/Green deployments on AWS — AWS Blue/Green deployment whitepaper
• Target Groups for ALB/NLB — Elastic Load Balancing Target Groups