4.3 - Outils de migration de bases et de refactorisation (SCT, DMS, Refactor Spaces)
L'objectif 4.3 de l'AWS Solutions Architect Professional couvre l'outillage de migration de bases et de refactorisation applicative. Un déplacement hétérogène comme Oracle vers Aurora PostgreSQL associe l'AWS Schema Conversion Tool (SCT) pour convertir schéma et code à l'AWS Database Migration Service (DMS) pour déplacer les données, et le rapport d'évaluation de SCT indique d'avance quels objets se convertissent automatiquement et lesquels exigent une reprise manuelle. AWS Transfer Family expose des endpoints SFTP, FTPS et FTP managés adossés à S3 ou EFS avec des fournisseurs d'identité personnalisés, License Included évite d'acheter et suivre les licences Windows ou SQL Server, et tu décomposes un monolithe de façon incrémentale avec le motif strangler fig routant les chemins migrés via un facade. Les cibles spécialisées modernisent les modes d'accès : DynamoDB avec DAX pour un magasin de sessions à forte lecture, Amazon DocumentDB pour la compatibilité MongoDB, et AWS Migration Hub Refactor Spaces pour fronter anciens et nouveaux services derrière un unique API Gateway managé. Un job EC2 inactif mais déclenché se refactorise en Lambda sur événements S3. Attends-toi à des mises en situation sur la conversion de schéma, le maintien des clients SFTP ou la décomposition incrémentale, et à choisir le bon outil.
Convertir le schéma puis déplacer les données (moteurs différents) = SCT + DMS. SFTP managé adossé à S3 en gardant les clients existants = AWS Transfer Family. Un unique API Gateway managé devant anciens et nouveaux services = Migration Hub Refactor Spaces.
Questions d'entraînement
1. Une entreprise migre une base Oracle auto-gérée vers Amazon Aurora PostgreSQL. Quels DEUX outils AWS gèrent ensemble la conversion du schéma et le transfert des données ? (Choisissez DEUX réponses.)
- Amazon Athena pour exécuter des requêtes SQL interactives directement sur les fichiers de la source
- AWS Schema Conversion Tool (SCT) pour convertir schéma et code (bonne réponse)
- Un crawler AWS Glue pour cataloguer seulement les tables Oracle
- AWS Database Migration Service (DMS) pour transférer les données (bonne réponse)
Pour une migration hétérogène (moteurs différents), SCT convertit le schéma, les procédures stockées et le code d'Oracle vers PostgreSQL, puis DMS réplique les données. Athena interroge S3, et un crawler Glue ne fait que bâtir un catalogue ; aucun ne convertit le schéma ni ne migre une base active.
2. Une entreprise doit copier 90 To d'un partage NFS sur site vers Amazon S3 via une liaison Direct Connect existante, avec vérification automatique et synchronisations incrémentielles. Quel service est conçu pour cela ?
- Amazon S3 Transfer Acceleration via l'endpoint public
- AWS DataSync exécutant des tâches de transfert en ligne planifiées (bonne réponse)
- AWS Snowball Edge expédié physiquement dans les deux sens
- Amazon Kinesis Data Firehose diffusant les fichiers
DataSync est conçu pour des transferts en ligne rapides de NFS/SMB/HDFS vers S3/EFS/FSx sur des liens réseau, avec vérification d'intégrité et synchronisations incrémentielles planifiées. Transfer Acceleration n'accélère que les envois S3 (pas d'agent NFS), Snowball est hors ligne pour faible bande passante, et Firehose diffuse des enregistrements, pas des partages.
3. Une base PostgreSQL de production doit migrer vers RDS avec seulement quelques minutes d'indisponibilité, en restant synchronisée pendant que l'équipe valide la cible avant la bascule. Quelle capacité de DMS permet cela ?
- Un chargement complet unique suivi d'une longue fenêtre de maintenance
- Exporter un snapshot et le restaurer pendant une coupure le week-end
- La réplication logique native de PostgreSQL configurée à la main de bout en bout
- Chargement complet plus réplication continue par change data capture (CDC) (bonne réponse)
Le chargement complet plus CDC de DMS copie les données existantes puis diffuse les changements pour garder la cible à jour ; on bascule dans une courte fenêtre une fois rattrapé. Un chargement unique ou une restauration de snapshot impose une longue coupure, et la réplication native manuelle est justement ce que DMS évite.
4. Des partenaires envoient des fichiers vers un serveur SFTP sur site. L'entreprise veut migrer cette ingestion vers AWS tout en gardant les clients SFTP et le flux d'identifiants existants des partenaires. Quelles DEUX affirmations sur AWS Transfer Family sont correctes ? (Choisissez DEUX réponses.)
- Il oblige chaque partenaire externe à réécrire ses applications clientes pour appeler directement l'API objet S3
- Il expose des endpoints managés SFTP/FTPS/FTP adossés à S3 ou EFS (bonne réponse)
- Il supporte des fournisseurs d'identité personnalisés pour les identifiants existants (bonne réponse)
- Il ne fonctionne que si les partenaires installent l'AWS CLI sur leurs serveurs
Transfer Family fournit des endpoints managés SFTP/FTPS/FTP qui déposent les fichiers directement dans S3 ou EFS, et peut utiliser un fournisseur d'identité personnalisé pour conserver les identifiants partenaires. Les partenaires n'ont ni à changer de client ni à installer la CLI, car ils parlent toujours du SFTP standard.
5. Un ingénieur dispose d'une image VM sur mesure sur site et doit simplement la rendre disponible en AMI EC2, sans mettre en place de réplication continue. Quel service fait cela directement ?
- AWS Application Migration Service pour la réplication bloc continue
- VM Import/Export pour importer l'image en AMI EC2 (bonne réponse)
- AWS Backup restaurant la VM depuis un coffre inter-comptes
- Amazon AppStream 2.0 diffusant le bureau aux utilisateurs
VM Import/Export prend une image VM existante (VMDK, VHD, OVA) et l'importe en AMI EC2 pour un déplacement ponctuel, sans agent ni réplication. MGN sert au réhébergement continu à grande échelle, Backup restaure des ressources AWS, et AppStream diffuse des applis bureau.
6. Après avoir migré une application web vers AWS, l'équipe veut une bascule capable d'envoyer d'abord un faible pourcentage du trafic réel vers la nouvelle pile et de revenir instantanément en cas de pic d'erreurs. Quelle approche permet cela ?
- Des enregistrements pondérés Route 53 déplaçant le trafic progressivement entre les piles (bonne réponse)
- Un unique changement DNS brutal configuré avec un TTL très long pointant droit vers la nouvelle pile
- Supprimer l'ancien environnement avant de valider le nouveau
- Une seule fenêtre de maintenance basculant tous les utilisateurs d'un coup
Le routage pondéré Route 53 envoie une petite part du trafic vers la nouvelle pile, permet de surveiller les métriques, d'augmenter progressivement et de revenir instantanément en cas de souci : une bascule blue/green sûre. Un changement brutal à long TTL, la suppression anticipée de l'ancienne pile ou un basculement global suppriment ce retour arrière rapide.