sylvainbruas

Posted on May 11 • Originally published at sylvain.bruas.fr

AWS European Sovereign Cloud (partie 2) : défis techniques, opérationnels et recommandations pratiques

#aws #souverainete #cloud #architecture

Cet article est la seconde partie de notre analyse d'AWS European Sovereign Cloud. Dans la première partie, nous avons posé les fondations : ce qu'est la souveraineté numérique (et ce qu'elle n'est pas), l'architecture de l'ESC, les garanties offertes par Nitro, la stratégie de chiffrement, les enjeux sectoriels et la question de SecNumCloud.

Maintenant, passons aux choses concrètes. Quand on ouvre la console ESC pour la première fois, qu'est-ce qui change vraiment ? Quels sont les pièges à éviter et les patterns qui fonctionnent ?

Les défis techniques

Parité de services

L'un des défis techniques majeurs de l'ESC est la parité de services avec AWS commercial. Au lancement, seul un sous-ensemble des services AWS est disponible. Cela signifie que les architectures conçues pour AWS commercial ne sont pas nécessairement transposables telles quelles vers l'ESC.

Les équipes d'architecture doivent :

Inventorier les services utilisés et vérifier leur disponibilité dans l'ESC
Identifier des alternatives pour les services manquants
Adapter les patterns d'architecture en conséquence

Par exemple, si votre architecture repose sur Amazon OpenSearch Serverless, ce service n'est pas disponible au lancement de l'ESC. D'autres services comme Amazon Bedrock sont présents mais avec un catalogue de modèles et de fonctionnalités plus limité que dans la partition commerciale — il est donc essentiel de vérifier la couverture exacte avant de s'engager.

Gestion des identités et des accès

La séparation du plan de contrôle implique que les comptes AWS ESC sont distincts des comptes AWS commerciaux. L'ESC dispose de son propre service IAM, entièrement séparé de celui de la partition commerciale. IAM dans l'ESC est global au sein de la partition ESC, exactement comme IAM est global au sein de la partition commerciale. Mais les deux IAM sont cloisonnés : aucune identité, aucun rôle, aucune politique ne traverse la frontière entre partitions.

Cela a des implications majeures :

AWS Organizations : les organisations ESC sont séparées des organisations commerciales. Vous gérez deux hiérarchies de comptes indépendantes.
IAM séparé : les rôles, politiques et utilisateurs IAM créés dans la partition commerciale n'existent pas dans l'ESC et vice versa. Les endpoints IAM de l'ESC utilisent le domaine amazonaws.eu (par exemple iam.eusc-de-east-1.amazonaws.eu). L'ensemble des identités doit être recréé dans l'ESC.
SSO/Federation : les intégrations avec les fournisseurs d'identité doivent être reconfigurées. Il est possible de pointer les deux instances IAM Identity Center (commerciale et ESC) vers le même IdP d'entreprise (Entra ID, Okta, etc.), mais les permission sets, les assignments de comptes et les groupes doivent être gérés séparément dans chaque partition.
Cross-partition access : pas de possibilité d'accès croisé entre comptes ESC et comptes commerciaux. Un rôle dans arn:aws:iam::123456789012:role/MyRole ne peut pas assumer un rôle dans arn:aws-eusc:iam::987654321098:role/MyRole — les deux partitions ne se voient tout simplement pas. C'est le même cloisonnement qui existe entre AWS commercial et AWS GovCloud ou AWS Chine.

Réseau et connectivité

La séparation réseau entre l'ESC et AWS commercial pose des défis de connectivité :

Pas de VPC peering entre ESC et régions commerciales
Pas de Transit Gateway partagé
Les connexions Direct Connect doivent être dédiées
Les architectures multi-régions doivent être repensées

Liaison réseau entre l'ESC et la partition commerciale

La question de la connectivité entre l'ESC et AWS commercial est cruciale pour les entreprises en mode hybride. Puisque les deux partitions sont logiquement et physiquement séparées, il n'existe pas de mécanisme natif de peering interne — pas de VPC peering, pas de Transit Gateway peering, pas de PrivateLink entre partitions. Voici les options disponibles, détaillées dans l'article de référence d'AWS : Connectivity patterns between AWS European Sovereign Cloud and AWS commercial partition.

Option 1 : Connectivité via Internet avec chiffrement TLS natif

Si l'application utilise nativement le chiffrement TLS (par exemple, du trafic API sur HTTPS/443), il est possible d'utiliser des Elastic IP addresses pour communiquer entre les partitions. C'est le pattern le plus performant et le plus simple à opérer : il ne nécessite pas de maintenir des appliances VPN sur des instances EC2 ni de configurer un Direct Connect Gateway. En revanche, cette option ne fournit pas de chiffrement au niveau de la couche transport réseau — la responsabilité du chiffrement en transit repose sur l'application.

Option 2 : VPN IPSec site-to-site entre partitions (service managé côté ESC)

Ce pattern établit des tunnels VPN IPSec directement entre les deux partitions, sans passer par une infrastructure on-premises. Côté ESC, le tunnel est terminé par le service managé AWS Site-to-Site VPN, attaché à un Transit Gateway — aucune appliance tierce n'est nécessaire dans la partition souveraine. Côté AWS commercial, une appliance virtuelle tierce (Cisco CSR, Palo Alto, Fortinet, StrongSwan, etc.) fait office de Customer Gateway et termine l'autre extrémité du tunnel. Le débit maximum par tunnel VPN est de 1,25 Gbps ; pour des besoins supérieurs, activez le routage ECMP (Equal-Cost Multi-Path) pour agréger le débit sur plusieurs connexions VPN. Ce pattern est adapté aux applications qui ne supportent pas le chiffrement au niveau applicatif ou qui ne doivent pas être exposées via un Internet Gateway.

Option 3 : Connectivité via Direct Connect et infrastructure on-premises ou fournisseur de services

Ce modèle hub-and-spoke route le trafic inter-partition via une infrastructure client connectée par AWS Direct Connect. Deux variantes existent :

Via un datacenter on-premises : des connexions Direct Connect séparées relient chaque partition au datacenter, où des équipements réseau (firewalls, routeurs) contrôlent le trafic inter-partition.
Via un fournisseur de services cloud exchange (Equinix, Digital Realty, etc.) : pour les organisations sans datacenter, une infrastructure gateway virtuelle hébergée chez le fournisseur assure le même rôle.

Le trafic est « hairpinné » via l'infrastructure client, ce qui ajoute de la latence, des coûts de transfert de données sortantes (DTO) et des frais de traitement Transit Gateway. Le Direct Connect Gateway est un construct global qui permet la connectivité vers n'importe quelle région AWS, mais ne propage pas les préfixes BGP entre les Transit Gateways associés.

Option 4 : Transit VPC avec Transit Gateway Connect

Ce pattern utilise un Transit VPC avec des appliances virtuelles tierces redondantes dans différentes zones de disponibilité, connectées au Transit Gateway via des attachments Transit Gateway Connect. Cette approche utilise BGP over GRE (Generic Routing Encapsulation) pour simplifier la connectivité avec le Transit Gateway. À noter que GRE ne fournit pas de chiffrement — si le chiffrement est nécessaire, il faut utiliser un VPN IPSec entre les appliances et le Transit Gateway (comme dans l'option 2).

Option 5 : Pas de liaison directe (air gap logique)

Pour les workloads les plus sensibles, la meilleure option peut être de ne pas établir de liaison réseau du tout entre l'ESC et la partition commerciale. Les données sont transférées via des mécanismes asynchrones contrôlés (export/import chiffré, files de messages avec validation), ce qui garantit une séparation maximale.

Backbone AWS et trafic inter-partition

L'ESC dispose de son propre backbone séparé de celui de la partition commerciale (similaire à AWS Chine). Cette séparation d'infrastructure renforce le modèle de souveraineté de l'ESC.

Considérations importantes

Quelle que soit l'option choisie, gardez à l'esprit :

La latence sera plus élevée qu'entre deux régions commerciales
Vous devez documenter et justifier chaque flux de données entre les partitions pour des raisons de conformité
Les coûts de transfert de données s'appliquent dans les deux sens

Observabilité et monitoring

Les outils de monitoring centralisés (Amazon CloudWatch, AWS CloudTrail) fonctionnent de manière isolée dans l'ESC. Les entreprises qui ont investi dans des dashboards centralisés couvrant plusieurs régions AWS commerciales devront adapter leur approche pour intégrer les métriques de l'ESC.

Les défis opérationnels

Le mode hybride : la complexité au quotidien

C'est probablement le défi le plus sous-estimé. La plupart des entreprises ne migreront pas 100 % de leurs workloads vers l'ESC. Elles adopteront un mode hybride où certaines charges de travail (les plus sensibles) seront dans l'ESC, tandis que d'autres resteront dans AWS commercial.

Cette hybridation crée une complexité opérationnelle considérable :

Gestion de deux environnements distincts : les équipes doivent maîtriser deux écosystèmes qui, bien que similaires, ont des différences subtiles (services disponibles, versions, limites).

Infrastructure as Code : les templates Terraform ou CloudFormation doivent être adaptés pour gérer les deux environnements. Les modules doivent être conditionnels, les providers configurés différemment, et les pipelines CI/CD dupliqués ou paramétrés.

Exemple Terraform : déploiement sur la partition commerciale vs l'ESC

Pour illustrer concrètement la différence, voici un exemple de déploiement d'une instance EC2 avec un bucket S3 sur les deux partitions.

Déploiement sur AWS commercial (partition aws) :

# providers.tf - Partition commerciale
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-3" # Paris
}

# main.tf - Ressources sur la partition commerciale
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "commercial-vpc"
    Environment = "production"
    Partition   = "aws-commercial"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eu-west-3a"

  tags = {
    Name = "commercial-private-subnet"
  }
}

resource "aws_instance" "app_server" {
  ami           = "ami-0a1b2c3d4e5f67890" # Amazon Linux 2023 - eu-west-3
  instance_type = "m6i.large"
  subnet_id     = aws_subnet.private.id

  metadata_options {
    http_tokens   = "required" # IMDSv2 obligatoire
    http_endpoint = "enabled"
  }

  tags = {
    Name        = "app-server-commercial"
    Environment = "production"
  }
}

resource "aws_s3_bucket" "data" {
  bucket = "mon-entreprise-data-commercial"

  tags = {
    Name        = "data-bucket-commercial"
    Partition   = "aws-commercial"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_key.arn
    }
  }
}

resource "aws_kms_key" "data_key" {
  description             = "Clé de chiffrement des données - Commercial"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

Déploiement sur AWS ESC (partition aws-eusc) :

# providers.tf - Partition ESC
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# Terraform 1.14+ avec le provider AWS 6.x résout nativement
# les endpoints ESC — il suffit de spécifier la région.
# Pas besoin de configurer les endpoints manuellement.
provider "aws" {
  region = "eusc-de-east-1" # Brandenburg, Allemagne
}

# Data source pour construire les ARN dynamiquement
# Retourne "aws-eusc" dans l'ESC, "aws" dans la partition commerciale
data "aws_partition" "current" {}
data "aws_caller_identity" "current" {}

# main.tf - Ressources sur la partition ESC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "sovereign-vpc"
    Environment = "production"
    Partition   = data.aws_partition.current.partition
    DataClass   = "sensible"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eusc-de-east-1a"

  tags = {
    Name = "sovereign-private-subnet"
  }
}

resource "aws_instance" "app_server" {
  ami           = "ami-0esc1a2b3c4d5e6f7" # AMI spécifique ESC
  instance_type = "m6i.large"
  subnet_id     = aws_subnet.private.id

  metadata_options {
    http_tokens   = "required"
    http_endpoint = "enabled"
  }

  tags = {
    Name        = "app-server-sovereign"
    Environment = "production"
    DataClass   = "sensible"
  }
}

resource "aws_s3_bucket" "data" {
  bucket = "mon-entreprise-data-sovereign"

  tags = {
    Name        = "data-bucket-sovereign"
    Partition   = data.aws_partition.current.partition
    DataClass   = "sensible"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_key.arn
    }
  }
}

resource "aws_kms_key" "data_key" {
  description             = "Clé de chiffrement des données - Souverain"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  # La clé reste exclusivement dans la partition ESC
  # Aucune réplication vers la partition commerciale
}

# Exemple d'ARN dynamique — fonctionne sur toute partition
output "kms_key_arn" {
  value = aws_kms_key.data_key.arn
  # Produit : arn:aws-eusc:kms:eusc-de-east-1:123456789012:key/...
}

Les différences clés à noter :

La région : eusc-de-east-1 (Brandenburg, Allemagne) au lieu de eu-west-3. Les noms de régions ESC suivent le format eusc-{pays}-{direction}-{numéro}.
Le domaine DNS : l'ESC utilise le domaine amazonaws.eu au lieu de amazonaws.com. Par exemple : ec2.eusc-de-east-1.amazonaws.eu, s3.eusc-de-east-1.amazonaws.eu. La console est accessible sur console.amazonaws-eusc.eu.
La partition ARN : les ARN utilisent aws-eusc au lieu de aws. Par exemple : arn:aws-eusc:s3:::mon-bucket vs arn:aws:s3:::mon-bucket. Utilisez data "aws_partition" "current" {} dans Terraform pour construire les ARN dynamiquement plutôt que de les hardcoder.
Les AMI : les images machine sont spécifiques à l'ESC et ne sont pas partagées avec la partition commerciale.
Les credentials : les identifiants IAM de la partition commerciale ne fonctionnent pas sur l'ESC et vice versa. Vous devez gérer deux jeux de credentials séparés. Si vous utilisez un pipeline CI/CD, configurez deux fournisseurs OIDC distincts, chacun pointant vers sa partition respective.
Terraform : à partir de Terraform 1.14+ avec le provider AWS 6.x (et OpenTofu 1.11+), les endpoints ESC sont résolus nativement — il suffit de spécifier la région, sans configuration manuelle des endpoints.

Gestion des secrets et du chiffrement : les clés KMS de l'ESC ne sont pas accessibles depuis AWS commercial et vice versa. Les données chiffrées dans un environnement ne peuvent pas être déchiffrées dans l'autre sans mécanismes de re-chiffrement.

Synchronisation des données : si certaines données doivent être partagées entre les deux environnements (par exemple, des données de référence non sensibles), il faut mettre en place des mécanismes de réplication qui respectent les contraintes de souveraineté.

Compétences et formation

L'ESC introduit de nouvelles contraintes que les équipes doivent intégrer :

Comprendre les différences entre ESC et AWS commercial
Adapter les pratiques DevOps aux contraintes de séparation
Former les équipes aux spécificités de la gouvernance souveraine
Mettre à jour les runbooks et procédures opérationnelles

Coûts et optimisation

Le mode hybride a un impact sur les coûts :

Duplication d'infrastructure : certains composants (monitoring, sécurité, réseau) doivent être déployés dans les deux environnements.
Licences : certains outils tiers peuvent nécessiter des licences séparées pour l'ESC.
Personnel : la complexité accrue peut nécessiter des ressources supplémentaires.
Prix de souveraineté : les prix dans l'ESC sont estimés à 10-15 % supérieurs à ceux de la région Francfort (eu-central-1) pour des services comparables, en raison des contraintes opérationnelles supplémentaires liées à la souveraineté.

Facturation et séparation financière

La facturation de l'ESC est entièrement séparée de celle de la partition commerciale. Voici les points clés :

Entité contractuelle distincte : la facturation ESC est gérée par AWS EMEA SARL (Luxembourg), et non par AWS Inc. (Seattle) comme pour la partition commerciale. Cela a des implications pour les équipes procurement et finance.
Facturation en euros : contrairement à la partition commerciale (facturée en USD), l'ESC est facturé en euros.
Savings Plans et Reserved Instances non transférables : les Enterprise Discount Programs (EDP), les Savings Plans et les Reserved Instances achetés dans la partition commerciale ne s'appliquent pas à l'ESC. Vous devez négocier et acheter des engagements séparés pour chaque partition.
Comptes et Organizations séparés : les comptes ESC ayant leur propre Organization, les tags d'allocation de coûts, les budgets et les rapports Cost and Usage Reports sont indépendants. Si votre équipe FinOps suit les dépenses cloud par account ID, elle devra adapter ses processus pour intégrer les deux partitions.

Gouvernance et conformité

La gouvernance d'un environnement hybride nécessite :

Des politiques claires de classification des données (quelles données vont dans l'ESC, lesquelles restent dans AWS commercial)
Des processus de validation pour tout nouveau déploiement
Un suivi continu de la conformité dans les deux environnements
Des audits réguliers pour vérifier que les données sensibles ne « fuient » pas vers l'environnement commercial

Recommandations pratiques

Évaluer son besoin réel de souveraineté

Avant de se lancer dans une migration vers l'ESC, il est essentiel de :

Classifier ses données : toutes les données n'ont pas le même niveau de sensibilité. Seules les données véritablement sensibles (données personnelles critiques, secrets industriels, données régulées) justifient le surcoût et la complexité de l'ESC.
Identifier ses obligations réglementaires : quelles réglementations s'appliquent réellement à votre organisation ? Êtes-vous soumis à la doctrine « Cloud au centre » ? À DORA ? À des exigences sectorielles spécifiques ?
Évaluer le risque géopolitique : quelle est la probabilité réelle que vos données soient impactées par des mécanismes extraterritoriaux ? Ce risque justifie-t-il la complexité supplémentaire ?

Adopter une approche progressive

Plutôt qu'une migration « big bang », privilégiez une approche incrémentale :

Commencez par un workload pilote bien délimité
Validez les patterns d'architecture et les processus opérationnels
Documentez les différences et les pièges rencontrés
Étendez progressivement à d'autres workloads

Investir dans l'automatisation

L'automatisation est la clé pour gérer la complexité du mode hybride :

Utilisez des abstractions dans votre Infrastructure as Code pour gérer les deux environnements
Automatisez les contrôles de conformité (données au bon endroit, accès correctement configurés)
Mettez en place des pipelines de déploiement qui gèrent nativement les deux cibles
Automatisez la détection de drift entre les environnements

Anticiper l'évolution du paysage

Le domaine de la souveraineté cloud évolue rapidement :

Le schéma EUCS va probablement redéfinir les standards au niveau européen
AWS va continuer à enrichir le catalogue de services de l'ESC
Les réglementations nationales et européennes vont continuer à évoluer
De nouvelles offres souveraines vont émerger

Construisez vos architectures de manière à pouvoir évoluer avec ce paysage changeant.

Conclusion

AWS European Sovereign Cloud représente une avancée significative dans la réponse aux enjeux de souveraineté numérique européenne. En proposant une infrastructure physiquement et logiquement séparée, opérée exclusivement par du personnel européen, AWS adresse une grande partie des préoccupations liées à la souveraineté des données.

Cependant, il est crucial de ne pas confondre souveraineté et cybersécurité. L'ESC répond à des enjeux de gouvernance et de contrôle, pas à des problématiques de protection contre les cybermenaces (même si les deux se complètent).

La question de SecNumCloud reste ouverte : pour les organisations soumises à la doctrine française, elle reste incontournable. Pour les autres, l'ESC offre un compromis pragmatique entre souveraineté et accès à l'écosystème AWS.

Le véritable défi réside dans l'opérationnel : gérer un mode hybride entre AWS commercial et l'ESC demande une maturité organisationnelle, des compétences spécifiques et des investissements en automatisation. Les entreprises qui réussiront cette transition seront celles qui auront pris le temps de bien classifier leurs données, d'adopter une approche progressive et d'investir dans l'outillage nécessaire.

La souveraineté numérique n'est pas une destination, c'est un chemin. Et ce chemin passe par des choix éclairés, une compréhension fine des enjeux, et une exécution rigoureuse.

DEV Community