10 commentaires
Salut ! pour RDS, regarde les IOPS (read/write), les sauvegardes (rétention, snapshots manuels non supprimés), les logs (performance insights). pour S3 : l'accès inter-région, les requêtes (GET/PUT/LIST), les transferts de données (data out) et le versioning. Souvent, c un truc qui pompe des gigas en data transfer ou des IOPS fantômes.
Les IOPS RDS sont ok, pas de pic suspect. Les backups sont automatisés standard (7 jours). S3 j'ai pas de transferts inter-région, on est sur un seul bucket avec le versioning activé.
Le versioning S3 peut être super traître. Chaque version d'un objet est stockée et facturée. Si une app fait beaucoup de PUT/DELETE sur des objets versionnés, le bucket peut grossir super vite sans que tu le voies directement dans la taille affichée "active". Utilise aws s3api list-object-versions pour voir toutes les versions et leur taille.
pour rds, t'as check si quelqu'un a pas provisionné une instance de dev ou de test qui tourne h24 et qui n'est pas taggée ou qui a pas été éteinte ? ou un storage qui a auto-scale mais qui n'est pas redescendu après un pic ? regarde les métriques cloudwatch freestoragespace et volumebytesused pour tes instances rds.
Et les requêtes S3 ? Beaucoup de requêtes GET/PUT/LIST peuvent coûter cher si t'en as des millions. Mets en place des S3 Access Logs sur ton bucket pour voir qui fait quoi et combien de requêtes sont générées. C'est crucial pour comprendre l'utilisation.
Y a aussi les transferts de données de RDS vers l'extérieur d'AWS ou même vers des AZ différentes. Même au sein du même VPC, des transferts entre AZ sont facturés si c'est pas explicite. Check DataTransfer-Out métriques dans CloudWatch pour ton RDS.
Est-ce que t'as des lifecycle policies sur S3 ? si tu n'as pas de règles pour purger les anciennes versions ou les versions non courantes, tes anciennes versions et tes objets "supprimés" (mais versionnés) restent éternellement et sont facturés.
pour rds, un petit coup d'œil aux dbinstanceclass et multiaz dans la console. des fois, on se retrouve avec une instance super puissante (genre un db.r6g.xlarge) ou en multiaz sans s'en rendre compte pour une app non critique. c'est un coût de base énorme.
Et le logging RDS lui-même. Si tu forwardes les logs (error, general, slowquery) à CloudWatch Logs, ça coûte aussi. C'est de l'ingestion de données et du stockage de logs. Si tu as une instance verbeuse, ça peut chiffrer.
OUAH ! merci les gars, j'ai trouvé les coupables ! pour S3, c'est exactement le versioning combiné à une nouvelle fonctionnalité qui faisait des PUT/DELETE en boucle sur des petits fichiers. le bucket était plein de versions obsolètes et je n'avais pas de lifecycle policy. pour RDS, c'était bien une petite instance de test oubliée, elle n'était pas taggée et impossible de la retrouver dans les filtres habituels. j'ai pu la choper via VolumeBytesUsed. énorme merci pour les pistes, vous m'avez sauvé !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut tout le monde ! j'ai une galère avec notre facture AWS ce mois-ci. les coûts RDS et S3 ont littéralement doublé sans qu'on ait eu de gros pic de trafic ou de changements majeurs côté infra/app. On est sur du Postgres RDS et S3 Standard. Je sèche un peu pour savoir d'où ça vient. Des idées de pistes à explorer ?