Cloud Cost Auditor prompts

Tu es un consultant FinOps senior. J'ai exporté ma facture <PROVIDER> du mois dernier au format CSV. Voici les 30 lignes les plus chères :

<COLLE_LE_CSV_OU_LISTE_LES_30_LIGNES>

Analyse en 5 sections :

1. **Top 3 services qui coûtent le plus** — pour chacun : nom du service, % de la facture totale, et l'usage typique correspondant.
2. **Lignes suspectes ou anormales** — repère ce qui semble disproportionné (ex: 8000$ d'EBS provisioning sans EC2 actif = volumes orphelins, ou Data Transfer Out > 30% de la facture = problème CDN/égress).
3. **Top 5 quick wins** — pour chaque ligne suspecte, donne-moi : (a) la cause probable, (b) l'action concrète (commande CLI ou clic console), (c) l'économie mensuelle estimée.
4. **Lignes 'normales' mais optimisables** — services bien utilisés mais qui pourraient passer en Reserved Instance / Savings Plan / Committed Use Discount. Estime le ROI.
5. **Une question de diagnostic** que je dois aller poser à l'équipe dev avant de prendre la moindre décision (ex: 'cet RDS de 500GB est-il vraiment utilisé en prod ou c'est un legacy ?').

Format : tableau pour 1-4, un seul bullet pour 5. Pas de préambule.

Tu es un consultant FinOps. Je te donne une liste de VMs (EC2 / Compute Engine / Azure VMs) avec leurs métriques d'utilisation moyenne sur les 30 derniers jours.

Format de mes données (CSV ou liste) :
Instance | Type | vCPU | RAM | CPU avg % | RAM avg % | Network in/out (GB) | Coût/mois

Mes VMs :
<COLLE_LES_DONNÉES>

Pour chacune, donne-moi en tableau :

1. **Verdict** : OK / À downsize / À supprimer / À investiguer
2. **Recommandation type d'instance** : si downsize, propose l'instance plus petite (ex: t3.large → t3.medium si CPU<20%)
3. **Économie estimée** : $/mois
4. **Risque** : faible / moyen / élevé (élevé = si CPU peak >80%, downsize risquerait de saturer)
5. **Action requise** : commande aws CLI / gcloud / az CLI pour faire le changement

Règle : ne propose JAMAIS de supprimer une VM sans demander à voir au moins 7 jours d'historique des connexions sortantes (sinon tu peux killer un cron caché). Demande explicitement les logs SSM / Cloud Logging avant.

Tu es un consultant FinOps spécialisé en object storage. J'ai un bucket <PROVIDER> avec les caractéristiques suivantes :

- Volume total : <X> To
- Classes de stockage actuelles : <ex: 100% S3 Standard>
- Coût mensuel : <Y>€
- Description des données : <DECRIS_LES_DONNÉES — ex: 'logs applicatifs des 5 dernières années, accédés en moyenne 1x par semaine pour debugging'>
- Pattern d'accès observé (si dispo) : <ex: 'derniers 30j accédés, plus rien après'>
- Contrainte de rétention : <ex: 'compliance 7 ans'>

Donne-moi :

1. **Recommandation de lifecycle policy** sous forme de JSON prêt à coller (AWS Lifecycle Rule, GCS Lifecycle, Azure Blob Lifecycle).
2. **Pour chaque transition** (Standard → IA → Glacier / Coldline / Archive) : à partir de combien de jours, et pourquoi à ce délai.
3. **Économie mensuelle estimée** à 6 mois et à 12 mois après mise en place de la policy.
4. **Risque de retrieval** : si je dois récupérer des données archivées, quel délai + quel coût supplémentaire.
5. **Une checklist pré-déploiement** : 5 vérifications à faire AVANT d'activer la policy (ex: vérifier que les apps n'ont pas hardcodé l'attente d'un accès < 100ms).

Ajoute un warning explicite si je risque de casser une dépendance (ex: 'Glacier Deep Archive a un délai de retrieval de 12h, incompatible avec tout dashboard temps réel').

Tu es un consultant FinOps. Je te donne mon profil de workload et tu me proposes la meilleure stratégie d'engagement <PROVIDER>.

Mon profil :
- Nombre d'instances : <X>
- Type d'instances : <ex: m5.large + r5.xlarge>
- Stabilité de l'usage : <stable 24/7 | variable jour/nuit | très bursty | dev only>
- Horizon d'utilisation prévisible : <6 mois | 1 an | 3 ans>
- Cash flow constraint : <fort | modéré | aucun>
- Tolérance à l'interruption : <aucune (prod critique) | modérée (workers batch) | forte (CI/CD)>

Donne-moi :

1. **Recommandation principale** (en 1 phrase claire) : ex 'Compute Savings Plan 1 an, all upfront, couvrant 70% de la baseline'.
2. **Mix optimal** sous forme de tableau : pour chaque tranche d'instances, quel modèle d'engagement, % couvert, et économie estimée vs 100% on-demand.
3. **ROI breakeven** : à partir de combien de mois l'engagement est rentable, et que se passe-t-il si je résilie avant.
4. **Risques** : 3 scénarios qui rendraient mon plan moins bon (ex: 'si tu pivot vers Graviton dans 6 mois, ton RI x86 devient inutile').
5. **Action plan** : 3 étapes concrètes dans l'ordre, avec qui doit valider (CTO / CFO / DevOps lead) avant de cliquer.

Règle : ne recommande JAMAIS un engagement 3 ans si l'horizon de l'entreprise est <2 ans (early-stage). Préfère Savings Plan 1 an ou Spot Fleet pour workloads bursty.

Tu es un consultant FinOps + networking. J'observe un pic anormal de coûts 'Data Transfer Out' / 'Egress' sur ma facture <PROVIDER>.

Contexte :
- Service / région concerné(e) : <ex: us-east-1, NAT Gateway>
- Volume sur le mois : <X> TB sortants
- Coût correspondant : <Y>€
- Architecture (résumé) : <ex: 'webapp Lambda + RDS Postgres + S3 statics + CloudFront devant'>
- Changement récent : <ex: 'on a déployé un microservice il y a 3 semaines' / 'aucun'>

Aide-moi à localiser la fuite :

1. **Hypothèses les plus probables** (top 5, ordonnées par fréquence en production) : ex 'cross-AZ traffic non optimisé', 'NAT Gateway au lieu de VPC Endpoint pour S3', 'CloudWatch Logs vers une région différente', 'pulls Docker depuis Internet au lieu d'ECR', 'log shipping vers Datadog hors-région'.
2. **Pour chaque hypothèse** : la commande/dashboard CloudWatch / VPC Flow Logs / Network Insights à utiliser pour confirmer ou écarter (donne-moi le query exact si possible).
3. **Fix concret** pour chacune : ex 'remplacer NAT Gateway par VPC Endpoint Gateway pour S3 → économie ~0.045/GB → ~10x'.
4. **Une question critique** à poser à l'équipe avant tout fix (ex: 'le microservice X cross-region est-il intentionnel pour DR ou c'est un placement par défaut ?').

Format : tableau pour 1-3, bullet pour 4.