AI in the AWS European Sovereign Cloud: What You Can Run and What You Cannot Build

When the AWS European Sovereign Cloud (ESC) comes up in a conversation about AI, the question asked is almost always whether the data stays in Europe. That one is already clear: keeping data inside a partition with a single Region in Brandenburg is what the partition is for. Sovereignty at the AI layer is a harder question than residency and it splits into three. Where is the data, who can see it while a model is working on it and whose model is it?

What the partition offers at the AI layer is easy to summarise. Four services are present: Amazon Bedrock, Amazon SageMaker AI, Amazon Polly and S3 Vectors. The rest of the AI portfolio, from Comprehend and Textract to Kendra, Amazon Q and Bedrock AgentCore, is not. Bedrock and SageMaker AI are the two that matter for anyone building; both behave like the services you already know, with the same APIs, SDKs and control planes; what has not come across is the inventory. Bedrock’s catalogue is five models, of which the three you can actually invoke are Google’s open-weight Gemma 4 family. SageMaker AI keeps everything that serves a model and does not yet offer most of what discovers, tunes and tracks one. There is no embeddings model anywhere, no way to reserve GPU capacity and a single GPU family, g6, underneath all of it.

Measured on the three questions asked earlier, the partition answers the first by existing. The second it answers twice. On Bedrock, considerably better than most buyers realise, because every model here runs on an engine AWS designed so that its own operators cannot reach your prompts. On SageMaker AI, where you host the model yourself, the answer is the one you already have for EC2: AWS’s standard isolation and nothing more. The third depends on which service you ask. On Bedrock the only models you can invoke are Google’s; on SageMaker AI the model is whatever you bring and can serve on the one GPU family available. The plumbing, in short, is the same and the catalogue is not. The ESC is a credible place to run and integrate models and is currently a poor place to build them.

This is the second of three posts on the AWS ESC with everything below verified against eusc-de-east-1. The first post covered what the partition is and how much sovereignty it gets you; the third covers serverless, containers and CI/CD.

What AWS said would come and what arrived

Of the four services present, Polly is the only one at parity; Comprehend, Textract, Transcribe, Translate, Rekognition, Kendra, Lex, Personalize, Bedrock AgentCore, Amazon Q and DataZone are absent from both the services list and the endpoint table, so there is no agentic Bedrock at all. What AWS has said about AI in the partition is short enough to quote in full. The launch services blog of July 2024 named three AI services, “Amazon SageMaker, Amazon Q, and Amazon Bedrock”; two of the three shipped. On 20 May 2026 AWS’s European newsroom stated that “in the coming months, customers will also gain access to new AI capabilities including Nova 2 Lite and open weight models on Amazon Bedrock and Mantle”, naming “open weight models from Mistral AI and OpenAI” specifically. None of those has arrived in the partition as I write. What has arrived, with no ESC announcement of any kind, is three Google models.

Bedrock and SageMaker AI are thin in opposite directions.

Bedrock: one engine, two endpoints and the models that work are on the second

Bedrock inference in the ESC, as everywhere in AWS now, runs on Mantle. AWS rebuilt the engine with security as its stated top priority (Exploring the zero operator access design of Mantle) and faster model onboarding, quality-of-service tiers and pooled capacity as its operational aims (What’s New, 4 December 2025). The engine surfaced December 2025 behind a new endpoint, bedrock-mantle, carrying the OpenAI-compatible APIs. By August 2026 AWS’s documentation states that the classic bedrock-runtime endpoint runs on the same engine, that the bedrock-mantle name “identifies an endpoint surface, not a different inference engine” and that new applications should use bedrock-runtime, keeping bedrock-mantle for capabilities “currently available only there” such as server-side tools, background inference and projects (endpoints page). My reading - AWS has not said this in as many words - is that the endpoint is the contract and the engine the infrastructure: AWS changed the infrastructure under the old contract and is converging the API surfaces on the old front door, keeping the newer door for what the old contract cannot yet express.

The two endpoints differ in more than API shape. bedrock-runtime serves the Bedrock-native InvokeModel and Converse APIs alongside the OpenAI-compatible and Anthropic APIs, carries Guardrails and cross-Region inference and admits requests the traditional way, through per-account quotas. bedrock-mantle serves only the OpenAI-compatible and Anthropic APIs and is, in AWS’s words, “architected with advanced scheduling and work-queueing mechanisms” over pooled capacity, with higher initial limits and, for most models, no per-account quota at all. Every model is bound to one surface or both; across the commercial catalogue the binding tracks age and provider: nothing launched before 2025 is on bedrock-mantle at all, most third-party chat models launched since are on both and every Amazon model is on bedrock-runtime alone whatever its date.

That binding decides everything in the ESC, because the partition’s catalogue sits on opposite sides of it. Nova Pro and Nova Lite are bound to bedrock-runtime, so they are admitted through per-account quotas; the three Google Gemma 4 models are bound to bedrock-mantle, so they are admitted by the scheduler. Neither surface currently serves the other’s models on any API. And the SDK’s model listing enumerates the bedrock-runtime catalogue only, so list-foundation-models returns the two Nova models and nothing else, while the console’s model catalogue shows the same two above a banner saying Gemma is “currently available only via API using the Bedrock-mantle endpoint”.

The recommended endpoint has nothing usable behind it

Enabling Nova works exactly as documented and neither model can be invoked. Every converse and invoke-model call has returned ThrottlingException: Too many tokens per day up to this point. In Service Quotas the six on-demand inference quotas covering the two models read zero and non-adjustable. I cannot prove the quotas are the cause but they are the only zeroes in a set of twenty quotas and AWS has not said why they are zero. Non-adjustable means self-service cannot raise them; requesting access or an explanation is therefore an AWS support request.

The other endpoint has the only models that answer

Model ID	Parameters	Context
google.gemma-4-e2b-it	5.1bn total, 2.3bn effective via Per-Layer Embeddings	128K
google.gemma-4-26b-a4b-it	25.2bn total, 3.8bn active per token, mixture of experts	256K
google.gemma-4-31b-it	30.7bn, dense	256K

All three work with no ceremony whatsoever. A SigV4-signed request to bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu lists them as available and returns completions on both OpenAI APIs. There is no model access step and no entry in Service Quotas; the scheduler rather than a quota decides whether you are served. They are open-weight models under the Apache 2.0 licence, which matters later.

So the only Bedrock models you can actually invoke in AWS’s European Sovereign Cloud are Google’s, on the bedrock-mantle endpoint.

The documentation will not settle any of this for you either. The Bedrock guide’s model tables, both Nova model cards and the ESC pricing page all present Nova as available in eusc-de-east-1 while the API throttles every call; the Gemma cards give a model ID without the -it suffix that the service requires and no pricing; the summary table of AWS’s own scaling and throughput guidance still tells general workloads to “Use the bedrock-mantle endpoint whenever possible”, a fortnight after the endpoints page switched its recommendation to bedrock-runtime.

Who can see what you send and what is kept

Zero operator access is the engine’s design and AWS now states it for Bedrock as a whole. In AWS’s words there is “no mechanism for any AWS operator to sign in to underlying compute systems or access any customer data, such as inference prompts or completions”; the ESC documentation says the same of the partition’s Bedrock. What it does not cover is what Bedrock keeps afterwards; that is governed by a separate setting: a data retention mode that you set once, on the account or on a project, with one API call. Four values matter. none is zero data retention, under which nothing is written to durable storage; default applies the model’s own policy, under which “AWS may retain the data for safety and abuse-prevention purposes”; aws_review additionally permits human review by AWS for the models whose providers require it; and inherit defers to the next scope up, which ends at the model’s own default.

In the ESC that chain ends at default for all three Gemma models, so a new account runs them under the model’s policy rather than under a guarantee of its own. The abuse detection page narrows what that means considerably: by default Bedrock does not store inputs or outputs, the models that are exceptions are named and none of them is in the partition; whatever is retained is “not shared with third-party model providers”. Google, in other words, receives nothing. Even so, none is available on all three models and becomes a guarantee only once you set it at the account or project scope; it also stops the Responses API storing conversations, which it otherwise does for 30 days. Set it. Then turn on the CloudTrail data events for Mantle and Bedrock’s invocation logging, because per default nothing about an inference call is visible to you afterwards either: none of our inference calls appeared in CloudTrail, by design.

Bedrock Guardrails, the configurable content, topic and PII filters, exist in the partition and work: we ran a test through it with the standalone ApplyGuardrail API. Guardrails are a bedrock-runtime feature, applied to Converse, InvokeModel and the OpenAI-compatible APIs on that endpoint. Since the only models that answer in the ESC are on bedrock-mantle, the pattern is a separate ApplyGuardrail call before and after the model: you send it the prompt or the response, marked as input or output; it returns either no action or an intervention, the per-policy assessment behind it and the text to serve, which for a PII rule is the redacted version and for a block is your configured message. That puts the safety layer in your code path.

SageMaker AI has everything for serving and little for building

SageMaker AI is present and reduced; the reduction has a clear shape once it is laid out. The differences page names fifteen available feature areas. Currently: training jobs, processing jobs, real-time inference, Studio and JupyterLab, Pipelines, the Model Registry, Model Cards, the Python SDK and the Deep Learning Containers. Missing: notebook instances, Feature Store, Autopilot, Ground Truth, hyperparameter tuning jobs, Inference Recommender, HyperPod and MLflow, confirmed by the API answering UnknownOperationException rather than by the documentation alone. The machinery that serves a model is there; the machinery that discovers, tunes and tracks one is not - yet, at least.

Three of the gaps change a design rather than merely inconveniencing an experiment. Real-time inference has no auto scaling, no Asynchronous Inference, no Serverless Inference and no inference components, so an endpoint here is a fixed-size deployment that does not respond to load. There is no JumpStart, so putting an open-weight model behind an endpoint is a build rather than a click.

The Studio object model is missing from CloudFormation. The partition’s CloudFormation registry does not provide Domain, UserProfile, Space and App. The domain and its user profiles end up as CLI or console work outside your infrastructure as code. The console’s own Create a new role flow for a Studio domain cannot complete in this partition: it currently fails on an internal IAM policy template that expects an account ID substitution that the partition does not supply, leaving a fresh role and several policies behind on each attempt. The execution role is therefore another thing to create yourself in CloudFormation and then point the wizard at.

One more thing a platform team meets on day one. SageMaker’s compute quotas start at zero for every training instance type and for all but two endpoint instance types, which is the same as commercial AWS and adjustable through Service Quotas self-service; out of the box you can serve on ml.m6g.large and ml.m6g.xlarge and nothing else.

Studio currently authenticates with IAM only and not with IAM Identity Center, in a partition that already has Identity Center; the console does offer the Identity Center option but the API rejects it. The pattern that works in a federated organisation is AuthMode=IAM and a presigned domain URL from the federated role, so nobody needs an IAM user to open a notebook.

The vector store arrived and the embedding model did not

S3 Vectors reached the partition in August 2026 with commercial limits intact. It works: we have run a bucket, an index, inserts and cosine queries end to end and had the right distances back. It has CloudFormation support too, which is more than the Studio domain manages.

There is no embeddings model anywhere in this partition, on either Bedrock endpoint. The managed half of a retrieval design is therefore solved and the half that turns your documents into vectors is yours to host, in a container you build, on the one GPU family available. Anyone planning retrieval-augmented generation (RAG) here should cost that in from the outset rather than discover it once the vector store has been chosen.

One GPU family and nothing to reserve it with

describe-instance-type-offerings returns 227 instance types across 26 families in eusc-de-east-1, of which exactly one family is accelerated: g6, NVIDIA L4. There is no P family and no Inferentia or Trainium. Two constraints from the EC2 differences page matter more than they look. Capacity Blocks for ML and Reserved Instances are both unavailable, so GPU capacity cannot be reserved ahead of a run.

The hardware is currently sized for inference and light training.

What this means: the three questions answered

Where the data is turns out to be the easy question - and the only one most sovereignty conversations ask. With one Region, no cross-Region inference profile and no shared backbone, residency is a property of the partition rather than a setting anyone has to get right. Who can see it has a strong answer on Bedrock, because zero operator access is a considerably stronger guarantee than residency and it holds for every model here.

The third question has a short answer. On SageMaker AI the model is whatever you bring. On Bedrock the only models you can invoke in Europe’s sovereign cloud are Google’s, open-weight and Apache 2.0, with no data flowing to Google and no European model in the catalogue. The awkward part is the count, three. It is odd all the same that Mistral AI, which AWS provides on commercial Bedrock and previously promised, is still missing.

On capability the conclusion is plain: the ESC is a credible place to run AI and a poor place to build it. The design that fits the partition today treats models as a dependency rather than an asset. Accept that you will own rather more of the platform than you would in the Frankfurt region: the embedding model, the safety layer, fixed-size endpoints and a Studio domain outside your IaC.

On the direction of travel I will offer judgement rather than prediction. Commercially AWS now has one engine under both Bedrock endpoints and has just told new applications to use bedrock-runtime; the ESC is the inverted case, where the recommended endpoint seems to have nothing usable on it and the specialist one has everything; that inversion reads to me as temporary. What AWS promised in May and what has landed since do not yet match, but the partition is visibly being backfilled over time: S3 Vectors and Redshift Serverless both arrived in August, the SageMaker feature list has increased and the Gemma models turned up without announcement. I would plan around these gaps today and I would not assume they are permanent.

The third post covers serverless and containers, where the primitives port across, the absence of CloudFront cascades further than you would expect and CI/CD is not included.

If you are evaluating the AWS European Sovereign Cloud for your organisation, Virtuability can help - or email team@virtuability.com.