AWS Architecture Blog·October 2, 2026Deploying Highly Available Oracle Databases on AWS with FSx for ONTAP
This article details the step-by-step deployment of Oracle Database on Amazon Elastic VMware Service (EVS) using Amazon FSx for NetApp ONTAP as NFS datastore storage. It focuses on practical implementation procedures for provisioning VMs, configuring storage, installing Oracle 19c, and setting up SnapMirror for cross-region disaster recovery. While the article is highly procedural, it touches upon underlying architectural decisions, such as storage sizing and high availability considerations, by referencing a related architectural planning post.
Read original on AWS Architecture BlogThis guide provides a detailed walkthrough for deploying Oracle Database on Amazon Elastic VMware Service (Amazon EVS) using Amazon FSx for NetApp ONTAP as the underlying NFS datastore. The approach aims to provide enterprises with a path to AWS that minimizes re-architecture and leverages existing VMware operational workflows, integrating cloud-native storage capabilities with a familiar virtualization environment.
Architectural Context and Prerequisites
The deployment outlined in this article builds upon a previously established architecture for highly available Oracle databases on Amazon EVS and FSx for ONTAP. Key architectural decisions include selecting Amazon EC2 bare metal instances for EVS hosts, sizing VMs appropriately, distributing storage between vSAN and FSx for NetApp ONTAP, and planning SnapMirror replication for cross-region disaster recovery (DR). Essential prerequisites for this deployment involve a pre-existing Amazon EVS environment, a minimum of 4 hosts per cluster (with a dedicated DB cluster recommended), a configured VPC with Route Server, AWS Transit Gateway, and AWS Direct Connect, and appropriate IAM permissions.
Storage Provisioning and Configuration
- Amazon FSx for NetApp ONTAP: Configured as a Single-AZ deployment (required for EVS) with specific SSD storage capacity, throughput, and IOPS settings tailored for Oracle workloads. Security groups must allow NFS traffic from the EVS management VLAN.
- Volume Creation: Separate ONTAP volumes are created for Oracle binaries (`/oradb1bin`), data (`/oradb1data`), and logs (`/oradb1log`). The `tiering-policy none` is crucial to ensure all data remains on the high-performance SSD tier, and log volumes are sized to accommodate 24 hours of archive logs.
- NFS Datastore Mounting: The FSx for ONTAP volumes are mounted as NFS datastores directly in vSphere, making them accessible at the ESXi host level.
- VMDK Creation and Guest OS Configuration: Virtual disks (VMDKs) for Oracle data, logs, and binaries are created on these NFS datastores within vSphere. Inside the Oracle VM guest OS, these VMDKs are formatted with XFS and mounted as local filesystems (`/u01`, `/u02`, `/u03`). This setup is critical because the Oracle VM interacts with these as local block devices, abstracting the underlying NFS storage and leveraging the ESXi host for NFS communication.
Oracle Performance Insight
For optimal Oracle performance, especially for data and log volumes, use Thick Provision, Eager Zeroed VMDKs. This pre-allocates and zeroes out disk space, reducing latency during initial writes and ensuring consistent performance.
Disaster Recovery with SnapMirror
The article highlights SnapMirror replication for cross-region disaster recovery. While the setup for SnapMirror is procedural, the underlying architectural implication is the ability to replicate Oracle databases asynchronously to a secondary region, providing a robust DR solution. This minimizes data loss and recovery time objectives (RTO/RPO) for critical Oracle workloads by replicating storage volumes rather than entire VMs or relying solely on database-level replication.