Setting up Amazon Elastic VMware Service
To use Amazon EVS, you will need to configure other AWS services, as well as set up your environment to meet VMware Cloud Foundation (VCF) requirements. For a summary checklist of deployment prerequisites, see Amazon EVS deployment prerequisite checklist.
Topics
Sign up for AWS
If you don’t have an AWS account, complete the following steps to create one.
-
Follow the online instructions.
Create an IAM user
-
Sign in to the IAM console
as the account owner by choosing Root user and entering your AWS account email address. On the next page, enter your password. Note
We strongly recommend that you adhere to the best practice of using the
Administrator
IAM user below and securely lock away the root user credentials. Sign in as the root user only to perform a few account and service management tasks. -
In the navigation pane, choose Users and then choose Create user.
-
For User name, enter
Administrator
. -
Select the check box next to AWS Management Console access. Then select Custom password, and then enter your new password in the text box.
-
(Optional) By default, AWS requires the new user to create a new password when first signing in. You can clear the check box next to User must create a new password at next sign-in to allow the new user to reset their password after they sign in.
-
Choose Next: Permissions.
-
Under Set permissions, choose Add user to group.
-
Choose Create group.
-
In the Create group dialog box, for Group name enter
Administrators
. -
Choose Filter policies, and then select AWS managed -job function to filter the table contents.
-
In the policy list, select the check box for AdministratorAccess. Then choose Create group.
Note
You must activate IAM user and role access to Billing before you can use the
AdministratorAccess
permissions to access the AWS Billing and Cost Management console. To do this, follow the instructions in step 1 of the tutorial about delegating access to the billing console. -
Back in the list of groups, select the check box for your new group. Choose Refresh if necessary to see the group in the list.
-
Choose Next: Tags.
-
(Optional) Add metadata to the user by attaching tags as key-value pairs. For more information about using tags in IAM, see Tagging IAM Entities in the IAM User Guide.
-
Choose Next: Review to see the list of group memberships to be added to the new user. When you are ready to proceed, choose Create user.
You can use this same process to create more groups and users and to give your users access to your AWS account resources. To learn about using policies that restrict user permissions to specific AWS resources, see Access Management and Example Policies.
Create an IAM role to delegate Amazon EVS permission to an IAM user
You can use roles to delegate access to your AWS resources. With IAM roles, you can establish trust relationships between your trusting account and other AWS trusted accounts. The trusting account owns the resource to be accessed, and the trusted account contains the users who need access to the resource.
After you create the trust relationship, an IAM user or an application from the trusted account can use the AWS Security Token Service (AWS STS) AssumeRole
API operation.
This operation provides temporary security credentials that enable access to AWS resources in your account.
For more information, see Create a role to delegate permissions to an IAM user in the
AWS Identity and Access Management User Guide.
Follow these steps to create an IAM role with a permissions policy that allows access to Amazon EVS operations.
Note
Amazon EVS does not support the use of an instance profile to pass an IAM role to an EC2 instance.
Sign up for an AWS Business, AWS Enterprise On-Ramp, or AWS Enterprise Support plan
Amazon EVS requires that customers are enrolled in an AWS Business, AWS Enterprise On-Ramp, or AWS Enterprise Support plan to receive continuous access to technical support and architectural guidance.
AWS Business Support is the minimum AWS Support tier that meets Amazon EVS requirements.
If you have business-critical workloads, we recommend enrolling in AWS Enterprise On-Ramp or AWS Enterprise Support plans.
For more information, see Compare AWS Support Plans
Important
Amazon EVS environment creation fails if you do not sign up for an AWS Business, AWS Enterprise On-Ramp, or an AWS Enterprise Support plan.
Check quotas
To enable Amazon EVS environment creation, ensure that your account has the required minimum account-level quotas. For more information, see Amazon EVS service quotas.
Important
Amazon EVS environment creation fails if the host count per EVS environment quota value is not at least 4.
Plan VPC CIDR sizes
When you create an Amazon EVS environment, you are required to specify a VPC CIDR block. The VPC CIDR block cannot be changed after the environment is created, and will need to have enough space reserved to accommodate the required EVS subnets and hosts that Amazon EVS creates during environment deployment. As a result, it is critical to carefully plan out the CIDR block size, taking into account Amazon EVS requirements and your future scaling needs prior to deployment. Amazon EVS requires a VPC CIDR block with a minimum size of /22 netmask to allow sufficient space for the required EVS subnets and hosts. For more information, see Amazon EVS networking considerations.
Important
Ensure that you have sufficient IP address space for both your VPC subnet and the VLAN subnets that Amazon EVS creates for VCF appliances. The VPC CIDR block must have a minimum size of /22 netmask to allow sufficient space for the required EVS subnets and hosts.
When you create a VPC, we recommend that you specify a CIDR block from the private IPv4 address ranges as specified in RFC 1918
Note
Amazon EVS does not support IPv6 at this time.
Create a VPC with subnets
Amazon EVS deploys your environment into a VPC that you provide. This VPC must contain a subnet for Amazon EVS service access (service access subnet). For steps to create a VPC with subnets for Amazon EVS, see Create a VPC with subnets and route tables.
Configure the VPC main route table
Amazon EVS VLAN subnets are implicitly associated to the VPC main route table. To enable connectivity to dependent services such as DNS or on-premises systems for successful environment deployment, you must configure the main route table to allow traffic to these systems. The main route table must include a route for the VPC’s CIDR. For more information about managing subnet route tables, see Manage subnet route tables in the Amazon VPC User Guide.
After environment deployment, you must explicitly associate each of the Amazon EVS VLAN subnets with a route table in your VPC. NSX connectivity fails if your VLAN subnets are not explicitly associated with a VPC route table. We strongly recommend that you explicitly associate your subnets with a custom route table after environment deployment. For more information, see Explicitly associate Amazon EVS VLAN subnets to a VPC route table.
Important
Amazon EVS supports the use of a custom route table only after the Amazon EVS environment is created. Custom route tables should not be used during Amazon EVS environment creation, as this may result in connectivity issues.
Gateway route requirements
Configure routes for these gateway types based on your connectivity requirements:
Note
Amazon EVS does not support direct internet gateway connectivity at this time.
-
NAT gateway (NGW)
-
Optional for outbound-only internet access.
-
Must be in a public subnet with internet gateway access.
-
Add routes from private subnets and EVS VLAN subnets to the NAT gateway.
-
For more information, see Work with NAT gateways in the Amazon VPC User Guide.
-
-
Transit gateway (TGW)
-
Required for on-premises connectivity via both AWS Direct Connect and AWS Site-to-Site VPN.
-
Add routes for on-premises network ranges.
-
Configure route propagation if using BGP.
-
For more information, see Transit gateways in Amazon VPC Transit Gateways in the Amazon VPC User Guide.
-
Best practices
-
Document all route table configurations.
-
Use consistent naming conventions.
-
Regularly audit your route tables.
-
Test connectivity after making changes.
-
Back up route table configurations.
-
Monitor route health and propagation.
For more information about working with route tables, see Configure route tables in the Amazon VPC User Guide.
Configure your VPC’s DHCP option set
Important
Your environment deployment fails if you don’t meet these Amazon EVS requirements:
-
Include a primary DNS server IP address and a secondary DNS server IP address in the DHCP option set.
-
Include a DNS forward lookup zone with A records for each VCF management appliance and Amazon EVS host in your deployment.
-
Include a DNS reverse lookup zone with PTR records for each VCF management appliance and Amazon EVS host in your deployment.
-
Configure the VPC’s main route table to ensure a route to your DNS servers exist.
-
Ensure that your domain name registration is valid and unexpired, and no duplicate hostnames or IP addresses exist.
-
Configure your security groups and network access control lists (ACLs) to allow Amazon EVS to communicate with:
-
DNS servers over TCP/UDP port 53.
-
Host management VLAN subnet over HTTPS and SSH.
-
Management VLAN subnet over HTTPS and SSH.
-
Amazon EVS uses your VPC’s DHCP option set to retrieve the following:
-
Domain Name System (DNS) servers for host IP address resolution. Amazon EVS requires a minimum of two DNS servers in the DHCP option set.
-
Domain names for DNS resolution.
-
Network Time Protocol (NTP) servers for time synchronization.
You can create a DHCP option set using the Amazon VPC console or AWS CLI. For more information, see Create a DHCP option set in the Amazon VPC User Guide.
Configure DNS servers
DNS configuration enables hostname resolution in your Amazon EVS environment. You can:
-
Configure up to four custom DNS servers.
-
Create private hosted zones for internal domain resolution.
To successfully deploy an environment, your VPC’s DHCP option set must have the following DNS settings:
-
A primary DNS server IP address and a secondary DNS server IP address in the DHCP option set.
-
A DNS forward lookup zone with A records for each VCF management appliance and Amazon EVS host in your deployment.
-
A reverse lookup zone with PTR records for each VCF management appliance and Amazon EVS host in your deployment. For NTP configuration, you can use the the default Amazon NTP address
169.254.169.123
, or another IPv4 address that you prefer.
For more information about configuring DNS servers in a DHCP option set, see Create a DHCP option set.
For on-premises connectivity, we recommend the use of Route 53 private hosted zones with inbound resolvers. This setup enables hybrid DNS resolution, where you can use Route 53 for internal DNS within your VPC and integrate it with your existing on-premises DNS infrastructure. This allows resources within your VPC to resolve domain names hosted on your on-premises network, and vice versa, without requiring complex configurations. If required, you can also use your own DNS server with Route 53 outbound resolvers. For steps to configure, see Creating a private hosted zone and Forwarding inbound DNS queries to your VPC in the Amazon Route 53 Developer Guide.
Note
Using both Route 53 and a custom Domain Name System (DNS) server in the DHCP option set may cause unexpected behavior.
Note
If you use custom DNS domain names defined in a private hosted zone in Route 53, or use private DNS with interface VPC endpoints (AWS PrivateLink), you must set both the enableDnsHostnames
and enableDnsSupport
attributes to true
.
For more information, see DNS attributes for your VPC.
Troubleshoot DNS reachability issues
Amazon EVS requires a persistent connection to SDDC Manager and DNS servers in your VPC’s DHCP option set to reach DNS records. If the persistent connection to SDDC Manager becomes unavailable, Amazon EVS will no longer be able to validate environment status, and you may lose environment access. For steps to troubleshoot this issue, see Reachability check failed.
Configure NTP servers
NTP servers provide the time to your network. A consistent and accurate time reference on your Amazon EC2 instance is crucial for many VCF environment tasks and processes. Time synchronization is essential for:
-
System logging and auditing
-
Security operations
-
Distributed system management
-
Troubleshooting
You can enter the IPv4 addresses of up to four NTP servers in your VPC’s DHCP option set.
You can specify the Amazon Time Sync Service at IPv4 address 169.254.169.123
.
By default, the Amazon EC2 instances that Amazon EVS deploys use the Amazon Time Sync Service at IPv4 address 169.254.169.123
.
For more information about NTP servers, see RFC 2123
To configure NTP settings
-
Choose your NTP source:
-
Amazon Time Sync Service (recommended)
-
Custom NTP servers
-
-
Add NTP servers to your DHCP options set. For more information, see Create a DHCP option set in the Amazon VPC User Guide.
-
Verify time synchronization.
Recommended best practices
-
Use multiple NTP sources for redundancy.
-
Monitor time synchronization regularly.
-
Address synchronization issues promptly.
Create and configure VPC Route Server infrastructure
Amazon EVS uses Amazon VPC Route Server to 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.
Note
For Route Server peer liveness detection, Amazon EVS only supports the default BGP keepalive mechanism. Amazon EVS does not support multi-hop Bidirectional Forwarding Detection (BFD).
Prerequisites
Before you begin, you need:
-
A VPC subnet for your route server.
-
IAM permissions to manage VPC Route Server resources.
-
A BGP ASN value for route server (Amazon-side ASN). This value must be in the range of 1-4294967295.
-
A peer ASN to peer your route server with the NSX Tier-0 gateway. Peer ASN values entered in the route server and NSX Tier-0 gateway must match. The default ASN for an NSX Edge appliance is 65000.
Steps
For steps to create a VPC Route Server, see Create a route server in the Amazon VPC User Guide.
Note
If you are using a NAT gateway or a transit gateway, ensure that your route server is configured correctly to propagate NSX routes to the VPC route table(s).
Note
We recommend that you enable persistent routes for the route server instance with a persist duration between 1-5 minutes. If enabled, routes will be preserved in the route server’s routing database even if all BGP sessions end.
Note
BGP connectivity status will be down until the Amazon EVS environment is deployed and operational.
Troubleshooting
If you encounter issues:
-
Verify that each route table has an explicit subnet association.
-
Check that the peer ASN values entered for route server and the NSX Tier-0 gateway match.
-
Confirm that Route Server endpoint IP addresses are unique.
-
Review route propagation status in your route tables.
-
Use VPC Route Server peer logging to monitor BGP session health and troubleshoot connection issues. For more information, see Route server peer logging in the Amazon VPC User Guide.
Create a transit gateway for on-premises connectivity
You can configure connectivity for your on-premises data center to your AWS infrastructure using AWS Direct Connect with an associated transit gateway, or using an AWS Site-to-Site VPN attachment to a transit gateway. For more information, see (Optional) Configure on-premises network connectivity.
Create an Amazon EC2 Capacity Reservation
Amazon EVS launches Amazon EC2 i4i.metal instances that represent ESXi hosts in your Amazon EVS environment. To ensure that you have sufficient i4i.metal instance capacity available when you need it, we recommend that you request an Amazon EC2 Capacity Reservation. You can create a Capacity Reservation at any time, and you can choose when it starts. You can request a Capacity Reservation for immediate use, or you can request a Capacity Reservation for a future date. For more information, see Reserve compute capacity with EC2 On-Demand Capacity Reservations in the Amazon Elastic Compute Cloud User Guide.
Set up the AWS CLI
The AWS CLI is a command line tool for working with AWS services, including Amazon EVS. It is also used to authenticate IAM users or roles for access to the Amazon EVS virtualization environment and other AWS resources from your local machine. To provision AWS resources from the command line, you need to obtain an AWS access key ID and secret key to use in the command line. Then you need to configure these credentials in the AWS CLI. For more information, see Set up the AWS CLI in the AWS Command Line Interface User Guide for Version 2.
Create an Amazon EC2 key pair
Amazon EVS uses an Amazon EC2 key pair that you provide during environment creation to connect to your hosts. To create a key pair, follow the steps on Create a key pair for your Amazon EC2 instance in the Amazon Elastic Compute Cloud User Guide.
Prepare your environment for VMware Cloud Foundation (VCF)
Before you deploy your Amazon EVS environment, your environment must meet VMware Cloud Foundation (VCF) infrastructure requirements.
For detailed VCF prerequisites, see the Planning and Preparation Workbook
You should also familiarize yourself with VCF 5.2.1 requirements.
For more information, see the VCF 5.2.1 release notes
Note
Amazon EVS only supports VCF version 5.2.1.x at this time.
Acquire VCF license keys
To use Amazon EVS, you need to provide a VCF solution key and a vSAN license key.
The VCF solution key must have at least 256 cores.
The vSAN license key must have at least 110 TiB of vSAN capacity.
For more information about VCF licenses, see Managing License Keys in VMware Cloud Foundation
Important
Use the SDDC Manager user interface to manage VCF solution and vSAN license keys. Amazon EVS requires that you maintain valid VCF solution and vSAN license keys in SDDC Manager for the service to function properly.
Note
Your VCF license will be available to Amazon EVS across all AWS Regions for license compliance.
Amazon EVS does not validate license keys.
To validate license keys, visit Broadcom support
VMware HCX prerequisites
You can use VMware HCX to migrate your existing VMware-based workloads to Amazon EVS. Before you use VMware HCX with Amazon EVS, make sure that the following prerequiste tasks have been completed.
Note
VMware HCX is not installed in the EVS environment by default.
-
Before you can use VMware HCX with Amazon EVS, minimum network underlay requirements must be met. For more information, see Network Underlay Minimum Requirements
in the VMware HCX User Guide. -
Confirm that VMware NSX is installed and configured in the environment. For more information, see the VMware NSX Installation Guide
. -
Ensure that VMware HCX is activated and installed in the environment. For more information about activating and installing VMware HCX, see About Getting Started with VMware HCX
in the Getting Started with VMware HCX Guide.