Amazon Elastic VMware Service (EVS)

Running Private Cloud in the Public Cloud, powered by VMware Cloud Foundation

Read the Guide View on GitHub

Amazon EVS makes the actual deployment surprisingly straightforward — you fill in your environment details through the AWS Console wizard, click deploy, and the automation takes it from there. Once initiated, a full VCF environment typically comes up in around 3 hours. Behind the scenes, AWS provisions the underlying EC2 bare-metal infrastructure and then hands off to the native VMware VCF deployment engine — Cloud Deployer — which builds out vCenter, SDDC Manager, NSX, and all VCF components exactly as it would in an on-premises deployment.

What makes or breaks a successful deployment is everything before you click deploy. Just like an on-premises VCF deployment, EVS expects a fully prepared environment — DNS resolving correctly, networking in place, IP plans finalized, licenses procured. The difference is that on-premises you have time to fix things mid-deployment; with EVS, the automation validates prerequisites upfront and will fail fast if anything is missing or misconfigured. Getting the prep right the first time is the entire point of this guide.

This guide covers every prerequisite required before submitting an Amazon EVS environment creation request. Complete all 10 steps in order — EVS will validate most of these during bring-up and fail with a specific error if any are missing.

StepPrerequisitePre-Create Required?
1AWS Account & Business Support PlanYes
2IAM Permissions & Service-Linked RoleYes
3IP Address PlanningPlan only
4VPC & Service Access SubnetYes
5Route 53 Private Zone & Inbound ResolversYes
6DHCP Options SetYes
7VPC Route Server & BGP (AWS side)Yes
8On-Demand Capacity Reservation (ODCR)Yes
9VCF Licensing (256-core key + vSAN key)Procure before bring-up
10EC2 Key PairYes

1 Step 1: AWS Account & Support Plan

Amazon EVS enforces a hard requirement on your AWS support tier. Environment creation will fail if this is not in place.

1.1 Required Support Plan

Your AWS account must be enrolled in AWS Business Support or higher (Enterprise On-Ramp or Enterprise Support). Developer Support is not sufficient. Verify your plan at AWS Console › Support › Support Plans.

1.2 Supported AWS Regions & Availability Zones

Amazon EVS is available in select regions. All EVS resources — VPC, subnets, hosts, and the Route Server — must reside in the same single AZ. EVS does not support multi-AZ deployments within a single environment. Choose your target AZ before proceeding and plan all subnets accordingly.

AWS regions supporting Amazon EVS

1.3 Transit Gateway for On-Premises Connectivity

If your EVS environment needs to communicate with on-premises networks, an AWS Transit Gateway is required. AWS does not support Direct Connect Private VIFs, VGW-based Site-to-Site VPNs, or VPC peering for EVS underlay connectivity — all external network paths must go through Transit Gateway.

Note: VPC peering is not a documented supported connectivity option for Amazon EVS. For external connectivity, use Transit Gateway.

2 Step 2: IAM Permissions & Service-Linked Role

EVS uses two distinct IAM constructs: a service-linked role that EVS manages automatically, and an identity-based policy that must be attached to the user or role initiating the deployment.

2.1 EVS Service-Linked Role

AWS automatically creates the AWSServiceRoleForEVS service-linked role on your first EVS operation. This role allows the EVS service to create and manage EC2 instances, network interfaces, subnets, and Secrets Manager secrets on your behalf. You cannot edit its permissions, but the deploying user must have permission to create it if it does not yet exist:

iam-evs-slr-policy.json — Allow SLR CreationIAM
# Attach to the user/role that will create the EVS environment
{
  "Effect": "Allow",
  "Action": "iam:CreateServiceLinkedRole",
  "Resource": "arn:aws:iam::*:role/aws-service-role/evs.amazonaws.com/AWSServiceRoleForEVS",
  "Condition": {
    "StringLike": { "iam:AWSServiceName": "evs.amazonaws.com" }
  }
}

2.2 User / Role Permissions

The principal creating the EVS environment needs the following permissions at minimum. Scope resource ARNs as tightly as practical for your environment.

ServiceRequired Actions
EVSevs:*
EC2DescribeVpcs, DescribeSubnets, DescribeInstances, RunInstances, TerminateInstances, CreateSubnet, DeleteSubnet, CreateNetworkInterface, DeleteNetworkInterface, DescribeCapacityReservations
Secrets ManagerCreateSecret, UpdateSecret, DeleteSecret, DescribeSecret
KMSDescribeKey, ListAliases (if using customer-managed keys)
IAMCreateServiceLinkedRole (scoped to EVS SLR ARN)
Best Practice: Do not use root credentials to deploy EVS. Create a dedicated IAM role or user with least-privilege permissions scoped to the deployment account and region. Alternatively, attach the AWS-managed policy AmazonEVSEnvironmentPolicy which covers the minimum permissions required to call CreateEnvironment.

3 Step 3: IP Address Planning

Plan all CIDRs before creating any AWS resources. Overlapping ranges will cause EVS bring-up to fail and cannot be corrected without redeployment. Start with the VPC CIDR (the outer boundary), then plan the VLANs that will live inside it.

3.1 VPC CIDR

The VPC CIDR is the outer boundary for every VLAN EVS will create. Choose it before anything else — it cannot be changed after an EVS environment is deployed into the VPC.

RequirementDetail
Minimum size/22 (1,024 addresses)
Recommended size/16 — provides space for all 10 EVS VLANs, Service Access Subnet, future expansion VLANs, and non-EVS subnets in the same VPC
Address spaceRFC 1918 private only: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
IPv6Not supported — IPv4 only
ImmutabilityCannot be changed after EVS deployment. Plan generously.
VLAN containmentAll VLAN CIDRs specified in CreateEnvironment must fall within this CIDR and must not overlap each other or existing subnets
On-premises overlapMust not overlap your on-premises or Transit Gateway-attached networks if you plan to use TGW for connectivity
Why /16? The /22 minimum gives exactly 1,024 addresses. EVS alone consumes space across 10 VLAN subnets plus the Service Access Subnet. A /16 (65,536 addresses) gives comfortable headroom for future VCF segments, NSX overlay networks, and any non-EVS workloads you run in the same VPC.

3.2 VLAN Address Plan

The table below shows the recommended layout for a 10.0.0.0/16 VPC. Reserve all ranges now — most subnets are created automatically by EVS during bring-up using the CIDRs you supply in the CreateEnvironment request.

Subnet / VLANPurposeAllowed SizePre-Create?Example CIDR
Service Access SubnetRoute Server endpoints, DNS Resolver ENIs/28 – /24Yes — Step 4.310.0.0.0/24
Host Management VLANESXi host management interfaces/28 – /24No — EVS creates10.0.10.0/24
Management VM VLANvCenter, SDDC Manager, NSX Managers, NSX Edges/28 – /24No — EVS creates10.0.11.0/24
vMotion VLANLive VM migration/28 – /24No — EVS creates10.0.12.0/24
vSAN VLANStorage traffic/28 – /24No — EVS creates10.0.13.0/24
Host VTEP VLANNSX host tunnel endpoints (Geneve)/28 – /24No — EVS creates10.0.14.0/24
Edge VTEP VLANNSX Edge tunnel endpoints (Geneve)/28 – /24No — EVS creates10.0.15.0/24
NSX Uplink VLANTier-0 north-south BGP peering/28 – /24No — EVS creates10.0.16.0/24
HCX Uplink VLAN(Optional) HCX-IX & HCX-NE traffic/28 – /24No — EVS creates10.0.20.0/24
Expansion VLAN 1Reserved for future VCF segments/28 – /24No — EVS creates10.0.21.0/24
Expansion VLAN 2Reserved for future VCF segments/28 – /24No — EVS creates10.0.22.0/24
Critical: Only the Service Access Subnet is pre-created by you (Step 4.3). All 10 VLAN subnets are automatically provisioned by EVS during bring-up using the CIDRs you specify in the CreateEnvironment request. Reserve these ranges now and do not create overlapping subnets in the VPC.
Sizing constraints: vMotion, vSAN, and Host VTEP VLANs must be the same size as the Host Management VLAN — they cannot be independently sized. The Host VTEP subnet consumes multiple IP addresses per host (exact count is NSX-version dependent), so size accordingly. No customer workloads (including bastion hosts or monitoring agents) may be launched in EVS-managed subnets — these are dedicated exclusively to VCF components.
HCX internet connectivity (optional): If you plan to use HCX for workload migration, AWS requires an IPAM (IP Address Manager) pool configured with public IP addresses for the HCX Uplink VLAN. Allocate at least 2 Elastic IP addresses (EIPs) from the IPAM pool — one for the HCX Manager appliance and one for the HCX Interconnect (HCX-IX) appliance. Configure the IPAM pool before EVS deployment so the EIPs are available when HCX is activated.

3.3 EVS Networking Constraints

These constraints affect your network design and must be accounted for before you commit to a topology. Review them now before creating any resources.

  • Transit Gateway required for external connectivity. Direct Connect Private VIFs, VGW-based Site-to-Site VPNs, and VPC peering are not supported for EVS underlay connectivity. All paths to on-premises or other VPCs must go through Transit Gateway.
  • S3 Gateway endpoints are not supported. To access S3 from EVS workloads, use an S3 Interface Endpoint (PrivateLink) — this provisions a private IP in your VPC that EVS workloads route to like any standard network destination, with no route table injection required.
  • Security groups do not apply to EVS VLAN subnet ENIs. NACLs are the only packet-level filtering mechanism for EVS traffic.
  • IPv6 is not supported. All EVS subnets and VLANs must use IPv4.
  • No customer workloads in EVS subnets. EVS-managed VLAN subnets are exclusively for VCF components — do not launch EC2 instances, bastion hosts, or other workloads in them.

4 Step 4: VPC & Service Access Subnet

4.1 Create the EVS VPC

Create a dedicated VPC for the EVS environment. Key requirements:

SettingRequirement
CIDR BlockMinimum /22 (1,024 addresses). Recommended /16 — provides space for all EVS VLANs, Service Access Subnet, and future growth. Must be RFC 1918 private space. Cannot be changed after EVS deployment.
IPv6Not supported
DNS HostnamesMust be enabled
DNS SupportMust be enabled
TenancyDefault (dedicated tenancy is not supported)
EVS VPC configuration in AWS console

4.2 Enable DNS on the VPC

Both DNS attributes must be enabled or EVS environment creation will fail:

AWS CLI — Enable VPC DNS AttributesCLI
aws ec2 modify-vpc-attribute --vpc-id vpc-xxxxxxxxxxxxxxxxx --enable-dns-hostnames
aws ec2 modify-vpc-attribute --vpc-id vpc-xxxxxxxxxxxxxxxxx --enable-dns-support

4.3 Create the Service Access Subnet

The Service Access Subnet is a dedicated subnet within the EVS VPC that serves as the control plane landing zone for two critical services:

  • VPC Route Server endpoints — the BGP termination points that NSX Tier-0 peers with to exchange routing information between the NSX overlay and the AWS VPC underlay
  • Route 53 Resolver inbound ENIs — the DNS interfaces that VCF components use to resolve private hostnames in the Route 53 private hosted zone

No EVS workload traffic flows through this subnet. It is strictly a management plane subnet — it carries DNS queries and BGP sessions, not VM data-plane traffic. Create it now, before Step 5, because the Route 53 Resolver endpoints (Step 5.2) must be placed into this subnet when they are created.

AWS recommendations

  • Use /24: AWS recommends a /24. Although the minimum required IPs are few (2 resolver ENIs + 2 route server endpoints), a /24 gives headroom for future infrastructure additions
  • Single AZ: Place the subnet in the same Availability Zone as the EVS environment — all EVS resources must be in a single AZ
  • Explicit route table association: The subnet must have an explicitly associated route table (not relying on the VPC main route table). Without this, BGP routes propagated by the Route Server (Step 7) will silently fail to appear
  • No workloads: Do not launch EC2 instances or other workloads in this subnet — keep it dedicated to EVS control plane services
SettingRequirement
VPCThe EVS VPC
CIDR size/24 recommended (minimum /28 for Route Server endpoints alone)
Availability ZoneSame AZ as the planned EVS environment
Route TableMust have an explicit subnet association — not just the implicit main route table. This is required for BGP route propagation in Step 7.
Service Access Subnet configuration in AWS console

Network ACL for the Service Access Subnet

The Service Access Subnet hosts both the Route 53 Resolver inbound ENIs (DNS) and the VPC Route Server endpoints (BGP). Configure the NACL now to allow both protocols. NACLs are stateless — both directions must be explicitly permitted.

DirectionProtocolPortsSource / DestinationPurpose
InboundUDP53VPC CIDRDNS queries to resolver ENIs
InboundTCP53VPC CIDRDNS over TCP to resolver ENIs
InboundTCP179 (BGP)VPC CIDRBGP sessions from NSX Edge
InboundTCP49152–65535 (ephemeral)VPC CIDRReturn traffic for outbound BGP
OutboundUDP49152–65535 (ephemeral)VPC CIDRDNS responses back to clients
OutboundTCP49152–65535 (ephemeral)VPC CIDRDNS over TCP & BGP return traffic
OutboundTCP179 (BGP)VPC CIDRBGP sessions to NSX Edge
AWS does not fail EVS bring-up if NACL rules are missing, but they are required for DNS resolution and BGP to function after deployment. Configure them now so the subnet is ready when resolvers (Step 5) and Route Server endpoints (Step 7) are placed into it.

5 Step 5: Route 53 Private Zone & Inbound Resolvers

VCF is extremely sensitive to DNS. EVS validates every DNS record during bring-up and will fail with a specific error for each missing or incorrect record. Complete this phase fully before creating the DHCP Options Set or the EVS environment.

5.1 Create the Route 53 Private Hosted Zone

Create a private hosted zone in Route 53 and associate it with the EVS VPC. Choose a domain that matches the domain_name you will put in the DHCP Options Set (e.g., evs.vcloudone.local). This domain must be unique within the VPC — do not reuse an existing zone.

Route 53 private hosted zone for EVS

5.2 Create Two Inbound Resolver Endpoints

Route 53 Resolver inbound endpoints allow VCF components running in the EVS VLANs to reach the private hosted zone. You must create two endpoints — each receives its own ENI and a dedicated IP address from the Service Access Subnet. These two IPs become the primary and secondary DNS servers in your DHCP Options Set.

Navigate to Route 53 › Resolver › Inbound endpoints › Create inbound endpoint and configure:

FieldResolver 1Resolver 2
Nameevs-dns-resolver-1evs-dns-resolver-2
VPCEVS VPCEVS VPC
Security GroupAllow UDP/TCP port 53 inbound from VPC CIDR (e.g. 10.0.0.0/16)
IP Address (AZ)10.0.0.10 — Service Access Subnet10.0.0.11 — Service Access Subnet

Note both IP addresses. They are used directly as domain-name-servers in the DHCP Options Set in Step 6.

Route 53 inbound resolver endpoints for EVS

5.3 Create DNS Records — A and PTR for All Components

All forward (A) and reverse (PTR) records must exist before EVS bring-up. Use IPs from your Management VM VLAN (10.0.11.0/24) for appliances and Host Management VLAN (10.0.10.0/24) for ESXi hosts. Create the following records in the private hosted zone:

ComponentForward A RecordReverse PTR IPVLAN
Cloud Buildercloud-builder.evs.vcloudone.local10.0.11.9Mgmt VM
ESXi Host 01esxi-01.evs.vcloudone.local10.0.10.21Host Mgmt
ESXi Host 02esxi-02.evs.vcloudone.local10.0.10.22Host Mgmt
ESXi Host 03esxi-03.evs.vcloudone.local10.0.10.23Host Mgmt
ESXi Host 04esxi-04.evs.vcloudone.local10.0.10.24Host Mgmt
SDDC Managersddc-manager.evs.vcloudone.local10.0.11.10Mgmt VM
vCenter Servervcenter.evs.vcloudone.local10.0.11.11Mgmt VM
NSX Manager 01nsx-mgr-01.evs.vcloudone.local10.0.11.12Mgmt VM
NSX Manager 02nsx-mgr-02.evs.vcloudone.local10.0.11.13Mgmt VM
NSX Manager 03nsx-mgr-03.evs.vcloudone.local10.0.11.14Mgmt VM
NSX Edge 01nsx-edge-01.evs.vcloudone.local10.0.11.21Mgmt VM
NSX Edge 02nsx-edge-02.evs.vcloudone.local10.0.11.22Mgmt VM
HCX Manager(Optional) hcx.evs.vcloudone.local10.0.20.10HCX Uplink
DNS A records for EVS components in Route 53

Also create reverse lookup (PTR) zones for each subnet: 10.0.10.in-addr.arpa (Host Mgmt) and 11.0.10.in-addr.arpa (Mgmt VM), associated with the EVS VPC.

Reverse PTR zone for Host Management VLAN (10.0.10.x) Reverse PTR zone for Management VM VLAN (10.0.11.x)
DNS Validation: EVS performs DNS resolution checks for every record listed above during environment creation. Missing A records, missing PTR records, or records that resolve to wrong IPs will cause bring-up to fail with a specific validation error. Do not proceed to Step 6 until all records resolve correctly.

5.4 Alternative: Use Your Own DNS Server (Optional)

If your organization already runs its own DNS infrastructure — Microsoft DNS, Infoblox, BIND, or any other provider — you can skip Steps 5.1 and 5.2 and use it instead of Route 53. Your DNS server must be reachable from the EVS VPC on UDP/TCP port 53, either running as a VM inside the VPC or accessible via Transit Gateway from on-premises.

RequirementDetails
ReachabilityDNS server IPs must be reachable from the EVS VPC on UDP/TCP port 53
Two server IPsEVS requires both a primary and secondary DNS IP in the DHCP Options Set — ensure two IPs are available (two servers, or one server with two IPs)
RecordsAll A and PTR records from Step 5.3 must still be created on your DNS server — the record requirements do not change
Forward & reverse zonesBoth forward and reverse (PTR) zones must exist, just as they would in Route 53
Domain nameMust exactly match what you enter in the DHCP Options Set domain name field

6 Step 6: DHCP Options Set

The DHCP Options Set tells EVS-managed hosts how to resolve DNS and synchronize time. It must be associated with the VPC before environment creation — not after.

6.1 Create and Associate the DHCP Options Set

Navigate to VPC › DHCP Option Sets › Create DHCP options set and configure:

FieldValueNotes
Domain nameevs.vcloudone.localMust exactly match the Route 53 private hosted zone name
Domain name servers10.0.0.10, 10.0.0.11The two inbound resolver IPs from Step 5.2 — primary first
NTP servers169.254.169.123AWS Time Sync Service — link-local, no internet required

After creating the set, associate it with the EVS VPC: select the VPC › Actions › Edit DHCP options set › choose the new set.

DHCP Options Set configuration for EVS
Why two DNS servers? EVS validates that both primary and secondary DNS IPs are reachable from the VPC before proceeding with bring-up. A single DNS server is not sufficient — if it fails, VCF has no fallback and bring-up will stall.

6.2 Alternative: Use Your Own NTP Server (Optional)

If your organization runs its own NTP infrastructure, replace 169.254.169.123 with your NTP server IP in the DHCP Options Set. Your NTP server must be reachable from the EVS VPC. Time accuracy is critical for VCF — certificate validation, vSAN, and NSX all depend on synchronized time across all hosts and management VMs.

When using your own DNS and NTP, configure the DHCP Options Set as follows:

FieldValueNotes
Domain nameYour DNS zone nameMust exactly match the zone on your DNS server
Domain name serversYour DNS server IPs (primary, secondary)Both must be reachable from the VPC on port 53
NTP serversYour NTP server IPMust be reachable from the VPC

7 Step 7: VPC Route Server & BGP

The VPC Route Server is the BGP bridge between the AWS underlay and the NSX overlay. You configure the AWS side entirely before bring-up. NSX Tier-0 BGP is automatically configured by EVS during environment creation — you do not need to touch NSX for this.

7.1 Create the VPC Route Server

Navigate to VPC › Route Servers › Create route server:

FieldValueNotes
Amazon Side ASNe.g. 65100Must be a private ASN — 16-bit range 64512–65534 or 32-bit range 4200000000–4294967294. Must differ from NSX Tier-0 ASN (default 65000).
Persist RoutesEnabledPreserves routes for 1–5 min after BGP session drops; prevents route flaps during maintenance
SNS NotificationsRecommendedAlerts on BGP state changes in production

Wait for Route Server status to reach Available before proceeding.

VPC Route Server creation in AWS console

7.2 Associate with the Service Access Subnet

Select the Route Server › Associations › Associate route server. Select the Service Access Subnet created in Step 4.3. AWS will automatically deploy two Route Server endpoints into that subnet. Note the IP address of each endpoint — EVS uses these as the BGP neighbor addresses when it auto-configures the NSX Tier-0 gateway during bring-up.

7.3 Create Two Route Server Peers

Navigate to Route server peers › Create route server peer. Create one peer per NSX Edge node. The peer address must be an IP from the NSX Uplink VLAN CIDR (e.g., 10.0.16.0/24) — these IPs will be assigned to NSX Edge uplink interfaces during EVS bring-up.

FieldPeer 1 (Edge 01)Peer 2 (Edge 02)
Route Server EndpointEndpoint 1 IDEndpoint 2 ID
Peer Address10.0.16.10 (NSX Uplink VLAN)10.0.16.11 (NSX Uplink VLAN)
Peer ASN65000 (NSX default)65000 (NSX default)
Liveness DetectionBGP KeepaliveBGP Keepalive
Important: Use BGP Keepalive only. BFD (Bidirectional Forwarding Detection) is not supported for Amazon EVS and will cause undefined session behavior.
Route Server endpoint peering configuration

7.4 Enable Route Propagation

Select the Route Server › Propagations › Create propagation. Select the Service Access Subnet route table and any workload subnet route tables that need to receive NSX overlay routes.

Common failure: Every propagated route table must have an explicit subnet association. Route tables that only have the implicit main-route-table association will silently fail to receive BGP routes. Verify explicit associations exist before proceeding.
Route Server route propagation to service access route table
NSX Tier-0 BGP is auto-configured. EVS automatically configures the NSX Tier-0 gateway BGP neighbors using the Route Server endpoint IPs and the peer ASN you specified. You do not need to log into NSX Manager to configure BGP — this is handled entirely during EVS bring-up.

8 Step 8: On-Demand Capacity Reservation (ODCR)

Amazon EVS runs on bare-metal instances. Because bare-metal capacity can be constrained in specific AZs, AWS recommends creating an On-Demand Capacity Reservation (ODCR) before deployment to improve your chances of securing capacity. At the time of writing, i4i.metal is the only supported instance type. Additional instance types — including i7i.metal-24xl and i7i.metal-48xl — are coming. Choose the instance type that matches your planned EVS environment.

8.1 Supported Instance Types

Instance TypevCPUsPhysical CoresNVMe StorageAvailability
i4i.metal12864Up to 30 TBAvailable now
i7i.metal-24xl9648Up to 15 TBComing soon
i7i.metal-48xl19296Up to 30 TBComing soon

8.2 Create the Capacity Reservation

SettingValue
Instance typeSelect the instance type for your EVS environment (see table above)
PlatformLinux/UNIX
QuantityMinimum 4 (match your planned cluster size; max 16)
Availability ZoneMust be the same AZ as the EVS environment
Reservation typeTargeted (recommended for security; open also works)
End dateNo end date (or set beyond your planned deployment window)
AWS CLI — Create ODCR for 4 EVS HostsCLI
aws ec2 create-capacity-reservation \
  --availability-zone us-east-1a \
  --instance-type i4i.metal \
  --instance-platform Linux/UNIX \
  --instance-count 4 \
  --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=Name,Value=evs-odcr-mgmt}]'

# Verify it reaches 'active' state before proceeding
aws ec2 describe-capacity-reservations \
  --query 'CapacityReservations[*].[CapacityReservationId,State,AvailableInstanceCount]'
EC2 vCPU Quota: The required vCPU quota depends on your chosen instance type. A 4-host cluster requires: 512 vCPUs for i4i.metal  |  384 vCPUs for i7i.metal-24xl  |  768 vCPUs for i7i.metal-48xl. Check and request a quota increase at Service Quotas › Amazon EC2 › Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances before deployment if needed.

9 Step 9: VCF Licensing

Amazon EVS is a BYOL (Bring Your Own License) service. Procure all three items from Broadcom before bring-up — you will enter them into the CreateEnvironment wizard during deployment.

9.1 Required License Keys

LicenseMinimumNotes
VCF Solution KeyVaries by instance typeCore count is based on physical cores × 4 hosts: 256 cores for i4i.metal (64 cores/host)  |  192 cores for i7i.metal-24xl (48 cores/host)  |  384 cores for i7i.metal-48xl (96 cores/host). Covers vSphere 8 Enterprise Plus, NSX, SDDC Manager, vCenter. Each key can only be assigned to one EVS environment.
vSAN License Key110 TiBCovers the vSAN storage capacity of the initial 4-host cluster. Cannot be reused across environments.
Broadcom Site IDRequiredYour organization's Broadcom support portal site ID, used for license validation and entitlement verification.
Validate your keys against your host count at the Broadcom support portal before deployment — a VCF Solution Key covering fewer cores than your cluster requires will cause CreateEnvironment to fail.

10 Step 10: EC2 Key Pair

10.1 EC2 Key Pair

Create an EC2 key pair in the same region as the EVS environment. This key pair is used for SSH access to ESXi hosts during and after deployment. Navigate to EC2 › Key Pairs › Create key pair. Store the private key securely — it cannot be recovered after creation.

Pre-Deployment Checklist

Complete all 10 steps before submitting CreateEnvironment. Use this checklist as your final gate — EVS validates most of these during bring-up and will fail with a specific error for anything missing.

CheckStepVerified?
AWS Business Support (or higher) active1
Transit Gateway configured (if on-premises connectivity required)1.3
IAM user/role has EVS + EC2 + SLR permissions2
VPC CIDR chosen (/16 recommended), RFC 1918, no on-premises overlap3.1
All VLAN CIDRs planned, non-overlapping, within VPC CIDR3.2
VPC created with /22+ CIDR, DNS enabled4.1
Service Access Subnet created with explicit route table association4.3
Service Access Subnet NACL allows UDP/TCP 53 (DNS) and TCP 179 (BGP)4.3
Route 53 private hosted zone created and VPC-associated5.1
Two inbound resolver endpoints created (IPs noted)5.2
All A and PTR records created and resolving correctly5.3
DHCP Options Set created with domain, 2 DNS IPs, NTP — associated with VPC6
VPC Route Server in Available state7.1
Two Route Server endpoints in Available state7.2
Two BGP peers created (NSX Uplink VLAN IPs, BGP Keepalive)7.3
Route propagation enabled on Service Access Subnet route table7.4
ODCR created for target instance type in correct AZ (state: active) — recommended8
EC2 vCPU quota sufficient for planned cluster size8
VCF Solution Key procured (core count matches instance type × hosts)9
vSAN License Key procured (110+ TiB)9
Broadcom Site ID available9
EC2 key pair created in target region10

Automation: Terraform Deployment

The EVS-PreREQ-Terraform kit automates Steps 2, 4–7: IAM policy, VPC, service access subnet, DNS resolvers, Route 53 records, DHCP options set, and Route Server with BGP peers. Step 3 (IP address planning) requires no AWS resources. Step 8 (ODCR) is included in odcr.tf as commented-out code — uncomment when ready. All defaults match the IP plan in this guide and are production-ready.

File descriptions

File Step What it creates
variables.tf All configurable values: region, AZ, CIDRs, domain, IPs, ASNs, host maps. Edit this file before applying.
main.tf 2, 4, 5, 6 VPC, service access subnet, explicit route table, Network ACL (DNS + BGP), DNS security group, Route 53 inbound resolver endpoint (2 IPs), DHCP options set, EVS service-linked role
dns.tf 5 Route 53 private hosted zone, two reverse PTR zones (Host VLAN + Mgmt VLAN), A and PTR records for all VCF components and ESXi hosts
peering.tf 7 VPC Route Server, VPC association, two Route Server endpoints in the service access subnet, two BGP peers (NSX Edge uplink IPs, bgp-keepalive), route propagation to the explicit route table
iam.tf 2 EVSDeploymentPolicy — minimum IAM policy for the user or role that calls CreateEnvironment
odcr.tf 8 On-Demand Capacity Reservation for i4i.metal — all code is commented out. Uncomment when EC2 vCPU quota ≥ 512 and you are ready to reserve capacity.
outputs.tf Prints all resource IDs, IPs, and zone IDs after apply — useful for cross-checking against the EVS Console during bring-up
providers.tf Terraform ≥ 1.5 and AWS provider ≥ 5.84 (required for Route Server resources). No remote state — local backend.

Customizing variables.tf

Open variables.tf and update the following before running terraform apply. The defaults match the IP plan in this guide — change them to match your environment.

variables.tf — values to update for your environmentv2.0
# ── Target region and AZ ──────────────────────────────────────────────────────
# All EVS resources must be in the same AZ.
variable "aws_region" { default = "us-east-1" }   # change to your region
variable "az"         { default = "us-east-1a" } # change to your target AZ

# ── VPC & subnet CIDRs ────────────────────────────────────────────────────────
# vpc_cidr minimum /22 — cannot be changed after EVS deployment.
# service_access_cidr hosts the Route Server endpoints and DNS resolver ENIs.
variable "vpc_cidr"            { default = "10.0.0.0/16"  }
variable "service_access_cidr" { default = "10.0.0.0/24"  }

# ── DNS domain ────────────────────────────────────────────────────────────────
# Must match the Route 53 private hosted zone name exactly.
# All VCF components are registered under this domain.
variable "domain_name" { default = "evs.vcloudone.local" }

# ── Resolver IPs ──────────────────────────────────────────────────────────────
# Two static IPs within service_access_cidr.
# These become the DHCP domain-name-servers — must be stable and ordered.
variable "resolver_ip_1" { default = "10.0.0.10" }  # primary DNS
variable "resolver_ip_2" { default = "10.0.0.11" }  # secondary DNS

# ── BGP ASNs ──────────────────────────────────────────────────────────────────
# route_server_asn: VPC Route Server ASN — must differ from nsx_peer_asn.
# nsx_peer_asn: NSX Tier-0 ASN — default NSX value is 65000.
variable "route_server_asn" { default = 65100 }
variable "nsx_peer_asn"     { default = 65000 }

# ── VCF component IPs ─────────────────────────────────────────────────────────
# Must be in the Management VM VLAN (default 10.0.11.x).
# A and PTR records are created for every entry in this map.
variable "vcf_components" {
  default = {
    "cloud-builder" = "10.0.11.9"
    "sddc-manager"  = "10.0.11.10"
    "vcenter"       = "10.0.11.11"
    "nsx-mgr-01"    = "10.0.11.12"
    "nsx-mgr-02"    = "10.0.11.13"
    "nsx-mgr-03"    = "10.0.11.14"
    "nsx-edge-01"   = "10.0.11.21"
    "nsx-edge-02"   = "10.0.11.22"
  }
}

# ── ESXi host IPs ─────────────────────────────────────────────────────────────
# Must be in the Host Management VLAN (default 10.0.10.x).
# Add or remove entries to match your host count (minimum 4 for EVS).
variable "esxi_hosts" {
  default = {
    "esxi-01" = "10.0.10.21"
    "esxi-02" = "10.0.10.22"
    "esxi-03" = "10.0.10.23"
    "esxi-04" = "10.0.10.24"
  }
}

# ── Reverse DNS zone names ────────────────────────────────────────────────────
# Must match the /24 prefix of the IPs in esxi_hosts and vcf_components.
# Format: third-octet.second-octet.first-octet.in-addr.arpa
# If you change the host or management VM subnet, update these too.
variable "host_mgmt_reverse_zone" { default = "10.0.10.in-addr.arpa" }  # matches 10.0.10.0/24
variable "mgmt_vm_reverse_zone"   { default = "11.0.10.in-addr.arpa" }  # matches 10.0.11.0/24

# ── NSX Edge uplink IPs ───────────────────────────────────────────────────────
# IPs assigned to NSX Edge uplink interfaces during EVS bring-up.
# Must be within the NSX Uplink VLAN (default 10.0.16.x).
# These are configured as Route Server BGP peer addresses.
variable "nsx_edge_peer_ips" {
  default = {
    "edge-01" = "10.0.16.10"
    "edge-02" = "10.0.16.11"
  }
}

Usage

terminalbash
# 1. Clone and enter the repo
git clone https://github.com/gitvcloudone/EVS-PreREQ-Terraform.git
cd EVS-PreREQ-Terraform

# 2. Edit variables.tf with your region, AZ, CIDRs, IPs, and hostnames
#    (see table above — at minimum update aws_region, az, and domain_name)

# 3. Initialize providers (downloads hashicorp/aws ~= 5.84)
terraform init

# 4. Preview what will be created — review before applying
terraform plan

# 5. Deploy (~45 resources, typically completes in 3-5 minutes)
terraform apply

# 6. Review outputs — all resource IDs and IPs are printed
terraform output
ODCR (Step 8): The odcr.tf file contains a commented-out aws_ec2_capacity_reservation resource for i4i.metal. Uncomment it when your EC2 vCPU On-Demand Standard quota is ≥ 512 and you are ready to reserve capacity before deploying EVS. The reservation uses instance_match_criteria = "targeted" so only your EVS deployment will consume it.

Terraform file reference

main.tf — VPC, Subnet, Route Table, Resolvers, DHCP, SLRv2.0
# Phase 4 — VPC & Service Access Subnet
resource "aws_vpc" "evs_vpc" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "evs-vpc" }
}

# Phase 4 — Service Access Subnet + explicit route table association
# Explicit association is required — propagated route tables without it
# silently fail to receive BGP routes from the Route Server.
resource "aws_subnet" "service_access" {
  vpc_id            = aws_vpc.evs_vpc.id
  cidr_block        = var.service_access_cidr
  availability_zone = var.az
}
resource "aws_route_table" "service_access" {
  vpc_id = aws_vpc.evs_vpc.id
  tags   = { Name = "evs-service-access-rt" }
}
resource "aws_route_table_association" "service_access" {
  subnet_id      = aws_subnet.service_access.id
  route_table_id = aws_route_table.service_access.id
}

# Phase 5 — Route 53 Inbound Resolver Endpoint
# AWS requires a minimum of 2 IPs per resolver endpoint.
# Explicit IPs (not dynamic lookup) ensure stable ordering in DHCP options.
resource "aws_route53_resolver_endpoint" "evs_dns" {
  name               = "evs-dns-resolver"
  direction          = "INBOUND"
  security_group_ids = [aws_security_group.dns_sg.id]
  ip_address { subnet_id = aws_subnet.service_access.id; ip = var.resolver_ip_1 }
  ip_address { subnet_id = aws_subnet.service_access.id; ip = var.resolver_ip_2 }
  tags = { Name = "evs-dns-resolver" }
}

# Phase 6 — DHCP Options Set
# domain_name must match the Route 53 private hosted zone exactly.
# NTP uses AWS Time Sync Service (169.254.169.123) — no internet required.
resource "aws_vpc_dhcp_options" "evs_dhcp" {
  domain_name         = var.domain_name
  domain_name_servers = [var.resolver_ip_1, var.resolver_ip_2]
  ntp_servers         = ["169.254.169.123"]
}
resource "aws_vpc_dhcp_options_association" "evs" {
  vpc_id          = aws_vpc.evs_vpc.id
  dhcp_options_id = aws_vpc_dhcp_options.evs_dhcp.id
}

# Phase 2 — EVS Service-Linked Role
resource "aws_iam_service_linked_role" "evs" {
  aws_service_name = "evs.amazonaws.com"
}

# Phase 9 — On-Demand Capacity Reservation (ODCR) — uncomment to enable
# Requires EC2 vCPU quota ≥ 512 (4 × i4i.metal × 128 vCPUs).
# instance_match_criteria = "targeted" means only launches that explicitly
# reference this reservation ID will consume capacity.
#
# resource "aws_ec2_capacity_reservation" "evs_hosts" {
#   instance_type           = "i4i.metal"
#   instance_platform       = "Linux/UNIX"
#   availability_zone       = var.az
#   instance_count          = 4
#   instance_match_criteria = "targeted"
#   tags                    = { Name = "evs-odcr" }
# }
peering.tf — Route Server, Endpoints, BGP Peers, Propagationv2.0
# Route Server ASN must differ from NSX Tier-0 ASN (default 65000).
# persist_routes prevents route flaps during brief BGP session drops.
resource "aws_vpc_route_server" "evs_rs" {
  amazon_side_asn         = var.route_server_asn  # default 65100
  persist_routes          = "enable"
  persist_routes_duration = 2
}
resource "aws_vpc_route_server_vpc_association" "evs_rs_vpc" {
  route_server_id = aws_vpc_route_server.evs_rs.route_server_id
  vpc_id          = aws_vpc.evs_vpc.id
}

# Two endpoints in the Service Access Subnet.
# EVS reads these endpoint IPs and auto-configures NSX Tier-0 BGP neighbors
# during bring-up — no manual NSX configuration required.
resource "aws_vpc_route_server_endpoint" "ep1" {
  route_server_id = aws_vpc_route_server.evs_rs.route_server_id
  subnet_id       = aws_subnet.service_access.id
  depends_on      = [aws_vpc_route_server_vpc_association.evs_rs_vpc]
}
resource "aws_vpc_route_server_endpoint" "ep2" {
  route_server_id = aws_vpc_route_server.evs_rs.route_server_id
  subnet_id       = aws_subnet.service_access.id
  depends_on      = [aws_vpc_route_server_vpc_association.evs_rs_vpc]
}

# Peer IPs are NSX Edge uplink IPs from the NSX Uplink VLAN (10.0.16.x).
# BFD is not supported for EVS — always use bgp-keepalive.
resource "aws_vpc_route_server_peer" "edge_01" {
  route_server_endpoint_id = aws_vpc_route_server_endpoint.ep1.route_server_endpoint_id
  peer_address             = var.nsx_edge_peer_ips["edge-01"]  # 10.0.16.10
  bgp_options {
    peer_asn                = var.nsx_peer_asn  # 65000
    peer_liveness_detection = "bgp-keepalive"
  }
}
resource "aws_vpc_route_server_peer" "edge_02" {
  route_server_endpoint_id = aws_vpc_route_server_endpoint.ep2.route_server_endpoint_id
  peer_address             = var.nsx_edge_peer_ips["edge-02"]  # 10.0.16.11
  bgp_options {
    peer_asn                = var.nsx_peer_asn
    peer_liveness_detection = "bgp-keepalive"
  }
}

# Propagate NSX overlay routes into the explicitly-associated route table.
resource "aws_vpc_route_server_propagation" "service_access_rt" {
  route_server_id = aws_vpc_route_server.evs_rs.route_server_id
  route_table_id  = aws_route_table.service_access.id
  depends_on      = [aws_route_table_association.service_access]
}
dns.tf — Private Zone, A Records, PTR Records (both VLANs)v2.0
resource "aws_route53_zone" "forward" {
  name = var.domain_name
  vpc { vpc_id = aws_vpc.evs_vpc.id }
}
# Host Management VLAN reverse zone (ESXi hosts — 10.0.10.x)
# Driven by var.host_mgmt_reverse_zone — update if you change esxi_hosts subnet.
resource "aws_route53_zone" "host_mgmt_reverse" {
  name = var.host_mgmt_reverse_zone
  vpc { vpc_id = aws_vpc.evs_vpc.id }
}
# Management VM VLAN reverse zone (appliances — 10.0.11.x)
# Driven by var.mgmt_vm_reverse_zone — update if you change vcf_components subnet.
resource "aws_route53_zone" "mgmt_vm_reverse" {
  name = var.mgmt_vm_reverse_zone
  vpc { vpc_id = aws_vpc.evs_vpc.id }
}

# VCF appliance A + PTR records (cloud-builder, sddc-manager, vcenter,
# nsx-mgr-01/02/03, nsx-edge-01/02) — all in Management VM VLAN (10.0.11.x)
resource "aws_route53_record" "vcf_a" {
  for_each = var.vcf_components
  zone_id  = aws_route53_zone.forward.zone_id
  name     = "${each.key}.${var.domain_name}"
  type     = "A"; ttl = 300; records = [each.value]
}
resource "aws_route53_record" "vcf_ptr" {
  for_each = var.vcf_components
  zone_id  = aws_route53_zone.mgmt_vm_reverse.zone_id
  name     = element(split(".", each.value), 3)  # last octet only
  type     = "PTR"; ttl = 300
  records  = ["${each.key}.${var.domain_name}."]
}

# ESXi host A + PTR records — Host Management VLAN (10.0.10.x)
resource "aws_route53_record" "esxi_a" {
  for_each = var.esxi_hosts
  zone_id  = aws_route53_zone.forward.zone_id
  name     = "${each.key}.${var.domain_name}"
  type     = "A"; ttl = 300; records = [each.value]
}
resource "aws_route53_record" "esxi_ptr" {
  for_each = var.esxi_hosts
  zone_id  = aws_route53_zone.host_mgmt_reverse.zone_id
  name     = element(split(".", each.value), 3)
  type     = "PTR"; ttl = 300
  records  = ["${each.key}.${var.domain_name}."]
}

Automation: Prerequisite Validator

The EVS-PreREQ-Validate script uses boto3 to auto-discover every non-default VPC in your account and validate it against EVS prerequisites — no input required. Run it against a manually-built environment or after running the Terraform kit above to confirm everything is wired correctly end-to-end.

↓ Download .zip View on GitHub →

Prerequisites

  • Python 3.8 or later
  • AWS credentials configured (aws configure, IAM instance role, or environment variables)
  • boto3 (pip install boto3)
  • IAM permissions: ec2:Describe*, iam:ListRoles, iam:GetPolicy, route53:*, route53resolver:ListResolverEndpoints, route53resolver:ListResolverEndpointIpAddresses, servicequotas:GetServiceQuota, support:DescribeSeverityLevels

Installation & usage

terminalbash
# Install boto3 if not already installed
pip install boto3

# Clone the validator
git clone https://github.com/gitvcloudone/EVS-PreREQ-Validate.git
cd EVS-PreREQ-Validate

# Run against default region (from AWS config / environment)
python evs_validate.py

# Run against a specific region
python evs_validate.py --region us-east-1
python evs_validate.py --region eu-west-1

Expected output

The script runs account-level checks first, then iterates every non-default VPC. Each check prints PASS, FAIL, or WARN. A summary with total counts is printed at the end. The exit code is 0 (all pass), 1 (failures), or 2 (credential error).

evs_validate.py — annotated sample outputPython / boto3
================================================================
  Amazon EVS Prerequisite Validator
  Region : us-east-1   Account : 123456789012
================================================================

── Phase 2: IAM
  ✓ PASS  AWSServiceRoleForEVS service-linked role exists
  ✓ PASS  EVSDeploymentPolicy found (arn:aws:iam::123456789012:policy/EVSDeploymentPolicy)
  # FAIL here means the SLR or policy was never created — run the Terraform kit
  # or create them manually before calling CreateEnvironment.

── EC2 vCPU Service Quota
  ✓ PASS  vCPU quota = 512  — meets minimum for 4 × i4i.metal
  # FAIL: quota = 256 — request increase at Service Quotas > Amazon EC2 >
  # "Running On-Demand Standard instances" before deploying EVS.

── AWS Support Plan
  ✓ PASS  Support plan is Business or higher
  # FAIL: Basic/Developer plan — EVS CreateEnvironment will be rejected.
  # Upgrade to Business, Enterprise On-Ramp, or Enterprise.

── VPC Auto-Discovery
    INFO  Found 1 non-default VPC(s)
  # The script skips the default VPC. If you see 0, your VPC hasn't been created.

================================================================
VPC: evs-vpc  (vpc-0f75dd807fc01abb9)  CIDR: 10.0.0.0/16
================================================================

── Phase 4: VPC
  ✓ PASS  CIDR 10.0.0.0/16 meets minimum /22 requirement
  ✓ PASS  DNS hostnames enabled
  ✓ PASS  DNS support enabled

── Phase 6: DHCP Options Set
  ✓ PASS  Domain name = 'evs.vcloudone.local'
  ✓ PASS  DNS servers: 10.0.0.10, 10.0.0.11
  ✓ PASS  NTP = 169.254.169.123 (AWS Time Sync Service)
  # FAIL on domain_name: DHCP domain must match the Route 53 zone exactly.
  # FAIL on DNS servers: printed IPs must match resolver endpoint IPs (see below).
  # FAIL on NTP: 169.254.169.123 must be in the list — no internet required.

── Phase 5: Route 53 Private Zones
  ✓ PASS  Forward zone(s): ['evs.vcloudone.local']
  ✓ PASS  Reverse PTR zone(s): ['11.0.10.in-addr.arpa', '10.0.10.in-addr.arpa']
    INFO  Zone: evs.vcloudone.local  (Z04587343LEL3Z83E8QNP)  records: 14
  ✓ PASS  DHCP domain 'evs.vcloudone.local' matches Route 53 zone
  # FAIL if no forward zone: create the private hosted zone and associate with the VPC.
  # FAIL if no reverse zones: EVS requires PTR zones for both ESXi and Mgmt VLANs.
  # records: 14 = 4 ESXi A/PTR + 8 VCF component A/PTR records — verify count matches.

── Phase 5: Route 53 Inbound Resolver Endpoint
  ✓ PASS  Inbound resolver endpoint(s): ['evs-dns-resolver']
  ✓ PASS    'evs-dns-resolver' — IPs: 10.0.0.11, 10.0.0.10  (status: OPERATIONAL)
  ✓ PASS    Resolver IPs ['10.0.0.11', '10.0.0.10'] are present in DHCP DNS servers
  # FAIL on resolver: create an INBOUND resolver endpoint with ≥ 2 IPs in the VPC.
  # FAIL on cross-check: DHCP domain-name-servers must exactly match resolver IPs.
  # FAIL if status is not OPERATIONAL: resolver endpoint is still provisioning.

── Phase 4: Service Access Subnet & Route Tables
  ✓ PASS  1 subnet(s) across AZs: us-east-1a(1)
  ✓ PASS  Explicit route table(s): ['rtb-0b7c5516a85491e95']
  ✓ PASS  Explicit subnet association(s): ['subnet-003763d6fb9af8fca']
  # FAIL on explicit route table: the main (implicit) VPC route table does not count.
  # A dedicated route table with an explicit subnet association is required so BGP
  # routes propagated by the Route Server are received by this subnet.

── Phase 7: NACL & Security Groups
  ✓ PASS  Custom NACL(s): ['acl-06980e7ddc52a53cb']
  ✓ PASS  Security group(s) with port 53 rule: ['evs-dns-sg', 'default']
  ✓ PASS  Security group(s) with port 179 rule: ['VPCRouteServer-rse-...', 'default']
  # FAIL on port 179: the Route Server auto-creates its own SGs but verify they exist.
  # FAIL on custom NACL: the default VPC NACL does not count — create one explicitly.

── Phase 7: VPC Route Server & BGP
  ✓ PASS  Route Server(s): ['rs-0e8e3f3e2278e29fa']
  ✓ PASS    Route Server rs-0e8e3f3e2278e29fa  ASN 65100  state: available
  ✓ PASS    Endpoints: 2  IPs: ['10.0.0.47', '10.0.0.90']
  ✓ PASS    2 BGP peer(s) configured with bgp-keepalive liveness
  ✓ PASS    Route propagation: 1 route table(s)  ['rtb-0b7c5516a85491e95']
  ✓ PASS    Propagation -> rtb-0b7c5516a85491e95 (explicit route table — correct)
  # FAIL on BGP peers: expected before EVS bring-up — NSX Edge IPs are configured
  #   during CreateEnvironment. This FAIL is normal at pre-deployment time.
  # FAIL on propagation targeting main RT: BGP routes would be silently dropped.
  #   Propagation must point to the explicit route table, not the VPC main table.

── Phase 9: On-Demand Capacity Reservation (ODCR)
  ⚠ WARN  No active i4i.metal ODCR in us-east-1a — create before deploying EVS
  # WARN (not FAIL) — optional until CreateEnvironment is called.
  # Create an ODCR for i4i.metal with instance_match_criteria = "targeted"
  # before deploying to guarantee capacity.

================================================================
SUMMARY  (29 checks across 1 VPC(s))
   27 PASS    0 FAIL    1 WARN

Exit code 0 — environment is ready for EVS deployment.
================================================================