Jenkins on AWS
Jenkins on AWS

Best practices

The following are best practices for a traditional deployment.


In its default configuration, Jenkins doesn’t perform any security checks that could expose passwords, certificates, and private data, as well as leave job builds and configurations open to anyone. Using security groups, configure user security and network security on both your master instance and work nodes to limit the vectors at which an attacker can compromise your system.


Launch your Jenkins master from an instance that has enough CPU and network bandwidth to handle concurrent users. Configure worker nodes so that they are identical to each other. They should run on the same instance family from the same generation, and builds should happen on the worker nodes, not the master. Worker nodes should be fungible—able to be thrown away quickly, and brought up or added into the cluster with as little manual interaction as possible. Use AMIs as described earlier to create a default image for your worker nodes. Then, launch additional worker nodes as necessary based on this image.

If your teams build at dedicated or predictable times, you can stop worker nodes when jobs are not running, and turn them on only when you need them. This way you don’t pay for idle instances.


At all times, monitor your instances, especially CPU and disk performance. Take advantage of Amazon CloudWatch alarms to monitor instance resources like CPU usage or disk utilization. This will help you right-size your instances and volumes. Email and SMS alerts can be configured to immediately notify you when events like low disk space or high CPU utilization cross a threshold that you define.

Backup and Restoration

Maintaining a regular backup of your Jenkins master is crucial to providing a stable environment. A backup ensures that your Jenkins instance can be restored in the event of data corruption or loss, or misconfiguration of Jenkins, which leaves it in a usable state.

You can perform a backup by either taking a snapshot of the entire server or by backing up the $JENKINS_HOME directory.

Amazon EBS provides a feature for backing up the data on your Amazon EBS volumes to Amazon Simple Storage Service (Amazon S3) by taking point-in-time snapshots. We strongly recommend that you take regular snapshots of the Amazon EBS volumes backing your Jenkins master. Because you can launch a new volume based on a snapshot, you can quickly recover in the event of a failure.

Instead of taking a snapshot of the entire volume, you can choose to just back up the $JENKINS_HOME directory, which contains your Jenkins-specific configurations. When you restore, you simply launch a new Jenkins master and replace the $JENKINS_HOME directory with the contents of your backup.

Finally, there are many plugins available to manage backups for your $JENKINS_HOME directory, such as the S3 Plugin, which backs up your configuration to Amazon S3, which is designed to provide 99.999999999% durability and 99.99% availability.

Further Reading

For more information on best practices for using Jenkins in your projects’ lifecycles, we encourage you to read the Jenkins Best Practices wiki.