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 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.
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.
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.
The posts behind it
AWS · · TutorialThis 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.
AWS · · TutorialEnterprises 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.
AWS · · TutorialTeams 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.
Databricks · · ExplainerTraditional 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.
AWS · · Problem & solutionDatalex, 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.
More like this
AI-DLC is an AI-driven development lifecycle that runs delivery through Inception, Design, and Construction, with specs, steering files, and hooks keeping agents aligned to agreed intent.
Apple Silicon's defining choice is one shared memory pool for CPU, GPU, and Neural Engine. This diagram maps that fabric, the on-package bandwidth it buys, and the scaling limits it imposes.
Antimicrobial resistance surveillance is a layered data architecture: raw reads and demand signals flow in, get normalized into governed tables, and answer plain-language queries. The diagram maps each boundary.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
