Membre depuis le 23/05/2019
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.
Membre depuis le 25/11/2018
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é.
Membre depuis le 09/09/2024
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.
Membre depuis le 04/12/2019
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.
Membre depuis le 23/05/2019
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.
Membre depuis le 09/09/2024
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.
Membre depuis le 04/12/2019
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.
Membre depuis le 23/05/2019
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.
Membre depuis le 09/09/2024
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.
Membre depuis le 25/11/2018
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é !
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
aurelie-dupre
Membre depuis le 25/11/2018
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 ?