SW BBANG F

Vous venez de créer un bucket S3 contenant des données sensibles et la console vous demande de choisir entre une clé gérée par AWS et une clé gérée par le client. Ce choix semble anodin, mais en production, il détermine qui contrôle réellement vos données, ce que vous payez chaque mois, et ce qui se passe si une clé est désactivée par erreur. Résumé (TL;DR) : AWS KMS et chiffrement S3 Critère Clé Gérée AWS (aws/s3) Clé Gérée Client (CMK) Création et rotation Automatique, gérée par AWS Manuelle ou automatique selon config Contrôle des politiques Aucun contrôle direct Politique de clé personnalisable Audit CloudTrail Partiel (appels S3 visibles) Complet (chaque appel KMS tracé) Coût mensuel Gratuit Voir tarification officielle AWS KMS Partage inter-comptes Non ...

Une instance EC2 disparaît sans explication un matin — aucune alerte, aucun ticket, et l'équipe pointe dans toutes les directions. Retrouver qui a déclenché l'action TerminateInstances est exactement le cas d'usage pour lequel CloudTrail Event History existe, à condition de savoir où chercher et comment interpréter ce qu'on y trouve. TL;DR — Retrouver l'auteur d'une suppression EC2 Étape Action Ce qu'on obtient 1 Ouvrir CloudTrail Event History Journal des appels API des 90 derniers jours 2 Filtrer sur TerminateInstances Liste des événements de terminaison 3 Identifier l'instance cible Correspondance par ID de ressource 4 Lire le champ userIdentity IAM user, rôle assumé, ou service AWS 5 Corréler avec sourceIPAddress et userAgent Contexte d'exécution (console, CLI, SDK) Comment CloudTrail enregistre les actions EC2 CloudTrail capture les appels API effectu...