The Breakout Connectivity for AWS Customers

1. Problem Statement 

AWS is the cloud computing platform of choice for many of the EMnify customers. The advent of the AWS Transit Gateway enables EMnify to significantly enhance reliability, QoS and manageability of the breakout connectivity to these customers. 

This document describes the steps an EMnify customer using the AWS cloud platform should follow in order to successfully setup the breakout connectivity with the EMnify production network via a shared Transit Gateway. 

Figure 1 illustrates a Transit Gateway connectivity scenario. 

Figure 1 Transit Gateway Connectivity Overview 

2. Breakout Connectivity Setup 

The breakout connectivity is set up in two steps. First, a Transit Gateway Resource Share is created between EMnify and the customer’s AWS account. Then, the routing is configured so as to enable data traffic to be exchanged between the endpoints and the on-premises application servers, via the shared Transit Gateway. 

2.1 Configuration Parameters Exchange with EMnify 

In order to set up a shared Transit Gateway, a customer has to provide EMnify with his/her AWS Account ID as well as the region where he/she wants to set up the breakout connectivity.  

EMnify will provide the name of the Transit Gateway resource share. 

A customer can retrieve her/his AWS Account ID by clicking the “My Account” link as illustrated in Figure 2. The region where the breakout connectivity is set up is basically the region where the customer application servers are located (in our example this would be “Ohio” or us-east-2). 

Figure 2  Retrieving the AWS Account ID and Region 

2.2 Creating a Transit Gateway Resource Share 

The configuration data provided by the customer (AWS Account ID and region) enables EMnify to initiate the process of sharing a Transit Gateway with the customer. As a result, following the configuration parameters exchange, the customer will receive a Resource Share invitation in the Resource Access Manager console, as illustrated in Figure 3.

Figure 3  Resource Share Invitation 

Figure 4  Accept a Resource Share 

As a result, the Resource Share transitions from the “Pending” into the “Active” state and the shared Transit Gateway becomes visible in the customer AWS deployment (see Figure 5). Note that the Transit Gateway is owned by EMnify and it is not possible to configure it in any way (e.g. assign it a Name tag) or attach any routing table to it. 

Figure 5  Shared Transit Gateway 

2.3 Routing Configuration 

In the next step, the customer shall set up the routing. This activity includes the following steps: 

1. Attach the Transit Gateway to the VPC, 
2. Configure the VPC Route Tables to route traffic through the Transit Gateway, 
3. Configure the Security Groups to accept traffic received through the Transit Gateway.  
4. Create Transit Gateway Attachment 

From the Transit Gateway Attachment option on the left hand menu in the AWS console, the customer shall create a Transit Gateway Attachment and attach the VPC where the Application Servers are located to the shared Transit Gateway. During the process, the Transit Gateway can be configured to attach to one or multiple subnets of the VPC. In our example, we assumed Application Servers are located in two subnets (see Figure 6) and accordingly attached both of them to the Transit Gateway. 

2.3.1 Create Transit Gateway Attachment 

From the Transit Gateway Attachment option on the left hand menu in the AWS console, the customer shall create a Transit Gateway Attachment and attach the VPC where the Application Servers are located to the shared Transit Gateway. During the process, the Transit Gateway can be configured to attach to one or multiple subnets of the VPC. In our example, we assumed Application Servers are located in two subnets (see Figure 6) and accordingly attached both of them to the Transit Gateway.  

Figure 6  Create a Transit Gateway Attachment 

2.3.2 Configuring the VPC Route Tables 

In order to route the traffic destinated to the endpoints through the Transit Gateway, the VPC routing table(s) have to be configured. This depends on the actual routing configuration of the customer VPC, which may use the main Route Table, per-subnet custom Route Tables or a combination of both (see https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html).  

As a reminder, custom Route Tables shall be explicitly associated with one or more subnets in order to have an effect on the routing decisions for the respective subnet(s). The main Route Table, on the other hand, maybe explicitly associated with one or more subnets and is implicitly associated with all the subnets that are not explicitly associated with any route table. With this in mind, route table entries shall be added to all the relevant Route Tables, to specify that traffic towards the IP address ranges allocated to the customer’s endpoints is routed via the shared Transit Gateway, as illustrated in Figure 7. 

Figure 7  Route Table Configuration 

In order to avoid the necessity to update the route tables each time a new IP address range is allocated for the customer endpoints, an “all including” address space (e.g. 100.64.0.0/16) may be configured from the start. This is a safe practice and no interference with foreign endpoints will occur because on the EMnify side the routing to each individual IP address space is done on a per-customer basis. 

2.3.3 Configure the VPC Security Groups 

As the last step, Security Groups shall be configured so that traffic from the customer endpoints is allowed to reach the customer Application Servers. The exact process depends again on the specifics of the customer deployment. One way to do it is to define a dedicated Security Group (see Figure 8) and associate it to each Application Server, in addition to the existing Security Groups, as illustrated in Figure 9.  

The Security Group rules may be made more specific by narrowing down the port and protocol to the specific applications and application servers used. 

At this stage traffic between the endpoints and application servers can flow in both directions. 

Figure 8  Security Group Configuration 

Figure 9  Routing via the Virtual Network Gateway 

3. Charging Initiation and Termination  

EMnify initiates the monthly charging for the breakout connectivity as soon as the customer VPC is attached to the shared Transit Gateway. Note that in addition to this, AWS charges the customer AWS account an hourly fee for the attachment to the EMnify’s shared Transit Gateway. Depending on the customer region the price is 0.05 to 0.09 USD per hour. 

The breakout connectivity can be terminated at any time by deleting the Transit Gateway Attachment and leaving the resource share, at which time the monthly charging from EMnify stops. In order to leave the resource share, select the shared Transit Gateway from the Resource Access Manager console and click on the “Leave resource share” button, as illustrated in Figure 10. 

Figure 10  Leaving the Resource Share 

4. Concluding Remarks 

Currently, overlapping IP address ranges of customer premises are not supported. Therefore, a customer will be required to use a different IP address range for his/her on-premise Application Servers if the desired IP address range is already assigned by another customer. In order to reduce the incidence of overlapping, EMnify enforces customers to use for their on-premise IP address ranges a 24 bit or longer prefix length. 

The Transit Gateway resource share invitation shall be explicitly accepted by the customer and the customer shall associate the shared Transit Gateway to the VPC where the Application Servers are located. 

It is safe to use an “all including” range for the endpoints address space in order to avoid repeated updates to the route tables and security groups each time new endpoint address spaces are allocated.