Migration d'une plateforme vidéo e-learning vers AWS
Une entreprise spécialisée dans la formation professionnelle en ligne propose des cours vidéo en haute définition à ses abonnés répartis dans le monde entier. Jusqu'à présent, les vidéos sont hébergées sur des serveurs on-premises et distribuées via un CDN tiers coûteux. Les vidéos sont uploadées mensuellement au format MP4 par les formateurs, puis doivent être visionnées sur tablette, smartphone et desktop. L'entreprise ne dispose d'aucune compétence interne en transcodage vidéo et souhaite migrer vers AWS pour réduire ses coûts opérationnels tout en améliorant la qualité de diffusion mondiale. Le DSI a fixé un objectif de haute disponibilité et de diffusion optimisée via le protocole HTTP Live Streaming (HLS), compatible avec les appareils mobiles fournis aux apprenants. L'entreprise souhaite également archiver les vidéos originales MP4 à moindre coût après transcodage, et conserver une intégrité totale des fichiers sources. Aucune expertise en infrastructure media n'est disponible en interne. Le projet doit être livré en moins de 3 mois, avec un budget d'infrastructure mensuel plafonné. La solution doit être serverless autant que possible afin de limiter la charge opérationnelle de l'équipe IT, composée de seulement 4 personnes.
Quelle architecture AWS serverless recommandez-vous pour transcoter les vidéos MP4 en HLS et les diffuser mondialement à 85 000 utilisateurs, sans expertise interne en transcodage ?
L'architecture optimale repose sur trois services complémentaires. Amazon Elastic Transcoder prend en charge le transcodage MP4 vers HLS sans nécessiter d'expertise interne : les vidéos uploadées dans un bucket S3 source déclenchent automatiquement un job Elastic Transcoder qui génère les fichiers HLS dans un bucket S3 de destination. Amazon CloudFront est ensuite configuré comme CDN avec ce bucket S3 comme origine, assurant une diffusion mondiale à faible latence via ses edge locations. Cette combinaison Elastic Transcoder + S3 + CloudFront est l'architecture de référence AWS pour la distribution vidéo serverless. Elle élimine le besoin de serveurs de transcodage à gérer, scale automatiquement selon la charge, et garantit la haute disponibilité native de S3 (durabilité 99,999999999%). Elastic Transcoder facture uniquement à la minute de contenu transcodé, ce qui est économique pour 120 vidéos mensuelles.
Comment archiver les vidéos MP4 originales à moindre coût après transcodage tout en préservant leur intégrité, et comment protéger les fichiers contre une suppression accidentelle ?
Pour l'archivage économique des MP4 originaux, il faut configurer une règle de cycle de vie S3 (S3 Lifecycle Policy) sur le bucket source pour transférer automatiquement les vidéos vers Amazon S3 Glacier après transcodage (par exemple, après 30 jours). Glacier offre un coût de stockage drastiquement réduit par rapport à S3 Standard, adapté à des fichiers rarement consultés. Pour protéger l'intégrité des fichiers contre une suppression accidentelle, deux mécanismes doivent être activés conjointement : le Versioning S3, qui conserve toutes les versions d'un objet et permet de restaurer une version précédente en cas de suppression accidentelle, et MFA Delete, qui exige une validation physique via un dispositif MFA pour supprimer définitivement une version. Les fichiers HLS dérivés stockés dans le bucket de destination peuvent rester en S3 Standard car ils sont régénérables via Elastic Transcoder — le Reduced Redundancy Storage (RRS) pourrait y être envisagé pour réduire les coûts, sa durabilité moindre (99,99%) étant acceptable pour des données reconstituables.
Comment configurer Route 53 pour que les utilisateurs soient automatiquement dirigés vers l'infrastructure CloudFront la plus proche, et comment gérer le nom de domaine racine de la plateforme e-learning (ex: formations.com) pour qu'il pointe vers CloudFront ?
Amazon CloudFront gère nativement la distribution géographique du contenu via ses edge locations mondiales, de sorte que le routage basé sur la latence est intrinsèque à CloudFront. Pour pointer le nom de domaine racine (zone apex, ex: formations.com) vers la distribution CloudFront, il faut utiliser un enregistrement Alias Route 53 — et non un CNAME. En effet, le standard DNS interdit les enregistrements CNAME au niveau du zone apex, mais Route 53 permet d'utiliser des Alias records qui résolvent nativement les ressources AWS comme CloudFront, sans coût supplémentaire de requête DNS. La configuration consiste à créer un enregistrement de type A avec l'option Alias activée, pointant vers le domaine CloudFront (ex: d1234.cloudfront.net). Pour les sous-domaines (ex: www.formations.com), un CNAME standard vers CloudFront est également valide. Route 53 Latency-Based Routing peut être utilisé en complément si plusieurs origines régionales sont configurées, mais pour une distribution CloudFront unique, l'Alias record suffit.
Optimisation d'une base de données transactionnelle RDS sous charge analytique
Une entreprise de retail en ligne exploite une base de données transactionnelle principale hébergée sur Amazon RDS MySQL, utilisée simultanément par son application e-commerce et par des jobs analytiques quotidiens. Chaque jour à 2h du matin, un job Amazon EMR se connecte directement à RDS pour extraire les données de ventes et générer des rapports PDF et des agrégats CSV destinés à Amazon Redshift. Pendant l'exécution de ce traitement analytique, qui dure environ 90 minutes, les équipes constatent une dégradation sévère des performances de l'application transactionnelle : les temps de réponse passent de 200 ms à plus de 4 secondes. Par ailleurs, le tableau de bord de direction est mis à jour manuellement par une équipe on-premises après réception d'un e-mail envoyé manuellement par l'équipe data. Ce système on-premises ne peut pas être modifié. L'entreprise souhaite résoudre les problèmes de performance et automatiser au maximum ce processus, sans changer le système de tableau de bord. Le volume de données analysé chaque nuit représente plusieurs dizaines de millions de lignes. L'entreprise cherche également à réduire le coût des instances EMR utilisées uniquement pour ce batch nocturne, tout en maintenant la fiabilité du traitement.
Comment éliminer l'impact du job analytique sur les performances de l'application transactionnelle RDS MySQL, sans modifier le schéma de la base de données ni l'application e-commerce ?
La solution consiste à créer une Read Replica RDS pour l'instance MySQL principale. Une Read Replica est une copie en lecture seule, synchronisée en quasi temps réel avec l'instance primaire via la réplication asynchrone native de MySQL. Le job EMR est reconfiguré pour se connecter à l'endpoint de la Read Replica plutôt qu'à l'instance principale, déchargeant ainsi totalement la charge analytique de la base transactionnelle. L'application e-commerce continue de se connecter à l'instance principale sans aucune modification. Il est important de noter que la Read Replica est distincte d'une instance Multi-AZ standby : l'instance Multi-AZ ne peut pas être utilisée pour des lectures ou écritures — elle sert uniquement au basculement automatique en cas de défaillance. La Read Replica peut être provisionnée dans la même région ou dans une région différente, et peut être dimensionnée avec un type d'instance adapté aux charges analytiques (forte RAM, lectures séquentielles) sans impact sur l'instance primaire. Pour les charges OLTP avec besoin de latence constante, le stockage Provisioned IOPS (io1/io2) est recommandé sur l'instance principale.
Comment automatiser la notification du système on-premises de tableau de bord sans modifier ce système, et comment réduire les coûts des instances EMR du batch nocturne ?
Pour automatiser la notification sans modifier le système on-premises, Amazon SNS (Simple Notification Service) est la solution appropriée. À la fin du job EMR, un message SNS est publié sur un topic configuré avec le système on-premises comme subscriber (via e-mail ou endpoint HTTP/HTTPS). SNS déclenche automatiquement la notification sans intervention humaine, remplaçant l'envoi manuel d'e-mail actuel. Le système on-premises reçoit la notification et lance le rafraîchissement du tableau de bord exactement comme avant — aucune modification du système cible n'est requise. Pour réduire les coûts EMR de 60 à 70%, les Spot Instances sont la solution optimale pour les jobs batch. Le job nocturne est non temps-réel et tolérant aux interruptions (il peut être relancé en cas d'interruption d'une Spot Instance), ce qui en fait un candidat idéal. Les nœuds core et task EMR peuvent être provisionnés en Spot Instances, tandis que le nœud master reste en On-Demand pour la stabilité. Cette combinaison — Read Replica pour la séparation des charges + Spot Instances pour EMR + SNS pour la notification — résout simultanément les trois problèmes identifiés.
L'équipe data envisage de stocker les rapports PDF générés par EMR dans S3. Quel type de stockage S3 est approprié pour ces PDF, et comment justifiez-vous ce choix par rapport aux logs bruts sources également stockés dans S3 ?
Les rapports PDF générés par EMR sont des données reproduisibles : en cas de perte, ils peuvent être régénérés à partir des logs bruts sources via une réexécution du job EMR. Ce caractère reconstituable justifie l'utilisation du Reduced Redundancy Storage (RRS) pour les PDF, qui offre une durabilité de 99,99% (contre 99,999999999% pour S3 Standard) à un coût inférieur. L'économie est acceptable car la perte d'un PDF n'entraîne aucune perte d'information définitive. En revanche, les logs bruts sources doivent impérativement rester en S3 Standard (ou S3 Standard-IA si l'accès est peu fréquent après les premières semaines) : ils constituent la source de vérité unique. Si ces logs étaient perdus, aucune régénération des rapports ne serait possible, et l'intégrité des données de l'entreprise serait compromise. Cette distinction — données reconstituables en RRS, données sources en Standard — est le principe fondamental d'optimisation des coûts S3 pour les pipelines analytiques. Les fichiers CSV agrégés dans Redshift bénéficient du même raisonnement que les PDF, étant régénérables depuis les logs bruts.
Sécurisation d'un VPC multi-niveaux pour une application e-commerce
Une entreprise de commerce électronique exploite une application multi-niveaux dans un VPC AWS : un tier web derrière un ELB public, un tier applicatif, et des bases de données RDS MySQL et DynamoDB. Des ressources statiques (images, CSS, JS) sont servies directement depuis S3. L'équipe sécurité a détecté dans les logs des tentatives d'accès non autorisées et des patterns d'attaque applicative (injections SQL, scraping intensif). L'entreprise souhaite renforcer sa posture de sécurité en ajoutant des couches de filtrage sans dégrader les performances ni l'expérience utilisateur. Par ailleurs, l'équipe a constaté que les développeurs stockaient des Access Key ID et Secret Access Key directement dans le code source des applications déployées sur EC2, ce qui représente un risque critique de compromission. Une revue IAM complète est demandée. L'entreprise gère également des données sensibles sur des volumes EBS non chiffrés, héritage d'une migration précédente. L'architecture actuelle utilise des Security Groups et des Network ACLs, mais la configuration n'est pas optimale : certains sous-réseaux de bases de données sont accessibles depuis Internet par erreur de configuration. L'équipe dispose d'un budget sécurité de 8 000 USD/mois et d'un délai de remédiation de 6 semaines.
Comment éliminer le risque lié au stockage des clés AWS (Access Key ID / Secret Access Key) dans le code source des applications EC2, et quelle est l'architecture IAM recommandée ?
La solution consiste à remplacer les credentials statiques par des IAM Roles attachés aux instances EC2. Un IAM Role fournit des credentials temporaires et automatiquement rotatifs via l'Instance Metadata Service (IMDS), accessibles à l'application sans aucune clé statique stockée dans le code. Le processus de migration est le suivant : créer un IAM Role avec les permissions minimales nécessaires (principe du moindre privilège), l'attacher à chaque instance EC2 concernée, puis supprimer toutes les Access Keys statiques du code source et des variables d'environnement. Les IAM Roles peuvent être attachés à des instances existantes sans les arrêter, via la console, CLI ou API. Cette approche élimine complètement le risque de compromission par exposition accidentelle du code (dépôt Git public, logs, etc.). Pour les 15 développeurs, des IAM Users avec des politiques strictes et une rotation obligatoire des mots de passe doivent être configurés. Il faut noter qu'une fois créé, le nom d'utilisateur IAM ne peut pas être modifié via la console — uniquement via CLI ou API — ce qui implique une planification soigneuse lors de la création des comptes développeurs.
Comment corriger la configuration réseau pour isoler les sous-réseaux de bases de données RDS d'Internet, et quelle est la différence fonctionnelle entre Security Groups et Network ACLs dans ce contexte ?
Pour isoler les bases de données RDS, plusieurs actions complémentaires sont nécessaires. Premièrement, les instances RDS doivent être déplacées dans des sous-réseaux privés, regroupés dans un DB Subnet Group — ensemble de sous-réseaux désignés pour RDS dans un VPC, généralement sans route vers Internet Gateway. Deuxièmement, les Security Groups des instances RDS doivent être configurés pour n'autoriser le trafic entrant (MySQL port 3306) qu'en provenance des Security Groups du tier applicatif, et non depuis Internet. Les Security Groups sont stateful : une règle entrante autorisée crée automatiquement la réponse sortante correspondante. Troisièmement, les Network ACLs au niveau des sous-réseaux RDS doivent bloquer explicitement tout trafic entrant depuis des plages CIDR publiques. Contrairement aux Security Groups, les Network ACLs sont stateless : elles évaluent chaque paquet indépendamment dans les deux sens. Ainsi, si une règle entrante SSH est autorisée dans une Network ACL, il faut également créer une règle sortante explicite pour les ports éphémères (1024-65535) afin d'autoriser la réponse. Cette complémentarité — Security Groups au niveau instance (stateful) + Network ACLs au niveau subnet (stateless) — constitue la défense en profondeur recommandée par AWS.
Comment chiffrer les 23 volumes EBS non chiffrés existants contenant des données sensibles, et quelle approche scalable recommandez-vous pour se protéger contre les attaques applicatives détectées dans les logs ?
Pour chiffrer les volumes EBS non chiffrés : un volume EBS existant ne peut pas être chiffré directement — il n'existe aucune option de chiffrement en place (in-place encryption). La seule méthode valide consiste à créer un snapshot du volume non chiffré, créer un nouveau volume chiffré à partir de ce snapshot (en activant le chiffrement lors de la création), migrer les données vers ce nouveau volume chiffré, puis supprimer l'ancien volume non chiffré. Cette dernière étape est critique : omettre la suppression de l'ancien volume non chiffré laisserait les données sensibles exposées. Pour 23 volumes, ce processus peut être scripté via AWS CLI (ec2-create-snapshot puis création de volume chiffré) et planifié par vagues pendant les fenêtres de maintenance. Concernant la protection contre les attaques applicatives, l'architecture recommandée est l'insertion d'un tier WAF (Web Application Firewall) sur des instances EC2 en Auto Scaling, placées derrière un nouvel ELB. Route 53 est reconfiguré pour pointer vers ce nouveau tier WAF, qui filtre les requêtes malveillantes (injections SQL, scraping) avant de les transmettre au tier web existant. Les Security Groups du tier web sont alors restreints pour n'accepter que le trafic provenant du tier WAF. Cette approche est élastique, économique et ne nécessite aucune modification du tier web.
Architecture haute disponibilité pour une application de vote en temps réel
Une chaîne de télévision nationale organise des émissions de téléréalité avec des votes du public en direct. Lors de la dernière saison, le système de vote on-premises s'est effondré sous la charge lors du prime time, provoquant une interruption de 45 minutes très médiatisée. La direction a décidé de migrer le système de vote vers AWS avant la prochaine saison, qui démarrera dans 10 semaines. Le nouveau système doit absorber des pics de charge imprévisibles (plusieurs millions de votes en quelques minutes lors des éliminations), stocker les votes de façon durable et hautement disponible, et afficher les résultats en temps quasi-réel sur le site web et l'application mobile. Les utilisateurs votent depuis des smartphones et tablettes via une application mobile et un site web. L'application mobile nécessite une adresse IP publique stable pour la communication avec l'API de vote (liste blanche côté opérateur télécom). Les préférences utilisateurs (émission favorite, historique de votes) doivent être persistées entre les sessions et entre les appareils, avec une taille estimée de 30 à 50 Ko par utilisateur. L'équipe technique est composée de 8 développeurs backend et 3 architectes AWS. Le budget projet est de 120 000 USD pour la migration initiale, avec un coût opérationnel mensuel cible de 6 000 USD hors pics.
Quel service AWS recommandez-vous pour stocker les votes en temps réel de manière durable, hautement disponible et scalable, et pourquoi DynamoDB est-il préférable à RDS MySQL dans ce contexte ?
Amazon DynamoDB est le service recommandé pour stocker les votes. C'est une base de données NoSQL entièrement gérée, serverless, qui absorbe automatiquement des pics de charge extrêmes sans configuration manuelle. Pour 3 millions de votes en 10 minutes (soit environ 5 000 votes/seconde), DynamoDB scale horizontalement de manière transparente via sa capacité en mode On-Demand, facturant uniquement les lectures/écritures consommées. RDS MySQL en revanche est une base relationnelle OLTP conçue pour des workloads à faible latence prévisible : bien qu'il supporte le stockage Provisioned IOPS pour des performances stables, il ne scale pas nativement face à des pics imprévisibles de plusieurs milliers d'écritures par seconde sans over-provisioning coûteux. De plus, RDS Multi-AZ offre la haute disponibilité mais l'instance standby ne peut pas servir de lectures — pour lire, il faudrait des Read Replicas supplémentaires. DynamoDB offre nativement une durabilité de 99,999999999%, une haute disponibilité multi-AZ transparente, et des performances en millisecondes à grande échelle, ce qui en fait le choix idéal pour un système de vote en direct. Pour les préférences utilisateur (30-50 Ko par utilisateur, 5 millions d'utilisateurs), DynamoDB avec Web Identity Federation via STS permet une authentification sécurisée depuis l'application mobile sans exposer de credentials AWS.
L'API de vote nécessite une adresse IP publique stable (liste blanche opérateur). Comment garantir une IP fixe pour les serveurs EC2 de l'API, et comment configurer la haute disponibilité avec basculement automatique entre deux régions AWS ?
Pour garantir une adresse IP publique stable et fixe sur les instances EC2 de l'API, il faut utiliser des Elastic IP Addresses. Contrairement aux adresses IP publiques dynamiques (attribuées automatiquement au lancement et changeant à chaque redémarrage), une Elastic IP est une adresse IPv4 statique allouée au compte AWS, réassignable à n'importe quelle instance. Ces Elastic IPs sont communiquées à l'opérateur télécom pour mise en liste blanche. Pour la haute disponibilité multi-régions, Route 53 est configuré avec des enregistrements de type Latency-Based Routing vers deux régions (par exemple eu-west-1 Paris et eu-west-3 ou us-east-1), chaque région disposant d'un ELB avec plusieurs instances EC2 en Auto Scaling. Pour le basculement automatique, l'option Evaluate Target Health est activée sur les alias records Route 53 pointant vers les ELBs : Route 53 utilise alors nativement les health checks internes de chaque ELB et bascule automatiquement vers la région secondaire si toutes les instances de la région primaire sont unhealthy. Le health check par défaut d'ELB utilise le protocole HTTP sur le port 80. Un enregistrement Alias Route 53 (et non CNAME) doit être utilisé si le domaine racine de l'API (zone apex) doit pointer vers l'ELB, car les CNAME sont interdits au niveau du zone apex par le standard DNS.
Comment architecturer le stockage S3 pour les assets statiques du site de vote (images des candidats, pages HTML) avec une protection contre la suppression accidentelle, et comment optimiser les coûts de distribution de ce contenu statique pour 5 millions d'utilisateurs ?
Pour les assets statiques du site de vote, S3 est le service de stockage de référence avec une durabilité de 99,999999999%. La protection contre la suppression accidentelle repose sur deux mécanismes complémentaires : le Versioning S3 (conserver toutes les versions des objets, permettant la restauration après suppression) et MFA Delete (exiger une validation MFA physique pour supprimer définitivement des versions). Ces deux fonctionnalités doivent être activées sur le bucket hébergeant les assets de production. Pour optimiser les coûts de distribution à 5 millions d'utilisateurs répartis géographiquement, Amazon CloudFront est configuré avec S3 comme origine. CloudFront met en cache les assets aux edge locations mondiales, réduisant drastiquement le nombre de requêtes vers S3 (et donc les coûts de transfer out S3) et diminuant la latence pour les utilisateurs. Il est important de noter qu'Amazon Glacier ne peut pas être utilisé comme origine CloudFront — Glacier est un service d'archivage froid sans endpoint HTTP direct compatible CloudFront. La facturation CloudFront dépend du volume de données transférées et du nombre de requêtes HTTP/HTTPS, mais pas du type de distribution. Pour les images des candidats qui ne changent pas (contenu statique permanent), une longue durée de TTL dans CloudFront maximise le cache hit ratio et réduit les coûts. Les assets régénérables (miniatures) peuvent être stockés en RRS pour réduire les coûts S3, leur durabilité moindre étant acceptable.
Reprise après sinistre et connectivité hybride pour un groupe industriel
Un groupe industriel manufacturier exploite ses systèmes ERP et de gestion de production entièrement on-premises dans son datacenter principal. Suite à une panne majeure du datacenter il y a six mois, le groupe a perdu 72 heures de production et subi un préjudice estimé à 2 millions d'euros. La direction exige désormais un plan de reprise après sinistre (DR) sur AWS avec un RTO inférieur à 4 heures et un RPO inférieur à 1 heure. Le groupe dispose de deux sites industriels en France reliés entre eux et dont l'un doit se connecter à AWS via une connexion dédiée AWS Direct Connect. L'infrastructure on-premises génère plusieurs téraoctets de données de logs machine et de capteurs par semaine, actuellement stockées localement. Ces données doivent être répliquées vers AWS pour analyse et archivage. L'équipe IT souhaite utiliser AWS Storage Gateway pour intégrer le stockage cloud de manière transparente sans refonte des applications existantes. Par ailleurs, l'application ERP utilise une base de données SQL Server, et l'équipe s'interroge sur les options Multi-AZ disponibles pour ce moteur. Le projet DR doit être opérationnel en 8 semaines. L'équipe IT compte 6 administrateurs systèmes habitués aux environnements Windows Server mais peu familiers avec AWS. Un budget de 25 000 USD/mois est alloué pour l'infrastructure DR AWS.
Comment concevoir l'architecture de reprise après sinistre sur AWS pour atteindre un RTO inférieur à 4 heures, en identifiant les composants critiques à préparer à l'avance ?
Pour atteindre un RTO inférieur à 4 heures, l'architecture DR repose sur plusieurs piliers complémentaires identifiés par AWS. Premièrement, les AMIs (Amazon Machine Images) de chaque serveur critique doivent être créées et maintenues à jour : elles permettent de relancer rapidement des instances EC2 conformes à l'environnement de production sans installation manuelle. Les snapshots EBS automatiques (via la commande ec2-create-snapshot) assurent des sauvegardes régulières des volumes de données avec une granularité horaire, compatible avec le RPO d'une heure. Deuxièmement, les scripts d'infrastructure (CloudFormation ou scripts CLI) doivent être préparés et testés pour provisionner automatiquement l'environnement complet (VPC, subnets, security groups, instances EC2, RDS) en quelques minutes. Les packages logiciels de l'ERP doivent être disponibles dans S3 pour installation rapide. Troisièmement, des tests réguliers de DR sont indispensables : une architecture non testée ne garantit pas le RTO cible. Des tests trimestriels de basculement complet doivent être planifiés. AWS Storage Gateway en mode Volume Gateway permet de répliquer les données on-premises vers S3/EBS en quasi temps réel, assurant la cohérence des données (RPO < 1h). La période de rétention des sauvegardes RDS peut être configurée jusqu'à 35 jours maximum.
Comment configurer la connectivité réseau entre les deux sites industriels on-premises et AWS via Direct Connect, et comment router le trafic pour que les applications accèdent à la fois à Internet et au réseau on-premises depuis le VPC ?
L'architecture réseau repose sur un VPC AWS avec une seule table de routage principale, suffisante pour couvrir les deux types de trafic. La route par défaut (0.0.0.0/0) pointe vers l'Internet Gateway pour le trafic public (mises à jour, accès aux services AWS publics). La connexion AWS Direct Connect depuis le site industriel principal est associée à une Virtual Private Gateway dans le VPC, et BGP propage automatiquement les routes spécifiques du réseau on-premises (ex: 10.0.0.0/8) vers le VPC via Direct Connect. Ces routes BGP plus spécifiques prennent la priorité sur la route par défaut pour le trafic destiné au réseau industriel, évitant tout conflit de routage. Pour le second site industriel, AWS VPN CloudHub peut être utilisé : en configurant plusieurs Customer Gateways (une par site) avec des ASN BGP uniques sur la même Virtual Private Gateway, les deux sites peuvent communiquer entre eux via AWS comme hub central, en plus de leur connectivité avec le VPC. Les sous-réseaux hébergeant les instances RDS doivent être configurés dans un DB Subnet Group (ensemble de sous-réseaux privés désignés pour RDS, obligatoire pour le déploiement Multi-AZ). Les Elastic IP Addresses sont utilisées pour les instances EC2 nécessitant une adresse publique stable, évitant les changements d'IP au redémarrage.
L'équipe envisage de migrer la base de données SQL Server vers RDS. Quelles sont les limitations spécifiques de RDS SQL Server concernant Multi-AZ et le stockage, et comment migrer efficacement les données depuis la base on-premises ?
Amazon RDS for SQL Server présente deux limitations importantes à connaître. Premièrement, concernant le stockage : RDS SQL Server utilise un stockage agrégé par bandes (striped storage) attaché à Windows Server, ce qui empêche l'augmentation dynamique du stockage après la création de l'instance — contrairement à MySQL et Oracle sur RDS qui supportent l'autoscaling de stockage. L'équipe doit donc dimensionner correctement le stockage dès la création, en anticipant la croissance. Pour les charges OLTP de l'ERP (latence faible et constante requise), le stockage Provisioned IOPS (io1/io2) est recommandé plutôt que le stockage standard. Deuxièmement, concernant Multi-AZ : historiquement, SQL Server sur RDS utilisait la mise en miroir de base de données (Database Mirroring) et présentait des limitations dans le support natif Multi-AZ comparé aux autres moteurs. L'équipe doit vérifier la disponibilité des options Multi-AZ pour la version SQL Server cible. La taille maximale d'une instance SQL Server Express Edition sur RDS est limitée à 10 Go par base de données (contrainte Microsoft), ce qui la rend inadaptée pour un ERP — il faudra utiliser SQL Server Standard ou Enterprise. Pour la migration des données depuis la base on-premises, AWS recommande l'utilisation de la fonctionnalité Bulk Copy (BCP) de SQL Server, qui permet d'exporter les données dans des fichiers ASCII puis de les importer efficacement dans RDS, ou SQL Server Management Studio pour des volumes modérés. Amazon RDS supporte SOAP exclusivement via HTTPS pour les échanges sécurisés.