Understanding Edge Locations

Your application connects to Twilio in order to use services provided by Twilio products. The following table shows a sample of service activities that require making a connection to Twilio:

To initiate any of these activities, your application needs to send data to a Twilio Region where the activity is ultimately processed.

Rather than connecting directly to a Twilio Region, your application sends data to a Twilio Region through an Edge Location: the client establishes a secure connection with an Edge Location, which then transmits data from the connection to the destination Region, where the data is ultimately processed to carry out the activity.

The target Edge Location and destination Region for a connection are specified by including them in the Fully Qualified Domain Name (FQDN) of the hostname used for the connection.

The format of a Twilio FQDN specifying a target Edge Location and Region follows the pattern of:

For example, to send an API request to the United States (US1) Region via the tokyo Edge Location, you would use the following hostname:

Some Twilio services need to initiate outbound connections to your applications or infrastructure.

The following table shows a sample of activities which require Twilio to make an outbound connection:

The processing that initiates these outbound connections always occurs within a Twilio Region. However, from the perspective of your application, connections from Twilio always originate from your selected Edge Location (or the default Edge Location, if one is not specified).

To learn how to configure which Edge Location Twilio uses when connecting to your application, see our guide to configuring your application for Edge Locations.

From a pure client/server networking perspective, there are only two parties involved in connections between your application and Twilio: your application, and a Twilio server at an Edge Location. However, when considering the entire end-to-end data flow between your application and Twilio from a holistic system architecture point of view, there are actually three main components involved:

• Your application
• An Edge Location, which effectively acts as a reverse proxy server
• A Twilio Region that that the Edge Location sends data to for processing

Your application only makes or receives network connections to and from the Edge Location; it never connects directly to a Twilio Region. However, it's important to remember that behind the scenes, data is also transmitted between the Edge Location and the target Region.

Thus, there are effectively two logical connection "legs" comprising an end-to-end data flow between your application and Twilio:

The outer leg of an end-to-end connection typically traverses the public Internet, while the inner leg always traverses Twilio's internal network.

Twilio's internal network consists of high speed links between all of our Edge Locations and Regions around the world, and offers high availability and reliably low latency.

Connections traversing the public Internet, on the other hand, often involve many "hops" between routers operated by various service providers. These connections can suffer from degraded performance, lower reliability, and a lower level of security.

Thus, when selecting an Edge Location for your use case, you should always aim to minimize the length of the outer connection leg, by selecting the Edge location nearest to your application. This will ensure that your application's data gets off of the public Internet and into Twilio's internal network as quickly as possible.

This example illustrates how selecting an optimal Edge Location can impact the performance of your application.

Imagine that you have an Interactive Voice Response (IVR) application hosted in Australia that uses Twilio features that are only available in the United States (US1) Region. Your application's Twilio API request data must ultimately be sent to US1 for processing. However, the outer connection leg to Twilio's network can be made via any Edge Location.

By default, the API requests that your application makes will connect using the ashburn Edge Location in the eastern United States:

Expand image

In this scenario, the outer leg of the connection spans the entire distance between your application server in Australia and the ashburn Edge Location in the United States, while the inner leg spans virtually no distance at all (since the Edge and the Region are located in the same city, and are directly connected). This configuration does technically work, but it has some major disadvantages:

1. Long distance round trips during TLS session negotiation

Twilio API requests are made over HTTPS. The client establishes a TLS session with a server at the Edge Location it is connecting to.

Since the setup of a TLS session involves a series of round trips between client and server, the distance of those round trips can have a large impact on the overall duration of a request.

2. Long distance traveled over the public internet

With your application in Australia connecting to an Edge Location in the US to establish the outer leg, the vast majority of distance covered by the end-to-end connection traverses the public Internet rather than Twilio's internal network. This can lead to suboptimal performance and reliability.

The combination of the above two points can result in excessive latency in your application's API requests.

Let's take a look at what happens when we instead route the requests to Twilio via the sydney Edge Location in Australia instead of the default ashburn Edge:

Expand image

Note that the outer connection leg is now much shorter, with the majority of the distance being covered by the inner leg of the connection.

This is advantageous to the overall request performance:

• Shorter round trip for TLS negotiation
• The majority of distance is traversed over Twilio's internal network rather than the public Internet

Learn how to use Edge Locations with:

• Programmable Voice: Mobile SDKs
• Programmable Voice: Javascript SDK
• Programmable Voice: SIP endpoint Registration
• Programmable Voice: SIP outbound traffic
• Programmable Voice: Failover
• Elastic SIP Trunking
• Outbund Twilio Webhooks