Enterprises with existing VMware Cloud Foundation (VCF) investments want to migrate their Oracle databases to AWS without rearchitecting applications or retraining operations teams. Oracle on Amazon EVS can take advantage of sub-millisecond storage latency, snapshot-based backup, cross-region DR, and independent storage scaling, all while preserving existing VMware operational workflows.

In this post, we show you how to architect a complete Oracle Database environment on Amazon EVS with Amazon FSx for NetApp ONTAP. You learn how the storage, compute, networking, and disaster recovery layers work together to deliver high availability, cross-region DR, and sub-millisecond storage latency while maintaining your familiar VMware operational tooling.

In this post, you learn how to:

• Design Oracle Database architecture on Amazon EVS running VMware Cloud Foundation 5.2.2
• Select optimal EC2 bare metal instance types and VM sizing for Oracle workloads
• Architect storage using Amazon FSx for NetApp ONTAP as NFS datastores for Oracle data and log volumes
• Plan SnapMirror replication for cross-region disaster recovery
• Evaluate migration options for moving existing Oracle workloads from on-premises VMware to EVS

Amazon EVS directly runs VMware Cloud Foundation (VCF) environments on Amazon Elastic Compute Cloud (Amazon EC2) bare metal instances within an Amazon Virtual Private Cloud (Amazon VPC). Amazon FSx for NetApp ONTAP provides managed ONTAP storage with NFS, SMB, iSCSI, and NVMe over TCP access. FSx for NetApp ONTAP can deliver sub-millisecond response times, multiple GBps of throughput, and up to 80,000 IOPS per file system (see FSx for ONTAP performance).

For more information, see FSx for NetApp ONTAP features.

For step-by-step deployment procedures including provisioning, storage configuration, Oracle installation, and SnapMirror setup, see our companion post: Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP.

Solution architecture

This section describes a highly available Oracle Database deployment on Amazon EVS with Amazon FSx for NetApp ONTAP storage across two AWS Regions. Figure 1 illustrates the numbered data flow from on-premises through hybrid connectivity into the production EVS environment and cross-region disaster recovery (DR).

The architecture consists of eight functional components, described in the following section.

Architecture components

These numbered items correspond to the data flow shown in the diagram.

1. Hybrid link — On-premises data center connects to AWS through AWS Direct Connect for dedicated, low-latency bandwidth.
2. Transit routing — AWS Transit Gateway routes traffic between the production VPC, DR region, and on-premises networks.
3. Workload landing — Traffic reaches the EVS Database Cluster running on i7i.metal-24xl Amazon EC2 bare metal instances with VCF 5.2.2.
4. Live migration — VMware HCX (Hybrid Cloud Extension) migrates Oracle VMs from on-premises VMware to EVS with near-zero downtime using Replication Assisted vMotion or bulk migration.
5. NFS data path — Each ESXi host mounts Amazon FSx for NetApp ONTAP as an NFS datastore. Oracle VMs access database volumes as block devices (VMDKs on the NFS datastore) with sub-millisecond latency and up to 80,000 IOPS. Each host has its own independent NFS path to FSx for ONTAP, distributing bandwidth across the cluster.
6. Cross-region DR — SnapMirror asynchronously replicates FSx for ONTAP volumes (data, logs, binaries) to the DR region with configurable Recovery Point Objective (RPO).
7. Dynamic routing — NSX Tier-0 gateway peers through BGP with Amazon VPC Route Server. This is one-way BGP. Route Server listens for routes advertised by NSX and writes them to the VPC route table, but does not advertise VPC routes back to NSX.
8. DR failover — On failover, Transit Gateway routes to the DR region where pre-provisioned standby Oracle VMs mount the SnapMirror replica volumes.

Factors to consider for Oracle Database deployment on EVS

Before you begin deployment, evaluate your Oracle workload requirements against the available infrastructure options. The decisions you make for instance types, VM sizing, and storage architecture directly affect database performance, cost, and operational complexity.

Oracle licensing consideration: Instance type selection affects Oracle license cost, which is an important factor to take into consideration. We recommend requesting an AWS Optimization and Licensing Assessment (AWS OLA) for further guidelines.

EC2 instance type selection for ESXi hosts

Amazon EVS currently supports two bare metal instance types for ESXi hosts. The choice depends on whether you prioritize per-core compute speed (i7i) or per-host memory and storage density (i4i). For most new Oracle deployments, i7i is the better choice because Oracle query performance is sensitive to CPU instruction throughput and storage IO latency.

• i7i.metal-24xl (recommended for new deployments): 5th Gen Intel Xeon delivers up to 23% better compute performance, critical for Oracle CPU-bound queries. 3rd Gen AWS Nitro SSDs provide up to 50% better real-time storage performance and up to 50% lower IO latency for vSAN. Torn write prevention (up to 16KB block sizes) helps reduce database double-write penalties.
• i4i.metal: Higher per-host density (128 vCPUs, 1,024 GiB RAM, 30 TB NVMe) suits environments requiring fewer, larger hosts to reduce VMware licensing costs.

VCF compatibility: Both instance types support VCF 5.2.2 with ESXi 8.0U3g. An EVS environment supports 4–32 hosts per cluster. You can mix instance types across clusters within the same SDDC.

VM sizing for Oracle Database guests

Size Oracle Database VMs based on these workload characteristics:

• Allocate vCPU count matching Oracle CPU_COUNT parameter
• Size memory for SGA + PGA + OS overhead (typically 75–85% of allocated VM memory for SGA)
• Configure VM swap on vSAN datastore (not NFS). vSAN uses local NVMe with single-digit millisecond latency.
• Use NUMA-aware VM placement for VMs exceeding single-socket core count
• Place OS swap and Oracle temp tablespace on the vSAN datastore for single digit ms latency at no additional cost

Storage architecture: vSAN + FSx for NetApp ONTAP

The recommended design splits storage responsibilities between two tiers:

• vSAN (backed by local NVMe drives on each ESXi host) handles low-latency, non-replicated workloads: VM boot disks, OS swap, and Oracle temp tablespace.
• FSx for NetApp ONTAP handles Oracle data files and redo logs that require snapshot-based backup and cross-region replication. ESXi hosts mount FSx for ONTAP volumes as NFS datastores, and Oracle VMs access standard VMDKs on those datastores.

This separation gives local NVMe speed for transient IO while adding snapshot, clone, and SnapMirror capabilities for persistent database files.

Why NFS datastore (host-level) instead of in-guest NFS (dNFS)? With in-guest NFS, all Oracle NFS traffic routes through the NSX overlay and an NSX Edge node before reaching FSx for ONTAP. This creates a single Edge chokepoint. With NFS datastores, each ESXi host talks NFS directly to FSx for ONTAP using its own network bandwidth. There is no Edge bottleneck and no extra latency hop.

FSx for NetApp ONTAP sizing considerations

Important: Use 100% SSD for Oracle. We recommend against using capacity pool tiering for Oracle database volumes. Keep tiering policy set to none for all Oracle volumes.

Important: SSD capacity planning. If the SSD tier fills to capacity, FSx for ONTAP blocks writes. Monitor SSD utilization and provision headroom (minimum 20% free).

Important: Read/write throughput asymmetry. On a 6 GB/s filesystem, read throughput can reach 6 GB/s, but write throughput is limited to approximately 1 GB/s. Size throughput capacity based on Oracle write workload requirements.

Network architecture

Amazon EVS uses VLAN subnets (defined at environment creation; cannot be changed later) to segment traffic.

VPC Route Server replaces static routes within the VPC. NSX Tier-0 gateways peer through BGP with Route Server endpoints. This is one-way BGP: Route Server listens for routes from NSX and programs them into the VPC route table but does not advertise VPC routes back to NSX. Beyond the VPC, routes remain static at Transit Gateway.

NSX-T segmentation for Oracle

• Dedicated Tier-1 gateway for production database segments (DB subnets)
• Separate Tier-1 for application tier (App subnets) and perimeter network
• Distributed firewall rules restrict Oracle listener access (TCP 1521) to authorized application segments only
• Micro-segmentation between Oracle instances prevents lateral movement

Important: Security group rules are not enforced on VLAN subnet interfaces. Use network ACLs and NSX distributed firewall for traffic control.

High availability and disaster recovery

• SnapMirror replication frequency determines RPO. Configure based on business requirements.
• Pre-provision standby Oracle VMs in the DR cluster to reduce Recovery Time Objective (RTO).
• Replicate binary volumes so that Oracle installation is not required during recovery.
• Automate failover with Ansible/SnapCenter to reduce human error.

Oracle licensing consideration for DR: There are license impacts based on how DR replication is implemented.  If you have licensing questions, we recommend requesting an AWS Optimization and Licensing Assessment (AWS OLA).

To comply with the Oracle licensing rules, an alternative is to replicate the Oracle VM through NetApp SnapMirror from Production to DR. Keep the DR replicated volumes as data-protection (DP) volumes that are NOT mounted as NFS datastores on DR hosts until a failover event is declared to avoid Oracle double licensing. Only then break the SnapMirror, mount the NFS datastore on the DR Host, and power on the VM. Pre-mounting the SnapMirror volume as a datastore , even with no VM powered on means Oracle binaries are accessible on those hosts, which Oracle may consider an “installation” requiring licenses across the entire DR cluster.

Database migration from on-premises VMware to EVS

The following table compares migration options from on-premises VMware to EVS.

For detailed procedures on each migration option, see our companion post: Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP.

Security

Security for Oracle on Amazon EVS spans multiple layers from network isolation to database-level encryption. The following table summarizes the security controls across each layer.

Cost optimization

Cost optimization for Oracle on Amazon EVS focuses on matching infrastructure capacity to workload demands and leveraging AWS pricing models. The following table summarizes key strategies across compute, storage, networking, and Oracle licensing. We recommend requesting an AWS Optimization and Licensing Assessment (AWS OLA) for further guidelines.

Summary

Deploying Oracle databases on Amazon EVS with Amazon FSx for NetApp ONTAP provides high availability, cross-region DR, and sub-millisecond storage latency while combining VMware operational consistency with AWS cloud economics:

• Performance: i7i.metal-24xl with up to 23% better compute, 50% lower IO latency. FSx for ONTAP delivers sub-millisecond latency with up to 80,000 IOPS.
• Availability: vSphere HA, SnapMirror cross-region replication, and optional Oracle Data Guard
• Manageability: SnapCenter for backup, clone, and recovery in seconds regardless of database size
• Migration flexibility: HCX (live), SnapMirror (ONTAP-to-ONTAP), PDB Relocation (multi-tenant), RMAN (universal)
• Security: NSX micro-segmentation, AWS KMS encryption, and zero-trust access
• Cost efficiency: Approximately 10% better price performance with i7i; on-the-fly throughput adjustment; AWS Savings Plans.

This architecture provides you with high availability, cross-region DR, and storage-based backup and cloning similar to Oracle RAC and Data Guard functions while maintaining your familiar VMware operational tooling and procedures.

Next steps

To get started with this deployment:

1. Provision an Amazon EVS environment in your target Region. See the Amazon EVS User Guide for setup instructions.
2. Deploy an Amazon FSx for NetApp ONTAP file system in the same VPC and Availability Zone as your EVS cluster.
3. Follow the step-by-step procedures in our companion post to mount NFS datastores, create Oracle VMDKs, and configure SnapMirror DR.
4. Test in a non-production environment first, then migrate production Oracle workloads.

Additional resources

• Amazon EVS User Guide
• EVS Supported VCF Versions and Instance Types
• Configure FSx for ONTAP as NFS Datastore for EVS
• FSx for NetApp ONTAP with EVS
• Amazon EVS Pricing
• Introducing Amazon EVS — AWS Blog
• NetApp Automation Toolkit for Oracle
• Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP

Author Bio

Satish Bhoi is a Technical Account Manager in AWS Enterprise Support, where he helps customers design and optimize cloud solutions. With over 20 years of industry experience, he specializes in cloud architecture and is passionate about exploring generative AI applications in cloud computing. Outside of work, Satish plays league cricket, coaches young players, and enjoys traveling and adventure.

Sudhir Balasubramanian is a Data & AI Infrastructure Architect — an Oracle ACE, VMware vExpert, Nutanix NCP — a Speaker, Blogger, Author, Technologist, Evangelist, Partner & Customer Advocate. Sudhir loves working with Customers & Partners to build creative solutions to solve complex problems & improve Customer experience. Outside of work, Sudhir likes to Hike, Walk, Cook and Listen to Classic Rock & Metal.