AWS OpsWorks

AWS OpsWorks Deployment Strategies (Historical Reference)

NOTE: This content is for historical reference. OpsWorks Stacks was deprecated in May 2024.

The deployment strategies described below are still relevant and applicable to modern AWS services like CodeDeploy, ECS, and App Runner.

All at Once Deployment

• OpsWorks Stacks did not automatically deploy updated code to online instances, and needed to be done manually
• Deploy command (for apps) or Update Custom Cookbooks command (for cookbooks) helped deploy the update to every instance concurrently
• Approach was simple and fast, but led to downtime in case of error
• OpsWorks allowed rollback to restore previously deployed app version
• By default, AWS OpsWorks Stacks stored the five most recent deployments, which allowed rolling back up to four versions

Modern Equivalent

• AWS CodeDeploy – Supports all-at-once deployment with automatic rollback capabilities
• ECS/EKS – Can perform rolling updates with configurable batch sizes

Rolling Deployment

• A rolling deployment updates an application on a stack’s online application server instances in multiple phases.
• With each phase, a subset of the online instances can be updated and verified to be successful before starting the next phase.
• In case of any issues, the instances running the old app version can continue to handle incoming traffic until the issues are resolved.
• Steps to perform Rolling deployment
  • Deploy the app on a single application server instance.
  • The instance can be deregistered from the load balancer, to prevent it from serving traffic
  • Verify the app is working fine
  • Deploy the update on the remainder of instances

Modern Equivalent

• AWS CodeDeploy – Supports rolling deployments with configurable batch sizes and health checks
• ECS – Rolling update strategy with minimum healthy percent and maximum percent parameters
• EKS – Rolling updates for Kubernetes deployments
• Elastic Beanstalk – Rolling deployment with configurable batch size

Blue Green Deployment

• Blue Green deployment can be achieved using separate environments for each phase of the application’s lifecycle.
• Different environments are sometimes referred to as stages like development, staging, production etc.
  • Blue environment is the production environment, which hosts the current application.
  • Green environment is the staging environment, which hosts the updated application.
• Development and testing can be performed on environments that are not publicly accessible, and when ready the traffic can be switched.
• Steps for Blue Green deployment with Route 53 and ELB load balancers
  • Attach unused ELB from the pool to the green environment’s application server layer
  • After all of the green environment’s instances have passed the ELB health check, the weights in Route 53 can be changed to route traffic gradually from Blue to Green environment.
  • Once the Green environment works fine and is ready to handle all traffic
  • Detach the load balancer from the old blue environment’s application server layer and return it to the pool
  • Blue environment can be retained for some time, so that if any issues arise the update can be rolled back by reversing the procedure to direct incoming traffic back to the old blue environment

Modern Equivalent

• AWS CodeDeploy – Native blue/green deployment support for EC2, Lambda, and ECS
• Elastic Beanstalk – Blue/green deployment using environment cloning and CNAME swap
• ECS – Blue/green deployment with CodeDeploy integration
• Route 53 – Weighted routing policies for gradual traffic shifting
• Application Load Balancer – Target group weighting for blue/green deployments

Modern AWS Deployment Services

AWS CodeDeploy

• Fully managed deployment service that automates software deployments
• Supports EC2, Lambda, ECS, and on-premises servers
• Deployment strategies: All-at-once, Rolling, Blue/Green, Canary
• Automatic rollback on deployment failure
• Integration with CI/CD pipelines via CodePipeline

AWS Systems Manager

• Unified interface for managing AWS resources
• Configuration management with State Manager
• Automation runbooks for common tasks
• Patch management and compliance reporting

Amazon ECS/EKS

• Container orchestration services
• Built-in rolling update strategies
• Blue/green deployments with CodeDeploy
• Service auto-scaling and load balancing

AWS App Runner

• Fully managed service for containerized web applications
• Automatic deployments from source code or container images
• Built-in load balancing and auto-scaling
• Zero-downtime deployments

AWS Certification Exam Practice Questions

⚠️ EXAM NOTE: AWS OpsWorks questions may still appear in older exam versions but are being phased out. Focus on CodeDeploy, Systems Manager, and container services for current exams.

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You company runs a complex customer relations management system that consists of around 10 different software components all backed by the same Amazon Relational Database (RDS) database. You adopted AWS OpsWorks to simplify management and deployment of that application and created an AWS OpsWorks stack with layers for each of the individual components. An internal security policy requires that all instances should run on the latest Amazon Linux AMI and that instances must be replaced within one month after the latest Amazon Linux AMI has been released. AMI replacements should be done without incurring application downtime or capacity problems. You decide to write a script to be run as soon as a new Amazon Linux AMI is released. Which solutions support the security policy and meet your requirements? Choose 2 answers
   1. Assign a custom recipe to each layer, which replaces the underlying AMI. Use AWS OpsWorks life-cycle events to incrementally execute this custom recipe and update the instances with the new AMI. (AMI cannot be updated using recipes)
   2. Create a new stack and layers with identical configuration, add instances with the latest Amazon Linux AMI specified as a custom AMI to the new layer, switch DNS to the new stack, and tear down the old stack. (Blue-Green Deployment)
   3. Identify all Amazon Elastic Compute Cloud (EC2) instances of your AWS OpsWorks stack, stop each instance, replace the AMI ID property with the ID of the latest Amazon Linux AMI ID, and restart the instance. To avoid downtime, make sure not more than one instance is stopped at the same time. (Instances cannot be updated by updating the AMI id and needs to be launched anew)
   4. Specify the latest Amazon Linux AMI as a custom AMI at the stack level, terminate instances of the stack and let AWS OpsWorks launch new instances with the new AMI. (Would result in downtime)
   5. Add new instances with the latest Amazon Linux AMI specified as a custom AMI to all AWS OpsWorks layers of your stack, and terminate the old ones. (Disposable Rolling deployment)
2. A company has developed a Ruby on Rails content management platform. Currently, OpsWorks with several stacks for dev, staging, and production is being used to deploy and manage the application. Now the company wants to start using Python instead of Ruby. How should the company manage the new deployment?
   1. Update the existing stack with Python application code and deploy the application using the deploy life-cycle action to implement the application code.
   2. Create a new stack that contains a new layer with the Python code. To cut over to the new stack the company should consider using Blue/Green deployment
   3. Create a new stack that contains the Python application code and manage separate deployments of the application via the secondary stack using the deploy lifecycle action to implement the application code.
   4. Create a new stack that contains the Python application code and manages separate deployments of the application via the secondary stack

References

• AWS OpsWorks Stacks (Deprecated)
• AWS CodeDeploy User Guide
• AWS Systems Manager User Guide
• Amazon ECS Deployment Types