What problem does redeploying the NSX Edge Cluster via SDDC Manager solve in Amazon EVS?
In a standard Amazon Elastic VMware Service (EVS) deployment, the NSX Edge Cluster is deployed independently of VMware Cloud Foundation’s SDDC Manager. That default behavior has a key limitation: SDDC Manager cannot create Application Virtual Networks on those edges.
Without Application Virtual Networks managed by SDDC Manager, you cannot natively deploy and lifecycle-manage optional VMware Cloud Foundation (VCF) components such as:
- VCF Logs
- VCF Operations
- VCF Automation
You can still deploy these tools outside SDDC Manager, but that typically increases operational overhead and architectural complexity.
By redeploying the NSX Edge Cluster via the SDDC Manager API, you:
- Enable SDDC Manager to create and manage Application Virtual Networks
- Simplify deployment and lifecycle management of additional VCF capabilities
- Align NSX Edge lifecycle with the broader SDDC Manager workflows
- Gain flexibility to define BGP pairings between NSX and Amazon VPC Route Server endpoints
In short, this approach reimagines the edge deployment so that EVS, NSX, and SDDC Manager work together as a cohesive platform for VCF add-ons and ongoing operations.
What are the main architectural changes required to support SDDC-managed NSX Edges in EVS?
To let SDDC Manager deploy and manage the NSX Edge Cluster in Amazon EVS, you make a few targeted changes in your AWS VPC and NSX configuration. At a high level, you are reshaping the routing architecture so that it meets SDDC Manager’s requirements for redundant uplinks and BGP connectivity.
Key architectural steps include:
1. **Add a new private subnet and route server endpoint**
- Create an additional private subnet in the EVS VPC (same Availability Zone as the service access subnet, and sized similarly to the existing private subnet).
- Associate this new subnet with the private route table used by EVS so traffic can flow correctly.
- Create a new VPC Route Server endpoint in this new private subnet.
2. **Adjust existing Route Server configuration**
- EVS supports only one NSX Edge Cluster, so you first shut down the existing edge nodes in vCenter. During this step, all north–south traffic is interrupted until BGP is re-established on the new edges.
- Remove the second Route Server peer and its endpoint that were created during the original EVS deployment.
- On the remaining original Route Server endpoint, create a new Route Server peer that will connect to the second edge node in the new cluster.
- On the new Route Server endpoint (in the new private subnet), create two Route Server peers that will connect to the new NSX Edge appliances.
3. **Prepare NSX Edge deployment inputs for SDDC Manager**
For the JSON payload you send to the SDDC Manager API, you need:
- Forward and reverse DNS entries for each new NSX Edge VM
- Management IPs on the VM management VLAN (for example, VLAN 20)
- Two TEP IPs per edge VM on the Edge TEP VLAN (for example, VLAN 60)
- New uplink IPs on the NSX Uplink VLAN (for example, VLAN 70)
- New uplink IPs on an expansion VLAN (for example, expansionVlan2 / VLAN 100)
- The compute cluster ID where the edges will be deployed (retrieved via the SDDC Manager API Explorer)
4. **Deploy the new NSX Edge Cluster via SDDC Manager API**
- Use the SDDC Manager API Explorer to validate the JSON payload and then execute the call to deploy the new NSX Edge Cluster.
- SDDC Manager deploys a new pair of NSX Edge VMs with redundant uplinks in separate subnets, satisfying its design requirements.
5. **Configure routing and BGP in NSX**
- Configure the new Tier-0 (T0) and Tier-1 (T1) gateways to match your existing design, including disabling standby relocation on the new T1 if required.
- Create a prefix list that only allows RFC 1918 addresses to be advertised via BGP, preventing non-private networks from being advertised to the Route Server.
- Add static routes on the T0 gateway:
- A default route for all traffic exiting NSX to the VPC underlay
- A static route to Route Server endpoint 1 via the NSX Uplink VLAN gateway
- A static route to Route Server endpoint 2 via the expansionVlan2 VLAN gateway
- Configure two BGP neighbors on the T0 gateway:
- Neighbor 1: IP of Route Server endpoint 1, with the VPC Route Server AS, and the two NSX Edge uplink IPs that connect to endpoint 1 as source addresses
- Neighbor 2: IP of Route Server endpoint 2, with the same AS, and the two NSX Edge uplink IPs that connect to endpoint 2 as source addresses
- Apply route filters so that only the intended prefixes (for example, RFC 1918) are advertised.
6. **Clean up the old Edge Cluster**
- After BGP is established and validated, delete the old T0 and T1 gateways, the old edge cluster, and the old edge transport nodes. This also removes the old edge VMs from vCenter.
These changes collectively reconfigure your EVS networking so that SDDC Manager can fully manage the NSX Edge Cluster, while maintaining resilient BGP connectivity to the AWS VPC Route Server.
What operational impacts and benefits should I expect from this NSX Edge redeployment approach?
You should plan for a short-term operational impact during the transition, followed by a more streamlined and manageable environment once the new NSX Edge Cluster is in place.
**Operational impacts during implementation**
1. **North–south traffic interruption**
- When you shut down the existing NSX Edge nodes, all north–south traffic (in and out of the EVS environment) is interrupted.
- This outage lasts until the new NSX Edge Cluster is deployed and BGP sessions with the VPC Route Server are established.
- To minimize risk, it is recommended to perform this work:
- Immediately after the initial EVS deployment, before production workloads are live, or
- During a planned maintenance window.
2. **Configuration changes in AWS and NSX**
- You will create and modify VPC subnets, Route Server endpoints, and peers.
- You will update NSX Tier-0 and Tier-1 gateway configurations, including static routes, BGP neighbors, and route redistribution.
- These are controlled, one-time changes, but they require careful planning and validation.
**Operational benefits after implementation**
1. **Application Virtual Networks enabled in SDDC Manager**
- SDDC Manager can now create and manage Application Virtual Networks on the NSX Edge Cluster it deployed.
- This unlocks the ability to deploy additional VMware Cloud Foundation components—such as VCF Logs, VCF Operations, and VCF Automation—directly through SDDC Manager.
- As a result, you reduce the need for custom, out-of-band deployments of these tools.
2. **Simplified lifecycle management**
- NSX Edges are now part of the SDDC Manager-managed stack, so patching, upgrades, and configuration consistency can be handled through standard SDDC Manager workflows.
- This helps reduce manual effort and the risk of configuration drift between NSX and the rest of the SDDC.
3. **More structured and flexible routing design**
- The new design uses redundant uplinks in separate subnets, aligned with SDDC Manager requirements.
- BGP pairings between NSX and the AWS VPC Route Server are explicitly defined and controlled.
- Prefix lists and route filters ensure that only intended (for example, RFC 1918) networks are advertised, which can help keep your routing domain cleaner and easier to reason about.
4. **Better alignment with VMware-to-AWS migration practices**
- The approach is consistent with how AWS and VMware specialists typically recommend structuring NSX and SDDC Manager in hybrid and migration scenarios.
- This alignment can make it easier to adopt additional VMware Cloud Foundation capabilities over time and to scale your EVS footprint as your workloads grow.
In summary, you incur a planned, temporary outage and some focused configuration work in exchange for a more manageable, SDDC-aligned NSX Edge deployment that supports Application Virtual Networks and reduces ongoing operational complexity.
Sign in with LinkedIn