Introducing VPC Peering for Amazon FSx for NetApp Ontap with VMware Cloud on AWS

By Kiran Reid, senior partner solutions architect, AWS, Pat Brandel, senior product manager, AWS, Siegfried Eigler, senior specialist solutions architect, AWS, and Ali Sardar, principal product manager, AWS

Last year, we announced Amazon FSx for NetApp ONTAP integration with VMware Cloud on AWS.

Since its launch, we have seen growing customer interest and adoption of the service.

VMware Cloud on AWS enables customers to extend their on-premises data centers and easily migrate workloads without having to convert machine image formats or undergo a re-platforming process. Amazon FSx for NetApp ONTAP is a storage service that allows customers to launch and run fully managed ONTAP file systems in the cloud.

We also introduced last year support for single-Availability Zone (AZ) deployments. Previously, AWS Transit Gateway (TGW) has been a requirement of the solution, providing customers with flexibility with connecting their file systems to their VMware Cloud on AWS software defined data centers (SDDCs).

Now, we announce the removal of AWS Transit Gateway as a requirement from the solution. Instead, we are adding support for virtual private cloud (VPC) peering.

In this post, we’ll go through the benefits of this connectivity option and explore the connectivity process and some connectivity considerations.

Customer benefits
VPC peering comes with improved security by enabling private connectivity between 2 or more VPC networks. Isolating traffic from the public internet reduces a whole class of risks from your stack since the traffic never leaves the AWS cloud network.

Peering is configured between the peered VPC and the SDDC, but traffic is restricted to the management subnet, and only NFS traffic is allowed.

With VPC peering, you save on network transit costs and benefit from improved network latency. Because peering traffic does not leave the AWS network, that reduces public IP latency. VPC peering creates a line-rate connection between VPCs, which allows direct Elastic Network Interface ENI-to-ENI communication with sub-millisecond latency between the peered VPCs.

Another reason to use VPC peering is when your instances do not require a public IP address or a network address translation (NAT) configuration to the public Internet.

Solution overview
You can create a VPC peering connection between 2 VPCs in the same or different AWS accounts and regions. The connection allows to communicate between hosts using private IPv4 or the IPV6 addresses.

Since the NFS datastore connection bypasses NSX and is between ESXi hosts and FSx for ONTAP-based NFS storage, a direct connection is established between 2 VPCs, without the need to traverse a routed connection.

Figure 1 – VPC peering
Click to enlarge

Connectivity process
There are 2 accounts required for connectivity: the account which belongs to VMware where the SDDC is deployed, and the customer account where the Amazon FSx for ONTAP filesystem is deployed.

Below process goes over high-level steps required to set up VPC peering between the customer-owned AWS account and VMware account:

• The customer contacts their VMware customer success or account representative and requests VPC peering.
• The owner of the requester VPC (VMware) sends a request to the owner of the accepter VPC (customer) to create the VPC peering connection.
• The owner of the accepter VPC (customer) needs to accept the VPC peering connection request to activate the VPC peering connection.
• The customer contacts VMware, informing them they have accepted the request and the VPC peering connection can be finalized.
• VMware updates the network routes to use the peering connection.
• The customer does the same in their VPC and configures their security group rules to allow NFS traffic.

Considerations
VPC peering for Amazon FSx for ONTAP is being introduced exclusively for the use of NFS datastore traffic; any other traffic has been explicitly blocked and is not supported.

The SDDC must be running v1.20 or newer and be a single-AZ SDDC. Multi-AZ FSx for NetApp deployments requires the architecture using AWS Transit Gateway and must continue to use SDDC groups to connect to the SDDC. Existing customers that want to utilize VPC peering should contact VMware if their SSDC is running a version prior to v1.20 and request an upgrade.

VMware does not support external storage for datastores on stretched clusters. This is targeted for a future date on VMware’s roadmap.

Costs
There is no charge to create a VPC peering connection. All data transferred over a VPC peering connection that stays within an Availability Zone is free. Cross-AZ data transfer charges apply if the storage is deployed in a different AZ than the SDDC.

Summary
With the release of VPC peering support, customers can take advantage of VMware Cloud on AWS with Amazon FSx for ONTAP without incurring the additional cost of AWS Transit Gateway data processing fees. This allows customers to further reduce the TCO and increase capabilities when operating within VMware Cloud on AWS.

Resources:
About this deployment option: VMware Cloud on AWS page, the FSx for NetApp ONTAP product page, and AWS News Blog announcement