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

Confluence Data Center supports multi-node clustering, giving you high availability and flexible scalability. You can leverage these features by deploying Confluence Data Center on appropriate infrastructure.

Confluence Data Center comes equipped with AWS Quick Start, but this deployment method is no longer supported or maintained by Atlassian, though it is still usable. Instead, we strongly recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust setup.

AWS Quick Start provided a framework for deploying your infrastructure with recommended pre-set defaults. This framework originally sped up your deployment, as you didn't have to build every piece of your infrastructure from scratch. Rather, you could design your infrastructure around our Quick Start and deploy it quickly on AWS.

This legacy document will serve as a single place to access most of the knowledge resources needed to streamline deployment. Here, we guide you through an end-to-end deployment of Confluence Data Center. 

1.  What you need to know

The AWS Quick Start for Confluence 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 can use in this document to deploy your Confluence 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 Confluence Data Center). In doing so, we also provide recommendations based on our knowledge and experience in managing Confluence Data Center at scale.

The AWS Quick Start for Confluence Data Center comes with its own deployment guide. That guide shows you how to use the Quick Start to deploy Confluence 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 Confluence 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, focusing on making it highly configurable for most types of organizations. We formerly used this Quick Start to deploy and maintain Confluence Data Center for different teams inside Atlassian before switching to Kubernetes. 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 how enterprise-scale organizations can deploy Confluence Data Center and tweak it to suit their needs. We define enterprise-scale organizations as those with Large or XLarge instances (based on our Confluence 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:

• Benchmarks: Infrastructure recommendations for enterprise Confluence 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 Confluence Data Center deployments in production. We do this because Confluence is vital to the work of thousands of Atlassians. In turn, we also get to experience firsthand how to run Confluence Data Center at the enterprise scale. We learn a lot in the process, and many of our recommendations are based on those learnings.

1.5 Prerequisite skills

This document will guide you on deploying Confluence Data Center on AWS. It assumes you're already familiar with Confluence.

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 can deploy through the Quick Start: 

2.1 Bastion host

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

2.2 Amazon Application Load Balancer

When deploying Confluence on AWS, you 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 Confluence 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 Confluence Data Center infrastructure is a clustered application deployment. Clustering provides your Confluence application with better performance and high availability.

Confluence Data Center Technical Overview lays out all the benefits and requirements of clustering for Confluence. The AWS Quick Start for Confluence 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 allows you to deploy Confluence 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)

Confluence 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 Confluence 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

2.8 Synchrony

By default, the Quick Start will deploy Synchrony as managed by Confluence. This allows you to install Synchrony on your application nodes, and Confluence will manage it for you. See Possible Confluence and Synchrony Configurations for more 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 infrastructure components. The following sub-sections guide you through configuring the settings that 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:

3.2  Application and database nodes

Infrastructure recommendations for enterprise Confluence 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 Confluence Data Center load profiles. 

Enterprise-scale organizations are typically Large or XLarge; use the table below to see where your existing instance's size fits based on your metrics:

For extra help on retrieving your existing deployment's metrics and figuring out your overall size, see Confluence Data Center load profiles.

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.8 or above. This is the same target Apdex we use when assessing and managing the performance of our own Confluence deployments within Atlassian.

3.2.1 Large

The Performance option offered the best Apdex among all the configurations we tested. Our benchmarks show that it maintained an Apdex above 0.8 even when it lost one node.

The Stability and Low cost options offer a good balance between price, fault tolerance, and performance. You'll notice that they both use the same virtual machine types – the Stability option just has an additional application node. The Stability option can afford to lose more nodes before going completely offline, but the Low cost option costs less. Any performance difference between the two is negligible. 

3.2.2 XLarge

In our benchmarks, the Stability configuration maintained acceptable performance (that is, Apdex above 0.8) even after losing one application node. At four application nodes, it is more fault tolerant overall than the Low cost configuration.

Both Stability and Low cost configurations are identical except for the number of nodes. Their Apdex scores don't differ much either. The Low cost configuration is fairly fault-tolerant, in that it can afford to lose 3 nodes before the service goes offline. However, our tests show that if the Low cost configuration loses one node, the Apdex dipped below 0.8.

3.3 HTTPS setup

For added security, we strongly recommend that you enable HTTPS. Proxy and HTTPS setup for Confluence outlines the requirements for doing so, but the Quick Start simplifies this process by just asking you for a valid certificate. You have two options for getting a certificate:

3.4 Check app compatibility

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

back to Choosing the right settings for your deployment

4.  Using the AWS Quick Start for Confluence Data Center

This section will guide you through an end-to-end deployment. This involves deploying a new ASI, and then deploying Confluence 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 Confluence).

Step 1: Choose an AWS Region

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

Step 2: Prepare your AWS account

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

Step 3: Import an SSL certificate

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

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.

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.

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

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:

Step 5: Configure Confluence Data Center

The Quick Start deploys Confluence 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 Confluence setup screen. If you get an HTTP Error 503 response when you access the URL, it means that Confluence Data Center is still loading. This is normal, and you should wait 2-3 minutes before trying again.
2. In the Get add-ons page of Confluence setup, choose Next. You can enable add-ons after setup if you wish.
   
   
3. On the License key page, enter a valid Confluence Data Center license, and then choose Next. If you don’t have a valid license for Confluence Data Center, choose Get an evaluation license. You’ll be taken to my.atlassian.com where you can generate an evaluation license. You can’t use a Confluence Server license with this Quick Start.
   
   
   
   
4. On the Load Content page, choose Example Site.
   
   
   
   
5. On the Configure User Management page, choose Manage Users and Groups within Confluence.
   
   
   
   
6. To set up Confluence Data Center, you need to create an administrator account and password. The administrator account has full access to all data in Confluence, so we highly recommend that you choose a strong password for this account. Enter the administrator’s user details, and then choose Next.
   
   
   
   
   

You should now see the Setup Successful page. Choose Further configuration to go directly to the Confluence administration console, and log in with the administrator user account you created in the previous step.

back to Using the AWS Quick Start for Confluence Data Center

5. Scaling up your deployment

After fully deploying your Confluence Data Center and installing the apps you need, 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).  

Open the Confluence administration page of your new deployment. You can access this page using the URL displayed in the Outputs tab of the AWS CloudFormation stack. From there, go to Clustering in the administration console sidebar. You should see a page similar to the following screen, which shows that the node is ready for clustering.

Step 1: Scale the number of application nodes

Start with increasing the number of application nodes (as recommended for your choice in Application 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 https://console.aws.amazon.com/cloudformation/.
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. 

In Confluence Data Center, go to Administration menu , then General Configuration. > General Configuration > Clustering to confirm that the additional nodes have formed a cluster.

Step 2: Enable collaborative editing (if needed)

Confluence Data Center 6.13 enables Collaborative editing by default. However, it's disabled on older versions of Confluence Data Center. If it is, you’ll need to manually enable it.

1. In Confluence Data Center, go to Administration menu , then General Configuration.> General Configuration > Collaborative editing, and verify that it is off. 
   
   
   
   
2. On the Collaborative editing page, choose the Change Mode button, choose On, and then choose Change.
   
   
   
   
3. Verify that collaborative editing is on and that the status of Synchrony is Running.
   
   

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 Confluence'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

6.2 Improving security

By importing an SSL certificate and enabling SSL, you've taken the first step in securing connections to your Confluence Data Center deployment. You can further enhance your deployment's security by following our Best Practices for Configuring Confluence Security.

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

• Connecting to LDAP or Jira applications or Other Services via SSL
• Configuring Secure Administrator Sessions

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

6.3 Migrating from an existing Confluence deployment

If you have an existing Confluence deployment, you can now migrate your users and data across. For more information about the migration process, see Migrating your existing Confluence site to AWS.

back to Enhancing and securing your deployment

7. Maintaining your infrastructure

7.1  Connecting to your nodes via SSH

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

7.2 Backing up and restoring

Refer to the following resources for information on backing up and restoring Confluence Data Center:

• Manually Backing Up the Site
• Restoring a Site
• Restoring Data from other Backups
  

If your organization has other backup tools at your disposal, test them first on your new Confluence Data Center. Some tools may not work well with large data sets. 

7.3 Upgrading

Here's some useful advice for upgrading your deployment:

1. Before upgrading to a later version of Confluence 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 Confluence Data Center running during your upgrade, we recommend using read-only mode for site maintenance.  Your users will be able to view pages, but not create or change them. 
3. We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. Create a staging environment for upgrading Confluence provides helpful tips on doing so.

When the time comes to upgrade your deployment to a later Long Term Support release, perform the following steps:

7.4 Monitoring

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

It's also important to choose tools that can monitor all the parameters you need to track. Focus on building enough data to identify trends: this will be more informative than studying performance snapshots when deciding how to best optimize your application over time. We compiled a list of tools for monitoring your Data Center application. 

7.5  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.

Remember, the AWS Quick Start template used in the preceding deployment steps is no longer supported or maintained by Atlassian. We strongly recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup.