Since the AWS European Sovereign Cloud (ESC) went live in January, almost every compliance conversation we have with customers ends with the same question: should we move? The honest answer is rarely yes or no. For most organisations it is “some of you, for some of your data, and only after you have counted what it costs”.
Below is our attempt at a complete answer, from what ESC is to how to choose between commercial, sovereign and hybrid. It ends with the most interesting thing AWS has announced about ESC so far: on Saturday 24 October, it will cut ESC off from the AWS global network on purpose.
What the European Sovereign Cloud actually is
ESC became generally available on 14 January 2026 with one Region, eusc-de-east-1 in Brandenburg, Germany, and more than 90 services. Today, AWS’s Capabilities by Region explorer lists 104 services as available there (with, for example, each RDS engine and FSx variant counted separately), and 886 services and features in total. Three things make it more than “another EU Region”.
It is a separate partition. Next to the commercial cloud (aws), AWS already runs separate partitions for China (aws-cn), GovCloud (aws-us-gov) and isolated US classified Regions. ESC adds aws-eusc, with its own IAM, its own AWS Organizations, its own billing in euro, its own console and its own endpoints under amazonaws.eu. ARNs start with arn:aws-eusc:. Existing accounts do not carry over; you open new ones.
It has its own control plane, in the EU. A dedicated Route 53 whose name servers use only European top-level domains, its own EU trust service provider and root certificate authority, and a dedicated European security operations centre. Customer content stays in the EU, and so does customer-created metadata such as roles, permissions, tags and configurations. In exceptional cases, EU-resident ESC staff have independent access to a replica of the source code needed to maintain the services.
It is run by a European company, with European people. ESC operates through German GmbH entities led by EU citizens, with an advisory board of EU citizens that includes two independent members. Day-to-day operations are carried out exclusively by EU residents located in the EU, and AWS is gradually moving to EU citizens only.
AWS plans to invest more than €7.8 billion in Germany through 2040, and backs the governance with a Sovereign Reference Framework (ESC-SRF) in AWS Artifact and a first set of attestations in March 2026: SOC 2 Type 1 and C5 Type 1 reports covering 69 services, plus seven ISO certifications. Type 1 means control design at a point in time, not operating effectiveness over a period; normal for a young cloud, but relevant if your auditor expects Type 2. Sovereign Local Zones in Brussels, Amsterdam and Lisbon were announced at launch and are still listed as announced, without a date. AWS has not announced a second ESC Region yet, but we expect more to follow. Read everything this post says about a single Region as a snapshot, not a permanent property.
What ESC does not change is who ultimately owns it: Amazon.com, Inc. The ESC Addendum commits AWS to redirect government requests to the customer, notify you, and challenge requests that conflict with EU law. It also says AWS will not move your content or customer-created metadata outside the EU “except as instructed by Customer or as necessary to comply with a valid and binding order of a governmental body”. AWS reports that no enterprise or government content stored outside the US has been disclosed to the US government since it started publishing that figure in 2020. Whether that is enough for you is a legal judgement, and one that has not been tested in court. We are not lawyers; put that question to yours.
How it differs from the other hyperscalers’ sovereign clouds
Every major provider now sells something called sovereign, and the word covers very different architectures. At hyperscale, there are two.
| Controls on the global cloud | Provider-operated separate cloud | |
|---|---|---|
| Examples | Microsoft Sovereign Public Cloud, Google Cloud Data Boundary, AWS commercial EU Regions | AWS ESC, Oracle EU Sovereign Cloud |
| Separate control plane | No | Yes |
| Operated by | The provider | The provider’s own EU entities |
| Main trade-off | Full breadth, but the platform stays globally integrated | Provider engineering behind a hard boundary, but a smaller catalogue and a non-EU parent |
Microsoft describes its Sovereign Public Cloud as “built on Microsoft’s global Azure infrastructure with enhanced sovereignty controls, such as Data Guardian, External Key Management, and tamper-evident access logs”. And in fairness, the separate-cloud model is not an AWS invention: Oracle has run its EU Sovereign Cloud as a separate realm since 2023.
Two kinds of offer are left out of this comparison on purpose. Disconnected and air-gapped clouds run a much smaller service set and solve a different problem. Partner clouds, such as Bleu and Delos Cloud on Microsoft technology or S3NS on Google technology, are a different category: a European company runs the hyperscaler’s software on its own, national-scale infrastructure. The catch is scale: capacity limited to what the partner has built, a core service set rather than the full catalogue, and features that arrive only after the licensor’s release cycle and the partner’s own checks. If your requirement is a European-owned operator, that is where to look. If it is hyperscale behind a sovereign boundary, they are not comparable to ESC.
What sets ESC apart is the combination: the same APIs, tooling and engineering organisation as commercial AWS, behind a partition boundary with its own identity, billing, DNS and PKI, run by EU entities. It is a partition, not a setting. That is its biggest strength and, as we will see, the source of most of its cost.
ESC versus Oracle EU Sovereign Cloud
Oracle’s EU Sovereign Cloud is the closest analogue, so it deserves a direct comparison. Both are separate clouds (a partition at AWS, a realm at Oracle) owned and run by EU legal entities, with support and operations restricted to EU residents. The differences are in how far the independence goes, and how much of it is documented.
Where AWS has an advantage. Operational autonomy and independence from global infrastructure are ESC’s strongest differentiators. AWS explicitly documents that ESC has no critical dependencies on infrastructure outside the EU, including the ability to keep operating if connectivity with the global AWS network is interrupted, and it is about to demonstrate that in public (more on that at the end). AWS also documents independent identity management, billing and metering, EU-based trust services and a dedicated security operations centre. Oracle states that its realm is “completely isolated both physically and logically from other Oracle realms”, but its public documentation does not describe separate identity, billing, trust services or a security operations centre at that level of detail. On governance, ESC’s advisory board includes two independent members who are not Amazon employees, a mechanism on top of the EU-incorporated operating subsidiaries. Oracle documents boards of directors made up of European nationals across its seven EU entities, but does not mention independent members.
Where Oracle has an edge. Two regions, Frankfurt and Madrid, against ESC’s one today, which matters if you need disaster recovery without leaving the sovereign cloud. We expect AWS to add ESC Regions over time, but until it does, that gap is real. A realm that Oracle says supports all its commercial services except some. And three years in the market.
The short version: if your requirement is demonstrable operational independence and governance, ESC documents and tests more. If you need disaster recovery without leaving the sovereign cloud today, Oracle is ahead.
What the analyst quadrants do, and do not, tell you
In Gartner’s 2026 Magic Quadrant for Strategic Cloud Platform Services (1 September 2026), AWS is a Leader for the 16th consecutive year and placed highest on Ability to Execute. Google, also a Leader, is placed furthest on Completeness of Vision.
But a Magic Quadrant positions vendors, not partitions. Nobody gets a separate dot for their sovereign offer. The quadrant tells you about the platform and the engineering organisation behind ESC, which counts for a cloud that is nine months old; it does not assess ESC itself. Nor does it tell you how ESC’s catalogue, ecosystem or sovereignty posture compares with Bleu, S3NS or Oracle. Gartner has no Magic Quadrant for sovereign cloud; its Market Guide for Cloud Infrastructure Sovereign Solutions (June 2026) describes that market without ranking it.
The closest thing to a sovereign ranking is ISG’s 2025 Provider Lens for Sovereign Cloud Infrastructure Services (EU). It evaluated 19 providers and named AWS a Leader for the third year in a row, with the highest score on portfolio attractiveness, crediting a “sovereign-by-design architecture that ensures data residency and regional independence”. Note the timing: the report appeared on 9 January 2026, days before ESC became generally available. It reflects AWS’s sovereignty portfolio and roadmap before ESC went live, not ESC as it runs today, which makes it as much an endorsement of the commercial Regions’ sovereignty controls as of ESC.
Not going to ESC? The commercial Regions are not the non-sovereign option
At the ESC launch, AWS itself said that “most customers are able to meet their requirements using one of the six existing AWS Regions in the EU”. There is evidence behind that.
On 22 September 2026, AWS announced that it is the first cloud provider whose services are approved for NATO RESTRICTED use by all NATO member nations. Spain’s National Cryptologic Centre (CCN) evaluated AWS against D32, NATO’s directive for handling NATO RESTRICTED information in public cloud, with AWS’s Trusted Secure Enclave Sensitive Edition as the baseline. Approved services can now be used at that level in any AWS Region located in a NATO member nation. Two caveats keep this honest. It is a pre-assessed baseline that gives Allies an accelerated path, not an accreditation of your system; that is still delegated to a member nation and/or the NATO Communications and Information Agency. And NATO RESTRICTED is NATO’s lowest classification level. One detail for Belgian readers: Frankfurt, Paris, Milan, Spain, Stockholm and London are in NATO member nations. Ireland, home of eu-west-1 and of many Belgian workloads, is not. Keep that in mind when designing your Region strategy.
The commercial Regions also carry the controls of the AWS Digital Sovereignty Pledge: the Nitro System, designed so that AWS operators cannot access customer content on EC2 instances, reviewed by NCC Group and written into the AWS Service Terms; AWS KMS External Key Store, which keeps key material in an external key manager you operate outside AWS (AWS recommends it only where that is an explicit requirement, because if it goes down, so does everything that depends on it); Control Tower data residency controls, including Region deny per organisational unit; and Dedicated Local Zones for single-customer infrastructure where you need it.
So the realistic question is not “sovereign or not sovereign”. It is which risks you need to mitigate, and whether a partition boundary mitigates one that these controls cannot.
Available is not the same as available
This is where most ESC plans go wrong. A service on the ESC list does not mean the service you use in Frankfurt is there, with the features you use.
AWS’s Capabilities by Region data, available in AWS Builder Center and through the AWS MCP servers, shows four states: Available, a directional launch quarter, Planning (“evaluating launch strategy”) and Not Expanding, which AWS defines as “will not launch in region”. For eusc-de-east-1, at the time of writing:
- Planned with a date: Amazon CloudFront (Q4 2026), Amazon Inspector and AWS Shield Advanced (Q1 2027).
- Planning, no date: AWS Application Migration Service. For a migration partner, that one stings: rehosting into ESC today means VM Import/Export, AWS Elastic Disaster Recovery or AWS DMS instead of MGN.
- Not Expanding: Amazon Detective, Amazon Security Lake, AWS CloudHSM, Amazon Textract, Amazon Q Developer and Amazon Elastic VMware Service, among others.
The subtler gap is inside services that are available. DynamoDB is there; Global Tables are Not Expanding. Route 53 is there; domain registration is at Planning. S3 is there; Multi-Region Access Points are at Planning. EC2 is there; Reserved Instances are not, so EC2 commitments go through Savings Plans. Some of this follows logically from a single-Region partition and should change once ESC gets more Regions. Until then, it is a gap for an architecture designed in Frankfurt.
Bedrock: the service is there, most of the models are not
Amazon Bedrock is available in ESC. Its model catalogue, at the time of writing, is Amazon Nova Pro, Amazon Nova Lite and three Gemma 4 variants served through the OpenAI-compatible bedrock-mantle endpoint. There are no Anthropic Claude models. Nova 2 Lite and open-weight models from Mistral AI and OpenAI were announced in May for “the coming months” and have not arrived. Guardrails is available; Knowledge Bases, Agents and AgentCore are at Planning.
The Gemma 4 launch in September is the most practical AI building block in ESC today, and AWS’s walkthrough is worth reading. Three things stand out:
- Open weights. Gemma 4 is released under Apache 2.0, so you can evaluate, benchmark and fine-tune the model yourself, without depending on a model provider’s roadmap. For a sovereignty discussion, that is an argument in its own right.
- How inference data is handled. AWS describes a zero operator access model, in which “no service operators can access model input or output during inference”, and zero data retention by default (with limited retention for abuse detection on some models). Every request stays in-Region in
eusc-de-east-1. - An OpenAI-compatible endpoint. Existing OpenAI SDK code moves over by changing the base URL and the key:
import os
from openai import OpenAI
client = OpenAI(
base_url="https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu/v1",
api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"], # short-term Bedrock API key, valid up to 12 hours
)
response = client.responses.create(
model="google.gemma-4-31b-it",
input="Summarise this incident report in three bullet points.",
store=False,
)
print(response.output_text)
The three variants cover the usual trade-offs: the 31B dense model for reasoning and coding (256K token context), the 26B-A4B mixture-of-experts model (3.8 billion active parameters per token) for cost-sensitive, high-throughput work, and the compact E2B for latency-sensitive or multimodal classification (128K context).
AWS has not said why, but part of the reason is structural. In Frankfurt, a model like Claude Sonnet 5.5 is not served in-Region at all: it runs through EU geographic cross-Region inference, which spreads requests over the EU Regions, or through global inference. ESC is one Region without cross-Region inference, so every model needs dedicated capacity in Brandenburg before it can appear. The catalogue will grow, but expect it to trail the commercial EU Regions at least until ESC has more than one Region. If your AI roadmap depends on frontier models, that alone may decide where those workloads live (see also When the model goes dark).
The practical rule: write your requirements at feature level, check them against Capabilities by Region and the per-service difference pages of the ESC User Guide, then test. The two sources do not always agree, which tells you how fast this is moving.
The ecosystem is not there yet
ESC has its own AWS Marketplace, with more than 165 solutions by May 2026, but it is a separate catalogue: only SaaS and AMI products are supported, and a SaaS listing must be deployable in ESC and keep its data there. Some vendors have shipped: AWS reports SAP Cloud ERP Private as generally available on ESC, and Sumo Logic launched its security operations platform there in June. Many others have announced intent and not shipped. At the time of writing:
- Snowflake, announced in 2025 as preparing for ESC, does not list an ESC Region on its supported-regions page.
- MongoDB said in 2025 it was preparing for ESC. The Atlas request for
eusc-de-east-1is at “Future Consideration”, with MongoDB saying in February that it is actively evaluating support. - Trend Micro has announced plans for Vision One on ESC, without a date.
- Datadog’s AWS integration API accepts the partitions
aws,aws-cnandaws-us-gov, notaws-eusc.
That is not a criticism of those vendors: building a SaaS control plane in a new partition is real work, and waiting for demand is a reasonable decision. But this gap matters more than most service gaps, for a reason that is easy to miss: your toolchain is inside your sovereignty boundary. ESC keeps your content and your metadata in the EU under EU operations. An observability, CSPM, backup or ITSM tool that reads your ESC accounts from a control plane outside the EU exports exactly what ESC was built to keep in. Before you design an ESC landing zone, list every tool that holds an IAM role in your accounts and check where each one runs.
Commercial, ESC or hybrid: how to decide
Start with the requirement, not the product. Three questions do most of the work.
- Who requires sovereignty, and what exactly do they require? “Customer content stays in the EU” is met by any EU Region. “Only EU-resident staff operate the systems”, “customer-created metadata stays in the EU” or “the service keeps running when cut off from non-EU infrastructure” are where ESC earns its place. “A European-owned operator” is met by neither ESC nor any other US-parented option.
- Does the workload fit inside today’s ESC? Services, features, models and every SaaS tool in the path.
- Which data actually needs it? Data classification, not the application map, should draw the line.
The answer usually lands in one of three shapes.
| Full commercial (EU Regions) | Full ESC | Hybrid | |
|---|---|---|---|
| Fits when | The requirement is residency, encryption and access control, and you need the full catalogue, frontier models and ecosystem | The requirement is EU-only operation and governance for the whole estate, and the workload fits today’s catalogue | A defined set of data needs ESC, and the rest benefits from commercial breadth |
| Typical examples | Most enterprise workloads, AI on frontier models, NATO RESTRICTED in NATO-country Regions | Public sector, critical infrastructure, defence supply chain, regulated greenfield platforms | A regulated core system or data store in ESC; analytics, AI and customer-facing apps in commercial |
| Watch out for | Sovereignty controls that are available but not enforced (Region deny, customer-managed keys, organisation-wide logging) | Missing services and tools, a single Region (for now) | The boundary leaking: sensitive data processed in commercial anyway |
| Relative cost | Baseline | Unit premium, plus migration into a new partition | Unit premium on the ESC part, plus duplication and integration, which can exceed the premium of full ESC |
AWS’s architecture guidance adds a fourth pattern: ESC as a sovereign failover target, with production in a commercial Region and backups, a pilot light or a warm standby in ESC. If your concern is geopolitical or legal disruption rather than day-to-day operation, backups or a tested pilot light are often the cheapest way to buy that exit option.
Whatever the shape, one rule decides whether hybrid works: the boundary has to follow the data. If the data you put in ESC gets copied into commercial for a dashboard, a model prompt or a support ticket, you have paid for the partition and kept the risk.
Hybrid means two clouds, and you pay for both
A hybrid estate is not one AWS environment with an extra Region. It is two environments that share an API style. AWS’s ESC landing zone guidance is explicit: a role in aws cannot assume a role in aws-eusc (or the reverse), and VPC peering, Transit Gateway, AWS RAM, S3 replication, ECR replication, AMI copy and VPC endpoints do not cross the boundary. In practice that means:
- Two organisations, two landing zones, each with its own management account, guardrails, logging and security services.
- Identity configured twice: a second IAM Identity Center instance federated to the same corporate identity provider, and CI/CD with one OIDC trust per partition, or a deployment plane inside ESC.
- Networking through the front door: TLS over the internet, Site-to-Site VPN or a separate Direct Connect connection. A commercial Direct Connect gateway cannot be extended into ESC.
- A separate supply chain: images and AMIs rebuilt or re-signed inside ESC rather than replicated, and certificates per partition.
- Infrastructure as code that knows about partitions. Anything that hardcodes
arn:aws:breaks. Cheap to fix early, expensive to fix late:
# CloudFormation: let the template resolve the partition
Resource: !Sub "arn:${AWS::Partition}:s3:::${BucketName}/*"
# Terraform: same idea
data "aws_partition" "current" {}
locals {
bucket_arn = "arn:${data.aws_partition.current.partition}:s3:::${var.bucket_name}"
}
Service endpoints move to amazonaws.eu, but IAM service principals such as lambda.amazonaws.com stay on amazonaws.com in both partitions.
Then there is the bill, where three costs stack up.
The unit price. ESC list prices are set in euro, at a figure slightly below the dollar price in Frankfurt. Lambda in ESC costs €0.0000164477 per GB-second against a commercial list price of $0.0000166667 in Frankfurt: about 1.3% lower as a number, but in a stronger currency. In dollar terms the premium is the exchange rate times 0.987, minus one: around 8.5% at 1.10 dollars per euro, around 18% at 1.20. A tecRacer comparison at launch, against Frankfurt, found roughly 15% across S3, FSx, EC2, Lambda, RDS and DynamoDB. Compared with Ireland, EC2 comes out higher, because Ireland is cheaper than Frankfurt to begin with. The flip side: commercial Regions can invoice in euro, but their prices are set in dollars and converted at the exchange rate of the invoice date. ESC list prices are set in euro, so the bill carries no currency risk, which some finance teams will value.
The commitment model. No EC2 Reserved Instances; EC2 commitments go through Savings Plans. Check the commitment options per service before you port an RI-based FinOps practice.
The duplication. A second landing zone, a second security tooling stack, a second identity configuration, a support plan in the second partition, data between partitions billed as data transfer out on the sending side, and the people who run it all. For a small ESC footprint, this fixed overhead easily exceeds the premium on the workload itself.
Which means hybrid is not automatically the cheaper option. When the workloads that could stay in commercial are small, or tightly coupled to the ones that must move, running two clouds and the integration between them can cost more than putting everything in ESC and paying the premium on the lot. Run both numbers before you decide to split.
ESC costs a little more per unit and a lot more per boundary. Put as little behind the boundary as your requirement allows, unless the boundary itself costs more than the premium you are trying to avoid.
Where Cloudar fits
This is the part where we talk about ourselves, so read it with that in mind. Cloudar is an ESC launch partner, holds the AWS Digital Sovereignty Competency, delivers Partner-Led Support in the AWS European Sovereign Cloud, and has built landing zones in the aws-eusc partition. That work has taught us that the hard part is rarely the ESC technology. It is keeping the moving parts consistent, so we have organised our work around the four questions customers actually ask:
| Service | The question it answers | What you get |
|---|---|---|
| Sovereignty Assessment | Do we need ESC at all? | Risk analysis, data classification and a placement decision (commercial, ESC or hybrid), mapped to your NIS2, DORA or tender requirements |
| ESC Readiness Assessment | Can our workloads move? | A gap analysis at service, feature and tooling level, including every SaaS tool that holds a role in your accounts |
| ESC Landing Zone | How do we build it securely? | Architecture, automation and governance for the aws-eusc partition, plus the identity and network links to your commercial estate |
| Sovereign Managed Services | Who runs it? | Monitoring, security, compliance and FinOps for the sovereign estate, backed by Partner-Led Support in ESC, and placements that move as the gap list shrinks |
Start with the Sovereignty Assessment. It is the step most organisations skip, and it decides whether the other three are needed at all. For many organisations the answer will be to stay in the commercial Regions with the right controls enforced. That is a valid outcome, and we will tell you so.
Saturday 24 October: AWS pulls the cable
Claims about operational independence are easy to write and hard to verify, so AWS is going to test one in public. On Saturday 24 October 2026, for several hours, ESC will run without its connection to the AWS Global Network backbone, the private network that normally carries authorised operational data between AWS locations. A dedicated system that handles limited, controlled transfers of operational data will be fully disabled, and traffic moves to ESC’s own internet connectivity from European ISPs. The exercise was called for by ESC’s managing directors and is run by a team made up entirely of EU residents.
What to expect. AWS says service availability inside ESC, other Regions and Direct Connect are not affected, but there may be brief connectivity disruptions at the start and end while routes converge on other networks. If you run cross-partition integrations over the internet or VPN, keep an eye on your monitoring that weekend.
What it proves. AWS designed the exercise to be consistent with the Commission’s Cloud Sovereignty Framework and BSI’s C3A, and will share an update with regulators and customers afterwards. That is the kind of evidence those frameworks ask for, and more than a policy document can offer.
Which brings us back to where we started. ESC is not the answer to every sovereignty question, and it is not just a label either. It is a partition: real operational separation, real gaps, real costs. The question is not whether ESC is sovereign enough. It is which of your data needs a partition, and whether you are prepared to run two clouds to give it one.
Service, feature and model availability in this post was checked against AWS Capabilities by Region, the ESC User Guide and the Amazon Bedrock model documentation on 16 October 2026. ESC is changing quickly; check before you plan.
Gartner, Magic Quadrant for Strategic Cloud Platform Services, 1 September 2026. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organisation and should not be construed as statements of fact. GARTNER and MAGIC QUADRANT are registered trademarks of Gartner, Inc. and/or its affiliates.
ISG Provider Lens, Multi Public Cloud Services, Sovereign Cloud Infrastructure Services (EU), 2025. ISG does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. ISG research publications consist of the opinions of ISG’s research organisation and should not be construed as statements of fact.
