Connect provider subscriptions across clouds and regions
Larger organisations rarely consume an AI provider through a single subscription. Existing vendor contracts are spread across cloud accounts, data-residency obligations pin certain workloads to certain geographies, and capacity headroom is often easier to secure by spreading the same model family across several regional deployments. Tetrate Agent Router models this fan as a set of independent provider entries, each subscription in each region configured as its own provider with its own endpoint and credentials, so that the same logical model can be mapped to several regional entries and routing has more than one place to send a request. The routing layer that consumes this structure is configured separately in Load balance across regional deployments; this guide stops at the point where the regional entries exist, are healthy, and are mapped to the logical models that routing will reference.
Persona: Platform operator working in the Admin Dashboard.
Estimated time: 30--45 minutes for a first pass across two or three clouds, depending on how many subscriptions and regions are involved and whether private connectivity is in scope.
When this guide applies
This guide is the right starting point when more than one subscription to the same provider, or to equivalent models across clouds, has to be represented in the platform:
| Situation | Why a separate provider entry is warranted |
|---|---|
| Existing contracts with more than one cloud vendor | Each contract carries its own account, endpoint, and credentials, and has to be represented independently |
| A model offered in several regions of the same cloud | Each regional endpoint is a distinct connection with its own latency and capacity profile |
| Data-residency obligations | A workload bound to a geography must reach a provider endpoint in that geography, not a default global one |
| Latency-sensitive traffic | Routing to the nearest regional endpoint reduces round-trip time; the nearer endpoints must exist as entries first |
| Capacity headroom and quota limits | Spreading load across several regional subscriptions raises the aggregate quota available to a single logical model |
If the goal is a single subscription to a single provider, the broader Provision models and providers guide is the simpler starting point. This guide assumes the multi-subscription case.
Outcomes
By the end of this guide:
- One provider entry exists per subscription and region, each with its own endpoint and credentials, and each reporting a healthy connection status.
- A naming convention is in place that keeps regional entries distinguishable at a glance.
- At least one logical model is mapped to several regional provider entries, so the routing layer has more than one backend to choose among.
- Where compliance requires it, regional entries dial a private endpoint rather than a public one, keeping provider traffic on the cloud backbone.
- Each connection has been verified, so routing can be configured against entries known to be reachable.
Prerequisites
- Administrator access to the Admin Dashboard, typically the
super_adminorprovider_adminrole. The role model is covered in Configure Single Sign-On. - Valid credentials for each subscription to be connected. A separate set of credentials is expected per cloud account and, in most cases, per region.
- The endpoint URL for each regional subscription. For cloud-hosted providers this is usually region-specific (the region appears in the host name) and differs from one regional entry to the next.
- For private connectivity, the network-level configuration (the private endpoint, route, or service connection) already in place in each cloud environment. The Admin Dashboard configures only the URL the gateway dials; it does not provision the underlying network. The architecture is described in Architecture Overview.
- A decision, taken before configuration begins, about which model families are to be mapped across which regions. The platform does not infer this; it is an explicit operator choice.
Step 1: decide which subscriptions warrant a separate entry
Before anything is configured, the set of provider entries to be created should be enumerated. The platform treats each provider entry as a single endpoint reached with a single set of credentials, so the rule is straightforward: wherever the endpoint or the credentials differ, a separate entry is required.
This typically produces one entry for each of the following:
- Each cloud vendor under contract: a subscription on one cloud and an equivalent subscription on another are always separate entries, because the credentials and endpoints have nothing in common.
- Each region of a cloud-hosted provider: a model served from one region and the same model served from another reach different endpoints, even when the underlying account is shared.
- Each account where contracts are split for billing or governance reasons, even within one cloud and region.
The output of this step is a short inventory: provider, cloud, region, account, and the reason the entry exists (contract, residency, latency, or capacity). That inventory drives the entries created in Step 3 and the model mapping in Step 4.
Step 2: settle on a naming convention
Because several entries will refer to the same underlying provider, the entry names are the only thing that keeps them distinguishable in the provider list, in routing configuration, and in usage analytics. A convention agreed before the entries are created avoids a later rename pass.
A workable convention encodes provider, cloud, and region in the identifier, with the region last so that related entries sort together. For example:
anthropic-aws-us-east-1
anthropic-aws-eu-west-1
anthropic-gcp-europe-west4
openai-azure-westus
openai-azure-swedencentral
The constraints are the same as for any provider identifier (lower case, beginning with a letter), and the display name carries a human-readable form alongside it, for example Anthropic (AWS, us-east-1). The value of the convention is operational rather than cosmetic: when a connection goes unhealthy or a region is drained for maintenance, the entry to act on is identifiable without cross-referencing.
Step 3: configure one provider entry per subscription and region
Each entry from the Step 1 inventory is configured as an independent provider. The mechanics of adding a provider (the fields, the credential entry, and the save-and-verify cycle) are the same as for a single provider and are covered in detail in Provision models and providers; for provider-specific endpoint and authentication detail, see Provision AWS Bedrock models. The points specific to the multi-region case are these:
- Add a provider entry for each row in the inventory, naming it according to the convention from Step 2.
- Set the endpoint URL to the region-specific endpoint for that subscription. The region usually appears in the host name, and two entries for the same provider in different regions differ only in this value.
- Enter the credentials belonging to that subscription. Credentials are not shared across regional entries even when the same vendor issued them; each entry carries its own.
- Set the region field, where the provider type exposes one, to match the region in the endpoint. A mismatch between the stated region and the endpoint is a common cause of a connection that authenticates but routes to the wrong geography.
- Save the entry and let the platform verify it before moving to the next. Verifying one entry at a time makes a failure easy to attribute to the subscription that caused it.
Where credentials are supplied by the developer rather than held by the platform, under the Bring Your Own Key (BYOK) pattern, the per-region structure still applies, but the credential handling differs; see Use your own provider credentials.
Step 4: map one logical model to several regional entries
A logical model is the name developers route to, a model family such as a given Claude or GPT model, independent of which regional subscription ultimately serves the request. Mapping that logical model across several regional entries is what gives the routing layer a choice of backends.
- Identify the logical model to be served from more than one region, drawn from the inventory in Step 1.
- For each regional provider entry that offers an equivalent model, enable that model so it is exposed through the entry. Model enablement is described in Provision models and providers.
- Confirm that the same logical model name is now associated with each of the intended regional entries. The set of regional entries backing one logical model is the pool the routing layer will distribute across.
- Repeat for each logical model that is to span regions.
The mapping defined here is the structure; it does not by itself decide how requests are spread across the regional entries. Weighting, ordering, and failover among them are configured in Load balance across regional deployments. Equivalence across clouds is an operator judgement: a model offered by one vendor and a comparable model from another are treated as one logical model only if the organisation has decided they are interchangeable for the traffic in question.
For models that are self-hosted rather than vendor-served, the same mapping approach applies once the self-hosted endpoint is configured; see Provision custom and self-hosted models.
Step 5: keep compliance-bound traffic on private connectivity
Where a subscription serves traffic subject to data-residency or network-isolation requirements, the regional entry should dial a private endpoint rather than a public one, so that provider traffic stays on the cloud backbone and never crosses the public internet.
- Confirm the private connection for that region is already provisioned at the cloud level: AWS PrivateLink, Azure Private Link, or GCP Private Service Connect, depending on the cloud.
- In the corresponding provider entry, set the endpoint URL to the private-link address rather than the public host name.
- Save and re-verify the entry. A private endpoint that resolves only inside the cloud network will fail verification if the data plane cannot reach it, which surfaces a misconfigured route or DNS record before any traffic depends on it.
The Admin Dashboard configures only the URL the gateway dials. The private endpoint itself (DNS, routing, and network policy) is configured beforehand in the cloud environment, and the value entered here references the result of that work. The architectural detail is in Architecture Overview. Private and public entries can coexist: a region under a residency obligation can use a private endpoint while another region, not so bound, uses a public one.
Step 6: verify each connection's health
A regional entry is only useful to routing once it is reachable. Before the routing layer is pointed at the pool of entries built in Step 4, each entry should be confirmed healthy.
- Open the provider list and review the status of every entry created in this guide. Each should report an active, healthy connection and a recent successful verification timestamp.
- For any entry reporting an unhealthy connection, open it and re-check the endpoint URL, the region, and the credentials in turn. A regional endpoint pasted from the wrong region, or credentials from the wrong account, are the usual causes when one entry among several fails while its siblings succeed.
- For private-endpoint entries, treat a verification failure as a network-reachability question first, whether the data plane can resolve and reach the private address, before suspecting the credentials.
- Once every entry in the pool is healthy, the logical models mapped in Step 4 are ready for the routing layer to distribute across.
Connection health is re-checked periodically and on each configuration change, so an entry that is healthy now but loses its endpoint or has its credentials expire will surface as unhealthy in the provider list without manual prompting.
What to do next
- Load balance across regional deployments: with the regional entries healthy and the logical models mapped, the next step is configuring how requests are distributed and how failover behaves across the pool. See Load balance across regional deployments.
- Use your own provider credentials: where developers supply their own subscription credentials rather than relying on platform-held ones, the BYOK flow complements the per-region structure built here. See Use your own provider credentials.
- Provision custom and self-hosted models: to extend the regional pools with models served from self-hosted endpoints rather than vendor subscriptions. See Provision custom and self-hosted models.
The regional provider entries and logical-model mappings created here remain in place as the structure the routing layer is built on.
Where to go next