Care about security? We do too. Learn what Atlassian does and what you can do too.
Need to test security settings? Learn how with authentication policies.
Eager to configure? Read on about single sign-on.
Manage password policies for users? Set up two-step verification and idle session duration.
Stay on top of data across your organization with all the reports and tracking options we offer.
Learn about where your cloud product data is hosted and the types of data you can move.
Control how users and apps access your Atlassian cloud products.
Get a behind-the-scenes look from our engineering team about how our cloud architecture is set up, how requests are processed in Jira or Confluence, and how we handle performance and availability.
Single sign-on, multi-tenant architecture
Our cloud architecture relies on shared Atlassian accounts, so that with one Atlassian account, users can log in to Jira products, Confluence, and Bitbucket. Users can log in to all the products they use quickly and easily, and admins get a straightforward way to control how users authenticate to access Atlassian products and which users have access to which content.
The architecture is also multi-tenant, which means a single instance of the software and its supporting infrastructure serves multiple customers. Customers share the software application and a single database, but each tenant's data is isolated and remains inaccessible to other tenants.
This shared structure results in more scalability for larger customers, more availability to smaller customers who wouldn’t be able to afford or support full on-premises setups, and a competitive price point for companies of all sizes.
Making requests in Atlassian cloud products
When a user makes a request from one of our products (e.g. opening a Jira issue or a Confluence page), our request workflow keeps your data secure. Here's a look at that workflow, using a Jira issues as an example:
The user opens a Jira issue, which lands on the Atlassian Edge closest to the user. The edge will verify the user’s session and identity with the Identity systems.
The edge determines where your Jira data is located, based on data in the tenant information service. In some cases, that region may be different from where the request originally occurred.
The edge forwards the request to the target region, where it lands on a Jira compute node.
Jira uses the tenant configuration system to determine information, such as the license and database location, and calls out to various other data stores and services (e.g. the Media platform that hosts images and attachments) to retrieve the information required to service the request.
Jira fulfills the original user request with information assembled from its previous calls to other services.
What is an edge?
At Atlassian, we use the word edge to describe the virtual walls we build around our software. Think of the edge as our castle walls. When a Jira or Confluence request comes in, it comes to the nearest gate and requests to enter. Through a series of validations (do we know who you are? Are you safe and authenticated?), that request is either allowed or denied access.
Global distribution and footprint
Atlassian partners with Amazon Web Services (AWS)—one of the leading Cloud computing services in the world—to deliver SaaS applications around the globe.
Our Jira and Confluence Cloud offerings currently run out of AWS presences in:
The United States (with locations on the east and west coasts)
The European Union (with locations in Dublin and Frankfurt)
Asia-Pacific (with locations in Sydney and Singapore)
Choosing the right region for each customer
When a product is provisioned it will likely have the majority of its content hosted close to where users are accessing it. To optimize product performance, we don’t limit data movement when it’s hosted globally and we may move data between regions as needed.
For some of our products, we also offer data residency. It allows you to choose whether in-scope product data globally distributed or held in place in one of our defined geographic locations. Learn more about data residency
Availability and performance
Our cloud architecture is built for high availability and performance.
In the Atlassian cloud architecture, the computing services required to process a request are decoupled from the data stores where we keep user content. This allows the platform to scale rapidly in the event of increased product usage.
The architecture allows us to make most upgrades with zero downtime. Upgrades that do cause downtime typically take less than 5 minutes (usually performed during a customer’s contracted maintenance window of 1:00 a.m. to 3:00 a.m. in the customer’s time zone).
Ultimately, this means the system is constantly available for Jira and Confluence cloud users.
To achieve high performance in our cloud architecture, Atlassian leverages a number of techniques, including:
Global distribution: Our cloud presence is global, which means we can move customer content closer to end users—optimizing performance for each customer based on their highest traffic location.
Dedicated internal networks: Our systems connect your users to the Atlassian cloud via the private, dedicated internal network nearest to them—even if the content being requested lives in another region. This speeds up connections and keeps the user experience running smoothly.
Content Delivery Networks (CDNs) and caching: Frequently accessed content is automatically cached and a system of distributed servers (a CDN) quickly delivers static assets that are common across all user requests.
Was this helpful?