Twilio Regions
Twilio Regions are isolated data centers around the world where Twilio performs the processing and storage required to enable your application's communications activities.
Twilio's default Region is located in the eastern United States (US). If you are operating your application or serving a customer base in a different part of the world, you might be aware that relying on Twilio's US-based infrastructure can result in serious business challenges such as:
- Severe latency due to the geographical distance between your application and Twilio
- Unmet data residency requirements
This guide introduces the key concepts you need to understand to overcome these challenges by integrating your application with a non-US Twilio Region.
By reading this guide, you'll learn:
- What kinds of processing and storage are carried out in Twilio Regions
- How Twilio's Region isolation model works, and how it impacts your application design
- How to select an optimal Twilio Region for your application
We refer to Twilio-powered communications activities as workloads.
Twilio workloads include activities such as sending SMS messages via API, handling incoming calls to your Twilio phone numbers, and connecting participants over a Video conference. Twilio carries out your workloads by performing processing and data storage on servers hosted in one of Twilio's core data center locations. Twilio calls these data center locations Regions.
Regardless of where in the world your application and users are located, Twilio must process your workloads in some Region. Twilio stores most data generated by a workload in the same Region where the workload is processed.
By default, all workloads are handled in the United States (US1) Region.
This can lead to challenges related to high latency for applications that aren't located near the eastern United States, and to unmet data residency requirements for businesses that must comply with local data privacy regulations.
With the availability of Twilio Regions outside of the United States, you can resolve these issues by configuring your application or clients to use a non-US Region of your choice.
Warning
Note that during this initial phase of the rollout of Twilio Regions, Twilio does not guarantee that all data will remain within your selected Region.
Twilio provides various services that can be used by your application. The following table shows several activities (a.k.a. workloads) carried out by some of these Twilio services, along with a sample of the corresponding processing and storage activities that Twilio performs in a Region.
Application activity (a.k.a. workload): Accept a call to your Twilio phone number
Processing examples:
- Look up webhook URL
- Send webhook request
- Parse response
- Initiate TwiML actions
Data storage examples:
- Call record and event logs
- Webhook request and response logs
- Call recording (if enabled)
Application activity (a.k.a. workload): Add a participant to a Video Group
Processing examples:
- Authenticate API call
- Look up Video Room
- Create participant record
- Establish audio/video channel records for the participant
Data storage examples:
- API request logs
- Room, Participant, Channel records
- Audio/video track recordings (if enabled)
Application activity (a.k.a. workload): Post a message in a Conversation via WhatsApp
Processing examples:
- Authenticate API call
- Look up Conversation
- Insert message into publishing queue
- Send message to client devices
Data storage examples:
- API request logs
- Conversation record
- Message record
- Delivery records
Application activity (a.k.a. workload): Initiate an outbound call from your SIP-connected PBX infrastructure
Processing examples:
- Authenticate SIP traffic
- Proxy the SIP INVITE
Data storage examples:
- Call logs
Warning
Not all products and features are available in Regions outside of US1. For a full list of regional product and feature availability, see our Regional product availability page.
Aside from some required administrative and billing infrastructure, each Twilio Region operates in a fully isolated manner: all processing activities and data storage are specific to a single Region and cannot be accessed across Regions.
This strict isolation model provides the following important properties:
- Twilio constrains all data related to a workload to the Region in which the workload is processed, allowing customers full control over where their data resides and ensuring low latency.
- System failure or network disruptions in one Region do not impact workloads being handled in other Regions.
Given this isolation model, an individual Twilio Region effectively functions as an entirely separate instance of Twilio.
We'll discuss the isolation model's application design implications in more detail in the following sections.
Twilio workloads have dependencies on persistent Twilio data entities, called resources. These resources belong to the Twilio Account (or Subaccount) that the workload is acting on behalf of. Customers create and manage an account's resources via the Twilio Console or the REST API.
Some examples of resources within your Twilio Account that your workloads might depend on include:
- Twilio API Keys
- Phone numbers
- Call logs
- Messaging Services
- TwiML Applications
- Studio Flows
- Serverless Functions
- Flex configurations
- Video Rooms
- Email Templates
- Access Control Lists
Below are some examples of applications and the Region-specific operational Twilio resources that they might require.
Example: SMS notification system
Required Twilio resources:
- Twilio API Key
Example: Interactive Voice Response system using Twilio Studio
Required Twilio resources:
- Phone Number configuration
- Studio Flow definition
Example: Interactive Voice Response system using Twilio SIP Interface
Required Twilio resources:
- SIP Domain configuration
- SIP Domain Access Control List
For these applications to work correctly, each required resource must be present in the same Region where the application is configured to process its Twilio workloads.
In addition to the persistent Twilio resources described above, which are created and managed by the application operator, some Twilio resources are created as a product of the execution of your application's workloads. Examples of these resources include:
Resource: Call records
Description:
A Call record is created whenever:
- Twilio handles an incoming call to your Twilio phone number
- Your application initiates an outbound call via Twilio
Resource: Recordings
Description:
A Recording is created when a Call or a Conference occurs and has voice recording enabled.
Resource: Message records
Description:
A Message record is created whenever:
- Twilio handles an incoming SMS message to your Twilio phone number
- Your application initiates an outbound SMS message via Twilio
Resource: Studio Flow Execution records
Description:
A Studio Flow Execution record is created each time your Flow is triggered by an incoming call or message
All of your account's Twilio resources, whether created by an administrator during application setup or created by your application's workloads, can be accessed via the Twilio Console or the REST API. Either way, resources are accessed on a Region-specific basis.
For example, consider that you have a Programmable Voice application processing workloads in the Australia (AU1) Region, and you wish to review a list of the application's incoming calls for the last week using the REST API. If you query the REST API's /Calls endpoint using the default target Region of US1, your application's Call records will not be returned. Because the workload (handling incoming calls) was not processed in US1, the resulting records do not exist in that Region. To access the records, you'll need to make an API request specifically against the AU1 Region where the calls were handled and the resulting Call records were created.
Check out this guide to learn more about managing Region-specific resources with the REST API.
While the resources discussed above are Region-specific and must be managed on an individual Region basis, Twilio shares certain Account-level resources across all Regions.
These shared resources include:
- Owned Twilio phone numbers
- Regional routing configurations
- Account-level billing and usage records
- Console Users
Each of these resources exist and are managed independently of Twilio Regions.
For example, your Account (or Subaccount) will have a single global pool of purchased phone numbers, and you can set a configuration for each phone number to specify which Region should handle incoming calls and messages to the number.
Similarly, your Account contains usage and billing related data at a global level, which records your usage and incurred billing items across all Twilio Regions.
You can manage Account-level resources via the Account section of the Console, or via the REST API in the US1 Region only.
When designing your application, you should think carefully about which Twilio Region is best suited to minimize network latency and adhere to your application's data residency requirements.
The distance your application's data needs to travel in order to reach Twilio has a direct impact on network latency. Excessive latency can lead to poor audio or video quality, ultimately resulting in a degraded customer experience. You should aim to minimize latency by selecting the Region which results in the shortest possible round trips between your servers or clients and the Region where your workloads are processed.
Imagine that you're hosting an IVR application on your servers located in Australia (AUS). Your application uses the default Twilio Region, US1.
When Twilio receives an incoming call to your application's phone number, the event is processed in the US1 Region. A webhook request is initiated from Twilio's servers in US1 to your application's servers in AUS. A TwiML response returned by your servers instructs Twilio how to greet the caller. (Read more about this architecture pattern in our IVR tutorials.)
The webhook request from US1 to your servers in AUS traverses such a great distance that even with the highest possible network speeds (which are universally limited, after all, by the speed of light), a certain degree of elevated round-trip latency is unavoidable. This causes a noticeable delay for the caller after the call is initially connected and an awkward period of silence after each time they enter input that needs to be transmitted to your server.
If your application used Twilio's AU1 Region instead of US1, then the round-trip distance would be considerably shorter, resulting in lower latency. Such a substantial reduction in round-trip latency can increase the responsiveness and perceived quality of your application significantly.
If you need to ensure that your customers' data remains within a particular country or region of the world for regulatory or other purposes, consult our Regional product and feature availability reference to find out which Region is based in a location that meets your geographical requirements.
With your application and clients configured to use the target Region, your Twilio workload's data will only be stored within that Region.
Warning
Note that during this initial phase of the rollout of Twilio Regions, Twilio does not guarantee that all data will remain within your selected Region.
To read more about the subject of data privacy and regulatory compliance for Twilio applications, see our forthcoming guide on that topic.
If it turns out that your application would in fact best be served by the US1 Region, you're in luck: US1 is the default Region where all workloads are processed if a Region isn't explicitly selected. Incoming calls and messages are routed to US1 if no specific routing is specified, and all Twilio resources created by you or your application are created in US1 by default.
Learn more about building with Twilio Regions by checking out one of the following tutorials: