Operate Globally with Twilio Regions and Edge Locations

Operate Globally with Twilio Regions and Edge Locations

Twilio is a world leading CPaaS (Communications Platform as a Service), and that means that we have to operate on a global scale to provide our customers with the best experience, both from a technical but also a regulatory view. To do this, we have to have infrastructure situated in data centers around the world, allowing our customers the flexibility to optimize their applications according to their customer base.

To take advantage of this global infrastructure, there are two parts of the Twilio platform that customers should familiarize themselves with; Twilio Regions and Edge Locations.

Twilio Regions

Local Data Processing And Storage in EU

At Twilio, we realize that the transfer of EU personal data to the US and other third countries might be an area of concern for privacy conscious EU citizens and EU data protection regulators. As part of our ongoing data privacy efforts, and since the Schrems II ruling these efforts became an even bigger priority, Twilio has committed to allow the ingestion, processing, and storing of data in data centers, not only in the EU, but across the world. This not only allows you to control where data is stored and processed, but it can also have the added benefit of increasing your application performance by reducing the latency of requests made to Twilio (we’ll cover this in more detail later). We call this effort the “Regionalization” of the Twilio product portfolio, or “Twilio Regions” for short.

Simply put, Twilio Regions will allow you to define that the work done by the Twilio platform will be carried out at a particular datacenter.* This would be the case regardless of whether that work is making a call, sending an SMS, or hosting your own code on our platform.

Edge Locations

Edge Locations are the ingress and egress points that your application has to communicate through the Twilio platform. Basically, this means that they define where the data you transfer to us actually enters (ingress) and exits (egress) our infrastructure and as you’ll see in this blog post, this can make a huge difference to the performance of your application.

Where Twilio Regions are concerned with ingesting, processing, and storing data, Edge Locations are concerned with optimizing the transfer of data to the regions.

If you have never worked with global infrastructure before, we know that this can easily become a confusing topic. So of course the natural next step to make things clearer is to talk about a construction site, its workers and how they get there. And no you didn’t misread that - just bear with me for a bit and hopefully it’ll become clearer.

Analogy for Twilio Regions and Edge Locations

We are Builders (Twilio Regions)

At Twilio, we believe to be successful you have to have the builder mindset and in fact one of the four main values of Twilio as a company is exactly that - “We are Builders”. Following along with this theme, we can draw a nice analogy between our global infrastructure and, as mentioned, a construction site and its workers. Specifically, we’ll have a fictional Irish construction site which has builders traveling every day from all over the world - in our example we’ll focus on builders coming from Frankfurt and Sydney.

In this example, the construction site is analogous to Twilio Regions in that any work done on one construction site stays on that construction site - it cannot be shared with any other construction site. In the same way, data processed and stored within a Regional Twilio datacenter stays within that datacenter, and cannot be shared with any other Twilio data centers.

This holds true regardless of where the worker came from, or indeed how the data came to be at that particular data center. As an example, it doesn’t matter if that worker came from Frankfurt or if they came from Sydney, the work that they do on the construction site stays on the construction site.

Getting to Work (Edge Locations)

In a similar way that we can say that the work done on a construction site is analogous to the work done within a Twilio datacenter, we can also draw similarities between how the worker gets to the construction site and also how data is transferred to a Twilio datacenter.

So let’s take the case of our Builder from Sydney - let’s call him Bob - traveling to work in the morning. In our fictional case, Bob will be traveling by plane every morning to Ireland from Sydney. If you’ve ever booked flights, you’ll know that there are many different options of how Bob could get to Ireland from Sydney, e.g. he could fly to Tokyo and then New York, over to Frankfurt and then from Frankfurt to Ireland.

Now this is obviously not the quickest route to get there as each of these “hops” to different airports will add extra time to Bob’s journey as he’ll need to transfer between planes etc.

Instead, the most efficient way for Bob to get to Ireland is via a direct flight, and this is the option he should take.

It is exactly the same situation for data traveling to Twilio data centers. If the data goes via the public internet, it is the same as if Bob were to travel by taking the route with lots of stop-overs. Below is a real world example of the hops which take place when data is traveling from London to Sydney. 

In the image above, you can see that there are actually 27 “hops” which take place before the data finally finds itself in Sydney, with each of these hops adding to latency through processing and also distance traveled. The route taken above is also not a one-off or an exception - it is in general the way in which data travels across the public internet.

This is where Edge Locations come in. Edge Locations act as our carrier, which offers a direct flight from Sydney to Ireland. By going to an Edge Location (in our example the Edge Location in Sydney) you get direct access to the Twilio network infrastructure which can transfer your data directly to the datacenter you need without all the hops in between (directly to Ireland instead of through Tokyo, New York and Frankfurt). This means that your requests get to where they need to go faster, thereby increasing the performance of your application.

Edge Locations are a means to increase the performance of your application by reducing the latency of requests made to Twilio. You can find a list of all available Edge Locations here.

Time for a New Job, Bob

We mentioned before that another potential benefit of using Twilio Regions is that it can also reduce the latency of requests made to Twilio. So, let’s again look at our construction worker, Bob, who has until now been traveling every day to Ireland from Sydney.

This is a long commute for Bob and, as you can imagine, he is getting tired of it and looking for other options. Luckily, the company Bob is working for in Ireland also has a construction site available for him to work at in Sydney. This is obviously going to reduce Bob’s commute drastically, and so he gladly decides to start working at this construction site instead. Bob will now work entirely within the Sydney construction site, and any work he does will have no effect on the Irish construction site.

In exactly the same way that Bob can reduce his commute by instead working in Sydney, you can reduce the latency of your applications requests to Twilio by changing the Twilio Region that you work from. In this example, we would change the Twilio datacenter from Ireland to Sydney. Now, instead of using an Edge Location to optimize a much longer route to Ireland, we do not have to travel beyond Sydney at all, which will improve your latency even more than using Edge Locations could.

Summary - The Where and the How

Hopefully now you have a better sense of what Twilio Regions and Edge Locations are and how they can be used within the context of your application. We saw that Twilio Regions allow you to define where data will be ingested, processed, and stored, whereas Edge Locations can be used to optimize how your data gets to Twilio.

If you want to find out more or are looking for a more in-depth technical review of Twilio Regions, you can learn more about Twilio Regions in our documentation, and learn more about Edge Locations here.

* Certain data may be sent to another Twilio region for purposes such as billing, logging or fraud detection. Please consult the documentation of the product you are using to check what this data may be.

Calum Muir is a Senior Solutions Engineer based out of Munich who has spent the last few years helping to digitalise the world. With a Masters degree in Electrical Engineering he made the switch to software partly after having a 3 hour roundtrip commute to London and so can sympathize with our construction worker, Bob. He is always keen to talk Twilio and can be reached at cmuir [at] twilio.com.