Choosing a server region looks simple at first. Find out where most of your users live, select the nearest data centre and launch the server.
That is often a sensible starting point, but it is not the whole decision.
Your server also needs to communicate with databases, storage services, APIs, payment providers and other parts of your infrastructure. The nearest region to your visitors may not be the best choice if every request then has to travel to a database on another continent.
The goal is not simply to put the server close to the largest number of users. It is to reduce the total distance travelled by the requests that matter, while also considering reliability, cost, service availability and data residency.
Every request takes time to travel from the user to your server and back again. This delay is known as network latency.
Latency contributes to Time to First Byte, or TTFB, which measures how long it takes the browser to receive the first byte of a response. TTFB is affected by more than physical distance. DNS lookup time, connection setup, redirects, server processing and network quality all contribute to the final result.
Server location tends to matter most for requests that cannot be served from a cache, including:
A content delivery network can bring images, stylesheets and JavaScript closer to visitors, but it cannot automatically remove the delay from every dynamic request.
Begin with evidence rather than assumptions.
Your analytics platform should show which countries and cities generate the most traffic. For an existing website, look at several months of data so that seasonal campaigns or temporary traffic spikes do not distort the picture.
It is also worth looking beyond total visitor numbers. The users who generate the most revenue, logins or support requests may be concentrated somewhere different from the wider audience.
For example, a website might receive plenty of informational traffic from the United States while most paying customers are in the United Kingdom. In that case, optimising the application for UK customers may be more valuable than optimising it for the largest raw visitor count.
For a new service without traffic data, use the expected customer base, sales territory and launch market as your starting point. You can review the decision once real usage data becomes available.
A fast connection between the visitor and the web server will not help much if the web server has a slow connection to the database.
Where possible, keep tightly connected services in the same region. This usually includes:
Suppose your application server is in London but its database is in New York. A page that performs ten separate database queries may repeatedly cross the Atlantic before it can be returned to the user.
Moving the application closer to the visitor could make this worse rather than better if the database stays where it is.
External services matter too. If your application depends heavily on a particular payment provider, identity platform or third-party API, test the connection from each candidate region. The geographically closest region does not always have the best network route.
Cloud providers do not necessarily offer every product, server type or feature in every region. Before selecting a location, check that it supports the services your application requires.
Also consider:
Data residency may narrow the choice further. Some organisations are required by contracts, internal policies or regulations to store or process particular data within a defined country or geographic area. Cloud architecture guidance from both AWS and Microsoft recommends treating residency requirements as part of the region selection process, rather than addressing them after deployment.
Region selection is an infrastructure decision, not a substitute for legal or compliance advice. Requirements should be confirmed with the appropriate specialist.
Physical distance is useful, but actual performance is what matters.
Shortlist two or three sensible regions and test them from the locations where your users are based. A good test should measure more than a basic ping.
Check:
Synthetic monitoring services can run tests from several countries at regular intervals. Real-user monitoring can then show what actual visitors experience across different devices, networks and locations.
Measure representative parts of the application. Testing a lightweight homepage tells you very little about the performance of a logged-in dashboard or a complicated checkout process.
Most websites do not need to run in several regions.
A single well-chosen region is often the best option for:
Running in one region keeps databases, deployments, backups and troubleshooting comparatively straightforward. Availability can still be improved by using multiple availability zones within that region, provided the hosting platform and application support it.
AWS guidance specifically warns against introducing a multi-region architecture when a multi-zone deployment already meets the business requirements. Multiple regions can improve availability, but they also add cost and operational complexity.
A good default architecture for many websites is therefore:
That approach is usually more dependable than building an elaborate global system that the team cannot confidently maintain.
A content delivery network stores copies of cacheable content in edge locations around the world. Visitors can receive that content from a nearby location instead of requesting it from the origin server every time.
CDNs are particularly effective for:
Cloudflare, for example, caches common static file types by default. Dynamic HTML is not cached by default, although caching rules can be configured where the content is suitable.
That distinction is important. Pages containing account details, baskets, personalised pricing or private information should not be cached indiscriminately. Cache behaviour needs to account for cookies, authentication, response headers and the possibility of serving one user’s content to another.
A CDN can significantly improve the delivery of public assets, but uncached requests still need to reach the origin. The location and performance of that origin continue to matter.
Operating in multiple regions may make sense when there is a clear requirement that cannot be met by a single region and a CDN.
Common reasons include:
The difficult part is rarely deploying a second copy of the application. The difficult part is managing the data.
A multi-region system needs answers to questions such as:
Active-active systems, where multiple regions accept traffic and writes at the same time, can provide excellent global performance. They also introduce replication delays, conflict resolution and reconciliation problems. AWS guidance notes that read-only or read-heavy workloads are generally easier to distribute than write-heavy transactional applications.
For many businesses, an active-passive arrangement is more realistic. The primary region serves normal traffic while a secondary region is maintained for recovery. This still requires careful replication and regular testing, but it avoids some of the complexity of accepting writes in several locations simultaneously.
Once an application is running in more than one region, traffic needs to be directed to an appropriate location.
DNS services can return different regional endpoints based on latency, geography, endpoint health or routing rules.
Amazon Route 53, for example, can use latency-based routing to select the AWS region expected to provide the lowest latency. AWS also notes that this decision is based on measurements between users and AWS infrastructure, so it may not accurately represent resources hosted outside AWS.
Azure Traffic Manager provides a similar DNS-based traffic distribution layer. It does not proxy or process the application request itself. It directs the client towards an endpoint, after which the client connects to that endpoint directly.
DNS routing is relatively simple and works across different hosting providers, but DNS responses can be cached. Traffic changes and failovers are therefore not always immediate.
A global proxy or accelerator accepts the user’s connection at a nearby network edge and then forwards the request to an appropriate backend.
Examples include:
AWS Global Accelerator uses anycast IP addresses and routes traffic through the AWS global network to regional endpoints.
Google Cloud’s global external Application Load Balancer can direct traffic to the closest healthy backend with available capacity, while presenting a single global frontend to users.
Proxy-based services can respond to changing health and capacity without relying entirely on new DNS lookups. They may also provide TLS termination, caching, a web application firewall and other edge features. The exact behaviour and cost vary considerably between providers.
For most new deployments, the following process is sufficient.
Use customer data, analytics and commercial priorities. Do not base the decision solely on total page views.
Identify the database, storage, APIs, payment services and other systems involved in producing a response.
Remove any region that does not meet your service availability, residency, reliability or budget requirements.
Measure real application requests rather than relying only on ping tests or provider maps.
Place the application and closely connected data services together wherever possible.
Cache public content safely and reduce the number of requests that must reach the origin.
Start with backups and availability zones. Move to multi-region infrastructure only when the business requirements justify its cost and complexity.
Audiences change. New products launch in different markets, providers introduce new regions and external dependencies move. Region choice should be reviewed when the application or customer base changes significantly.
For agencies and technical teams, the most useful improvement is often consistency.
Region selection should form part of the onboarding process for every new website or application. Record:
This prevents infrastructure decisions from being lost when staff change or a project is handed over.
Performance should also be monitored from the client’s actual market. A UK agency may manage a website whose customers are mostly in Australia, Canada or the United States. Monitoring only from the agency’s office would provide a misleading view of the customer experience.
Avoid promising that a different server region will automatically make a slow website fast. Application code, database queries, plugins, image sizes, caching and third-party scripts often have a larger effect than geography. Server location is one part of performance work, not a replacement for it.
The best server region is usually the one that keeps the application close to its most important users and keeps its tightly connected services close to each other.
For a typical website, that means one carefully selected region supported by sensible caching, a CDN, reliable backups and ongoing monitoring.
For a global application, it may mean several regions, distributed data and a global traffic layer. That architecture should be introduced because the application has a measured performance, availability or compliance requirement, not simply because multiple regions sound more advanced.
Start with the users, trace the full request path, test the realistic options and choose the simplest setup that delivers the required result.
ServerAuth provides a whole host of management tools, from controlling who can access your server, to managing your website deployments. And with an ever-growing suite of tools you'll always be one step ahead!
Start for free
