AWS Well-Architected Framework : Le pilier Cost Optimization, l'art de payer juste

Publié le 23 octobre 2025 par Mathieu Roger

Introduction : Le mythe du Cloud “moins cher”

“Le Cloud, c’est moins cher que l’on-premise.” C’est probablement l’affirmation la plus répétée — et la plus dangereuse — de ces dix dernières années.

La vérité ? Le Cloud peut être moins cher… si vous savez ce que vous faites. Sans discipline, sans gouvernance, sans mesure, le Cloud devient rapidement un gouffre financier. J’ai vu des factures AWS exploser de 500% en quelques mois parce que personne ne regardait le compteur.

Le pilier Cost Optimization du AWS Well-Architected Framework n’est pas un pilier de “réduction des coûts à tout prix”. C’est un pilier de dépenses justes : payer pour ce qui apporte de la valeur métier, pas un centime de plus, pas un centime de moins.

La différence entre une architecture Cloud profitable et une architecture Cloud ruineuse ne tient souvent qu’à quelques principes simples :

Mesurer où va chaque euro
Dimensionner correctement les ressources
Adapter dynamiquement aux besoins
Exploiter les modèles de pricing intelligents
Questionner systématiquement la valeur métier

Ce n’est pas une question de faire des économies de bouts de chandelle. C’est une question de durabilité économique de l’architecture.

Qu’est-ce que le pilier Cost Optimization ?

Définition et périmètre

Le pilier Cost Optimization définit la capacité à exécuter des systèmes qui délivrent de la valeur métier au coût le plus bas possible.

Il s’articule autour de cinq domaines de pratique :

Practice Cloud Financial Management : Établir une culture FinOps
Expenditure and Usage Awareness : Comprendre et attribuer les dépenses
Cost-Effective Resources : Utiliser les ressources au meilleur rapport qualité/prix
Manage Demand and Supply Resources : Adapter l’offre à la demande
Optimize Over Time : Améliorer continuellement l’efficience économique

Les principes directeurs

1. Adopter un modèle de consommation : Payer uniquement ce que vous consommez

Pas de CAPEX, que de l’OPEX variable
Arrêter les ressources inutilisées
Scale down quand la demande baisse

2. Mesurer l’efficience globale : Coût par transaction, par utilisateur, par unité métier

Ne pas optimiser isolément
Raisonner en TCO (Total Cost of Ownership)
Inclure les coûts humains (ops, maintenance)

3. Éliminer les dépenses datacenter : Le Cloud retire cette charge

Pas de gestion de matériel
Pas de surcapacité “au cas où”
Pas de cycles de renouvellement

4. Analyser et attribuer les dépenses : Savoir qui dépense quoi

Tagging rigoureux (projet, équipe, environnement)
Chargeback ou showback
Responsabilisation des équipes

5. Utiliser les services managés : Réduire les coûts de possession

Moins d’ops = moins de coûts humains
Optimisations AWS automatiques
Focus sur la valeur métier

Métriques de la Cost Optimization

Métriques de base :

Coût total mensuel : Facture AWS globale
Coût par service : EC2, S3, RDS, Lambda, etc.
Coût par environnement : Prod, Staging, Dev
Coût par projet/équipe : Attribution via tags

Métriques d’efficience :

Coût par utilisateur actif : Dépense Cloud / MAU
Coût par transaction : Dépense Cloud / Nombre de transactions
Coût par Go stocké : Optimisation storage
Coût par requête API : Optimisation compute

Métriques d’optimisation :

% d’instances avec Savings Plans : Couverture des engagements
% d’utilisation Spot : Exploitation des Spot Instances
Taux de ressources idle : % de ressources sous-utilisées
Waste (gaspillage) : Ressources payées mais inutilisées

Practice Cloud Financial Management : La culture FinOps

1. Qu’est-ce que FinOps ?

FinOps (Financial Operations) est une pratique culturelle qui allie Finance, Ops et Engineering pour optimiser les coûts Cloud.

Les trois piliers FinOps :

Inform : Visibilité et transparence

Dashboards temps réel
Alertes et anomalies
Attribution des coûts (showback/chargeback)

Optimize : Amélioration continue

Right-sizing des ressources
Élimination du waste
Négociation des engagements (RI, SP)

Operate : Gouvernance et automatisation

Politiques et guardrails
Automatisation des optimisations
Culture de responsabilité

Le modèle “You Build It, You Run It, You Pay For It” : Les équipes qui construisent et opèrent les services sont également responsables de leurs coûts. Cette responsabilisation change radicalement les comportements.

2. Établir une équipe FinOps

Composition idéale :

FinOps Lead : Évangélisation, stratégie, reporting
Cloud Architects : Expertise technique, recommandations
Finance : Budget, prévisions, P&L
Engineering : Implémentation des optimisations
Product/Business : Priorisation basée sur la valeur métier

Responsabilités :

Reporting mensuel avec tendances et anomalies
Review trimestrielle de l’architecture avec focus coûts
Création et maintien de dashboards
Formation des équipes
Définition des politiques de coûts

3. Outils et dashboards

AWS Cost Explorer : Analyse des coûts

Visualisation par service, région, tag
Filtres et groupements personnalisés
Forecasting (prévisions basées sur l’historique)
Anomaly Detection (alertes sur variations inhabituelles)

AWS Cost and Usage Report (CUR) : Export détaillé

Données granulaires (horaire)
Intégration avec outils tiers (QuickSight, Athena, Tableau)
Analyse approfondie (resource-level)

AWS Budgets : Alertes et seuils

Budgets par service, tag, coût/usage
Alertes à 80%, 100%, 120% du budget
Actions automatiques (ex: arrêt instances si dépassement)

Dashboard FinOps idéal :

┌─────────────────────────────────────────────────┐
│ Vue Exécutive                                   │
├─────────────────────────────────────────────────┤
│ • Coût total mensuel : 85,432 € (+12% vs m-1)   │
│ • Forecast fin de mois : 92,000 € (budget 90k)  │
│ • Top 3 services : EC2 (45%), RDS (20%), S3(10%)│
│ • Savings potential : 18,500 €/mois             │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ Vue par Équipe/Projet                           │
├─────────────────────────────────────────────────┤
│ • Team Alpha : 25,000 € (+5%)                   │
│ • Team Beta : 35,000 € (+45%) ⚠️ Anomalie       │
│ • Team Gamma : 15,000 € (-10%)                  │
│ • Untagged : 10,432 € ⚠️ À attribuer            │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ Optimisation                                    │
├─────────────────────────────────────────────────┤
│ • Idle resources : 8,500 €/mois                 │
│ • Right-sizing potential : 5,000 €/mois         │
│ • Savings Plans coverage : 65% (target 80%)     │
│ • Spot utilization : 15% (target 30%)           │
└─────────────────────────────────────────────────┘

4. Tagging Strategy : La base de tout

Sans tags, impossible de savoir qui dépense quoi. Le tagging rigoureux est non négociable.

Tags obligatoires (enforced via AWS Config) :

Environment: Production | Staging | Development | Test
Project: project-name
Owner: team-name
CostCenter: finance-code
Application: app-name

Tags recommandés :

LaunchedBy: user@example.com
ExpirationDate: 2025-12-31
BackupPolicy: daily | weekly | none
Compliance: GDPR | PCI-DSS | HIPAA

Enforcement :

AWS Config Rules : Alerte si ressource sans tags requis
AWS Organizations : Service Control Policies (SCP) pour bloquer création sans tags
Lambda automation : Tagger automatiquement ou arrêter les ressources non conformes

Exemple de politique :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotLike": {
        "aws:RequestTag/Environment": ["Production", "Staging", "Development"],
        "aws:RequestTag/Project": "*",
        "aws:RequestTag/Owner": "*"
      }
    }
  }]
}

Résultat : Impossible de lancer une instance EC2 sans les tags obligatoires.

Expenditure and Usage Awareness : Comprendre où va l’argent

1. Analyse des coûts par dimension

Par service AWS :

Identifier les services les plus coûteux
Comprendre l’évolution mensuelle
Détecter les anomalies

Exemple typique :

EC2 : 45% (20,000 €)
RDS : 20% (9,000 €)
S3 : 10% (4,500 €)
Data Transfer : 8% (3,600 €)
ELB : 5% (2,250 €)
CloudWatch : 3% (1,350 €)
Autres : 9% (4,050 €)

Par région :

Détection de ressources “oubliées” dans des régions inutilisées
Optimisation géographique (certaines régions sont moins chères)

Par environnement :

Production : 60%
Staging : 20%
Development : 15%
Sandbox : 5%

Red flag : Si Dev/Staging représentent >40% du total, il y a du waste.

2. Identification du waste (gaspillage)

Idle resources : Ressources payées mais inutilisées

EC2 instances :

CPU < 5% pendant 7+ jours
Réseau < 1 MB/jour
Action : Arrêter ou terminer

EBS volumes :

Volumes détachés (pas attachés à une instance)
Snapshots anciens (>365 jours)
Action : Supprimer ou archiver

RDS instances :

Zero connections pendant 7+ jours
DB de dev/test qui tournent 24/7
Action : Arrêter ou passer en Aurora Serverless

Load Balancers :

Zero requêtes pendant 7+ jours
Action : Supprimer

Elastic IPs :

IPs non associées (facturation même si non utilisées)
Action : Libérer

S3 buckets :

Données jamais accédées (>365 jours)
Logs non nécessaires
Action : Lifecycle policy vers Glacier ou suppression

Exemple concret de nettoyage :

Audit d’un compte AWS client :

50 instances EC2 idle (CPU <1%) → 5,000 €/mois waste
200 EBS volumes orphelins → 2,000 €/mois waste
15 RDS instances de test 24/7 → 3,000 €/mois waste
80 snapshots EBS >365 jours → 800 €/mois waste
500 TB S3 jamais accédés → 10,000 €/mois waste

Total waste identifié : 20,800 €/mois

Nettoyage → économie immédiate de 18,000 €/mois (certaines ressources conservées pour investigation).

3. Anomaly Detection : Alertes intelligentes

AWS Cost Anomaly Detection utilise le machine learning pour détecter des variations de coûts inhabituelles.

Configuration :

Monitor:
  - Name: "EC2 Cost Monitor"
    Service: EC2
    Threshold: 20% increase vs previous week
    Alert: Slack + Email

  - Name: "Data Transfer Spike"
    Service: Data Transfer
    Threshold: 50% increase vs previous day
    Alert: PagerDuty (urgent)

  - Name: "S3 Storage Growth"
    Service: S3
    Threshold: 100 GB/day increase
    Alert: Email

Exemples d’anomalies détectées :

Data Transfer spike : +500% en 24h
- Cause : Backup mal configuré qui upload vers Internet au lieu de S3
- Coût évité : 10,000 €
EC2 spike : +200 instances en 1 heure
- Cause : Bug dans auto-scaling (scaling loop)
- Coût évité : 5,000 €/jour
S3 storage growth : +10 TB en 48h
- Cause : Application qui logge les requêtes complètes (data + body)
- Coût évité : 2,000 €/mois

4. Forecasting : Anticiper les coûts

AWS Cost Explorer Forecasting : Prédiction basée sur l’historique

Analyse des tendances
Prévision sur 3/6/12 mois
Alertes si dépassement prévu

Modèle de prévision :

Coût actuel : 50,000 €/mois
Croissance observée : +10%/mois (business growth)
Forecast 6 mois :
  M+1 : 55,000 €
  M+2 : 60,500 €
  M+3 : 66,550 €
  M+4 : 73,205 €
  M+5 : 80,525 €
  M+6 : 88,578 €

Budget annuel prévu : 820,000 €
Budget alloué : 700,000 €
⚠️ Gap : 120,000 € → Actions d'optimisation nécessaires

Actions préventives :

Négocier Savings Plans supplémentaires
Optimisation agressive (right-sizing, Spot)
Discussions avec Finance pour budget additionnel
Priorisation des initiatives (impact coûts)

Cost-Effective Resources : Choisir les bonnes ressources

1. Compute : EC2 pricing models

AWS propose plusieurs modèles de pricing pour EC2, chacun adapté à un cas d’usage.

On-Demand : Tarif plein, flexibilité maximale

Tarif : 100% (baseline)
Engagement : Aucun
Flexibilité : Totale
Cas d’usage : Pics imprévisibles, tests ponctuels

Savings Plans : Engagement 1 ou 3 ans, réduction 40-70%

Compute Savings Plans : Flexibilité maximale (famille, taille, OS, région)
EC2 Instance Savings Plans : Moins flexible (famille fixe) mais réduction légèrement supérieure
Tarif : 30-60% vs On-Demand
Engagement : 1 ou 3 ans
Cas d’usage : Workloads stables et prévisibles

Reserved Instances : Engagement sur type d’instance précis

Tarif : 40-70% vs On-Demand
Engagement : 1 ou 3 ans
Moins flexible que Savings Plans
Peut être vendu sur le marketplace RI

Spot Instances : Capacité inutilisée, réduction 70-90%

Tarif : 10-30% vs On-Demand (90% réduction)
Interruption : Possible avec préavis 2 minutes
Cas d’usage : Workloads fault-tolerant (batch, CI/CD, big data, ML training)

Stratégie optimale (exemple) :

Application avec baseline de 50 instances et pics à 100 :

Baseline (50 instances) :
  - 40 instances : Savings Plans 3 ans → 24,000 €/an (au lieu de 60,000)
  - 10 instances : On-Demand → 12,000 €/an (flexibilité)

Pics (50 instances additionnelles) :
  - 30 instances : Spot (quand disponible) → 3,600 €/an (au lieu de 36,000)
  - 20 instances : On-Demand (fallback) → 24,000 €/an

Total : 63,600 €/an au lieu de 120,000 €/an
Économie : 47% (56,400 €/an)

Mix optimal général :

60-70% : Savings Plans (workloads stables)
10-20% : On-Demand (flexibilité, buffer)
10-20% : Spot (workloads tolérants)

2. Spot Instances : Exploiter la capacité inutilisée

Les Spot Instances peuvent réduire les coûts de 70-90%, mais nécessitent une architecture adaptée.

Principes :

AWS peut interrompre avec préavis de 2 minutes
L’application doit être fault-tolerant
Diversifier les types d’instances et AZ

Cas d’usage idéaux :

CI/CD Pipelines :

Builds, tests
Tolérance aux interruptions (retry automatique)
Économie : 80-90%

Batch Processing :

Jobs divisibles en tâches (AWS Batch, EMR, Spark)
Checkpointing pour reprendre après interruption
Économie : 70-80%

Machine Learning Training :

Long running jobs avec checkpointing
SageMaker managed spot training
Économie : 70-90%

Kubernetes Workers :

EKS avec mix On-Demand + Spot
Karpenter pour orchestration intelligente
Économie : 50-70%

Stratégie Spot avancée :

Spot Fleet configuration:
  AllocationStrategy: capacity-optimized
  InstanceTypes:
    - c5.large
    - c5a.large
    - c5n.large
    - c6i.large
    - c6a.large
  OnDemandBaseCapacity: 2  # Minimum On-Demand pour stabilité
  SpotMaxPrice: 50% of On-Demand  # Prix max acceptable
  InstancePoolsToUseCount: 3  # Diversifier pour disponibilité

Exemple concret :

Pipeline CI/CD d’une startup :

Avant : 20 instances m5.large On-Demand 24/7 → 3,500 €/mois
Après : 20 instances m5.large Spot (Spot Fleet) → 500 €/mois
Économie : 86% (3,000 €/mois)
Disponibilité : 99.5% (quelques builds rallongés, zéro impact business)

3. Serverless : Payer à la requête

Le serverless élimine le coût des ressources idle.

Lambda :

Paiement : par requête + durée d’exécution (GB-seconde)
Free tier : 1M requêtes + 400,000 GB-s par mois
Cold start : 100-500ms (amélioration continue avec Provisioned Concurrency)

Exemple de pricing Lambda :

API avec 10M requêtes/mois
Durée moyenne : 200ms
Mémoire : 512 MB

Calcul :
  Requêtes : 10M - 1M (free tier) = 9M × $0.20/1M = $1.80
  Compute : 9M × 0.2s × 0.5GB = 900,000 GB-s
           900,000 - 400,000 (free tier) = 500,000 GB-s
           500,000 × $0.0000166667 = $8.33

Total : $10.13/mois (vs $200+/mois pour EC2 équivalent)

Fargate :

Containers serverless
Paiement : par vCPU + mémoire + durée
Pas de gestion d’instances

API Gateway :

Paiement : par requête API
Cache intégré
Throttling natif

DynamoDB On-Demand :

Paiement : par Read/Write Request Unit
Pas de capacity planning
Auto-scaling instantané

Quand le serverless est plus économique :

✅ Trafic sporadique ou imprévisible

Exemple : Webhooks, scheduled jobs
Économie vs EC2 : 80-95%

✅ Microservices à faible charge

Exemple : API internes peu utilisées
Économie vs EC2 : 60-90%

✅ Event-driven processing

Exemple : Traitement d’images S3
Économie vs EC2 24/7 : 90-99%

❌ Charge constante élevée

Lambda/Fargate devient plus cher que EC2 avec Savings Plans
Seuil : ~30-40% d’utilisation constante

4. Storage : S3 Intelligent-Tiering

S3 Intelligent-Tiering automatise l’optimisation des coûts de stockage.

Fonctionnement :

Monitoring automatique des patterns d’accès
Déplacement automatique entre tiers selon l’utilisation
Pas de frais de retrieval (contrairement à Glacier)

Tiers disponibles :

Frequent Access (default)       : $0.023/GB
Infrequent Access (30 jours)    : $0.0125/GB (-46%)
Archive Instant (90 jours)      : $0.004/GB (-83%)
Archive Access (90-180 jours)   : $0.0036/GB (-84%)
Deep Archive (180+ jours)       : $0.00099/GB (-96%)

Exemple concret :

100 TB de données :

Tout en S3 Standard : 2,300 €/mois
Avec Intelligent-Tiering :
- 20 TB Frequent : 460 €
- 30 TB Infrequent : 375 €
- 30 TB Archive Instant : 120 €
- 20 TB Deep Archive : 20 €
- Total : 975 €/mois

Économie : 58% (1,325 €/mois)

Quand utiliser :

✅ Données avec patterns d’accès inconnus ou changeants
✅ Datasets longs terme (logs, backups, archives)
✅ Workloads avec mix accès chaud/froid
❌ Données avec pattern prévisible (utiliser lifecycle policy directe)

5. Right-sizing : Dimensionnement optimal

Over-provisioning est l’une des sources principales de waste.

AWS Compute Optimizer :

Analyse l’utilisation réelle (CPU, RAM, réseau, I/O)
Recommande le type optimal
Estime les économies potentielles

Exemple de recommandations :

Instance : m5.2xlarge (8 vCPU, 32 GB RAM)
Coût actuel : 300 €/mois
Utilisation observée : CPU 12%, RAM 25%

Recommandation : m5.large (2 vCPU, 8 GB RAM)
Coût après : 75 €/mois
Économie : 225 €/mois (75%)

Risque : Faible (marge suffisante)
Impact : Zéro (CPU/RAM suffisants)

Processus de right-sizing :

Analyse : Compute Optimizer + CloudWatch metrics (14-30 jours)
Priorisation : Trier par économies potentielles
Test : Valider en staging/dev
Déploiement progressif : Canary en production
Monitoring : Surveiller 7 jours post-changement
Itération : Ajuster si nécessaire

Red flags à surveiller :

CPU < 20% en moyenne
RAM < 30% en moyenne
Réseau < 10% de la bande passante
IOPS disque < 10% du provisionné

Manage Demand and Supply : Adapter à la demande

1. Auto-shutdown des environnements non-prod

Le problème : Dev/Staging/Test qui tournent 24/7 alors qu’utilisés uniquement 8h/jour, 5j/semaine.

Waste typique :

Utilisation réelle : 40h/semaine (8h × 5j)
Facturation actuelle : 168h/semaine (24h × 7j)
Waste : 76% (128h/168h)

Solution : Schedulers automatiques

AWS Instance Scheduler :

Schedule:
  Dev:
    Start: Mon-Fri 8:00 AM
    Stop: Mon-Fri 8:00 PM
    Timezone: Europe/Paris
    Apply-to: Environment=Development

  Staging:
    Start: Mon-Fri 7:00 AM
    Stop: Mon-Fri 10:00 PM
    Timezone: Europe/Paris
    Apply-to: Environment=Staging

Exemple concret :

Client avec 50 instances de dev/test :

Avant : 50 instances × 160 €/mois = 8,000 €/mois
Après auto-shutdown (8h/j, 5j/7) : 50 × 40 €/mois = 2,000 €/mois
Économie : 75% (6,000 €/mois)

Services supportés :

EC2 instances
RDS databases
Auto Scaling Groups
ECS clusters

Implémentation simple :

# Lambda function déclenchée par CloudWatch Events
import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    
    # Stop all dev instances at 8 PM
    instances = ec2.describe_instances(
        Filters=[{'Name': 'tag:Environment', 'Values': ['Development']}]
    )
    
    instance_ids = [i['InstanceId'] for r in instances['Reservations'] 
                    for i in r['Instances'] if i['State']['Name'] == 'running']
    
    if instance_ids:
        ec2.stop_instances(InstanceIds=instance_ids)
        print(f"Stopped {len(instance_ids)} dev instances")

2. Auto-scaling intelligent

Auto-scaling adapte automatiquement les ressources à la demande.

Target Tracking : Maintenir une métrique cible

AutoScaling:
  MetricType: TargetValue
  Target: CPUUtilization 50%
  Min: 2
  Max: 20
  
  Behavior:
    ScaleOut:
      StabilizationSeconds: 60
      Policies:
        - Type: PercentChangeInCapacity
          Value: 50  # +50% à chaque scale out
          Cooldown: 60
    
    ScaleIn:
      StabilizationSeconds: 300  # Attendre 5 min avant scale in
      Policies:
        - Type: PercentChangeInCapacity
          Value: -10  # Seulement -10% à chaque scale in
          Cooldown: 300

Scheduled Scaling : Scaling prévisible

ScheduledActions:
  - Name: "MorningScaleUp"
    Recurrence: "0 7 * * MON-FRI"
    MinSize: 10
    MaxSize: 50
    DesiredCapacity: 15

  - Name: "EveningScaleDown"
    Recurrence: "0 20 * * MON-FRI"
    MinSize: 2
    MaxSize: 10
    DesiredCapacity: 3

  - Name: "WeekendScaleDown"
    Recurrence: "0 20 * * FRI"
    MinSize: 2
    MaxSize: 5
    DesiredCapacity: 2

Predictive Scaling : ML pour anticiper

Analyse des patterns historiques
Prédiction de la charge future
Scaling proactif (avant le pic)

Exemple concret :

E-commerce avec variations journalières :

Nuit (0h-6h) : 2 instances → 200 €/mois
Jour (6h-18h) : 8 instances → 800 €/mois
Soirée (18h-24h) : 15 instances → 750 €/mois
Pics (Black Friday) : 50 instances → scaling automatique

Coût moyen : 1,750 €/mois au lieu de 4,500 €/mois (50 instances 24/7) Économie : 61% avec meilleure performance aux pics

3. Queues et buffering

Les queues permettent d’absorber les pics de charge sans sur-provisionner.

Architecture sans queue :

API → Direct processing → Database
      (doit scaler pour les pics)

Architecture avec queue :

API → SQS Queue → Workers (scale based on queue depth) → Database
      (buffer)    (smooth processing)

Avantages :

Découplage : API et workers scalent indépendamment
Absorption des pics : Queue buffer temporaire
Retry automatique : Messages persistés jusqu’à traitement réussi
Cost optimization : Workers peuvent traiter plus lentement (donc moins d’instances)

Exemple :

Traitement de factures :

Sans queue : 50 instances 24/7 pour gérer les pics → 8,000 €/mois
Avec SQS : 5 instances permanentes + scale jusqu’à 20 aux pics → 2,500 €/mois
Économie : 69%

SLA : Traitement en moins de 5 minutes (acceptable métier)

4. Reserved Capacity pour workloads prévisibles

Exemples de workloads prévisibles :

Bases de données de production (24/7)
Services core toujours actifs
Cache permanent (ElastiCache)
Data warehouses (Redshift)

Stratégie :

Analyser l’historique (minimum 3 mois)
Identifier le minimum constant (baseline)
Souscrire Savings Plans pour 70-80% de ce baseline
Garder 20-30% en On-Demand pour flexibilité

Exemple :

RDS PostgreSQL production :

Utilisation : db.r6i.2xlarge (8 vCPU, 64 GB RAM)
On-Demand : 1,400 €/mois
Reserved Instance 3 ans : 500 €/mois
Économie : 64% (900 €/mois)

ROI : Immédiat (pas de changement technique)

Optimize Over Time : Amélioration continue

1. Adoption des nouveaux services

AWS innove constamment avec des services plus efficaces/économiques.

Exemples de migrations rentables :

EBS gp2 → gp3 :

Performance équivalente ou supérieure
Prix : -20%
Migration : Zero downtime

Intel/AMD → Graviton3 :

Performance : +25%
Prix : -20%
Total : +45% performance/prix

RDS → Aurora Serverless v2 :

Scaling automatique
Économie : 50-70% pour workloads variables

EC2 → Lambda :

Pour workloads sporadiques
Économie : 80-95%

Self-managed → Managed services :

Exemple : MongoDB sur EC2 → DocumentDB
Économie TCO : 40-60% (incluant coûts ops)

Veille technologique :

AWS What’s New (blog officiel)
Re:Invent announcements (annuel)
AWS Cost Optimization blog
FinOps Foundation resources

2. Reviews trimestrielles

Processus de review :

Q1 : Well-Architected Review avec focus coûts

Audit complet de l’architecture
Identification des quick wins
Roadmap d’optimisation

Q2 : Analyse des tendances

Évolution des coûts par service
Attribution par équipe/projet
Forecast 12 mois

Q3 : Optimisation infrastructure

Right-sizing automatisé
Migration vers services nouveaux
Refactoring si nécessaire

Q4 : Négociation des engagements

Revue des Savings Plans existants
Calcul des nouveaux engagements
Optimisation du mix pricing

3. Automatisation des optimisations

AWS Cost Optimization Hub : Service centralisé de recommandations

Recommandations multi-comptes
Priorisation par impact/effort
Tracking de l’implémentation

Automatisations courantes :

1. Suppression automatique des snapshots anciens

# Lambda hebdomadaire
def cleanup_old_snapshots(retention_days=90):
    ec2 = boto3.client('ec2')
    cutoff_date = datetime.now() - timedelta(days=retention_days)
    
    snapshots = ec2.describe_snapshots(OwnerIds=['self'])
    
    for snapshot in snapshots['Snapshots']:
        if snapshot['StartTime'].replace(tzinfo=None) < cutoff_date:
            ec2.delete_snapshot(SnapshotId=snapshot['SnapshotId'])

2. Right-sizing automatique des EBS volumes

# Analyser l'utilisation, recommander gp2 → gp3 ou downsize
def optimize_ebs_volumes():
    ec2 = boto3.client('ec2')
    cloudwatch = boto3.client('cloudwatch')
    
    volumes = ec2.describe_volumes()
    
    for volume in volumes['Volumes']:
        # Analyser métriques CloudWatch (30 jours)
        # Si IOPS < 10% du provisionné → recommander downsize
        # Si gp2 → recommander gp3 (-20% coût)

3. Auto-tagging des ressources non conformes

# EventBridge rule → Lambda au lancement de ressource
def auto_tag_resources(event):
    resource_id = event['detail']['resource-id']
    launched_by = event['detail']['userIdentity']['arn']
    
    ec2 = boto3.client('ec2')
    ec2.create_tags(
        Resources=[resource_id],
        Tags=[
            {'Key': 'LaunchedBy', 'Value': launched_by},
            {'Key': 'LaunchedAt', 'Value': datetime.now().isoformat()},
            {'Key': 'AutoTagged', 'Value': 'true'}
        ]
    )

Cas d’usage : L’impact de la Cost Optimization

Scénario sans discipline financière : Le gouffre invisible

Situation réelle observée chez une scale-up tech :

Contexte initial :

Croissance rapide (100 → 500 employés en 18 mois)
Équipes autonomes (10 squads)
Culture “move fast” → zéro gouvernance coûts
“On verra plus tard pour l’optimisation”

Symptômes après 12 mois :

Facture Cloud :

M1 : 15,000 €
M6 : 45,000 € (+200%)
M12 : 120,000 € (+700%)
Croissance business : +150% (4x moins que la facture)

Analyse détaillée :

Waste identifié :

200 instances EC2 idle ou sous-utilisées : 25,000 €/mois
Environnements dev/test 24/7 : 15,000 €/mois
80 TB S3 jamais accédés : 1,800 €/mois
40 RDS databases de test permanents : 8,000 €/mois
Data transfer non optimisé : 6,000 €/mois
100% On-Demand (zero Savings Plans) : 35,000 €/mois manqués
Total waste : 90,800 €/mois (76% de la facture !)

Problèmes organisationnels :

Pas de tagging → impossible d’attribuer les coûts
Pas de budget par équipe → zéro accountability
Pas de review → accumulation du waste
Pas de culture coûts → “l’infra c’est gratuit”

Impact business :

CFO en panique
Budget IT explosé (+600% vs prévu)
Runway réduit de 24 mois à 14 mois
Discussions avec investisseurs compliquées
Pression sur les équipes produit (freeze hiring)

Transformation avec discipline FinOps

Programme d’optimisation 6 mois :

Mois 1-2 : Quick wins (fondations)

Tagging enforcé :
- Tags obligatoires via AWS Config
- Auto-tagging via Lambda
- Attribution des coûts par équipe
Cleanup immédiat :
- Suppression ressources idle (validation humaine)
- Snapshots anciens supprimés
- Environnements oubliés terminés
- Économie immédiate : 35,000 €/mois
Auto-shutdown dev/test :
- Instance Scheduler déployé
- Dev : 8h/j, 5j/7
- Staging : 10h/j, 6j/7
- Économie : 12,000 €/mois

Mois 3-4 : Optimisations structurelles

Savings Plans :
- Analyse baseline sur 6 mois
- Souscription 70% du compute stable
- Mix 1 an (flexibilité) + 3 ans (max savings)
- Économie : 30,000 €/mois
Right-sizing :
- Compute Optimizer sur toutes les instances
- 60 instances downsized
- 20 instances migrées vers Graviton
- Économie : 8,000 €/mois
Storage optimization :
- S3 Intelligent-Tiering activé
- Lifecycle policies configurées
- EBS gp2 → gp3
- Économie : 5,000 €/mois

Mois 5-6 : Culture et gouvernance

FinOps Team :
- 1 FinOps Lead recruté
- 2 Cloud Architects formés FinOps
- Roadmap d’optimisation continue
Dashboards et alertes :
- Dashboard exécutif (CEO/CFO)
- Dashboards par équipe
- Budgets et alertes configurés
- Anomaly Detection activé
Culture de responsabilité :
- Budget mensuel par équipe
- Review mensuelle avec leads
- Gamification (équipe la plus optimisée)
- Formation FinOps pour tous

Résultats après 6 mois :

Coûts :

Avant : 120,000 €/mois
Après : 30,000 €/mois
Économie : 90,000 €/mois (75%)
Économie annualisée : 1,080,000 €

ROI programme :

Investissement : 100,000 € (recrutement + temps équipe + outils)
Économie année 1 : 1,080,000 €
ROI : 10.8x en 1 an

Impact business :

Runway : 14 mois → 32 mois (sans lever de fonds)
CFO satisfait (sous-budget)
Discussions investisseurs apaisées
Budget réalloué vers hiring et produit

Bénéfices indirects :

Visibilité : Enfin comprendre qui dépense quoi
Accountability : Équipes responsables de leurs coûts
Optimisation continue : Culture installée
Performance : Beaucoup d’optimisations ont amélioré les perfs

Outils et services AWS pour Cost Optimization

Analyse et visibilité

AWS Cost Explorer : Visualisation et analyse des coûts
AWS Cost and Usage Report (CUR) : Export détaillé
AWS Budgets : Alertes et seuils
AWS Cost Anomaly Detection : ML pour détecter variations

Optimisation

AWS Compute Optimizer : Recommandations ML
AWS Trusted Advisor : Best practices (dont coûts)
AWS Cost Optimization Hub : Recommandations centralisées
AWS Instance Scheduler : Auto-shutdown dev/test

Pricing models

Savings Plans : Engagement flexible 1-3 ans
Reserved Instances : Engagement précis
Spot Instances : Capacité inutilisée -70-90%
S3 Intelligent-Tiering : Optimisation storage automatique

Gouvernance

AWS Organizations : Gestion multi-comptes
AWS Service Catalog : Catalogue de services approuvés
AWS Control Tower : Landing zone avec guardrails
AWS Config : Compliance et enforcement

Checklist d’implémentation Cost Optimization

Phase 1 : Visibilité (Semaine 1-2)

Activer Cost Explorer dans tous les comptes
Activer Cost and Usage Report (CUR)
Configurer tagging strategy
Enforcer tags via AWS Config
Créer dashboard FinOps de base
Établir baseline des coûts actuels

Phase 2 : Quick wins (Mois 1)

Identifier et supprimer ressources idle (avec validation)
Supprimer snapshots/backups anciens
Configurer auto-shutdown dev/test
Activer S3 Intelligent-Tiering
Migrer EBS gp2 → gp3
Configurer budgets et alertes
Activer Anomaly Detection

Phase 3 : Optimisations structurelles (Mois 2-3)

Analyser recommandations Compute Optimizer
Right-sizing instances (dev → staging → prod)
Analyser patterns compute et calculer Savings Plans
Souscrire Savings Plans (70% du baseline)
Identifier workloads pour Spot Instances
Implémenter Spot pour CI/CD et batch
Optimiser storage (S3 lifecycle policies)

Phase 4 : Gouvernance et culture (Mois 4-6)

Établir équipe FinOps
Attribution des coûts par équipe/projet
Review mensuelle par équipe (showback/chargeback)
Formation FinOps pour tous
Automatiser optimisations récurrentes
Well-Architected Review avec focus coûts
Review trimestrielle avec Finance

Phase 5 : Optimisation continue (6+ mois)

Veille sur nouveaux services AWS
Migrations vers services plus efficients
Review annuelle des engagements (RI/SP)
Amélioration continue du tagging
Gamification et reconnaissance des équipes optimisées
Partage des best practices inter-équipes

Erreurs courantes et comment les éviter

Erreur #1 : “On optimisera plus tard”

Mythe : “Concentrons-nous sur le produit, on verra les coûts quand on aura du trafic”

Réalité : Le waste s’accumule exponentiellement. Plus vous attendez, plus c’est cher et complexe.

Solution : FinOps dès le jour 1. Tagging rigoureux, budgets, auto-shutdown dev/test.

Erreur #2 : “Tout en Savings Plans 3 ans”

Mythe : “Maximum de savings = 100% en Savings Plans 3 ans”

Réalité : Trop d’engagement tue la flexibilité. Architectures qui évoluent, technologies qui changent.

Solution : 60-70% du baseline en Savings Plans, garder 20-30% flexible.

Erreur #3 : “L’optimisation, c’est le job de l’équipe Cloud”

Mythe : “Les architectes Cloud vont s’occuper des coûts”

Réalité : Sans ownership des équipes produit, le waste revient instantanément.

Solution : Showback/Chargeback. Chaque équipe est responsable de son budget.

Erreur #4 : “On ne touche pas à la prod”

Mythe : “Trop risqué d’optimiser la production”

Réalité : La prod représente 60-80% des coûts. C’est là qu’il faut optimiser.

Solution : Approche progressive et testée. Staging d’abord, puis canary en prod.

Erreur #5 : “Le Spot, c’est trop complexe”

Mythe : “Les Spot Instances peuvent s’arrêter n’importe quand, c’est inutilisable”

Réalité : Avec une architecture adaptée, Spot = -70-90% sans impact.

Solution : Identifier les workloads tolérants (CI/CD, batch, ML). Diversifier les types.

Erreur #6 : “Pas de tagging = pas grave”

Mythe : “On tagguera plus tard / On sait qui dépense quoi”

Réalité : Sans tags, impossible d’attribuer, donc impossible d’optimiser intelligemment.

Solution : Enforcer les tags dès la création. Bloquer les ressources sans tags requis.

La Cost Optimization au-delà d’AWS

Les principes de Cost Optimization s’appliquent à tous les clouds :

Azure :

Azure Cost Management + Billing
Reserved VM Instances
Azure Spot VMs
Azure Savings Plans

Google Cloud :

Cloud Billing Reports
Committed Use Discounts (CUD)
Preemptible VMs (équivalent Spot)
Recommender pour optimisations

Multi-cloud :

CloudHealth, CloudCheckr, Flexera
Normalisation du tagging cross-cloud
FinOps Foundation practices

On-premise :

Virtualisation pour densité
Décommissionnement hardware ancien
Consolidation des datacenters

Les fondamentaux restent identiques :

Mesurer pour comprendre
Attribuer pour responsabiliser
Dimensionner pour optimiser
Automatiser pour pérenniser

Conclusion : La Cost Optimization, investissement stratégique

Le pilier Cost Optimization nous rappelle une vérité fondamentale : le Cloud n’est pas magiquement moins cher. C’est un modèle économique différent qui nécessite discipline et gouvernance.

Sans Cost Optimization :

Factures qui explosent sans compréhension
Waste invisible qui s’accumule (75%+ dans certaines organisations)
Runway qui se réduit dangereusement
Pression sur les équipes et les budgets

Avec Cost Optimization :

Visibilité complète sur les dépenses
Alignement coûts/valeur métier
Économies massives (50-80% possibles)
Culture de responsabilité
Durabilité économique de l’architecture

Les bénéfices sont multiples :

Financial :

Réduction 40-70% en moyenne des coûts Cloud
ROI programme FinOps : 10-20x en première année
Predictibilité budgétaire

Technique :

Architecture mieux dimensionnée = meilleure performance
Services managés = moins de dette technique
Innovation facilitée (budget réalloué)

Organisationnel :

Équipes responsables de leurs coûts
Décisions éclairées par la data
Culture d’efficience

La question n’est pas “faut-il investir dans la Cost Optimization ?”, mais “peut-on se permettre de ne pas le faire ?”

Comme le dit Jeff Bezos : “Frugality breeds resourcefulness, self-sufficiency, and invention.” L’optimisation des coûts n’est pas une contrainte, c’est un catalyseur d’innovation.

Prochainement dans cette série : Le pilier Sustainability du AWS Well-Architected Framework — comment concevoir des architectures éco-responsables et minimiser l’empreinte carbone.

Besoin d’un audit FinOps ou d’accompagnement pour optimiser vos coûts Cloud ? Notre équipe d’experts certifiés AWS est disponible. Contactez-nous.