What does the Atlassian Cloud platform architecture look like?

Atlassian uses the industry-leading Cloud provider AWS for its hosting architecture. Thanks to Atlassian’s system of data residency, you can choose where in the world your in-scope project data is stored. The Snapshot feature of Amazon RDS (Relational Database Service), is used to create automated daily backups. This is because the core principles of the Atlassian Cloud are security and reliability.

Common platform features are used by multiple Atlassian products, as shown in the following diagram:

These services are offered via a multi-tenant microservice architecture called Micros, an internally developed Platform-as-a-Service (PaaS).

Each Atlassian product, such as Jira and Confluence, consists of multiple “containerized” services that are centrally managed through common platform capabilities.

Multi-tenant architecture

In addition to Cloud infrastructure, Atlassian uses a multi-tenant architecture. Here, a single service hosts multiple clients, including databases and compute instances needed to run the Cloud products. Atlassian does not have a system where each customer has its own infrastructure.

Consequently, a container/tenant can store data for multiple clients. The Jira of an insurance company, for example, can be right next to the Jira of a small business. But this data is strictly isolated and inaccessible to third parties due to Atlassian’s encryption.

Each microservice has its own data storage and can only be accessed using the authentication protocol for that particular service. If a microservice is compromised, you have limited access to the data required by that particular service.

Tenant provisioning and lifecycle

When a new client is added, a series of events triggers the orchestration of distributed services and the provisioning of data stores. Microservices are granted minimal privileges to reduce the risk of security breaches.

Atlassian’s data lifecycle can be divided into seven steps

1. Trading systems are immediately updated with the client’s latest metadata and access control information. Triggers for this action are:
   1. Creation of a new client
   2. Deletion of a client
   3. Activation of products
   4. Deactivation of products
   5. Suspension of a product
   6. Unlocking a product
   7. License update
2. Creation as well as updating of the customer page and the correct product group
3. Providing apps and products
   1. Most of the content is hosted near where the customers are located. You can also choose data residency.
4. Creation and storage of core metadata
5. Creation and storage of website and product identity data
6. Provision of product databases within a website
7. Deploying the apps licensed for the product(s)

The following illustration shows how the website is provisioned for a customer in the distributed architecture rather than in a single store:

Tenant separation

Atlassian, as mentioned earlier, has taken steps to ensure that customer data remains separate from that of other customers. They use a “tenant context” to achieve logical isolation of customers. This means that each customer’s data at rest is logically separated from that of other tenants, and that all requests being processed have a tenant-specific view so that other tenants are not affected. This concept is what Atlassian calls Tenant Context Service (TCS).

Here, the data for a tenant is stored centrally in a context, which is associated with a unique ID. When a client wants to access their data in Jira or Confluence Cloud, the TCS uses the tenant ID so that data is collected and linked.

Atlassian Edges

Edge refers to a system developed by Atlassian, virtual walls built around the software. When a request comes in, it lands on the edge closest to the user. Atlassian’s Edge verifies that the request is legitimate, checks the user’s identity, and forwards the request to the target region based on TCS information. The node uses the client configuration system to gather needed information and invokes data stores and services. The request also includes information from previous invocations.

Read more in Atlassian’s guide to Cloud architecture.