AWS Case Study: Migrating an Atlassian Stack to AWS Infrastructure

  • November 07, 2017

Any journey begins with a first step and that’s exactly the approach this financial service firm had in mind when they asked the AWS experts at Flux7 to come in and help. Specifically, the IT team wanted to start with a small project that would set them up for future success. Using Flux7’s Enterprise DevOps Framework, we were able to help them focus on an achievable first step, the migration of their Atlassian stack to AWS, with a longer term roadmap. Read on as we share this AWS case study.

Headquartered in New York City, this financial services company is a fast-growing  investment management firm that offers a variety of portfolio management and advisory services to its clients. The company’s rapid growth presented a challenge that the product development and execution teams sought to address by moving critical applications to a high availability environment in AWS. The ultimate goal was to provide consistently high availability services to internal customers in order to maintain high levels of productivity. In addition, managing risk is not a foreign task to this company, so ensuring the protection of valuable corporate IP was also an essential part of the project.

The Flux7 Solution

To ensure this firm’s deployment could scale elastically, it was identified early on that the Flux7 team would migrate the firm’s Atlassian Stack, consisting of JIRA and Confluence to AWS infrastructure. The DevOps team would set-up a new JIRA Service Desk server, along with Jenkins and integrate them both with GitHub Enterprise (GHE).

Getting started, Flux7 delivered AWS CloudFormation templates to create stacks for:


  1. The necessary parameters to be exported and used in other stacks. This export stack included both output and exported parameters, including VPC, CIDRs, and SNS topic. It was created to maintain best practices in a manually created landing zone.
  2. Amazon RDS PostgreSQL, the relational database service used to set up, operate, and scale PostgreSQL deployments in the cloud. Using RDS as the backend database greatly simplified maintenance while improving durability and availability. Further, Flux7 used Postgres to comply with Atlassian recommendations and used DeletionPolicy snapshots to preserve data.
  3. IAM Roles. To securely control access to AWS resources, Flux7 included roles for each instance requiring permissions, and created a default IAM role to assign to instances with basic permissions. Moreover, IAM roles were separated into their own template to ensure secure ownership.
  4. EC2 Instances which allow for elastic computing, were given their own template and used in conjunction with Service Catalog. All of which allows the application teams to flexibly choose security groups and IAM instance profiles.
  5. Security groups for different instance types.

We also worked together with this client to build an Amazon Service Catalog. We filled this “self-service vending machine” with products for EC2 Instances and RDS that were created with a CloudFormation template. Users can launch their desired product from the service catalog and specify their desired parameters.

An Ansible playbook can be run on the instance to configure the software. We developed Ansible playbooks to handle all the required tasks to deploy and maintain JIRA, JIRA Service Desk, Confluence, GitHub Enterprise and Jenkins in Red Hat Linux 7.  We set up the Jenkins cluster with a GHE high availability installation, with GHE distributed across multiple Availability Zones. GHE and Jenkins were also set up to run routine backups to S3.

Throughout the engagement, the Flux7 team transferred important knowledge to this firm’s team, coaching them on both tools and processes to help ensure their ongoing success in independently managing their new AWS infrastructure and DevOps model.


As source control is essential to this company, if its source control and issues tracking systems like Jira were to go down, development processes would stop working, resulting in idle time, delay and the potential loss of IP. However, with the migration, outages could now be reduced to mere minutes (if not less) and are designed to self-heal.

By all measures, the GitHub Enterprise and Atlassian Jira, and Confluence migration was a successful first step in the firm’s journey to greater availability, productivity and continued IP protection. Indeed, the migration to AWS is viewed as a strong foundation to the firm’s future IT initiatives. Are you interested in migrating your Jira, Confluence, or other application to AWS for greater availability? Read our AWS migration case studies here.

Subscribe to our blog


Related Blog Posts