Now that you have Jenkins installed, it's relatively painless to run tests against git builds and deploy to Elastic Beanstalk. To do this sanely, you'll want:

  1. Jenkins Git Plugin or another version control plugin
  2. Jenkins AWSEB Deployment Plugin

Create a Deployment Bucket

I prefer to have a separate bucket for all my deployments, and organize different deploys by key. The AWSEB plugin makes that simple by requiring an S3 Bucet Prefix option, which I typically just set to the app name, appending the environment (-dev, -qa, -etc.) if it's not production. You can use the CLI tool to create a bucket, or generate one using the AWS web console. You'll need a unique name across all of S3, so plan on including part of your username. For example:

aws s3 mb s3://pecosbill-deployment

Once your bucket is created, you'll need a Jenkins user, and a policy that allows that user to access the bucket.

Create Jenkins User

Create a Jenkins IAM user. I found it helpful to use the web interface for the first handful of roles, so you can do a sanity check after attaching policies. There are policy generators and IAM simulators that help you lock everything down.

IAM User Policy

I'm a fan of using encrypted S3 buckets to store and deploy sensitive information (more on this soon). Because of that, I want to make sure any buckets I use for those credentials are not accessible by the Jenkins user. This is easily done if your deploys go to one bucket and your credentials go to another. Below is a simple user policy that blocks all s3 access to name-of-credential-bucket, and allows it for everything else. Attach this policy to the IAM user you just created, making sure to modify the bucket names you wish to secure:

"Version": "2012-10-17",
"Statement": [
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"Effect": "Allow",
"Action": [
"Resource": "*"

It's important to have both the base bucket name, and the bucket name followed by '/*' in order to stop access to the entire bucket. You could use a bucket policy instead here, but I find user- and role-based policies more manageable.

IAM Credentials

Once your user is created, and the security policy is in place, generate credentials for your IAM user. You'll enter access key ID and secret access key into your Jenkins job configuration. You can do this from the IAM > Users panel of the AWS console, but it's faster through the AWS CLI tool, which can be installed quickly with:

pip install awscli

Once the CLI tool is installed and configured, go ahead and generate your credentials:

aws iam create-access-key --user-name MyUser

Make sure to store the credentials this command returns somewhere safe. 1Password is a good solution, and I'm sure there are plenty of others.

Configure Deploy into Elastic Beanstalk

Now everything is ready to create a deploy job. Create your Jenkins job as normal, and after your tests, add an additional build step "Deploy into Elastic Beanstalk".

AWS Access Key Id <shorter string from IAM credentials>
AWS Shared Secret Key <longer string from IAM credentials>
AWS Region us-east-1 (or whatever your region is)
Application Name <your-elastic-beanstalk-app-name>
S3 Bucket Name <your-deployment-bucket-name>
S3 Key Prefix <app-name> (or whatever you like)
Root Object (File / Directory) . (assuming you're using the git plugin and packaging your whole checkout)
Excludes .git/**/*,.tox/**/* (depends on your app)
Version Label Format ${BUILD_ID}
Environment Name <your-elastic-beanstalk-environment-name>

Now save the Jenkins job, and give it a run. Hopefully, the Jenkins job will succeed and then you'll see your application start to deploy in the Elastic Beanstalk console.