Hosting
...
provider AWS
General Cloud hosting architecture
We use Amazon Web Services (AWS) as a cloud service provider and its highly available data center facilities in multiple regions worldwide. Each AWS region is a separate geographical location with multiple, isolated, and physically-separated groups of data centers known as Availability Zones (AZs).
We leverage utilize AWS compute, storage, network, and data services to build develop our products and platform components, which enables . This allows us to utilize take advantage of the redundancy capabilities offered provided by AWS, such as including availability zones and regions.
Availability zones
Each Availability availability zone is designed to be intentionally isolated from failures in the other zones and to provide inexpensive. It also ensures cost-effective, low-latency network connectivity to other AZs in within the same region. This multi-zone high availability is the first line of defense for serves as the primary defense against geographic and environmental risks and means that , enabling services running in multi-AZ deployments should be able to withstand AZ failure.
Jira and Confluence use utilize the multi-AZ deployment mode for Amazon RDS (Amazon Relational Database Service). In a multi-AZ this deployment, Amazon RDS provisions sets up and maintains a synchronous standby replica in a different AZ within the same region to provide offer redundancy and failover capability. The AZ failover process is automated and typically takes completes within 60-120 seconds, so that allowing database operations can resume as quickly as possible without to quickly resume without requiring administrative intervention.
Data location
Our main region is AWS eu-central-1 in Frankfurt, Germany.
We plan to add more regions later this year. You’ll find more information about the available regions and the scope in our data residency concept.
Data backups
With respect to our cloud products, and specifically Specifically referring to you and your application data, we use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.
Amazon RDS snapshots are retained for 30 days with support for point-in time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups.
Data center security
AWS maintains multiple certifications for the protection of their data centers. These certifications address physical and environmental security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures.
Yasoon Cloud Platform Architecture
Diagram//Services
...
yasoon Cloud platform architecture
| Drawio | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Multi-Tenant Isolation
While our customers share a common cloud-based infrastructure when using our cloud products, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.
Atlassian’s approach to achieving this varies across our applications. In the case of Jira and Confluence Cloud, we use a concept we refer to as the “tenant context” to achieve logical isolation of our customers. This is implemented both in the application code, and managed by something we have built called the tenant context service (TCS). This concept ensures that:
Each customer’s data is kept logically segregated from other tenants when at-rest
Any requests that are processed by Jira or Confluence have a tenant-specific view so other tenants are not impacted
In broad terms, the TCS works by storing a context for individual customer tenants. The context for each tenant is associated with a unique ID stored centrally by the TCS, and includes a range of metadata associated with that tenant, such as which databases the tenant is in, what licenses the tenant has, what features they can access, and a range of other configuration information. When a customer accesses Jira or Confluence cloud, the TCS uses the tenant ID to collate that metadata, which is then linked with any operations the tenant undertakes in the application throughout their session.
Access Security
...
Change Management
While actively embracing a DevOps culture, we maintain highly restricted access to the Cloud infrastructure. Developers are limited to read-only access. The infrastructure is scripted using AWS CDK, and all modifications undergo thorough review and comparison with policies to ensure compliance.
Updates and deployments
The backend Cloud services are updated every morning 9 am CET or as needed with zero downtime.
The user interfaces have mutiple update channels: fast and stable
By default, small customer instances are automatically assigned to the fast update channel that do get updates first. With a week delay, the changes will then get deployed for the stable update channel