> ## Documentation Index
> Fetch the complete documentation index at: https://docs.milkstraw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Upgrade EC2 instance types for Amazon EC2 Auto Scaling groups

> Step-by-step guide to upgrade EC2 instance types for Amazon EC2 Auto Scaling groups using Blue/Green or Instance Refresh deployments.

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.

<Note>
  If a MilkStraw AI task sent you here, open it from your project on the **Overview** page and use the instance type it recommends in the Launch Template steps below. When you're done, set the task to **Solved** so MilkStraw AI can check the change.
</Note>

***

## 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:

    ```text theme={null}
    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**.

<Note>
  If your ASG uses a mixed instances policy, the instance types set on the ASG override the type in the Launch Template. Edit the instance types (or instance type requirements) on the ASG instead. If your ASG uses a launch configuration, copy it to a Launch Template first.
</Note>

#### 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.:

    ```text theme={null}
    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:

    ```text theme={null}
    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.

<Warning>
  This has more risk than Blue/Green because you're modifying the production environment directly, but Instance Refresh with high min-healthy-percentage can still be quite safe.
</Warning>

### 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html)

* **Launch Templates** — [AWS Launch Template documentation](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)

* **Blue/Green deployments on AWS** — [AWS Blue/Green deployment whitepaper](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)

* **Target Groups for ALB/NLB** — [Elastic Load Balancing Target Groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.