Understanding Edge Locations
Twilio operates a collection of DNS-addressable network edges around the world, called Edge Locations. Edge Locations provide the entry and exit points where your application's network traffic connects to 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.
Twilio automatically selects the optimal Edge Location for your requests using geo-aware DNS and CDN-backed routing infrastructure. This improves latency and resilience by directing your application traffic through the nearest available Edge Location.
By reading this guide, you'll learn:
- What types of connectivity are supported by Edge Locations
- How Edge Locations relate to Twilio Regions
- How automatic Edge Location selection works
- The proper hostname format to ensure optimal routing
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.
To control where your data is processed, authenticated, and stored, use the fully-qualified hostname format:
**PRODUCT**.**EDGE_LOCATION**.**PROCESSING_REGION**.twilio.com
Example:
api.sydney.us1.twilio.com
The processing region (e.g. us1, ie1, au1) defines where Twilio handles the request.
The Edge Location must be specified; however, Twilio may override it based on the request's geographic location to route traffic through a more optimal Edge Location.
Always include the edge location
If you use a hostname without any edge location then your requests will route through US1. For example, a hostname of api.ie1.twilio.com does not enable regional processing outside of US1.
Always use the following FQDN format:
<product>.<edge-location>.<processing-region>.twilio.com
This ensures:
- Your requests are processed at the region of your choice
- Twilio will optimize the Edge Location based on the location of the request
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 an optimized Edge Location based on your geographic location.
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 |
Learn how to use Edge Locations with: