> ## 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 you're coming from the MilkStraw AI recommender, you'll plug the recommended instance type(s) into the Launch Template steps below.
</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 you're using **MilkStraw**, plug in the **MilkStraw-recommended instance type**.

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

    ```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.

***

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

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

  * Enable this if you want **all instances replaced**, even those that already match the new template.

  * Leave it off if you only want to replace instances that don't match the new config.

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)