Amazon EVS Oracle + FSx ONTAP Architecture Diagram: VCF HA & SnapMirror DR

On October 2, 2026, Satish Bhoi, Ben Lipman, and Sudhir Balasubramanian described a highly available Oracle Database on Amazon Elastic VMware Service with Amazon FSx for NetApp ONTAP. Teams that already run VMware Cloud Foundation can move Oracle without rearchitecting the application or retraining operators. VMware workflows stay, with sub-millisecond storage latency, snapshot backup, cross-region disaster recovery, and storage that scales apart from the ESXi hosts.

This Amazon EVS Oracle FSx ONTAP architecture diagram follows that AWS Architecture Blog post only. Steady-state connectivity from on-premises is AWS Direct Connect and AWS Transit Gateway. VMware HCX is a live or bulk migration into the cluster, not that network. The picture is an architecture reading, not a runbook, and it does not link the companion article where the authors put provisioning steps.

Amazon EVS on VCF 9.1

Amazon EVS runs VMware Cloud Foundation on EC2 bare metal inside a VPC. With VCF 9.x, EVS provisions the hosts and VLAN subnets, and you deploy VCF with Broadcom’s VCF Installer, the self-deployed model. Evaluation mode lets you check the design before license keys, and VLAN subnets are fixed at creation. The post uses VCF 9.1 and ESXi 9.1, build 9.1.0.0100.25433460. New deployments should prefer 9.x, because VCF 5.2.2 is heading out of support. A cluster holds 4 to 32 hosts.

For most new Oracle work the recommended host is i7i.metal-24xl: 96 vCPUs, 48 cores, and 768 GiB of RAM, on 5th Gen Intel Xeon, with 3rd Gen Nitro SSDs under vSAN. License cost moves with the instance, so the authors recommend an AWS Optimization and Licensing Assessment. Match guest vCPUs to Oracle CPU_COUNT. A typical SGA is 75 to 85 percent of VM memory, beside PGA and operating-system overhead. Keep VM swap on vSAN, not on NFS.

Data files and redo on FSx, boot and temp on vSAN

Two storage roles cover the guest. vSAN on local NVMe holds boot disks, OS swap, and the Oracle temp tablespace, at single-digit millisecond latency and at no extra charge for swap and temp. FSx for NetApp ONTAP holds data files and redo logs. Each ESXi host mounts FSx as an NFS datastore, and the guest sees VMDKs. Redo stays on FSx with the data files. Temp stays on vSAN with boot and OS swap.

Host NFS avoids one NSX Edge as a choke point. In-guest NFS would cross the NSX overlay and that Edge. A datastore lets each host reach FSx for ONTAP on its own bandwidth.

Keep Oracle volumes on 100 percent SSD with tiering set to none, not on the capacity pool. Leave at least 20 percent SSD free, because a full tier blocks writes. On a file system sized at 6 GB/s, the post says reads can reach 6 GB/s while writes stay near 1 GB/s per high-availability pair. More write capacity means more pairs and a deliberate layout across aggregates. The article also cites sub-millisecond response times and up to 80,000 IOPS per file system. Binary volumes are in the SnapMirror set so recovery does not reinstall Oracle.

One-way NSX into the VPC Route Server

VPC Route Server replaces static routes inside the VPC. NSX Tier-0 peers with it over BGP in one direction only. NSX advertises. Route Server listens and programs the VPC route table. Nothing is advertised back to NSX. Past the VPC, Transit Gateway routes stay static. The drawing uses that single arrow.

A dedicated Tier-1 gateway serves production database segments. A second Tier-1 serves the application tier and the perimeter. The distributed firewall allows Oracle listener TCP 1521 only from authorized application segments and limits movement between Oracle instances. Security group rules are not enforced on Amazon EVS VLAN subnet interfaces. Use network ACLs and the NSX distributed firewall on those interfaces.

HCX is migration only

Direct Connect is the dedicated hybrid link. Transit Gateway joins the production VPC, the DR Region, and on-premises networks. HCX is not that path. It migrates Oracle VMs from on-premises VMware to EVS by Replication Assisted vMotion, which the post calls near-zero downtime, or by bulk migration. Near-zero downtime is about the move only. This page states no recovery-point number and no recovery-time number. Other options in the post, still separate from DX / TGW, are ONTAP-to-ONTAP SnapMirror, PDB relocation, and RMAN backup and restore.

SnapMirror to the standby Region

SnapMirror asynchronously replicates FSx for ONTAP data, log, and binary volumes to the DR Region. Frequency follows business requirements. The post publishes no minutes and no seconds. Asynchronous replication does not promise the standby is current to the last commit. Pre-provisioned standby Oracle VMs shorten recovery, with no duration given. Ansible or SnapCenter can automate failover. On failover, Transit Gateway routes to the DR Region and the standby VMs mount the replica.

Keep the replicas as data-protection volumes, unmounted as NFS datastores on DR hosts until failover is declared. An earlier mount can look like an Oracle installation on the DR cluster even if the VM is off. At failover, break SnapMirror, mount the datastore, and power the VM on. License questions go to an AWS Optimization and Licensing Assessment. vSphere HA plus SnapMirror is the availability path. Oracle Data Guard is optional in the summary, not a second arrow here. Place FSx for ONTAP in the same Availability Zone as the EVS cluster.

FAQ

Where do Oracle data files, redo logs, boot disks, OS swap, and temp live?

vSAN on local NVMe holds VM boot disks, OS swap, and the Oracle temp tablespace. FSx for NetApp ONTAP, mounted by each ESXi host as an NFS datastore, holds Oracle data files and redo logs as VMDKs. That host-level path avoids sending in-guest NFS through an NSX Edge.

How does NSX update the VPC route table?

One way. NSX Tier-0 advertises routes with BGP to Amazon VPC Route Server. Route Server listens and programs those routes into the VPC route table. It does not advertise VPC routes back to NSX. Beyond the VPC, Transit Gateway routes stay static.

Is HCX the hybrid network, and do security groups protect EVS VLAN interfaces?

No. Direct Connect and Transit Gateway are the hybrid path, labeled DX / TGW. HCX only migrates Oracle VMs, live or bulk, on a separate dashed arrow into the EVS cluster. Security group rules are not enforced on VLAN subnet interfaces. Use network ACLs and the NSX distributed firewall, including a limit on TCP 1521 to authorized application segments.

Conclusion

The October 2, 2026 design is Direct Connect and Transit Gateway into Amazon EVS on VCF 9.1, with HCX only for migration, vSAN for boot, OS swap, and temp, FSx for ONTAP for data and redo, asynchronous SnapMirror to the DR Region, and one BGP advertisement from NSX Tier-0 into VPC Route Server. The only source is the AWS Architecture Blog article on a highly available Oracle Database on Amazon EVS and FSx for ONTAP. More diagrams are on the ByteDiagram blog.