🏠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

SAA-C03Guide

Guide - SAA-C03 AWS Certified Solutions Architect Associate

Dernière révision : mai 2026

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

Sections

Concevoir des architectures sécurisées34 entrées
Concevoir des architectures résilientes28 entrées
Concevoir des architectures hautement performantes26 entrées
Concevoir des architectures optimisées en coûts24 entrées

Concevoir des architectures sécurisées

Application à trois niveaux : web, application, base de données. La base de données doit être inaccessible depuis Internet en toutes circonstances.

Sous-réseaux publics pour le niveau web (ALB). Sous-réseaux privés pour les niveaux application et base de données. Le groupe de sécurité de la base de données autorise le trafic uniquement depuis le groupe de sécurité du niveau application (pas depuis des plages CIDR).

Pourquoi: Les tables de routage des sous-réseaux imposent l'accessibilité ; les références de groupe de sécurité à groupe de sécurité encodent le principe du moindre privilège au niveau du groupe de sécurité et survivent aux changements d'adresse IP.

Une instance EC2 doit accéder à S3. Éviter les identifiants intégrés.

Rôle IAM attaché via un profil d'instance. Le SDK récupère des identifiants temporaires depuis IMDSv2.

Pourquoi: Les clés d'accès à longue durée de vie sur les instances sont la première cause de fuite d'identifiants. Les rôles sont renouvelés automatiquement et ne sont jamais persistés.

Bloquer les attaques SSRF qui tentent de lire les métadonnées d'instances EC2.

Appliquer IMDSv2 (`HttpTokens=required`) lors du lancement de l'instance. Rejeter les requêtes non authentifiées d'IMDSv1.

Pourquoi: IMDSv2 nécessite un jeton de session via PUT avant que le point de terminaison des métadonnées ne réponde ; les attaques SSRF qui ne font que des GET sont bloquées.

Le service A du Compte A invoque une fonction Lambda dans le Compte B. Moindre privilège.

Politique basée sur les ressources sur la fonction Lambda cible accordant `lambda:InvokeFunction` au principal du rôle du Compte A. L'appelant assume son propre rôle et invoque directement - aucune chaîne de rôles n'est nécessaire.

Pourquoi: Les politiques de ressources sont le modèle inter-comptes le plus simple pour les ressources à façade de service (Lambda, S3, SNS, SQS, KMS).

D'autres comptes AWS doivent télécharger des objets dans un compartiment S3 central.

Politique de compartiment accordant `s3:PutObject` aux principaux de comptes externes. Ajouter une exigence d'ACL `bucket-owner-full-control` afin que le propriétaire du compartiment conserve le contrôle des objets.

Pourquoi: Sans `bucket-owner-full-control` (ou `BucketOwnerEnforced` pour la propriété d'objets), les objets téléchargés sont la propriété du compte de l'écriture.

Empêcher que tout compartiment S3 de l'organisation ne soit rendu public.

Activer le Blocage de l'accès public à S3 au niveau du compte (et à l'échelle de l'organisation via des SCP). Cela remplace les ACL et les politiques au niveau du compartiment.

Pourquoi: Le paramètre au niveau du compte prévaut sur les paramètres par compartiment - une défense contre les erreurs de configuration accidentelles.

Les développeurs doivent pouvoir créer leurs propres rôles IAM mais ne peuvent pas accorder des autorisations au-delà d'un ensemble maximal défini.

Limites d'autorisations (permission boundaries) sur le principal développeur. Permissions effectives = politique d'identité ∩ limite.

Pourquoi: Les SCP s'appliquent au niveau du compte/OU ; les limites d'autorisations ciblent les principaux individuels. Utilisez les limites d'autorisations pour les modèles d'administration déléguée.

Restreindre une OU à des Régions spécifiques pour la conformité à la résidence des données.

Politique de contrôle des services (SCP) dans Organizations refusant toute action où `aws:RequestedRegion` ne figure pas dans la liste autorisée.

Pourquoi: Les SCP sont le seul mécanisme qui peut refuser des actions que le compte lui-même autorise. IAM ne peut pas refuser ce qu'un compte racine pourrait accorder.

Authentification unique des employés à travers de nombreux comptes AWS ; intégration avec un fournisseur d'identité d'entreprise (IdP).

AWS IAM Identity Center (anciennement AWS SSO) avec fédération SAML/OIDC vers l'IdP d'entreprise. Les ensembles d'autorisations sont mappés à des rôles dans les comptes membres.

Pourquoi: Identity Center est l'identité canonique multi-comptes pour les employés. Cognito est destiné aux utilisateurs finaux d'applications, pas aux employés.

Choisir entre Cognito User Pool et Identity Pool.

User Pool = inscription / connexion / émission de JWT pour les utilisateurs d'applications. Identity Pool = échange de jetons contre des identifiants AWS temporaires. La plupart des applications utilisent les deux : User Pool authentifie, Identity Pool autorise l'accès à AWS.

Ajouter une étape de validation personnalisée à la connexion Cognito (par exemple, liste blanche de domaines de messagerie).

Déclencheurs Lambda : Pré-inscription, Pré-authentification, Définir/Créer/Vérifier le défi d'authentification. Valider ou rejeter dans la fonction Lambda.

Nécessité d'un contrôle total sur la rotation des clés, la suppression et la piste d'audit par clé.

Clé KMS gérée par le client (CMK). Les clés gérées par AWS (`aws/<service>`) sont plus simples mais n'offrent aucun contrôle de politique de clé ni visibilité sur l'utilisation individuelle des clés.

Pourquoi: Les CMK vous permettent de définir l'étendue de l'accès par clé dans CloudTrail, de définir des politiques de clé pour une utilisation inter-comptes et de désactiver/planifier la suppression.

Le Compte B doit déchiffrer des objets S3 chiffrés avec la CMK du Compte A.

La politique de clé sur la CMK accorde `kms:Decrypt` aux principaux du Compte B. L'IAM du Compte B a également besoin de `kms:Decrypt` sur l'ARN de la clé. Les deux parties sont requises.

Pourquoi: KMS inter-comptes nécessite une autorisation explicite à la fois sur la politique de clé et sur l'identité IAM de l'appelant (contrairement à la plupart des politiques de ressources).

Chiffrer des données dans `us-east-1` ; déchiffrer dans `us-west-2` après réplication, sans rechiffrer.

Clé KMS multi-régions. Une clé primaire dans une Région, une réplique dans une autre, toutes deux avec le même matériel de clé et le même ID.

Pourquoi: Évite la nécessité de ré-encapsuler le texte chiffré pour un basculement ou une reprise après sinistre inter-régions.

Chiffrer de gros objets sans que les appels d'API KMS par objet ne dominent les coûts.

Chiffrement par enveloppe. KMS génère une clé de données (un appel d'API) ; utiliser la clé de données pour chiffrer la charge utile localement ; stocker la clé de données chiffrée avec le texte chiffré.

Pourquoi: KMS est soumis à des limites de débit et est facturé par requête. Le modèle d'enveloppe est la méthode canonique pour chiffrer des données de plus de quelques Ko.

Choisir entre Secrets Manager et SSM Parameter Store SecureString.

Identifiants de base de données avec rotation automatique, partage inter-comptes, secrets volumineux → Secrets Manager. Indicateurs de configuration, paramètres d'application, secrets simples, coût le plus bas → SSM Parameter Store.

Pourquoi: Secrets Manager dispose de fonctions Lambda de rotation intégrées pour RDS/Aurora/DocumentDB/Redshift ; Parameter Store n'a pas de rotation native mais est gratuit pour le niveau Standard.

Faire pivoter le mot de passe RDS automatiquement tous les 30 jours.

Secrets Manager avec rotation gérée. Un modèle Lambda intégré gère la rotation d'un seul utilisateur sur le point de terminaison RDS. Les applications récupèrent le secret au moment de la connexion (mis en cache) - pas de redéploiement d'application.

Atténuer une inondation HTTP de couche 7 sans bloquer les pics légitimes.

Règle basée sur le taux d'AWS WAF (par exemple, 2000 requêtes / 5 min par IP) sur l'ALB ou CloudFront. À combiner avec des groupes de règles gérés pour les adresses IP connues comme malveillantes.

Pourquoi: Les règles de taux WAF suivent par adresse IP source ; blocage automatique lorsque le seuil est dépassé ; libération après la fenêtre.

Application critique nécessitant une protection contre les coûts DDoS et un support SRT 24h/24 et 7j/7.

AWS Shield Advanced sur CloudFront / ALB / NLB / Global Accelerator. Inclut une protection des coûts (remboursements pour les dépenses de mise à l'échelle pendant une attaque) + accès à l'équipe de réponse de Shield.

Pourquoi: Shield Standard est automatique et gratuit ; Advanced ajoute des protections et un SLA. CloudFront est toujours la porte d'entrée recommandée.

Choisir entre groupe de sécurité et NACL.

Avec état, attachement à une ENI, autorise seulement → groupe de sécurité (par défaut). Sans état, au niveau du sous-réseau, autorise + refuse explicitement → NACL. Utilisez les NACL pour les règles de refus génériques (blocage de plages IP) ; les groupes de sécurité pour tout le reste.

Pourquoi: Les NACL évaluent le trafic entrant et sortant séparément. Les groupes de sécurité autorisent automatiquement le trafic de retour.

Les instances EC2 dans un sous-réseau privé doivent atteindre S3/DynamoDB sans les coûts de sortie du NAT.

Endpoint de passerelle VPC pour S3 et DynamoDB. Gratuit, entrée dans la table de routage, pas de NAT.

Pourquoi: Les endpoints de passerelle sont uniquement pour S3/DynamoDB. Permet d'économiser les frais de traitement des données du NAT et maintient le trafic sur le backbone AWS.

Un sous-réseau privé doit atteindre les API de services AWS (KMS, Secrets Manager, ECR, etc.) de manière privée.

Endpoint d'interface VPC (PrivateLink) par service. ENI dans votre VPC, facturé par heure + par Go.

Pourquoi: Les endpoints d'interface fonctionnent pour presque tous les services AWS. Utilisez-les pour supprimer la sortie NAT pour les appels de service.

Un fournisseur SaaS expose son service VPC aux comptes clients de manière privée, sans appairage VPC ni maintenance du routage client.

Service de point de terminaison AWS PrivateLink adossé à un NLB. Les clients créent des points de terminaison d'interface pour consommer le service.

Pourquoi: Aucun problème de chevauchement de CIDR, pas de maillage d'appairage, exposition unidirectionnelle (le fournisseur ne voit pas le trafic client).

Connecter plus de 30 VPC à travers les comptes et les environnements sur site dans une topologie hub-and-spoke.

AWS Transit Gateway. Un seul attachement par VPC ; les tables de routage segmentent le trafic.

Pourquoi: L'appairage full-mesh nécessite N×(N-1)/2 connexions. TGW évolue linéairement et prend en charge le cross-account via RAM.

Connectivité hybride nécessitant une bande passante prévisible, une faible latence et un chiffrement.

Direct Connect avec un VPN Site-à-Site sur le DX (MACsec ou IPsec). DX seul n'est pas chiffré ; le VPN sur DX est privé + chiffré + faible gigue.

Pourquoi: Le VPN simple sur Internet est bon marché mais a une latence variable. DX seul est rapide mais en texte clair au niveau de la couche liaison.

Détection continue des menaces à travers les journaux de flux VPC, DNS, CloudTrail, audit EKS, événements de données S3.

Amazon GuardDuty. À l'échelle de l'organisation via l'administrateur délégué d'Organizations.

Pourquoi: Détection des menaces gérée. Les résultats sont acheminés vers Security Hub ou EventBridge pour l'automatisation de la réponse.

Découvrir et classifier les informations personnelles identifiables (PII) / informations de santé protégées (PHI) dans les compartiments S3.

Amazon Macie. Découverte de données sensibles basée sur le ML, limitée à S3, s'intègre avec Security Hub.

Scan continu des CVE pour EC2, les images ECR, les fonctions Lambda.

Amazon Inspector v2. Découvre automatiquement les ressources via l'agent Systems Manager, scanne par rapport aux CVE publiées.

Agréger les résultats de GuardDuty, Inspector, Macie, IAM Access Analyzer dans un seul tableau de bord.

AWS Security Hub. CSPM avec les AWS Foundational Security Best Practices et les normes CIS.

Assurer que tous les volumes EBS sont chiffrés ; remédier automatiquement aux ressources non conformes.

Règles AWS Config (gérées `encrypted-volumes`) + Runbook d'automatisation Systems Manager pour la remédiation, déclenchées via l'action de remédiation Config.

Journal d'audit unique et inaltérable à travers tous les comptes de l'organisation.

Piste d'organisation avec validation des fichiers journaux activée, écrite dans un compartiment S3 central avec une politique de compartiment interdisant la suppression.

Pourquoi: Les pistes d'organisation s'activent automatiquement dans tous les comptes membres (actuels et futurs). Les hachages de validation prouvent que les journaux n'ont pas été modifiés.

Plusieurs départements ont besoin d'un accès délimité à différents préfixes dans un compartiment S3 partagé.

Points d'accès S3 - un par département, chacun avec sa propre politique d'accès et (optionnellement) une restriction VPC.

Pourquoi: Plus propre qu'une politique de compartiment tentaculaire ; les points d'accès ont leurs propres ARN et noms DNS.

Charge de travail PCI DSS - isolation stricte des comptes non-PCI.

Compte AWS dédié au sein d'une unité d'organisation (OU) d'Organizations avec des SCP restreignant l'accès aux services/régions. VPC, clés KMS, rôles IAM séparés. Network Firewall ou GWLB pour l'inspection des sorties.

Pourquoi: La limite de compte est l'isolation de rayon d'impact la plus forte dans AWS.

Certificat TLS public pour `*.example.com` sur ALB et CloudFront. Renouvellement automatique.

Certificat public AWS Certificate Manager (ACM) avec validation DNS dans Route 53. Se renouvelle automatiquement 60 jours avant l'expiration.

Pourquoi: Gratuit pour une utilisation avec les services intégrés à AWS. La validation par e-mail fonctionne mais la validation DNS est préférée pour l'automatisation.

Concevoir des architectures résilientes

Base de données RDS de production avec basculement en moins d'une minute.

Déploiement RDS Multi-AZ (ou Cluster de base de données Multi-AZ). Réplication synchrone vers la veille ; basculement automatique via un changement de point de terminaison DNS.

Pourquoi: Multi-AZ est pour la haute disponibilité (HA), pas pour la mise à l'échelle des lectures. Les réplicas en lecture sont pour la mise à l'échelle des lectures (et asynchrones ; latence potentielle).

Choisir Aurora vs RDS pour une nouvelle charge de travail MySQL/PostgreSQL.

Aurora pour un débit plus élevé, un basculement plus rapide, jusqu'à 15 réplicas en lecture, Global Database, Serverless v2. RDS pour les moteurs plus anciens (MariaDB, Oracle, SQL Server) ou les déploiements plus simples/moins chers.

Pourquoi: Le stockage Aurora est partagé entre les réplicas (pas de latence de réplication due au stockage). Le basculement est typiquement < 30s.

Base de données multi-régions active-passive avec une latence de réplication < 1s et un RTO < 1 min.

Aurora Global Database. Réplication au niveau du stockage vers jusqu'à 5 Régions secondaires ; promouvoir une secondaire en principale en cas de désastre.

Pourquoi: La réplication utilise une infrastructure dédiée ; la latence inter-régions est typiquement < 1s. Les réplicas en lecture dans les Régions éloignées permettent des lectures locales à faible latence.

Charge de base de données variable / imprévisible avec des périodes d'inactivité.

Aurora Serverless v2. Mise à l'échelle par incréments de 0,5 ACU ; événements de mise à l'échelle en moins d'une seconde ; pas de pause complète mais un minimum très bas.

Pourquoi: La v2 maintient la connexion ouverte pendant les événements de mise à l'échelle (contrairement à la v1). Paiement par seconde d'ACU.

Lectures + écritures en quelques ms dans plus de 3 Régions, avec réplication "last-writer-wins".

DynamoDB Global Tables. Réplication multi-active avec résolution des conflits "last-writer-wins".

Pourquoi: Actif-actif dans chaque Région ; pas de leader. À utiliser lorsque la tolérance aux conflits au niveau de l'application est acceptable.

Récupérer une table DynamoDB à un point spécifique des 35 derniers jours après une suppression accidentelle.

Activer la récupération à un instant T (PITR). La restauration crée une nouvelle table à la seconde choisie.

Acheminer le trafic vers la Région primaire ; basculer vers la secondaire en cas d'échec du contrôle de santé.

Politique de routage de basculement de Route 53. Contrôle de santé actif sur le point de terminaison primaire ; l'enregistrement secondaire sert lorsque le primaire est défaillant.

Pourquoi: Le contrôle de santé au niveau de l'application (chemin HTTP) détecte les pannes partielles que les sondes TCP manquent.

Envoyer chaque utilisateur vers la Région saine avec la latence la plus faible.

Routage basé sur la latence de Route 53. Vérification de la santé de chaque point de terminaison ; Route 53 renvoie la réponse saine avec la latence la plus faible par requête.

Déploiement Canary : envoyer 10 % à la v2, 90 % à la v1.

Routage pondéré de Route 53. Deux enregistrements de même nom, cibles différentes, poids 10 et 90.

Les instances EC2 prennent 3 minutes à s'initialiser ; la mise à l'échelle horizontale est trop lente pendant les pics de trafic.

Pool d'instances préchauffées (warm pool) d'Auto Scaling. Instances pré-initialisées maintenues arrêtées (moins cher) prêtes à démarrer en quelques secondes.

Pourquoi: Le démarrage à froid + le bootstrap est le goulot d'étranglement. Le pool préchauffé déplace ce travail en dehors du chemin critique.

Lors de la mise à l'échelle descendante, vider le travail en cours et persister les journaux avant la terminaison de l'instance.

Hook de cycle de vie Auto Scaling en `Terminating:Wait`. Le hook publie sur SNS/EventBridge ; le gestionnaire termine le drainage et appelle `complete-lifecycle-action`.

Réduire le coût de calcul sur une flotte non critique qui tolère les interruptions.

ASG avec politique d'instances mixtes : capacité de base en On-Demand, capacité additionnelle en Spot, plusieurs types d'instances et Zones de Disponibilité pour la diversification.

Pourquoi: La diversification des types d'instances réduit le risque d'interruption Spot par rapport à un pool unique.

Choisir entre ALB et NLB.

HTTP/HTTPS, routage par chemin/hôte, intégration WAF, authentification OIDC → ALB. TCP/UDP/TLS à l'échelle extrême, IP statique par AZ, latence la plus faible, conservation de l'adresse IP source du client → NLB.

Insérer une flotte d'appliances de sécurité tierces en ligne pour l'inspection du trafic à travers les VPC.

Gateway Load Balancer (GWLB) avec une flotte d'appliances comme cibles. Le trafic est encapsulé via GENEVE ; insertion transparente via le routage.

Les messages "poison" font échouer les gestionnaires et se remettent en file d'attente en boucle.

File d'attente de lettres mortes (DLQ) SQS. Configurer `maxReceiveCount` sur la file d'attente source ; les messages dépassant ce compte sont déplacés vers la DLQ pour inspection.

Ordre strict et traitement exactement une fois par groupe de messages.

File d'attente SQS FIFO avec déduplication basée sur le contenu ou `MessageDeduplicationId` explicite. Utilisez `MessageGroupId` pour des groupes ordonnés parallèles.

Pourquoi: SQS Standard garantit au moins une livraison sans garantie d'ordre. FIFO a un débit plus faible sauf en mode haut débit.

Lambda asynchrone échoue suite à un timeout en aval - capturer les événements échoués pour les rejouer.

Destinations Lambda : configurer la destination d'échec comme SQS / SNS / EventBridge / une autre Lambda. Les destinations de succès sont également prises en charge.

Pourquoi: Plus propre qu'une DLQ sur la fonction : les destinations reçoivent l'événement complet + la charge utile de la réponse ; les DLQ ne reçoivent que l'événement déclencheur.

Un workflow multi-étapes nécessite une nouvelle tentative par tâche avec un backoff exponentiel et une capture d'erreur.

Workflow AWS Step Functions Standard. Bloc `Retry` avec `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. Bloc `Catch` achemine les erreurs spécifiques vers un état de récupération.

L'origine CloudFront (S3 ou ALB) échoue - basculer vers une origine secondaire sans modifications DNS.

Groupe d'origines CloudFront avec primaire + secondaire. Configurer les critères de basculement (codes 4xx/5xx). CloudFront réessaie contre la secondaire.

Centraliser les sauvegardes pour EBS, RDS, DynamoDB, EFS, FSx avec une seule politique de rétention.

AWS Backup avec des plans de sauvegarde + sélection des ressources par tag. Copie inter-comptes / inter-régions prise en charge. Vault Lock pour l'immuabilité de la conformité.

Sauvegardes résistantes aux rançongiciels : même un administrateur ne peut pas supprimer avant la rétention.

AWS Backup Vault Lock en mode conformité. Application WORM ; même le compte root ne peut pas raccourcir la rétention.

Choisir un modèle de reprise après sinistre (DR) selon les exigences RPO/RTO.

Sauvegarde et restauration : RPO heures, RTO heures, le moins cher. Veilleuse (Pilot Light) : RPO minutes, RTO dizaines de minutes. Veille chaude (Warm Standby) : RPO secondes, RTO minutes. Multi-Site Actif-Actif : RPO quasi nul, RTO secondes, le plus cher.

Répliquer un compartiment critique inter-régions pour la reprise après sinistre avec un RPO de moins de 15 minutes.

Réplication inter-régions S3 (CRR) avec S3 Replication Time Control (RTC). 99,99% des objets en 15 minutes.

Pourquoi: La CRR standard est "au mieux". RTC ajoute un SLA + des métriques de réplication dans CloudWatch.

Protéger les objets S3 contre la suppression accidentelle et l'écrasement par rançongiciel.

Activer la gestion des versions S3 + la suppression MFA + le verrouillage d'objets (mode gouvernance ou conformité) sur les compartiments critiques.

Pourquoi: La gestion des versions préserve les écrasements/suppressions ; le verrouillage d'objets bloque la suppression avant la rétention ; la suppression MFA ajoute un second facteur pour la suppression permanente.

Une application mondiale a besoin d'un basculement RTO zéro entre deux Régions.

Actif-actif entre les Régions : Global Accelerator ou routage par latence de Route 53 pour l'entrée ; DynamoDB Global Tables / Aurora Global Database pour les données ; réplication inter-régions pour les stockages d'objets.

Trafic TCP/UDP avec faible gigue vers la Région saine la plus proche ; IP anycast statiques.

AWS Global Accelerator. Deux IP anycast ; achemine vers le point de terminaison le plus proche via le backbone AWS.

Pourquoi: Meilleur que la latence de Route 53 pour le trafic non-HTTP. Basculement plus rapide (anycast) + liste blanche d'IP statiques.

Lambda traite les commandes depuis SQS - le message peut être livré deux fois.

Idempotence : stocker le hachage de la requête dans DynamoDB avec TTL ; PUT-IfNotExists à chaque nouvelle tentative. Ou utiliser une file d'attente FIFO avec déduplication.

Les expulsions volontaires de pods (vidange de nœud, autoscaler de cluster) arrêtent toutes les répliques d'un déploiement.

PodDisruptionBudget Kubernetes spécifiant `minAvailable` ou `maxUnavailable`. Le cluster le respecte lors des perturbations volontaires.

Concevoir des architectures hautement performantes

Choisir une classe de stockage S3.

Accès fréquent → Standard. Modèle d'accès inconnu → Intelligent-Tiering. Accès peu fréquent > 30 jours → Standard-IA. Une seule AZ acceptable, accès peu fréquent → One Zone-IA. Archive, récupération en ms → Glacier Instant. Archive, minutes → Glacier Flexible. Archive, heures, le moins cher → Glacier Deep Archive.

Compartiment à accès mixte avec des modèles imprévisibles ; optimisation automatique des coûts.

S3 Intelligent-Tiering. Surveille l'accès ; déplace automatiquement les objets entre les niveaux (Fréquent / Peu fréquent / Archive Instantané / Archive / Archive Profonde). Pas de frais de récupération.

Pourquoi: Petits frais de surveillance par objet, mais moins cher que de se tromper. Par défaut pour les modèles inconnus.

Télécharger de gros objets (> 100 Mo) de manière fiable et rapide sur Internet.

Téléchargement multipartie S3 (parties parallèles) + S3 Transfer Acceleration (ingestion via les points d'accès CloudFront).

Pourquoi: Les parties parallèles saturent la bande passante ; Transfer Acceleration décharge le saut WAN vers le backbone AWS.

Choisir un type de volume EBS.

Usage général, par défaut → gp3 (3000 IOPS de base, 125 Mo/s ; ajustable). Base de données à IOPS élevés → io2 Block Express. Débit séquentiel Big Data → st1. Archive froide → sc1. Volumes de démarrage → gp3.

Pourquoi: gp3 a dissocié les IOPS/débit de la taille ; moins cher que gp2 à performances équivalentes.

Plusieurs instances EC2 doivent lire et écrire sur le même volume de bloc.

EBS Multi-Attach avec io2 / io1 (instances Nitro uniquement). Attachement concurrent à jusqu'à 16 instances dans la même AZ.

Pourquoi: L'application doit coordonner les écritures (système de fichiers en cluster). EFS est la solution par défaut pour l'accès aux fichiers partagés ; Multi-Attach est pour les bases de données en cluster qui nécessitent un stockage par blocs.

Choisir un système de fichiers partagé.

NFS Linux compatible POSIX, multi-AZ, mise à l'échelle automatique → EFS. SMB Windows / intégré à AD → FSx for Windows. HPC, Lustre, lié à S3 → FSx for Lustre. Fonctionnalités NetApp ONTAP (instantanés, outils NetApp) → FSx for ONTAP. ZFS → FSx for OpenZFS.

EFS - choisir le mode de débit.

Charge de travail variable, évolue avec la taille → Mode Rafale (Bursting). Débit élevé prévisible → Mode Provisionné (Provisioned). Sensible aux rafales mais désirant une dépense élastique → Mode Élastique (Elastic) (par défaut pour les nouveaux systèmes de fichiers, s'adapte automatiquement).

Sauvegarde de fichiers/blocs/bandes sur site qui s'intègre avec S3 / Glacier.

AWS Storage Gateway : File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + instantanés EBS), Tape Gateway (VTL → Glacier).

Actifs statiques + réponses API avec des utilisateurs mondiaux ; réduire la charge d'origine.

CloudFront avec une politique de cache appropriée. TTL longs pour les statiques ; la clé de cache inclut uniquement les en-têtes/chaînes de requête essentiels. Utilisez Origin Shield pour les origines à forte cardinalité.

Pourquoi: Le taux de réussite du cache détermine à la fois les performances et les coûts. Une mauvaise clé de cache (par exemple, inclure tous les en-têtes) détruit le taux de réussite.

Manipuler la requête/réponse en périphérie.

Léger, côté visionneur, sub-ms (réécritures d'en-têtes, redirections, A/B) → CloudFront Functions. Plus lourd, Node.js / Python, calcul plus long, accès réseau → Lambda@Edge.

Choisir ElastiCache Redis vs Memcached.

Réplication, persistance, pub/sub, ensembles triés, basculement Multi-AZ → Redis. Multi-thread, simple clé/valeur, sharding horizontal uniquement → Memcached.

Le magasin de sessions Redis nécessite une HA avec basculement automatique entre les AZ.

Groupe de réplication ElastiCache for Redis avec Multi-AZ + basculement automatique activé. Primaire dans une AZ, réplicas dans d'autres.

Latence de lecture DynamoDB de l'ordre des microsecondes ; cache sans modifications d'application.

DynamoDB Accelerator (DAX). Cache géré dans le VPC ; même SDK DynamoDB ; lecture transparente.

Pourquoi: ElastiCache nécessite une logique de cache au niveau de l'application. DAX est une solution prête à l'emploi pour DynamoDB.

Choisir une stratégie de cache.

Chargement paresseux (cache miss → récupération + remplissage) : simple, ne met en cache que ce qui est demandé. Écriture directe (write-through) (écrit dans le cache + la DB lors de la mise à jour) : cache toujours frais, mais écritures supplémentaires. TTL : limite l'obsolescence sur l'un ou l'autre modèle.

Choisir une plateforme de calcul.

Événementiel de moins de 15 minutes, mise à l'échelle en moins d'une seconde, pas d'infra → Lambda. Conteneurs de longue durée, pas de gestion de nœuds → Fargate. Noyau personnalisé, GPU, état persistant, le moins cher soutenu → EC2.

Le démarrage à froid de Lambda Java nuit à la latence p99.

Lambda SnapStart (Java, Python, .NET). Instantané de l'environnement d'exécution initialisé restauré lors de l'invocation ; démarrage à froid jusqu'à 10 fois plus rapide.

Charge de rafale prévisible ; démarrages à froid inacceptables.

Concurrence provisionnée (Provisioned Concurrency). Environnements préchauffés prêts à être invoqués à n'importe quel débit. À combiner avec Application Auto Scaling pour une mise à l'échelle planifiée.

Pourquoi: Coûte plus cher que le mode à la demande mais élimine le démarrage à froid. Non nécessaire pour un trafic stable où l'utilisation de la concurrence provisionnée reste naturellement élevée.

Choisir le type d'API Gateway.

Ensemble complet de fonctionnalités (validation de requête, transformations, clés API, plans d'utilisation) → API REST. Coût inférieur, latence inférieure, natif JWT/OIDC, plus simple → API HTTP. Bidirectionnel en temps réel → API WebSocket.

Application mobile/web nécessitant GraphQL avec des abonnements en temps réel adossés à DynamoDB / Lambda.

AWS AppSync. GraphQL géré, abonnements WebSocket, autorisation fine via Cognito / IAM / autorisateurs Lambda.

Choisir Kinesis Data Streams vs Firehose vs Managed Service for Apache Flink vs MSK.

Consommateurs personnalisés, latence en ms, relecture, diffusion multi-consommateurs → Data Streams. Simplement livrer à S3/Redshift/OpenSearch avec mise en tampon → Firehose. Traitement de flux (fenêtres, jointures) → Managed Service for Apache Flink. Compatible Kafka → MSK.

Les requêtes Athena scannent des téraoctets ; coût / temps excessifs.

Partitionner les données par prédicat de requête (date, région). Convertir au format colonne Parquet/ORC. Utiliser la projection de partition pour éviter les allers-retours du catalogue.

Pourquoi: Athena facture par To scanné. Le format colonne + le partitionnement réduisent souvent les coûts de 10 à 100 fois.

Interroger des données situées dans S3 depuis Redshift sans les charger.

Redshift Spectrum. Schéma externe sur Glue Data Catalog ; les nœuds Spectrum scannent S3 et diffusent les résultats au cluster.

Choisir le mode de capacité DynamoDB.

Charges de travail imprévisibles / en pic / nouvelles → À la demande (On-demand). Charges de travail stables, prévisibles, intenses - et sensibles aux coûts → Provisionné avec auto-scaling. Changer de mode au maximum une fois toutes les 24 heures.

Interroger DynamoDB par un attribut qui n'est pas la clé de partition.

Index secondaire global (GSI) pour les requêtes sur une clé de partition différente. Index secondaire local (LSI) pour une clé de tri alternative sur la même clé de partition (le LSI doit être créé au moment de la création de la table).

La table de sessions DynamoDB croît sans limite ; les sessions expirent après 24h.

DynamoDB TTL sur un attribut d'époque numérique. DynamoDB supprime les éléments expirés de manière asynchrone, aucune capacité d'écriture n'est facturée.

Une charge de travail HPC nécessite la latence inter-nœuds la plus faible possible.

Groupe de placement en cluster : instances dans la même AZ sur le même rack physique. Jusqu'à 10 Gbit/s par flux unique.

Pourquoi: Placement Spread → isolation maximale (HA) ; Partition → Big Data (Hadoop, Cassandra) ; Cluster → latence la plus faible.

Concevoir des architectures optimisées en coûts

Choisir l'option d'achat EC2 pour une flotte stable 24h/24 et 7j/7.

Plan d'Économie de Calcul (1 an ou 3 ans) - 66 % de réduction sur le prix catalogue, flexible sur la famille d'instances, la taille, l'OS, la location, la Région. Les RI uniquement lorsque vous avez besoin d'une réservation de capacité.

Pourquoi: Les Plans d'Économie dominent les RI pour la plupart des cas d'utilisation axés uniquement sur les coûts (plus flexibles, même réduction).

Choisir entre Compute Savings Plan, EC2 Instance Savings Plan et SageMaker Savings Plan.

Compute SP : flexibilité maximale (couvre EC2, Fargate, Lambda) - meilleur par défaut. EC2 Instance SP : verrouillé sur la famille, remise plus importante. SageMaker SP : uniquement SageMaker.

Utiliser Spot pour réduire les coûts des charges de travail tolérantes.

Spot via une politique d'instances mixtes ASG avec une stratégie d'allocation optimisée pour la capacité + plusieurs types d'instances. Gérer l'avis d'interruption de 2 minutes via les métadonnées de l'instance.

Pourquoi: L'optimisation de la capacité choisit les pools les moins susceptibles d'être récupérés. Plusieurs types diversifient le risque du pool.

Avoir des instances réservées (RI) inutilisées après une migration.

Vendre sur le Reserved Instance Marketplace (uniquement les RI Standard). Ou convertir via des RI Convertibles vers une famille différente.

Pourquoi: Les RI Convertibles offrent une réduction légèrement moindre en échange du droit d'échange.

Réduire les coûts de calcul sans réécriture d'architecture.

Migrer vers des instances Graviton (ARM64). Environ 20 % moins cher, environ 40 % de meilleure performance-prix pour de nombreuses charges de travail. Nécessite des images de conteneurs multi-architectures ou des binaires recompilés.

Fonctions Lambda où l'environnement d'exécution prend en charge ARM.

Définir l'architecture sur `arm64` (Graviton). 20% moins cher par ms que x86, souvent plus rapide. Nécessite des dépendances natives compatibles avec l'architecture.

Coût Lambda trop élevé ; exécution limitée par le CPU.

Augmenter la mémoire (ce qui fait évoluer le CPU et le réseau proportionnellement). Utiliser Lambda Power Tuning (outil Step Functions) pour trouver le point optimal - souvent plus de mémoire est plus rapide ET moins cher.

Les journaux et les anciens objets s'accumulent dans S3 Standard.

Règles de cycle de vie S3 : transition vers IA après 30 jours, Glacier Flexible après 90 jours, Deep Archive après 180 jours, expiration après rétention. À combiner avec Intelligent-Tiering pour les modèles inconnus.

Visualiser les dépenses S3 à travers les comptes ; trouver des candidats à l'optimisation.

S3 Storage Lens. Tableau de bord à l'échelle de l'organisation avec l'utilisation, l'activité, les recommandations d'économie de coûts. Niveau de métriques avancées pour une ventilation au niveau des préfixes.

Les frais de traitement des données de NAT Gateway dominent la facture.

Remplacer le trafic des services AWS par des VPC Endpoints (passerelle pour S3/DynamoDB ; interface pour tout le reste). Déplacer les charges de travail nécessitant une sortie Internet vers des sous-réseaux publics uniquement si nécessaire.

Pourquoi: NAT Gateway facture par Go traité même pour le trafic des services AWS. Les points de terminaison éliminent ce chemin.

Réduire les coûts de transfert de données.

Même AZ, même VPC = gratuit. Inter-AZ = 0,01 $/Go dans chaque sens. Inter-région = cher. Sortie vers Internet = le plus cher mais gratuit via CloudFront pour le contenu cachable. Toujours sortir via CloudFront lorsque c'est possible.

Les coûts de CloudWatch Logs s'envolent.

Définir une rétention explicite (le défaut est "Ne jamais expirer"). Exporter les anciens journaux vers S3 + Glacier. Utiliser Logs Insights uniquement sur les données chaudes. Filtrer au niveau de l'agent (ne pas envoyer les journaux de débogage en production).

Trouver des candidats à l'ajustement de taille (right-sizing) pour EC2, Auto Scaling Groups, EBS, Lambda.

AWS Compute Optimizer. Lit les métriques CloudWatch + ML, recommande de réduire la taille ou de changer de famille. Gratuit pour l'option à l'échelle de l'organisation.

Détecter les pics de dépenses inattendus de manière proactive.

Détection d'anomalies de coût AWS (dans Cost Explorer). Surveille les services / comptes liés / catégories de coûts basés sur le ML. Alertes via SNS / e-mail.

Arrêter les dépenses incontrôlées dans un compte sandbox.

AWS Budgets avec action : à 80 % du seuil, exécuter une notification SNS ; à 100 %, attacher une politique SCP / IAM de refus via une action Budgets.

Rétrofacturation par équipe ou par produit sans comptes séparés.

Tags d'allocation de coûts. Activer les tags définis par l'utilisateur dans la console de facturation ; afficher dans Cost Explorer + CUR. Combiner avec `aws:CreatedBy` pour l'attribution d'identité.

Les instances EC2 de développement/test fonctionnent 24h/24 et 7j/7 - utilisées seulement de 9h à 17h.

AWS Instance Scheduler (fonction Lambda déployée par CloudFormation). Tagger les instances avec des noms de planning ; exécute des démarrages/arrêts de type cron. Ou simplement `aws:autoscaling:scheduledActions` sur les ASG de développement.

Pourquoi: Réduction d'environ 70 % des dépenses de calcul de développement avec un arrêt hors heures de bureau.

Instance RDS de développement inactive la nuit/les week-ends.

Arrêter l'instance RDS (mono-AZ ; jusqu'à 7 jours, puis redémarre automatiquement). Ou Aurora Serverless v2 avec min ACU = 0,5 (pas d'arrêt complet, mais coût minimal en inactivité).

Optimisation des coûts de la flotte de conteneurs.

Utilisation stable et élevée → ECS sur EC2 (avec Spot/Savings Plans) - le moins cher. En pointe / de courte durée / pas de gestion de nœuds → Fargate. Fargate Spot est 70% moins cher que Fargate pour les charges de travail tolérantes.

Réduire les sorties S3 / EC2 vers Internet.

Utiliser CloudFront en façade. Transfert origine → périphérie est gratuit ; périphérie → utilisateur est moins cher que la sortie directe EC2/S3 à grande échelle. Activer la compression + des TTL appropriés.

Migrer 100 To de NFS sur site vers S3.

Agent AWS DataSync sur site ; transfert planifié vers S3. Chiffré, vérifié en intégrité, limité en débit. Snowball Edge pour 100 To+ ou faible bande passante.

Déplacer > 1 Po de l'environnement sur site vers AWS ; bande passante trop lente pour un transfert en ligne.

Famille AWS Snow. Snowball Edge Storage Optimized (80 To) pour les cas typiques ; plusieurs appareils en parallèle pour des centaines de To. Snowmobile est retiré - utiliser plusieurs Snowball pour des échelles de pétaoctets.

RDS / ElastiCache / OpenSearch / Redshift de production fonctionnant 24h/24 et 7j/7.

Instances Réservées pour les bases de données gérées (pas d'équivalent Savings Plan pour ces services). 1 an ou 3 ans ; paiement partiel à l'avance généralement le meilleur NPV.

Gains rapides et à faible effort en matière de coûts sur le compte.

Vérifications des coûts d'AWS Trusted Advisor : équilibreurs de charge inactifs, EC2 sous-utilisées, EBS non attachés, RDS sous-utilisées, Redshift inactifs. Le niveau gratuit est limité ; ensemble complet avec support Business / Enterprise.