Integration / Model provider
Amazon Bedrock, routed by jurisdiction.
Route to Amazon Bedrock in-Region endpoints and EU geography inference profiles with your own AWS credentials, while YTT Secunet blocks global profiles and records the exact Region in a signed receipt.
Amazon Bedrock gives you three residency shapes. An in-Region on-demand call in eu-central-1 processes in Frankfurt. A geography-scoped cross-Region inference profile, identified by an eu. prefix on the model id, may route the request to any AWS Region in that profile, all inside the EU; AWS documents that it does not add Regions to an existing geography profile and publishes a new profile id instead. A global profile can route to commercial Regions worldwide. AWS also documents that Bedrock does not store or log prompts and completions by default, that model invocation logging is an opt-in feature you control, and that model providers do not have access to customer prompts.
YTT Secunet treats each shape as a separate endpoint class. For an EU tenant the eu-gdpr-strict pack allows Frankfurt, Ireland, Paris and Stockholm in-Region endpoints plus the EU geography profile, and denies anything with a global prefix. A customer whose regulator expects processing in Germany only can narrow the rule to eu-central-1 and pay the availability cost of a single Region. Because some newer models are offered in certain EU Regions only through a geography profile, the registry tells you before activation whether the model you picked can meet a single-Region rule.
Calls go out with your IAM role through SigV4, so billing, quotas and CloudTrail records stay in your AWS account. YTT Secunet stores no prompts; the receipt records the Region, the inference profile id where one was used, the model id and a hash of the request. If you enable Bedrock invocation logging to S3, keep the bucket in the same jurisdiction, because that log is an at-rest copy that YTT Secunet's zero-retention design does not cover.
| Region or deployment | Location | Jurisdiction |
|---|---|---|
| eu-central-1 (Frankfurt) | Frankfurt am Main, Germany | EU / European Union |
| eu-west-1 (Ireland) | Dublin, Ireland | EU / European Union |
| eu-west-3 (Paris) | Paris, France | EU / European Union |
| eu-north-1 (Stockholm) | Stockholm, Sweden | EU / European Union |
| eu-central-2 (Zurich) | Zurich, Switzerland | CH / Switzerland |
| eu-west-2 (London) | London, United Kingdom | UK / United Kingdom |
- 01
Enable access to the models you need in each target Region from the Bedrock console, and note which are offered in-Region and which only through the EU geography profile.
- 02
Create an IAM role YTT Secunet can assume, scoped to bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the specific model and inference profile ARNs.
- 03
Add an AWS service control policy that denies Bedrock calls outside your approved Regions, so the restriction holds even outside YTT Secunet.
- 04
Register the endpoints in YTT Secunet with Region, model id and, where used, the eu. inference profile id; attach them to the matching policy packs.
- 05
Point your OpenAI- or Anthropic-compatible SDK at the YTT Secunet regional base URL; YTT Secunet converts to the Bedrock Converse API.
providers:
aws-bedrock:
assume_role: arn:aws:iam::123456789012:role/yttsecunet-invoke
external_id: jr-tenant-7f3a
endpoints:
- id: bedrock-fra-claude
region: eu-central-1
model: anthropic.claude-sonnet-4-6
mode: in-region
- id: bedrock-eu-profile-claude
region: eu-central-1
inference_profile: eu.anthropic.claude-sonnet-4-6
mode: geography-profile
routes:
- policy: eu-gdpr-strict
primary: bedrock-fra-claude
failover: [bedrock-eu-profile-claude]
deny_profile_prefixes: [global., us., apac.]- Global cross-Region inference profiles are denied by every residency pack because they can process outside the tenant's jurisdiction.
- An EU geography profile satisfies eu-gdpr-strict but not a Germany-only rule; YTT Secunet reports which Regions a profile contains so you can decide.
- Zurich (eu-central-2) is classed as CH. AWS lists Zurich among the possible destinations of EU geography profiles and other EU Regions as destinations for calls from Zurich, so a Swiss-only rule must use in-Region Zurich endpoints and refuse the eu. profile.
- If Bedrock invocation logging is on, the policy checks that the log destination bucket is in the same jurisdiction before the route activates.
Why would I put YTT Secunet in front of Bedrock instead of using IAM alone?
IAM and SCPs can restrict Regions per account, which you should do. They do not decide per request which tenant may use which Region, mask PII before the call, or give you a signed, third-party verifiable receipt per inference. YTT Secunet adds those on top of your AWS controls.
Do my prompts pass through YTT Secunet's AWS account?
They pass through a YTT Secunet data plane in memory and are sent to Bedrock under your IAM role. Usage, billing and CloudTrail events are in your account. With Sovereign Dedicated, the data plane runs in your own VPC.
Which Region is used when a profile is selected?
Bedrock picks a destination Region within the profile. YTT Secunet records the profile id and, where Bedrock returns it, the Region that served the call, so your evidence shows the geography boundary that applied.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.