This chapter covers AWS OpsWorks for Chef Automate and AWS OpsWorks for Puppet Enterprise—fully managed configuration management services that integrate Chef and Puppet with AWS. For the SOA-C02 exam, these topics appear in Domain 3 (Deployment) under Objective 3.2: 'Automate deployment of resources using AWS services such as ... AWS OpsWorks for Chef Automate and AWS OpsWorks for Puppet Enterprise.' While not a heavy topic (approximately 2-4% of questions), understanding the managed service architecture, integration with AWS services, and common troubleshooting scenarios is essential for the exam. We will explore the core mechanisms, step-by-step setup, real-world use cases, and exam-specific traps.
Jump to a section
Imagine a large restaurant kitchen where the head chef writes recipes in a master recipe book. Each recipe details every step: chop onions, sauté for 3 minutes, add 200ml stock, simmer for 20 minutes. The kitchen has multiple cooks (servers) who must follow these recipes to prepare dishes. Instead of the head chef shouting instructions, each cook has their own copy of the recipe book (Chef server). When a new recipe is added or an existing one is updated, the head chef publishes the changes, and all cooks automatically fetch the latest version (via Chef client). The head chef also assigns each cook a specific role (e.g., 'grill station' or 'pastry station'), and the recipe book includes a 'run list' for each role—a sequence of recipes to execute. If a cook is sick (server failure), a replacement cook pulls the same role's run list and gets the same dishes prepared. The entire kitchen runs consistently, even as cooks come and go. OpsWorks for Chef Automate manages this entire system—the recipe book (cookbooks), the head chef (Chef server), and the automated synchronization—so you don't have to build the kitchen infrastructure yourself. Puppet works similarly but uses 'manifests' (like blueprints) and 'agents' that pull configurations from a 'Puppet master'. OpsWorks for Puppet Enterprise manages that master and agent infrastructure for you.
What AWS OpsWorks for Chef and Puppet Are
AWS OpsWorks for Chef Automate and AWS OpsWorks for Puppet Enterprise are fully managed configuration management services. They allow you to use Chef and Puppet—popular open-source tools for automating server configuration—without having to manage the underlying infrastructure (the Chef server or Puppet master). AWS handles the heavy lifting: provisioning, patching, backup, and scaling of the management servers. You provide the cookbooks (Chef) or modules (Puppet) and manage nodes (servers) that run the Chef client or Puppet agent.
Why They Exist
Before these managed services, organizations had to deploy and maintain their own Chef server or Puppet master—typically on EC2 instances. This required expertise in both the configuration management tool and AWS operations. Tasks like high availability, backup, and scaling were manual. OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise eliminate this operational overhead. They are AWS-native services that integrate with IAM, CloudWatch, and other AWS services.
How They Work Internally
When you create a Chef Automate server (called a 'stack' in OpsWorks), AWS provisions an EC2 instance running Chef Automate software (including Chef server, Chef Manage UI, and Chef Automate analytics). The server is configured with a self-signed SSL certificate by default, but you can upload your own. The server is accessible via HTTPS (port 443) and SSH (port 22) for administration.
Nodes (EC2 instances or on-premises servers) run the Chef client, which connects to the Chef server to fetch its run list and cookbooks. The Chef client runs periodically (default every 30 minutes) and applies the desired state. With OpsWorks for Chef Automate, you can register nodes by installing the Chef client and providing the server URL and a validation key. Alternatively, you can use AWS OpsWorks to automatically register EC2 instances via the OpsWorks agent (for Chef 12 stacks) or via custom scripts.
For Puppet Enterprise, AWS provisions a Puppet master server with the Puppet Enterprise software. Nodes run the Puppet agent, which connects to the master to fetch catalogs. The agent runs every 30 minutes by default. OpsWorks for Puppet Enterprise also includes a console for reporting and RBAC.
Key Components, Values, Defaults, and Timers
Chef Automate Server: Provisioned as an EC2 instance (t3.medium by default, but can be changed at launch). The server includes:
- Chef Server 12 - Chef Manage (UI) - Chef Automate (analytics and visibility) - Puppet Enterprise Server: Provisioned as an EC2 instance (m5.large by default). Includes:
- Puppet Server
- PuppetDB
- Puppet Enterprise Console
- Node registration: For Chef, you need the server's FQDN (e.g., https://your-chef-server.opsworks-cm.io/organizations/default). For Puppet, you need the master's FQDN and a token.
- Default run interval: 30 minutes for both Chef client and Puppet agent. Can be changed in client configuration.
- Backup: AWS automatically backs up the Chef Automate server daily (retained for 7 days) and stores backups in an S3 bucket managed by AWS. For Puppet Enterprise, backups are also automated.
- High availability: OpsWorks for Chef Automate and Puppet Enterprise are single-instance by default. For production, you may need to implement your own HA strategy (e.g., multiple Chef servers with a shared data store). AWS does not provide automatic failover.
- Scaling: The server can be scaled vertically by modifying the instance type (via AWS support). Horizontal scaling is manual.
Configuration and Verification Commands
To set up a Chef Automate stack:
1. Open the AWS OpsWorks console.
2. Choose 'Chef Automate' and click 'Create server'.
3. Provide a server name, Chef Automate version (default latest), instance type, and key pair.
4. Optionally, upload a custom SSL certificate and associate a custom domain.
5. After creation, note the server endpoint (e.g., https://your-chef-server.opsworks-cm.io).
6. Register nodes: On an EC2 instance, install the Chef client and run:
curl -L https://omnitruck.chef.io/install.sh | sudo bash
sudo chef-client -S https://your-chef-server.opsworks-cm.io/organizations/default -K /path/to/validator.pemTo verify:
sudo chef-clientCheck the Chef Manage UI for node list.
For Puppet Enterprise: 1. Console: Create a Puppet Enterprise server. 2. After creation, download the agent installer script. 3. On nodes, run:
curl -k https://your-puppet-server.opsworks-cm.io:8140/packages/current/install.bash | sudo bashSign certificate on the master:
sudo /opt/puppetlabs/bin/puppetserver ca sign --certname <node-fqdn>How It Interacts with Related Technologies
IAM: You need IAM permissions to create and manage OpsWorks stacks. The service uses a service-linked role (AWSServiceRoleForOpsWorksCM) to access resources like EC2 and S3.
CloudWatch: Server health metrics (CPU, memory) and logs are sent to CloudWatch Logs.
VPC: The server is launched in a VPC. You must ensure network connectivity (security groups, NACLs) between the server and nodes.
AWS Systems Manager: You can use SSM to run commands on nodes, but the primary configuration management is through Chef/Puppet.
AWS CloudFormation: You can provision OpsWorks stacks using CloudFormation templates (resource type AWS::OpsWorksCM::Server).
Exam-Specific Details
The exam may ask about the difference between OpsWorks for Chef Automate and OpsWorks Stacks (the older service). OpsWorks Stacks uses a custom OpsWorks agent and is Chef-based but not Chef Automate. OpsWorks for Chef Automate is a fully managed Chef server.
Know that OpsWorks for Chef Automate and Puppet Enterprise are regional services. You must create a server in each region where you need it.
Default backup retention is 7 days. You cannot change this via the console; you must use AWS Support.
The server endpoint is in the format *.opsworks-cm.io.
Nodes can be on-premises or EC2. For on-premises, ensure network connectivity (VPN or Direct Connect).
The exam may present a scenario where a company wants to migrate from self-managed Chef to OpsWorks for Chef Automate. The answer typically involves creating a new Chef Automate server and uploading existing cookbooks and data via knife.
Create the OpsWorks Server
Navigate to the AWS OpsWorks console and choose either Chef Automate or Puppet Enterprise. Click 'Create server'. Provide a name (e.g., 'MyChefServer'), select the instance type (default t3.medium for Chef, m5.large for Puppet), and choose a key pair for SSH access. Optionally, upload a custom SSL certificate and associate a custom domain. Under 'Network', select a VPC and subnet. The server will be provisioned in about 15-20 minutes. During this time, AWS creates an EC2 instance, installs the Chef Automate or Puppet Enterprise software, and configures it with the specified settings. A service-linked role is automatically created if not present.
Configure Node Registration
Once the server is active, note the server endpoint (e.g., `https://my-chef-server.opsworks-cm.io`). For Chef, you need the validator key (a .pem file) that is available in the OpsWorks console under 'Settings'. Download this key and store it securely. For Puppet, you need the master's FQDN and a registration token (or you can use autosigning). The validator key for Chef is used by the Chef client during initial registration to obtain a client certificate. For Puppet, the agent automatically requests a certificate from the master, which must be signed (manually or via autosigning).
Register Nodes via Bootstrap Script
On each target node (EC2 instance or on-premises server), run the bootstrap command. For Chef, this typically involves downloading and installing the Chef client, then running `chef-client` with the server URL and validator key. Example: `curl -L https://omnitruck.chef.io/install.sh | sudo bash && sudo chef-client -S https://my-chef-server.opsworks-cm.io/organizations/default -K /path/to/validator.pem`. The Chef client will generate a client key and request registration. The server responds with a client certificate, and the node is added to the Chef server's node list. For Puppet, run the installer script: `curl -k https://puppet-master.opsworks-cm.io:8140/packages/current/install.bash | sudo bash`. The agent will install, configure itself to point to the master, and request a certificate.
Sign Puppet Certificates (if needed)
For Puppet Enterprise, after the agent runs, the master receives a certificate signing request (CSR). By default, the master does not automatically sign certificates. You must manually sign each certificate on the master server via SSH: `sudo /opt/puppetlabs/bin/puppetserver ca sign --certname <node-fqdn>`. Alternatively, you can configure autosigning by editing `/etc/puppetlabs/puppet/autosign.conf` on the master. For Chef, the registration is automatic using the validator key; no manual signing is required. However, if you revoke the validator key, new nodes cannot register.
Deploy Cookbooks or Modules
With nodes registered, you can now deploy configurations. For Chef, use `knife` from your workstation: `knife cookbook upload my_cookbook -c knife.rb`. The knife.rb file must point to the Chef server endpoint and use the appropriate client key. For Puppet, you can use r10k or Code Manager to deploy environments from a Git repository. Alternatively, you can manually place modules in `/etc/puppetlabs/code/environments/production/modules/` on the master. The nodes will pull the latest configuration during their next run (default every 30 minutes). You can also trigger an immediate run with `sudo chef-client` or `sudo puppet agent -t`.
Enterprise Scenario 1: Standardizing EC2 Configuration
A financial services company manages 500+ EC2 instances across multiple AWS accounts and regions. They need to ensure consistent security hardening (e.g., CIS benchmarks) and application configuration. Using OpsWorks for Chef Automate, they create a single Chef server in us-east-1. They develop cookbooks for security policies, monitoring agents, and application stacks. Each EC2 instance is launched with a user-data script that installs the Chef client and registers with the server. The Chef client runs every 15 minutes (shortened from default 30) to enforce compliance. When a new security patch is required, the team updates the cookbook and uses knife ssh to trigger a chef-client run on all nodes. The managed Chef server handles backups automatically; they have not lost any configuration data. One challenge: when the Chef server fails (e.g., due to AZ outage), nodes continue to run with cached configuration but cannot update. They mitigate by taking regular snapshots of the Chef server's EBS volume.
Enterprise Scenario 2: Hybrid Cloud with Puppet
A retail company has 200 on-premises servers in a data center and 300 EC2 instances. They use Puppet for configuration management. Instead of managing their own Puppet master, they deploy OpsWorks for Puppet Enterprise in a VPC with a VPN connection to their data center. On-premises servers connect to the Puppet master over the VPN. The master is configured with autosigning for nodes from trusted subnets. They use PuppetDB for inventory and reporting. The OpsWorks server is sized as m5.large, handling 500 nodes without performance issues. They use Code Manager to deploy Puppet code from a Git repository. A common issue: when the VPN drops, on-premises nodes cannot reach the master and fail to apply changes. They use a local file server as a proxy.
Performance and Misconfiguration
Scale: OpsWorks for Chef Automate supports up to 500 nodes per server (soft limit). For more, you need to scale vertically or use multiple servers. Puppet Enterprise can handle thousands of nodes with appropriate master sizing.
Misconfiguration: A common mistake is not opening port 443 (HTTPS) in the security group for the Chef server. Nodes cannot register. Another is using the wrong validator key; the Chef client will fail authentication. For Puppet, forgetting to sign certificates leaves nodes in an unapproved state. Also, if you change the server's SSL certificate, you must update the client configuration.
Backup: AWS automatically backs up the server daily, but if you need point-in-time recovery, you must take manual snapshots. Restoring from backup requires contacting AWS Support.
What SOA-C02 Tests on This Topic
Objective 3.2 specifically mentions AWS OpsWorks for Chef Automate and AWS OpsWorks for Puppet Enterprise as services to automate deployment. The exam tests your understanding of:
The difference between OpsWorks Stacks and OpsWorks for Chef Automate.
How to register nodes (validator key for Chef, certificate signing for Puppet).
Default run intervals (30 minutes).
Backup retention (7 days).
Integration with IAM (service-linked role).
Network requirements (port 443, VPC).
Common Wrong Answers and Why
'OpsWorks for Chef Automate supports automatic scaling of nodes.' Wrong. The Chef server itself can be scaled, but node registration is manual or via user-data. The service does not auto-scale nodes.
'You can manage on-premises servers without any additional setup.' Wrong. On-premises servers need network connectivity (VPN/Direct Connect) and must be able to reach the Chef server endpoint.
'Backups are retained for 30 days by default.' Wrong. Default retention is 7 days. You need AWS Support to change it.
'Chef Automate and Puppet Enterprise are the same as OpsWorks Stacks.' Wrong. OpsWorks Stacks is a different service with its own agent and lifecycle management.
Specific Numbers and Terms
Default Chef client run interval: 30 minutes (can be changed in client.rb).
Default backup retention: 7 days.
Server endpoint format: *.opsworks-cm.io.
Default instance type for Chef Automate: t3.medium.
Default instance type for Puppet Enterprise: m5.large.
Service-linked role: AWSServiceLinkedRoleForOpsWorksCM.
Ports: HTTPS (443) for API, SSH (22) for admin.
Edge Cases
If you lose the validator key, you cannot register new nodes, but existing nodes continue to work. You can generate a new validator key from the OpsWorks console.
If the Chef server's SSL certificate expires, nodes will fail to connect. You must update the certificate and restart the Chef server.
OpsWorks for Puppet Enterprise does not support autosigning by default; you must configure it manually.
How to Eliminate Wrong Answers
If a question mentions 'OpsWorks' without specifying 'for Chef Automate' or 'for Puppet Enterprise', it might be referring to OpsWorks Stacks. Read carefully.
If the answer suggests that OpsWorks for Chef Automate provides high availability out-of-the-box, it is wrong. HA is manual.
If the answer mentions 'Chef server' as a separate EC2 instance you manage, it is not describing the managed service.
Focus on the key differentiator: AWS manages the server infrastructure for you.
AWS OpsWorks for Chef Automate and Puppet Enterprise are fully managed configuration management services that eliminate the need to manage the Chef server or Puppet master yourself.
The default Chef client and Puppet agent run interval is 30 minutes.
Backups are automatically performed daily and retained for 7 days; to change retention, contact AWS Support.
Nodes can be EC2 instances or on-premises servers, provided network connectivity (HTTPS port 443) is established.
For Puppet, you must manually sign node certificates unless autosigning is configured.
The server endpoint uses the format `*.opsworks-cm.io`.
IAM service-linked role `AWSServiceLinkedRoleForOpsWorksCM` is required for the service to create and manage resources.
High availability is not built-in; you must implement manual HA strategies for production workloads.
OpsWorks Stacks is a separate service with different capabilities and is not interchangeable with OpsWorks for Chef Automate.
You can use AWS CloudFormation to provision OpsWorks for Chef Automate and Puppet Enterprise servers.
These come up on the exam all the time. Here's how to tell them apart.
AWS OpsWorks for Chef Automate
Uses Chef client and cookbooks (Ruby-based DSL).
Default instance type: t3.medium.
Node registration uses a validator key (.pem file).
Server endpoint: `*.opsworks-cm.io`.
Backup: daily, retained 7 days.
AWS OpsWorks for Puppet Enterprise
Uses Puppet agent and manifests (Puppet DSL).
Default instance type: m5.large.
Node registration requires certificate signing (manual or autosign).
Server endpoint: `*.opsworks-cm.io` (same format).
Backup: daily, retained 7 days.
Mistake
AWS OpsWorks for Chef Automate and OpsWorks Stacks are the same service.
Correct
OpsWorks Stacks is a different service that uses a custom OpsWorks agent and is more like an application lifecycle manager (with layers and instances). OpsWorks for Chef Automate provides a fully managed Chef server with the standard Chef client. They are separate services with different APIs and use cases.
Mistake
You must use EC2 instances as nodes; on-premises servers are not supported.
Correct
On-premises servers are fully supported as long as they have network connectivity to the Chef server or Puppet master (via VPN or Direct Connect). They run the standard Chef client or Puppet agent.
Mistake
The Chef server automatically scales to handle more nodes.
Correct
The Chef server is a single EC2 instance. To scale, you must manually change the instance type (via AWS Support) or implement a multi-server setup. There is no automatic horizontal scaling.
Mistake
Backups are configurable for any retention period.
Correct
Backup retention is fixed at 7 days by default. To change it, you must contact AWS Support. You can also take manual snapshots of the server's EBS volume for custom retention.
Mistake
Puppet certificates are automatically signed by default.
Correct
By default, the Puppet master does not autosign certificates. You must manually sign each node's certificate or configure autosigning via `/etc/puppetlabs/puppet/autosign.conf`.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AWS OpsWorks Stacks is a configuration management service that uses a custom OpsWorks agent and is designed for application lifecycle management (deploying apps, managing layers, etc.). It uses Chef 12 but is not a full Chef server. AWS OpsWorks for Chef Automate provides a fully managed Chef server with the standard Chef client, Chef Manage UI, and Chef Automate analytics. OpsWorks Stacks is more focused on AWS-native orchestration, while OpsWorks for Chef Automate gives you a standard Chef environment without managing the server.
You can register an EC2 instance by installing the Chef client and running `chef-client` with the server URL and validator key. The validator key is available in the OpsWorks console under 'Settings' for your Chef Automate server. Typically, you include the bootstrap command in user-data when launching the instance. Example: `curl -L https://omnitruck.chef.io/install.sh | sudo bash && sudo chef-client -S https://your-server.opsworks-cm.io/organizations/default -K /path/to/validator.pem`.
Yes. When creating the Chef Automate server, you can upload a custom SSL certificate and specify a custom domain. This replaces the default self-signed certificate. If you need to update the certificate later, you must contact AWS Support or recreate the server.
If the Chef server fails, existing nodes continue to run with their cached configuration (the last applied state) and will not receive updates until the server is restored. AWS automatically backs up the server daily, and you can restore from the latest backup by contacting AWS Support. In production, you should implement high availability (e.g., multiple Chef servers with a shared data store) to minimize downtime.
You can change the run interval by editing the `client.rb` file on each node. The default is 30 minutes. For example, to set it to 15 minutes, add `chef_interval 900` to `/etc/chef/client.rb` and restart the chef-client service. Alternatively, you can set it via a cookbook attribute.
By default, autosigning is disabled. You can enable it by editing `/etc/puppetlabs/puppet/autosign.conf` on the Puppet master and adding entries (e.g., `*.example.com`). However, this is a security risk. For production, it is recommended to manually sign certificates or use a policy-based autosigning.
Nodes must be able to reach the Chef server endpoint on port 443 (HTTPS). If the server is in a VPC, the nodes must have network access (e.g., same VPC, VPC peering, VPN, or Direct Connect). The security group for the Chef server must allow inbound HTTPS from the nodes' IP ranges.
You've just covered AWS OpsWorks for Chef and Puppet — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?