Twilio Regions

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.

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

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:

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.)

Expand image

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.

Expand image

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.

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:

• Route a phone number's incoming calls to a non-US Region

• Make an outbound phone call via REST API in a non-US Twilio Region

• Use the Programmable Voice Javascript SDK with a non-US Twilio Region