Comparison / 12 capabilities
YTT Secunet vs DIY Multi-Region Cloud Routing
Many platform teams build residency routing themselves: model deployments in several regions, a small routing service, and a spreadsheet that says which tenant may use which deployment.
Matrix tally
- YTT Secunet edge8
- Parity1
- DIY multi-region cloud routing edge3
Rows where DIY multi-region cloud routing is stronger are marked as such. Filter the matrix below to read them first.
The cloud primitives underneath are good. Azure lets you choose Data Zone or regional deployment types and deny Global ones with Azure Policy. Amazon Bedrock offers geographic cross-Region inference profiles that keep processing inside a geography, and AWS service control policies can deny regions outright. What a DIY build rarely gets to is the second half of the problem: one policy layer across several clouds and self-hosted runtimes, failover that respects jurisdiction across providers, pseudonymization before the prompt leaves, and evidence an auditor can verify independently. That second half is where YTT Secunet spends its engineering.
| Capability | YTT Secunet | DIY multi-region cloud routing | Edge |
|---|---|---|---|
| Native residency controls in each cloud | Uses them rather than replacing them. Receipts record the provider region id and deployment that served each call. | Strong. Azure Data Zone and regional deployment types with Azure Policy to deny Global SKUs; Bedrock geographic inference profiles and AWS service control policies; regional endpoints on other clouds. | Parity |
| Consistency across clouds and runtimes | One policy pack applies to Azure, AWS, Google Cloud, Mistral, OVHcloud, Scaleway, STACKIT, Swisscom and self-hosted vLLM or Ollama. | Each cloud has different primitives, names and failure modes. The glue code that unifies them is yours to write and maintain. | YTT Secunet edge |
| Failover | Candidate endpoints are filtered by jurisdiction across providers, so an Azure incident in Frankfurt can fail to an EU-hosted Mistral endpoint or your own vLLM cluster, never to another continent. | Usually per provider. Cross-provider failover that respects jurisdiction is possible but rarely built, and retries in SDKs can quietly pick a default global endpoint. | YTT Secunet edge |
| Ownership of the code path | A managed component. On Sovereign Dedicated it runs in your VPC, but the code is YTT Secunet's. | Complete. Every line, every dependency and every release is under your control. | Alternative edge |
| Time to first compliant route | A base URL change and two headers, then policy tuning. | Weeks for a single cloud and region. Multi-cloud routing with failover and audit evidence is typically a multi-quarter project. | YTT Secunet edge |
| Added latency | Under 8 ms p99 per request (YTT Secunet production figure). | None beyond your own routing service if the application calls the regional endpoint directly. | Alternative edge |
| PII pseudonymization | In-path detection and reversible pseudonymization with the vault kept in the origin jurisdiction. Detectors for IBANs and national IDs such as Steuer-ID, NIR and NHS numbers ship with the product. | Buildable with open-source detectors such as Microsoft Presidio plus your own token vault, key management and restore logic in the response path. | YTT Secunet edge |
| Audit evidence | Per-response signed receipt with request hash, policy version, provider region, facility, upstream TLS thumbprint, model id and ZDR flag, rolled into an hourly Merkle root. | Cloud audit logs and your application logs. They show configuration and invocations, but turning them into evidence a regulator can check without trusting you is custom work. | YTT Secunet edge |
| Endpoint inventory | Sovereign Endpoints registry tracks which models run where, under which deployment type and with which certifications. | A spreadsheet or wiki page that someone has to update whenever a provider adds a model, a region or a data zone member. | YTT Secunet edge |
| Legal review of routing rules | Rego in version control plus a visual policy editor so privacy counsel can review and approve changes directly. | Code review by engineers. Legal usually signs off on a description of the change rather than the change itself. | YTT Secunet edge |
| Vendor and subprocessor footprint | Adds a processor to your records and DPA chain. Sovereign Dedicated keeps the data path inside your own infrastructure. | No new vendor beyond the clouds you already use. | Alternative edge |
| Compliance documentation | Generated exports for TIA evidence, records of processing and Annex IV technical documentation evidence. | Written and refreshed by hand each audit cycle. | YTT Secunet edge |
- You use one cloud, one model provider and one jurisdiction, and native controls such as an Azure Policy that denies Global deployments already give you what auditors ask for.
- Your platform team wants to own the whole data path and has budget to build and run an evidence pipeline alongside it.
- Your procurement or outsourcing rules make adding any new processor slower than building the capability internally.
- You do not need per-tenant routing because each deployment serves exactly one customer population.
- You run models on more than one cloud, or mix hosted providers with self-hosted vLLM, and want one policy across all of them.
- Your EU, UK and Swiss entities have different transfer rules and share one application.
- You want failover to another provider inside the same jurisdiction rather than to another region of the same provider.
- Your auditors or enterprise customers ask for proof of processing location that they can verify themselves.
Most teams run both for a while. These steps keep your current setup serving traffic until the receipts show the new route is doing what policy says.
- 01
Inventory every model deployment you already run, with region, deployment type and the tenants allowed to use it, and import that list into the Sovereign Endpoints registry.
- 02
Translate the routing spreadsheet into Rego. Start from the closest pre-built pack and add rules for tenant-specific exceptions.
- 03
Point one service at the YTT Secunet regional base URL and compare the resolved endpoints in receipts with your own logs for a week.
- 04
Move failover out of application code into YTT Secunet and delete the per-region client wrappers.
- 05
Keep your cloud-native guardrails, such as Azure Policy and service control policies, as defence in depth beneath the gateway.
- 06
Give internal audit the ytt-verify tool and a week of Merkle roots, then retire the custom evidence scripts.
Whatever sits in front of your providers today, the integration point for YTT Secunet is the inference client. The base URL moves to the regional entry point for the tenant's zone, and two headers name the tenant and the policy pack.
Request and response bodies keep the OpenAI or Anthropic schema, so streaming, tool calls and JSON mode work as before. The model name becomes a logical alias that the endpoint registry maps to an in-zone deployment.
- A denied request returns HTTP 451 with a decision id, never a silent reroute
- Every response carries a signed residency receipt header
- Receipts export to your SIEM alongside your current gateway logs
import OpenAI from "openai";
// Before: provider default endpoint, region decided by the provider.
// After: YTT Secunet regional entry point, zone decided by policy.
const client = new OpenAI({
baseURL: "https://eu.yttsecunet.com/v1",
apiKey: process.env.YTT_SECUNET_API_KEY,
defaultHeaders: {
"X-YTT-Policy": "eu-gdpr-strict@4.2.0",
"X-YTT-Tenant": tenant.id,
},
});
const res = await client.chat.completions
.create({ model: "gpt-4o", messages })
.withResponse();
const receipt = res.response.headers.get("x-ytt-proof-signature");We already deny Global deployments with Azure Policy. What does YTT Secunet add?
Azure Policy stops the wrong deployment from existing in Azure. YTT Secunet decides, per request, which of the right deployments a given tenant may use, extends that decision to providers outside Azure, keeps failover inside the jurisdiction and signs a record of the outcome. Keep the Azure Policy; it is a good backstop.
Do requests still run on our own cloud accounts?
Yes. YTT Secunet forwards to the deployments you register, using your provider credentials, so reserved capacity, committed spend and your existing provider terms still apply. YTT Secunet does not host foundation models itself.
What happens to our routing if YTT Secunet has an incident?
Enterprise Sovereign carries a 99.95% gateway SLA and Sovereign Dedicated a 99.99% SLA with in-jurisdiction failover. On Sovereign Dedicated the data plane runs in your own VPC or data centre, so its availability sits inside your own failure domains.
Sovereign route ready
Put both on the same traffic and compare the evidence.
Start a 14-day trial, route one tenant through YTT Secunet, and check every receipt with the open-source verifier.