Choosing a GPU cloud region: latency, data residency, cost

Region choice is a workload decision

Reviosa runs GPU capacity in four regions: US East (us-east-1, Ashburn, Virginia), US West (us-west-2, Portland, Oregon), EU Central (eu-central-1, Frankfurt), and Asia Pacific (ap-northeast-1, Tokyo). Our published rates are identical in all four, so the region decision is not a price decision. It is about where your users are, where your data is allowed to live, where your data already sits, and what capacity you need.

Training and inference answer those questions differently. A training job talks to its dataset and checkpoints, not to end users, so latency to people is irrelevant and data location dominates. An inference endpoint talks to users on every request, so latency and the jurisdiction of user data dominate. Many teams end up training in one region and serving from two or three.

Typical latency from users to each region

The table below shows typical public-internet round-trip times (RTT) from major metros to each region. These are approximate ranges based on commonly observed internet routing between these cities, not guarantees or measurements of our network. Last-mile conditions, ISP peering, and mobile networks can add 10-50 ms or more.

Treat this as a starting point, then measure from where your users actually are. A small synthetic probe from a few client locations to each region takes an hour to set up and replaces guesswork with data.

How much latency actually matters

For LLM inference, network RTT is often smaller than people expect relative to model time. A streamed chat response has a time-to-first-token of a few hundred milliseconds to a few seconds, dominated by queueing and prefill. Adding 80 ms of transatlantic RTT to a 700 ms TTFT is noticeable in a dashboard but rarely in a product. After the first token, streaming hides RTT almost entirely.

Where latency is decisive:

• Real-time voice and conversational agents. Speech-to-text, LLM, and text-to-speech chained together can make several round trips per turn. At a target of under one second end to end, every 100 ms of RTT is a large fraction of the budget.
• Agentic workflows with many sequential calls. An agent that makes 20 tool calls and model calls in sequence pays the RTT 20 times.
• Interactive image and video tools where users expect the canvas to react quickly.
• Bulk batch inference, by contrast, does not care about latency at all. Run it wherever capacity and data are.

A useful rule: if network RTT is under roughly 10% of your end-to-end p95, region choice for latency is a nice-to-have. Above that, put compute near users.

Data residency: high-level considerations

This section is general orientation, not legal advice. Data protection obligations depend on your specific data, contracts, and jurisdictions, so confirm your requirements with counsel.

European Union (GDPR). The GDPR does not strictly require that personal data stay in the EU, but it restricts transfers outside the European Economic Area unless a transfer mechanism applies, such as an adequacy decision or standard contractual clauses. Many teams simplify compliance by processing EU personal data in an EU region. Our privacy policy describes how we handle data for customers in the EEA and UK, including users of our Frankfurt region. If you fine-tune on EU user data or serve EU users with prompts containing personal data, eu-central-1 is the natural home.

Japan (APPI). Japan's Act on the Protection of Personal Information requires, in general terms, either the individual's consent or an appropriate framework before personal data is provided to a third party in a foreign country, with some exceptions. Japan and the EU have mutual adequacy arrangements. Processing Japanese personal data in ap-northeast-1 keeps the data within Japan, which simplifies many conversations with customers and regulators.

United States. There is no general federal data-residency requirement, but sector rules and customer contracts often impose one. US-only commitments are straightforward with us-east-1 and us-west-2.

Two practical points apply everywhere:

1. Residency is about every copy. Logs, backups, snapshots, evaluation datasets, and model artifacts all count. Our snapshots support cross-region copy, which is useful for disaster recovery and something you should consciously disable or scope when residency matters.
2. Models trained on personal data can carry obligations too. Decide where training runs and where resulting weights may travel before the run, not after.

Dataset gravity and egress

For training, the dataset is the anchor. A 50 TB pretraining corpus takes about 11 hours to move at a sustained 10 Gbps, and longer in practice once you account for many small files, retries, and validation. Moving it once is fine. Moving it every time you change regions is not.

Guidelines we give teams:

• Train where the data lives. Put the corpus in object storage in one region and launch training there. Ingress is free, so the first upload costs time but not transfer fees.
• Stage shards onto NVMe block volumes next to the GPUs for the hot path, rather than streaming from far-away buckets during training.
• Move artifacts, not datasets. A fine-tuned 70B checkpoint is a few hundred gigabytes; the data that produced it may be a hundred times larger. Copy the weights to the serving regions.
• Know your egress budget. Object storage egress is free up to 3× stored volume, and our pricing page lists the networking rates beyond that.

Capacity and SKU availability

Not every SKU has the same depth in every region at every moment. For on-demand work, the console shows what is launchable right now in each region. For large or long-running needs, such as a multi-node training run or a guaranteed inference fleet, reserve capacity in advance so the region decision is not made for you by whatever is free that day. Our on-demand vs reserved guide covers the trade-off, and sales can scope reserved capacity per region.

Two capacity patterns work well:

• Single-region training, multi-region serving. Train in the region with your data and reserved capacity; replicate the final weights to serving regions.
• Follow-the-sun batch. Batch and evaluation jobs that are indifferent to region can run wherever capacity is available, provided data residency allows it.

A decision checklist

For most teams, the answer is one training region and one to three inference regions. Because pricing is identical everywhere and the same images, APIs, and volume types are available in every region, adding a second serving region is mostly a deployment exercise rather than a re-architecture. See the platform overview for how networking and storage work across regions.

FAQ

Does Reviosa charge different prices in different regions?

No. Published rates are identical in all four regions, so you can choose a region based on latency, data residency, and data location without a price penalty.

Which region should I use for GDPR-sensitive workloads?

Teams processing EU personal data typically use EU Central in Frankfurt to simplify transfer obligations. This is general guidance, not legal advice, so confirm requirements with your counsel.

Does latency matter for LLM inference?

Less than many expect for streamed chat, where model time dominates. It matters a lot for real-time voice, agents making many sequential calls, and interactive tools.

Should I train and serve in the same region?

Not necessarily. Train where your dataset lives, then copy the much smaller model weights to the regions closest to your users.