Can You Leave? Data Portability & Egress

Part 1 deliberately kept Question 4 — can you leave — at the general level. This post is the deep-dive: concrete data-export formats, API and query-language openness, and egress pricing already documented for AWS, GCP, Azure, and OVH, plus new findings on how the five sovereignty offerings from Part 2 actually hold up on exit.

Data export format🔗

The log-archiving pre-flight and auditor-export post already has working bulk-export commands per provider: AWS via an Athena query into S3, GCP via a BigQuery extract into GCS as newline-delimited JSON, Azure via a blob-batch download, and OVH’s self-hosted ClickHouse path via a direct Parquet export. All four produce a file a customer can carry elsewhere. The same post pairs every export with a SHA-256 checksum manifest — proof the download wasn’t corrupted in transit, which matters as much for an exit as it does for an auditor handover.

API and query-language openness🔗

The log-archiving UX comparison covers query interfaces across the same four: Athena, BigQuery, and self-hosted ClickHouse are all SQL variants — each with its own extensions, but built on a language every other SQL engine also understands. Azure’s Log Analytics runs on KQL (Kusto Query Language), which is not SQL and not portable to another provider’s tooling without a rewrite. That’s a sharper, more specific lock-in point than data format alone: even with the data exported cleanly, the queries built around it don’t travel with it.

Egress pricing🔗

Real money attaches to leaving, not just friction. From the cost comparison’s FAQ: AWS charges ≈$0.085/GB egress from EU regions, GCP $0.085/GiB from europe-west3, Azure ≈$0.08/GB from West Europe. OVH charges no egress fee for traffic within the OVH network — egress to external networks is billed normally, but that’s a real, quantifiable asymmetry for a multi-year archive that might need to move.

Applying this to Part 2’s cases🔗

A new check confirms one consistent pattern across four of the five offerings from Part 2: the sovereignty marketing sits on top of the parent hyperscaler’s standard platform, not on a separate technical stack with its own APIs.

AWS European Sovereign Cloud uses the same AWS Console, SDKs, CLI, Terraform, OpenTofu, and CDK as standard AWS — no proprietary sovereign-specific API layer, confirmed directly against AWS’s own whitepaper and launch documentation. The catch is administrative, not technical: ESC runs as a fully separate AWS partition with its own root accounts and IAM, and there is no cross-partition role assumption, VPC peering, or ECR image sharing with standard AWS — real friction at the account boundary, even though the API itself is unchanged. Neither AWS’s documentation nor its pricing page names a specific bulk-export tool or discloses a per-GB egress rate for ESC; independent secondary sources report pricing running roughly 15% above standard EU regions, which this post could not confirm against a primary AWS source, so treat that figure as reported, not verified here.

Microsoft Sovereign Cloud (Sovereign Public/Private Cloud) is built on the same global Azure infrastructure using the identical Azure and Microsoft 365 APIs as the standard public cloud — sovereignty is implemented as a policy and tooling layer (Data Guardian, customer-managed keys, Sovereign Landing Zone templates), not a separate platform. No data-export mechanism, format, or egress-pricing specifics for this offering were found in Microsoft’s own documentation — an open gap, not a confirmed fact either way.

Bleu is the weakest-evidenced of the five on this specific question. Bleu and its parent companies describe “quasi-parity” with standard Azure and Microsoft 365 services, but a claim that this extends to full API/management parity did not survive verification — there is not enough public evidence to say Bleu’s API surface is open the same way AWS’s or Microsoft’s is. No export-format or egress-pricing information for Bleu was found at all. This post says so plainly rather than assuming an answer either way.

Google Cloud’s sovereignty offerings need to be split into two, because they are not one product. “France Data Boundary by S3NS” — a control layer (Access Transparency, Cloud External Key Manager, Key Access Justifications) applied to roughly 46 standard GCP products — uses the same *.googleapis.com console and API endpoints as vanilla GCP; nothing proprietary sits in front of the covered services. “Cloud de Confiance by S3NS” (also marketed as “Trusted Cloud” or PREMI3NS) is a structurally different, more isolated product: its own console (console.cloud.s3nscloud.fr) and its own API domains (compute.s3nsapis.fr instead of compute.googleapis.com), with Thales running first- and second-line support directly and controlling a quarantine zone that vets Google’s own software updates before they reach the platform. S3NS’s own marketing calls this a “quasi-mirror” of standard GCP without naming which APIs are identical and which aren’t — of everything checked for this post, this is the offering furthest from a drop-in-portable API surface.

Across all five, one gap is shared rather than distinguishing: no primary source for any of them names an actual bulk-export API, CLI tool, or output format — open like Parquet/CSV, or proprietary. That’s a documentation gap common to all five sovereignty-branded offerings, not a point in favor of any single one.

The floor under all of this: the EU Data Act🔗

Whatever egress friction exists across these providers today is not a permanent feature of the market. Under the EU Data Act (Regulation 2023/2854), Article 29, cloud switching charges — explicitly including data-egress fees — have been capped at the provider’s direct switching costs since January 2024, and ordinary switching charges — including standard data-egress fees tied to switching — must be phased out entirely from January 12, 2027, for data-processing services the Data Act covers. That applies to AWS, Microsoft, Google, and their sovereignty-branded offerings alike, regardless of what any of them calls itself. Premium or additional services around a migration (e.g. converting data into a specific format, or accelerating the switch) can still be priced separately — the Data Act caps ordinary switching charges, not every possible service around a move. Today’s egress numbers are a snapshot of where things stand before that deadline, not a durable differentiator between providers.

Independent commentary on these offerings specifically, rather than on hyperscaler lock-in in general, exists too, from the same industry body in two separate statements. CISPE — a trade association representing EU-based cloud infrastructure providers — objected specifically to the EU’s April 2026 selection of S3NS for a sovereign-cloud framework contract, calling it a case that “threatens to institutionalize sovereignty washing” (quoted in full in Part 2). Separately, in March 2026, CISPE and 24 other European providers wrote to the European Commission urging that the upcoming Cloud and AI Development Act define sovereignty by control rather than by having an EU legal presence — the same underlying argument, made at the policy level rather than about one specific provider. It’s the same term this series opened with, applied independently by an industry body to exactly the exit-path question this post asks.

None of this is a recommendation for or against any specific provider or offering. Whether the account-boundary friction in AWS ESC, the undocumented export tooling shared across all five, or the proprietary API surface specific to S3NS’s Trusted Cloud product actually matters depends entirely on how likely a given workload is to need to move, and what it would cost to find out the hard way. This post names what’s documented and what isn’t — it doesn’t rank the five against each other.

Next in this series: Part 6 — What Does It Cost to Leave — or Arrive? →

Related🔗

• Sovereign-Cloud-Washing: Five Questions — Question 4, where this framework first appeared
• Who Builds the Platform? Ownership vs. Stack — the Bleu, S3NS, Microsoft, AWS, and Google cases this post checks on exit
• Log Archiving Pre-Flight, Flexibility & Auditor Export — the bulk-export commands and checksum-manifest pattern behind this post’s export-format section
• Log Archiving: Query, Dashboards & Recommendations — the SQL-vs-KQL comparison behind the API-openness section
• AWS vs. GCP vs. Azure vs. OVHcloud: Managed Log Archiving — the egress-pricing figures behind this post’s cost section

Sources🔗

• AWS European Sovereign Cloud whitepaper: design approach and launch blog post
• AWS European Sovereign Cloud pricing
• Microsoft Learn: Microsoft Sovereign Cloud overview
• Capgemini: launch of Bleu’s commercial activities
• Google Cloud: Sovereign Controls by Partners overview, in-scope services for sovereign cloud, and France Data Boundary by S3NS
• S3NS: Trusted Cloud by S3NS and next.ink: Thales and Google detail how S3NS works on Cloud de Confiance
• McCann FitzGerald: EU Data Act switching charges and egress fees
• The Register: CISPE warns EU against “sovereignty washing” (March 2026, Cloud and AI Development Act letter)
• The Register: EU picks four sovereign-cloud providers, incl. CISPE’s “sovereignty washing” objection to S3NS (April 2026)