# Amazon EVS Getting Started Guide > Getting started guide for Amazon EVS, owned end-to-end across three launches. Written for on-prem VMware administrators new to AWS networking. Sample PDF: Download architecture sample (PDF) — https://codyanthony.dev/Cody_Anthony_Sample_1_Technical_Procedure_EVS_Architecture.pdf Rendered version: https://codyanthony.dev/case-studies/architecture-guides/evs-getting-started/ Author: Cody Anthony (https://codyanthony.dev/about/) --- This guide for Amazon Elastic VMware Service documents the networking requirements for deploying VMware Cloud Foundation (VCF) on AWS infrastructure. It’s written for VMware administrators coming from on-premises environments who are new to AWS networking constructs.
He showed an exceptional ability to quickly absorb deep technical details and translate them into clear, approachable documentation that customers could easily understand. Cody's superpower was looking around corners to anticipate where customers might struggle. His instincts and insights directly influenced multiple service changes that materially improved our customer experience. — Andy Reedy, Sr. Manager, EC2 Product Management, AWS
For more information about EVS console and API work, see [EVS Day 1 Deployment Experience](/case-studies/console-ux/evs-day1-deployment/), [EVS CreateEnvironment API Reference](/case-studies/api-documentation/evs-createenvironment/), and [Amazon EVS CloudFormation Reference](/case-studies/api-documentation/evs-cloudformation/). For workload migration with HCX, see [EVS HCX Migration & Connectivity](/case-studies/architecture-guides/evs-hcx-migration/). ## Project context The work spanned Private Preview (Q4 2024), Public Preview (Q2 2025), and General Availability (Q3 2025). For each launch, I partnered with EVS and EC2 product, UX, engineering, and solutions architects to close documentation gaps, reduce Day 1 friction, and coordinate cross-service updates. ## My role and ownership I owned the guide end-to-end: defined cross-service requirements, designed the information architecture, authored the content, and coordinated SME validation and cross-service documentation updates. I translated VMware-based networking requirements into AWS terms while defining the new Layer 2 networking constructs introduced by EVS. ## What the work solved I surfaced architectural constraints early so customers could validate service fit, network design, and compliance requirements before provisioning. - Reduced the risk of failed deployments by documenting hard requirements before environment creation, including VPC Route Server endpoint, peer, ASN, and route propagation rules. - Helped prevent security boundary misconfigurations by clarifying that network ACLs, not security groups, control traffic on Amazon EVS VLAN subnets. - Made go/no-go constraints visible before setup, including IP addressing immutability, VCF version support, and boot volume encryption limitations. ## What this sample demonstrates - Translating VMware networking requirements into AWS terms for a dual audience - Cross-service constraint documentation across Amazon EVS, VPC Route Server, route tables, BGP, and VLAN subnets - Clear security-boundary guidance for network ACLs versus security groups - Surfacing compliance and service-fit constraints before customers provision resources - Procedural writing that embeds validation checkpoints into the deployment flow ## Live documentation - [PDF excerpt — EVS Deployment Guide sample](/Cody_Anthony_Sample_1_Technical_Procedure_EVS_Architecture.pdf) - [Getting started with Amazon Elastic VMware Service](https://docs.aws.amazon.com/evs/latest/userguide/getting-started.html) - [Data protection in Amazon EVS](https://docs.aws.amazon.com/evs/latest/userguide/data-protection.html) --- **Note on authorship and excerpt selection:** This sample focuses on network architecture and security boundary configuration. I selected it to show how I documented cross-service constraints, including BGP dependencies on VPC Route Server, and service-fit limitations that customers needed to understand before provisioning. The published documentation covers these constraints across the getting-started and data protection pages. In this curated excerpt, I surface the boot volume encryption limitation earlier to illustrate my core recommendation: constraints that affect compliance or service fit should appear before customers create resources. --- ## Documentation excerpt (curated) ## Getting started with Amazon Elastic VMware Service **Important:** To get started as simply and quickly as possible, this topic specifies the minimum requirements for Amazon EVS environment creation. Before creating these resources, review the following prerequisites and architectural constraints: **Network Planning:** Plan out your IP address space and DNS record setup. You cannot change the IP addressing scheme after deployment. **VCF Version:** Amazon EVS only supports VCF version 5.2.1.x at this time. You should familiarize yourself with VCF 5.2.1 requirements. For more information, see the [VCF 5.2.1 release notes](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/vcf-release-notes/vmware-cloud-foundation-521-release-notes.html). **Boot Volume Encryption:** Amazon EVS hosts do not support encryption for the Amazon EBS boot volume at this time. Ensure this limitation meets your data residency and compliance requirements before creating an environment. --- ## Prerequisites Before getting started, you must complete the Amazon EVS prerequisite tasks. For more information, see [Setting up Amazon EVS](https://docs.aws.amazon.com/evs/latest/userguide/setting-up.html). ## Network infrastructure: dynamic routing ### Set up a VPC Route Server instance with endpoints and peers Amazon EVS uses Amazon VPC Route Server to enable BGP-based dynamic routing to your VPC underlay network. You must specify a route server that shares routes to at least two route server endpoints in the service access subnet. The peer ASN configured on the route server peers must match, and the peer IP addresses must be unique. **Important:** Your environment deployment fails if you don't meet these Amazon EVS requirements for VPC Route Server configuration: - You must configure at least two route server endpoints in the service access subnet. - When configuring Border Gateway Protocol (BGP) for the Tier-0 gateway, the VPC Route Server peer ASN value must match the NSX Edge peer ASN value. - When creating the two route server peers, you must use a unique IP address from the NSX uplink VLAN for each endpoint. These two IP addresses will be assigned to the NSX edges during Amazon EVS environment deployment. - When enabling Route Server propagation, you must ensure that all route tables being propagated have at least one explicit subnet association. BGP route advertisement fails if propagated route tables do not have an explicit subnet association. For more information about setting up VPC Route Server, see the [Route Server get started tutorial](https://docs.aws.amazon.com/vpc/latest/userguide/route-server-tutorial-create.html). --- ## Security architecture: layer 2 isolation ### Create a network ACL to control Amazon EVS VLAN subnet traffic Amazon EVS uses a network access control list (ACL) to control traffic to and from Amazon EVS VLAN subnets. **Important:** EC2 security groups do not function on elastic network interfaces that are attached to Amazon EVS VLAN subnets. To control traffic to and from Amazon EVS VLAN subnets, you must use a network access control list. For more information, see [Create a network ACL for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) in the Amazon VPC User Guide. If you plan to configure HCX internet connectivity, ensure that the network ACL rules that you configure allow the necessary inbound and outbound connections for HCX components. For more information about HCX port requirements, see the [VMware HCX User Guide](https://techdocs.broadcom.com/us/en/vmware-cis/hcx.html). --- ## Service implementation: environment configuration ### Create an Amazon EVS environment **Note:** Steps 1–5 (licensing & host configuration) omitted for brevity. **Step 6: Configure networks and connectivity** On the **Configure networks and connectivity** page, do the following: a. **For HCX connectivity requirements**, select whether you want to use HCX with private connectivity or over the internet. b. **For VPC**, choose the VPC that you previously created. c. **(For HCX internet connectivity only) For HCX network ACL**, choose which network ACL your HCX VLAN will be associated with. **Important:** We strongly recommend that you create a custom network ACL dedicated to the HCX VLAN. For more information, see [Create a network ACL to control Amazon EVS VLAN subnet traffic](#security-architecture-layer-2-isolation). d. **For Service access subnet**, choose the private subnet that was created when you created the VPC. e. **For Security group (optional)**, you can choose up to two security groups that control communication between the Amazon EVS control plane and VPC. Amazon EVS uses the default security group if no security group is chosen. **Note:** Ensure that the security groups that you choose provide connectivity to your DNS servers and Amazon EVS VLAN subnets. f. **Under Management connectivity**, enter the CIDR blocks to be used for the Amazon EVS VLAN subnets. For **HCX uplink VLAN CIDR block**, if configuring a public HCX VLAN, you must specify a CIDR block with a netmask length of exactly `/28`. Amazon EVS throws a validation error if any other CIDR block size is specified for the public HCX VLAN. For a private HCX VLAN and all other VLANs CIDR blocks, the minimum netmask length that you can use is `/28` and the maximum is `/24`. **Important:** Amazon EVS VLAN subnets can only be created during Amazon EVS environment creation, and cannot be modified after the environment is created. You must ensure that the VLAN subnet CIDR blocks are properly sized before creating the environment. You will not be able to add VLAN subnets after the environment is deployed. For more information, see [Amazon EVS networking considerations](https://docs.aws.amazon.com/evs/latest/userguide/architecture.html#evs-subnets). g. **Under Expansion VLANs**, enter the CIDR blocks for additional Amazon EVS VLAN subnets that can be used to expand VCF capabilities within Amazon EVS, such as enabling NSX Federation. h. **Under Workload/VCF connectivity**, enter the CIDR block for the NSX uplink VLAN, and choose two VPC Route Server peer IDs that peer to Route Server endpoints over the NSX uplink. i. Choose **Next**.