Building a durable Jenkins CI setup in AWS

 | 24. marraskuuta 2017

CI pipeline is an essential part of modern software project and one of the most popular CI-servers is  Jenkins. Managing and setting up a highly available Jenkins server can be a tedious job. For smaller projects, cost of running a multi-instance setup is often too expensive.

If you are willing to accept minor downtime in case of a sudden server loss, we demonstrate here a simple self-healing single server setup that you can use in your AWS environment.

The setup uses  AWS EBS. EBS is highly available and persistent block storage service, that we can use to persist Jenkins state between server terminations.

We use AWS autoscaling group with node count of exactly one that automatically restarts new server if the existing server is suddenly terminated (remember, in reality  everything fails, all the time  ).

We use  AWS Route53  for registering a domain for the newly created Jenkins instance – so that access to the server is not bound to node IP address that changes upon termination.

To glue everything together we use EC2 instances user data and AWS Cloudformation for documented and repeatable setup.

The prerequisite

To use this template you should have basic VPC with at least one public subnet and Route53 hosted zone already set up.

The basic setup

Simple jenkins setup architecture diagram

For the sake of simplicity we install the Jenkins into public subnet, but in production usage you should run it in private subnet and manage the network access depending on your networking configuration.

The permissions

First your EC2 instance needs some permissions to call AWS API. We define IAM role that has policy that grants access to listing and attaching EBS volumes and allows EC2 to update its own DNS record in the given Route53.

The EBS Mounting

The real magic happens in the userdata script that is executed when the EC2 instance is started. When the EC2 instance is first time started a custom  user data script  is run. This configures the instance with defined software packages and it is also the place to run you EBS mounting and Route53 registration code.

The Route53 registration

When the Jenkins is up and running we need to bind it to some domain name  (in this example jenkins.{yourdomain}) , so you don’t have to lookup the IP address every time the server restarts.

Doing the first login

To gain access to Jenkins for the first time you need get the first time login password from Jenkins.

This part of script checks if this is first Jenkins start and prints the first time login password into std-out. You can view the userdata scripts output in AWS Console.

Go to AWS console -> ec2 -> select jenkins instance 
In the context menu select  Instance settings -> Get system log  and you should see in the bottom part of the log a entry  Your Jenkins Password ********** . You can copy paste that password into Jenkins ui and login.
Now you have successfully created a simple and durable Jenkins setup =).

You can view/download the whole template  jenkins.yaml here

Pilvi haltuun

Huolehdimme pilvestä kokonaisuutena, jotta asiakkaamme voivat keskittyä kasvuun, kehitykseen ja asiakkaisiinsa.

Varmistamme, että digitaaliset palvelut toimivat luotettavasti ja tukevat liiketoimintaa kaikissa tilanteissa.

Uusimmat kirjoitukset

CNAPP Cloud-Native Application Protection Platform

Miten pitää pilviympäristöt turvallisina ilman, että kehitys hidastuu?

Tekijä Teemu Peräkylä • 13. toukokuuta 2026
Pilviympäristöjen kasvaessa myös tietoturvan hallinta monimutkaistuu. Uusien työkalujen lisääminen ei aina ratkaise ongelmaa, vaan voi lisätä hajanaisuutta ja vaikeuttaa kriittisten riskien tunnistamista. CNAPP tuo tietoturvan osaksi pilvinatiivien sovellusten kehitystä ilman, että nopeus tai ketteryys kärsii.

Asiakas edellä – Teemu Peräkylä osaksi Webscalea

Tekijä Sara Peltola • 22. huhtikuuta 2026
Teemu Peräkylä liittyi Webscaleen, tuoden yli 20 vuoden IT-myynnin kokemuksen. Ota yhteyttä !
European Cloud

Hyperscaler vai eurooppalainen pilvipalvelu?

Tekijä Teemu Peräkylä • 8. huhtikuuta 2026
Pilvipalveluiden valinta ei ole pelkkä tekninen tai kustannuksiin perustuva päätös. Digitaalinen suvereniteetti korostuu, kun organisaatiot pohtivat datan sijaintia ja hallintaa. Tekstissä vertailemme hyperscalereita ja eurooppalaisia pilvipalveluita sekä sitä, miksi paras ratkaisu löytyy usein näiden yhdistelmästä.