> ## 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 AWS Elastic Beanstalk

> Step-by-step guide to upgrade EC2 instance types for existing AWS Elastic Beanstalk environments using Blue/Green or Rolling deployments.

This guide walks you through upgrading EC2 instance types for existing AWS Elastic Beanstalk (EB) environments, with two main paths:

* **Option 1 (recommended): Blue/Green deployment**

  Create a parallel environment with the new instance type, validate it, then swap traffic.

* **Option 2: Rolling / Immutable deployment**

  Change instance types in place using EB's deployment policies.

<Note>
  If you're coming from the MilkStraw AI recommender, you'll plug the recommended instance type(s) into the steps below.
</Note>

***

## Before you start

Make sure:

* You can log in to the AWS Console and have IAM permissions for:

  * **Elastic Beanstalk**, **EC2**, **Auto Scaling**, **Elastic Load Balancing**, **IAM**, and **Route 53** (if you manage DNS there).

* You know your current **Elastic Beanstalk platform**, for example:

  * Docker, Node.js, .NET, Python, Java, etc.

* You know whether your app requires **GPU instances**.

* Your current EB environment:

  * Is **healthy (green)**.

  * Can have the **same application version** deployed to a new environment (you still have the artifact and configuration).

***

## Option 1 · Blue/Green deployment (recommended)

Safest path: clone your existing environment with a new instance type (green), validate it, then swap traffic from the old one (blue). This gives:

* Zero or very low downtime.

* Instant, simple rollback by swapping traffic back.

### Step 1 · Create a parallel environment (Green)

1. Open the **Elastic Beanstalk console**.

2. Go to **Applications** → choose your app → **Environments**.

3. Select your current **production environment** (this is your **blue** env).

4. Click **Actions** → **Clone environment**.

#### 1.1 Basics

In the clone wizard:

* **Environment name**

  Use your own naming convention, for example:

  ```text theme={null}
  production-core-env-v2
  ```

* **Domain (CNAME)**

  * Let AWS auto-generate a CNAME (recommended; you'll swap later), **or**

  * Choose a distinct name like `prod-core-v2.myapp.elasticbeanstalk.com`.

* **Application version**

  * Select the **same version** currently running in the blue environment.

#### 1.2 Capacity & instances

In the capacity / instances settings:

* **Instance type**

  * Set to the **new instance type**, for example:

    ```text theme={null}
    m6a.xlarge
    ```

  * If you're using **MilkStraw**, put the **MilkStraw-recommended instance type** here.

* **Scaling**

  * For load-balanced environments, something like:

    ```text theme={null}
    Desired capacity: 2
    Min:              1
    Max:              10
    ```

  * For single-instance environments:

    ```text theme={null}
    Desired capacity: 1
    Min:              1
    Max:              1
    ```

* **Root volume size**

  * Increase if your app needs more disk (for logs, temp files, `emptyDir` usage from containers, etc.).

  * Typical values: **50–100 GiB** for most web apps.

* **(Optional) Spot instances**

  * Only enable Spot or mixed capacity if you're comfortable with interruption handling and understand how EB manages mixed instances.

* **(Optional) GPU**

  * Only choose GPU instance types if:

    * Your platform / AMI supports GPU, and

    * You have drivers installed (via `.ebextensions`, Docker image, or a custom AMI).

#### 1.3 Network

Use the same network setup as your current (blue) environment:

* **VPC and subnets**

  * Select the **same VPC**, subnets, and availability zones.

* **Security groups**

  * Use the same instance and load balancer security groups as the blue environment.

* **Load balancer**

  * Keep the same type (ALB/NLB/Classic) and listener ports as the current environment.

This keeps behavior consistent so you're only changing **instance type**, not overall topology.

#### 1.4 Software & environment variables

Mirror the configuration from your blue environment:

* Environment variables and secrets.

* Health check path / URL.

* Timeouts and connection draining / deregistration delay on the load balancer.

* Any platform-specific options (Node, .NET, Docker, etc.).

Then:

* **Create the environment** and wait for health to become **Green**.

While it's coming up, you can also monitor:

* Instance registration in the **target group** (if using ALB/NLB).

* Health checks on instances.

#### 1.5 Validate the new environment

Before switching traffic, validate that the green environment behaves like production:

* Open the **new environment URL** (its EB CNAME) and run **smoke tests**:

  * Basic page load.

  * Login / key user flows.

* Check **logs and metrics**:

  * HTTP 4xx/5xx.

  * Latency.

  * CPU/memory (CloudWatch).

* If you depend on external services:

  * Databases (RDS, Aurora, etc.)

  * Queues, caches, other APIs

  * Confirm connectivity and correct IAM roles.

Only move to the next step once the new environment looks healthy and stable.

***

### Step 2 · Shift traffic to the new environment

Goal: move users to the environment running the **new instance type** while keeping the old one for fast rollback.

#### 2.1 Lower DNS TTL (if using a custom domain)

If you use a custom domain like `app.example.com`:

* Typically it's a **CNAME** to the EB CNAME.

* In Route 53 (or your DNS provider), **lower the TTL** on that CNAME to something like **60–300 seconds**, ideally **15–30 minutes before** the swap.

This makes it faster for clients to pick up the new EB CNAME after the swap.

#### 2.2 Swap CNAMEs in Elastic Beanstalk

In the EB console:

1. Select the **new (green)** environment.

2. Go to **Actions** → **Swap environment URLs**.

3. Choose the **old (blue)** environment as the swap partner.

4. Confirm the swap.

EB will swap the CNAMEs so that:

* Your **custom DNS**, if pointing to EB, now resolves to the **green environment**.

* The old environment gets the "other" CNAME, but stays running, untouched.

**Rollback** is the same action in reverse: swap URLs again to send traffic back to blue.

#### 2.3 Post-swap checks

After the swap:

* Watch:

  * ALB/NLB **Target Group** healthy hosts.

  * HTTP 5xx rate and latency.

  * Application logs and error tracking.

* If you see:

  * Error spikes, high latency, or health turning yellow/red,

  * Swap back **immediately** and investigate:

    * Instance sizing (CPU, memory).

    * Network / security group differences.

    * Any configuration drift.

***

### Step 3 · Decommission or park the old environment

Don't delete the blue environment immediately. Instead:

1. Keep it around for a **bake period** (for example, 24–48 hours).

2. During that time, monitor:

   * Error rates.

   * Performance.

   * Any unusual behavior in the new environment.

Once you're confident:

You can either:

* **Terminate the old environment**

  * This removes its Auto Scaling Group, instances, and load balancer.

**or**

* **Scale to zero (for load-balanced envs)**

  * Set **Desired** and **Min** to `0`.

  * This stops instances but preserves configuration so you can scale it back up temporarily if needed.

Finally, clean up:

* Old application versions you no longer need.

* Unused target groups.

* Any custom launch templates, if you created them for the old environment.

***

## Option 2 · Rolling / Immutable deployment (in-place update)

This option keeps the same environment but instructs EB to roll out the new instance type in batches. It's often useful for:

* Worker environments.

* Internal services where short partial capacity reduction is acceptable.

* Teams that prefer fewer separate environments.

<Warning>
  This has more risk than Blue/Green because you're modifying the production environment directly, but Immutable deployments can still be quite safe.
</Warning>

### Step 1 · Change the instance type

In the EB console:

1. Go to **Environments** → select your environment.

2. Open the **Configuration** page.

3. Under **Instances**:

   * Set **Instance type** to the new instance type (for example, `m6a.xlarge`).

   * If using MilkStraw, paste in the **recommended instance type**.

### Step 2 · Configure deployment policy

Still in Configuration:

1. Go to **Rolling updates and deployments** (or similar, depending on your EB console version).

2. Choose one of:

   * **Immutable** (preferred where possible)

     * EB creates a **temporary Auto Scaling Group** with the new instance type.

     * New instances are registered with the load balancer.

     * Once healthy, EB cuts over and then retires the old instances.

     * If things go wrong, EB can roll back to the original ASG.

   * **Rolling with additional batch**

     * EB spins up a **new batch** of instances with the new type **before** terminating old ones.

     * Protects capacity during the update.

3. Set a **safe batch size**, for example **25–33%**:

   * This controls how much of your capacity is updated at once.

   * Make sure remaining capacity can handle your normal traffic.

Apply the changes.

### Step 3 · Monitor and validate

While EB is updating:

* Watch:

  * Environment health (should stay green).

  * Load balancer target health.

  * CPU/memory on new instances.

  * 5xx errors and latency.

If health degrades badly or errors spike:

* **Abort** the deployment in the EB console.

* EB will roll back to the previous Auto Scaling Group and instance type.

Once the deployment finishes:

* Run smoke tests.

* Validate key user paths, logs, and metrics.

***

## Extra resources

* **Elastic Beanstalk deployment policies** — [AWS Elastic Beanstalk deployment options](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html)

* **Blue/Green deployments with Elastic Beanstalk** — [AWS Blue/Green deployment guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)

* **Configuring Auto Scaling for Elastic Beanstalk** — [Auto Scaling configuration](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.as.html)