Running Confluence Data Center in AWS
Confluence Data Center is an excellent fit for the Amazon Web Services (AWS) environment. Not only does AWS allow you to scale your deployment elastically by resizing and quickly launching additional nodes, it also provides a number of managed services that work out of the box with Confluence Data Center instances and handle all their configuration and maintenance automatically.
On this page:
Deploying Confluence Data Center using the AWS Quick Start
The simplest way to deploy your entire Data Center cluster in AWS is by using the Quick Start. The Quick Start launches, configures, and runs the AWS compute, network, storage, and other services required to deploy a specific workload on AWS, using AWS best practices for security and availability.
Here's an overview of the architecture for the Confluence Data Center Quick Start:
The deployment consists of the following components:
- One or more Amazon Elastic Compute Cloud (EC2) instances as cluster nodes, running Confluence, in an auto scaling group.
- One or more Amazon Elastic Compute Cloud (EC2) instances as cluster notes, running Synchrony (which is required for collaborative editing), in an auto scaling group.
- An Amazon Application Load Balancer (ALB), both as load balancer and SSL-terminating reverse proxy.
- Amazon Elastic File System (EFS) server for the shared home directory which contains attachments and other files accessible to all Confluence nodes.
- An Amazon Relational Database (RDS) PostgreSQL instance as the shared database.
For more information on the architecture, components and deployment process, see our Quick Start Guide.
EC2 sizing recommendations
The Quick Start uses c3.xlarge instances by default for Confluence and Synchrony nodes. The instance type is up to you, but it must meet Confluence's system requirements. Smaller instance types (micro, small, medium) are generally not adequate for running Confluence.
Supported AWS regions
Not all regions offer the services required to run Confluence. You'll need to choose a region that supports Amazon Elastic File System (EFS). You can currently deploy Confluence using the Quick Start in the following regions:
- Asia Pacific (Sydney)
- EU (Frankfurt)
- EU (Ireland)
- US East (North Virginia)
- US West (Oregon)
The services offered in each region change from time to time, so check the Regional Product Services table in the AWS documentation to see if your preferred region is supported yet.
Scaling up and down
To increase or decrease the number of Confluence or Synchrony cluster nodes:
- Go to Services > CloudFormation in the AWS console, select the stack, and click Update Stack.
- Change the Minimum number of cluster nodes and Maximum number of cluster nodes parameters as desired.
It may take several minutes for the Auto Scaling Group to detect and apply changes to these parameters.
Unless you specify the same number for Minimum and Maximum number of cluster nodes, the Auto Scaling Group will launch new cluster nodes and terminate existing ones automatically to achieve the optimal desired number of nodes between these two limits. By default, this target number is determined by the following CloudWatch metrics:
- If the average CPU utilization across the Auto Scaling Group exceeds 60% for 5 minutes, the target number of nodes increases by one (up to the Maximum).
- If the average CPU utilization across the Auto Scaling Group is lower than 40% for 30 minutes, the target number of nodes decreases by one (down to the Minimum).
A default "cooldown" period of 10 minutes between scaling events is also applied. See Scaling Based on Metrics for more information.
Note: Adding new cluster nodes, especially automatically in response to load spikes, is a great way to increase capacity of a cluster temporarily. Beyond a certain point, adding large numbers of cluster nodes will bring diminishing returns. In general, increasing the size of each node (i.e., "vertical" scaling) will be able to handle a greater sustained capacity than increasing the number of nodes (i.e., "horizontal" scaling), especially if the nodes themselves are small.
See the AWS documentation for more information on auto scaling groups.
Connecting to your nodes over SSH
It is possible to SSH to your cluster nodes and file server to perform configuration or maintenance tasks. Note that you must keep your SSH private key file (the PEM file you downloaded from Amazon and specified as the Key Name parameter) in a safe place. This is the key to all the nodes in your instance, and if you lose it you may find yourself locked out.
Note: the ConfluenceDataCenter.template deploys all EC2 instances in the Subnets specified by the Internal subnets parameter. If you have specified Internal subnets that are completely unreachable from outside, then you may need to launch an EC2 instance with SSH running and accessible in one of the the External subnets, and use this as a "jump box" to SSH to any instances in your Internal subnets. That is, you SSH first to your "jump box", and from there to any instance deployed in the Internal subnets.
When connecting to your instance over SSH, use ec2-user as the user name, for example:
ssh -i keyfile.pem ec2-user@ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com
The ec2-user has sudo access. SSH access is by root is not allowed.
Upgrading
To upgrade a Confluence Data Center instance launched from ConfluenceDataCenter.template:
- In the AWS console, Update Stack
- Change the size of the Confluence and Synchrony auto scaling groups (maximum and minimum) to 0. This will terminate all running nodes.
- Once the update is complete, check that all EC2 nodes have been terminated.
- In the AWS console, Update Stack.
- Change the Confluence Version to the version you want to upgrade to.
- Change the size of the Confluence and Synchrony auto scaling groups (maximum and minimum) to 1. Do not add more than one node until after the upgrade is complete.
- Access Confluence in your browser. Any upgrade tasks will run at this point.
- Confirm that Confluence and Synchrony are both running successfully, and that you are running the new version (check the footer).
- In the AWS console, Update Stack.
- Change the maximum Confluence nodes and Maximum Synchrony nodes to your usual auto scaling group size.
- Confirm that your new nodes have joined the cluster.
Confluence Data Center in AWS currently doesn't allow upgrading an instance without some downtime in between the last cluster node of the old version shutting down and the first cluster node on the new version starting up.
You must make sure all existing nodes are terminated before launching new nodes on the new version.
Backing up
We recommend you use the AWS native backup facility, which utilizes snap-shots to back up your Confluence Data Center.
Migrating your existing Confluence site to AWS
To migrate an existing Confluence instance to AWS:
- Upgrade your existing site to the version you have deployed to AWS (Confluence 6.1 or later).
- Migrate your database to PostgreSQL (if you're not already using Postgres). See Migrating to Another Database.
- Back up your PostgreSQL database and your existing
<shared-home>/attachmentsdirectory. - Copy your backup files to
/media/atl/confluence/shared-homein your EC2 instance. - Restore your PostgreSQL database dump to your RDS instance with
pg_restore.
See Importing Data into PostgreSQL on Amazon RDS in Amazon documentation for more information on how to do this.
Notes:
- When you create a cluster using the CloudFormation template, the database name is
confluence. You must maintain this database name when you restore, or there will be problems when new nodes are provisioned. You will need to drop the new database and replace it with your backup. - You don't need to copy indexes or anything from your existing local home or installation directories, just the attachments from your existing shared home directory.
- If you've modified the
<shared-home>/config/cache-settings-overrides.propertiesfile you may want to reapply your changes in your new environment. - The
_copymethod described in this AWS page, Importing Data into PostgreSQL on Amazon RDS, is not suitable for migrating Confluence.