Isn’t this just the AWS-to-EU service map?

No. The service map grades what each AWS service maps to; this page is the engagement that moves you. The map tells you the gaps exist (DynamoDB, Redshift, deep Lambda wiring). The exit engagement is the embedded team that re-platforms them and sequences the move.

How bad is the egress bill to leave?

It depends on data volume and how you sequence the move, which is exactly why sequencing is an early design decision. We estimate it in the audit and order the migration to control it, rather than discovering it mid-cutover.

What happens to our DynamoDB and Redshift workloads?

They are the rows with no managed EU twin, so they get re-platformed, typically onto self-hosted ScyllaDB or ClickHouse, or a managed EU equivalent where one fits. This is where an AWS exit concentrates real engineering, and we prove it early.

Which EU provider should we leave AWS for?

The one that fits your workloads. A streaming-heavy estate benefits from OVHcloud’s managed Kafka; a cost-driven one from Hetzner’s IaaS; a balanced one from Scaleway. We grade your estate against each before recommending, and the comparison starts on the service map.

Leave AWS

Leaving AWS: the exit engagement, not the service table

AWS is the most common estate we move teams off, and the hardest to leave by design. This is not the AWS-to-EU service map. That table lives on its own page and grades every service. This is the engagement: the AWS-specific lock-in that makes an exit non-trivial, and how an embedded team unpicks it and moves you onto EU-sovereign infrastructure.

The AWS lock-in you are actually paying for

AWS is not expensive to enter; it is expensive to leave. These are the specific mechanisms that keep an estate on AWS long after the team wants out. Each one is a line in the exit plan.

Data-egress economics AWS charges to move data out but not in. Large estates face a real egress bill just to leave, which makes sequencing (what moves when, and how) a cost decision, not only a technical one.
Proprietary managed services DynamoDB, Redshift, Kinesis, Aurora-specific features and deep Lambda event wiring have no drop-in EU twin. These are where an AWS exit concentrates its engineering, and where the service map marks the honest gaps.
IAM and account coupling Identity, organisations, SCPs and resource policies knit an estate tightly to AWS. Unpicking who-can-do-what and re-expressing it on the target is quiet, careful work that a lift-and-shift underestimates.
Commercial commitments Reserved Instances, Savings Plans, enterprise discount agreements and Marketplace contracts can pin you financially even when the architecture is ready to move. The exit plan has to account for the paper, not just the packets.

How an AWS exit runs

The same embedded, incremental model as any SaveOps migration, sharpened for AWS-specific traps. In order:

Estate and lock-in audit We inventory the AWS account against a target EU provider and, crucially, rank the lock-in: which services are clean repoints, which are the proprietary rows with no twin, and what the egress and contractual bills look like.
Target selection and de-risking We pick the EU provider that fits (a streaming estate leans to OVHcloud’s managed Kafka, a cost-driven one to Hetzner) and prove the hard parts first: the DynamoDB or Redshift replacement, the S3 repoint, the IAM re-expression.
Sequenced migration Workloads move in increments ordered to control egress cost and risk, not alphabetically. Data-gravity moves are timed deliberately; each increment has a rollback path and your engineers on it.
Wind down the AWS account Handover includes actually decommissioning: confirming no silent dependency still calls back to AWS, closing out reserved commitments sensibly, and leaving your team operating the EU estate on infrastructure-as-code.

When the AWS exit is actually done

An AWS migration is finished only when the account can be switched off, not merely when the workload runs elsewhere:

Every workload runs in production on EU-sovereign infrastructure your team operates.
The proprietary-service gaps (DynamoDB, Redshift, Kinesis and peers) are re-platformed, not left calling back to AWS.
IAM, networking and DNS are fully re-expressed on the target; nothing critical still resolves to an AWS endpoint.
Reserved and contractual commitments are accounted for, so the finance line closes cleanly with the technical one.
The AWS account can be wound down without breaking anything. That is the real test that the exit is complete.

What a team leaving AWS asks first

Isn’t this just the AWS-to-EU service map?: No. The service map grades what each AWS service maps to; this page is the engagement that moves you. The map tells you the gaps exist (DynamoDB, Redshift, deep Lambda wiring). The exit engagement is the embedded team that re-platforms them and sequences the move.
How bad is the egress bill to leave?: It depends on data volume and how you sequence the move, which is exactly why sequencing is an early design decision. We estimate it in the audit and order the migration to control it, rather than discovering it mid-cutover.
What happens to our DynamoDB and Redshift workloads?: They are the rows with no managed EU twin, so they get re-platformed, typically onto self-hosted ScyllaDB or ClickHouse, or a managed EU equivalent where one fits. This is where an AWS exit concentrates real engineering, and we prove it early.
Which EU provider should we leave AWS for?: The one that fits your workloads. A streaming-heavy estate benefits from OVHcloud’s managed Kafka; a cost-driven one from Hetzner’s IaaS; a balanced one from Scaleway. We grade your estate against each before recommending, and the comparison starts on the service map.