AWS OpsWorks

• AWS OpsWorks was a configuration management service that helped configure and operate applications in a cloud enterprise by using Chef or Puppet
• OpsWorks offered three variants: OpsWorks Stacks, OpsWorks for Chef Automate, and OpsWorks for Puppet Enterprise
• All OpsWorks services reached End of Life in 2024 and have been replaced by AWS Systems Manager Application Manager

OpsWorks Variants (Historical)

• OpsWorks Stacks — Used Chef cookbooks for configuration management with a simplified layer-based architecture (EOL May 26, 2024)
• OpsWorks for Chef Automate — Fully managed Chef Automate server for running Chef cookbooks and compliance automation (EOL May 5, 2024)
• OpsWorks for Puppet Enterprise — Fully managed Puppet Enterprise server for Puppet-based configuration management (EOL March 31, 2024)

Migration to AWS Systems Manager

• AWS recommends migrating OpsWorks workloads to AWS Systems Manager Application Manager
• Systems Manager provides equivalent or superior functionality for all OpsWorks Stacks features:

• AWS provided a migration script to automatically generate CloudFormation templates from existing OpsWorks stacks
• Refer to Migrate your AWS OpsWorks Stacks to AWS Systems Manager for detailed migration guidance

OpsWorks Stacks (Historical Reference)

• OpsWorks Stacks provided a simple and flexible way to create and manage stacks, groups of AWS resources like load balancers, web, application and database servers, and application deployed on them
• OpsWorks Stacks helped deploy and monitor applications in the stacks.
• Unlike OpsWorks for Chef Automate, OpsWorks Stacks did not require or create Chef servers; and performed some of the work of a Chef server itself
• OpsWorks Stacks monitored instance health, and provisioned new instances, when necessary, by using Auto Healing and Auto Scaling
• OpsWorks Stacks integrated with IAM to control how users can interact with stacks, what stacks can do on the users behalf, what AWS resources an app can access etc
• OpsWorks Stacks integrated with CloudWatch and CloudTrail to enable monitoring and logging
• OpsWorks Stacks could be accessed globally and used to create and manage instances globally

Stacks

• Stack was the core AWS OpsWorks Stacks component.
• Stack was a container for AWS resources like EC2, RDS instances etc that had a common purpose and should be logically managed together
• Stack helped manage the resources as a group and also defined some default configuration settings, such as the instances’ OS and AWS region
• Stacks could also be run in VPC to be isolated from direct user interaction
• Separate Stacks could be created for different environments like Dev, QA etc

Layers

• Stacks helped manage cloud resources in specialized groups called layers.
• A layer represented a set of EC2 instances that served a particular purpose, such as serving applications or hosting a database server.
• Layers depended on Chef recipes to handle tasks such as installing packages on instances, deploying apps, and running scripts
• Custom recipes and related files were packaged in one or more cookbooks and stored in a cookbook repository such S3 or Git

Recipes and LifeCycle Events

• Layers depended on Chef recipes to handle tasks such as installing packages on instances, deploying apps, running scripts, and so on.
• OpsWorks Stacks ran the recipes for each layer, even if the instance belonged to multiple layers for e.g. instance hosting both the application and the mysql server
• AWS OpsWorks Stacks featured a set of lifecycle events – Setup, Configure, Deploy, Undeploy, and Shutdown – which automatically ran specified set of recipes at the appropriate time on each instance
  • Setup
    • Once a new instance had booted, OpsWorks triggered the Setup event, which ran recipes to set up the instance according to the layer configuration for e.g. installation of apache, PHP packages
    • Once setup was complete, AWS OpsWorks triggered a Deploy event, which ran recipes to deploy the application to the new instance.
  • Configure
    • Whenever an instance entered or left the online state, AWS OpsWorks triggered a Configure event on all instances in the stack.
    • Event ran each layer’s configure recipes to update configuration to reflect the current set of online instances for e.g. the HAProxy layer’s Configure recipes can modify the load balancer configuration to reflect any added or removed application server instances.
  • Deploy
    • OpsWorks triggered a Deploy event when the Deploy command was executed, to deploy the application to a set of application servers.
    • Event ran recipes on the application servers to deploy application and any related files from its repository to the layer’s instances.
  • Undeploy
    • OpsWorks triggered an Undeploy event when an app was deleted or Undeploy command was executed to remove an app from a set of application servers.
    • Event ran recipes to remove all application versions and perform any additional cleanup tasks.
  • Shutdown
    • OpsWorks triggered a Shutdown event when an instance was being shut down, but before the underlying EC2 instance was actually terminated.
    • Event ran recipes to perform cleanup tasks such as shutting down services.
    • OpsWorks allowed Shutdown recipes a configurable amount of time to perform their tasks, and then terminated the instance.

Instance

• An instance represented a single computing resource for e.g. EC2 instance and defined the resource’s basic configuration, such as OS and size
• OpsWorks Stacks created instances and added them to a layer.
• When the instance was started, OpsWorks Stacks launched an EC2 instance using the configuration settings specified by the instance and its layer.
• After the EC2 instance finished booting, OpsWorks Stacks installed an agent that handled communication between the instance and the service and ran the appropriate recipes in response to lifecycle events
• OpsWorks Stacks supported instance auto-healing, whereby if an agent stopped communicating with the service, OpsWorks Stacks automatically stopped and restarted the instance
• OpsWorks Stacks supported the following instance types
  • 24/7 instances – launched and stopped manually
  • Time based instances – run on scheduled time
  • Load based instances – automatically started and stopped based on configurable load metrics
• Linux based computing resources created outside of the OpsWorks stacks for e.g. console or CLI could be added, incorporated and controlled through OpsWorks

Apps

• An AWS OpsWorks Stacks app represented code to run on an application server residing in the app repository like S3
• App contained the information required to deploy the code to the appropriate application server instances.
• When an app was deployed, AWS OpsWorks Stacks triggered a Deploy event, which ran the Deploy recipes on the stack’s instances.
• OpsWorks supported the ability to deploy multiple apps per stack and per layer

OpsWorks Deployment Strategies

Refer to OpsWorks Deployment Strategies blog post for details

AWS Certification Exam Practice Questions

• 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.
• NOTE: AWS OpsWorks reached End of Life in 2024. These questions are maintained for historical reference. Current AWS exams may still reference OpsWorks concepts in the context of migration scenarios.

1. You are working with a customer who is using Chef configuration management in their data center. Which service is designed to let the customer leverage existing Chef recipes in AWS?
   1. Amazon Simple Workflow Service
   2. AWS Elastic Beanstalk
   3. AWS CloudFormation
   4. AWS OpsWorks (NOTE: OpsWorks reached EOL in 2024. The current alternative is AWS Systems Manager with the AWS-ApplyChefRecipes Run Command document.)
2. Your mission is to create a lights-out datacenter environment, and you plan to use AWS OpsWorks to accomplish this. First you created a stack and added an App Server layer with an instance running in it. Next you added an application to the instance, and now you need to deploy a MySQL RDS database instance. Which of the following answers accurately describe how to add a backend database server to an OpsWorks stack? Choose 3 answers
   1. Add a new database layer and then add recipes to the deploy actions of the database and App Server layers. (Refer link)
   2. Use OpsWorks’ “Clone Stack” feature to create a second RDS stack in another Availability Zone for redundancy in the event of a failure in the Primary AZ. To switch to the secondary RDS instance, set the [:database] attributes to values that are appropriate for your server which you can do by using custom JSON.
   3. The variables that characterize the RDS database connection—host, user, and so on—are set using the corresponding values from the deploy JSON’s [:deploy][:app_name][:database] attributes. (Refer link)
   4. Cookbook attributes are stored in a repository, so OpsWorks requires that the “password”: “your_password” attribute for the RDS instance must be encrypted using at least a 256-bit key.
   5. Set up the connection between the app server and the RDS layer by using a custom recipe. The recipe configures the app server as required, typically by creating a configuration file. The recipe gets the connection data such as the host and database name from a set of attributes in the stack configuration and deployment JSON that AWS OpsWorks installs on every instance. (Refer link)
3. You are tasked with the migration of a highly trafficked node.js application to AWS. In order to comply with organizational standards Chef recipes must be used to configure the application servers that host this application and to support application lifecycle events. Which deployment option meets these requirements while minimizing administrative burden?
   1. Create a new stack within Opsworks add the appropriate layers to the stack and deploy the application (NOTE: With OpsWorks EOL, the current equivalent would be using AWS Systems Manager Application Manager with Chef recipes via Run Command.)
   2. Create a new application within Elastic Beanstalk and deploy this application to a new environment (need to comply with chef recipes)
   3. Launch a Node JS server from a community AMI and manually deploy the application to the launched EC2 instance
   4. Launch and configure Chef Server on an EC2 instance and leverage the AWS CLI to launch application servers and configure those instances using Chef.
4. A web-startup runs its very successful social news application on Amazon EC2 with an Elastic Load Balancer, an Auto-Scaling group of Java/Tomcat application-servers, and DynamoDB as data store. The main web application best runs on m2.xlarge instances since it is highly memory- bound. Each new deployment requires semi-automated creation and testing of a new AMI for the application servers which takes quite a while and is therefore only done once per week. Recently, a new chat feature has been implemented in node.js and waits to be integrated in the architecture. First tests show that the new component is CPU bound Because the company has some experience with using Chef, they decided to streamline the deployment process and use AWS OpsWorks as an application life cycle tool to simplify management of the application and reduce the deployment cycles. What configuration in AWS OpsWorks is necessary to integrate the new chat module in the most cost-efficient and flexible way?
   1. Create one AWS Ops Works stack, create one AWS Ops Works layer, create one custom recipe
   2. Create one AWS Ops Works stack, create two AWS Ops Works layers create one custom recipe (Single environment stack, two layers for java and node.js application using built-in recipes and custom recipe for DynamoDB connectivity only as other configuration. Refer link)
   3. Create two AWS Ops Works stacks, create two AWS Ops Works layers create one custom recipe
   4. Create two AWS Ops Works stacks, create two AWS Ops Works layers create two custom recipe
5. 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.
   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.
   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. (Will lead to 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.
6. When thinking of AWS OpsWorks, which of the following is not an instance type you can allocate in a stack layer?
   1. 24/7 instances (24/7 instances are supported and started manually and run until you stop them)
   2. Spot instances (OpsWorks did not support spot instances directly but they could be used with auto scaling)
   3. Time-based instances (Time-based instances are run by AWS OpsWorks on a specified daily and weekly schedule)
   4. Load-based instances (Load-based instances are automatically started and stopped by AWS OpsWorks, based on specified load metrics, such as CPU utilization)
7. Which of the following tools does not directly support AWS OpsWorks, for monitoring your stacks?
   1. AWS Config (Refer link)
   2. Amazon CloudWatch Metrics (AWS OpsWorks used CloudWatch to provide thirteen custom metrics with detailed monitoring for each instance in the stack)
   3. AWS CloudTrail (AWS OpsWorks integrated with CloudTrail to log every AWS OpsWorks API call and store the data in an S3 bucket)
   4. Amazon CloudWatch Logs (Amazon CloudWatch Logs could be used to monitor stack’s system, application, and custom logs.)
8. When thinking of AWS OpsWorks, which of the following is true?
   1. Stacks have many layers, layers have many instances.
   2. Instances have many stacks, stacks have many layers.
   3. Layers have many stacks, stacks have many instances.
   4. Layers have many instances, instances have many stacks.

References

• AWS OpsWorks User Guide (Archived)
• Migrate your AWS OpsWorks Stacks to AWS Systems Manager
• Seamlessly off-board from AWS OpsWorks Stacks by detaching resources
• AWS Systems Manager Application Manager