Amazon SOA-C02: Gestion des coûts et étiquetage des ressources — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. 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.

Transfert de données et facteurs de coût spécifiques aux services

Le réseau et le stockage sont des facteurs de coût courants et très variables. Comprenez ces spécificités :

• Transfert de données : la sortie (egress) inter-régions est facturée par Go ; le trafic inter-AZ peut être gratuit ou payant selon le service (certains services facturent le trafic inter-AZ). Les frais de NAT Gateway incluent des frais horaires plus les Go traités — les factures de NAT Gateway peuvent dominer les coûts de sortie pour les charges de travail à haut débit.
• Répartiteurs de charge : ALB/NLB entraînent des frais par heure et par Go traité ; un trafic avec beaucoup de redirection augmente les coûts.
• S3/EBS : la tarification du stockage S3 dépend de la classe (Standard, Intelligent-Tiering, Glacier) et des requêtes ; les politiques de cycle de vie déplacent les objets vers des niveaux à moindre coût pour réduire les dépenses de stockage. Le stockage des snapshots EBS est facturé par Go-mois et pour les opérations de copie inter-régions.
• Services gérés : les I/O de RDS, la capacité de lecture/écriture et les sauvegardes à la demande de DynamoDB, ainsi que les coûts de stockage et de snapshot d’ElasticSearch (OpenSearch Service).

Tactiques d’optimisation :

• Utilisez des points de terminaison VPC pour S3 afin de réduire la sortie vers Internet et utilisez S3 Transfer Acceleration ou CloudFront pour réduire la sortie de l’origine lors de la desserte d’utilisateurs mondiaux.
• Consolidez le trafic inter-régions ou co-localisez les services dans la même région pour éviter la sortie inter-régions.
• Remplacez les NAT Gateways par des points de terminaison VPC, des Gateway Load Balancers ou des instances NAT lorsque c’est approprié et après avoir testé les compromis de performance.

Pièges courants et critères de décision

• Laisser des ressources non balisées et non comptabilisées : imposez des balises obligatoires avec AWS Config et utilisez l’API de balisage des groupes de ressources (Resource Groups Tagging API) pour trouver et corriger automatiquement les ressources non balisées.
• Méconnaissance de la portée des Savings Plan/RI : confirmez si les Compute Savings Plans (inter-services) ou les EC2 Instance Savings Plans / RI (portée par famille/zone) correspondent à vos charges de travail avant de vous engager.
• Se fier uniquement au CPU pour le redimensionnement (rightsizing) : incluez les métriques de mémoire, de réseau et d’IOPS disque (CloudWatch et Compute Optimizer) pour éviter les régressions de performance après un redimensionnement à la baisse.
• Ignorer les coûts de transfert de données entre régions/services : cartographiez les flux de trafic, mesurez la sortie via les VPC Flow Logs/Athena, et co-localisez les gros producteurs/consommateurs ou utilisez CloudFront/points de terminaison VPC.
• Mauvaise configuration du budget : choisissez judicieusement entre Réel (Actual) et Prévisionnel (Forecasted) et attachez des actions programmatiques (SNS → Lambda) pour limiter ou notifier de manière précoce.
• Laisser des stockages/snapshots orphelins et des ELB inactifs : planifiez un nettoyage automatisé pour les volumes EBS non attachés, les snapshots obsolètes et les répartiteurs de charge inutilisés.

Problème pratique : Scénario d’utilisation

ApexAnalytics connaît une augmentation des coûts de 40 % d’un mois sur l’autre après une campagne marketing ; les ingénieurs ont lancé de nombreuses piles de développement dans plusieurs régions et se sont appuyés sur des NAT Gateways pour l’accès à Internet. L’équipe financière a besoin d’une visibilité et d’une correction immédiates.

1. Activez les rapports CUR horaires avec les ID de ressources et livrez-les dans un compartiment S3 dédié aux coûts ; créez une table Athena pour interroger les principaux facteurs de coût par linkedAccountId, région et usageType.
2. Activez et imposez les balises de répartition des coûts (Cost Allocation Tags) (CostCenter, Project, Owner) via les Tag Policies et les balises obligatoires d’AWS Config, et remplissez rétroactivement les balises manquantes à l’aide de l’API Resource Groups Tagging.
3. Exécutez les rapports de redimensionnement de Cost Explorer et de Compute Optimizer, identifiez la charge de calcul de base stable et achetez un Savings Plan approprié pour les heures de base ; planifiez un redimensionnement à la baisse pour les instances sous-utilisées.
4. Auditez la sortie réseau avec VPC Flow Logs → Athena ; remplacez les NAT Gateways par des points de terminaison VPC lorsque c’est possible et centralisez les charges de travail de test régionales pour éviter les transferts inter-régions.
5. Créez des budgets AWS Budgets avec des seuils prévisionnels, attachez SNS pour déclencher Lambda afin de mettre en quarantaine les comptes de développement non critiques ou de notifier les propriétaires, et activez Cost Anomaly Detection pour les pics soudains.

Justification : La livraison des rapports CUR et l’application des balises permettent une refacturation précise et une analyse historique. Le redimensionnement (rightsizing) et les engagements mesurés (Savings Plans) réduisent les dépenses prévisibles, tandis que les optimisations réseau et les actions budgétaires automatisées préviennent les futurs coûts de sortie imprévus.

← Serverless et intégration d’applications · Tous les domaines

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

Parcourir Amazon →