A rolling deployment strategy is a deployment approach used in AWS that gradually replaces instances of the previous version of an application with instances of the new version. This method ensures minimal downtime and maintains application availability throughout the deployment process.
In AWS El…A rolling deployment strategy is a deployment approach used in AWS that gradually replaces instances of the previous version of an application with instances of the new version. This method ensures minimal downtime and maintains application availability throughout the deployment process.
In AWS Elastic Beanstalk, rolling deployments work by deploying the new version in batches. Instead of updating all instances simultaneously, the platform updates a subset of instances at a time while keeping the remaining instances running the old version to handle incoming traffic.
Key characteristics of rolling deployments include:
1. **Batch Processing**: Instances are updated in configurable batch sizes. You can specify either a fixed number or a percentage of instances to update at once.
2. **Health Checks**: Before moving to the next batch, AWS verifies that the newly deployed instances pass health checks. If instances fail health checks, the deployment can be rolled back.
3. **Reduced Capacity**: During deployment, your environment operates at reduced capacity since some instances are being updated and are temporarily unavailable.
4. **Cost Effective**: Unlike immutable deployments, rolling deployments do not require provisioning additional instances, making them more cost-efficient.
5. **Longer Deployment Time**: Since updates happen in batches, the overall deployment takes longer compared to all-at-once deployments.
Configuration options in Elastic Beanstalk allow you to set batch size and pause time between batches. A variation called "Rolling with Additional Batch" launches new instances before taking old ones out of service, maintaining full capacity throughout the process.
Rolling deployments are ideal for production environments where you need to balance deployment speed with availability requirements. They provide a safer alternative to all-at-once deployments while being simpler to implement than blue-green deployments. However, during the deployment window, multiple versions of your application run concurrently, which requires consideration for backward compatibility.
Rolling Deployment Strategy - AWS Developer Associate Guide
What is a Rolling Deployment Strategy?
A rolling deployment is a deployment strategy where application updates are gradually rolled out to a subset of instances at a time, rather than updating all instances simultaneously. This approach ensures that the application remains available throughout the deployment process by keeping some instances running the old version while others are being updated.
Why is Rolling Deployment Important?
Rolling deployments are crucial for several reasons:
• Zero Downtime: Your application remains available during the entire deployment process • Reduced Risk: If issues occur, only a portion of your infrastructure is affected • Gradual Validation: You can monitor the health of updated instances before proceeding • Resource Efficiency: No need to provision additional infrastructure (unlike blue/green deployments) • Rollback Capability: Easier to stop and reverse if problems are detected
How Rolling Deployment Works
Step 1: The deployment process begins by taking a batch of instances out of service Step 2: The new application version is deployed to these instances Step 3: Health checks verify the updated instances are functioning correctly Step 4: Updated instances are brought back into service Step 5: The process repeats for the next batch until all instances are updated
Rolling Deployment in AWS Services
Elastic Beanstalk Rolling Deployments: • Rolling: Deploys to batches, reducing capacity during deployment • Rolling with additional batch: Launches a new batch first to maintain full capacity • Batch size can be configured as a fixed number or percentage
ECS Rolling Updates: • Controlled by minimumHealthyPercent and maximumPercent parameters • Service scheduler replaces tasks gradually
CodeDeploy Rolling Deployments: • Uses deployment configurations like OneAtATime, HalfAtATime, or custom configurations • Supports EC2, on-premises, and Lambda deployments
Key Configuration Parameters
• Batch Size: Number or percentage of instances updated at once • Pause Time: Wait period between batches for health validation • Health Check Grace Period: Time allowed for instances to pass health checks • Minimum Healthy Instances: Ensures capacity is maintained during deployment
Advantages vs Disadvantages
Advantages: • No additional infrastructure costs • Continuous availability • Controlled, predictable deployment process
Disadvantages: • Deployment takes longer than all-at-once • Brief period where multiple versions run simultaneously • Rollback requires re-deployment
Exam Tips: Answering Questions on Rolling Deployment Strategy
1. Identify the scenario: When questions mention maintaining availability during deployment with minimal additional resources, think rolling deployment
2. Know the variants: Understand the difference between Rolling (reduced capacity) and Rolling with additional batch (full capacity maintained)
3. Batch size implications: Smaller batch sizes mean slower but safer deployments; larger batch sizes are faster but riskier
4. Compare with other strategies: • Blue/Green = two environments, instant switch, higher cost • All-at-once = fastest but causes downtime • Immutable = new instances created, replaces old ones • Rolling = gradual update of existing instances
5. Watch for capacity keywords: If the question emphasizes maintaining full capacity, the answer is likely Rolling with additional batch
6. Health checks matter: Rolling deployments rely heavily on health checks to determine when to proceed with the next batch
7. Version coexistence: Remember that during rolling deployments, both old and new versions temporarily serve traffic together
8. Cost considerations: Rolling deployment is more cost-effective than blue/green because it does not require duplicate infrastructure