Modernizing PeopleSoft on Oracle AI Database@AWS and with Amazon FSx for NetApp ONTAP (FSxN)

Introduction

Running PeopleSoft in the cloud has historically come with a familiar set of trade-offs: you gain elasticity but sometimes give up the raw database performance and deep Oracle integration your applications depend on. That calculus changed meaningfully when Oracle introduced Oracle AI Database@AWS(ODB@AWS), a service that runs actual Oracle Exadata infrastructure inside AWS data centers, managed through the AWS console, and billed through a single AWS invoice.

Pair that with Amazon FSx for NetApp ONTAP (FSxN) for the application filesystem layer, and you have a PeopleSoft architecture that does not ask you to compromise. The database gets the performance and licensing characteristics of Exadata. The application tier gets shared, enterprise-grade storage with built-in High Availability (HA), instant cloning, and cross-region replication. Together they form a deployment pattern that is genuinely production-ready for the most demanding PeopleSoft environments.

This blog walks through what that architecture looks like in practice how the components fit together, where the resiliency boundaries sit, and why FSxN specifically is a better answer for PeopleSoft’s application filesystem than generic cloud block or file storage.

What is PeopleSoft

PeopleSoft is Oracle’s suite of enterprise business applications covering Human Capital Management (HCM), Financials, Supply Chain, Campus Solutions, and more. Unlike some newer SaaS HR and finance platforms, PeopleSoft is a self-managed application customers run on their own infrastructure, apply their own patches, and control their own upgrade cadence. That ownership model is exactly why many large organizations still prefer it: full control over customizations, integrations, and timing.

PeopleSoft’s architecture separates the database tier (Oracle Database, almost universally) from the application tier, which includes PeopleSoft Application Server, Process Scheduler, web server nodes, and a shared application filesystem that all nodes must be able to read and write. That shared filesystem requirement is one of the reasons FSxN is such a natural fit it delivers a true multi-host Network File System(NFS) mount point with the performance characteristics PeopleSoft actually needs.

What is Oracle AI Database@AWS(ODB@AWS)

ODB@AWS is not a managed database service in the conventional sense. It is Oracle’s Exadata Database Service running on Exadata hardware physically located inside AWS data centers, connected to AWS via a low-latency private network interconnect. From the AWS side, it shows up as a resource you provision through the AWS Marketplace, manage through the AWS console, and pay for on your AWS bill. From the Oracle side, it behaves exactly like Exadata running in an OCI region because architecturally, it is.

That distinction matters for PeopleSoft. Oracle EE licenses applied to ODB@AWS in BYOL mode unlock capabilities that would otherwise require separate purchased options on standard EC2 deployments such as Diagnostics Pack, Tuning Pack, Real Application Testing, Transparent Data Encryption, and more are all included in the BYOL subscription at no additional charge. For a PeopleSoft database that has been running on-premises Exadata, this means you migrate to the cloud without giving anything up.

ODB@AWS is available in multiple AWS regions and supports Oracle Database 19c and above. It integrates natively with AWS services Amazon S3 for backups, CloudWatch for monitoring, IAM for access control so your existing AWS operational tooling continues to work.

What is Amazon FSx for NetApp ONTAP (FSxN)

FSxN  is a fully managed file storage service that runs NetApp’s ONTAP software on AWS infrastructure. It supports NFS, SMB, and iSCSI, so it works equally well as application filesystem storage, database storage, or both. For PeopleSoft specifically, FSxN’s NFS support means all your application server nodes can mount the same filesystem simultaneously a hard requirement for PeopleSoft’s shared application home.

Beyond the protocol support, FSxN brings a set of enterprise storage capabilities that simply do not exist in native AWS file storage options: FlexClone for instant space-efficient environment copies, SnapMirror for efficient asynchronous cross-region replication, Multi-AZ deployment for synchronous HA within a region, and ONTAP snapshots for rapid point-in-time recovery. These are production-proven features from NetApp’s on-premises lineage, now available as a managed AWS service with no additional licensing.

Architecture Overview

The architecture described here spans two AWS regions and three availability zones, designed to meet the availability and recovery requirements most PeopleSoft customers operate under. The primary site runs in one region with a high availability site in a second availability zone in the same region. A disaster recovery site runs in a second AWS region entirely.

PeopleSoft Reference Architecture: Oracle AI Database@AWS (ODB@AWS)

Architecture Components

AWS Regions and Availability Zones

The deployment uses two AWS regions. The primary region hosts both the production and HA environments across two Availability Zones. The DR region hosts a standby environment ready for activation in the event of a regional failure. AWS Availability Zones are physically separate data centers within a region, each with independent power, cooling, and networking a failure in one AZ does not propagate to another.

VPC and Networking

Each region runs within an AWS Virtual Private Cloud (VPC), which provides network isolation with full control over IP addressing, subnets, routing, and security group rules. The Exadata infrastructure behind ODB@AWS runs in a separate, AZ-scoped ODB Network that Oracle provisions and manages. It has no connectivity to your VPC by default. Connectivity is established through ODB Peering, which routes traffic privately between your Application VPC and the ODB Network, so database traffic between EC2 application servers and the Exadata cluster travels over a private path and never touches the public internet.

This ODB Network is also what delivers the architecture’s ultra-low latency. Keeping the PeopleSoft Application Server and Process Scheduler EC2 instances in the same placement group as the ODB Network physically co-locates them with the Exadata hardware they connect to. Combined with ODB Peering, this delivers consistent, sub-millisecond round-trip latency between the application and database tiers, directly benefiting PeopleSoft’s batch processing (Application Engine, SQR) and PIA response times.

Compute (EC2) Layer

PeopleSoft application servers, including Application Server domains, Process Scheduler domains, PIA web servers, and Elasticsearch nodes, run on Amazon EC2. These instances are sized appropriately for the workload and distributed across Availability Zones. An AWS Application Load Balancer in front of the web tier distributes user traffic across PIA nodes, and an internal load balancer handles server-to-server communication within the application tier.

Application Storage (FSxN Layer)

FSxN is deployed in Multi-AZ configuration for the production environment, synchronously replicating data between storage nodes in two Availability Zones. All PeopleSoft application server nodes mount the FSxN NFS volume, giving them a consistent, shared view of the application home directory, PS_APP_HOME, and PS_CUST_HOME. This shared mount is essential for PeopleSoft. Process Scheduler, Application Server, and web server nodes all need to read and write to common filesystem locations.

For the DR region, FSxN SnapMirror continuously replicates the application filesystem to a standby FSxN instance, keeping the DR environment’s storage in sync with production.

Database (ODB@AWS Layer)

The Oracle Database runs on ODB@AWS in all three environments: Primary, HA, and DR. Each environment has its own ODB@AWS cluster:

• Primary ODB@AWS: Serves live production traffic in Availability Zone A of the primary region.
• HA ODB@AWS: a second ODB@AWS cluster in Availability Zone B of the same primary region, configured as an Oracle Data Guard physical standby with synchronous redo apply. This provides High Availability at the database layer across AZs in the event of a primary AZ failure.
• DR ODB@AWS: an ODB@AWS cluster in the DR region, configured as a Data Guard standby with asynchronous redo apply. This protects against full regional failures and supports planned regional failovers.

Oracle Data Guard ships redo logs from the primary to the standby databases in real time, maintaining transactional consistency. In a failover scenario, the standby can be opened as the new primary within minutes, and the PeopleSoft application tier in the target environment re-points its TNSNAMES configuration accordingly.

Load Balancers

Traffic management uses two load balancer layers:

• External ALB: Routes inbound user traffic from the internet to PeopleSoft’s PIA web server tier. Handles SSL termination and distributes load across web nodes in both AZs.
• Internal ALB: Routes traffic between PIA web servers and Application Server domains within the VPC. Ensures no single Application Server domain becomes a bottleneck and that web server nodes can reach any available Application Server.

High Availability: Built Into Every Layer

High availability in this architecture is not a single mechanism. It is independent resiliency at each tier, so a failure at one layer does not cascade.

Application Tier HA

EC2 instances hosting PeopleSoft Application Server, Process Scheduler, and PIA domains are deployed across two Availability Zones. If an AZ goes offline, the remaining instances in the other AZ continue serving traffic. The ALB health checks detect failed nodes automatically and stop routing traffic to them. Because all nodes share the FSxN filesystem, there is no per-node application state to reconcile during a failover, so surviving nodes pick up seamlessly.

Storage HA with FSxN Multi-AZ

FSxN Multi-AZ deploys active and standby storage nodes in separate Availability Zones and synchronously replicates all writes between them before acknowledging to the client. If the active node or its AZ becomes unavailable, FSxN automatically fails over to the standby node. From the EC2 application servers’ perspective, the NFS mount remains available throughout, and the failover is transparent at the filesystem level.

This synchronous replication means there is no data loss at the storage layer during an AZ failover. Recovery Point Objective (RPO) for storage is zero.

Database HA with ODB@AWS Data Guard

The HA ODB@AWS cluster in the second AZ runs as a Data Guard physical standby with synchronous redo log shipping. Every committed transaction on the primary is hardened to the standby before the commit is acknowledged to the application. This gives you zero data loss (RPO = 0) at the database layer as well, which is the right target for a financial or HR system.

Oracle Data Guard’s fast-start failover capability can automate promotion of the standby to primary in the event of a detected failure, with recovery time objectives typically measured in single-digit minutes depending on in-flight transaction volume.

Disaster Recovery: Cross-Region Protection

The DR environment mirrors production in a second AWS region, covering the scenario where the entire primary region becomes unavailable, whether due to a natural disaster, regional outage, or deliberate failover for maintenance.

Database DR with ODB@AWS Data Guard

The DR ODB@AWS cluster receives asynchronous redo log shipping from the primary. Asynchronous replication means the primary does not wait for the DR standby to acknowledge before committing transactions, keeping production latency unaffected by the cross-region network path. The tradeoff is a small potential data loss window (typically seconds) at the DR tier, which organizations can quantify and accept or narrow by tuning replication frequency and network throughput.

Activating the DR database is a standard Data Guard switchover or failover operation. Once the DR ODB@AWS is opened as primary, the application tier in the DR region re-points its database connection strings and resumes serving users. Because ODB@AWS in the DR region is already provisioned and running in standby mode, there is no infrastructure spin-up delay during a failover, since the cluster is warm and ready.

Application Storage DR with FSxN SnapMirror

SnapMirror replicates the production FSxN volumes to the DR region asynchronously. It tracks only changed data blocks since the last replication cycle, keeping network bandwidth consumption low even for large PeopleSoft application filesystems. In a DR failover, the SnapMirror relationship is broken, the DR FSxN volume is mounted by EC2 instances in the DR region, and PeopleSoft application servers come online against that storage.

SnapMirror replication happens at the storage level, carrying snapshots rather than just current data. This means you can mount a previous snapshot of the application filesystem in the DR region if the most recent replication captured corrupted data. That recovery flexibility is difficult to replicate with pure block storage replication schemes.

Importantly, SnapMirror is included with FSxN at no additional license cost. You are not paying for a separate replication product on top of your storage subscription, which matters when you are already managing ODB@AWS costs in two regions.

FSxN for PeopleSoft: More Than Just Shared Storage

FSxN earns its place in this architecture beyond the basic requirement for a shared NFS filesystem. Several of its capabilities have direct, material impact on how you operate PeopleSoft day-to-day.

FlexClone: Instant Non-Production Environments

PeopleSoft shops typically maintain multiple non-production environments, such as DEV, TST, QA, UAT, and sometimes separate upgrade or customization sandboxes. Traditionally, provisioning a new environment means waiting for a full copy of the production database and filesystem to complete, which can take hours or days for large PeopleSoft installations.

FlexClone creates a writable clone of an FSxN volume instantly, without duplicating the underlying data. The clone references the same data blocks as the source and only allocates new storage as changes are made. A DEV or QA environment that would have taken half a day to provision now takes minutes, and it consumes only a fraction of the storage a full copy would require.

This capability directly accelerates PeopleSoft upgrade cycles, PUM (PeopleSoft Update Manager) image testing, and customization development. It also means you can provision a fresh copy of production data for a regression test cycle without disrupting any existing non-production environment.

ONTAP Snapshots: Fast Operational Recovery

ONTAP snapshots are point-in-time, space-efficient copies of a volume that can be created in seconds and retained according to a schedule. For PeopleSoft, this means you can snapshot the application filesystem before a patch application, PUM update, or customization deployment. If something goes wrong, you can roll back to the pre-change state in minutes rather than hours.

This kind of fast operational recovery is distinct from disaster recovery. It handles the day-to-day risk of “something went wrong with this deployment” rather than “the region is down.” The ability to recover quickly from a bad patch or a botched configuration change is often more valuable in practice than the DR scenario it accompanies.

Performance for PeopleSoft Workloads

PeopleSoft’s application tier is IO-intensive in ways that matter: batch jobs from Process Scheduler read and write large files, SQR and Application Engine programs generate output in the filesystem, and the application home contains thousands of small files that get accessed during startup and operation. FSxN’s NFS implementation is tuned for this kind of mixed workload, and its throughput scales with your provisioned capacity.

For the database tier, ODB@AWS on Exadata delivers performance characteristics that standard EC2-based Oracle deployments cannot match: Smart Scan for analytical queries, Exadata’s storage cell offloading, and the raw IO throughput that large PeopleSoft databases need during batch processing windows.

Licensing Considerations

While understanding Oracle’s licensing policies in a cloud environment remains one of the key challenges when planning cloud migrations, the licensing benefits of deploying ODB@AWS make the option particularly compelling.

Under the BYOL licensing model on ODB@AWS, one Oracle Processor License maps to two OCPUs, with each OCPU equivalent to four ECPUs (the billing unit for ODB@AWS). This allows existing on-premises processor licenses can be applied directly to ODB@AWS, often resulting in a surplus license capacity.

Additionally, the BYOL licensing model includes several Oracle Database options and Management Packs at no additional cost, including Diagnostics Pack, Tuning Pack, Real Application Testing, Transparent Data Encryption, Data Masking and Subsetting Pack, DDL Logging, and Exadata Columnar Cache. These included capabilities can provide significant licensing cost advantages compared with a standard EC2 deployment, where similar functionality may require additional Oracle licenses.

Oracle also provides a 100-day migration window during which on-premises licenses can be used concurrently with ODB@AWS without triggering a licensing compliance issue. This provides a genuine benefit for PeopleSoft migrations, which often require extended parallel-run periods to support user acceptance testing.

On the FSxN side, FlexClone and SnapMirror are both included in the FSxN subscription. You are not paying extra for the clone capability that reduces your non-production storage costs, or for the SnapMirror replication that powers your DR strategy.

Why This Architecture

Organizations evaluating PeopleSoft on AWS have traditionally faced a choice between familiarity and capability. Running on EC2 with standard EBS or FSx is familiar but gives up the Exadata performance characteristics many PeopleSoft databases depend on. Running on OCI is capable but introduces a different cloud operating model. ODB@AWS closes that gap.

The combination of ODB@AWS and FSxN delivers:

• Zero compromise on database performance: Exadata infrastructure inside AWS, not emulated.
• Single cloud operating model: One AWS console, one bill, one set of IAM policies, one network perimeter.
• Genuine HA and DR: Synchronous standby in a second AZ, asynchronous standby in a second region, both at the database and storage layers.
• Operational agility: FlexClone-powered non-production environments that provision in minutes, snapshot-based rollback for deployments and patches.
• Licensing clarity: BYOL applies directly, built-in options reduce cost versus equivalent EC2 deployments, SnapMirror and FlexClone included in FSxN.
• AWS ecosystem integration: S3 for backups, CloudWatch for monitoring, IAM, Direct Connect, Transit Gateway, all of which continue to work exactly as they do today.

Conclusion

Migrating PeopleSoft to AWS no longer requires accepting a lower tier of Oracle database infrastructure. With ODB@AWS handling the database layer on actual Exadata hardware, and FSxN providing the shared application filesystem with enterprise-grade HA, cloning, and cross-region replication, the architecture described here meets the availability, performance, and operational requirements of production PeopleSoft environments without asking you to re-architect the application itself.

The path forward is straightforward: lift your PeopleSoft environment onto this platform, apply your existing Oracle licenses through BYOL, and take advantage of FSxN’s FlexClone capability to finally get your non-production environment provisioning under control. The infrastructure will not be your bottleneck.