Skip to main content

Size XL - Sonatype Nexus Repository - AWS Cloud-Native Reference Architecture

This Nexus Repository extra-large reference architecture describes the minimum requirements for an enterprise-scale high-availability Nexus Repository cluster in AWS with a baseline request load of 15,000 requests per second (900,000 requests per minute). It has been validated to support this volume in a steady state and to handle spikes of 50,000 requests per second without failing.

This architecture is designed for global enterprises and very large development organizations that require extreme-scale throughput, advanced high availability, and strong operational resilience.

Infrastructure Specifications

This Nexus Repository reference architecture defines an enterprise-scale clustered Nexus Repository deployment supported by shared infrastructure services. The architecture includes the following layers:

  • Compute Layer – Nexus Repository clustered application runtime

  • Database Layer – Highly available PostgreSQL database

  • Storage Layer – Optimized shared object storage for blob data

  • Network Layer – Load balancing and cluster connectivity

Diagram of a Sonatype Nexus Repository AWS reference architecture for a size XL deployment supporting 15,000 requests per second with spikes up to 50,000 rps. Dev and CI/CD tools connect through an Application Load Balancer to a Nexus Repository cluster r

Compute Layer (Nexus Repository)

The compute layer comprises the Nexus Repository application cluster, which processes repository requests across multiple high-capacity nodes.

This layer meets the following specifications:

Four Nexus Repository nodes:

  • 48 vCPU per node

  • 192 GiB RAM per node

Cluster capacity:

  • 192 total vCPU

  • 768 GiB total RAM across the cluster

JVM configuration (per node):

  • Xms=96G

  • Xmx=96G

  • MaxDirectMemorySize=48G

Example AWS instance types:

  • m8g.12xlarge

  • m7g.12xlarge

Each node participates in the Nexus Repository cluster and connects to shared database and storage services. Local storage is used for operational data and temporary files.

Recommended local storage configuration per node:

  • Local NVMe SSD

  • Approximately 500 GB

  • Minimum 3000 IOPS

Recommended network configuration per node:

  • ≥25 Gbps network bandwidth per node

  • Higher bandwidth if artifact downloads are not offloaded through object storage

Database Layer (PostgreSQL HA)

This architecture uses a highly available PostgreSQL database cluster. This configuration removes the database as a single point of failure and provides automatic failover capability.

This layer meets the following specifications:

  • PostgreSQL high-availability deployment

  • One primary writer node

  • One reader node for failover

Example AWS deployment:

  • AWS RDS PostgreSQL or Aurora PostgreSQL

  • Size: db.r8g.8xlarge

  • 32 vCPU

  • 128 GiB RAM

Database connection pool sizing:

  • ~800–1,200 connections per node

  • ~3,200–4,800 total connections across cluster

Storage Layer (Shared Object Storage)

The storage layer for this architecture must meet the following requirements:

  • Object storage must be accessible to all repository instances

  • Shared storage is required to ensure all instances can access the same artifact data

  • Use separate blob stores per repository or repository group using distinct S3 prefixes. This helps avoid object storage throughput limits.

Deployments at this scale should also use the following best practices:

  • Leverage the pre-signed URL feature so that artifact downloads are served directly from S3 rather than passing through the Nexus Repository node.

  • For extremely high-throughput environments, organizations may choose to use multiple S3 buckets to distribute storage traffic across object storage infrastructure.

Network and Security

This architecture requires an Application Load Balancer (ALB) to distribute repository traffic across the cluster nodes.

Apply standard network security practices, including the following:

  • Restrict inbound access to the repository service ports

  • Secure administrative access to the host instance

  • Isolate repository infrastructure within a controlled network environment

Limitations

  • This architecture is designed for a single-region deployment and does not provide multi-region failover.

  • You must enable rolling upgrades on each Nexus Repository node in order to upgrade your Nexus Repository version without downtime.

  • Enterprise-scale deployments require additional infrastructure tuning, including increased database and object storage connection pools.

Deploying this Architecture

You can quickly deploy this reference architecture using Sonatype's Nexus Repository Terraform configuration for an AWS deployments. This automates the creation and configuration of all required AWS resources, including networking, compute, storage, and security components.

For full deployment details, see the README that accompanies the provided Terraform.