Deploying enterprise-scale Jira on AWS: a step-by-step guide

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Jira Data Center supports multi-node clustering, giving you high availability and flexible scalability. Multi-node clustering also lets you do zero-downtime upgrades for minimized planned downtime. You can leverage these features by deploying Jira Data Center on appropriate infrastructure.

To help you out, Jira Data Center comes equipped with a fully supported AWS Quick Start. This Quick Start provides a framework for deploying your infrastructure with recommended pre-set defaults. This framework will speed up your deployment, as you don't have to build every piece of your infrastructure from scratch. Rather, you can design your infrastructure around our Quick Start and deploy it quickly on AWS.

This document will serve as a single place to access most of the knowledge resources you'll need to streamline your first deployment. Here, we'll guide you through an end-to-end deployment of Jira Data Center. The instructions here should apply to both Jira Software Data Center and Jira Service Desk Data Center.

tip/resting Created with Sketch.

Non-clustered VS clustered infrastructure

If you have an existing Server installation, you can still use its infrastructure when you upgrade to Data Center. Many features exclusive to Data Center (like SAML single sign-onself-protection via rate limiting, and CDN support) don't require clustered infrastructure. You can start using these Data Center features by simply upgrading your Server installation’s license.

For more information on whether clustering is right for you, check out Atlassian Data Center architecture and infrastructure options.

On this page:

1. What you need to know

The AWS Quick Start for Jira Data Center takes the guesswork out of designing your required infrastructure, preparing all the components that need to be configured. It provides templates that you'll use in this document to deploy your Jira Data Center instance.

1.1 Is this document different from the Quick Start deployment guide?

Yes. In this document, we show you a reference deployment suitable for enterprise-scale organizations. Then, we walk you through the entire deployment process (which includes using the AWS Quick Start for Jira Data Center). In doing so, we also provide recommendations based on our knowledge and experience in managing Jira Data Center at scale.

The AWS Quick Start for Jira Data Center comes with its own deployment guide. That guide shows you how to use the Quick Start to deploy Jira Data Center on AWS. However, it's designed to be useful for organizations of all sizes, and doesn't provide recommendations for a specific reference deployment.

1.2 Why use a third-party cloud platform?

When it comes to hosting Jira Data Center, using a third-party cloud platform like AWS offers many benefits compared to using physical servers. For one, it frees your organization from much of the burden of deploying, maintaining, and scaling physical hardware.

We collaborated with AWS to develop the Quick Start you'll be using, focusing on making it highly configurable for most types of organizations. We use this Quick Start to deploy and maintain Jira Data Center for different teams inside Atlassian. In fact, many of the design principles used for shaping this Quick Start came from lessons we learned from our own AWS deployments.

1.3 What does enterprise-scale mean? 

This document is focused on helping enterprise-scale organizations deploy Jira Data Center and tweak it to suit their needs. We define enterprise-scale organizations as those with Large or XLarge instances (based on our Jira Data Center load profiles).

1.4 How do I know these recommendations are right for me?

Most of the recommendations in this document are based on the following:

  • BenchmarksInfrastructure recommendations for enterprise Jira instances on AWS provides guidance on how to design architecture for the enterprise scale. This guidance is based on extensive testing, whose methodology we also explain in that same article. We use many of the same recommendations in this document. 
  • Experience: Within Atlassian, we run some of the biggest Jira Data Center deployments in production. We do this because Jira is vital to the work of thousands of Atlassians. In turn, we also get to experience firsthand how to run Jira Data Center at the enterprise scale. We learn a lot in the process, and many of our recommendations are based on those learnings.

  • Customer research: We assist many customers and partners, and in the process we learn a lot about how our products are used. This exposes us to the challenges customers face in deploying and maintaining infrastructure; our recommendations are designed to help you address those challenges.

Keep in mind, however, that these recommendations are based on what we believe are appropriate for most enterprise-scale organizations. Your own organization will likely have unique needs and quirks that call for different strategies. Use these recommendations as a baseline which you can tailor to better address your needs. 

1.5 Prerequisite skills

This document will guide you on deploying Jira Data Center on AWS. It assumes you're already familiar with the application you are installing – either Jira Software or Jira Service Desk.

This deployment's application nodes will have Amazon Linux 2 installed. In order to maintain this deployment, you'll need to be familiar with:
  • how to manage Linux servers, and
  • how to navigate through AWS resources through their UI.

1.6 What this deployment will entail

We provide you with a reference architecture that we use as a base for most enterprise-scale organizations. This reference architecture contains a brief explanation of each component, so you'll have an idea of what to expect.

Then, we'll explain how to assess your own organization's size (or load profile), and choose the right settings to tweak it to your preferences. From there, we'll show you how to apply those settings on an AWS deployment using our fully supported AWS Quick Start. The Quick Start has access to more parameters you can customize, but we don't cover them in detail here.


back to What you need to know

2. Reference architecture

The following diagram illustrates the basic architecture of what you'll be deploying through the Quick Start: 

2.1 Bastion host

This host enables secure access to Jira Data Center without exposing it to the internet. For more information, see Bastion Hosts.

2.2 Amazon Application Load Balancer

When deploying Jira on AWS, you'll need to use an Application Load Balancer (ALB). The Quick Start configures the ALB as a load balancer and SSL-terminating reverse proxy. 

2.3 Atlassian Standard Infrastructure

The AWS Quick Starts for Jira, Confluence, and Bitbucket all use the Atlassian Standard Infrastructure (ASI). The ASI is a highly available, secure virtual private cloud (VPC) specifically customized to host Atlassian Data Center products on AWS. The ASI contains basic networking components required by Jira Data Center, and makes it easier to integrate multiple Atlassian Data Center products under a shared infrastructure. The following diagram shows the different components set up by the ASI:

2.4 Clustered application deployment

One of the key components of a Jira Data Center infrastructure is a clustered application deployment. Clustering provides your Jira application with better performance and high availability.

Installing Jira Data Center lays out all the clustering requirements of Jira. The AWS Quick Start for Jira Data Center simplifies the configuration of your cluster, allowing you to simply choose what nodes to use and setting up the rest as needed. 

2.5 Highly available database

The Quick Start you'll be using will allow you to deploy Jira Data Center with either of two supported databases: Amazon RDS for PostgreSQL (default) or Amazon Aurora Features: PostgreSQL-Compatible Edition. You can configure either one with high availability using its own built-in failover features.

2.6 Amazon Elastic File System (EFS)

Jira Data Center uses a shared file system to store artifacts like attachments, avatars, icons, import/export files, and plugins in a common location accessible to all Jira nodes. The Quick Start architecture implements the shared file system by using the highly available Amazon Elastic File System (Amazon EFS) service.

2.7 Amazon CloudWatch

The Quick Start can also provide you with node monitoring through Amazon CloudWatch. This will allow you to track each node's CPU, disk, and network activity, all from a pre-configured CloudWatch dashboard. The dashboard will be configured to display the latest log output, and you can customize the dashboard later on with additional monitoring and metrics.

By default, Amazon CloudWatch will also collect and store logs from each node into a single, central source. This centralized logging allows you to search and analyze your deployment's log data more easily and effectively. See Analyzing Log Data with CloudWatch Logs Insights and Search Log Data Using Filter Patterns for more information.

Amazon CloudWatch provides basic logging and monitoring, but also costs extra. To help reduce the cost of your deployment, you can disable logging or turn off Amazon CloudWatch integration during deployment.

tip/resting Created with Sketch.

To download your log data (for example, to archive it or analyze it outside of AWS), you’ll have to export it first to S3. From there, you can download it. See Exporting Log Data to Amazon S3 for details.

back to Reference architecture

3. Choosing the right settings for your deployment

The Quick Start simplifies the deployment process by choosing the right settings for most of your infrastructure components. The following sub-sections will guide you through configuring the settings that will help tweak it to fit your organization's size. It's best to decide now what settings to use, as this will help streamline the deployment process.

3.1 Database engine

The Quick Start allows you to choose between the following two supported databases, both of which also feature high availability:

  • Amazon RDS for PostgreSQL (default): you can deploy this as a primary database instance replicating to a standby instance hosted in a different AZ. Should the primary database instance fail, Amazon RDS will perform an automatic failover to the replica. For related information about high availability with Amazon RDS, see Multi-AZ Deployments.
  • Amazon Aurora Features: PostgreSQL-Compatible Edition: like Amazon RDS, you can have a primary database instance (a "writer" node) replicating to a standby (a "reader" node) in a different AZ. However, you can improve your database's reliability by increasing the number of reader nodes. 

Either database will be deployed with a configuration fully supported by Atlassian. You'll need to enable Multi-AZ deployment to enable high availability.

3.2 Application and database nodes

Infrastructure recommendations for enterprise Jira instances on AWS lays out the recommended node configurations (instance type and number) to use for the application and database. These recommendations are based on robust performance tests we ran for different Jira Data Center load profiles

Jira Data Center deployments of enterprise-scale organizations are typically Large or XLarge. Refer to the values in the following table to see which one is more representative of your organization:



XLarge (special data set)

Custom Fields800to1,8001,513
Permission Schemes100to400100
Issue Security Schemes200to8004

XLarge special data set

At present, our Jira Data Center load profiles don't have official ranges for XLarge. We used a special data set  in Infrastructure recommendations for enterprise Jira instances on AWS as a stand-in for XLarge. This data set represents most customer and test instances we've seen that represent what XLarge would be.

After finding out whether you're Large or XLarge, note the type of node configuration you'll need for your infrastructure. Each node configuration offers different benefits, and in our own internal tests they all performed with an Apdex of 0.7 or above. This is the same target Apdex we use when assessing and managing the performance of our own Jira Data Center deployments within Atlassian.

Test-based recommendations

Some of the recommendations we provide here are based on test results, and are useful as a baseline for the node configuration you'll need. Your own performance results depend on many factors such as 3rd-party apps, data, traffic, or instance type. Hence, the target Apdex we use might not be replicable for your environment. Read through our test methodology if you want to understand the basis for these recommended configurations. 

3.2.1 Large

Node configurationApplication nodesDatabase node
Performance/Stabilityc4.8xlarge x 3db.m5.4xlargedb.r5.4xlarge
Low costc4.8xlarge x 2

Our test results for Jira Data Center 8.5 show that having powerful hardware with fewer nodes will provide the most optimal performance. The instance type used - c4.8xlarge - has 36 CPUs and 60 GB of RAM. Having 2 or 3 nodes of this type ensures good performance at a reasonable cost. The main difference between both is fault tolerance and cost.

3.2.2 XLarge

Node configurationApplication nodesDatabase node
Performance/Stabilityc5.9xlarge x 6db.m5.4xlargedb.r5.4xlarge
Low costc5.4xlarge x 6

With the difference in application node types used here, you'll need to choose carefully with XLarge. The Performance/Stability configuration offers roughly 11% better performance than the Low cost one. However, the Low cost configuration costs 57% less. 

3.3 HTTPS setup

For added security, we strongly recommend that you enable HTTPS. The Quick Start simplifies this process by just asking you for a valid certificate. You have two options for getting a certificate:

Option 1: You can request a certificate directly from AWS. When you do, it'll be imported directly into AWS Certificate Manager. Refer to the following resources for instructions:

Option 2: Alternatively, you can obtain a valid certificate issued by a trusted Certificate Authority. Once you have a certificate, you'll need to import it into AWS Certificate Manager.

3.4 Check app compatibility

By default, the Quick Start deploys Jira Data Center 8.5 (the latest Long Term Support release version). You need to check if apps you want to install are compatible with your chosen version. 

back to Choosing the right settings for your deployment

4. Using the AWS Quick Start for Jira Data Center

This section will guide you through an end-to-end deployment. This involves deploying a new ASI, and then deploying Jira Data Center into it. This ASI can serve as the foundational network stack for all other Atlassian Data Center products, should you also choose to deploy them (and integrate with Jira).

Quick Start Guide

The following steps are taken from Jira Data Center on the AWS Cloud Quick Start Reference Deployment. We streamlined the steps to help make it easier for you.

Step 1: Choose an AWS Region

You'll need to choose a region that supports Amazon Elastic File System (EFS). These regions are:

  • Americas
    • Northern Virginia
    • Ohio
    • Oregon
    • Northern California
    • Montreal
  • Europe/Middle East/Africa
    • Ireland
    • Frankfurt
    • London
    • Paris
  • Asia Pacific
    • Singapore
    • Tokyo
    • Sydney
    • Seoul
    • Mumbai

This list was last updated on .

The services offered in each region change from time to time. If your preferred region isn't on this list, check the Regional Product Services table in the AWS documentation to see if it already supports EFS. 

AWS GovCloud is not for production

Our Quick Starts are also available on AWS GovCloud regions, but only for testing purposes. We do not support any deployments on GovCloud regions resulting from this Quick Start. 

Step 2: Prepare your AWS account

Once you've chosen an AWS Region for your deployment, you'll need to prepare your AWS accordingly:

  1. If you don’t already have an AWS account, create one at by following the on-screen instructions.
  2. Use the region selector in the navigation bar to choose the AWS Region where you want to deploy. 
  3. (Optional) If you plan to provision a Bastion host, create a key pair in your preferred region.

If necessary, request a service limit increase for the EC2 t3.medium instance type. You might need to do this if you already have an existing deployment that uses this instance type, and you think you might exceed the default limit with this reference deployment.

Step 3: Import an SSL certificate

You'll need an SSL certificate to enable HTTPS, which will help secure your deployment. If you requested a certificate directly from AWS, it'll already be imported in AWS Certificate Manager.

If you obtained a valid certificate issued by a trusted Certificate Authority, you'll need to import it using the AWS Management Console:

  1. Open the AWS Certificate Manager (ACM).

  2. Choose Import a certificate.

  3. Do the following:

    1. For Certificate body, paste the PEM-encoded certificate to import.

    2. For Certificate private key, paste the PEM-encoded, unencrypted private key that matches the certificate's public key.


      Currently, Services Integrated with AWS Certificate Manager support only the RSA_1024 and RSA_2048 algorithms.

    3. (Optional) For Certificate chain, paste the PEM-encoded certificate chain.

  4. Choose Review and import.

  5. Review the information about your certificate, then choose Import.

From the AWS Certificate Manager, you can get the Amazon Resource Name (ARN) of your certificate. You'll use this later on in Step 5: Customize your deployment.

Step 4: Launch the Quick Start

You are responsible for the cost of the AWS services used while running this Quick Start reference deployment. For full details, see the pricing pages for each AWS service you will be using in this Quick Start. Prices are subject to change.

Log in to your AWS account and click here to launch the Quick Start. An end-to-end deployment (that is, deploying with a new ASI) should take around 40 minutes.

The fastest way to launch the Quick Start is directly from its AWS S3 bucket. However, when you do, any updates we make to the Quick Start templates will propagate directly to your deployment. These updates sometimes involve adding or removing parameters from the templates. This could introduce unexpected (and possibly breaking) changes to your deployment.

For production environments, we recommend that you copy the Quick Start templates into your own S3 bucket. Then, launch them directly from there. Doing this gives you control over when to propagate Quick Start updates to your deployment.

  1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

    git clone --recurse-submodules

  2. (Optional) The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:

    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-jira-dc-with-vpc.template.yaml 
    └── quickstart-jira-dc.template.yaml

  3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

  4. Create an S3 bucket in your region:

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

    • quickstart-jira-dc-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

    • quickstart-jira-dc.template.yaml: use this for deploying into an existing ASI.

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

  2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

    aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read

  3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation → Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

Step 5: Customize your deployment

On the Specify Details page, change the stack name if needed. Review the parameters for the template and customize the deployment.

Use the Jira Product drop-down to choose what to install: 

  • Jira Core (Core)
  • Jira Software (Software)
  • Jira Service Desk (ServiceDesk)

The first parameter to set is which product version to use (JiraVersion). 

By default, the Quick Start installs the latest Long Term Support release version. These releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Long Term Support releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

However, if you are planning to migrate data from an existing deployment, use its version instead. This helps avoid any risks that could result in inconsistencies or data loss. You can always upgrade later on after you've completed the migration process.

The default version is the Long Term Support release for Jira Cora and Jira Software. Jira Service Desk uses different version numbers. Refer to Jira applications compatibility matrix for the right Jira Service Desk version.

The following table describes the other options that will allow you to implement the choices you made earlier in Choosing the right settings for your deployment:

Cluster Nodes
Parameter label (name)DefaultDescription
Enable CloudWatch integration (CloudWatchIntegration)Metrics and LogsSets the level of monitoring that Amazon CloudWatch should do. By default, Amazon CloudWatch will perform basic monitoring and centralized logging. If cost is an issue, choose Metrics Only (disable centralized logging) or Off (disable Amazon CloudWatch altogether).  
Cluster node instance type
t3.mediumChoose the application node type that matches your size and preferred node configuration in Application and database nodes. For example, if you prefer Performance/Stability for Large, choose c4.8xlarge.
Maximum number of cluster nodes

Both of these parameters default to 1. Do not change this default, even if the Application and database nodes recommends a specific number of nodes. You'll need to deploy with one one application node, and then scale it up later after configuring Jira Data Center.
Minimum number of cluster nodes
Parameter label (name)DefaultDescription
Database engine (DBEngine)PostgreSQLYou can choose between the default Amazon RDS database or Amazon Aurora.
Database instance class (DBInstanceClass)db.t2.mediumChoose the database node type that matches your size and preferred node configuration in Application and database nodes. For example, if you prefer Performance/Stability for Large, choose db.m4.4xlarge (for Amazon RDS) or db.r4.4xlarge (for Amazon Aurora).
Master (admin) password 
N/AThe password for the master (postgres) account. This password should be 8-128 alphanumeric characters and include uppercase letters, lowercase letters, numbers, and at least 1 symbol (excluding /, @, &, ",').
Enable RDS Multi-AZ deployment
TrueBy default, high availability features for your chosen database will be enabled. Do not change this setting.
Application user database password 
N/AThe password for the database user account. This password should be 8-128 alphanumeric characters and include uppercase letters, lowercase letters, numbers, and at least 1 symbol (excluding /, @, &, ",').
Bastion host provisioning
Parameter label (name)DefaultDescription
Use/Deploy Bastion host  (BastionHostRequired) true

Depending on which template you choose, this controls whether to provision a Bastion host or use an existing one.

Set this to false you prefer to access your nodes through the  AWS Systems Manager Sessions Manager. If you leave this as true, you'll need to provide a KeyPairName.

Parameter label (name)DefaultDescription
SSL certificate ARN (SSLCertificateARN)N/A

Enter the Amazon Resource Name (ARN) of the certificate from Step 2: Import an SSL certificate. This will enable SSL on your deployment, using your certificate to secure connections.

Availability Zones (AvailabilityZones)N/AThe list of Availability Zones to use for the subnets in the ASI. The Quick Start uses two Availability Zones from your list and preserves the logical order you specify.
Permitted IP range (CidrBlock)N/AEnter the CIDR IP range that should be permitted access Atlassian services. We recommend that you set this value to a trusted IP range. For example, you might want to grant only your corporate network access to the software. 
SSH Key Pair name (KeyPairName)N/A

Choose the key pair you created in Step 2: Prepare your AWS account. This public/private key pair will allow you to connect to your nodes via the Bastion host.

DNS (Optional)
Parameter label (name)DefaultDescription
Existing DNS Name (CustomDnsName)N/AFor public-facing Jira deployments, use a proper domain name. You'll need to register this domain name through a third-party service.
Application tuning
Parameter label (name)DefaultDescription
JVM Heap Size Override
N/ASet this to 8g. This is the same heap size used in the tests that form the basis for our recommendations.

On the Options page, you can specify tags (key-value pairs) for resources in your stack and set advanced options. When you’re done, choose Next.
  1. On the Review page, review and confirm the template settings. Under Capabilities, check the following options:
    • I acknowledge that AWS CloudFormation might create IAM resources with custom names.
    • I acknowledge that AWS CloudFormation might require the following capability: CAPABILITY_AUTO_EXPAND
  2. Choose Create to deploy the stack.
  3. Monitor the status of the stack. When the status is CREATE_COMPLETE, your deployment is ready for configuration.
  4. Use the URLs displayed in the Outputs tab for the stack to view the resources that were created.

Step 5: Configure Jira Data Center

The Quick Start deploys Jira Data Center with a single application node (Auto Scaling group of min=1 and max=1).

  1. Choose the URL displayed in the Outputs tab of the AWS CloudFormation stack to go to the Jira setup screen. If you get an HTTP Error 503 response when you access the URL, it means that Jira Data Center is still loading. This is normal, and you should wait 2-3 minutes before trying again.
  2. On the Setup application properties page, enter a title for your Jira application deployment and choose the Mode you want. The Base URL field should already have the domain name you used earlier in Existing DNS Name. Choose Next.

  3. On the Specify your license key page, enter a valid Jira Software or Service Desk Data Center license key. If you don’t have a valid license for the Jira application you’ve selected to deploy, choose generate a Jira trial license and sign up for an evaluation Data Center license.

  4. To set up the Jira application, you need to create an Administrator account and password. The Administrator account has full access to all data in Jira, so we highly recommend that you choose a strong password for this account. Enter the Administrator’s user details in the setup screen, and then choose Next.

  5. On the Set up email notifications page, choose Later, and then choose Finish.

  6. In the first Welcome to Jira page, choose a language and then choose Continue.

  7. In the second Welcome to Jira page, choose an avatar for your profile, if you wish, and then choose Next.

  8. On the Welcome page, choose Create sample project, and enter a name for the project.
  9. Choose Settings (the gear icon in the upper right), and then choose System

  10. Scroll down to the Cluster nodes section. You should see your current node in the Active state.

Your Jira deployment is now in a state where you can add nodes that will automatically cluster with your existing node.

back to Using the AWS Quick Start for Jira Data Center

5. Scaling up your deployment

After fully deploying Jira Data Center, you can now scale it up. This involves increasing the number of nodes used by the application cluster. At present, it only has one node. The following steps will walk you through scaling it up to your chosen configuration in Application and database nodes.

  1. Sign in to the AWS Management Console, use the region selector in the navigation bar to choose the AWS Region for your deployment, and open the AWS CloudFormation console at
  2. Click the Stack name of your deployment. This will display your deployment's Stack info. From there, click Update.
  3. On the Select Template page, leave Use current template selected, and then choose Next.
  4. On the Specify Details page, go to the Cluster nodes section of Parameters. From there, set your desired number of application nodes in the following parameters:
    1. Minimum number of cluster nodes
    2. Maximum number of cluster nodes
  5.  Click through to update the stack.

After the stack update finishes, you should now have a static number of cluster nodes. Confirm that the additional nodes have formed a cluster by viewing the Cluster nodes section of the System info page in Jira.

Disabled Auto Scaling

Since your cluster has the same minimum and maximum number of nodes, Auto Scaling is effectively disabled.

Setting different values for the minimum and maximum number of cluster nodes enables Auto Scaling. This dynamically scale the size of your cluster based on system load.

However, we recommend that you keep Auto Scaling disabled. At present, Auto Scaling can't effectively address sudden spikes in your deployment's system load. This means that you'll have to manually re-scale your cluster depending on the load.

back to Scaling up your deployment

6. Enhancing and securing your deployment

After scaling your deployment to the right size, you can now install any apps you need to enhance Jira's functionality. This is also a good time to further secure your deployment – right before you let users start accessing it.

6.1 Installing apps

Use the Universal Plugin Manager to install apps on your new deployment. If you are connected to the Atlassian Marketplace website from Confluence's administration console, you can install apps using the Install button from the Find new add-ons or Find new apps administration page. This single-click installation method is the quickest way to install apps, although it's not the only way. 

For alternative methods of installing apps, see Installing Marketplace apps. Refer to Using the Universal Plugin Manager for more related information.

6.2 Improving security

By importing an SSL certificate and enabling SSL, you've taken the first step in securing connections to your deployment. For more information about enhancing your deployment's security, see How to configure Jira server applications for Security Best Practices.

For a more detailed list of security resources, see Server optimization. In particular, we recommend that you read and understand the following:

We also recommend that you enable Single Sign-On (SSO) via Crowd. SSO offers a great balance between security, manageability, and convenience. 

back to Enhancing and securing your deployment

7. Maintaining your infrastructure

AWS allows you to maintain most of your infrastructure through two services:

Refer to the AWS documentation on both services for more details.

7.1 Connecting to your nodes via SSH

You can perform node-level configuration or maintenance tasks on your deployment through the AWS Systems Manager Sessions Manager. This browser-based terminal lets you access your nodes without any SSH Keys or a Bastion host. For more information, see Getting started with Session Manager.

Access via Bastion host

You can also access your nodes via a Bastion host (if you deployed one). To do this, you'll need your SSH private key file (the PEM file you specified for the Key Name parameter). Remember, this key can access all nodes in your deployment, so keep this key in a safe place.

The Bastion host acts as your "jump box" to any instance in your deployment's internal subnets. That is, access the Bastion host first, and from there access any instance in your deployment. 

The Bastion host's public IP is the BastionPubIp output of your deployment's ATL-BastionStack stack. This stack is nested in your deployment's Atlassian Standard Infrastructure (ASI). To access the Bastion host, use ec2-user as the user name, for example:

ssh -i keyfile.pem ec2-user@<BastionPubIp>

The ec2-user has sudo access. SSH access is by root is not allowed.

The keyfile.pem private key should be the same one you created earlier in Step 2: Prepare your AWS account of Using the AWS Quick Start for Jira Data Center.

7.2 Backing up and restoring

The Backing up data and Restoring data pages explain the backup and restoration process, along with our recommendations for each.

7.3 Migrating from an existing Jira deployment

To migrate an existing instance into AWS:

  1. Migrate its database to PostgreSQL (if not already).
  2. Take a backup of your existing home directory and database.
  3. Copy the backup file to your file server EC2 instance.
  4. Unpack the backup file under /media/atl/jira/shared of your file server.
  5. Restore the PostgreSQL database dump contained in the backup file to your RDS instance with pg_restore.

7.4 Upgrading

Before you begin, consider upgrading to an Atlassian Long Term Support releases (if you're not on one already). Long Term Support releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Long Term Support releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

Here's some useful advice for upgrading your deployment:

  1. Before upgrading to a later version of Jira Data Center, check if your apps are compatible with that version. Update your apps if needed. For more information about managing apps, see Using the Universal Plugin Manager.
  2. If you need to keep Jira Data Center available to users during your upgrade, we recommend upgrading Jira Data Center with zero downtime. This method allows your nodes to work on different Jira versions while you upgrade them one by one. During the upgrade, Jira remains available to users.
  3. We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. Creating a test environment for Jira provides helpful tips on doing so.

For detailed instructions (including how to upgrade Jira Data Center with zero downtime), see Upgrading Jira Data Center on AWS. For more information about zero-downtime upgrades (outside of AWS), see Upgrading Jira Data Center with zero downtime.

7.5 Monitoring

Monitoring is crucial in maintaining the integrity and continued optimal operation of your deployment. Tracking its health helps you prepare for usage growth or re-configuration. Jira Data Center sample deployment and monitoring strategy explains how we monitor one of our own production deployments. 

If you enabled Amazon CloudWatch, you'll already have centralized logging and basic node monitoring. Centralized logging allows you to analyze your deployment's log data more easily and effectively

As of Jira 8.4, we also introduced a number of monitors you can use to analyze bottlenecks and set alerts for specific events. See Jira Data Center monitoring to learn more.

7.6 Re-scaling your infrastructure

Your new deployment's application node cluster uses Auto Scaling Groups, but only to statically control the number of its nodes. We don't recommend that you use Auto Scaling to dynamically scale the size of your cluster. Adding an application node to the cluster usually takes over 20 minutes, which isn't fast enough to address sudden load spikes. Rather, you should regularly monitor the performance of your deployment and manually re-scale your application node cluster as needed. 

If you can identify any periods of high and low load, you can schedule the application node cluster to scale accordingly. See Scheduled Scaling for Amazon EC2 Auto Scaling for more information. 

back to Maintaining your infrastructure

8. Atlassian Enterprise Support

Over time, we may change our recommendations depending on new tests, insights, or improvements in Confluence Data Center. Contact an Atlassian Technical Account Manager for more guidance on choosing the right configuration for your Data Center deployment.

Our Premier Support team performs health checks by meticulously analyzing your deployment and logs to ensure that your infrastructure configuration is suitable for your Data Center application. If the health check process reveals any gaps or areas of improvement, Premier Support will recommend possible changes.

Last modified on Jun 27, 2022

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.