Amazon SAA-C03: Transfert et migration de données — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

La décision : bande passante ou expédition physique

Chaque migration commence par un calcul. Calculez le temps de transfert théorique avant de choisir un outil :

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Les chiffres sont sans appel. À un débit soutenu de 100 Mbps, 1 To prend environ 24 heures ; à 1 Gbps, environ 2,5 heures. Une liaison de 15 Mbps plafonnée à 70 % d’utilisation ne fournit qu’environ 113 Go par jour, donc 20 To nécessiteraient plus de 175 jours. Le transfert de 150 To pendant la nuit (10 heures à 80 % de 100 Mbps) produit environ 360 Go par nuit, soit 10,5 To par mois — bien loin d’un délai de 30 jours. Même saturée à 100 % 24h/24 et 7j/7, une connexion de 100 Mbps ne déplace qu’environ 1 To/jour, donc 150 To nécessitent un minimum de 150 jours. À l’échelle du pétaoctet, la situation s’aggrave : une liaison de 500 Mbps avec une efficacité réelle fournit un débit théorique d’environ 5,4 To/jour, ce qui signifie que 10 Po nécessiteraient plus de cinq ans de transfert continu — plus de temps qu’il n’en faut pour provisionner la plupart des circuits Direct Connect.

Une règle de base raisonnable :

L’erreur la plus courante dans les scénarios de migration est de choisir un transfert WAN qui, mathématiquement, ne peut pas se terminer dans les délais impartis. Le piège corollaire — « on n’a qu’à le lancer chaque nuit via le WAN » — n’est pas seulement plus lent. Il consomme la bande passante de production, risque des transferts partiels ou corrompus nécessitant de nouvelles tentatives d’envoi, et coûte généralement plus cher une fois les frais de bande passante et le temps d’ingénierie comptabilisés. Les frais d’une unité Snowball, plus l’expédition, constituent un poste de dépense fixe et prévisible.

La famille Snow pour le transfert de masse hors ligne

Les appareils Snowball Edge existent en deux variantes :

Snowcone est le petit format (~8 To SSD), durci et transportable par coursier, utile pour les sites à espace restreint et préchargé avec des agents DataSync pour la synchronisation en périphérie. Snowmobile — un conteneur de 45 pieds transportant jusqu’à 100 Po — ciblait les évacuations de datacenters à l’échelle de l’exaoctet, mais a été déprécié au profit de flottes de Snowball Edge en parallèle dans la plupart des régions. Sélectionner Snowmobile pour un volume inférieur à un pétaoctet est un leurre.

La variante Compute n’est pas juste un disque plus grand. Elle exécute localement des AMI EC2, des fonctions Lambda et des charges de travail Greengrass, ce qui en fait le bon choix lorsque les données doivent être transformées, filtrées ou que les PII (informations d’identification personnelle) doivent être masquées avant l’ingestion, lorsqu’une charge de travail doit reprendre immédiatement dans AWS après l’ingestion, ou lorsque le site est déconnecté ou connecté par intermittence (navires, sites miniers isolés, déploiements tactiques, recherche à distance). Choisissez Compute Optimized lorsqu’un traitement sur l’appareil est requis ; choisissez Storage Optimized lorsque la charge de travail est une simple copie en masse.

Chaque appareil Snow effectue un chiffrement 256 bits au repos à l’aide de clés KMS qui ne quittent jamais AWS. Les boîtiers sont inviolables, avec une étiquette d’expédition à encre électronique (E Ink) et un module de plateforme sécurisée (Trusted Platform Module) matériel. Les données sur l’appareil sont écrites à l’aide du client Snowball, du point de terminaison compatible S3 ou d’un montage NFS ; TLS protège les données en transit pendant l’ingestion et l’échange du manifeste d’expédition. À son retour, le contenu est ingéré dans S3 et l’appareil est effacé de manière cryptographique conformément à la norme NIST 800-88.

Pour les projets à l’échelle du pétaoctet par site, le parallélisme est le modèle à suivre. Un bureau avec une capacité de liaison de 1 à 2 Gbps aurait encore besoin de mois de saturation continue pour déplacer 1 Po en ligne ; une flotte d’environ 13 appareils Storage Optimized par site (chacun de 80 To) expédiée en parallèle respecte un délai de quatre semaines tout en épargnant la liaison Internet du bureau. Pour une tâche de 600 To sur deux semaines avec une liaison saturée de 100 Mbps, une petite flotte en parallèle est la seule bonne réponse — même sans tenir compte du coût, les lois de la physique rendent DataSync ou un nouveau Direct Connect impossibles.

DataSync pour un transfert en ligne, vérifié et incrémentiel

DataSync est l’outil approprié lorsque la bande passante est suffisante mais que les caractéristiques de la charge de travail — des millions de petits fichiers, des arborescences de répertoires profondes, des synchronisations incrémentielles continues ou une migration inter-systèmes de fichiers — mettraient à mal des outils naïfs. Un répertoire de 20 millions de fichiers de 4 Ko copié avec aws s3 cp est limité par la latence aller-retour, et non par le débit ; chaque PutObject entraîne un aller-retour TLS/HTTP et des frais de requête API. Le regroupement en archives fonctionne mais fait perdre l’adressabilité par fichier. L’agent DataSync parallélise sur de nombreux flux TCP, gère les métadonnées de manière native, vérifie la somme de contrôle de chaque fichier de bout en bout avec SHA-256, effectue des tentatives de manière transparente et rend compte à CloudWatch — atteignant jusqu’à ~10 Gbit/s par agent avec une tarification prévisible par Go.

Les sources et les destinations couvrent NFS, SMB, HDFS, des stockages objets autogérés, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS et FSx for NetApp ONTAP. Les transferts utilisent TLS 1.2 en transit et peuvent passer par des points de terminaison d’interface VPC pour ne pas transiter par l’Internet public.

Un détail essentiel : DataSync nécessite un agent pour les sources NFS/SMB sur site (on-premises). L’agent s’exécute en tant que VM sur VMware, Hyper-V ou KVM, sur EC2 ou sur Snowcone. Croire que DataSync fonctionne sans agent pour l’on-prem est un piège courant — il ne fonctionne sans agent que lorsque les deux points de terminaison sont des services natifs d’AWS.

Un déploiement minimal :

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Deux fonctionnalités opérationnelles sont importantes. La limitation de la bande passante (BytesPerSecond) empêche de saturer une liaison partagée — répondant directement aux scénarios de type « liaison de 1 Gbit/s partagée avec d’autres départements ». Le filtrage et la planification permettent des synchronisations en dehors des heures de bureau et l’exclusion de fichiers temporaires. Sur une connexion Direct Connect de 10 Gbit/s avec des utilisateurs qui continuent de lire et d’écrire, la planification de tâches répétées est le modèle canonique : le balayage initial transfère la majeure partie des données, les exécutions incrémentielles successives rattrapent les deltas, et 700 To peuvent être transférés en bien moins d’une semaine, même avec une utilisation partielle.

Un piège plus subtil concerne la fidélité des métadonnées. DataSync préserve un ensemble sélectionné d’attributs POSIX ou SMB — UID/GID/mode/timestamps pour NFS, propriété et DACL pour SMB — mais il ne capture pas tous les attributs propriétaires d’un NAS. Les ACL spécifiques au fournisseur, les attributs étendus au-delà de ce que le protocole expose, les snapshots et les métadonnées de déduplication sortent de son champ d’application. Lorsque la conformité exige une réplique exacte du NAS incluant les fonctionnalités du fournisseur, DataSync seul est insuffisant ; une approche compatible avec NetApp, telle que FSx for ONTAP avec SnapMirror, ou un lift-and-shift via Storage Gateway, est nécessaire.

DataSync complète également Snowball : Snowball déplace les 150 To initiaux, et DataSync gère ensuite le delta hebdomadaire continu d’un jeu de données de travail de 500 Go.

Storage Gateway : présentation hybride, pas migration

Storage Gateway n’est pas un outil de migration — c’est une couche de présentation hybride. Les applications sur site continuent de communiquer en NFS, SMB, iSCSI ou iSCSI-VTL pendant que les données atterrissent dans S3, S3 Glacier ou des snapshots EBS. Confondre Storage Gateway avec DataSync est une erreur fréquente : File Gateway n’est pas conçu pour déplacer 70 To à la hâte, et DataSync ne présente pas de partage persistant aux clients sur site.

File Gateway est le cheval de bataille. L’écriture de \\gateway\share\reports\2024\report.pdf produit s3://bucket/reports/2024/report.pdf — consommable nativement par Athena, Lambda, EMR ou tout client S3. Ce mappage un-à-un entre fichier et objet est un avantage majeur par rapport aux cibles de sauvegarde de type boîte noire. La mise en cache locale signifie que les fichiers chauds sont retournés à la vitesse du réseau local ; les fichiers froids sont diffusés depuis S3 à la demande.

Le cache est le point central de l’appliance. Les lectures de données chaudes sont servies localement ; les écritures atterrissent d’abord sur le disque local et sont téléversées de manière asynchrone. Une erreur de conception courante est de supposer que le stockage sur S3 signifie que chaque lecture subit une latence aller-retour sur Internet — ce n’est pas le cas, à condition que le jeu de données de travail tienne dans le cache. Inversement, un sous-dimensionnement du cache produit des défauts de cache constants et la charge de travail semble « lente ». Règle générale : cache = 20 % de l’ensemble des données ou 100 % du jeu de données de travail chaud, la valeur la plus élevée étant retenue.

Le piège du mode cache vs. mode stocké mérite une attention particulière. Le mode cache conserve la copie principale dans S3 avec les blocs chauds en local — économique, élastique, mais un défaut de cache représente un aller-retour sur le WAN. Le mode stocké conserve la copie principale sur le disque local avec des snapshots asynchrones vers S3 en tant que snapshots EBS — chaque lecture est locale et à faible latence, mais l’ensemble des données doit tenir sur site. Pour une exigence de remplacement de sauvegarde de type « accès local à toutes les données pendant qu’elles sont sauvegardées sur AWS », le mode stocké est correct ; le mode cache violerait cette exigence. Choisir le mode cache pour une charge de travail qui nécessite une faible latence pour l’ensemble des données va à l’encontre de la conception ; choisir le mode stocké lorsque le site ne peut pas héberger l’ensemble des données est impossible par définition.

Tape Gateway répond à un besoin très spécifique : mettre au rebut une bibliothèque de bandes physiques tout en conservant intacts les flux de travail Veeam, NetBackup ou Commvault en présentant une VTL sur iSCSI, avec des données dont le cycle de vie est géré de S3 vers Glacier ou Deep Archive. C’est une solution inestimable lorsque la rétention réglementaire est définie en termes de supports de bande et que le logiciel de sauvegarde existant ne peut pas être modifié.

AWS Transfer Family

Transfer Family fournit des points de terminaison SFTP, FTPS, FTP et AS2 entièrement gérés, adossés à S3 ou EFS. La proposition de valeur est la préservation des contrats de protocole orientés partenaires : les systèmes des fournisseurs qui n’émettent des fichiers que via SFTP continuent de le faire sans modification, tandis que la réception se fait nativement sur S3 — avec des politiques de cycle de vie, des déclencheurs Lambda et une intégration analytique.

Le piège ici est de supposer qu’un fournisseur historique peut « simplement passer aux API S3 ». De nombreux systèmes de fournisseurs sont des appliances, des flux HL7 hospitaliers, des systèmes de traitement par lots bancaires ou des pipelines EDI B2B dont le client SFTP est intégré au firmware ou à des binaires signés. Le coût de la gestion du changement, de la revue de sécurité et de la re-certification pour y toucher dépasse souvent celui de la migration AWS complète. Transfer Family contourne entièrement ce problème. Le support AS2 permet en outre des charges de travail EDI avec des accusés de réception MDN (Message Disposition Notification) et la signature/le chiffrement des messages pour la conformité B2B.

L’authentification prend en charge les utilisateurs gérés par le service, AWS Directory Service (Managed Microsoft AD ou AD Connector pour un AD sur site), ou un fournisseur d’identité personnalisé via API Gateway/Lambda — permettant aux identifiants d’entreprise existants de rester la source de vérité. Un autorisateur Lambda peut renvoyer des rôles IAM par utilisateur, des mappages de répertoires personnels et des politiques de session, offrant une isolation par fournisseur sans infrastructure par fournisseur.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow est la couche d’intégration gérée pour le mouvement de données de SaaS vers AWS : Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk, et des dizaines d’autres, avec des flux de données vers S3, Redshift ou Snowflake. Il gère la pagination, l’extraction incrémentielle, le mappage de champs, le filtrage, le masquage et la validation sans nécessiter de tâche ETL développée manuellement.

La fonctionnalité critique pour la sécurité est l’intégration PrivateLink pour les connecteurs pris en charge (notamment Salesforce). Au lieu de sortir sur l’internet public pour atteindre le tenant SaaS et de revenir vers AWS, le flux transite par un point de terminaison VPC privé — éliminant l’exposition des charges utiles extraites sur l’internet public et simplifiant la posture d’audit pour les charges de travail de santé, financières et contenant des informations personnelles identifiables (PII). Les flux peuvent être planifiés, déclenchés par des événements lors de changements d’enregistrements SaaS, ou exécutés à la demande, et prennent en charge jusqu’à 100 Go par exécution de flux.

AppFlow opère à une couche plus élevée que DataSync ou Storage Gateway : c’est le bon outil lorsque la source est un SaaS piloté par API, et non un système de fichiers ou une base de données.

Migration de bases de données : DMS et SCT

AWS Database Migration Service réplique les données entre des bases de données source et cible tandis que la source reste pleinement opérationnelle. Il prend en charge les migrations homogènes (MySQL → RDS MySQL, Oracle → RDS Oracle) et hétérogènes (Oracle → Aurora PostgreSQL, SQL Server → MySQL), et les cibles s’étendent au-delà de RDS pour inclure Aurora, Redshift, S3, DynamoDB et Kinesis. Les sources incluent Oracle, SQL Server, MySQL, PostgreSQL, MongoDB et Db2.

Une tâche fonctionne dans l’un des trois modes suivants :

Le moteur d’un basculement à temps d’arrêt minimal est la Capture des Données Modifiées (Change Data Capture). Pendant un chargement complet avec CDC, DMS copie en masse les lignes existantes tout en exploitant le journal des transactions de la source — redo log Oracle, binlog MySQL, MS-CDC ou MS-Replication de SQL Server. Une fois le chargement complet terminé, le CDC applique les changements mis en file d’attente et maintient la cible continuellement à jour jusqu’à ce que l’application bascule. Ne pas activer le CDC lorsque l’application doit rester accessible en écriture est une erreur d’architecture courante : un chargement complet seul laisse la cible obsolète dès la fin du chargement.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Pour les travaux hétérogènes, l’AWS Schema Conversion Tool (ou son équivalent cloud DMS Schema Conversion) traduit le DDL, les procédures stockées, les vues et les fonctions, en signalant les éléments nécessitant des réécritures manuelles. DMS déplace les données ; SCT convertit le schéma. Ignorer le rapport d’évaluation de SCT est la raison pour laquelle des migrations échouent trois jours avant le basculement.

Les prérequis et limitations spécifiques à chaque moteur peuvent avoir de graves conséquences s’ils sont ignorés. Les LOB Oracle de plus de 64 Ko nécessitent le mode LOB limité (limited LOB mode) avec un maximum fixe ; LONG RAW a des mises en garde. PostgreSQL nécessite wal_level=logical et un rôle de réplication. MySQL nécessite la journalisation binaire au format ROW avec un binlog_row_image suffisant et des privilèges CDC élevés (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, les comportements spécifiques à RAC et les assemblys CLR de SQL Server sont souvent non pris en charge. TLS est appliqué entre l’instance de réplication et les points de terminaison, avec les modes SSL require, verify-ca ou verify-full.

DMS Serverless est le bon choix lorsque le profil de la charge de travail est imprévisible ou en rafales — un système Oracle sur site avec des pics d’activité en journée et des nuits calmes, par exemple. Vous définissez MinCapacityUnits et MaxCapacityUnits en DCU (DMS Capacity Units) et DMS met à l’échelle la capacité de réplication en fonction de la pression sur le CPU et la mémoire :

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Un piège fréquent est de supposer qu’une instance DMS provisionnée (par ex., dms.c5.4xlarge) se mettra à l’échelle automatiquement. Ce n’est pas le cas — les instances provisionnées sont des hôtes EC2 de taille fixe. Si le débit dépasse la capacité, le retard de réplication (replication lag) augmente et vous devez modifier manuellement la classe d’instance, ce qui redémarre les tâches. DMS provisionné convient aux migrations à état stable avec un débit connu ; Serverless convient aux migrations imprévisibles.

Pour une migration MySQL de 20 To avec une fenêtre de deux semaines et un temps d’arrêt serré, DMS avec chargement complet plus CDC vers Aurora MySQL ou RDS MySQL est la solution la plus rentable. Les restaurations natives avec mysqldump/mysqlpump entraînent un temps d’arrêt inacceptable ; Snowball ajoute une latence de transport et des interruptions de service.

DMS Fleet Advisor découvre les inventaires de bases de données sur site, ce qui est utile pour la planification par vagues (wave planning).

Migration de Serveurs : AWS Application Migration Service (MGN)

AWS Application Migration Service est le service principal pour le lift-and-shift (« réhébergement ») et a remplacé CloudEndure Migration et Server Migration Service pour la plupart des cas d’utilisation. MGN installe un AWS Replication Agent léger sur chaque serveur source (physique, VMware, Hyper-V ou un autre cloud). L’agent effectue un instantané initial au niveau bloc dans une zone de transit à faible coût dans le VPC cible — de petites instances T3 avec des volumes EBS attachés — puis réplique en continu et de manière asynchrone les changements au niveau bloc. Comme la réplication est continue et au niveau bloc, le basculement se mesure en minutes : MGN convertit les volumes de transit en instances EC2 de production du type d’instance cible au moment du basculement.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Les lancements de test sont essentiels et souvent négligés. MGN lance des instances de test isolées à partir de l’état de réplication actuel sans perturber la réplication en cours. Vous validez le comportement de l’application, supprimez le test, itérez, et ne lancez le basculement que lorsque les tests réussissent — le basculement arrête la réplication, lance l’instance finale et marque la vague comme terminée.

La mauvaise approche consiste à exporter manuellement les VM au format OVF, à les téléverser via

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

, et à réinstaller les applications sur des instances EC2 fraîchement provisionnées. C’est lent, sujet aux erreurs, nécessite un temps d’arrêt par VM égal à la durée de l’exportation, ne fournit pas de réplication delta et n’offre aucun test non disruptif. MGN élimine tout cela — la source continue de fonctionner jusqu’à la dernière seconde du basculement, et la dérive entre la source et la cible est pratiquement nulle.

La recommandation générale pour le portefeuille est de réhéberger d’abord, puis de changer de plateforme (re-platform) ou de refactoriser dans la Région où le coût d’itération est plus faible. Une refactorisation et une migration simultanées multiplient les risques sans avantage compensatoire.

Connectivité Hybride : Direct Connect et VPN

AWS Direct Connect fournit un circuit de couche 2 dédié depuis un routeur sur site vers un emplacement Direct Connect, offrant une bande passante constante (1, 10, 100 Gbit/s dédiés ; sous 1 Gbit/s via des connexions hébergées par des partenaires) et une latence prévisible. Les Interfaces Virtuelles (VIF) partitionnent le circuit :

• VIF privée (Private VIF) — accès à un seul VPC via une passerelle privée virtuelle (Virtual Private Gateway).
• VIF de transit (Transit VIF) — accès à de nombreux VPC via une passerelle Direct Connect (Direct Connect Gateway) attachée à une passerelle de transit (Transit Gateway). C’est le modèle canonique pour les grands environnements multi-VPC et multi-sites.
• VIF publique (Public VIF) — accès aux points de terminaison de services publics AWS (S3, DynamoDB) sans passer par Internet.

DX n’est pas, en soi, hautement disponible : un circuit unique sur un seul emplacement DX dépend d’un seul chemin de fibre optique. Deux modèles de résilience sont importants :

1. DX + sauvegarde VPN Site-to-Site sur Internet est le minimum viable pour la haute disponibilité. BGP gère le basculement automatique avec l’attribut AS-path prepending, MED ou local-pref pour préférer DX en régime normal.
2. Deux circuits DX sur des emplacements DX distincts est le modèle de résilience maximale pour les charges de travail critiques et est requis pour le SLA de DX.

Ne provisionner aucun chemin de secours est un piège bien connu : lorsque DX tombe en panne et qu’il n’y a pas de VPN, les applications hybrides, les tâches DataSync et les téléversements Storage Gateway sont tous bloqués pendant la durée de la réparation par l’opérateur. Un VPN pur est acceptable pour les charges de travail à plus faible débit ou comme solution temporaire pendant le provisionnement de DX, ce qui peut prendre des semaines.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Lorsque le chiffrement de la couche physique est obligatoire, choisissez une connexion DX compatible MACsec. Combiner DX pour la bande passante, DataSync pour l’orchestration et Storage Gateway pour un accès local continu est le modèle hybride canonique pour les grands ensembles de données actifs qui ne peuvent tolérer aucune fenêtre d’interruption.

AWS Outposts pour une Infrastructure AWS sur Site

Outposts étend l’infrastructure AWS dans les locaux d’un client sous la forme d’un rack entièrement géré (ou de serveurs Outposts 1U/2U). Il exécute localement un ensemble de services sélectionnés — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — avec les mêmes API que la Région parente. Les opérations du plan de contrôle retournent à la Région parente via un lien de service (service link) composé de tunnels chiffrés redondants ; une panne du WAN empêche temporairement le lancement de nouvelles instances mais n’arrête pas les charges de travail en cours d’exécution.

La répartition des responsabilités partagées est le piège qui surprend les opérateurs. AWS livre et maintient le matériel, l’hyperviseur et les services gérés. Le client est responsable de :

• L’espace physique, l’alimentation, le refroidissement et la mise en réseau conformes aux spécifications d’Outposts (alimentations redondantes, commutateurs en amont, PDU appropriés).
• La sécurité physique des locaux.
• La configuration du réseau local — la passerelle locale (Local Gateway ou LGW) pour le trafic sur site et la liaison montante du lien de service.
• Les aspects liés au système d’exploitation et aux applications des charges de travail, exactement comme dans la Région.
• Une connectivité WAN adéquate vers la Région parente.

Outposts n’élimine pas les opérations — il déplace l’abstraction. Supposer qu’AWS est responsable de l’alimentation du datacenter ou du réseau en amont est une erreur d’interprétation fondamentale. Ce n’est pas non plus « exécuter n’importe quel service AWS sur site » : la liste des services pris en charge est limitée, et des services comme Route 53 ou IAM restent basés dans la Région.

Pour une modernisation Hadoop/Spark où les données doivent rester sur site pour des raisons réglementaires, EMR on Outposts est le modèle correct — des clusters Spark gérés et élastiques avec les outils de la Région et une résidence des données locale. Storage Gateway ou DataSync ne respectent pas l’exigence de résidence des données ; un lift-and-shift vers EMR dans la Région ne respecte pas la conformité.

Distribution de contenu aux flottes Edge

Lorsque des serveurs Outposts, des magasins de détail ou des périphériques Edge extraient de manière répétée la même charge utile volumineuse (une nouvelle version logicielle nocturne, par exemple), l’extraction directe depuis un bucket S3 dans une seule Région sature les liaisons montantes et augmente le temps de déploiement. Le pattern correct est CloudFront avec une origine S3 et des URL signées :

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Le premier périphérique dans une région préchauffe le cache Edge ; chaque périphérique suivant extrait les données avec la latence Edge. Les URL signées empêchent les téléchargements non autorisés sans nécessiter d’identifiants IAM par périphérique, et il n’y a aucune flotte de réplicas régionaux à gérer.

Deux anti-patterns à rejeter : héberger la version sur un unique serveur web EC2 (un désastre en termes de mise à l’échelle et de latence), et répliquer le bucket S3 dans chaque Région via la Cross-Region Replication juste pour réduire la latence de téléchargement (coût de stockage et complexité opérationnelle inutiles que la mise en cache CloudFront résout gratuitement).

Résumé des décisions

← Stockage et cycle de vie des données · Tous les domaines · Réseau et connectivité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →