Get started with OpsWorks for Chef Automate

In November, AWS hosted its big annual event, re:Invent, where lots of new features were released. The full list of product announcements can be found here. One of them, OpsWorks for Chef Automate, allows you to launch a Chef Automate server fully managed by AWS.This means that AWS not only takes care of the infrastructure where the instance is running but also of the OS and application it runs (here, Chef Automate). The good news is that you don’t have to take care of patching or upgrading the instance. AWS guarantees that the Chef Automate server is compatible with your cloud environment and ready to use when instantiated. As of December 2016, it is available in US East (N. Virginia), US West (Oregon) and EU (Ireland).

This article will explain what Chef Automate is, and how AWS offers it.


What is Chef Automate ?


Chef Automate gathers "Compliance", "Workflow" (former Chef Delivery), and "Visibility" concepts. It can be deployed on-premise or on AWS.

"Workflow" allows you to handle continuous deployment pipelines, from development to production. Tests can be performed, and both manual and automatic actions can be taken to progress in the pipeline.

"Compliance" feature helps you to check whether your nodes are compliant or not with rules. You can define these rules using InSpec or with built-in profiles. Compliance reports are then presented in the UI.

"Visibility" brings the ability to query Chef data from nodes or server. With this feature, you can, for example, visualize the number of cookbooks deployed on your nodes in the Chef Automate UI.

Finally, Chef Automate integrates with Chef server, which allows management of nodes using cookbooks.


Getting started

The first step is to instantiate your Chef Automate server. AWS provides documentation to start with OpsWorks for Chef Automate.

After a few customizations (Region, Instance type), you are asked to provide a SSH key for connecting to your instance. Surprisingly, you are able to SSH to the Chef server, although AWS says the service is fully managed. This can be a good thing if you want to customize your Chef server more deeply, but it also can be an issue: AWS may not agree to provide support for your Chef instance if you make too many changes to it.

You also have the option to enable automated backup, so your Chef Automate server can be restored from an S3 bucket if needed.

You have to wait around 20 minutes for the instance to be ready. In the meantime, you have to download both Starter Kit and sign-in credentials. The starter kit contains the private key you need to connect to your Chef server and provides a configuration file to run Chef commands against your Chef Automate server, using the Chef Development Kit.

When the server is ready, you can then upload a cookbook as you would with a classic Chef server, using Berks for example. A simple "berks install" followed by "berks upload" will upload your cookbooks and their dependencies to the Chef server.

Note: It appears that you have to enable DNS hostnames in your VPC so your Chef Automate server can work. Failing at doing so will prevent you from uploading cookbooks.

Quoting AWS: "During spawn the instance configures some details using private hostnames, which results in a server error during cookbook upload if you don’t enable DNS Hostnames". This option is not activated by default when you create a VPC, so you have to select your VPC and "Edit DNS Hostnames" to enable it.

If you don’t want to activate DNS hostnames in your VPC for some reason, AWS provided this procedure, until a proper solution is deployed:

  1. SSH into the Chef Automate instance
  2. Run the following commands:
    a. "cd /etc/opscode/"
    b. Modify "chef-server.rb" to change the value of bookshelf[‘vip’]:
    "bookshelf[‘vip’] = ‘’
    c. "chef-server-ctl reconfigure"

Uploading a cookbook should now work without problems.

If you decide to delete your Chef Automate server, do it from the OpsWorks console. If you only remove the EC2 instance, you will have remains in OpsWorks that can’t be deleted.



AWS charges Opsworks for Chef Automate per node hour. This means that each node you connect to your Chef instance will be billed hourly, using a tiered model. You will also be charged for the underlying EC2 instance used to run the Chef server.

An interesting thing to do is to compare this offer with the official Chef server available in the AWS Marketplace. Of course, the number of features in this Marketplace version is more limited than Chef Automate, and AWS does not provides support on it, but it can be enough to manage configuration of your nodes if you have some Chef knowledge already.

Let’s take a quick look at the prices of the Marketplace version, without the underlying instance cost. It is charged the same way as Chef Automate, and costs $0.008 / node / hour. In comparison, Automate is almost 2 times more expensive, $0.0155 / node / hour at the first tier.

So if you have 100 nodes to manage in a month, you will pay $1131,5 with Chef Automate, and only $584 with the marketplace Chef Server.

The free tier applies to Chef Automate, with a limit of 10 nodes connected per month.



In short, Opsworks for Chef Automate can be a solution to customers who want to have analytics, compliance, and workflow features along with Chef server. Since it’s a managed service, AWS will support you in case of issue, and will maintain your OS and software. On the other hand if you already have a support team or only want to manage nodes and configuration, the AWS marketplace Chef server would probably be adequate and more cost effective.