Last updated on February 16, 2024
AWS OpsWorks Cheat Sheet
- A configuration management service that helps you configure and operate applications in a cloud enterprise by using Puppet or Chef.
- AWS OpsWorks Stacks and AWS OpsWorks for Chef Automate (1 and 2) let you use Chef cookbooks and solutions for configuration management, while OpsWorks for Puppet Enterprise lets you configure a Puppet Enterprise master server in AWS.
- With AWS OpsWorks, you can automate how nodes are configured, deployed, and managed, whether they are Amazon EC2 instances or on-premises devices:
OpsWorks for Puppet Enterprise
- Provides a fully-managed Puppet master, a suite of automation tools that enable you to inspect, deliver, operate, and future-proof your applications, and access to a user interface that lets you view information about your nodes and Puppet activities.
- Does not support all regions.
- Uses puppet-agent software.
- Features
- AWS manages the Puppet master server running on an EC2 instance. You retain control over the underlying resources running your Puppet master.
- You can choose the weekly maintenance window during which OpsWorks for Puppet Enterprise will automatically install updates.
- Monitors the health of your Puppet master during update windows and automatically rolls back changes if issues are detected.
- You can configure automatic backups for your Puppet master and store them in an S3 bucket in your account.
- You can register new nodes to your Puppet master by inserting a user-data script, provided in the OpsWorks for Puppet Enterprise StarterKit, into your Auto Scaling groups.
- Puppet uses SSL and a certification approval process when communicating to ensure that the Puppet master responds only to requests made by trusted users.
- Deleting a server also deletes its events, logs, and any modules that were stored on the server. Supporting resources are also deleted, along with all automated backups.
- Pricing
- You are charged based on the number of nodes (servers running the Puppet agent) connected to your Puppet master and the time those nodes are running on an hourly rate, and you also pay for the underlying EC2 instance running your Puppet master.
OpsWorks for Chef Automate
- Lets you create AWS-managed Chef servers that include Chef Automate premium features, and use the Chef DK and other Chef tooling to manage them.
- AWS OpsWorks for Chef Automate supports Chef Automate 2.
- Uses chef-client.
- Features
- You can use Chef to manage both Amazon EC2 instances and on-premises servers running Linux or Windows.
- You receive the full Chef Automate platform which includes premium features that you can use with Chef server, like Chef Workflow, Chef Visibility, and Chef Compliance.
- You provision a managed Chef server running on an EC2 instance in your account. You retain control over the underlying resources running your Chef server and you can use Knife to SSH into your Chef server instance at any time.
- You can set a weekly maintenance window during which OpsWorks for Chef Automate will automatically install updates.
- You can configure automatic backups for your Chef server and is stored in an S3 bucket.
- You can register new nodes to your Chef server by inserting user-data code snippets provided by OpsWorks for Chef Automate into your Auto Scaling groups.
- Chef uses SSL to ensure that the Chef server responds only to requests made by trusted users. The Chef server and Chef client use bidirectional validation of identity when communicating with each other.
- Deleting a server also deletes its events, logs, and any cookbooks that were stored on the server. Supporting resources are deleted also, along with all automated backups.
- Pricing
- You are charged based on the number of nodes connected to your Chef server and the time those nodes are running, and you also pay for the underlying EC2 instance running your Chef server.
OpsWorks Stacks
- Provides a simple and flexible way to create and manage stacks and applications.
- Stacks are group of AWS resources that constitute an full-stack application. By default, you can create up to 40 Stacks, and each stack can hold up to 40 layers, 40 instances, and 40 apps.
- You can create stacks that help you manage cloud resources in specialized groups called layers. A layer represents a set of EC2 instances that serve a particular purpose, such as serving applications or hosting a database server. Layers depend on Chef recipes to handle tasks such as installing packages on instances, deploying apps, and running scripts.
- OpsWorks Stacks does NOT require or create Chef servers.
- Features
- You can deploy EC2 instances from template configurations, including EBS volume creation.
- You can configure the software on your instances on-demand or automatically based on lifecycle events, from bootstrapping the base OS image into a working server to modifying running services to reflect changes.
- OpsWorks Stacks can auto heal your stack. If an instance fails in your stack, OpsWorks Stacks can replace it with a new one.
- You can adapt the number of running instances to match your load, with time-based or load-based auto scaling.
- You can use OpsWorks Stacks to configure and manage both Linux and Windows EC2 instances.
- You can use AWS OpsWorks Stacks to deploy, manage, and scale your application on any Linux server such as EC2 instances or servers running in your own data center.
- Instance Types
- 24/7 instances are started manually and run until you stop them.
- Time-based instances are run by OpsWorks Stacks on a specified daily and weekly schedule. They allow your stack to automatically adjust the number of instances to accommodate predictable usage patterns.
- Load-based instances are automatically started and stopped by OpsWorks Stacks, based on specified load metrics, such as CPU utilization. They allow your stack to automatically adjust the number of instances to accommodate variations in incoming traffic.
- Load-based instances are available only for Linux-based stacks.
- Lifecycle Events
- You can run recipes manually, but OpsWorks Stacks also lets you automate the process by supporting a set of five lifecycle events:
- Setup occurs on a new instance after it successfully boots.
- Configure occurs on all of the stack’s instances when an instance enters or leaves the online state.
- Deploy occurs when you deploy an app.
- Undeploy occurs when you delete an app.
- Shutdown occurs when you stop an instance.
- You can run recipes manually, but OpsWorks Stacks also lets you automate the process by supporting a set of five lifecycle events:
- Monitoring
- OpsWorks Stacks sends all of your resource metrics to CloudWatch.
- Logs are available for each action performed on your instances.
- CloudTrail logs all API calls made to OpsWorks.
- Security
- Grant IAM users access to specific stacks, making management of multi-user environments easier.
- You can also set user-specific permissions for actions on each stack, allowing you to decide who can deploy new application versions or create new resources.
- Each EC2 instance has one or more associated security groups that govern the instance’s network traffic. A security group has one or more rules, each of which specifies a particular category of allowed traffic.
- Pricing
- You pay for AWS resources created using OpsWorks Stacks in the same manner as if you created them manually.
AWS OpsWorks-related Cheat Sheets:
Validate Your Knowledge
Question 1
A company manually runs its custom scripts when deploying a new version of its application that is hosted on a fleet of Amazon EC2 instances. This method is prone to human errors, such as accidentally running the wrong script or deploying the wrong artifact. The company wants to automate its deployment procedure.
If errors are encountered after the deployment, the company wants to be able to roll back to the older application version as fast as possible.
Which of the following options should the Solutions Architect implement to meet the requirements?
- Create two identical environments of the application on AWS Elastic Beanstalk. Use a blue/green deployment strategy by swapping the environment’s URL. Deploy the custom scripts using Elastic Beanstalk platform hooks.
- Create a new pipeline on AWS CodePipeline and add a stage that will deploy the application on the AWS EC2 instances. Choose a “rolling update with an additional batch” deployment strategy, to allow a quick rollback to the older version in case of errors.
- Utilize AWS CodeBuild and add a job with Chef recipes for the new application version. Use a “canary” deployment strategy to the new version on a new instance. Delete the canary instance if errors are found on the new version.
- Create an AWS System Manager automation runbook to manage the deployment process. Set up the runbook to first deploy the new application version to a staging environment. Include automated tests and, upon successful completion, use the runbook to deploy the application to the production environment
Correct Answer: 1
Blue/Green Deployment involves maintaining two separate, identical environments. The “Blue” environment is the current production version, while the “Green” is for the new version. . This Green environment is an exact replica of the Blue one but hosts the new version of your application. After deploying and thoroughly testing the new version in the Green environment, you simply switch the environment’s URL to redirect traffic from the Blue to the Green environment. This switch makes the new version live for users. If a rollback is needed due to any issues, it’s just a matter of switching the URL back to the original Blue environment and instantly reverting to the previous version of the application.
In Elastic Beanstalk you can perform a blue/green deployment by swapping the CNAMEs of the two environments to redirect traffic to the new version instantly. If there are any custom scripts or executable files that you want to run automatically as part of your deployment process, you may use platform hooks.
To provide platform hooks that run during an application deployment, place the files under the .platform/hooks directory in your source bundle, in one of the following subdirectories:
prebuild – Files here run after the Elastic Beanstalk platform engine downloads and extracts the application source bundle, and before it sets up and configures the application and web server.
predeploy – Files here run after the Elastic Beanstalk platform engine sets up and configures the application and web server, and before it deploys them to their final runtime location.
postdeploy – Files here run after the Elastic Beanstalk platform engine deploys the application and proxy server.
Therefore, the correct answer is: Create two identical environments of the application on AWS Elastic Beanstalk. Use a blue/green deployment strategy by swapping the environment’s URL. Deploy the custom scripts using Elastic Beanstalk platform hooks.
The option that says: Create an AWS System Manager automation runbook to manage the deployment process. Set up the runbook to first deploy the new application version to a staging environment. Include automated tests and, upon successful completion, use the runbook to deploy the application to the production environment is incorrect. While this is technically possible, it does not offer the fastest rollback mechanism in case of immediate issues post-deployment, as the rollback would involve a separate process. Moreover, unlike AWS Elastic Beanstalk, which has built-in features for version tracking, using AWS System Manager for deployment requires a more manual approach to version control. You would need to maintain a system for tracking different application versions, ensuring that you have the correct version deployed in the right environment (staging vs. production). This adds complexity to the deployment process.
The option that says: Create a new pipeline on AWS CodePipeline and add a stage that will deploy the application on the AWS EC2 instances. Choose a “rolling update with an additional batch” deployment strategy, to allow a quick rollback to the older version in case of errors is incorrect. Although the pipeline can deploy the new version on the EC2 instances, rollback for this strategy takes time. You will have to re-deploy the older version if you want to do a rollback.
The option that says: Utilize AWS CodeBuild and add a job with Chef recipes for the new application version. Use a “canary” deployment strategy to the new version on a new instance. Delete the canary instance if errors are found on the new version. is incorrect. Although you can detect errors on a canary deployment, AWS CodeBuild cannot deploy the new application version on the EC2 instances. You have to use AWS CodeDeploy if you want to go this route. It’s also easier to set up Chef deployments using AWS OpsWorks rather than in AWS CodeBuild.
References:
https://aws.amazon.com/opsworks/chefautomate/
https://docs.aws.amazon.com/opsworks/latest/userguide/best-deploy.html#best-deploy-environments-blue-green
https://docs.aws.amazon.com/opsworks/latest/userguide/workingapps-deploying.html
Note: This question was extracted from our AWS Certified Solutions Architect Professional Practice Exams.
Question 2
A DevOps team is preparing an AWS CloudFormation template for a web application. The application’s architecture requires launching EC2 instances across multiple Availability Zones within private subnets. An Application Load Balancer (ALB) will route incoming traffic to these instances. Additionally, the application must be accessible to clients that use IPv6 addresses.
What must be included in the CloudFormation template to meet the requirements?
- Define a VPC with an IPv6 CIDR block. Launch the EC2 instances in the private subnet, and assign an IPv6 Elastic IP address to each instance. Set up a NAT gateway to use NAT64 with a DNS64 server to allow outbound IPv6 communication from the private subnet to the internet.
- Define a VPC configured with subnets enabled for the IPv6 CIDR block. Configure the ALB with the IP address type as Dualstack. Add subnets for the ALB. Add a listener on port 443 that forwards traffic to a target group. Add the EC2 instances as targets of the target group.
- Create a VPC with an IPv6 CIDR block. Launch EC2 instances that support IPv6 IPs in a private subnet of the VPC. Configure route table entries for the IPv6 network and assign IPv6 addresses to the EC2 instances.
- Instead of an Application Load Balancer (ALB), use a Network Load Balancer (NLB) configured with the IP address type of Dualstack. Create an IPv6 target group with the EC2 instances running the web services as targets. Associate the target group with the NLB.
Correct Answer: 2
Elastic Load Balancing (ELB) automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It supports the following types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers.
To support IPv6, configure your Application Load Balancers or Network Load Balancers with the “dualstack” IP address type. This will allow the client to communicate with the load balancers using both IPv4 and IPv6 addresses. The Application Load Balancer supports both HTTP and HTTPs listeners to support IPv6. The Network Load Balancer supports IPv6 on frontend connections for only TCP and TLS listeners.
Creating a VPC with IPv6 subnets ensures that the VPC supports IPv6 addresses. Subnets should also be configured within the VPC to host the private EC2 instances.
Therefore, the correct answer is: Define a VPC configured with subnets enabled for the IPv6 CIDR block. Configure the ALB with the IP address type as Dualstack. Add subnets for the ALB. Add a listener on port 443 that forwards traffic to a target group. Add the EC2 instances as targets of the target group.
The option that says: Define a VPC with an IPv6 CIDR block. Launch the EC2 instances in the private subnet, and assign an IPv6 Elastic IP address to each instance. Set up a NAT gateway to use NAT64 with a DNS64 server to allow outbound IPv6 communication from the private subnet to the internet is incorrect. Although configuring the VPC with an IPv6 address is necessary, it’s not sufficient to fulfill all the requirements. Assigning an Elastic IP address to each instance is not needed because Elastic IPs are typically used for static public IPv4 instances and not for private instances. Setting up a NAT gateway significantly complicates the solution.
The option that says: Create a VPC with an IPv6 CIDR block. Launch EC2 instances that support IPv6 IPs in a private subnet of the VPC. Configure route table entries for the IPv6 network and assign IPv6 addresses to the EC2 instances is incorrect. Although this solution mentions IPv6, it is incomplete. It does not cover ALB configuration or setting up the listener, which is necessary for the traffic to reach the instances in the private subnet. Also, since clients connect to the web application through the ALB, configuring IPv6 directly on the EC2 instances is unnecessary. ALB can communicate with its targets regardless of whether the client connects using IPv4 or IPv6.
The option that says: Instead of an Application Load Balancer (ALB), use a Network Load Balancer (NLB) configured with the IP address type of Dualstack. Create an IPv6 target group with the EC2 instances running the web services as targets. Associate the target group with the NLB is incorrect. Although a Network Load Balancer can also be configured with an IP address type of Dualstack to support IPv6 addresses, it only supports TCP and UDP protocols and is not the best solution for accessing the web service in the EC2 instances.
References:
Check out this AWS Elastic Load Balancing Cheat Sheet:
For more AWS practice exam questions with detailed explanations, visit the Tutorials Dojo Portal:
AWS OpsWorks Cheat Sheet References:
https://aws.amazon.com/opsworks/chefautomate/features
https://aws.amazon.com/opsworks/chefautomate/pricing
https://aws.amazon.com/opsworks/chefautomate/faqs
https://aws.amazon.com/opsworks/puppetenterprise/feature
https://aws.amazon.com/opsworks/puppetenterprise/pricing
https://aws.amazon.com/opsworks/puppetenterprise/faqs
https://aws.amazon.com/opsworks/stacks/features
https://aws.amazon.com/opsworks/stacks/pricing
https://aws.amazon.com/opsworks/stacks/faqs
Get $4 OFF in AWS Solutions Architect & Data Engineer Associate Practice Exams for $10.99 ONLY!
Be Inspired and Mentored with Cloud Career Journeys!
Enroll Now – Our Azure Certification Exam Reviewers
Enroll Now – Our Google Cloud Certification Exam Reviewers
Tutorials Dojo Exam Study Guide eBooks
FREE AWS Exam Readiness Digital Courses
Subscribe to our YouTube Channel
FREE Intro to Cloud Computing for Beginners
FREE AWS, Azure, GCP Practice Test Samplers
Written by: Jon Bonso
