Rolling deployments are a deployment strategy used to update applications gradually across a fleet of servers or instances, minimizing downtime and reducing risk during updates. Instead of updating all instances simultaneously, rolling deployments update a subset of instances at a time while the re…Rolling deployments are a deployment strategy used to update applications gradually across a fleet of servers or instances, minimizing downtime and reducing risk during updates. Instead of updating all instances simultaneously, rolling deployments update a subset of instances at a time while the remaining instances continue serving traffic.
In AWS, rolling deployments are commonly implemented through services like Elastic Beanstalk, ECS, and Auto Scaling Groups. The process works by taking a batch of instances out of service, deploying the new version, performing health checks, and then moving to the next batch once the updated instances are healthy.
Key characteristics of rolling deployments include:
1. **Gradual Updates**: Updates are applied incrementally, typically as a percentage or fixed number of instances at a time.
2. **Maintained Capacity**: The deployment maintains a portion of healthy instances throughout the process, ensuring continuous availability.
3. **Health Monitoring**: Each batch undergoes health checks before proceeding to the next, allowing early detection of issues.
4. **Rollback Capability**: If problems occur, the deployment can be halted, and previously updated instances can be reverted.
5. **Configuration Options**: You can configure batch size, pause time between batches, and minimum healthy instances.
AWS Elastic Beanstalk offers rolling deployment policies where you specify the batch size and whether to maintain full capacity during deployment. Auto Scaling Groups support instance refresh functionality for rolling updates.
Considerations when using rolling deployments:
- During deployment, multiple application versions run concurrently
- Database schema changes require careful planning for backward compatibility
- Deployment duration increases with fleet size
- Session management needs attention as users may switch between versions
Rolling deployments provide a balanced approach between deployment speed and risk mitigation, making them suitable for production environments where zero-downtime updates are essential but blue-green deployment complexity is not warranted.
Rolling Deployments - AWS Solutions Architect Professional Guide
What are Rolling Deployments?
Rolling deployments are a deployment strategy where new versions of an application are gradually released to a subset of instances or servers at a time, while the remaining instances continue serving the current version. This process continues until all instances are updated to the new version.
Why are Rolling Deployments Important?
Rolling deployments are crucial for several reasons:
• Zero Downtime: Applications remain available throughout the deployment process • Risk Mitigation: Issues can be detected early before affecting all instances • Rollback Capability: Easy to stop and revert if problems are discovered • Resource Efficiency: Does not require double the infrastructure like blue-green deployments • Gradual Traffic Shift: Allows monitoring of new version performance incrementally
How Rolling Deployments Work in AWS
In Elastic Beanstalk: • Deploys new version in batches (configurable batch size) • Each batch is taken out of service during deployment • Reduced capacity during deployment based on batch size • Supports 'Rolling with Additional Batch' to maintain full capacity
In ECS: • Controlled by minimum healthy percent and maximum percent settings • Tasks are gradually replaced with new task definition versions • Load balancer drains connections before terminating old tasks
In CodeDeploy: • Uses deployment configurations like OneAtATime, HalfAtATime, or AllAtOnce • Supports custom deployment configurations for precise control • Works with EC2, Lambda, and ECS deployments
In Auto Scaling Groups: • Instance refresh feature enables rolling updates • Configurable minimum healthy percentage • Supports checkpoints and warmup periods
Key Configuration Parameters
• Batch Size: Number or percentage of instances updated simultaneously • Minimum Healthy Percent: Minimum capacity that must remain available • Maximum Percent: Maximum capacity allowed during deployment • Health Check Grace Period: Time to wait before checking instance health • Pause Time: Wait time between batches for monitoring
Rolling Deployments vs Other Strategies
Compared to Blue-Green: • Rolling uses less infrastructure but has longer deployment time • Blue-green offers instant rollback; rolling requires gradual rollback • Rolling may have version inconsistency during deployment
Compared to All-at-Once: • Rolling is safer but slower • All-at-once has potential downtime but is fastest
Exam Tips: Answering Questions on Rolling Deployments
1. Identify Capacity Requirements: If the question mentions maintaining capacity during deployment, consider 'Rolling with Additional Batch' in Elastic Beanstalk
2. Cost Considerations: Rolling deployments are more cost-effective than blue-green when infrastructure costs are a concern
3. Deployment Speed vs Safety: Smaller batch sizes mean slower but safer deployments; larger batches are faster but riskier
4. Health Check Importance: Questions about failed deployments often involve health check configurations
5. Version Consistency: If the application cannot handle multiple versions running simultaneously, rolling deployments may not be suitable - look for blue-green alternatives
6. ECS Specifics: Remember that minimum healthy percent of 100% with maximum of 200% maintains full capacity during rolling updates
7. Connection Draining: Always consider connection draining settings when questions involve stateful applications or long-running requests
8. Rollback Scenarios: Rolling deployments require another rolling deployment to rollback, unlike blue-green which offers instant rollback
9. Watch for Keywords: Terms like 'gradual', 'phased', 'incremental', or 'batch-based' typically indicate rolling deployments
10. Auto Scaling Integration: Instance refresh in Auto Scaling Groups is the native way to perform rolling updates for EC2 instances