How Atlassian improved Jira and Confluence performance on Arm Neoverse-based AWS Graviton
Atlassian migrated over 3,000 Jira and Confluence EC2 instances to AWS Graviton processors, then optimized performance through JVM tuning, cache analysis, and workload-specific strategies, achieving up to 30% throughput gains and 9.8% cost savings.
Video
Video available
The useful question is what changes for users, developers or buyers, and whether the announcement stays industry context or becomes something people can actually use.
Atlassian migrated more than 3,000 EC2 instances running Jira and Confluence to Arm Neoverse-based AWS Graviton processors, initially confirming compatibility before shifting focus to performance optimization under real-world conditions. The team evaluated system behavior, including CPU utilization, memory access patterns, and JVM configuration, to identify bottlenecks and improve latency, throughput, and cost efficiency. AWS-native tools such as Amazon CloudWatch and AWS Compute Optimizer were used alongside profiling to guide infrastructure decisions and right-sizing. Atlassian’s approach emphasized connecting system-level metrics with hardware signals like cache misses and branch mispredictions to inform targeted optimizations.
Performance analysis revealed 25% higher L3 cache misses on Graviton3 compared to Intel, prompting JVM adjustments such as code cache sizing and tiered compilation to better utilize Graviton’s cache. The team also examined TLB behavior and enabled Transparent Huge Pages where appropriate, though they noted potential latency trade-offs requiring validation against specific workloads. These optimizations were part of a broader strategy that separated latency-sensitive from throughput-oriented workloads, using newer Graviton generations for user-facing traffic while older instances supported non-critical tasks. Fallback strategies were implemented to maintain resilience during capacity constraints.
Production validation proved critical, as initial testing for Confluence on Graviton3 showed regressions in major latency percentiles, leading Atlassian to migrate to Graviton4-based c8g instances. The team emphasized defining benchmarks that reflect real user experiences, measuring both steady-state performance and breaking points where latency rises faster than throughput. Profiling before tuning helped identify whether workloads were compute-bound, memory-bound, or latency-sensitive, ensuring optimization efforts targeted actual constraints rather than generic changes.
Atlassian’s migration resulted in 20–30% request-throughput improvements without performance regressions, alongside approximately 9.8% cost savings across the fleet, with some shards achieving over 25% savings. The experience underscored the importance of workload-specific analysis, production-like validation, and operational flexibility, including mixed instance policies and architecture-aware launch templates. AWS Graviton’s custom Neoverse cores and Nitro System provided the foundation, while measurement, tuning, and strategic workload placement delivered additional performance and efficiency gains at scale.