Choosing the right AWS storage backend for Perforce P4 in game development

Game studios running Perforce P4 on Amazon Web Services (AWS) face a critical infrastructure decision: which storage backend to use for their depot volumes. The answer depends on depot size, team scale, and how your studio balances cost against operational complexity.

P4 is widely used in game development because it handles large binary assets (textures, meshes, cinematics, and full engine builds) alongside source code in a single repository. Studios with hundreds of developers syncing multi-gigabyte workspaces generate storage I/O patterns that differ from typical software development. Depot volumes grow into the tens or hundreds of terabytes, sync operations demand sustained sequential throughput, and continuous integration and continuous delivery (CI/CD) build farms create bursty parallel read loads.

In this post, we compare four AWS storage options for P4 depot volumes: Amazon Elastic Block Store (Amazon EBS), Amazon FSx for NetApp ONTAP, Amazon Elastic File System (Amazon EFS), and Amazon Simple Storage Service (Amazon S3) archive depots. We evaluate each against real-world game development workloads and provide a decision framework to help you choose.

Prerequisites

To get the most from this post, you should have:

• An AWS account with permissions to provision storage services
• Familiarity with Perforce P4 (formerly Helix Core) administration and the Server Deployment Package (SDP)
• A basic understanding of AWS storage services (Amazon EBS, Amazon FSx, Amazon EFS, Amazon S3)
• Knowledge of your current depot size, growth trajectory, and team size

How P4 uses storage

Before comparing options, it helps to understand how P4 organizes its data. The Perforce Server Deployment Package (SDP) defines three storage volumes:

• /mnt/p4depots: Archive files (versioned binary and text content), rotated journals, and checkpoints. This volume holds the bulk of your data and sees sustained sequential reads during sync operations and sequential writes during submits.
• /mnt/p4db: Metadata databases. Small relative to depots but accessed with random I/O patterns. Low latency matters here.
• /mnt/p4logs: Active journal, server logs, and temporary storage.

The depot volume (/mnt/p4depots) is where storage choice has the greatest impact on cost, performance, and operational complexity. The metadata and logs volumes are best served by Amazon EBS gp3 in nearly all cases because of their low-latency random I/O requirements. This post focuses on the depot volume decision.

Amazon EBS gp3

Amazon EBS gp3 volumes provide block-level storage attached to a single Amazon Elastic Compute Cloud (Amazon EC2) instance. For P4, EBS is the starting point with the least operational overhead.

Performance characteristics

Amazon EBS gp3 volumes deliver a baseline of 3,000 IOPS and 125 MiBps throughput, independently scalable up to 80,000 IOPS and 2,000 MiBps, with a maximum volume size of 64 TiB. Latency is in the low single-digit milliseconds. For a studio with a depot under 16 TB, a single gp3 volume provides enough throughput for concurrent developer syncs and CI/CD reads without additional tuning.

Operational model

Amazon EBS volumes attach to one instance at a time. Your commit server and its high-availability (HA) standby replica each need their own copy of the depot data. P4 handles this through its built-in replication. The standby maintains a full copy of both metadata and archive files. Disaster recovery uses EBS snapshots replicated to a secondary AWS Region.

When to choose EBS

Choose Amazon EBS gp3 when your depot is under 16 TB, your team is small to medium (under 100 concurrent developers), and you want the lowest operational overhead. EBS is also the right choice for the metadata (/mnt/p4db) and logs (/mnt/p4logs) volumes regardless of what you use for depots.

Limitations

Amazon EBS volumes can’t be shared across instances. As depot size grows beyond 16 TB, you pay for full copies on both the commit server and every standby replica. There are no built-in storage efficiency features like deduplication or compression. Every byte is stored as written, with no reduction.

FSx for ONTAP

FSx for ONTAP is a fully managed shared file and block storage service built on the ONTAP file system. Both Perforce and AWS recommend FSx for ONTAP for depots exceeding 16 TB. (AWS also lists Amazon FSx for OpenZFS as an option for larger depots; this post focuses on FSx for ONTAP.)

Performance characteristics

FSx for ONTAP delivers sub-millisecond latency on the SSD tier. A single HA pair provides up to 6 GBps of throughput (4 GBps on first-generation file systems), and scale-out file systems with multiple HA pairs reach up to 72 GBps; well beyond what a P4 depot requires. It supports NFS, SMB, and iSCSI access. For P4 depot volumes, Perforce recommends iSCSI with multiple connections for maximum performance, or NFS with nconnect for a balance of performance and lower operational overhead.

Storage efficiency

This is where FSx for ONTAP differentiates itself for game development workloads. Inline deduplication, compression, and compaction reduce the physical storage footprint. AWS documents savings of up to 65% in storage capacity for general file shares. Actual savings for a P4 depot depend heavily on asset composition: already-compressed binaries (textures, audio, and video) yield little additional compression, while deduplication across the many stored revisions of versioned files can recover meaningful space. Measure your depot’s data-reduction ratio rather than assuming a fixed figure.

Shared storage and HA

FSx for ONTAP multi-Availability Zone (AZ) deployments provide a single shared /mnt/p4depots volume accessible from both the commit server and its HA standby. This removes the need for P4 to replicate archive files between commit and standby. The lbr.replication setting can be configured as shared, which can result in faster failover and reduced replication bandwidth.

CI/CD acceleration

ONTAP FlexClone creates instant, space-efficient writable copies of depot data. Build farms can clone a depot snapshot in seconds without immediately consuming additional storage, run a build against it, and discard the clone. This accelerates build verification and reduces the cost of parallel build environments.

Disaster recovery

ONTAP SnapMirror provides efficient cross-Region replication at the block level. Combined with automatic data tiering (cold data moves from SSD to a capacity pool backed by lower-cost storage), DR replicas can cost significantly less than maintaining full EBS copies in a secondary Region.

When to choose FSx for ONTAP

Choose FSx for ONTAP when your depot exceeds 16 TB, you have 100 or more concurrent developers, you need shared storage between commit and replica servers, or your CI/CD pipeline benefits from instant clones. It’s also the right choice when storage efficiency savings offset the higher baseline cost.

Limitations

FSx for ONTAP has a higher initial setup complexity than Amazon EBS. It introduces network-attached storage latency for the depot volume. For the sequential I/O patterns of depot access, this latency is negligible. Pricing includes SSD capacity, capacity pool storage, and throughput capacity, which means more dimensions to manage than Amazon EBS.

Amazon EFS

Amazon EFS provides fully managed, elastic NFS file storage that scales automatically. It supports shared access across multiple instances and Availability Zones.

Performance characteristics

Amazon EFS Elastic throughput delivers over 10 GBps of read throughput, and read latencies on the Standard storage class can be sub-millisecond. However, write and random-I/O latencies are higher than both Amazon EBS and FSx for ONTAP for the patterns P4 generates, and EFS doesn’t support iSCSI.

Why it isn’t recommended for P4 depots

Neither the Perforce deployment guide nor the AWS guidance for P4 recommends EFS for depot storage. The reasons are practical:

• No deduplication or compression. You pay for every stored byte at a per-GB rate higher than FSx for ONTAP at scale.
• No equivalent to FlexClone for CI/CD workflows.
• Higher latency for the mixed random and sequential I/O patterns that P4 generates during operations like p4 verify or p4 obliterate.
• NFS only, with no iSCSI option. This limits tuning options for P4.

When EFS might apply

Amazon EFS can serve as shared storage for ancillary P4 components: configuration files, shared scripts, or SDP tooling that multiple instances need to access. It isn’t suitable as a primary depot backend.

S3 archive depots

P4 natively supports Amazon S3 as a storage backend for archive depots. This isn’t a general-purpose depot solution. It’s specifically designed for offline storage of infrequently accessed content.

How it works

You configure an archive depot type in P4 that stores file data directly in an S3 bucket rather than on the local file system. Files are archived from active depots to the archive depot using the p4 archive command and restored with p4 restore. Mountpoint for Amazon S3 can also present an S3 bucket through a read-optimized file interface (it doesn’t implement full POSIX semantics). It’s optimized for sequential reads and supports only sequential writes to new objects; not the random, in-place writes that active P4 depots require.

Cost advantage

Amazon S3 offers the lowest cost per TB of these four options at scale, with lifecycle policies that automatically tier data from S3 Standard to S3 Glacier storage classes for long-term retention. For studios that must retain historical asset versions for business or contractual reasons, S3 archive depots provide indefinite retention at a low per-GB cost. See the Amazon S3 pricing page for current rates in your Region.

When to choose S3

Use Amazon S3 archive depots for cold data: assets from shipped titles, deprecated engine versions, or historical builds that developers rarely access but must retain. Combine S3 with an active depot on Amazon EBS or FSx for ONTAP. Active development runs on high-performance storage, while completed projects move to S3 for long-term archival.

Limitations

Amazon S3 can’t serve as the primary storage for active depot operations. Object storage provides whole-object writes rather than the random, in-place writes P4 performs on active archive files, and it offers no POSIX file locking. Combined with request latency that is too high for interactive use, these access-pattern differences make S3 unsuitable as an active depot backend. Amazon S3 has provided strong read-after-write consistency for all requests since December 2020, so data consistency isn’t the limiting factor; the object-write semantics and latency are.

Comparison summary

The following table compares the four options across dimensions that matter for game development workloads.

¹ AWS-documented savings of up to 65% in storage capacity for general file shares. Actual savings for a P4 depot vary with asset composition.

² Relative ranking, not absolute cost. Ordered from least to most expensive per GB-month: Amazon S3, FSx for ONTAP SSD, Amazon EBS gp3, Amazon EFS Standard. The ranking reflects total cost for a 50 TB active depot under each service’s HA model: EBS can’t be shared, so the commit server and HA standby (plus any DR replica) each hold a full copy (2–3×), which outweighs its lower per-GB rate; FSx for ONTAP and EFS share one volume, and FSx further reduces its footprint through storage efficiency and cold-block tiering. Verify current rates on the EBS, FSx for ONTAP, EFS, and S3 pricing pages for your Region.

³ 72 GBps is the maximum for scale-out file systems (up to 12 HA pairs). A single HA pair—typical for a P4 commit server—delivers up to 6 GBps (4 GBps on first-generation file systems), still far exceeding depot throughput needs.

Decision framework

Use the following guidance based on your studio’s profile.

[Figure 1 – Decision framework for choosing AWS storage for Perforce P4 — Insert decision framework flowchart image here]

Small studio

Start with Amazon EBS gp3 for all three P4 volumes. The lower operational overhead outweighs the cost of maintaining full replicas at this scale. Use EBS snapshots for DR.

Mid-size studio

Use Amazon EBS gp3 for metadata and logs. Use FSx for ONTAP for the depot volume. The storage efficiency savings and shared-storage HA model reduce both cost and failover complexity at this scale. Consider Amazon S3 archive depots for shipped titles.

Large studio

FSx for ONTAP for depot storage is the clear choice. Shared storage between commit and replicas, FlexClone for CI/CD, SnapMirror for DR, and storage efficiency features all compound at this scale. Implement Amazon S3 archive depots with lifecycle policies for long-term retention of cold assets.

All studios

Regardless of size, use Amazon EBS gp3 for /mnt/p4db (metadata) and /mnt/p4logs (journals and logs). These volumes need low-latency random I/O that block storage delivers best.

Conclusion

Choosing the right storage backend for P4 on AWS isn’t a one-size-fits-all decision. Amazon EBS gp3 provides the lowest-overhead path for smaller depots. FSx for ONTAP delivers the performance, efficiency, and operational advantages that larger studios need. Amazon S3 archive depots handle long-term retention at a low per-GB cost. Amazon EFS, while a capable service for other workloads, isn’t the right fit for P4 depot volumes.

Start by measuring your depot size and growth trajectory, then match it to the decision framework in the previous section. As your studio scales, you can migrate from Amazon EBS to FSx for ONTAP for the depot volume without changing your metadata or logs configuration. Because the SDP storage layout keeps the depot volume independent of the metadata and logs volumes, this transition does not require reconfiguring those volumes.

For more information, see the Perforce P4 AWS Deployment Guide and the Guidance for Building Perforce P4 on AWS. To get started with a reference deployment, explore the Cloud Game Development Toolkit on GitHub.

We’d like to hear from you. If you have questions or feedback about this post, leave a comment below. If you’re evaluating storage options for a P4 deployment and want to discuss your architecture, reach out through your AWS account team or contact AWS.