Understanding Edge Locations
Twilio operates a collection of DNS-addressable network edges around the world, called Edge Locations. Edge Locations allow you to control the geographic location where your application's network traffic enters and exits Twilio's platform.
Your applications can connect to any of Twilio's public Edge Locations over the Internet, at no additional cost. Alternatively, you may opt to connect to one of our private Edge Locations for a higher degree of security and reliability. To learn more about using private Edge Locations, see the Twilio Interconnect product overview.
You can improve the performance and resiliency of your application by selecting an optimal Edge Location for your Twilio use case.
By reading this guide, you'll learn:
- What types of connectivity are supported by Edge Locations
- How Edge Locations relate to Twilio Regions
- Some concrete ways that Edge Locations can improve your application
- How to select an optimal Edge Location for your use case
Info
To see a complete list of available Edge Locations, see the reference page.
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:
| Activity | Connection Type |
|---|---|
| Make a Twilio API request to send an SMS using Twilio Programmable Messaging | HTTPS |
| Initiate an outbound phone call from your PBX infrastructure via Twilio Elastic SIP Trunking | SIP |
| Connect to a Video Room from a mobile application that uses the Twilio Programmable Video SDK | Websocket |
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.
Info
Any Edge Location can be used in combination with any Region.
For example, your application hosted in Santiago, Chile may connect to the US1 Region via the sao-paulo Edge Location. If the sao-paulo Edge Location becomes unavailable for any reason, your application may connect to US1 via the ashburn (or any other) Edge Location, instead.
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:
<product>.<edge-location>.<region>.twilio.com
For example, to send an API request to the United States (US1) Region via the tokyo Edge Location, you would use the following hostname:
api.tokyo.us1.twilio.com
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:
| Activity | Connection type |
|---|---|
| Sending webhook callback requests to your application | HTTPS |
| Forwarding an incoming call to your PBX infrastructure using Twilio Elastic SIP Trunking | SIP |
| Connecting a call to a mobile application that uses the Twilio Programmable Voice SDK | Websocket |
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 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:
| Leg | Spans | Transport mechanism |
|---|---|---|
| Outer | Client to Edge Location | Public Internet (or private Interconnect) |
| Inner | Edge Location to destination Twilio Region | Twilio's internal network |
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.
| If you are an Interchange customer, you will have an assigned private Edge Location that you'll use. |
|---|
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:
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:
- 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.
- 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:
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: