Close

HPE Aruba Networking Blogs

Aruba EdgeConnect SD-WAN and AWS Cloud WAN simplify connectivity and segmentation from edge to cloud

Organizations enjoy a scalable, seamless experience when using the Aruba EdgeConnect SD-WAN platform to connect to the AWS Cloud WAN service, assuring secure, private connectivity from the branch edge to workloads and services within the AWS cloud.

The challenge

Many customers, especially large enterprises and cloud-first companies, deploy various AWS services including Virtual Private Clouds (VPCs), AWS Direct Connect circuits, AWS Site-to-Site VPNs, AWS Client VPNs, and AWS Transit Gateways (TGW) (including all Transit Gateway attachment types) across multiple AWS regions globally. As these deployments grow in complexity and scope, enterprises need a more effective way to scale connectivity across AWS regions, especially when establishing full mesh interconnectivity across multiple AWS regions. In addition, they are looking for an improved way to enable network and routing segmentation to increase security, performance, allow better access control, and allow better containment of network traffic.

Moreover, these enterprises often deploy SD-WAN virtual instances in VPCs to augment connectivity from on-premises networks into AWS workloads and preserve end-to-end segmentation while also utilizing other SD-WAN capabilities such as dynamic path selection, WAN optimization, Foreword Error Correction (FEC), NAT, firewall, and Intrusion Detection and Prevention Systems (IDPS).

Currently, when AWS Transit Gateway peering connections are used to interconnect AWS Transit Gateways deployed in separate regions, users must create static routes to route traffic to the destination region. Additionally, if an enterprise wants to segment their AWS environment in the current Transit Gateway architecture, they must create and manage separate Transit Gateway route tables, which can be cumbersome at scale. These challenges are compounded when enterprises attempt to add more segments and expand into other AWS regions while connecting to on-premises networks.

Introducing AWS Cloud WAN

To address these challenges, AWS introduced the AWS Cloud WAN service (Cloud WAN). Cloud WAN enables customers to define a multi-region, segmented, dynamically routed global network using a new construct named Core Network. The Core Network construct, along with the Core Network Policy, allows customers to build a multi-region, AWS-managed network that uses the AWS global backbone as a Wide Area Network (WAN). It allows the creation of a globally, distributed network in minutes from the AWS Network Manager dashboard. Cloud WAN simplifies the creation and maintenance of network segments (VRFs) across your AWS global network. While you can create your own global network by interconnecting multiple Transit Gateways across Regions, Cloud WAN provides built-in automation, segmentation, and configuration management features designed specifically for building and operating global networks.

Aruba EdgeConnect SD-WAN with AWS Cloud WAN

Aruba EdgeConnect SD-WAN utilizes the AWS Cloud WAN service to provide advanced SD-WAN capabilities that make it easy for organizations to preserve and extend on-premises network segments into AWS thereby increasing overall data security, access control, and performance.

Components of AWS Cloud WAN

In depth details of AWS Cloud WAN components and use cases can be found on the following AWS links:

To provide context for the remaining discussion, below is a brief explanation of the key Cloud WAN components obtained from the AWS documentation:

Global Network: The Global Network is a high-level container for your AWS-based network objects such as AWS Transit Gateways and other Cloud WAN Core Networks. You can create a Global Network from the AWS Network Manager console.

Core Network: The part of your global network orchestrated and managed by AWS. The Core Network includes the Core Network Edges created as part of running a Core Network Policy. The Core Network also includes all user-created attachments within your Cloud WAN environment including VPC attachments, Site-to-Site VPN attachments, Cloud WAN Connect attachments, Client VPN attachments, etc.

Core Network Edge (CNE): A Core Network Edge is similar to a TGW. You can specify one or more AWS regions in your Core Network Policy where you want the Core Network Edges created. When you execute your Core Network Policy, AWS will automatically create the Core Network Edges specified in your Core Network Policy. On the AWS console and on some AWS documents, Core Network Edges are also known as Edge locations.

Core Network Policy (CNP): The Core Network Policy is used to define the global configuration of your Cloud WAN. Using the Core Network Policy, you can define how your VPCs, Site-to-Site VPNs, and existing AWS Transit Gateway resources establish connectivity to your Core Network. The Core Network Policy also defines the routing policy and how traffic should be segmented across your Cloud WAN. You can build your Core Network Policy using the AWS Management Console or Cloud WAN APIs.

Attachments: Attachments allow you to connect AWS resources such as VPCs, AWS Site-to-Site VPN connections, AWS Transit Gateways, etc., to your Core Network.

Segments: Segments allow you to divide a global network into separate isolated networks.

AWS Cloud WAN architecture

Figure 1 shows the topology diagram of a Cloud WAN architecture prior to inserting SD-WAN instances. It includes of the following resources:

  • A Global Network
  • A Core Network
  • Two Core Network Edges in AWS California and AWS N. Virginia regions
  • Two segments named Engineering and SQA that span across the California and N. Virginia regions
  • Four VPCs in the California region (SQA-VPC-A, SQA-VPC-B, Engineering-VPC-A, and Engineering-VPC-B)
  • Four VPCs in the N. Virginia region (SQA-VPC-X, SQA-VPC-Y, Engineering-VPC-X, and Engineering-VPC-Y). Each VPC connects to the Core Network Edge of its region.
  • A Core Network Policy that manages the resources within the Core Network

Figure 1: A multi-region AWS Cloud WAN architecture with “Engineering” and “SQA” segments present on each Core Network Edge.

The following high-level steps are performed to create the above architecture:

1. Create a Global Network

The first step of setting up AWS Cloud WAN is the creation of a Global Network. A Global Network is a single, private network that acts as the high-level container for your network objects.

2. Create a Core Network and Core Network Policy

After the Global Network is created, you must create your Core Network followed by the Core Network Policy. Note that you can only create one Core Network inside a Global Network.

Note: It is extremely easy to spin up Core Network Edges in multiple regions using the Core Network Policy. In our architecture above, our Core Network Policy includes the California and N. Virginia AWS as the locations to create the Core Network Edges. Also, our Core Network Policy specifies the creation of the SQA segment and the Engineering segment, which will be available on each Core Network Edge.

Once you execute the Core Network Policy, AWS automatically assigns an Autonomous System Number (ASN) from a range you provided to each Core Network Edge. These ASNs are required when establishing a Border Gateway Protocol (BGP) session over a Site-to-Site VPN attachment or a Connect attachment. Using a Connect attachment, you can establish connectivity with a Core Network Edge using two methods. These two methods are shown under the “Connect protocols” dropdown menu on the AWS Management Console when creating a Connect attachment. They are: 1) Connectivity over a Generic Routing Encapsulation (GRE) tunnel, and 2) Connectivity over a tunnel-less (No Encapsulation) attachment. Aruba EdgeConnect SD-WAN appliances support both options.

Note: A tunnel-less attachment on AWS Cloud WAN is a new capability that provides customers with a simpler and more performant way to connect from an SD-WAN appliance deployed in AWS with a Core Network Edge. With this capability, an SD-WAN appliance can now natively peer with a Core Network Edge using BGP without the need for specialized tunneling protocols that are used in site-to-site VPN attachments (IPsec) or in GRE-based Connect attachments. Additionally, a tunnel-less attachment provides the full VPC attachment bandwidth for customer traffic, as opposed to a site-to-site VPN attachment (1.25 Gbps per IPsec tunnel) or a GRE-based Connect attachment (5 Gbps per GRE tunnel).

One important note to keep in mind is that, as of October 2023, a tunnel-less attachment can only support one network segment (VRF) per VPC. This means that if you have an SD-WAN appliance deployed in a VPC that contains multiple network segments, traffic from only one of those segments can be sent to the Core Network Edge over a tunnel-less attachment. The support for one AWS Cloud WAN segment per tunnel-less attachment is a roadmap item as of October 2023. Due to this limitation, in this blog post, we only discuss the use of GRE-based Connect attachments, which allow an SD-WAN appliance with multiple network segments to connect and extend those segments with a Core Network EdgeConnect, and vice versa.

3. Create attachments

Once your Core Network and the Core Network Policy are in place, you are ready to create attachments. In our architecture, we attached four VPCs in the California region (SQA-VPC-A, SQA-VPC-B, Engineering-VPC-A, and Engineering-VPC-B) to the California Core Network Edge using VPC attachments. Similarly, we attached another four VPCs in the N. Virginia region to the N. Virginia Core Network Edge using VPC attachments. These VPC attachments allow the workloads in the VPCs to be sending and receiving traffic from other AWS networks as well as non-AWS networks.

Note: To enable segmentation and grouping of VPCs that belong to the same business unit, we attached each SQA VPC to the SQA segment. Similarly, each Engineering VPC is attached to the Engineering segment. In this example, the Engineering and SQA segments are totally isolated:  the SQA VPCs can only communicate with other SQA VPCs within the same region or across regions, and each Engineering VPC can only communicate with other Engineering VPCs within the same region or across regions. While this isolation is the default behavior of segments in Cloud WAN, it is also possible to allow access to the resources of one segment from the resources of another segment to provide inter-segment communication with fine grained control. It is also possible to isolate each attachment even within a single segment and only allow east-west communication via a security virtual appliance such as a firewall deployed in a Share Services VPC. Such a configuration can be easily made by updating the Core Network Policy.

Figure 2 shows the Topology graph of the Cloud WAN resources that we have built up to now. It contains the same Core Network Edges, segments, and VPC attachments mentioned on Figure 1.

Figure 2: A Cloud WAN with two Core Network Edges, two Segments (present on each Core Network Edge), and eight VPC attachments.

In the next section, we discuss how to insert Aruba EdgeConnect SD-WAN appliances into this architecture to preserve end-to-end segmentation of Engineering and SQA segments when connecting on-premises networks with AWS.

Deploy Aruba EdgeConnect SD-WAN into an AWS Cloud WAN architecture

Typically, an SD-WAN fabric consists of tens, hundreds, or even thousands of on-premises and public cloud locations. When organizations deploy Virtual EdgeConnect Enterprise (EC-V) instances in AWS, a pair EC-Vs are deployed in unique Availability Zones in a single region for redundancy. Note that for simplicity in the illustration, Figure 3 below shows two on-premises locations with EdgeConnect Enterprise devices, and only one (not a pair) of EC-V in each region in AWS.

Figure 3: A multi-region AWS Cloud WAN architecture with Aruba EdgeConnect SD-WAN instances.

The following high-level steps are performed to insert EdgeConnect Enterprise instances into the above architecture:

1. Deploy the EdgeConnect Enterprise appliances in the AWS cloud.

You can deploy the EC-V instances in AWS from the Aruba Orchestrator with just a few clicks. Figure 4 shows a screenshot from the Aruba Orchestrator’s AWS EC-V deployment page. While deploying the EC-V in AWS, the Orchestrator creates a brand new VPC, subnets, Security Groups, Elastic IPs, route tables, and other resources for bringing up the EC-V. Once the deployment completes, the EC-V appears on the Orchestrator ready to be added into the SD-WAN fabric.

Figure 4: Deploying two EC-Vs in two Availability Zones in the AWS California region from Aruba Orchestrator.

After repeating the above step to deploy EdgeConnect Enterprise instances into the AWS N. Virginia region and establishing IPsec tunnel connectivity with the rest of the EdgeConnect Enterprise instances, the Aruba Orchestrator’s topology page will look like the image in Figure 5.

Figure 5: The Topology page of the Aruba Orchestrator showing the EdgeConnect Enterprise instances deployed in the Regional Hub and Spoke mode. In this deployment, the AWS EC-Vs are acting as “Hub” EC-Vs.

2. Establish connectivity from the EdgeConnect Enterprise instances in AWS with the Core Network Edge

To establish connectivity from an EdgeConnect Enterprise instance with a Core Network Edge, you must create a Cloud WAN Connect attachment or a Site-to-Site IPsec VPN attachment. Figure 6 shows a logical topology that contains the networking constructs required to establish connectivity between High-Availability (HA) EdgeConnect Enterprise instances deployed in one region with a Core Network Edge. As shown on the figure, Aruba recommends creating a Cloud WAN Connect attachment and establishing BGP sessions over a GRE tunnel from each EdgeConnect Enterprise instance with the Core Network Edge. This is because a GRE tunnel in AWS can support up to 5 Gbps of throughput. However, if your organization requires end-to-end encryption from the EdgeConnect Enterprise instance to the Core Network Edge, you can establish a Site-to-Site IPsec VPN tunnel instead. The disadvantage of using IPsec tunnels is that you are limited to 1.25 Gbps per IPsec tunnel. In this blog, we use the Cloud WAN Connect attachments.

Figure 6: A logical topology that shows the VPC attachment, Cloud WAN Connect attachments, the Cloud WAN Connect Peers (GRE tunnels), the VTIs, and the BGP sessions required for extending segments between the EdgeConnect Enterprise instances and the Core Network Edge.

The following high-level steps are performed to create the attachments:

A. Create a VPC attachment

As shown in Figure 6, you must first create a VPC attachment from the SD-WAN VPC to the Core Network Edge of that region. As both EdgeConnect Enterprise instances in our architecture are created within one VPC, you only need to establish one VPC attachment with the Core Network Edge. (If your EdgeConnect Enterprise instances are deployed in separate VPCs within the region, you must ensure that each VPC is attached with the Core Network Edge.) Figure 7 shows the SD-WAN VPC attachments created in each region in our architecture.

Figure 7: The SD-WAN VPC to the Core Network Edge VPC attachment in each region.

B. Create a Cloud WAN Connect attachment and a Connect Peer for each segment

Once the VPC attachment is in place to connect the EdgeConnect Enterprise instance to the Core Network Edge, you are ready to create the Cloud WAN Connect attachments. As shown in Figure 6, a Cloud WAN Connect attachment allows an EdgeConnect Enterprise instance to map a segment to a Core Network Edge. Since each EdgeConnect Enterprise instance contains the Engineering and SQA segments, you must create four Cloud WAN Connect attachments for an HA EC-V deployment in one region. Figure 8 shows all eight Cloud WAN Connect attachments created on all four EdgeConnect Enterprise instances deployed in the California and N. Virginia regions.

Figure 8: Cloud WAN Connect attachments on each region.

As shown in Figure 9, each Cloud WAN Connect attachment includes a Connect Peer that contains the GRE endpoint IP addresses and the BGP endpoint IP addresses on both Core Network Edge as well as the EdgeConnect Enterprise instance. This information is required in order to set up BGP over GRE sessions on the EdgeConnect Enterprise instance.

Figure 9: Connect Peer details of the Engineering Cloud WAN Connect attachment of the EdgeConnect Enterprise instance in California.

3. Enable segmentation on EdgeConnect Enterprise instances from Aruba Orchestrator

Enabling routing segmentation, also known as, Virtual Routing and Forwarding (VRF), on the Aruba Orchestrator allows you to enable segmentation throughout your SD-WAN fabric with a single click. As illustrated on Figure 10, on the Routing Segmentation (VRF) page, we have created the Engineering and SQA segments.

Figure 10: Enabling Routing Segmentation and adding the Engineering and SQA segments.

4. Create GRE tunnels

Creating a GRE tunnel from an EdgeConnect Enterprise instance with a Core Network Edge allows you to create the “bridge” between the SD-WAN fabric and the Cloud WAN environment. Figure 11 shows the GRE tunnels on all four EdgeConnect Enterprise instances deployed in the California and N. Virginia regions.

Figure 11: The Tunnels page of Aruba Orchestrator showing passthrough GRE tunnels established on EdgeConnect Enterprise instances with Core Network Edges.

5. Create Virtual Tunnel Interfaces (VTIs)

After GRE tunnels are established you create VTIs on the EdgeConnect Enterprise instance. A VTI acts as the BGP endpoint on the EdgeConnect Enterprise instance. When creating a VTI, you must place it in the correct segment. Figure 12 shows the VTIs created on all four EdgeConnect Enterprise instances deployed in the California and N. Virginia regions.

Figure 12: The VTI page of Aruba Orchestrator showing all VTIs created on each EdgeConnect Enterprise instance.

By now, with all the attachments in place, the Topology graph on the AWS Network Manager dashboard looks like the image on Figure 13.

Figure 13: Topology graph on the AWS Network Manager dashboard showing all attachments and segments.

6. Establish BGP from each segment of the EC-V with the Core Network EdgeConnect

Finally, you enable BGP from each segment on the EC-V with the Core Network Edge. Figure 14 shows the BGP sessions on all four EdgeConnect Enterprise instances deployed in the California and N. Virginia regions.

Figure 14: The BGP page of Aruba Orchestrator showing BGP sessions created on each EdgeConnect Enterprise instance.

With the BGP sessions in the Established state, you will now see the routes advertised by the SD-WAN fabric into the Core Network on the Routes page of the AWS Network Manager dashboard as illustrated in Figure 15.

Figure 15: AWS Network Manager dashboard displaying the routes advertised by the SD-WAN fabric.

Similarly, the routes advertised by the Core Network Edge are seen on the Aruba Orchestrator’s Routes page as show in Figure 16.

Figure 16: Aruba Orchestrator displaying routes learned from the Core Network Edge.

Conclusion

To summarize, Aruba EdgeConnect SD-WAN and AWS Cloud WAN integration will allow customers to seamlessly extend on-premises segments into the AWS cloud and vice versa to increase security, performance, access control, and containment of network traffic for Site-to-Cloud, Site-to-Site, and inter-region workload use-cases. Aruba and AWS continue to innovate through the addition of advanced capabilities and interoperability to help enterprises increase productivity while keeping their workforces connected and secure.