Quiz : Stockage AWS : plus de 20 questions!

S3 signifie Simple Storage Service. C’est un service de stockage d’objets évolutif conçu pour le stockage de données à grande échelle.

AWS S3 propose plusieurs classes de stockage :

• Standard : pour les données fréquemment consultées
• Accès Infrequent (IA) : coût réduit pour un accès moins fréquent
• Glacier : stockage d’archivage à long terme et à faible coût

Chaque classe propose des tarifs et des caractéristiques d’accès différents, permettant d’optimiser les coûts en fonction des modèles d’utilisation des données.

En savoir plus sur les classes de stockage S3

DynamoDB est considéré comme « sans schéma » parce qu’il vous permet de stocker des propriétés arbitraires dans les éléments sans schéma prédéfini.

DynamoDB Best Practices

La clé ici est updates, pas les insertions ou les PUTs. Si vous effectuez des insertions, vous pouvez utiliser BatchWriteItem ou TransactWriteItems.

Bien que BatchWriteItem puisse gérer plusieurs opérations, il est limité aux PUTs et aux DELETEs. TransactWriteItems est plus puissant, mais c’est un peu le marteau-piqueur pour des mises à jour simples. Pour des mises à jour simples, UpdateItem est le meilleur choix. Il vous permet de UPDATE, ou de modifier un ou plusieurs attributs d’un élément existant.

L’opération UpdateItem modifie un élément par requête. Pour de gros remplissages ou des mises à jour en masse, vous orchestrez généralement de nombreux appels UpdateItem ou utilisez un workflow plus large comme l’exécution par lots PartiQL, Step Functions, Glue, EMR, ou un processus worker personnalisé.

L’opération UpdateItem :

• Met à jour les attributs d’un élément existant.
• Ajoute de nouveaux attributs à un élément existant.
• Supprime des attributs d’un élément existant.
• Effectue conditionnellement la mise à jour si l’élément existe ou satisfait certaines conditions.

DynamoDB UpdateItem

OpenSearch est le service géré d’AWS pour la recherche, l’analyse de logs et les charges de travail de recherche en texte intégral.

Les distracteurs sont des services utiles, mais ils ne sont pas le moteur de recherche conçu spécifiquement dans cette liste :

• ElastiCache : Principalement un cache en mémoire. L’ElastiCache actuel pour Valkey inclut des commandes de recherche pour des données indexées en mémoire, il n’est donc plus exact de dire que le service n’a aucune recherche intégrée.
• Neptune : Base de données graphe ; il peut s’intégrer à OpenSearch pour la recherche en texte intégral.
• Redshift : Entrepôt de données pour l’analyse SQL.
• DocumentDB : Base de données de documents avec recherche texte compatible MongoDB dans les versions prises en charge.

Les zones de disponibilité (AZ) sont des centres de données distincts dans une région. Le déploiement RDS Multi-AZ fournit un basculement automatique vers une réplique de secours dans une AZ proche.

Déploiement Multi-AZ:

• Fournit un basculement automatique
• Augmente la disponibilité de la base de données
• Crée une réplique de secours synchrone
• Minimise les temps d’arrêt lors des pannes d’infrastructure

Ne confondez pas le déploiement Multi-AZ avec les réplicas de lecture, qui servent à mettre à l’échelle les opérations de lecture.

API Gateway prend en charge les API WebSocket bidirectionnelles, mais l’implémentation est gérée par API Gateway plutôt que d’être un socket direct vers votre propre processus serveur. API Gateway maintient la connexion client et achemine les messages vers Lambda, des points de terminaison HTTP ou d’autres intégrations. Les messages peuvent être renvoyés aux clients connectés via l’API de gestion d’API Gateway.

Les autres services sont beaucoup plus adaptés aux WebSockets :

• Lightsail : Idéal pour des configurations WebSocket simples 👌
• AppSync : Utilise les WebSockets pour les abonnements GraphQL gérés
• EC2 : Votre option classique « faites ce que vous voulez » pour les WebSockets
• EKS : Parfait pour faire tourner des clusters WebSocket évolutifs

Astuce pro : Si vous avez besoin de la puissance brute des WebSockets, restez avec les services de calcul !

Dans pratiquement TOUS les systèmes, adopter une conception « moindre privilège » est un moyen essentiel de renforcer la sécurité et d’assurer la pérennité. Tenter de verrouiller un système existant est aussi difficile que de déplacer tout un immeuble de bureaux sur de nouvelles fondations.

Les buckets S3 ne font pas exception. Pour appliquer le principe du moindre privilège, commencez sans aucune permission et accordez uniquement l’accès nécessaire. Utilisez les rôles et les politiques IAM pour contrôler l’accès et auditez régulièrement les permissions des buckets.

Bonnes pratiques de sécurité :

• Appliquer le principe du moindre privilège
• Commencer sans permissions
• Accorder uniquement l’accès nécessaire
• Utiliser les rôles et les politiques IAM
• Auditer régulièrement les permissions des buckets

Évitez les réglages trop permissifs qui pourraient exposer des données sensibles.

S3 Security Best Practices

Aurora Serverless :

• Redimensionne automatiquement la capacité de calcul
• Ajuste les ressources en fonction de la charge de travail
• Idéal pour les charges de travail imprévisibles
• Vous ne payez que pour les ressources réellement utilisées

Parfait pour les applications avec des schémas de trafic variables.

Aperçu d’Aurora Serverless

Le SDK DynamoDB vous permet de récupérer jusqu’à 100 éléments dans une seule requête BatchGetItem. C’est plus élevé que la limite pour BatchWriteItem, qui est de 25 éléments. De plus, il existe des limites sur la taille totale du payload, la taille du document et le taux de requêtes.

Comprendre ces limites est essentiel pour optimiser les performances de votre application et garantir des opérations de données efficaces.

Note : Il est possible de dépasser certaines de ces limites – si vous savez convaincre votre responsable de compte AWS. 😎

Les clients DynamoDB sont essentiellement des wrappers de son API HTTP. L’opération BatchWriteItem peut PUT ou DELETE jusqu’à 25 documents par requête HTTP, mais elle ne peut pas UPDATE plusieurs documents.

Bien que DynamoDB puisse INSERT jusqu’à 25 documents par requête HTTP, il ne peut UPDATE qu’1 document par requête en utilisant l’opération UpdateItem.

La capacité à la demande est idéale pour :

• Charges de travail imprévisibles
• Trafic sporadique
• Applications aux modèles d’accès inconnus
• Éviter le sur‑approvisionnement

La capacité provisionnée est préférable pour :

• Charges de travail prévisibles et constantes
• Plus de contrôle sur les performances
• Économies potentielles

Modes de capacité DynamoDB

Astuces de performance S3 :

• S3 moderne ajuste automatiquement les taux de requêtes par préfixe
• Vous n’avez pas besoin de préfixes aléatoires ou de hachage pour les performances
• Utilisez des noms de clés logiques adaptés à vos modèles d’accès
• Surveillez les réponses 503 Slow Down si vous poussez des taux de requêtes très élevés

Les anciennes recommandations préconisaient de randomiser les préfixes pour éviter les partitions chaudes, mais AWS ne recommande plus cela comme exigence de performance par défaut.

S3 Performance Guidelines

Meilleures pratiques de sauvegarde :

• Activer les sauvegardes automatisées
• Utiliser la récupération point‑en‑temps
• Conserver les sauvegardes selon les exigences de conformité
• Tester régulièrement le processus de restauration
• Envisager une sauvegarde multi‑région

Les sauvegardes automatisées offrent :

• Protection continue des données
• Options de récupération flexibles

Meilleures pratiques de sauvegarde RDS

Avantages de Redis :

• Prend en charge des structures de données complexes
• Options de persistance
• Opérations avancées
• Messagerie Pub/Sub

Memcached :

• Stockage clé‑valeur simple
• Cache pur
• Haute performance pour les cas d’utilisation simples

Redis vs Memcached

Index secondaire global (GSI) :

• Permet d’interroger des attributs qui ne sont pas la clé primaire
• Crée des modèles d’accès alternatifs
• Augmente la flexibilité des requêtes
• Engendre un coût supplémentaire de capacité d’écriture

Utile pour des exigences de requêtes complexes au‑delà de la clé primaire.

Index DynamoDB

Gestion du cycle de vie :

• Transférer automatiquement les objets entre les classes de stockage
• Déplacer les données peu utilisées vers un stockage moins cher
• Définir des règles d’expiration des objets
• Optimiser les coûts de stockage
• Réduire la charge de gestion manuelle

Règles du cycle de vie S3

Amazon Aurora prend en charge jusqu’à 15 répliques de lecture, ce qui vous permet de faire évoluer considérablement vos opérations de lecture. Ces répliques bénéficient de :

• Réplique quasi instantanée entre les répliques
• Impact minimal sur les performances de l’instance principale
• Distribution efficace des charges de travail en lecture

Cette configuration permet une mise à l’échelle horizontale pour les applications à forte demande de lecture.

En savoir plus sur les répliques Aurora

Fonctionnalités de chiffrement RDS :

• Chiffrer les données au repos avec KMS
• Chiffrer les données en transit avec SSL/TLS
• Activer le chiffrement lors de la création de la base de données
• Protéger les informations sensibles
• Conformité aux normes de sécurité

Options de chiffrement RDS

DynamoDB Streams :

• Capturer les changements au niveau des éléments
• Permettre les architectures événementielles
• Déclencher des fonctions Lambda
• Prendre en charge la réplication inter-régions
• Fournir un déplacement de données quasi en temps réel

Vue d’ensemble de DynamoDB Streams

Avantages du téléchargement multipart :

• Gérer efficacement les gros fichiers
• Reprendre les téléchargements interrompus
• Télécharger en parallèle les parties du fichier
• Recommandé pour les fichiers > 100 Mo
• Fiabilité réseau améliorée

Téléchargement multipart S3

Stratégie de stockage optimale:

• 20 % en S3 Standard pour un accès quotidien
• 30 % en S3 Standard‑IA pour un accès mensuel
• 50 % en Glacier pour un accès annuel

Cette approche optimise les coûts tout en respectant les modèles d’accès appropriés.

Considérations de coût:

• Tarification du stockage par Go
• Coûts de récupération
• Modèles d’accès
• Coûts de transition

Comprendre les modèles de cohérence de DynamoDB est essentiel :

• 1 RCU = 1 lecture fortement cohérente/seconde pour des éléments jusqu’à 4 KB
• 1 RCU = 2 lectures éventuellement cohérentes/seconde pour des éléments jusqu’à 4 KB

Donc :

• 100 RCUs = 100 lectures fortement cohérentes de 4 KB/seconde
• 100 RCUs = 200 lectures éventuellement cohérentes de 4 KB/seconde

Choisissez le modèle de cohérence en fonction de :

• Les exigences de l’application
• Les considérations de coût
• Les besoins de performance
• Les exigences de fraîcheur des données

Processus de basculement Aurora :

1. Détecte la défaillance de l’instance principale
2. Sélectionne une réplique Aurora principalement selon le niveau de priorité de basculement
3. Utilise les caractéristiques de l’instance comme critères de départage lorsque les priorités sont identiques
4. Met à jour automatiquement le point de terminaison du cluster

Bonnes pratiques :

• Conservez plusieurs répliques dans différentes zones de disponibilité
• Configurez intentionnellement les niveaux de promotion
• Utilisez le point de terminaison du cluster dans les applications
• Testez régulièrement les scénarios de basculement

Modèle de cohérence S3 :

• Cohérence forte en lecture après écriture pour toutes les opérations
• S’applique aux PUT et DELETE
• Aucun besoin de contournements auparavant utilisés
• Aucun coût supplémentaire

Impact :

• Logique d’application simplifiée
• Pas besoin de vérifications de cohérence
• Lectures immédiates fiables après écriture
• Fiabilité accrue de l’application

Caractéristiques du TTL DynamoDB :

• Un processus en arrière-plan surveille l’attribut TTL
• Les éléments expirés sont supprimés selon un planning au meilleur effort, généralement en quelques jours
• Aucun coût supplémentaire pour le TTL
• Les éléments supprimés apparaissent dans les flux

Cas d’utilisation :

• Gestion de sessions
• Expiration de journaux
• Nettoyage de données temporaires
• Conformité réglementaire

Mise à l’échelle d’Aurora Serverless :

• Aurora Serverless v2 ajuste la capacité par incréments fins d’ACU
• La vitesse de mise à l’échelle dépend de la capacité actuelle et des paramètres min/max d’ACU
• Les versions prises en charge peuvent se mettre en pause automatiquement à 0 ACU lorsqu’elles sont configurées
• Facturation à la seconde basée sur les ACU

Bonnes pratiques :

• Fixer une capacité minimale suffisamment élevée pour absorber les pics soudains sur les charges critiques
• Surveiller les événements de mise à l’échelle
• Garder la gestion des connexions à l’esprit