Upgrade EC2 instance types for AWS Elastic Beanstalk

This guide walks you through upgrading EC2 instance types for existing 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.

---

​

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

  Ask AI

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

    Ask AI

    m6a.xlarge
    
  • If you’re using MilkStraw, put the MilkStraw-recommended instance type here.
• Scaling
  • For load-balanced environments, something like:
    Copy

    Ask AI

    Desired capacity: 2
    Min:              1
    Max:              10
    
  • For single-instance environments:
    Copy

    Ask AI

    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.

​

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
• Blue/Green deployments with Elastic Beanstalk — AWS Blue/Green deployment guide
• Configuring Auto Scaling for Elastic Beanstalk — Auto Scaling configuration