AWS Partner Network (APN) Blog

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

By Kiran Reid, Sr. Partner Solutions Architect – AWS
By Pat Brandel, Sr. Product Manager – AWS
By Siegfried Eigler, Sr. Specialist Solutions Architect – AWS
By 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 NetApp 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 are excited to 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 two 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 Amazon Web Services (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 two VPCs in the same or different AWS accounts and regions. The VPC peering connection allows you to communicate between hosts using private IPv4 or the IPV6 addresses.

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

VMC-Peering-External-Storage-1

Figure 1 – VPC peering.

Connectivity Process

There are two 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.

The below process goes over the high-level steps required to set up VPC peering between the customer-owned AWS account and the 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 NetApp 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 full advantage of VMware Cloud on AWS with Amazon FSx for NetApp ONTAP without incurring the additional cost of AWS Transit Gateway data processing fees. This allows customers to further reduce the total cost of ownership (TCO) and increase capabilities when operating within VMware Cloud on AWS.

To learn more about this deployment option, visit the VMware Cloud on AWS page, the FSx for NetApp ONTAP product page, and the AWS News Blog announcement.