Back in 2014, emnify launched its service based on the belief that IoT would transform cellular connectivity from merely a means of connecting individuals to enterprises being able to offer a globally-connected service or product - and indeed it did. We've been doing great in the space of providing cellular connectivity for enterprises. Now, we're building on that success and launching emnify Cloud Connect, a way for enterprises to connect their virtual private cloud and networks seamlessly to their IoT devices (that use emnify SIM cards) in order to capitalize on cloud-native services. Let's dive into the technology behind emnify Cloud Connect and how your enterprise stands to benefit from it!
Enterprises deploy and manage their IoT applications and projects in the cloud to not only benefit from highly-available, scalable cloud infrastructure but to also implement new, faster solutions using state-of-the-art cloud services for AI, image recognition, data analytics, and security.
Our connectivity service started as the industry's first public, cloud-native mobile core network and connectivity management platform. To build on cellular connectivity that serves as the basis for our connectivity service, we previously launched emnify Data Streamer, that provides a real-time event data stream using Kinesis. We are now introducing a way for customers to leverage cellular connectivity even further - emnify Cloud Connect enables cloud-native connectivity between IoT devices and customer infrastructure in a reliable, secure and scalable manner.
When do you need emnify Cloud Connect?
The advantages of the cloud environment are clear: upfront investment is low while availability is high, since access to geographically redundant infrastructure is made easier. With traditional operators the connectivity integration are not straight forward and you need private APNs, IPsec to get remote access to device and seperate your data from the public internet.
emnify Cloud Connect provides private, secure, and reliable cellular connectivity for your global IoT projects. This enables you to connect devices to your cloud platform, while allowing you to also have remote access to your devices. Instead of data being routed through the public internet the data is directly forwarded to your virtual private cloud.
How does emnify Cloud Connect work for AWS Customers?
In November 2018, Amazon Web Services (AWS) introduced a transit gateway service that provides virtual routing capabilities, while being fully managed and distributed by AWS. The primary goal of the transit gateway service is to provide a scalable alternative to VPC peering, since interconnecting VPCs results in a mesh-like topology, which can quickly grow to become too complex and difficult to maintain. The AWS Transit Gateway service takes a hub-and-spoke approach, with the transit gateway itself being the central connectivity management entity. There are also several other benefits to using transit gateway that are listed on the AWS Website.
For your IoT project running on the AWS cloud platform, emnify Cloud Connect works by utilizing emnify’s cloud-native packet gateway infrastructure and combining that with the AWS Transit Gateway. emnify Cloud Connect extends your virtual private cloud (VPC) to the mobile world, integrating your IoT Devices like any other network entities and functions you are using on AWS.
Customer VPCs and VPN gateways can be associated with emnify Cloud Connect by creating transit gateway resource attachments.
Transit Gateway as our choice of technology
emnify chose AWS Transit Gateway as the underlying technology that works with emnify Cloud Connect. We've done this for several reasons to benefit our customers, namely:
Customer Isolation
Because emnify provides breakout connectivity to many customers it is essential to provide isolation between the on-premise VPCs of customers as well as between the IP address ranges of their remote IoT devices. Customer isolation is enforced on a transit gateway thanks to the ability to configure separate route tables per transit gateway attachment. In this way, emnify can specify the allowed destinations on a per attachment (in other words, per customer) basis.
Security and High Availability
Security and high availability are essential to any connectivity solution. The traffic through a transit gateway remains private and isolated, like the traffic inside any VPC. Further the traffic never breaks out into public internet but only resides in the AWS premises.
A transit gateway attachment may and should be associated to multiple Availability Zones to increase availability. Ultimately, there may be a different number of availability zones associated to individual attachments. For optimal availability, emnify implemented failover mechanisms to ensure connectivity availability even in case availability zones become unavailable.
Routing of Transit CIDRs
Another property of the transit gateway is that it allows the routing of transit CIDRs. This is an important aspect because the IoT devices with emnify connectivity have static private IP addresses in the 100.64.0.0./10 shared address space. Routing towards this IP address range and its sub-ranges via the emnify production network is not possible using either VPC peering or site-to-site VPN because these are transit IP addresses (i.e. they are not allocated inside the customer VPC).
With transit gateway this becomes possible, without having to use an additional tunnelling layer (e.g. GRE) to “hide” the transit CIDRs.
Dynamic Route Propagation to other Cloud Platforms or On-Prem Infrastructure
Exchanging traffic between customer infrastructure hosted on-premise or in other cloud platforms requires a method to announce the emnify shared IP address range and respectively the customer IP range across the VPN. In order to do this in an automatic fashion a route-based VPN is used, meaning that emnify automatically configures a route for the customer in the Transit Gateway and the route is dynamically propagated using the Border Gateway Protocol (BGP). The transit gateway provides a very flexible route propagation mechanism that allows also to specify multiple VPNs for different subset of devices (separated by IP address subnets).
What are the steps involved when creating a Transit Gateway Resource Sharing?
We’ve previously mentioned the emnify production network connecting to the customers’ on-premise networks; meaning there are two separate AWS accounts involved. How can they be brought under the same transit gateway, and when it comes to connectivity, who manages what? The transit gateway is essentially managed by emnify and shared, via the Resource Access Manager, with the AWS Account IDs of customers (denoted as principals).
- As soon as a principal is added to the transit gateway resource share, an invitation is received by the principal.
- Upon accepting the invitation, a transit gateway is automatically created in the principal’s VPC.
- The customer must attach the transit gateway to its VPC, which triggers a transit gateway attachment to be automatically created on the emnify’s side.
- emnify then configures the routing through the transit gateway by populating the route tables associated to the emnify’s and respective customer’s attachments.
- On the customer’s side, the routing merely consists of setting the transit gateway as the next hop for the traffic destined for the mobile IoT devices.
The resource sharing mechanism provides for a clear delimitation of the management responsibilities of the two connectivity partners. While emnify’s transit gateway and the customer’s VPC show up in each other’s deployments, the route tables associated with the transit gateway attachments can only be managed by emnify, but emnify cannot access resources inside the customer’s VPC unless IAM roles are explicitly created for this purpose.
A transit gateway attachment to a customer can be terminated at any time by removing the principal from the transit gateway resource share.
How is the Transit Gateway deployed at emnify?
Figure 1 illustrates a typical Transit Gateway deployment.
Supported AWS Region
emnify Cellular Cloud Connectivity is available now in AWS Regions eu-west-1, eu-central-1, us-east-1, ap-southeast-1/2. Support for additional regions will follow later this year.
Conclusion
This concludes our introduction to AWS and its Transit Gateway service. We reviewed its capabilities and showed why routing transit CIDRs, support for customer isolation and scalability makes it so attractive for the emnify’s deployments. If you want to learn more about our cloud native services also watch our Cloud-native Services Website.
Contact us
If you run your workloads on Microsoft Azure or Google Compute Engine, and are interested to benefit from cellular cloud connectivity, please contact us to participate in our Beta Program with support for additional cloud environments.
emnify
The content team of emnify is specialized in all things IoT. Feel free to reach out to us if you have any question.
