Enterprises seeking cloud migration paths for Oracle on VMware can now deploy Oracle 19c on Amazon EVS with FSx for ONTAP, using NFS datastores and SnapMirror for cross-region disaster recovery without rearchitecting or retraining.
- Leverages FSx for ONTAP NFS storage with VMware ESXi for Oracle data and logs
- Supports SnapMirror replication for cross-region disaster recovery and day-2 operations
- Maintains familiar Oracle VM workflows to avoid rearchitecting and license pitfalls
Infrastructure signal
The deployment integrates Amazon Elastic VMware Service (EVS) with Amazon FSx for NetApp ONTAP as an NFS datastore, providing persistent and scalable storage for Oracle Database 19c. Storage volumes are provisioned on FSx for ONTAP, pinned to SSD tiering for performance consistency, and mounted at the ESXi host level. This abstraction ensures Oracle sees the storage as local XFS filesystems, avoiding the need for NFS-specific database tuning.
SnapMirror replication is configured for cross-region disaster recovery, replicating the entire Oracle VM storage from production to a disaster recovery cluster. Important architectural choices ensure that replicated volumes are kept offline and unmounted in DR environments until failover events to avoid Oracle licensing violations. This infrastructure design balances high availability and cost control by aligning with Oracle licensing and AWS optimization assessments.
Developer impact
Developers and database administrators retain their existing Oracle workflows because the Oracle VM accesses storage as local XFS volumes, masking the networked NFS backend. Database creation, backup, point-in-time recovery, and cloning follow conventional practices without modifications for cloud specifics. SnapCenter integration is used for snapshot backups and restores, supporting typical data protection needs in a cloud environment.
The familiar VMware-based compute environment minimizes retraining and operational disruption. Developers can continue using Oracle ASM or filesystem storage management without adapting to cloud-native storage APIs. However, careful coordination is required to align deployment steps with provisioning, mounting, and replication operations to ensure smooth development and testing cycles.
What teams should watch
Cloud architects and platform teams should monitor Oracle licensing implications closely when planning deployment size and disaster recovery configurations. Engaging AWS Optimization and Licensing Assessments (AWS OLA) before scaling is crucial to avoid unexpected treasury exposure. Licensing constraints strongly influence instance type selection and DR strategy, especially regarding replicated VMs and SnapMirror volume mounting.
Operations teams must be vigilant about the SnapMirror replication state and mounting procedures on DR sites to avoid inadvertent licensing triggers. Observability into NFS datastore health, SnapMirror sync status, and VMware host-level storage paths will ensure both database reliability and cost efficiency. Teams deploying this solution should also align regular day-2 tasks like snapshot backups, recovery, and cloning with NFS datastore management and VMware orchestration.