AWS European Sovereign Cloud (partie 1) : souveraineté numérique, architecture et enjeux

Introduction

La souveraineté numérique est devenue un sujet central dans les stratégies IT des entreprises européennes. Entre les réglementations de plus en plus strictes, les tensions géopolitiques et la dépendance croissante aux hyperscalers américains, les organisations doivent repenser leur approche du cloud. C'est dans ce contexte qu'Amazon Web Services a annoncé le lancement d'AWS European Sovereign Cloud (ESC), une infrastructure cloud dédiée, physiquement et logiquement séparée des régions AWS commerciales existantes.

Mais qu'est-ce que la souveraineté numérique exactement ? En quoi diffère-t-elle de la cybersécurité ? Quels sont les véritables enjeux pour les entreprises qui envisagent de migrer vers cette offre ? Et surtout, comment naviguer dans la complexité d'un mode hybride entre AWS commercial et l'ESC ?

Cette série de deux articles propose une analyse approfondie de ces questions. Dans cette première partie, nous abordons les fondamentaux : définition de la souveraineté, architecture de l'ESC, rôle de Nitro, stratégie de chiffrement, enjeux sectoriels et question de SecNumCloud. La seconde partie couvre les défis techniques, opérationnels et les recommandations pratiques.

Souveraineté numérique : de quoi parle-t-on ?

Définition et périmètre

La souveraineté numérique désigne la capacité d'un État, d'une organisation ou d'un individu à exercer un contrôle sur ses données, ses infrastructures numériques et ses processus de décision dans l'espace numérique. Elle englobe plusieurs dimensions :

• La souveraineté des données : savoir où sont stockées les données, qui y a accès, et sous quelle juridiction elles tombent.
• La souveraineté opérationnelle : garantir que l'exploitation des infrastructures est réalisée par du personnel soumis au droit européen, sans possibilité d'ingérence étrangère.
• La souveraineté technologique : disposer de la maîtrise des technologies utilisées, ou a minima d'une indépendance suffisante pour ne pas être soumis à des décisions unilatérales d'un fournisseur étranger.

Ne pas confondre souveraineté et cybersécurité

C'est probablement la confusion la plus répandue dans les discussions autour du cloud souverain. La cybersécurité et la souveraineté numérique sont deux concepts distincts, bien qu'ils se recoupent partiellement.

La cybersécurité concerne la protection des systèmes d'information contre les menaces : attaques, intrusions, fuites de données, ransomwares, etc. Elle répond à la question « comment protéger mes données contre les attaquants ? ».

La souveraineté numérique concerne le contrôle et la gouvernance des données et des infrastructures. Elle répond à la question « qui a le pouvoir de décision sur mes données et mes systèmes ? ».

Un cloud peut être parfaitement sécurisé au sens cybersécurité (chiffrement, contrôle d'accès, détection d'intrusion) tout en posant des problèmes de souveraineté si, par exemple, un gouvernement étranger peut légalement contraindre le fournisseur à divulguer des données via des mécanismes comme le CLOUD Act américain.

Inversement, un cloud souverain mal configuré peut présenter des failles de sécurité béantes. La souveraineté ne garantit pas la sécurité, et la sécurité ne garantit pas la souveraineté. Les deux sont nécessaires, mais aucun ne suffit seul.

Le contexte réglementaire européen

Plusieurs textes législatifs européens encadrent désormais la gestion des données et poussent vers plus de souveraineté :

• RGPD (2018) : protection des données personnelles, avec des restrictions sur les transferts hors UE.
• NIS2 (2024) : renforcement des obligations de cybersécurité pour les entités essentielles et importantes.
• DORA (2025) : résilience opérationnelle numérique pour le secteur financier.
• Data Act (2025) : portabilité des données et conditions d'accès.
• EUCS (en cours) : schéma européen de certification cloud, qui devrait définir des niveaux d'assurance pour les services cloud.

C'est dans ce paysage réglementaire dense que s'inscrit l'offre AWS ESC.

AWS European Sovereign Cloud : architecture et principes

Qu'est-ce que l'ESC ?

AWS European Sovereign Cloud est une infrastructure cloud complètement séparée des régions AWS commerciales. Contrairement à une simple région européenne d'AWS (comme eu-west-1 à Dublin ou eu-central-1 à Francfort), l'ESC repose sur :

• Une séparation physique : des datacenters dédiés, situés exclusivement sur le territoire de l'Union européenne.
• Une séparation logique : un plan de contrôle indépendant, des systèmes de facturation séparés, et aucune interconnexion avec l'infrastructure AWS globale.
• Un personnel exclusivement européen : les opérations sont réalisées par des employés résidant dans l'UE et soumis au droit européen.
• Une gouvernance européenne : les décisions opérationnelles sont prises au sein de l'UE, sans possibilité d'intervention depuis les États-Unis.

Les services disponibles

L'ESC propose progressivement les services AWS les plus utilisés, adaptés aux exigences de souveraineté. On y retrouve notamment Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS), AWS Lambda, Amazon Virtual Private Cloud (VPC), et les services de sécurité comme AWS Key Management Service (KMS) avec des clés gérées exclusivement dans l'ESC.

Cependant, tous les services AWS ne sont pas disponibles dans l'ESC. C'est l'un des défis majeurs que nous aborderons dans la seconde partie.

Pour suivre l'évolution des services disponibles et planifier vos architectures en fonction des capacités actuelles et à venir, AWS met à disposition un outil interactif : AWS Builder - Capabilities. Cet outil permet de visualiser les services disponibles par région et par partition, y compris l'ESC. Il est particulièrement utile pour les architectes qui doivent valider la faisabilité d'un déploiement sur l'ESC avant de s'engager dans une migration. Vous pouvez y filtrer par catégorie de service (compute, storage, database, analytics, etc.) et comparer la couverture entre la partition commerciale et la partition souveraine.

AWS Nitro System : la fondation sécuritaire de l'ESC

Un élément fondamental de l'architecture de sécurité d'AWS — et donc de l'ESC — est le système AWS Nitro. Comprendre Nitro est essentiel pour appréhender les garanties de sécurité offertes par l'infrastructure souveraine.

Qu'est-ce que Nitro ?

AWS Nitro System est l'architecture matérielle et logicielle sous-jacente à toutes les instances EC2 modernes. Il se compose de trois éléments principaux :

• Les cartes Nitro : des composants matériels dédiés qui gèrent le réseau, le stockage (EBS) et le monitoring, en les déchargeant complètement de l'hyperviseur.
• Le Nitro Security Chip : une puce dédiée qui contrôle l'accès au matériel serveur et fournit une racine de confiance matérielle (hardware root of trust).
• Le Nitro Hypervisor : un hyperviseur minimaliste et durci, dont la surface d'attaque est considérablement réduite par rapport aux hyperviseurs traditionnels.

Ce que Nitro apporte à la souveraineté

Dans le contexte de l'ESC, Nitro offre des garanties de sécurité qui renforcent la posture de souveraineté :

Isolation cryptographique : chaque instance EC2 est isolée au niveau matériel. Même un employé AWS ayant un accès physique au serveur ne peut pas accéder à la mémoire ou au stockage d'une instance en cours d'exécution. Le Nitro Security Chip empêche physiquement toute lecture de la mémoire volatile.

Pas d'accès opérateur : contrairement aux architectures traditionnelles où un administrateur système peut potentiellement accéder aux données des machines virtuelles, Nitro élimine cette possibilité par conception. Il n'existe aucun mécanisme — ni SSH, ni console de debug, ni port de maintenance — permettant à un opérateur AWS d'accéder au contenu d'une instance client.

Attestation matérielle : Nitro Enclaves permet d'exécuter du code dans un environnement d'exécution de confiance (TEE - Trusted Execution Environment) avec une attestation cryptographique. Cela garantit que le code exécuté n'a pas été altéré et que les données traitées restent confidentielles, même vis-à-vis de l'opérateur de l'infrastructure.

Intégrité du firmware : le Nitro Security Chip vérifie l'intégrité du firmware à chaque démarrage. Toute modification non autorisée du firmware est détectée et empêche le démarrage du serveur.

Une architecture reconnue dans la littérature académique

Il est intéressant de noter que l'architecture Nitro n'est pas simplement un produit marketing. Elle est citée et étudiée dans des ouvrages de référence sur l'architecture des processeurs et la virtualisation matérielle. Le concept de déport des fonctions d'I/O vers des composants matériels dédiés (offloading), la séparation stricte entre le plan de données et le plan de contrôle au niveau silicium, et l'utilisation d'une racine de confiance matérielle sont des patterns architecturaux documentés dans la littérature sur les systèmes sur puce (SoC) et les architectures de sécurité matérielle.

Des ouvrages comme Computer Architecture: A Quantitative Approach (Hennessy & Patterson) abordent les principes fondamentaux sur lesquels repose Nitro : la spécialisation matérielle, les accélérateurs dédiés et l'isolation par le matériel. L'approche de Nitro — qui consiste à retirer l'hyperviseur du chemin critique des données et à confier les opérations sensibles à des puces dédiées — s'inscrit dans une tendance plus large de l'industrie vers les SmartNICs et les DPU (Data Processing Units), documentée dans les publications IEEE et ACM sur les architectures de datacenter modernes.

Cette reconnaissance académique renforce la crédibilité des garanties de sécurité offertes par Nitro : il ne s'agit pas d'une simple promesse contractuelle, mais d'une impossibilité technique vérifiable et documentée.

Nitro et la réponse au CLOUD Act

L'un des arguments les plus puissants de Nitro dans le contexte de la souveraineté est le suivant : même si, théoriquement, une autorité étrangère obtenait une injonction légale contre AWS, l'architecture Nitro rend techniquement impossible l'accès aux données en cours de traitement sur les instances. AWS ne peut pas fournir ce à quoi il n'a pas accès. Combiné à un chiffrement côté client avec des clés gérées par le client (Customer Managed Keys dans KMS ESC), cela crée une protection technique qui complète la protection juridique offerte par la séparation de l'ESC.

KMS, chiffrement au repos et souveraineté : faut-il des CMK pour être souverain ?

Le chiffrement au repos est souvent présenté comme la pierre angulaire de la protection des données dans le cloud. Mais dans le contexte de la souveraineté, la question n'est pas simplement « mes données sont-elles chiffrées ? » mais plutôt « qui contrôle les clés de chiffrement ? ».

Les options de chiffrement sur AWS

AWS propose plusieurs niveaux de chiffrement au repos :

• SSE-S3 (Server-Side Encryption with S3 Managed Keys) : AWS gère entièrement les clés. Le chiffrement est transparent pour l'utilisateur. C'est le niveau par défaut depuis janvier 2023.
• SSE-KMS avec clé gérée par AWS (aws/s3) : AWS KMS gère la clé, mais vous bénéficiez d'un audit via CloudTrail et de politiques de contrôle d'accès.
• SSE-KMS avec CMK (Customer Managed Key) : vous créez et contrôlez la clé dans KMS. Vous définissez qui peut l'utiliser, vous pouvez la désactiver ou la supprimer, et vous contrôlez sa rotation.
• SSE-C (Server-Side Encryption with Customer-Provided Keys) : vous fournissez la clé à chaque requête via les headers HTTPS. AWS l'utilise pour chiffrer/déchiffrer en mémoire puis la supprime immédiatement — elle n'est jamais stockée côté AWS. Cette option est pleinement compatible avec l'ESC puisqu'elle repose uniquement sur le protocole S3 standard, sans dépendance à un service de gestion de clés spécifique à une partition.
• Chiffrement côté client (Client-Side Encryption) : vous chiffrez les données dans votre application avant de les envoyer à AWS. AWS ne voit jamais les données en clair et ne manipule aucune clé. C'est l'option la plus agnostique : elle fonctionne sur toute partition (commerciale, ESC, GovCloud) puisque le chiffrement est entièrement décorrélé de l'infrastructure AWS. C'est aussi l'option qui offre le niveau de souveraineté le plus élevé — même avec un accès physique aux disques ou aux HSM, les données restent illisibles sans vos clés.

Doit-on avoir des CMK pour être souverain ?

C'est une question qui revient systématiquement dans les discussions sur la souveraineté, et la réponse mérite d'être nuancée.

L'argument en faveur des CMK : avec une Customer Managed Key, vous avez le contrôle total sur le cycle de vie de la clé. Vous pouvez la révoquer à tout moment, rendant les données illisibles. C'est un mécanisme de « kill switch » qui vous donne un pouvoir concret sur vos données, indépendamment du fournisseur cloud.

Mais les CMK ne suffisent pas à garantir la souveraineté : une CMK dans KMS reste gérée par le service KMS d'AWS. Même si vous contrôlez la politique d'accès, c'est AWS qui opère le HSM (Hardware Security Module) sous-jacent. Dans la partition commerciale, un employé AWS aux États-Unis pourrait théoriquement avoir accès au plan de contrôle de KMS.

Dans l'ESC, la donne change : les HSM de KMS dans l'ESC sont opérés exclusivement par du personnel européen, dans des datacenters européens, avec un plan de contrôle séparé. Une CMK dans KMS ESC offre donc un niveau de souveraineté significativement supérieur à une CMK dans KMS commercial.

Quand les CMK sont-elles indispensables ?

Les CMK sont recommandées (voire obligatoires selon les contextes) dans les cas suivants :

• Données régulées : si votre régulateur exige que vous démontriez un contrôle sur les clés de chiffrement, les CMK sont nécessaires.
• Exigence de révocabilité : si vous devez pouvoir rendre des données illisibles rapidement (en cas de fin de contrat, de litige, ou de compromission), les CMK vous donnent ce pouvoir.
• Audit et traçabilité : les CMK dans KMS génèrent des événements CloudTrail pour chaque utilisation, ce qui permet un audit complet de qui accède aux données et quand.
• Séparation des responsabilités : dans une organisation où l'équipe sécurité doit contrôler les clés indépendamment de l'équipe applicative, les CMK permettent cette séparation via les key policies.

Quand les CMK ne sont pas nécessaires ?

Pour des données non sensibles ou des cas d'usage où la souveraineté n'est pas un enjeu (données publiques, caches, données temporaires), le chiffrement par défaut SSE-S3 ou SSE-KMS avec clé AWS est suffisant. Multiplier les CMK sans raison augmente la complexité opérationnelle (gestion de la rotation, risque de suppression accidentelle, coûts KMS) sans apporter de bénéfice réel.

La stratégie recommandée

Une approche pragmatique consiste à :

1. Classifier les données par niveau de sensibilité
2. Appliquer des CMK uniquement aux données sensibles et régulées
3. Utiliser le chiffrement par défaut pour les données non sensibles
4. Envisager le chiffrement côté client pour les données les plus critiques (secrets industriels, données de santé nominatives) — dans ce cas, même AWS avec un accès au HSM ne pourrait pas déchiffrer les données

Les enjeux de la souveraineté pour les entreprises

Enjeux stratégiques

Pour les entreprises européennes, la souveraineté numérique n'est pas qu'une question de conformité réglementaire. C'est un enjeu stratégique à plusieurs niveaux :

• Continuité d'activité : en cas de sanctions internationales ou de tensions géopolitiques, une entreprise dépendante d'un cloud américain pourrait se voir couper l'accès à ses propres données.
• Confiance des clients : dans des secteurs comme la santé, la finance ou le secteur public, la localisation et le contrôle des données sont des critères de choix déterminants.
• Propriété intellectuelle : les données de R&D, les algorithmes propriétaires et les secrets industriels nécessitent un niveau de protection qui va au-delà de la simple cybersécurité.
• Indépendance décisionnelle : ne pas être soumis aux conditions générales d'utilisation d'un fournisseur qui peut modifier unilatéralement ses termes de service.

Enjeux sectoriels

Certains secteurs sont particulièrement concernés par la souveraineté :

• Secteur public et défense : obligation légale de traiter certaines données sur le territoire national, sous contrôle d'entités habilitées.
• Santé : les données de santé sont soumises à des réglementations spécifiques (hébergement de données de santé en France, par exemple).
• Finance : DORA impose des exigences strictes sur la résilience et le contrôle des prestataires cloud.
• Énergie et infrastructures critiques : NIS2 renforce les obligations pour les opérateurs d'importance vitale.

Le défi législatif : SecNumCloud, nécessité ou superflu ?

Qu'est-ce que SecNumCloud ?

SecNumCloud est une qualification délivrée par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) en France. Elle atteste qu'un prestataire de services cloud respecte un ensemble d'exigences de sécurité et de souveraineté définies par le référentiel de l'ANSSI.

La version 3.2 du référentiel, publiée en 2022, a introduit des critères de souveraineté stricts : le prestataire doit être une entité européenne, détenue majoritairement par des capitaux européens, et ne doit pas être soumis à des législations extraterritoriales (comme le CLOUD Act).

SecNumCloud est-il nécessaire ?

La réponse dépend fortement du contexte :

Pour les administrations françaises : la doctrine « Cloud au centre » de l'État français impose l'utilisation de clouds qualifiés SecNumCloud pour les données sensibles. C'est donc une obligation réglementaire dans ce contexte.

Pour les entreprises privées françaises : SecNumCloud n'est pas une obligation légale générale. Cependant, certains secteurs régulés (santé, finance) peuvent avoir des exigences qui convergent vers ce type de qualification.

Pour les entreprises européennes hors France : SecNumCloud est une qualification purement française. Elle n'a pas de valeur juridique en Allemagne, aux Pays-Bas ou en Italie. Chaque pays peut avoir ses propres exigences ou se référer au futur schéma EUCS.

SecNumCloud vs EUCS : le débat européen

Le schéma européen de certification cloud (EUCS) est en cours d'élaboration au niveau de l'ENISA. Il devrait définir trois niveaux d'assurance : basique, substantiel et élevé.

Le débat fait rage sur le niveau « élevé » : doit-il inclure des critères de souveraineté (immunité aux lois extraterritoriales) comme le fait SecNumCloud 3.2, ou doit-il se limiter à des critères techniques de sécurité ?

La France pousse pour inclure des critères de souveraineté au niveau élevé, tandis que d'autres pays européens (notamment les Pays-Bas et les pays nordiques) considèrent que cela exclurait de facto les hyperscalers américains et limiterait le choix des entreprises.

Position d'AWS ESC par rapport à SecNumCloud

AWS ESC ne vise pas la qualification SecNumCloud dans sa forme actuelle. En effet, SecNumCloud 3.2 exige que le prestataire soit détenu majoritairement par des capitaux européens, ce qui exclut structurellement AWS, même avec l'ESC.

Cependant, l'ESC répond à de nombreuses exigences de souveraineté :

• Données stockées exclusivement dans l'UE
• Personnel européen
• Séparation du plan de contrôle
• Pas d'accès depuis l'extérieur de l'UE

La question est donc : SecNumCloud est-il un prérequis absolu, ou l'ESC offre-t-il un niveau de souveraineté suffisant pour la majorité des cas d'usage ? Pour les entreprises qui ne sont pas soumises à la doctrine « Cloud au centre », l'ESC peut constituer une réponse pragmatique aux enjeux de souveraineté, sans les contraintes d'un écosystème SecNumCloud encore limité en termes de services disponibles.

---

Comprendre les enjeux de souveraineté, l'architecture de l'ESC et le cadre législatif est un prérequis. Mais la vraie complexité se révèle quand on passe à l'implémentation : comment gérer deux partitions au quotidien ? Quels sont les pièges techniques ? Comment adapter son Infrastructure as Code ?

C'est ce que nous abordons dans la seconde partie : parité de services, IAM régional, connectivité réseau entre partitions, Terraform multi-partition, Landing Zone Accelerator, facturation séparée, et recommandations pratiques pour réussir votre adoption de l'ESC.