---
title: "Amazon EVS Architecture: Where vSAN Ends and FSx for ONTAP Begins"
description: "Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work."
---

# Amazon EVS Architecture: Where vSAN Ends and FSx for ONTAP Begins

**Type:** [Architecture](https://yomu.fyi/visual-explainers/category/architecture.md)

![Layered architecture diagram of Amazon EVS: an on-premises VMware estate feeding a migration layer, an EVS compute band split into vSAN and FSx for ONTAP storage panels, and a cross-Region SnapMirror disaster recovery layer.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/40ddc9a1-2887-4c46-b551-eecd7d70470d/image-26741f4a-e1fb-4bdd-9b09-7b2d04d22151.webp)

> Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work.

## Explanation

Amazon Elastic VMware Service (Amazon EVS) lets teams keep VMware Cloud Foundation operations on AWS bare metal instances instead of rearchitecting applications or retraining operators. The architecture splits into bounded layers: the existing on-premises estate, a migration layer using VMware HCX, SnapMirror, or RMAN, the EVS compute layer running VCF, and two storage zones inside it. vSAN serves low-latency transient workloads while FSx for NetApp ONTAP NFS datastores carry Oracle data files and redo logs, with SnapMirror replicating volumes cross-Region for disaster recovery. Knowing which layer owns the data is what keeps latency, licensing, and failover behavior predictable.

## FAQ

### How does this EVS design avoid paying for Oracle twice in the DR Region?

Standby Oracle VMs are pre-provisioned in the recovery Region but mount the SnapMirror replicas only after failover actually happens. Because the database is not running against replicated storage during normal operation, the standby does not consume a second Oracle license until it is genuinely needed.

### Which migration path fits an existing Oracle estate already on NetApp ONTAP?

SnapMirror handles ONTAP-to-ONTAP volume transfer, which suits environments already standardized on ONTAP storage. VMware HCX covers live VM migration when you want to move workloads with minimal disruption, and RMAN backup and restore remains the universal option for databases on non-ONTAP storage.

**Tags:** [Amazon EVS](https://yomu.fyi/topic/amazon-evs.md), [AWS](https://yomu.fyi/topic/aws.md), [Disaster Recovery](https://yomu.fyi/topic/disaster-recovery.md), [FSx for NetApp ONTAP](https://yomu.fyi/topic/fsx-for-netapp-ontap.md), [Migrations](https://yomu.fyi/topic/migration.md), [Virtualization](https://yomu.fyi/topic/virtualization.md)

## Related reading

### [Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP](https://yomu.fyi/post/deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-for-ontap.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Satish Bhoi
- Published: Oct 2, 2026
- Type: Tutorial

This post provides step-by-step procedures to deploy Oracle Database on Amazon Elastic VMware Service (Amazon EVS) with Amazon FSx for NetApp ONTAP as NFS datastore storage. It covers provisioning storage volumes, mounting NFS datastores, installing Oracle 19c, and configuring SnapMirror replication for cross-region disaster recovery. The deployment uses FSx for ONTAP volumes pinned to SSD tier and presents them as VMDKs on NFS datastores, with Oracle accessing them as local XFS filesystems. Four migration paths are detailed for moving on-premises Oracle workloads, including SnapMirror-based replication for existing ONTAP environments and RMAN backup/restore for non-ONTAP storage. Day-2 operations such as snapshot backup, point-in-time recovery, and database cloning via SnapCenter FlexClone are also covered.


### [Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP](https://yomu.fyi/post/architect-highly-available-oracle-database-on-amazon-evs-and-fsx-for-o.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Satish Bhoi
- Published: Oct 2, 2026
- Type: Tutorial

Enterprises with existing VMware Cloud Foundation investments can migrate Oracle databases to AWS using Amazon Elastic VMware Service (EVS) and Amazon FSx for NetApp ONTAP without rearchitecting applications or retraining operations teams. The architecture splits storage between vSAN for low-latency transient workloads and FSx for ONTAP NFS datastores for Oracle data files and redo logs, delivering sub-millisecond latency and up to 80,000 IOPS. Cross-region disaster recovery uses SnapMirror to asynchronously replicate FSx for ONTAP volumes, with pre-provisioned standby Oracle VMs that mount replicas only after failover to avoid Oracle double licensing. Recommended EC2 bare metal instance types include i7i.metal-24xl for per-core compute speed and i7i.metal-48xl for vertical scaling, both supporting VCF 9.1. Migration options include VMware HCX for live migration, SnapMirror for ONTAP-to-ONTAP transfer, and RMAN for universal database movement.


### [Deploy open source Regional availability tools in your VPC](https://yomu.fyi/post/deploy-open-source-regional-availability-tools-in-your-vpc.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Stefan Janjic
- Published: Oct 2, 2026
- Type: Tutorial

Teams building multi-Region architectures on AWS need to know which services are available per Region, but want that data deployed inside their VPC under their governance. This post introduces Capability Insights for AWS, a self-hosted dashboard that auto-refreshes Regional availability data every 24 hours, and Workload Analysis, which scans CloudTrail and CloudFormation to filter services to only those your account uses. Capability Insights deploys a static website backed by API Gateway, Lambda, and EventBridge within your VPC, pulling data from the centralized AWS Capabilities by Region S3 bucket. Workload Analysis reduces the scope from over 200 services to typically 20-30, attributing each resource type to the specific CloudFormation stacks that deploy it and showing property configurations in use. The dashboard provides a targeted view of service availability, API operations, and CloudFormation resource types per Region, enabling focused gap analysis for Regional expansion planning and helping identify service-availability gaps.


### [Lakebase Postgres branch-based restores for fast recovery at scale](https://yomu.fyi/post/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Cassie Murray, Carlota Soto
- Published: Oct 1, 2026
- Type: Explainer

Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.


### [Accelerating airline retailing innovation: how Datalex modernized with AWS Experience-Based Acceleration and agentic AI](https://yomu.fyi/post/accelerating-airline-retailing-innovation-how-datalex-modernized-with.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Kanniah Vagathupatti Jaikumar
- Published: Oct 1, 2026
- Type: Problem & solution

Datalex, a leader in airline ecommerce, needed to modernize its mature EJB2/Java 8 system for Modern Airline Retailing while maintaining continuous airline operations. Over three days, 16 Datalex engineers and 6 AWS specialists proved migration feasibility by extracting a Reservation service into a Spring Boot microservice on Java 21. The team used agentic AI tools—Kiro and AWS Transform Custom—to automate code changes, and established repeatable patterns for DevSecOps, observability, and a multi-agent AI prototype via Amazon Bedrock AgentCore. A business service proxy using the Strangler Fig pattern enabled incremental migration with backward compatibility. The board approved significant investment, the prototype team expanded into a full Agile team, and the EBA shortened discovery from an estimated 8–12 weeks to three days.