N’est-ce pas simplement la carte des services AWS→UE ?

Non. La carte note ce vers quoi chaque service AWS correspond ; cette page est la mission qui vous déplace. La carte vous dit que les écarts existent (DynamoDB, Redshift, câblage Lambda poussé). La mission de sortie est l’équipe en régie qui les re-plateforme et séquence le déplacement.

À combien s’élève la facture d’egress pour partir ?

Elle dépend du volume de données et de la façon dont vous séquencez le déplacement, ce qui est précisément pourquoi le séquencement est une décision de conception précoce. Nous l’estimons dans l’audit et ordonnons la migration pour la maîtriser, plutôt que de la découvrir en pleine bascule.

Qu’advient-il de nos workloads DynamoDB et Redshift ?

Ce sont les lignes sans jumeau managé européen : elles sont re-plateformées, généralement vers ScyllaDB ou ClickHouse auto-hébergés, ou un équivalent européen managé lorsqu’il convient. C’est là que la sortie d’AWS concentre une vraie ingénierie, et nous le prouvons tôt.

Vers quel fournisseur européen quitter AWS ?

Celui qui convient à vos workloads. Un parc orienté streaming profite du Kafka managé d’OVHcloud ; un parc guidé par le coût de l’IaaS d’Hetzner ; un parc équilibré de Scaleway. Nous notons votre parc face à chacun avant de recommander, et la comparaison démarre sur la carte des services.

Quitter AWS

Quitter AWS : la mission de sortie, pas la table de services

AWS est le parc dont nous sortons le plus souvent les équipes, et le plus difficile à quitter par construction. Ceci n’est pas la carte des services AWS→UE. Cette table a sa propre page et note chaque service. Ceci est la mission : le verrouillage propre à AWS qui rend une sortie non triviale, et comment une équipe en régie le démêle et vous fait basculer vers une infrastructure souveraine européenne.

Le verrouillage AWS que vous payez réellement

AWS n’est pas cher à l’entrée ; il est cher à la sortie. Voici les mécanismes précis qui maintiennent un parc sur AWS bien après que l’équipe veut partir. Chacun est une ligne du plan de sortie.

Économie de l’egress AWS facture la sortie des données, pas l’entrée. Les gros parcs affrontent une vraie facture d’egress juste pour partir, ce qui fait du séquencement (quoi migrer, quand et comment) une décision de coût, pas seulement technique.
Services managés propriétaires DynamoDB, Redshift, Kinesis, les fonctions propres à Aurora et un câblage événementiel Lambda poussé n’ont pas de jumeau européen prêt à l’emploi. C’est là que la sortie d’AWS concentre son ingénierie, et là que la carte des services marque les écarts honnêtes.
Couplage IAM et compte L’identité, les organisations, les SCP et les politiques de ressources tissent un parc étroitement à AWS. Démêler qui-peut-faire-quoi et le réexprimer sur la cible est un travail discret et minutieux qu’un simple lift-and-shift sous-estime.
Engagements commerciaux Instances réservées, Savings Plans, accords de remise entreprise et contrats Marketplace peuvent vous retenir financièrement même quand l’architecture est prête à partir. Le plan de sortie doit tenir compte du papier, pas seulement des paquets.

Comment se déroule une sortie d’AWS

Le même modèle en régie, incrémental, que toute migration SaveOps, affûté pour les pièges propres à AWS. Dans l’ordre :

Audit du parc et du verrouillage Nous inventorions le compte AWS face à un fournisseur européen cible et, surtout, hiérarchisons le verrouillage : quels services sont des repointages propres, quelles sont les lignes propriétaires sans jumeau, et à quoi ressemblent les factures d’egress et contractuelles.
Choix de la cible et réduction du risque Nous choisissons le fournisseur européen adapté (un parc de streaming penche vers le Kafka managé d’OVHcloud, un parc guidé par le coût vers Hetzner) et prouvons d’abord les parties dures : le remplacement de DynamoDB ou Redshift, le repointage S3, la réexpression de l’IAM.
Migration séquencée Les workloads migrent par incréments ordonnés pour maîtriser coût d’egress et risque, pas par ordre alphabétique. Les déplacements liés à la gravité des données sont calés délibérément ; chaque incrément a un chemin de retour arrière et vos ingénieurs dessus.
Fermeture du compte AWS Le transfert inclut le démantèlement réel : vérifier qu’aucune dépendance silencieuse ne rappelle AWS, clôturer sensément les engagements réservés, et laisser votre équipe exploiter le parc européen en infrastructure-as-code.

Quand la sortie d’AWS est réellement terminée

Une migration AWS n’est finie que lorsque le compte peut être éteint, pas seulement quand le workload tourne ailleurs :

Chaque workload tourne en production sur une infrastructure souveraine européenne que votre équipe exploite.
Les écarts de services propriétaires (DynamoDB, Redshift, Kinesis et consorts) sont re-plateformés, pas laissés à rappeler AWS.
IAM, réseau et DNS sont entièrement réexprimés sur la cible ; plus rien de critique ne résout vers un endpoint AWS.
Les engagements réservés et contractuels sont pris en compte, pour que la ligne financière se clôture proprement avec la ligne technique.
Le compte AWS peut être fermé sans rien casser. C’est le vrai test que la sortie est complète.

Ce qu’une équipe qui quitte AWS demande d’abord

N’est-ce pas simplement la carte des services AWS→UE ?: Non. La carte note ce vers quoi chaque service AWS correspond ; cette page est la mission qui vous déplace. La carte vous dit que les écarts existent (DynamoDB, Redshift, câblage Lambda poussé). La mission de sortie est l’équipe en régie qui les re-plateforme et séquence le déplacement.
À combien s’élève la facture d’egress pour partir ?: Elle dépend du volume de données et de la façon dont vous séquencez le déplacement, ce qui est précisément pourquoi le séquencement est une décision de conception précoce. Nous l’estimons dans l’audit et ordonnons la migration pour la maîtriser, plutôt que de la découvrir en pleine bascule.
Qu’advient-il de nos workloads DynamoDB et Redshift ?: Ce sont les lignes sans jumeau managé européen : elles sont re-plateformées, généralement vers ScyllaDB ou ClickHouse auto-hébergés, ou un équivalent européen managé lorsqu’il convient. C’est là que la sortie d’AWS concentre une vraie ingénierie, et nous le prouvons tôt.
Vers quel fournisseur européen quitter AWS ?: Celui qui convient à vos workloads. Un parc orienté streaming profite du Kafka managé d’OVHcloud ; un parc guidé par le coût de l’IaaS d’Hetzner ; un parc équilibré de Scaleway. Nous notons votre parc face à chacun avant de recommander, et la comparaison démarre sur la carte des services.