Rolling deployments

Rolling Deployments - AWS SysOps Administrator Associate Guide

What are Rolling Deployments?

Rolling deployments are a deployment strategy where application updates are gradually released to a subset of instances at a time, rather than updating all instances simultaneously. This approach allows you to update your application with minimal downtime while maintaining service availability throughout the deployment process.

Why are Rolling Deployments Important?

Rolling deployments are crucial for several reasons:

• High Availability: Your application remains accessible during updates since only a portion of instances are being updated at any given time
• Risk Mitigation: If issues arise during deployment, only a subset of users are affected, and you can halt the rollout
• Controlled Updates: You maintain control over the pace of deployment and can monitor each batch before proceeding
• Resource Efficiency: No need to provision additional infrastructure (unlike blue/green deployments)
• Easy Rollback: Problems can be detected early, allowing for quicker rollback decisions

How Rolling Deployments Work in AWS

AWS Elastic Beanstalk Rolling Deployments:

1. You specify a batch size (percentage or fixed number of instances)
2. Elastic Beanstalk takes the first batch of instances out of service
3. The new application version is deployed to that batch
4. Health checks verify the instances are healthy
5. If successful, the process continues with the next batch
6. This repeats until all instances are updated

Key Configuration Options:

• Rolling: Deploy in batches, reducing capacity during deployment
• Rolling with Additional Batch: Launches a new batch first to maintain full capacity
• Batch Size: Number or percentage of instances to update at once

AWS CodeDeploy Rolling Deployments:

• Uses deployment configurations like OneAtATime, HalfAtATime, or custom configurations
• Integrates with Auto Scaling groups for seamless updates
• Supports automatic rollback on deployment failure

Rolling Deployment Trade-offs

• Longer Deployment Time: Takes more time than all-at-once deployments
• Reduced Capacity: Standard rolling deployments temporarily reduce capacity (unless using additional batch)
• Version Inconsistency: During deployment, different instances run different versions temporarily
• Sticky Sessions Consideration: Users may experience inconsistent behavior if sessions are tied to specific instances

Exam Tips: Answering Questions on Rolling Deployments

• When the question mentions maintaining availability during deployment with minimal cost, rolling deployments are often the correct answer

• If the scenario requires FULL capacity during deployment, look for Rolling with Additional Batch as the answer

• Compare with other deployment strategies:
- All-at-once = fastest but causes downtime
- Rolling = balanced approach, some capacity reduction
- Blue/Green = zero downtime but requires double resources
- Immutable = new instances, slower but safer

• Watch for keywords: 'gradual update', 'batch updates', 'minimize downtime', 'maintain partial capacity'

• Remember batch size impact: Smaller batches = safer but slower; larger batches = faster but riskier

• Health check questions: Rolling deployments rely heavily on health checks to determine if deployment should proceed to the next batch

• Rollback scenarios: Know that rolling deployments can be configured to automatically roll back if deployment fails or health checks fail

• Auto Scaling integration: Understand that rolling deployments work with Auto Scaling groups to manage instance updates

• Cost considerations: Rolling deployments are more cost-effective than blue/green since they do not require duplicate environments