Using AWS CodeDeploy for Rolling Updates

In modern DevOps practices, delivering new features quickly is essential but so is maintaining availability and minimizing risk. One of the most effective ways to update applications safely on AWS CodeDeploy is via rolling updates. Rather than swapping the entire environment at once (like blue/green), a rolling update gradually replaces instances with the new version so your application stays online during the process.

In this blog, we’ll dive deep into how CodeDeploy supports rolling updates, how to set them up, how they differ from other strategies, best practices, pitfalls, real-life examples, and wrap up with an FAQ. This isn’t just theory we’ll talk in human terms so your DevOps team can adopt it practically.

1. What is a Rolling Update?

A rolling update is a deployment strategy where you incrementally replace old versions of your application with new versions across your fleet of instances (or services).
Rather than taking all servers offline or switching traffic to a completely new environment (as in blue/green), you update a subset of hosts at a time.

Why choose a rolling update?

• Minimal new infrastructure: You don’t necessarily need to create a whole new environment; you update existing ones gradually.

• Reduced downtime: Because only part of the fleet is being updated at any time, the overall system stays available.

• Controlled risk: If something goes wrong, you can halt and roll back just the subset you updated instead of the full environment.

AWS describes rolling deployments as one of the deployment options for updating applications while replacing the infrastructure in small increments. ()

2. How AWS CodeDeploy Supports Rolling Updates

AWS CodeDeploy is an AWS managed service designed to automate application deployments across EC2 instances (or on-premises), Lambda, ECS and more. () For EC2/On-Premises, it supports both in-place and blue/green deployments. A rolling update can be implemented within an in-place deployment by specifying how many instances can be updated at once.

Key Features Relevant to Rolling Updates:

• You can specify deployment configurations that control how many hosts get updated at once (e.g., “one at a time” or “10% at a time”). ()

• CodeDeploy monitors the health of each instance during update and can stop the deployment if too many failures occur. ()

• Integration with Auto Scaling groups means new instances can automatically receive the latest revision. ()

• Rollbacks: If a problematic revision is deployed, CodeDeploy supports automatic or manual rollback to a previous version. ()

How Rolling Updates Work in CodeDeploy (EC2/On-Premises)

1. You define an application and deployment group in CodeDeploy.

2. The deployment group targets an EC2 fleet (instances tagged or in an ASG).

3. You specify a deployment configuration (e.g., CodeDeployDefault.OneAtATime, CodeDeployDefault.HalfAtATime, or custom).

4. When you trigger a deployment revision, CodeDeploy updates a batch of instances (as per config), proceeds to the next batch when the previous batch succeed.

5. At each stage, if health checks fail or alarms trigger, CodeDeploy can stop or rollback.

6. When complete, all instances run the new revision.

3. Rolling Update vs In-Place vs Blue/Green

To choose the right strategy, it’s helpful to compare.

In-Place

• The old version is replaced on each instance in place (stop app, install new version, start). ()

• Infrastructure stays the same.

• Faster, simpler, but greater risk: if something fails, user traffic may be impacted.

Rolling Update (via CodeDeploy)

• Essentially an in-place update but staged in batches.

• Keeps service available by only updating a subset.

• Moderate risk, moderate infrastructure requirement.

Blue/Green

• A parallel environment (Green) is created, the app is installed, validated, and traffic is switched. Then the old environment (Blue) is retired. ()

• Highest availability and lowest risk, but requires more infrastructure or cost.

When to use each?

• Use Rolling Updates when your fleet size is manageable and you want to minimize infrastructure cost but maintain availability.

• Use Blue/Green for mission-critical services where risk is unacceptable and you can afford duplication.

• Use In-Place for simpler apps or non-production environments where downtime is tolerable.

4. Setting Up a Rolling Update in AWS CodeDeploy: Step by Step

Here’s a walkthrough of how you might set up a rolling update for an application running on EC2/Auto Scaling groups.

Step 1: Prepare your Build and Revision

• Package your application (war/zip) or container image.

• Upload it to S3 or GitHub (CodeDeploy supports multiple sources). ()

• Create an AppSpec file (appspec.yml or JSON) that defines hooks and lifecycle events (BeforeInstall, Install, AfterInstall, ValidateService). ()

Step 2: Create Application & Deployment Group

• In CodeDeploy console, create an Application (Compute platform: EC2/On-Premises).

• Create a Deployment Group targeting the instances (via tags or ASG).

• Configure a Deployment Configuration - e.g., OneAtATime, HalfAtATime, or define a custom one (e.g., 10% of instances at a time).

• Configure Load Balancer (if applicable) to deregister instances while deploying.

• Configure Rollback settings: automatic rollback on failure or alarms.

Step 3: Trigger the Deployment

• Create a new deployment revision (select your revision in S3 or GitHub).

• Choose “In-place” deployment type (this allows rolling update behaviour).

• Start deployment. CodeDeploy will update the first batch of instances, wait for them to pass health checks, then proceed to the next batch.

Step 4: Monitor the Deployment

• Watch the deployment status in the console or via CLI (aws codedeploy get-deployment).

• Monitor CloudWatch alarms or custom application health metrics.

• If a batch fails, CodeDeploy stops or triggers rollback based on your config.

Step 5: Verify & Clean Up

• Once deployment completes across all instances, verify application behaviour.

• Update documentation, metrics, dashboards.

• Confirm no old version remains; if rollback occurred, investigate root cause.

Step 6: Automate via CI/CD

• Integrate the deployment in your pipeline (for example, via AWS CodePipeline).

• Every time there’s a build, a deployment revision triggers CodeDeploy, ensuring rolling update behaviour is part of your delivery process.

5. Best Practices for Rolling Updates with CodeDeploy

Here are some practical tips to make your rolling updates safer, smoother, and more predictable.

5.1 Define Appropriate Batch Size

• Too large a batch = approaching full downtime risk.

• Too small a batch = slow rollout, longer deployment window.
  Choose based on fleet size, complexity, SLAs.

5.2 Use Health Checks and Alarms

• Tie your deployment to meaningful health checks (application metrics, error rate) not just basic instance health.

• If alarms trigger, CodeDeploy should stop or roll back.

• Health automation avoids pushing bad changes further.

5.3 Gracefully Drain Instances

If you’re behind a load balancer, ensure each instance is deregistered before update and re-registered after. This avoids traffic hitting half-updated instances.
Use the AppSpec hooks or lifecycle hooks to manage drain gracefully (e.g., /healthz endpoint returning unavailable temporarily).

5.4 Use Immutable Infrastructure Principles where Possible

Even in rolling updates, consider rebuilding nodes (rather than editing in place) for consistency. Combine with ASG replacement for newer builds.

5.5 Coordinate With Auto Scaling

If your fleet uses Auto Scaling, understand how scale-out/scale-in during deployment interacts with CodeDeploy. AWS docs highlight possible race conditions when ASG events occur simultaneously. ()
Suspending scaling during a deployment might be advisable.

5.6 Test in Staging with the Same Configuration

Before pushing to production, run a rolling update in staging using the same batch size and configuration to practice rollback and monitor behaviour.

5.7 Keep Rollbacks Simple

Define automatic rollback criteria ahead of time (e.g., number of failed instances, threshold of error rate increase). CodeDeploy allows rollback to a previous revision. ()
Make sure rollback is tested.

5.8 Monitor Deployment Duration

Rolling updates take longer than ‘all-at-once’ rollouts. Track deployment time and optimize. Eliminate unnecessary hooks or long sleeps.

5.9 Versioning & Change Management

Ensure your revision history is maintained (build numbers, Git SHAs). If a rollback occurs, you’ll quickly know which version to redeploy.

5.10 Use Tags & Metadata

Tag instances by environment (prod/stage), service type and ensure consistency. Helps targeting and tracking.

6. Common Pitfalls and How to Avoid Them

Pitfall: No Real Health Checks

Simply checking for “instance up” isn’t enough. Bad deployment could pass instance health but fail business logic. Use logs, error rates, latency metrics.

Pitfall: ASG Scaling Interferes with Deployment

If Auto Scaling triggers new instances during a rolling update, some may receive old version. AWS documentation explains this scenario and recommends careful planning. ()
Solution: Temporarily suspend scaling or allow update to complete first.

Pitfall: Long Deployment Windows

Updating one instance at a time in a large farm can take hours. Balance batch size vs risk.

Pitfall: Mixing Rolling Update and Blue/Green Inconsistently

Sometimes teams mix strategies without clarity. Decide clearly which method you use in each environment.

Pitfall: Poor Rollback Strategy

If rollback isn’t tested or defined, a bad deployment can stay live too long. Use automatic rollback and ensure it works.

Pitfall: Console-Only Deployment

Avoid manual console deployments for production. Use infrastructure-as-code, pipelines, and version control for repeatability.

7. Real-World Example: Rolling Update for a Training Platform

Let’s say you, as the Digital Marketing Director overseeing a training portal built on AWS EC2 Auto Scaling groups, want to deploy a new version of your content ingestion service.

Setup

• Auto Scaling group “content-ingest-prod” with 10 EC2 instances behind an Application Load Balancer.

• CodeDeploy application “ContentIngestApp”, deployment group tied to the ASG.

• Deployment configuration set to HalfAtATime (i.e., 50% of instances updated at once).

• Health checks: ALB target health + custom CloudWatch error rate < 1%.

• Automatic rollback configured on 3 failed instances or error rate > 2%.

Rolling Update Execution

1. Upload new revision (version 2.1.0) to S3.

2. Trigger CodeDeploy deployment with config HalfAtATime.

3. CodeDeploy takes 5 of the 10 instances out of ALB, updates them, validates them, then re-registers them.

4. Next 5 are updated.

5. No downtime since 5 instances always serve traffic.

6. After update, error rate remains <1%. Deployment completes.

7. Monitor dashboard: latency stable, instance health good.

If Something Goes Wrong

Suppose the new version contains a bug that increases error rate to 3%.

• During second batch, CloudWatch alarm triggers.

• CodeDeploy stops the deployment and triggers automatic rollback to previous version.

• The rollback happens across the updated instances with minimal impact.

Outcome

• Smooth rollout with no user disruption.

• Controlled risk, clear rollback path.

• Deployment history tracked.

• You can repeat the process for subsequent updates.

8. When (and When Not) to Use Rolling Updates

Use Rolling Updates When:

• You have a large fleet where full replacement (blue/green) is cost-prohibitive.

• You want to minimize downtime but don’t require full isolation of new version.

• Your application supports backward compatibility during deployment.

• You are confident in monitoring and rollback processes.

Avoid Rolling Updates When:

• Your changes include major database schema changes or non-backward-compatible updates.

• You need full isolation between old and new versions (then blue/green is better).

• You want near-zero risk and can afford duplicate infrastructure.

• Your deployment time per instance is very long and batch size would make rollout too slow.

9. Measuring Success & KPIs for Rolling Updates

To evaluate how well your rolling update process is working, track metrics such as:

• Deployment success rate (percentage of deployments without rollback).

• Mean time to deploy (from trigger to completion).

• Mean time to rollback (if needed).

• Application error rate during rollout vs baseline.

• User-facing impact: latency changes, availability metrics.

• Resource utilisation: was batch size optimal?

Use these to refine your deployment configuration and process.

10. Summary

Rolling updates via AWS CodeDeploy offer a balanced approach between speed, efficiency, availability and risk. By updating instances progressively rather than all at once or via full swap, teams can keep services online while deploying changes safely.

Key takeaways:

• Define deployment group, batch size and health checks carefully.

• Monitor health and automate rollback.

• Integrate into CI/CD pipelines for consistency.

• Choose rolling updates when you want incremental deployment without full duplication.

• Follow best practices to avoid major pitfalls.

When done well, rolling updates become an essential part of a reliable, high-velocity DevOps workflow.

Frequently Asked Questions (FAQ)

Q1. Can CodeDeploy perform a true “rolling update” where instances are replaced gradually?
Yes. For EC2/On-Premises with the in-place deployment type, CodeDeploy supports incremental updates where only a fraction of instances are taken offline at a time. ()

Q2. How do I configure how many instances are updated at once?
You select a deployment configuration for your deployment group (e.g., OneAtATime, HalfAtATime or custom percentage). This controls the batch size for rolling updates.

Q3. What happens if one of the batches fails health checks?
If health checks fail (either instance error or custom CloudWatch alarms), CodeDeploy can stop the deployment or trigger an automatic rollback, depending on your rollout settings. ()

Q4. How does rolling update differ from blue/green in CodeDeploy?
Rolling update updates existing instances in batches (in-place). Blue/green deploys a new environment, validates it, then shifts traffic. Blue/green usually offers lower risk but higher cost.

Q5. Can rolling updates be applied to ECS or Lambda using CodeDeploy?
While CodeDeploy supports ECS and Lambda, ECS and Lambda deployments typically use blue/green or traffic shifting models rather than classic in-place rolling updates. ()

Q6. Should I disable auto scaling during a rolling update?
If your ASG may scale out/in during the deployment, it could interfere. AWS documentation suggests handling such scenarios carefully to avoid version mismatches. ()

Q7. Is there downtime risk with rolling updates?
Some risk remains (e.g., if batch size is too large or health checks are insufficient). But compared to “all-at-once” updates, downtime is much lower. Proper configuration reduces risk further.

Q8. How do I test rollback readiness?
In non-production, simulate failures (introduce a bug) and verify your rollback triggers correctly. Record time, monitor user impact, and refine your process.

Q9. How do I monitor the deployment’s progress?
Use the CodeDeploy console, AWS CLI (aws codedeploy get-deployment), CloudWatch metrics/alarms and you can integrate SNS for notifications.

Q10. What’s a good batch size for rolling updates?
It depends on fleet size, SLAs, deployment time per host. A common starting point is 10–20% of total hosts at a time, then refine based on results.