Intelematics

CASE STUDY

Hosted Direct Connect (DX) shared across multiple VPCs

Intelematics leverages the flexibility and modern services of Amazon Web Services (AWS) to share a single hosted AWS Direct Connect (DX) deployment across multiple AWS VPCs

Background

Intelematics is a wholly owned subsidiary of RACV, pioneering the introduction of telematics and connected vehicle services through supporting manufacturer programs. Programs include car monitoring systems that have been preventing accidents for almost 20 years. Being at the forefront of technology, Intelematics has implemented scalable and reliable solutions over many years, earning the trust of some of the world’s most respected automotive brands. Today, they help millions of drivers all over the world by leveraging cloud-based architecture to enable secure connected vehicle and traffic data solutions with a firm focus on the needs of their customers. Intelematics flexibility, innovation, support infrastructure and agnostic approach to hardware provides an effective solution for transport and city planners, automotive manufacturers, fleets, automotive clubs, government and industry bodies.

Challenge

A component of Intelematics’ SUNA solution consists of many remote encoders/decoders that provide broadcast and monitoring information for radio stations all across Australia. Some of these devices are located in very remote locations and use legacy xDSL access technologies for connectivity back to Intelematics data centres in Melbourne/Sydney. There was a requirement for an initial 6 AWS VPCs to have access to the remote encoder devices via the MPLS during the cloud migration phase, as well as the end state solution.

Commercial and timing constraints meant that Intelematics needed to use the current MPLS Service Provider’s (SP) product offerings.

Solution

An AWS “Network” Account was created to provide connectivity services to all other Intelematics application VPCs across various accounts. This account consisted of the following AWS network related services:

VPC

Direct Connect Gateway

NAT Gateway

Direct Connect

Private VIF (hosted)

Virtual Private Gateway

Transit Gateway

Solution Options

The following solutions were considered and evaluated:

Option 1

VPN attachment to AWS TGW. Ruled out as the SP did not offer a managed FW service meaning Intelematics would need to provide their own FW co-located which was against the DC exit strategy.

Option 2

Dedicated DX with transit VIF attachment. Ruled out due to cost. DX VIF terminated on SP managed router.

Option 3

Hosted DX with private VIF, DXG and VGW in each VPC. Not preferred option as does not scale past 10 VPCs (AWS limit number of VGW per DXG). DX VIF terminated on SP managed router.

Option 4

Hosted DX with private VIF, DXG and single VGW in “Network VPC”. Chosen option. VGW in single VPC employed to share hosted VIF for all VPCs using AWS TGW and NAT Gateway. DX VIF terminated on SP managed router.

The hosted VIF provided by the SP DX partner was created with a Direct Connect Gateway and associated with the Virtual Private Gateway attached to the Network Account VPC using dynamic routing (BGP). In this way the SP on-prem router only received a single prefix (i.e. the CIDR of the Network VPC). A Transit Gateway (TGW) was employed to provide the “hub” function of a hub and spoke network topology. Application VPCs form the “spokes” (refer to the architecture diagram appended). 4 The Network VPC private subnets (associated with the TGW attachment) contains a default static route to the applicable NAT-GW in the Availability Zone. This ensures connectivity to the SP MPLS with a source NAT to the private IP of the NAT-GW interface.

This topology was chosen due to the type of DX procured by Intelematics from the SP. The hosted DX does not support Transit VIF and thus cannot be connected directly to the TGW. The NAT solution employed in the Network VPC allows the DX to be used by all Application spoke VPCs as it circumvents the non transitive nature of a VPC. The alternative was to use a Dedicated DX with Transit VIF, however this was deemed to not be cost effective. High Availability is realised using AWS best practice methodology such as multi-AZ deployment for applications and services. The Network VPC has NAT-GW instances configured in all 3 AZs in apsoutheast-2 region. There does still exist single points of failure for the Direct Connect connectivity. Only a single DX was procured from Summit Internet due to cost considerations. DX VIF terminated on SP managed router. The TGW provides the required connectivity to application VPCs and consists of two route tables:

Outcomes

This NAT-GW solution used allowed for only the Network VPC CIDR to be advertised to the SP MPLS network regardless of the CIDRs of the spoke VPCs. This means as the number spoke VPCs increases, the SP’s managed router does not require a configuration update for BGP prefix filtering. The use of source NAT for AWS TCP client connections to the MPLS network also increases security as it limits the MPLS view of Intelmatics’ AWS topology.

This network solution was also feasible as Intelematics’ application connectivity (from a TCP point of view), are initiated from AWS spoke VPC instances and thus there are no inbound TCP connections to AWS from the MPLS network. Inbound connections to spoke VPCs are possible over the hosted VIF, however they would require a reverse proxy function employed in the Network VPC.