🏠Accueil 📚Certifications 📱Applications Mobiles

🎓Infos examen

✍️Blog 💼Carrières 📊Progrès 📅Calendrier 💬Support

Politique de Confidentialité Conditions d'Utilisation Nous Contacter Politique des Cookies Avertissement Accessibilité DMCA / Droits d'Auteur

Aller au contenu

SAP-C02Guide

Guide - SAP-C02 AWS Certified Solutions Architect Professional

Dernière révision : mai 2026

Une référence concise des modèles d'architecture évalués par l'examen SAP-C02. Lisez de haut en bas ou sautez à une section.

Sections

Concevoir des solutions pour la complexité organisationnelle38 entrées
Concevoir de nouvelles solutions41 entrées
Amélioration continue des solutions existantes35 entrées
Accélérer la migration et la modernisation des charges de travail26 entrées

Concevoir des solutions pour la complexité organisationnelle

Mettre en place un environnement AWS de plus de 100 comptes avec des garde-fous, une journalisation et une identité cohérents dès le premier jour.

AWS Control Tower comme zone d'atterrissage. Account Factory provisionne les comptes; des garde-fous obligatoires et fortement recommandés imposent les bases; des comptes d'archivage de journaux centralisés + d'audit sont créés automatiquement.

Pourquoi: Control Tower codifie le modèle multi-comptes bien architecturé. Construire à partir de zéro via Organizations seul reproduit la même plomberie manuellement.

Besoin d'ajouter des garde-fous et des ressources personnalisés au-delà des valeurs par défaut de Control Tower sur tous les comptes.

Customizations for AWS Control Tower (CfCT). Pipeline de modèles CloudFormation + SCPs déployés via StackSets vers les OUs.

Pourquoi: CfCT étend Control Tower sans interrompre son cycle de vie. Règles Config personnalisées, bases de sécurité, réseau - tout est versionné et rejouable.

Appliquer le chiffrement S3 KMS + corriger automatiquement les buckets non conformes sur 300 comptes en moins de 15 minutes.

Pack de conformité AWS Config à l'échelle de l'organisation via un administrateur délégué. Règle Config + document SSM Automation pour l'auto-remédiation.

Pourquoi: Les packs de conformité déploient les règles Config + la remédiation dans toute l'organisation à partir d'un seul compte. Les approches par Lambda par compte ou SCP uniquement manquent soit la détection en temps réel, soit la remédiation.

Journaux CloudTrail infalsifiables sur tous les comptes conservés 7 ans ; seule l'équipe de sécurité peut les lire.

Trace d'organisation livrant à un bucket S3 de compte de journalisation dédié. Object Lock en mode Conformité avec une rétention de 7 ans. SCP restreignant l'accès au bucket aux rôles IAM de sécurité.

Pourquoi: Object Lock en mode Conformité bloque la suppression même par l'utilisateur root. La trace d'organisation collecte automatiquement tous les comptes. Un compte de journalisation dédié isole le rayon d'impact.

Fédérer 150 comptes à l'AD d'entreprise via SAML ; attribuer des permissions par groupe AD.

IAM Identity Center avec un IdP SAML 2.0 externe. Ensembles de permissions mappés aux groupes AD via le provisionnement SCIM. Affectations de comptes via des groupes.

Pourquoi: Identity Center centralise la fédération sur tous les comptes de l'organisation. Les ensembles de permissions sont réutilisables sur plusieurs comptes ; SCIM maintient l'état des utilisateurs/groupes synchronisé.

Accorder l'accès aux ressources étiquetées avec le centre de coûts de l'utilisateur, s'adaptant à des milliers d'utilisateurs.

Contrôle d'accès basé sur les attributs dans Identity Center. Transmettre les attributs AD via SAML ; les ensembles de permissions référencent `aws:PrincipalTag/CostCenter` par rapport à `aws:ResourceTag/CostCenter`.

Pourquoi: ABAC s'adapte sans modifications de politique par utilisateur. Ajouter un nouveau centre de coûts n'est qu'une balise - pas de réécriture IAM.

Le compte CI/CD assume un rôle de déploiement dans 50 comptes de charge de travail pour exécuter CloudFormation.

Rôle IAM par compte de charge de travail avec une politique de confiance autorisant le principal du compte CI/CD. CI/CD assume via STS AssumeRole. Utiliser un ID externe si un outil tiers initie.

Pourquoi: L'ID externe empêche le problème du député confus. L'enchaînement de rôles limite la session à 1 heure même si le rôle permet plus.

L'équipe réseau centrale possède le VPC ; 30 comptes spoke déploient des charges de travail dans des sous-réseaux partagés.

AWS RAM partage les sous-réseaux avec les comptes participants. Les participants lancent des ressources sans posséder le VPC ; l'équipe centrale conserve le contrôle de la table de routage + NAT.

Pourquoi: Les VPC partagés éliminent la prolifération de VPC par compte + l'IPAM en double. Les participants ne peuvent pas supprimer le VPC ni modifier le routage.

Connecter des VPCs sur 5 régions + sur site avec un routage déterministe et une inspection centrale.

Transit Gateway dans chaque région. Peering TGW pour l'inter-région. VPC d'inspection avec des appliances accessibles via les tables de routage TGW.

Pourquoi: Le peering TGW évite un maillage complet de VPN/peering inter-régions. Les tables de routage par attachement permettent à la sécurité d'inspecter des flux spécifiques sans perturber les autres.

Construire un réseau privé mondial sur les régions + les sites distants avec un routage basé sur des politiques - au-delà du peering TGW.

AWS Cloud WAN. La politique de réseau central en JSON définit de manière déclarative les segments, les régions, les attachements, le partage.

Pourquoi: Cloud WAN remplace la conception TGW "hub-of-hubs" par un seul backbone mondial géré. Les segments offrent une isolation logique entre les régions.

Le DC sur site a besoin d'une liaison 10 Gbps vers AWS avec une résilience aux pannes de liaison et aucune exposition à Internet.

Deux connexions Direct Connect à des emplacements DX séparés. Chacune avec un VIF privé se terminant sur une Direct Connect Gateway → TGW. Basculement BGP entre les connexions.

Pourquoi: Un seul DX est un point de défaillance unique. Différents emplacements DX protègent contre les pannes à l'échelle du site. DX Gateway permet à un VIF d'atteindre plusieurs régions/VPC.

Liaison Direct Connect en tant que principale ; besoin d'un basculement VPN automatique.

VPN Site-à-Site attaché au même TGW que la passerelle DX. AWS préfère les routes BGP DX ; le VPN prend le relais lorsque le BGP DX se retire.

Pourquoi: La préférence de route BGP rend le basculement automatique. Un VPN pré-provisionné évite les délais de provisionnement pendant la panne.

Le régulateur exige un chiffrement de couche 2 entre le site sur site et AWS via Direct Connect.

Direct Connect avec MACsec sur une connexion dédiée 10 Gbps ou 100 Gbps. Clé pré-partagée configurée aux deux extrémités.

Pourquoi: IPsec fonctionne au niveau de la couche 3 ; MACsec chiffre au niveau de la couche 2 à la vitesse de la ligne, satisfaisant les régulateurs qui exigent le chiffrement de la liaison physique.

Le trafic est-ouest entre les VPC doit passer par une inspection avec état.

VPC d'inspection centralisé avec AWS Network Firewall. Les tables de routage TGW dirigent le trafic inter-VPC via le VPC du pare-feu avant d'atteindre la destination.

Pourquoi: Network Firewall est le moteur de règles Suricata géré pour l'inspection avec état. La centralisation évite la prolifération de pare-feu par VPC.

Appliquer automatiquement une configuration WAF + Network Firewall de base sur chaque compte de l'organisation.

AWS Firewall Manager avec administrateur délégué. Les politiques pour WAF, Shield Advanced, Network Firewall, les groupes de sécurité s'appliquent à l'échelle de l'organisation.

Pourquoi: Firewall Manager attache automatiquement les politiques aux nouvelles ressources. Sans cela, chaque compte s'écarte de la base à mesure que des comptes sont ajoutés.

Centraliser les résultats de Security Hub de plus de 100 comptes dans un seul tableau de bord.

Administrateur délégué Security Hub. La région d'agrégation collecte les résultats de tous les comptes membres + toutes les régions activées dans une seule console.

Pourquoi: Sans agrégation, les résultats restent par compte/région. L'administrateur délégué évite d'utiliser le compte de gestion pour les opérations de sécurité.

Activer GuardDuty dans toute l'organisation avec une surveillance centrale et une visibilité de la facturation par compte.

GuardDuty avec administrateur délégué. Activation automatique sur les nouveaux comptes via l'intégration de l'organisation. Résultats agrégés au compte administrateur.

Pourquoi: L'activation automatique comble le fossé des comptes nouvellement créés qui seraient autrement non surveillés.

Découverte continue des PII sur tous les buckets S3 dans 200 comptes.

Macie avec administrateur délégué. Activation automatique à l'échelle de l'organisation. Les résultats sont transmis à Security Hub pour une révision unifiée.

Pourquoi: Macie ne peut pas lire les comptes sans configuration explicite. La configuration au niveau de l'organisation garantit que chaque bucket est inclus.

Enquêter sur un résultat GuardDuty en corrélant les journaux CloudTrail + VPC Flow Logs sur plusieurs comptes.

Administrateur délégué Amazon Detective dans un compte de sécurité dédié. Les comptes membres contribuent au graphe de comportement.

Pourquoi: Detective construit automatiquement le graphe de comportement à partir des VPC Flow Logs, CloudTrail, GuardDuty. L'administrateur délégué (pas le compte de gestion) suit les meilleures pratiques AWS.

Détecter quand une ressource de l'organisation est partagée avec un compte externe.

IAM Access Analyzer avec l'organisation comme zone de confiance, délégué au compte de sécurité. Résultats sur l'accès inter-comptes dans S3, les rôles IAM, les clés KMS, Lambda, SQS, Secrets.

Pourquoi: Access Analyzer utilise la vérification formelle, pas la correspondance de motifs. La zone de confiance au niveau de l'organisation traite les comptes frères comme fiables.

Maximiser l'utilisation des Savings Plans sur 50 comptes avec des modèles de charge de travail non concordants.

Facturation consolidée dans Organizations avec Savings Plans + partage de RI activé. Les plans achetés dans le compte payeur sont partagés à l'échelle de l'organisation.

Pourquoi: Le partage mutualise l'utilisation afin que la capacité inutilisée dans un compte compense la demande dans un autre. Désactiver le partage uniquement pour l'isolation de l'allocation des coûts.

Permettre aux équipes d'applications de s'auto-approvisionner en infrastructure approuvée (VPC, RDS) sans droits d'administrateur IAM.

Portfolios AWS Service Catalog. Produits CloudFormation pré-approuvés avec des contraintes. Partager les portfolios entre les comptes via Organizations.

Pourquoi: Fournit un self-service encadré. Les politiques de contrainte masquent la complexité (types d'instances, balises) tandis que les produits portent la portée IAM pour le lancement.

Appliquer des balises obligatoires `CostCenter` et `Environment` de manière cohérente dans toute l'organisation.

Politiques de balises Organizations attachées aux OUs. Définir les valeurs autorisées + la capitalisation. Combiner avec la règle Config `required-tags` pour l'application.

Pourquoi: Les politiques de balises valident ; les règles Config détectent la non-conformité. Les SCPs peuvent refuser la création de ressources sans balises.

Empêcher les actions de l'utilisateur root dans les comptes membres (exigence de conformité).

SCP refusant toute action lorsque `aws:PrincipalArn` correspond à `arn:aws:iam::*:root`.

Pourquoi: Les SCPs s'appliquent même à l'utilisateur root. IAM ne peut pas refuser l'utilisateur root. Les actions root ne devraient jamais être nécessaires, sauf pour la récupération de compte.

Imposer des plans AWS Backup sur tous les comptes avec une rétention cohérente.

Politiques de sauvegarde Organizations attachées aux OUs. Définir les plans + les critères de sélection ; appliquer automatiquement aux ressources concernées.

Pourquoi: La duplication des plans de sauvegarde par compte entraîne une dérive. Les politiques d'organisation imposent une source unique de vérité.

Plus de 100 VPC, chacun avec une NAT Gateway, gonflent les coûts. Désir d'un point de sortie unique.

VPC de sortie centralisé avec NAT Gateway. Les VPC spoke acheminent 0.0.0.0/0 → TGW → VPC de sortie → NAT.

Pourquoi: Une seule NAT au lieu de 100 réduit considérablement les coûts. Les règles de transfert de données inter-régions de TGW s'appliquent, il faut donc concevoir soigneusement le trafic inter-régions.

Les instances EC2 dans le VPC doivent résoudre les noms d'hôtes sur site ; le site sur site doit résoudre le DNS privé du VPC.

Points de terminaison d'entrée + de sortie du Route 53 Resolver. Les règles de transfert envoient les requêtes `corp.local` sur site ; le DNS sur site transfère `*.compute.internal` au point de terminaison d'entrée.

Pourquoi: Les points de terminaison Resolver sont des ENI HA dans deux zones de disponibilité. Le transfert conditionnel offre une résolution bidirectionnelle sans exposer le DNS à Internet.

Les services internes ont besoin d'un DNS résolvable à partir de plusieurs VPCs sur plusieurs comptes.

Zone hébergée privée Route 53 associée à des VPC de plusieurs comptes via une association de VPC inter-comptes.

Pourquoi: Une seule PHZ partagée via l'association inter-comptes est préférable aux doublons par VPC qui dérivent.

Les charges de travail Windows nécessitent un AD complet avec une relation de confiance avec la forêt sur site.

AWS Managed Microsoft AD. Établir une relation de confiance bilatérale avec l'AD sur site via DX/VPN.

Pourquoi: Managed AD est un véritable Microsoft AD (DCs dans deux AZs, schéma extensible). AD Connector ne fait que proxy ; Simple AD manque de support de confiance.

Les applications dans AWS doivent s'authentifier auprès d'un AD sur site existant sans répliquer les identités.

AD Connector. Agit comme un proxy du VPC vers l'AD sur site via DX/VPN.

Pourquoi: Aucune donnée d'annuaire ne quitte le site sur site ; les requêtes d'authentification transitent. La latence dépend de la liaison.

Une charge de travail sensible à la latence doit s'exécuter dans un centre de données spécifique mais être gérée via les API AWS.

Rack/serveur AWS Outposts. Les mêmes API AWS (EC2, EBS, ECS, EKS, sous-ensemble RDS) s'exécutent sur site. Se connecte à une région parente.

Pourquoi: Pour une latence locale inférieure à la milliseconde vers les systèmes sur site ou la résidence des données là où les Local Zones ne couvrent pas. Mono-AZ - coupler deux Outposts pour la HA.

Réduire la latence pour les utilisateurs finaux dans une métropole éloignée de la région parente.

AWS Local Zones. Déployer le calcul, le stockage près des centres de population ; le plan de données est acheminé vers la région parente pour le plan de contrôle.

Pourquoi: Les Local Zones hébergent EC2/EBS/RDS/ELB près des grandes villes. Moins cher que les Outposts lorsque la pleine propriété du DC n'est pas nécessaire.

L'application nécessite une latence de quelques millisecondes pour les utilisateurs mobiles sur 5G.

Zones AWS Wavelength dans les réseaux 5G des opérateurs. Déployer EC2/EBS en périphérie de l'opérateur ; le trafic reste sur le réseau du fournisseur mobile.

Pourquoi: Élimine entièrement le saut sur l'Internet public pour les cas d'utilisation 5G comme la réalité augmentée/virtuelle, l'inférence en temps réel, les jeux.

L'auditeur de conformité a besoin de la configuration actuelle de chaque ressource dans toute l'organisation.

Agrégateur AWS Config dans le compte d'audit, avec une portée sur l'ensemble de l'organisation et toutes les régions.

Pourquoi: L'agrégateur Config est la vue en lecture seule à l'échelle de l'organisation. Les agrégateurs n'activent pas Config dans les comptes membres - c'est une action distincte.

Les journaux CloudWatch de 50 comptes doivent atterrir dans une archive S3 unique pour l'ingestion SIEM.

Filtres d'abonnement dans chaque compte → Kinesis Data Stream / Firehose inter-comptes → S3 dans le compte de journalisation.

Pourquoi: Les filtres d'abonnement permettent aux groupes de journaux de pousser en temps réel. Firehose gère le traitement par lots, la compression, le partitionnement S3.

Générer des rapports de preuves pour SOC 2, PCI, HIPAA en continu sur toute l'organisation.

AWS Audit Manager. Les cadres pré-construits mappent les contrôles aux preuves AWS (Config, CloudTrail, Security Hub). Administrateur délégué dans le compte de sécurité.

Pourquoi: Audit Manager collecte automatiquement les preuves par contrôle. Permet d'économiser des centaines d'heures de collecte manuelle de captures d'écran par cycle d'audit.

Déployer un rôle IAM de base sur tous les comptes existants et futurs de l'organisation.

CloudFormation StackSets avec des permissions gérées par le service + déploiement automatique sur les nouveaux comptes. Cibler l'ensemble de l'organisation ou des OUs spécifiques.

Pourquoi: Les StackSets auto-gérés nécessitent IAM dans chaque compte. Les StackSets gérés par le service exploitent les permissions de l'organisation et sont la valeur par défaut pour Organizations.

Après des mois d'exécution de StackSets, soupçonner que des modifications manuelles ont causé une dérive.

Initier la détection de dérive sur le StackSet. Examiner les résultats par instance de stack sans modifier les ressources.

Pourquoi: La détection de dérive compare la configuration des ressources en direct au modèle. Le redéploiement de StackSets pour "corriger" la dérive peut entraîner des modifications involontaires.

Concevoir de nouvelles solutions

Charge de travail de base de données variable et en rafale - les besoins en capacité varient 10 fois en quelques minutes.

Aurora Serverless v2. Définir les ACU min/max ; Aurora se met à l'échelle en quelques secondes sans interruption de connexion.

Pourquoi: v2 s'adapte en ajoutant de la capacité à l'instance existante - pas de basculement. Aurora provisionné ne peut pas s'adapter aussi vite ; Serverless v1 s'adapte plus lentement et interrompt les connexions.

Application globale avec un RPO <1s et un RTO <1min pour le basculement de base de données inter-régions.

Aurora Global Database. Réplication basée sur le stockage, décalage de réplication typique <1s. Promouvoir le secondaire en quelques secondes.

Pourquoi: Global DB transfère des pages, pas des transactions - inter-région en moins d'une seconde. Les réplicas de lecture inter-régions via la réplication logique ne peuvent pas égaler cela.

Reproduire une base de données de production pour des tests sans payer pour une copie complète.

Clonage Aurora. Copie sur écriture - le clone initial est gratuit ; seules les pages modifiées sont facturées.

Pourquoi: Les clones sont ponctuels, instantanés, isolés. Snapshot+restauration prend des heures et facture le stockage complet immédiatement.

Récupérer d'une erreur logique (DROP TABLE en production) en quelques minutes, pas en heures.

Aurora MySQL Backtrack. Rembobine le cluster sur place à un point antérieur dans le temps sans restaurer à partir d'une sauvegarde.

Pourquoi: Backtrack est sur place et rapide. Les restaurations PITR créent un nouveau cluster - plus lent et nécessite une bascule d'application.

Acheminer les requêtes de reporting vers des instances de lecture spécifiques avec une mémoire plus grande.

Points de terminaison personnalisés Aurora. Définir un point de terminaison pointant vers un sous-ensemble de lecteurs (ceux avec une plus grande mémoire).

Pourquoi: Le point de terminaison de lecture par défaut distribue les requêtes en round-robin à tous les lecteurs. Les points de terminaison personnalisés partitionnent le cluster par type de charge de travail.

La table DynamoDB subit des pics de partitions chaudes qui limitent certaines lectures/écritures.

Provisionné avec auto-scaling + capacité adaptative (automatique). Redessiner la clé de partition si une seule clé est le hotspot.

Pourquoi: La capacité adaptative réalloue le débit entre les partitions sans action. Mais si une seule clé est chaude, seule la refonte du schéma (clé composite, sharding d'écriture) aide.

Effet secondaire sur chaque écriture DynamoDB - pousser vers OpenSearch pour l'indexation de recherche.

DynamoDB Streams + déclencheur Lambda. Lambda regroupe les enregistrements du flux et écrit vers OpenSearch.

Pourquoi: Streams capture les changements au niveau des éléments pendant 24h. Modèle de déclencheur natif - un adaptateur Kinesis Data Streams existe pour une rétention/analyse plus longue.

Une écriture en deux phases sur plusieurs éléments DynamoDB doit être atomique.

TransactWriteItems / TransactGetItems. Sémantique ACID sur jusqu'à 100 éléments.

Pourquoi: Les transactions natives évitent la complexité du saga distribué. Le coût est de 2x la capacité normale par élément - à utiliser uniquement lorsque l'atomicité est requise.

Migrer un cluster MongoDB auto-hébergé vers un service géré en préservant l'API.

Amazon DocumentDB. API compatible MongoDB. Utiliser mongodump/mongorestore ou DMS pour la migration.

Pourquoi: DocumentDB est compatible API avec MongoDB 4.0/5.0 (la plupart des opérateurs, pas tous). Vérifier la compatibilité des pilotes/fonctionnalités avant de s'engager.

Le moteur de recommandation doit parcourir un graphe social de 100 millions de nœuds.

Amazon Neptune. Graphe de propriétés (Gremlin) ou RDF (SPARQL).

Pourquoi: Base de données de graphes conçue spécifiquement. La modélisation des relations dans DynamoDB ou RDS est possible mais les performances des requêtes se dégradent avec la profondeur des sauts.

Flotte IoT émettant 10 millions de points de données de séries chronologiques/sec avec une rétention à fréquence mixte.

Amazon Timestream. Stockage en mémoire (récent), stockage magnétique (historique) - hiérarchisation automatique.

Pourquoi: Séries chronologiques conçues spécifiquement - la mise à l'échelle de DynamoDB/RDS serait prohibitive à ce rythme. La hiérarchisation de rétention intégrée réduit le coût de stockage.

Le grand livre bancaire nécessite une vérification cryptographique de chaque modification d'enregistrement.

Amazon QLDB. Journal immuable et vérifiable cryptographiquement. Utiliser l'exportation de digest SHA-256 pour les preuves.

Pourquoi: QLDB est un grand livre conçu spécifiquement. DynamoDB Streams fournit l'historique des changements mais pas de chaînage cryptographique intégré.

Charge de travail d'analyse de journaux avec des pics imprévisibles et des opérations sans intervention.

Amazon OpenSearch Serverless. Calcul/stockage découplés ; mise à l'échelle automatique des OCUs.

Pourquoi: Pas de dimensionnement de cluster ou de gestion de shard. Pour les charges de travail prévisibles et soutenues, les domaines provisionnés sont moins chers.

Analyse à l'échelle du pétaoctet avec calcul élastique et partage de données entre les équipes.

Nœuds Redshift RA3 avec stockage géré. Partage de données inter-clusters (sans copie).

Pourquoi: RA3 sépare le calcul du stockage - scalez chacun indépendamment. Le partage de données élimine l'ETL entre les clusters des équipes.

Cluster Redshift existant + data lake S3 - interroger S3 depuis Redshift, ou utiliser Athena ?

Redshift Spectrum lorsque des jointures entre les tables du cluster et les données S3 sont nécessaires. Athena lorsque l'ad-hoc est entièrement serverless sur S3 uniquement.

Pourquoi: Spectrum exécute les requêtes S3 via le calcul Redshift. Athena facture par To scanné. Choisissez en fonction de l'endroit où se trouvent les données dominantes.

Différentes équipes ont besoin d'une visibilité différente par ligne/colonne sur les mêmes tables Glue Catalog.

AWS Lake Formation avec filtres au niveau des lignes + des colonnes + des cellules. Accorder via les balises LF.

Pourquoi: Les politiques IAM/S3 ne peuvent pas faire de filtrage au niveau des lignes. Lake Formation applique un accès granulaire via les métadonnées Glue Catalog + les consommateurs Athena/Redshift Spectrum/EMR.

Job Glue quotidien traitant des données incrémentielles ; ne doit pas retraiter les fichiers d'hier.

Marque-pages de job Glue. Suivre les clés S3 / lignes de base de données traitées ; reprendre à partir du dernier point de contrôle réussi.

Pourquoi: Les marque-pages évitent le traitement en double sans suivi manuel de l'état. Désactiver pour les exécutions de retraitement complet.

Choisir entre Kafka géré et Kinesis Data Streams pour le streaming d'événements.

MSK pour les clients/écosystème Kafka existants. Kinesis pour une intégration AWS étroite (déclencheurs Lambda, Firehose, KCL) et une option serverless.

Pourquoi: Les deux diffusent durablement avec relecture. MSK préserve l'API et l'écosystème Kafka ; Kinesis coûte moins cher pour les petits flux et s'intègre nativement.

Débit Kafka variable ; souhait d'une gestion de cluster sans intervention.

MSK Serverless. Mise à l'échelle automatique des partitions et du débit ; paiement par partition + données.

Pourquoi: Pas de dimensionnement de broker. Pour un débit élevé soutenu, MSK provisionné est moins cher.

Connecter SQS → filtre → Step Functions sans écrire de Lambda de "colle".

EventBridge Pipes. Source → filtre optionnel → enrichissement optionnel → cible.

Pourquoi: Remplace une Lambda typique utilisée comme "colle". Réduit le code, le coût et la surface opérationnelle.

Rejouer les événements de la semaine dernière via un nouveau consommateur sans les réémettre de la source.

Archive + relecture EventBridge. L'archive capture les événements correspondants ; les rejoue à une cible plus tard.

Pourquoi: La relecture intégrée évite d'avoir besoin d'un stockage d'événements séparé. Utile pour la récupération d'incidents et l'intégration de nouveaux consommateurs.

Des centaines de producteurs émettent des événements ; les consommateurs ont besoin de liaisons typées.

Registre de schémas EventBridge avec auto-découverte. Générer des liaisons de code fortement typées (Java, Python, TypeScript).

Pourquoi: La découverte apprend les schémas à partir des événements observés. Les liaisons offrent une sécurité au moment de la compilation.

Orchestration facturée en moins d'une seconde de workflows courts et à grand volume (>100k/sec).

Workflows Step Functions Express. Facturation par milliseconde d'exécution ; 5 minutes maximum.

Pourquoi: Les workflows Standard sont durables + suivis historiquement, facturés par transition d'état. Express échange la piste d'audit contre le coût sur les flux de courte durée.

Traiter 10 millions d'objets S3 en parallèle via une Step Function.

État Distributed Map. Exécutions enfant concurrentes jusqu'à 10 000 en parallèle ; lit la source directement depuis S3.

Pourquoi: La Map Inline est limitée à 40 exécutions parallèles. La Map Distribuée s'adapte aux jobs de la taille d'un bucket S3 sans atteindre les quotas de service.

La file d'attente FIFO nécessite un débit >300 messages/sec.

SQS FIFO avec mode haut débit activé. Jusqu'à 70k messages/sec par API par région ; partitionner par `MessageGroupId`.

Pourquoi: Le FIFO standard est limité à 300 messages/sec sans traitement par lots. Le mode haut débit partitionne l'ordonnancement par ID de groupe.

Plusieurs consommateurs ont chacun besoin du débit de lecture complet sur le même flux Kinesis.

Enhanced Fan-Out (EFO). Chaque consommateur obtient un canal dédié de 2 Mo/s/shard via push HTTP/2.

Pourquoi: Le polling par défaut partage la limite de 2 Mo/s/shard entre les consommateurs. EFO élimine la contention à un coût plus élevé.

Firehose vers S3 ; les requêtes du data lake scannent trop car le partitionnement est par temps d'ingestion, et non par temps d'événement.

Partitionnement dynamique Firehose. Extraire le temps de l'événement / l'ID du locataire du JSON ; écrire dans le préfixe S3 `year=YYYY/month=MM/tenant=X/`.

Pourquoi: L'élagage de partition Athena/Spectrum sur le temps d'événement réduit considérablement le coût et la latence du scan.

Un client mobile/web a besoin de mises à jour en temps réel et d'une récupération sélective des champs.

AWS AppSync (GraphQL) avec abonnements. Basé sur WebSocket.

Pourquoi: Les clients GraphQL récupèrent uniquement les champs demandés et s'abonnent aux deltas. REST/HTTP API Gateway force une sur-récupération et un polling.

L'API interne ne doit pas être accessible depuis l'Internet public.

Point de terminaison privé API Gateway via un point de terminaison VPC d'interface. La politique de ressource restreint l'accès à des VPCs spécifiques.

Pourquoi: Les API privées ne sont accessibles que depuis le VPC + les réseaux connectés. Les API publiques nécessitent WAF + authentification pour être sécurisées.

Verrouiller l'origine S3 afin que seul CloudFront puisse la lire.

Origin Access Control (OAC). Remplace l'OAI hérité ; prend en charge SSE-KMS et toutes les fonctionnalités S3.

Pourquoi: OAI ne prend pas en charge les objets SSE-KMS. AWS recommande OAC pour toutes les nouvelles distributions.

Limiter dans le temps l'accès à des vidéos payantes spécifiques dans S3.

URLs signées CloudFront (par URL) ou cookies signés (plusieurs URLs). Le groupe de clés de confiance signe les requêtes.

Pourquoi: Les URLs pré-signées S3 contournent la mise en cache de CloudFront. Les URLs signées CloudFront mettent en cache en périphérie ET restreignent l'accès.

Transformation légère des requêtes des spectateurs : réécriture d'en-têtes, redirection, routage A/B.

Fonctions CloudFront. JS, latence sub-milliseconde, tous les POPs de périphérie.

Pourquoi: Lambda@Edge est une implémentation complète Node/Python en périphérie régionale - plus lourde et plus chère. Les fonctions sont 10 fois moins chères pour les manipulations simples.

Exécuter des charges de travail multi-locataires non fiables dans EKS avec une forte isolation.

Isolation par pod EKS Fargate. Chaque pod s'exécute dans une micro-VM dédiée.

Pourquoi: Les groupes de nœuds gérés partagent le noyau - l'escalade de privilèges traverse les locataires. L'isolation du noyau Fargate est la plus forte dans EKS.

Latence d'autoscaling du cluster EKS trop lente ; prolifération des types d'instances des groupes de nœuds.

Karpenter. Le provisionneur choisit les types d'instances juste à temps en fonction des exigences des pods en attente.

Pourquoi: Cluster Autoscaler met à l'échelle des ASGs prédéfinis, lent et limité. Karpenter met à l'échelle des EC2 arbitraires en quelques secondes avec diversification.

Le pod EKS a besoin d'un IAM à privilège minimum (éviter le partage de rôle d'instance de nœud).

Rôles IAM pour les comptes de service (IRSA) via le fournisseur OIDC. Annoter le ServiceAccount avec l'ARN du rôle.

Pourquoi: EKS Pod Identity est la nouvelle alternative - modèle de confiance plus simple. IRSA est mature et fonctionne sur toutes les régions.

Les démarrages de tâches ECS-on-EC2 prennent 5 à 7 minutes lors de la mise à l'échelle - besoin de moins de 60 secondes.

ECS Capacity Provider avec une cible de mise à l'échelle gérée d'environ 80% sur `CapacityProviderReservation`. Maintenir un tampon inactif.

Pourquoi: Un tampon réservé signifie que les nouvelles tâches atterrissent instantanément sur la capacité existante pendant que l'ASG lance des remplacements.

Lambda déclenchée par SQS mais seulement 5% des messages correspondent - invocations gaspillées.

Mappage de source d'événement avec des critères de filtre. Lambda n'est invoquée que pour les messages correspondants.

Pourquoi: Le filtre pré-Lambda évite le coût par invocation sur les messages non pertinents. Le filtrage est pris en charge sur SQS, Kinesis, DynamoDB, MQ, Kafka.

Une application de production a besoin d'un point de terminaison LLM avec une faible charge opérationnelle.

Amazon Bedrock pour les modèles de fondation gérés (Claude, Llama, Titan). SageMaker uniquement lorsque vous devez héberger des modèles personnalisés ou des modèles open-weights finement ajustés.

Pourquoi: Bedrock est uniquement via API - pas d'infra. SageMaker est une plateforme ML complète - choisissez-le lorsque vous maîtrisez le cycle de vie de l'entraînement/fine-tuning.

Choisir une IA gérée pour la vision / le PNL sans entraîner de modèle.

Rekognition (étiquettes image/vidéo, visages, modération de contenu). Comprehend (sentiment, entités, langues, détection PII). Translate. Polly. Transcribe.

Pourquoi: Les services d'IA pré-entraînés d'AWS sautent tout le cycle de vie ML pour les tâches courantes. Utilisez SageMaker uniquement lorsque les solutions prêtes à l'emploi ne conviennent pas.

L'application web prend en charge l'e-mail/mot de passe + Google + Apple + SSO d'entreprise SAML.

Cognito User Pool avec UI hébergée. Configurer les IdPs OIDC + SAML. L'application reçoit le JWT Cognito.

Pourquoi: Le User Pool agrège les IdPs en un seul jeton. L'Identity Pool ne fait qu'échanger des jetons contre des identifiants AWS - pour l'accès à l'API AWS, pas pour l'authentification.

Tables globales DynamoDB avec écritures simultanées sur la même clé dans deux régions.

La dernière écriture l'emporte par horodatage. L'application conçoit des écritures idempotentes ou partitionne les écritures par région.

Pourquoi: La réplication GT est multi-maître asynchrone. La résolution des conflits est basée sur l'horodatage - les applications doivent tolérer la cohérence éventuelle.

Amélioration continue des solutions existantes

Flotte EC2 sur-provisionnée dans toute l'organisation ; besoin de recommandations de dimensionnement automatisées.

AWS Compute Optimizer activé au niveau de l'organisation. Examiner les recommandations par rapport aux fenêtres d'utilisation ; exporter vers S3 pour le suivi.

Pourquoi: Compute Optimizer utilise le ML sur les métriques CloudWatch. Le dimensionnement manuel manque les signaux de forme de la charge de travail.

Détecter les pics de coûts inattendus en quelques heures, pas en fin de mois.

AWS Cost Anomaly Detection. Le ML surveille les dépenses par service / par compte ; alerte via SNS / e-mail lorsque le seuil est dépassé.

Pourquoi: Les budgets se déclenchent sur les seuils prévus. La détection d'anomalies détecte les surprises (clé compromise, job d'entraînement incontrôlé) des jours/semaines plus tôt.

Lorsque le compte atteint 100 % de son budget mensuel, arrêter automatiquement les ressources non essentielles.

Actions de budget AWS. Appliquer une politique IAM restrictive + déclencher une Lambda via SNS pour arrêter les instances EC2/RDS non essentielles.

Pourquoi: Les actions de budget passent de "alerte uniquement" à "appliquer". Associez-les à la détection d'anomalies de coût pour détecter les dépenses non budgétisées.

Visibilité à l'échelle de l'organisation sur les opportunités d'optimisation des coûts S3.

S3 Storage Lens avec métriques avancées + portée à l'échelle de l'organisation. Met en évidence les candidats pour le stockage froid, les opportunités de stockage intelligent, les téléchargements multipartie abandonnés.

Pourquoi: Le niveau gratuit couvre les métriques de base ; le niveau avancé affiche la réplication, l'activité, les recommandations d'optimisation. Centralisé dans le compte d'audit/sécurité.

La facture S3 continue d'augmenter malgré les opérations de suppression.

Règle de cycle de vie pour annuler les `téléchargements multipartie incomplets` après 7 jours. Inspecter avec `s3api list-multipart-uploads`.

Pourquoi: Les téléchargements échoués laissent des parties qui sont facturées comme du stockage mais sont invisibles dans la liste de la console. Fuite de coût courante.

Données d'archive froide accessibles au maximum une fois par trimestre.

S3 Glacier Flexible Retrieval (restauration en 1 à 12 heures). Pour les données "jamais consultées", utiliser Deep Archive (récupération en 12 heures, coût le plus bas).

Pourquoi: Standard-IA maintient un accès en millisecondes ; les niveaux Glacier échangent le temps d'accès contre une réduction de coût d'environ 80 à 95 %.

Réduire le coût de sortie de la NAT Gateway pour le trafic S3 + DynamoDB.

Points de terminaison VPC Gateway pour S3 + DynamoDB (gratuits). Acheminer le trafic via le point de terminaison, contourner la NAT.

Pourquoi: NAT facture par Go ; les points de terminaison Gateway sont gratuits. Pour les autres services AWS, les points de terminaison d'interface réduisent mais n'éliminent pas le coût.

Charge de travail bavarde entre les AZs ; le coût de transfert de données domine la facture.

Co-localiser les microservices dans la même AZ lorsque possible. Utiliser VPC Lattice ou un maillage de services avec routage par affinité AZ.

Pourquoi: Le transfert inter-AZ coûte 0,01 $/Go dans chaque direction. Le bavardage des microservices à l'échelle s'additionne. Échanger une partie de la HA contre des coûts là où 99,95 % suffisent.

Le trafic de sortie vers Internet est le poste de dépense le plus important.

Fronter tout avec CloudFront. La sortie CloudFront vers Internet est moins chère que la sortie directe EC2/ALB.

Pourquoi: La tarification de sortie CloudFront est échelonnée et significativement inférieure à la sortie régionale. La mise en cache réduit davantage la sortie d'origine.

Choisir entre Compute Savings Plan vs EC2 Instance Savings Plan vs Reserved Instances.

Compute SP : le plus flexible (n'importe quelle région, famille, OS) - réduction légèrement moindre. EC2 Instance SP : région bloquée par famille - réduction plus importante. RI : cas rares nécessitant une réservation de capacité.

Pourquoi: Compute SP couvre Lambda + Fargate + EC2. Les RI ne l'emportent sur les SP que lorsque la réservation de capacité est importante ; dans la plupart des cas, les SP sont plus avantageux.

Flotte de traitement par lots sans état fonctionnant sur Spot - taux d'interruption trop élevé.

Spot Fleet avec stratégie optimisée pour la capacité sur de nombreux types d'instances + AZs.

Pourquoi: La stratégie au prix le plus bas se concentre sur un seul pool - forte interruption. La stratégie optimisée pour la capacité choisit les pools avec la capacité disponible la plus profonde.

Réduire le coût de calcul sur la couche web sans état d'environ 20% sans réécrire.

Migrer vers Graviton (ARM) - `c7g`, `m7g`, Lambda ARM, Aurora Graviton. Test de compatibilité pour les binaires compilés.

Pourquoi: Graviton offre une amélioration de ~20% du rapport prix-performance pour la plupart des charges de travail. Java/Python/Node "fonctionnent simplement" ; le code natif peut nécessiter une recompilation.

Réduire les coûts d'un service Fargate de longue durée mais tolérant aux interruptions.

Fargate Spot via une stratégie de fournisseur de capacité. Mélanger Spot + à la demande pour les tâches HA.

Pourquoi: Fargate Spot est environ 70% moins cher. Les tâches reçoivent un avertissement de 2 minutes avant la terminaison - à coupler avec un vidage gracieux.

Le coût de stockage des journaux CloudWatch augmente de mois en mois.

Définir la rétention par groupe de journaux (par défaut, pour toujours). Pour le long terme, exporter vers S3 + supprimer dans CW. Utiliser la classe Logs Infrequent Access.

Pourquoi: CW Logs coûte 0,03 $/Go d'ingestion + stockage pour toujours. S3 Standard-IA à 0,0125 $/Go est moins cher pour l'accès d'archivage.

Remplacer la surveillance fragmentée par une observabilité unifiée sur tous les services.

CloudWatch ServiceLens pour la carte de service ; X-Ray pour les traces ; CloudWatch Logs Insights pour l'ad-hoc ; Container Insights pour ECS/EKS ; RUM pour le navigateur ; Synthetics pour les canaries.

Pourquoi: La pile native AWS évite les agents par hôte. Associer avec l'OpenTelemetry SDK pour la portabilité.

Tracer une requête à travers des services dans 5 comptes.

Observabilité inter-comptes X-Ray. Les comptes sources partagent les traces avec le compte de surveillance central via OAM.

Pourquoi: Sans OAM, les traces sont fragmentées par compte. L'agrégation inter-comptes centralise la vue du chemin de requête.

Afficher les métriques + journaux + traces de plusieurs comptes dans une seule console CloudWatch.

CloudWatch Observability Access Manager (OAM). Les comptes sources se lient à un compte de surveillance via un "sink" + un "link".

Pourquoi: OAM est le tissu d'observabilité multi-comptes canonique. Élimine le saut de console par compte.

Lenteur du cluster Aurora - identifier le top SQL par événement d'attente.

Performance Insights activé sur le cluster. Top SQL par charge + analyse d'attente sans vidage du journal de requêtes.

Pourquoi: PI échantillonne les événements d'attente avec une faible surcharge. Les métriques CloudWatch vous indiquent que quelque chose est lent, PI vous dit quoi.

Détecter automatiquement les anomalies dans DynamoDB / RDS / Lambda / ECS sans écrire de seuils d'alarme.

Amazon DevOps Guru. Détection d'anomalies basée sur le ML sur les métriques opérationnelles + événements corrélés.

Pourquoi: Les seuils statiques manquent les modes rares. DevOps Guru apprend les bases et alerte sur les déviations par rapport à la normale.

Patch de 5 000 instances EC2 selon un calendrier sans scripts par instance.

SSM Patch Manager avec bases de correctifs + fenêtres de maintenance. Ciblage basé sur les balises ; approbation automatique des correctifs de sécurité après N jours.

Pourquoi: Patch Manager centralise l'ensemble du cycle de vie des correctifs. Les scripts auto-gérés dérivent et manquent les nouvelles instances.

Corriger automatiquement les échecs de règles Config (par exemple, SG ouvert) sans approbation humaine.

Action de remédiation Config invoquant un document SSM Automation. `AWS-DisablePublicAccessForSecurityGroup` etc. pré-construits.

Pourquoi: Config détecte ; SSM Automation agit. Boucle plus serrée que SNS → humain → ticket.

Le pipeline "golden" d'images AMI/conteneur doit être reproductible et à jour des correctifs.

Pipeline EC2 Image Builder. AMI source → recette (composants) → test → distribuer aux régions/comptes.

Pourquoi: Remplace les scripts Packer ad-hoc par un cycle de vie géré. Planifier les reconstructions pour la mise à jour mensuelle des correctifs.

Analyse continue des CVE sur les images EC2 + ECR + Lambda.

Amazon Inspector v2 avec activation à l'échelle de l'organisation. Les résultats sont transmis à Security Hub.

Pourquoi: Inspector v2 couvre EC2 + images de conteneurs + dépendances Lambda dans un seul service. La correspondance manuelle de CVE est impossible à l'échelle.

Valider qu'une application multi-tiers peut respecter un RTO d'1 heure / un RPO de 15 minutes.

AWS Resilience Hub. Définir la politique → évaluer l'application → recommandations + runbooks automatisés.

Pourquoi: Resilience Hub formalise les revendications RTO/RPO avec des tests concrets. Les runbooks manuels de DR dérivent.

Tester que l'auto-scaling et le basculement fonctionnent en cas de défaillances réelles, et non supposées.

AWS Fault Injection Service (FIS). Expériences modélisées - tuer des instances, limiter les API, injecter de la latence. Exécuter pendant les Game Days.

Pourquoi: Ingénierie du chaos en tant que service. Une défaillance réelle expose des hypothèses fragiles ; la lecture de runbooks ne le fait pas.

Basculement multi-régions - vérification automatisée de la préparation + évacuation zonale.

Route 53 Application Recovery Controller. Vérifications de préparation + contrôles de routage pour le basculement basé sur les cellules.

Pourquoi: Les vérifications de santé Route 53 simples évaluent les points de terminaison. ARC ajoute des plans de contrôle actifs/passifs pour un basculement explicite et audité.

Mettre à niveau la version majeure de RDS avec capacité de restauration.

Déploiements Bleus/Verts RDS. Lancer un clone vert avec la nouvelle version ; rejouer le binlog ; basculer en moins d'1 minute.

Pourquoi: Une mise à niveau majeure sur place est irréversible. Blue/Green maintient l'ancienne base de données en direct jusqu'à ce que la bascule réussisse.

Réduire le rayon d'impact des mauvais déploiements avec un rollback automatique.

CodeDeploy avec configuration Canary (par exemple, `CodeDeployDefault.ECSCanary10Percent5Minutes`). L'alarme CloudWatch déclenche un rollback.

Pourquoi: Canary contient la panne à 10% pendant 5 minutes. Le déploiement "tout en une fois" a un impact maximal ; le déploiement progressif propage mais n'a pas de porte basée sur le trafic.

Fonctions Lambda sur-provisionnées en mémoire.

Compute Optimizer pour Lambda. Recommandations d'ajustement de la mémoire à partir des profils d'invocation.

Pourquoi: La machine à états AWS Lambda Power Tuning est l'alternative - Compute Optimizer est sans intervention.

Générer une politique IAM à privilège minimum à partir de l'activité CloudTrail observée.

Génération de politique IAM Access Analyzer. Analyse CloudTrail pour le rôle ; émet une politique des seules actions utilisées.

Pourquoi: Mieux que de faire manuellement `iam:Get*` etc. Utilisez la politique générée comme point de départ, puis révisez.

Connexion échouant d'EC2 à RDS - trouver pourquoi sans captures de paquets.

VPC Reachability Analyzer. Analyse statique des tables de routage, SGs, NACLs, NAT, peering. Retourne le bloqueur.

Pourquoi: Plus rapide que tcpdump. Identifie la configuration spécifique (quelle règle SG, quel déni NACL).

Auditer quels chemins depuis Internet peuvent atteindre les ressources internes.

VPC Network Access Analyzer. Les expressions de portée décrivent les chemins interdits (par exemple, internet → couche DB). Retourne les chemins correspondants.

Pourquoi: Reachability Analyzer est point à point ; Network Access Analyzer est la conformité à l'échelle de la portée.

Gains rapides sur les coûts à l'échelle de l'organisation.

Vérifications d'optimisation des coûts de Trusted Advisor (nécessite le support Business/Enterprise). ELBs inactifs, EC2 sous-utilisés, EIPs inutilisées, utilisation des RI.

Pourquoi: Le niveau gratuit de TA est limité ; Business+ débloque toutes les vérifications. La vue d'organisation avec administrateur délégué affiche les résultats agrégés.

Les tempêtes de connexions Lambda → RDS épuisent les connexions à la base de données.

RDS Proxy. Pool de connexions entre Lambda et RDS/Aurora. Basculement plus rapide (réduction d'environ 66%).

Pourquoi: La concurrence de Lambda crée une connexion par invocation dans le pire des cas. Le proxy multiplexe sur un petit pool.

Taux de cache-miss de contenu "longue traîne" trop élevé à l'origine - origine sous charge.

CloudFront Origin Shield dans une région proche de l'origine. Déduplique les requêtes sur les périphéries avant d'atteindre l'origine.

Pourquoi: Sans Origin Shield, chaque POP manque indépendamment l'origine. Shield réduit le taux de hits sur l'origine d'environ 70%.

Accélérer la migration et la modernisation des charges de travail

Migrer (lift-and-shift) 200 serveurs sur site vers EC2 avec un temps d'arrêt minimal.

AWS Application Migration Service (MGN). Réplication continue au niveau des blocs ; basculement par serveur en quelques minutes.

Pourquoi: MGN est l'outil de réhébergement recommandé par AWS (a remplacé SMS + CloudEndure). Le basculement par serveur permet une migration par vagues.

Migrer Oracle sur site vers Aurora PostgreSQL avec un temps d'arrêt minimal.

Schema Conversion Tool (SCT) pour la réécriture de schéma + procédures. AWS DMS pour le chargement complet + CDC.

Pourquoi: SCT traite le code ; DMS traite les données. CDC maintient la source synchronisée jusqu'au basculement.

Découvrir toutes les bases de données sur site et évaluer la complexité de la migration.

AWS DMS Fleet Advisor. Inventaire + évaluation des flottes hétérogènes à l'échelle.

Pourquoi: Fleet Advisor consolide la découverte + le dimensionnement en un seul workflow avant de lancer les jobs DMS.

Classer 500 applications pour la stratégie de migration.

Cadre des Sept R : Retirer (décommissionner), Retenir (garder sur site), Relocaliser (déplacement vers VMware Cloud), Réhéberger (MGN), Replatformer (RDS au lieu d'une DB auto-gérée), Racheter (abandonner & SaaS), Refactoriser (microservices).

Pourquoi: Les grands portfolios mélangent les 7. Le mappage précoce par application évite la dette de migration "taille unique".

Construire l'inventaire de migration avec les dépendances avant de commencer les vagues.

AWS Application Discovery Service. Sans agent (scan vCenter) ou basé sur agent (par serveur). Génère une carte de dépendances.

Pourquoi: Sans mappage de dépendances, la planification des vagues manque les couplages étroits. Discovery les met en évidence automatiquement.

Suivre des centaines de migrations de serveurs + bases de données en cours via MGN, DMS, manuel.

AWS Migration Hub comme tableau de bord unique. Aggrège le statut de MGN, DMS, Refactor Spaces.

Pourquoi: Les consoles par outil fragmentent le statut. Migration Hub consolide et prend en charge le reporting de portfolio.

Déplacer 100 To d'un site distant sans bande passante WAN utilisable.

AWS Snowball Edge Storage Optimized. Expédier l'appareil, copier localement, retourner à AWS. Plusieurs appareils en parallèle pour >80 To.

Pourquoi: Snowmobile (45 Po) est pour l'exa-octet ; Snowcone (8 To) pour le petit. Edge est le cheval de bataille à l'échelle du pétaoctet.

Réplication continue de données NFS sur site → S3 avec plafonnement de bande passante.

Agent AWS DataSync. Tâches planifiées ; limitation de bande passante par tâche ; mode de vérification pour l'intégrité.

Pourquoi: DataSync est conçu spécifiquement et 10 fois plus rapide que rsync auto-géré sur WAN. Snowball est hors ligne ; DataSync est en ligne.

L'application sur site attend NFS/SMB mais les données doivent atterrir dans S3.

File Gateway dans Storage Gateway. Cache local + backend S3 ; les objets sont également accessibles via l'API S3.

Pourquoi: Volume Gateway expose iSCSI ; Tape Gateway émule VTL. File Gateway est le pont NAS-vers-S3.

Une entreprise fortement dépendante de VMware souhaite une capacité côté AWS sans réoutiller vSphere/NSX.

VMware Cloud on AWS. Même pile vSphere sur des hôtes AWS bare-metal. Utiliser HCX pour la migration en direct.

Pourquoi: Préserve les outils opérationnels. Pont avant la refactorisation. Après, progressivement migrer vers les services AWS natifs.

Conteneuriser les monoliths Java/.NET hérités sans réécrire.

CLI AWS App2Container. Inspecte l'application en cours d'exécution, génère les artefacts de conteneur + les manifestes ECS/EKS.

Pourquoi: A2C capture la configuration d'exécution (environnement, ports, dépendances) dans une image fonctionnelle. La conteneurisation manuelle manque les dépendances non évidentes.

Modernisation de mainframe COBOL - convertir en microservices Java.

Service AWS Mainframe Modernization avec Blu Age (refactorisation) ou Micro Focus (replateforme). Choisir en fonction de la tolérance à l'émulation d'exécution.

Pourquoi: Refactorisation débloque les modèles cloud-natifs ; Replateforme est plus rapide mais émule le mainframe. Les deux réduisent le coût de licence du mainframe.

Décomposer un monolithe sur 18 mois sans geler le développement.

Modèle Strangler Fig. Placer API Gateway/ALB devant le monolithe ; acheminer des points de terminaison spécifiques vers de nouveaux microservices au fur et à mesure de leur découpage.

Pourquoi: Les réécritures "big-bang" échouent généralement. Strangler découple le basculement par route, maintient le monolithe fonctionnel pendant la transition.

Vouloir extraire progressivement des microservices sans posséder le plan de routage.

AWS Migration Hub Refactor Spaces. Abstraction d'application/route/service gérée sur API Gateway + VPCs.

Pourquoi: Évite d'écrire la plomberie du "strangler fig". Routage + connectivité VPC pré-construits pour l'extraction incrémentielle.

PostgreSQL auto-géré sur EC2 → RDS pour les opérations gérées.

DMS pour le basculement avec CDC. N'utiliser RDS Custom que si vous avez besoin d'un accès OS ou d'extensions spécifiques au fournisseur.

Pourquoi: RDS gère les sauvegardes/correctifs/HA. RDS Custom est une porte de sortie pour les besoins hérités mais réintroduit la charge opérationnelle.

Migrer de RDS MySQL vers Aurora MySQL pour la performance + le coût.

Réplica de lecture Aurora depuis RDS, puis promotion. Ou DMS pour un temps d'arrêt nul lorsque les décalages de version sont importants.

Pourquoi: Le chemin via réplica de lecture est le plus simple dans le moteur. DMS gère les différences de version et les mouvements hétérogènes.

L'entreprise souhaite un financement de migration AWS + un cadre de meilleures pratiques.

Programme d'Accélération de la Migration AWS (MAP). Phases : Évaluer (MRA), Mobiliser (partenaire MAP + outils), Migrer & Moderniser.

Pourquoi: MAP débloque des financements et une méthodologie structurée. Sauter MAP manque les deux.

Estimation des coûts avant migration pour le sponsor exécutif.

AWS Pricing Calculator (configuration conçue) + Migration Evaluator (basé sur les données de l'inventaire sur site).

Pourquoi: Pricing Calculator donne des prix "hypothétiques". Migration Evaluator ingère les données vSphere/Hyper-V pour projeter les économies réelles.

Décommissionner les serveurs SFTP auto-hébergés ; les partenaires fournisseurs doivent continuer à utiliser SFTP.

AWS Transfer Family (SFTP/FTPS/FTP) adossé à S3 ou EFS.

Pourquoi: Service de protocole géré. Utilisateurs mappés IAM ; points de terminaison uniquement VPC. Évite l'exécution de démons SSH EC2.

Migrer (lift-and-shift) des partages de fichiers Windows avec intégration AD.

Amazon FSx for Windows File Server. Joint à l'AD ; SMB ; DataSync pour la synchronisation en ligne depuis sur site ; Snowball pour le transfert en masse.

Pourquoi: FSx for Windows est la zone d'atterrissage native AD. EFS est uniquement Linux ; S3 manque de sémantique SMB.

Migrer les charges de travail NetApp ONTAP en conservant toutes les fonctionnalités NetApp (snapshots, FlexClone).

Amazon FSx for NetApp ONTAP. API ONTAP natives ; multi-protocole NFS+SMB ; réplication SnapMirror depuis sur site.

Pourquoi: Les autres saveurs de FSx n'exposent pas les fonctionnalités spécifiques à ONTAP. Migrer (lift-and-shift) NetApp sans ré-architecturer les sauvegardes/réplications.

Le basculement basé sur DNS risque des rémanences de cache DNS.

Basculement derrière CloudFront / ALB / Global Accelerator. Changer le backend sans modifier le DNS public.

Pourquoi: Les caches respectent le TTL mais les clients/pare-feu mettent agressivement en cache. Une adresse publique stable isole des rémanences DNS.

Migration progressive du trafic de sur site vers AWS pour le contrôle des risques.

Routage pondéré Route 53. Démarrer 1% → AWS, augmenter progressivement. Vérifications de santé pour un basculement automatique.

Pourquoi: Le routage pondéré permet une migration de type "canary" au niveau DNS. ARC ajoute des portes explicites pour les basculements à enjeux plus élevés.

Suivre les licences BYOL Windows / Oracle / SQL Server sur les charges de travail migrées.

AWS License Manager. Définir des règles ; les appliquer au lancement ; partager via RAM sur toute l'organisation.

Pourquoi: La non-conformité BYOL est coûteuse. License Manager empêche le sur-déploiement accidentel.

Après la migration, les instances RDS de développement/test sont sur-provisionnées pendant la nuit.

Migrer le dev/test vers Aurora Serverless v2 avec un ACU minimum faible. Mise à l'échelle automatique vers le bas en cas d'inactivité.

Pourquoi: Économise le coût d'inactivité nocturne sans la complexité d'un planificateur d'instances.

Exécuter Kubernetes sur site avec les mêmes outils qu'EKS pendant la migration.

EKS Anywhere sur le matériel sur site. Mêmes versions Kubernetes + ECR + intégration AWS Outposts.

Pourquoi: Un plan de contrôle cohérent réduit la dérive de compétences de l'opérateur. La migration ultérieure vers EKS est un déplacement de charge de travail, pas une réécriture d'outillage.