AWS Cloud Topologies
SteelConnect Manager (SCM) provides the ability to orchestrate the deployment of virtual SteelConnect gateways and virtual SteelHeads directly into Amazon Web Services (AWS) Virtual Private Clouds (VPCs) effectively linking branch offices, data centers, and headquarter (HQ) locations and VPCs, both in the same or different regions. After integrating SCM with your AWS account (through Identity and Access Management [IAM] cross-account), the console automatically discovers and displays your subnets, in all VPCs and regions.
With SteelConnect’s knowledge of your infrastructure, you can deploy virtual SteelConnect gateways and SteelHeads in all (or individual) VPCs and establish an automated VPN overlay through the internet while also benefiting from optimizing your applications over the WAN. This software-defined WAN automation interconnects VPCs using full-mesh VPN routing—with no manual configuration.
AWS, Azure, and SteelConnect use slightly different terms to refer to similar network concepts. Virtual Private Clouds (AWS) and VNets (Azure) are called sites in SteelConnect, and subnets are referred to as zones in SteelConnect.
This topic provides a guide and examples to connect AWS VPCs with SteelConnect and deploy the SteelHead for SteelConnect WAN optimization solution in AWS. Traffic can be optimized from your branch offices and data centers to your VPCs and/or directly between VPCs.
Deployment into the AWS cloud
The configuration steps to deploy SteelConnect gateways in the AWS cloud are outlined in the SteelConnect Manager User Guide. The steps to do so are:
1. Subscribe to Riverbed AWS products.
2. Configure your AWS accounts with SteelConnect Manager.
3. Import AWS networks.
4. Deploy SteelConnect gateways to your AWS network.
5. Optionally, configure high availability through redundancy.
AWS also offers advanced features, including:
AWS Direct Connect to configure a private network connection to your cloud deployments
SteelConnect AWS transit VPC to communicate between multiple Virtual Private Clouds (VPCs)
Once you have read through the steps in the SteelConnect Manager User Guide on how to configure your deployment into AWS, you can deploy a SteelConnect gateway in your AWS environment.
Deploying a HA SteelConnect gateway in AWS
You can deploy SteelConnect gateways in AWS in high availability.
An example of this topology has multiple on-premises sites and the organization wants to extend its network to the AWS cloud and connect to its subnets in the Mumbai Region.
Network before AWS in Mumbai
To extend the network to Mumbai with AWS in high availability
1. Connect the subnets.
In SCM, choose Network Design > AWS, select the Import VPCs tab, and click Connect.
Connect VPC
When you connect a subnet in a VPS and AWS region, SCM creates a Site and Zone object for your Organization.
2. From the AWS Deploy Instances tab, deploy the gateway and set Redundancy to On.
Deploy AWS gateway with redundancy
When you click Submit to deploy your instance, SCM logs in to your AWS environment, scans for two free /28 subnets: one for the uplink and the other for the downlink subnet of the gateway to deploy. It does the same for the subnet in the other Availability Zone. The gateway boots up, patches itself, gets an Elastic IP address, and connects to the internet gateway (IGW) of the VPC.
You need to have a network configured that has available subnets.
AWS deployment architecture details the AWS deployment. Note that only one on-premises network appears for simplicity purposes. In this deployed network, IPsec VPN tunnels are automatically formed from the AWS subnet to all other on-premises networks in a full-mesh.
AWS deployment architecture
In case of the failure of the gateway in Availability Zone A, your network can be routed through the gateway deployed in Availability Zone B.
Failover for AWS HA
In your VPC, two gateways appear.
HA gateways
The two appliances also appear in HA mode deployed under the Appliances tab on SCM.
HA appliances
In the AWS VPC Dashboard, entries appear for the SteelConnect appliances’ uplinks and downlinks.
AWS dashboard with SteelConnect uplinks and downlinks
With Auto selected for routing when deploying the gateways, all the routes to other networks (on-premises, or any other existing cloud network sites) are added by the script automatically when the gateways start deploying for the subnets on AWS.
AWS routes
The real-time event log in SCM shows the deployment process.
SCM event log with deployment details
After you deploy the gateways in HA mode, the dashboard displays the new site.
SCM dashboard with HA configured
SteelConnect gateway with SteelHead in AWS
In this topology, we deploy SteelHead for end-to-end WAN optimization in the network. SteelHead WAN optimization enhances your SteelConnect Infrastructure as a Service (IaaS) deployment by automatically optimizing all TCP traffic to increase speed and reduce bandwidth over the secure VPN links. In addition to interconnecting your cloud infrastructure to your on-premises sites (or bringing the cloud closer by providing a direct path to your IaaS applications from each branch) you can now use SteelHead to boost performance and reduce traffic. Everything is controlled through a cloud console for a true hybrid-WAN solution using the very latest in software-defined automation.
The process is similar to the steps described in the previous topology, but when you deploy your gateway in AWS, select a specification for the SteelHead. The specifications include throughput limits that indicate the amount of optimized traffic the instance supports.
Deploying SteelHead with a gateway
Once deployed, the appliance appears in the Appliances Overview page.
Appliances Overview page
You can see the status of the currently deployed appliance by clicking Manage on the AWS tab on SCM.
Managing the SteelHead in AWS
While not required, if you need to make specific configuration changes to the SteelHead for SteelConnect, you can log in to it from the browser of a jump host (Windows/Linux) in your VPC by navigating to its private IP address in the downlink subnet. The initial login credentials for the SteelHead are username admin and your specific instance ID is your password.
Configuration changes for the SteelHead for SteelConnect
On AWS, you can review the uplink and downlink subnets for the SteelConnect gateway.
Uplink and downlink subnets
The routes are added to all other networks in the route tables on AWS.
Route tables in AWS
The architecture for the deployment is show in AWS architecture with SteelHead.
AWS architecture with SteelHead
Transit VPC Routing using SteelConnect gateways
The AWS transit VPC feature in SteelConnect enables communication among multiple Virtual Private Clouds (VPCs) within the same AWS region by using a hub-and-spoke topology. One VPC in an AWS region is designated as the hub and all other VPCs in the region are spokes. All VPCs are connected to each other through the hub by using SteelConnect gateways and AutoVPN tunnels over VPC peering connections. The hub gateway is also automatically configured with an uplink to an AWS internet gateway, which enables AutoVPN tunnels to branch offices over the internet.
The benefits of this feature include:
Enhanced security - The hub can be configured as a bastioned VPC, protecting its spokes behind a firewall or other security measures.
Overcoming AWS VPC peering limitations - AWS VPC peering allows communication between two directly connected VPCs. SteelConnect AWS transit VPC enables network traffic to travel among multiple VPCs without a direct connection between them. Transitive peering and edge-to-edge routing are possible with SteelConnect AWS transit VPC.
Simpler operations - It is much easier to configure and manage networks from a single hub rather than have a full-mesh infrastructure when applicable.
Visibility - Since all traffic flows through the hub site, it is much easier to analyze this consolidated traffic and assess traffic patterns in your networks in a comprehensive manner.
The following features are interoperable and supported with AWS transit VPC topologies:
High availability (redundancy) for hub gateways and spoke gateways.
WAN optimization using SteelHead in both hub sites and spoke sites.
Your topology must meet the following requirements to use this feature:
The hub VPC and all spoke VPCs must be in the same AWS region.
The minimum instance size for the hub gateway is t2.small.
In SteelConnect, the hub site must not be configured as an AutoVPN leaf of any other site.
In SteelConnect, spoke sites must not be configured as a master site.
In SteelConnect, the hub site must be deployed prior to deploying spoke sites.
Performing parallel deploy, undeploy, or manage operations on a transit VPC hub site or spoke site is not recommended.
Deploying an AWS transit VPC topology
Before you deploy an AWS transit VPC topology, ensure that:
you have identified which of your VPCs will serve as the hub site.
you have identified which of your VPCs will serve as spoke sites.
all VPCs are imported into SteelConnect Manager.
the hub site must be deployed prior to deploying spoke sites.
As a sample topology, consider two VPCs: one for applications for Engineering and the other a Security VPC. Sample AWS transit VPC site demonstrates a gateway deployed in the Security VPC as a hub site and the Engineering VPC as a spoke site.
Sample AWS transit VPC site
To deploy an AWS transit VPC topology with this sample topology
1. Connect the Security Hub VPC.
In SCM, choose Network Design > AWS. Select the Import VPCs tab and click Connect for the Security subnet.
Connect to the VPC
2. Deploy the gateway instance for the hub site.
From the Deploy Instances tab, find the site to use as a hub and click Deploy.
Deploying the gateway for the hub site
3. Connect the spoke subnet.
Connecting the spoke subnet
4. Deploy the gateway for the spoke subnet. From the Uplink drop-down, select Transit VPC and in the Transit Hub field set the VPC of your hub subnet. (The hub subnet should appear as an available option in the Transit Hub field.)
Deploying the spoke subnet
On AWS, the Peering Connection appears under the VPC Dashboard (SCM created this).
AWS peering connection
On SCM, a new WAN object for Transit VPC appears.
WAN object for Transit VPC
Under Sites, the two new AWS sites for the region you deployed in hub (AWS Transit Hub) and spoke (AutoVPN Leaf) mode appear.
AWS hub-and-spoke sites
Under Appliances on SCM, you can see the new appliances deployed on SCM.
AWS appliances in SCM
From the AWS console, you can review the route tables for the Security subnet and Engineering subnets populated with all the routes for the Organization’s networks (both on-premises and cloud).
Route table for Security subnet
Route table for Engineering subnet
There is no default route for the subnets. You need to add a default route if you want your subnets to reach the internet. To do so, click Edit for the Route Table and add an entry for the Destination 0.0.0.0/0 Target IGW (Amazon’s internet gateway) if you want to send the traffic direct to internet, or pcx (peering connection) if over the peering connection (recommended for traffic from the Engineering to Security subnet), or to the Uplink interface of the local gateway.
Deployment over AWS DirectConnect
For customers that already have an existing AWS Direct Connect (DX) circuit and want to extend their on-premises networks into their AWS cloud network over this private DX connection, SteelConnect can provide a secure overlay over the AWS backbone. This allows for SD-WAN features to be implemented at sites that are connected via Direct Connect.
In this deployment, at the on-premises branch office, the SteelConnect gateway is configured with two uplinks: one for the internet connection and the other for the private high-bandwidth DX connection. On AWS, you need to create a virtual gateway (VGW) in the appropriate region and then associate it with the DX circuit along with the VPC that is to be deployed from SCM.
AWS Direct Connect architecture
When Direct Connect is selected as an Uplink, the system selects a free /26 subnet and breaks it into 3 /28’s, (leaving one of the /28 subnets unused out of the four). One /28 subnet is allocated for the IGW uplink, and another for the VGW uplink used with Direct Connect. The downlink subnet consumes the last /28 subnet.
It is possible to have several VPCs connected to a central hub using the transit VPC OR normal IGW Leaf options, and then use the hub as the dual-linked gateway with Internet + Direct Connect uplinks.
If you use manual routing, no route table entries will be created in by SCM.
When automatic routing is selected, specific routes will be written to the AWS route tables of connected subnets in order to attract traffic. Static routes and propagated routes from the VGW Direct Connect, and will take priority, thus existing routes do not need to be deleted.
In SCM 2.10, the WAN that is selected to be used with Direct Connect must have encryption (overlay) enabled. Underlay WANs are not supported.
To deploy AWS Direct Connect
The SteelConnect Manager User Guide has detailed steps for Direct Connect configuration.
1. Connect to the Direct Connect VPC.
2. Deploy the gateway and specify the Uplink to be Internet + Direct Connect.
Setting the gateway uplink type for Direct Connect
3. In the Direct Connect WAN field, specify an overlay network.
The Direct Connect WAN field appears once you specify Internet + Direct Connect as the Uplink.
SCM only lets you connect to encrypted WANs and only encrypted WANs appear in this field.
In our sample topology, the DX circuit is over an encrypted MPLS connection.
Direct Connect WAN
When you deploy, SCM logs in to your AWS console and creates an overlay tunnel over your existing DX circuit from your VPC.
SCM creates two uplinks for the new AWS site: one over the internet and one over the DX circuit.
Direct Connect uplinks
Once deployed, the AWS gateway appears under Appliances. When you click it and view the IPs tab, you will see two IP addresses for the two Uplink connections over the IGW and VGW.
Direct Connect gateway IP addresses
In AWS, you will see an extra uplink subnet created for the DX connection, which routes over Amazon’s VGW.
Uplink subnet in AWS