You cannot move a watsonx.ai instance to another region. The region you select when you provision is fixed for the life of that instance, and most teams choose it the way they choose a default: they take whatever the console offered. Then a month in, the model they actually want will not load, because it is not hosted where they landed. The region is the first architecture decision on watsonx.ai, it is made in about four seconds, and it is the one you cannot take back without rebuilding.

This part is the deployment topology under the choices you already made. Part 4 picked SaaS or software, Part 5 read the bill, and Part 6 sized the GPUs. Here we place the thing on a map, then decide how the network reaches it and who holds the keys. Three questions: which region, which endpoint, whose encryption.

Why the region is a one-way decision

A region on IBM Cloud is a physical place, a set of data centers wired together as one multi zone region, and a watsonx.ai instance lives in exactly one of them. That single fact drives more than latency. The region sets which foundation models you can call, whether you can tune a model at all, which compliance certifications cover the service, and where your data sits for residency rules. None of those are toggles you flip later. They are properties of the region, so choosing the region chooses all of them at once.

The reason it is a one way door is operational, not contractual. There is no button to relocate a running instance, so a move means standing up a fresh instance in the new region, re creating your projects, prompts, deployments, and connections, and cutting traffic over. That is a migration, not a setting. So the cost of guessing here is not a slower response, it is a rebuild. Spend the four seconds up front instead, because the sections below turn each of those region bound properties into something you can check before you click.

Where watsonx.ai actually runs

watsonx as a Service runs in six IBM Cloud regional data centers, and separately on AWS in two. On IBM Cloud the regions are Dallas, Frankfurt, London, Tokyo, Sydney, and Toronto. The three core services, watsonx.ai Studio for building, watsonx.ai Runtime for serving and tuning, and watsonx.governance for oversight, are available from all six. That word available hides the trap: the service being present in a region does not mean every model and feature inside it is. IBM also offers watsonx.ai on AWS in Mumbai and Northern Virginia as a native SaaS service, which matters if your organization standardizes on AWS accounts and billing.

Start from the table below as your map, then read the next section before you commit to a pin on it. The region code in the second column is the string you will see in the console and in API endpoints, so it is worth knowing that Dallas is us-south and Frankfurt is eu-de rather than guessing from the city name.

Regions and per region capabilities change. This is a snapshot from the IBM regional availability of services and features page; confirm the current list before you provision.

Pick the region by the model, not the map

The instinct is to pick the region nearest your users. That is the wrong first filter. Latency to a foundation model is dominated by how long the model takes to generate tokens, not by the few tens of milliseconds of network distance, so shaving geography while missing the model you need is a bad trade. The first filter is the model. Find the region or regions that host every model your application calls, and only then, among those, pick the closest one. If exactly one region hosts your model set, geography was never a choice, and it is better to learn that now than after you build.

The spread is not small. Counting the IBM provided models that are ready to inference without you deploying anything, Dallas carries far more than the rest, and the tail regions carry a third of what Dallas does. The chart makes the gap concrete. A team that assumed all six regions were interchangeable and picked Toronto for proximity would find seven models where Dallas offers seventeen.

Models are only the first gate. Whether you can tune, host a custom model, or use Prompt Lab is also region bound, and tuning is the tightest constraint of all. The Tuning Studio for LoRA fine tuning runs in Dallas and Frankfurt only, so if tuning your own weights is on the roadmap you are choosing between two regions before you consider anything else. Custom and deploy on demand models sit in Dallas, Frankfurt, Sydney, and Toronto but not London or Tokyo. The second chart lines these up so you can see which capability narrows your options fastest.

Public, private, and mixed service endpoints

Once the instance has a home, the next decision is how traffic reaches it. A service endpoint is the network address your applications call to use watsonx.ai Runtime, and IBM Cloud gives you three shapes. Public is the default: the service is reachable over the internet, secured by IAM and TLS but with a route from anywhere. Private, sometimes called a cloud service endpoint, puts the service on the IBM Cloud private network so it is reachable only from inside IBM Cloud, with no path from the public internet at all. Mixed enables both at once, which is the pragmatic middle for a team migrating from public to private without a hard cutover.

The knob is the Endpoints field on the IBM Cloud catalog page when you provision, and it is worth understanding what private actually buys. Public with IAM is not insecure, a caller still needs a valid API key and hits TLS, so the difference is not encryption, it is reachability. Private removes the internet as an attack surface entirely, which is the control auditors ask about and the one that lets you say, truthfully, that the service cannot be called from outside your cloud. If you have no requirement forcing it, public with tight IAM is fine. If you do, private is the setting, and the table lays out when each fits.

After you set watsonx.ai Runtime to private only, the service is not accessible from the public internet. Confirm the exact endpoint options for your account on the IBM service endpoints documentation.

Virtual private endpoints and the VPC path

Private endpoints solve reachability, but they still leave your application talking to an IBM Cloud address on the private network. A virtual private endpoint, a VPE, goes one step further and gives the service a private IP address inside your own Virtual Private Cloud. To your application, watsonx.ai Runtime then looks like a resource that lives in your VPC subnet, reached over the IBM Cloud backbone and never the internet. You create a VPE gateway in the VPC, bind it to the watsonx.ai Runtime service, and your workloads call that local IP. This is the pattern enterprises reach for when a security team wants every dependency to resolve to an address they own and can put a security group in front of.

The difference between a plain private endpoint and a VPE is worth being precise about, because teams conflate them. A private endpoint keeps traffic off the internet. A VPE does that and also brings the service address into your VPC IP space, so your existing network controls, security groups, subnets, and routing apply to it as if it were one of your own machines. The flow below traces both the private path and what happens to a public request once you have gone private only.

flowchart LR
  U[Client app in your VPC] --> VPE[VPE gateway, private IP]
  VPE --> BB[IBM Cloud private backbone]
  BB --> WX[watsonx.ai Runtime endpoint]
  NET[Public internet] -. no route when private only .-> WX

How data stays encrypted and who holds the keys

Reachability handled, the last topology question is the data. On watsonx.ai your data at rest is encrypted by default, with keys IBM manages, and for many teams that is enough. The reason to go further is control, not stronger math. Bring Your Own Key, BYOK, lets you supply and rotate the root key through IBM Key Protect, so IBM still operates the service but you hold the key that unlocks the data and can revoke it. Keep Your Own Key, KYOK, goes further again using Hyper Protect Crypto Services, where the key lives in a dedicated hardware security module that even IBM operators cannot access. The trade is operational weight: the more control you take, the more key lifecycle you own, and a lost or wrongly revoked root key locks you out of your own data.

Match the tier to the requirement rather than to nerves. Default IBM managed encryption suits most pilots and plenty of production. BYOK through Key Protect is the common enterprise answer when a policy says the customer must be able to revoke access, and it is the setting I reach for by default on regulated work. KYOK with a dedicated module is for the highest assurance cases, financial and government workloads where separation from the operator has to be provable. Decide this alongside the region, because the object storage and services your data touches are provisioned per region too, and residency plus key control together are what a data protection review actually asks about.

Lock the network before you lock the data

There is one more control that sits above the endpoint setting: context based restrictions, CBR. A network zone in CBR is a named set of allowed sources, IP ranges, VPCs, or service references, and a rule ties a service to a zone so that requests from anywhere outside it are denied even with a valid API key. This is the difference between a service that anyone with a leaked key can call and one that only answers from your VPC. Private endpoints control the route, IAM controls who, and CBR controls from where. Layer all three and a stolen key alone gets an attacker nothing, because the request never arrives from an allowed zone.

Before you decide any of this, it helps to check your candidate region against the models you actually need in code rather than by squinting at a table. The script below encodes a slice of the regional model map and prints which IBM Cloud regions can serve your whole list, and which survive if you also need tuning. Change the two inputs to your own case and run it. It is a planning filter, and I flag its limits under the output.

# watsonx.ai region picker: which IBM Cloud region hosts every model you need.
# Data from the IBM regional availability of services and features page. Reconfirm before you commit.
IBM_REGIONS = ['us-south', 'eu-de', 'eu-gb', 'jp-tok', 'au-syd', 'ca-tor']

# Provided, ready to use inferencing: model maps to the regions that host it.
HOSTS = {
    'granite-3-8b-instruct': {'us-south', 'eu-de', 'eu-gb', 'jp-tok', 'au-syd', 'ca-tor'},
    'llama-3-3-70b-instruct': {'us-south', 'eu-de', 'eu-gb', 'jp-tok', 'ca-tor'},
    'mistral-large-2512': {'us-south'},
    'llama-3-405b-instruct': {'us-south'},
}
TUNING = {'us-south', 'eu-de'}   # LoRA tuning, Dallas and Frankfurt only

def regions_for(models, need_tuning=False):
    covered = set(IBM_REGIONS)
    for m in models:
        covered &= HOSTS.get(m, set())
    if need_tuning:
        covered &= TUNING
    return sorted(covered)

want = ['granite-3-8b-instruct', 'llama-3-405b-instruct']
print('Models:', want)
print('Regions hosting all of them:', regions_for(want))
print('If you also need LoRA tuning:', regions_for(want, need_tuning=True))

Expected output: Models: ['granite-3-8b-instruct', 'llama-3-405b-instruct'], Regions hosting all of them: ['us-south'], If you also need LoRA tuning: ['us-south']. The 405b model is Dallas only, so it alone forces the region. Failure modes: this encodes a slice of the map, not the full catalog, so add your real models before trusting it; deploy on demand availability differs from the provided list used here; the two AWS regions are left out on purpose; and a region that hosts a model today may drop it in a later release, so treat the print as a shortlist to confirm, not a guarantee.

Other clouds structure the same choice differently. If you are comparing, the way AWS handles regional model access and cross region inference in Amazon Bedrock regions, quotas, and cross-region inference is a useful contrast to watsonx.ai, where a model simply is or is not in your region with no cross region fallback.

Where I would put the first watsonx instance

My recommendation is concrete. Unless a data residency rule sends you elsewhere, start in Dallas or Frankfurt, because between them they hold nearly every model, both tuning slots, and the broadest compliance coverage, so they leave the most doors open. Pick Frankfurt if EU residency is in play, Dallas otherwise. Reach for London, Tokyo, Sydney, or Toronto only when a residency or latency requirement is real and you have confirmed your exact models live there. Proximity is the tie breaker, never the first filter.

On the network, default to public with strict IAM for a pilot, and move to a private endpoint or a VPE the moment the workload is real and touches anything sensitive. Add context based restrictions so a leaked key cannot be used from outside your zone, and take BYOK through Key Protect on any regulated data so you can revoke access on your own terms. Region first, then endpoint, then keys, decided in that order and written down before you provision, because every one of them is a rebuild to undo.

Do one thing before Part 8. List the exact model IDs your first application will call, run them through the region picker above, and note which regions survive. That shortlist is your region decision, made on evidence. With the instance placed and the network locked, Part 8 gets into inferencing and prompt engineering, the API, prompt templates, Prompt Lab, and streaming, which is where you finally send a request to the endpoint you just secured.

References

IBM docs: Regional availability of services and features
IBM docs: Managing the watsonx.ai Runtime service endpoint
IBM Cloud docs: About virtual private endpoint gateways
IBM docs: watsonx data security
IBM Cloud docs: About Key Protect

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts