AWS Well-Architected Framework : Le pilier Sustainability, faire mieux avec moins

Publié le 30 octobre 2025 par Mathieu Roger

Introduction : Green IT n’est pas un oxymore

Pendant longtemps, l’industrie tech a vécu avec l’illusion que le numérique était “immatériel” donc sans impact environnemental. La réalité est brutalement différente : le secteur numérique représente 4% des émissions mondiales de gaz à effet de serre, plus que l’aviation civile.

Le Cloud amplifie ce paradoxe : l’infrastructure est invisible, donc l’impact l’est aussi. On provisionne des ressources d’un clic, on les oublie, elles tournent à vide… et elles consomment.

Le pilier Sustainability du AWS Well-Architected Framework, ajouté en 2021, marque une prise de conscience : l’architecture Cloud doit être éco-responsable. Pas par altruisme (même si c’est important), mais parce que c’est économiquement et techniquement la bonne chose à faire.

La bonne nouvelle ? Durabilité et efficience vont de pair. Réduire l’empreinte carbone, c’est :

Consommer moins de ressources = coûts réduits
Optimiser les algorithmes = meilleures performances
Éliminer le waste = architecture plus propre

Ce pilier n’est pas un “nice to have” éthique. C’est un impératif business dans un monde où :

Les régulations environnementales se durcissent (Green Deal européen, CSRD)
Les clients exigent de la transparence sur l’empreinte carbone
Les investisseurs intègrent les critères ESG (Environmental, Social, Governance)
Les talents recherchent des entreprises responsables

Qu’est-ce que le pilier Sustainability ?

Définition et périmètre

Le pilier Sustainability se concentre sur la minimisation de l’impact environnemental des workloads Cloud tout au long de leur cycle de vie.

Il s’articule autour de six domaines de conception :

Region Selection : Choisir des régions avec électricité bas-carbone
User Behavior Patterns : Comprendre et optimiser les patterns d’utilisation
Software and Architecture Patterns : Architectures efficientes
Data Patterns : Optimiser stockage, transfert et traitement des données
Hardware Patterns : Utiliser le matériel le plus efficient
Development and Deployment Process : Intégrer la durabilité dans les pratiques

Les principes directeurs

1. Comprendre son impact : On ne peut optimiser que ce qu’on mesure

Calculer l’empreinte carbone de ses workloads
Identifier les hotspots de consommation
Établir des métriques de durabilité

2. Établir des objectifs de durabilité : Comme des SLA, mais pour l’environnement

Réduction d’empreinte carbone de X% par an
Ratio carbone/transaction en baisse continue
Part d’énergie renouvelable en augmentation

3. Maximiser l’utilisation : Le waste n’est pas seulement économique, il est environnemental

Ressources sous-utilisées = énergie gaspillée
Right-sizing = efficience énergétique
Mutualisation = optimisation collective

4. Anticiper et adopter de nouvelles offres : La technologie évolue vers plus d’efficience

Nouveaux processeurs (Graviton, efficience +60%)
Services managés optimisés
Innovations matérielles (refroidissement, densité)

5. Utiliser des services managés : AWS optimise à l’échelle

Mutualisation des ressources
Optimisations continues
Datacenter ultra-efficients

6. Réduire l’impact en aval : Pas seulement le Cloud, mais toute la chaîne

Devices des utilisateurs (moins de JS/assets)
Réseaux (moins de transfert)
Stockage (compression, déduplication)

Métriques de la durabilité

Empreinte carbone :

kgCO2e/transaction : Carbone par unité de travail
kgCO2e/utilisateur/an : Impact par utilisateur
PUE (Power Usage Effectiveness) : Efficience énergétique datacenter (AWS : 1.2 vs industrie : 1.6)

Utilisation des ressources :

% CPU moyen : >50% = bon, <20% = waste
Taux de ressources idle : À minimiser
Density : Workloads par serveur physique

Efficience applicative :

CPU cycles/transaction : Moins = mieux
Transfert réseau/transaction : Moins = mieux
Requêtes DB/transaction : Optimiser les queries

Énergies renouvelables :

% d’énergie renouvelable : Par région AWS (varie de 40% à 100%)

Region Selection : Choisir son énergie

1. Mix énergétique par région AWS

Toutes les régions AWS n’ont pas le même mix énergétique. Certaines sont alimentées majoritairement par des énergies renouvelables, d’autres par des énergies fossiles.

Régions AWS avec énergie renouvelable élevée :

Région	Code	% Renouvelable	PUE	Notes
Montréal	ca-central-1	~100%	1.14	Hydroélectricité
Oregon	us-west-2	~95%	1.15	Hydroélectricité + éolien
Stockholm	eu-north-1	~95%	1.10	Hydroélectricité + éolien
Frankfurt	eu-central-1	~80%	1.18	Mix renouvelable
Paris	eu-west-3	~75%	1.20	Nucléaire + renouvelable
Irlande	eu-west-1	~70%	1.19	Éolien

Régions avec énergie fossile élevée :

Région	Code	% Fossile	Notes
Virginie du Nord	us-east-1	~60%	Charbon + gaz
Singapour	ap-southeast-1	~80%	Gaz naturel
Hong Kong	ap-east-1	~75%	Charbon

Customer Carbon Footprint Tool : AWS fournit un dashboard qui calcule l’empreinte carbone de vos workloads par région.

Trade-offs à considérer :

✅ Avantages région renouvelable :

Empreinte carbone réduite (jusqu’à -80%)
Image responsable
Conformité réglementaire (CSRD, taxonomie verte)

❌ Contraintes :

Latence potentielle si éloignement des utilisateurs
Certains services pas disponibles partout
Data residency / compliance (GDPR, souveraineté)

Stratégie optimale :

Identifier les workloads flexibles géographiquement :
- Batch nocturnes → Peut tourner ailleurs
- Data processing asynchrone → Latence non critique
- Backups, archives → Aucune latence requirement
Migrer vers régions renouvelables :
- Stockholm pour l’Europe (excellent PUE + 95% renouvelable)
- Oregon pour les US Ouest
- Montréal pour l’Amérique du Nord
Garder en région locale ce qui est latence-critique :
- API temps-réel
- Bases de données transactionnelles
- Applications interactives

Exemple concret :

Application européenne :

Avant : 100% sur eu-west-1 (Irlande, 70% renouvelable)
Après optimisation :
- API + DB : eu-west-1 (latence critique)
- Batch nocturnes : eu-north-1 (Stockholm, 95% renouvelable)
- Backups : eu-north-1
- Data analytics : eu-north-1

Résultat : -30% empreinte carbone, coûts équivalents (Stockholm légèrement moins cher)

2. AWS et l’engagement renouvelable

Objectif AWS : 100% d’énergie renouvelable d’ici 2025 (en avance sur l’objectif initial 2030).

Initiatives :

400+ projets d’énergie renouvelable (éolien, solaire)
Plus grand acheteur corporate d’énergie renouvelable au monde
Investissement : 5+ GW de capacité renouvelable

Pour les clients :

Datacenter AWS : PUE moyen 1.2 (vs 1.6 industrie) → -25% énergie gaspillée
Refroidissement optimisé (free cooling, IA)
Serveurs custom optimisés (Graviton, Nitro)

Avantage mutualisation :

Datacenter AWS : 84% moins de carbone que datacenter on-premise moyen
Efficience à l’échelle + énergie renouvelable

User Behavior Patterns : Optimiser l’utilisation

1. Comprendre les patterns d’usage

Analyse temporelle :

La majorité des applications ont des patterns d’usage prévisibles :

Applications B2B : Heures de bureau (9h-18h), jours ouvrés
E-commerce : Pics en soirée, week-end, périodes promotionnelles
Médias/Streaming : Soirée (20h-23h), week-end
Batch/Analytics : Fenêtres off-peak (nuit, week-end)

Mesurer pour comprendre :

CloudWatch Metrics:
  - RequestCount par heure sur 30 jours
  - CPUUtilization par heure
  - NetworkIn/Out par heure
  
Patterns identifiés:
  - Nuit (0h-6h) : 5% du trafic
  - Matin (6h-12h) : 30% du trafic
  - Après-midi (12h-18h) : 45% du trafic
  - Soirée (18h-24h) : 20% du trafic
  
  - Semaine : 80% du trafic
  - Week-end : 20% du trafic

Actions d’optimisation :

1. Auto-scaling temporal :

# Scale down la nuit et le week-end
ScheduledScaling:
  BusinessHours:
    Start: Mon-Fri 07:00
    MinSize: 10
    MaxSize: 50
    DesiredCapacity: 15
  
  OffHours:
    Start: Mon-Fri 20:00
    MinSize: 2
    MaxSize: 10
    DesiredCapacity: 3
  
  Weekend:
    Start: Fri 20:00
    MinSize: 2
    MaxSize: 5
    DesiredCapacity: 2

2. Batch processing off-peak :

Traiter les jobs lourds la nuit (moins de contention)
Utiliser les Spot Instances (encore moins cher)
Profiter de l’énergie renouvelable excédentaire (certaines heures)

3. Caching agressif :

CDN (CloudFront) : Réduire les requêtes au backend
ElastiCache : Éviter requêtes DB répétitives
Browser caching : Réduire transferts réseau

Exemple concret :

Application SaaS B2B :

Avant : 20 instances 24/7 → 480 instances×heures/jour
Après optimisation :
- Heures de bureau (10h/j) : 20 instances → 200 instances×heures
- Heures creuses (14h/j) : 3 instances → 42 instances×heures
- Total : 242 instances×heures/jour

Économie :

Ressources : -50%
Coûts : -50%
Empreinte carbone : -50%

2. Influencer les comportements utilisateurs

Nudging écologique :

Inciter les utilisateurs à des comportements moins consommateurs :

Exemples :

Vidéos : Proposer résolution adaptative (720p par défaut au lieu de 4K)
Images : WebP au lieu de JPEG/PNG (30% plus léger)
Assets : Lazy loading (charger seulement ce qui est visible)
Emails : Texte plutôt que HTML lourd avec images

Impact :

Moins de bande passante = moins d’énergie réseau
Moins de transfert = moins d’énergie datacenter
Moins de processing côté client = batterie préservée

Exemple concret :

Plateforme vidéo :

Avant : 1080p par défaut → 3 GB/heure/utilisateur
Après : 720p adaptatif → 1.5 GB/heure/utilisateur
Impact : -50% bande passante, -50% stockage (compression)
Expérience : Dégradation imperceptible pour la majorité

3. Développement durable des features

Questionner chaque feature :

Cette feature apporte-t-elle de la valeur proportionnée à son impact ?
Peut-on la simplifier sans perdre l’essentiel ?
Les utilisateurs l’utilisent-ils vraiment ?

Exemple : Feature de notification temps-réel

Impact : WebSocket permanent = connexion 24/7 = énergie continue
Alternative : Polling toutes les 30s = 99% moins de connexions
Trade-off : Latence +30s, mais acceptable pour cas d’usage

Feature flags et A/B testing :

Mesurer l’impact environnemental de chaque feature
Désactiver les features peu utilisées (long tail)

Software and Architecture Patterns : Efficience by design

1. Architectures éco-responsables

Serverless-first : Payer uniquement ce qui est consommé

Lambda : Zéro ressource idle
Fargate : Pas de gestion d’instances sous-utilisées
DynamoDB On-Demand : Auto-scaling instantané

Event-driven architecture : Découplage et efficience

Producer → EventBridge → Consumer (Lambda)
           (async)       (scale to zero)

Avantages :

Scaling exact (ni trop, ni trop peu)
Pas de polling (économie CPU)
Bufferisation naturelle (queues)

Right-sizing systématique :

Dimensionner pour l’usage réel, pas “au cas où”
Monitoring continu et ajustement
Compute Optimizer : Recommandations ML

Multi-tenancy : Mutualiser pour optimiser

Un cluster partagé vs X clusters dédiés
Meilleure utilisation des ressources
Isolation logique (namespace, IAM) plutôt que physique

Exemple :

10 clients avec cluster K8s dédié chacun : 10 control planes = waste énorme
10 clients sur cluster mutualisé avec namespaces : 1 control plane = -90% ressources

2. Optimisation applicative

Code efficient : Moins de cycles = moins d’énergie

Algorithmes optimisés :

# ❌ O(n²) - Inefficient
def find_duplicates_bad(items):
    duplicates = []
    for i in items:
        for j in items:
            if i == j and i not in duplicates:
                duplicates.append(i)
    return duplicates

# ✅ O(n) - Efficient
def find_duplicates_good(items):
    seen = set()
    duplicates = set()
    for item in items:
        if item in seen:
            duplicates.add(item)
        seen.add(item)
    return list(duplicates)

Impact : 100x moins de CPU pour 10,000 items

Requêtes DB optimisées :

-- ❌ N+1 queries problem
SELECT * FROM orders WHERE user_id = 123;
-- Pour chaque order:
SELECT * FROM items WHERE order_id = ?;

-- ✅ Single query avec JOIN
SELECT o.*, i.*
FROM orders o
JOIN items i ON i.order_id = o.id
WHERE o.user_id = 123;

Impact : 1 requête au lieu de 100+ → -99% CPU DB

Caching intelligent :

Mettre en cache ce qui est souvent lu et rarement modifié
Invalider le cache intelligemment (pas de TTL arbitraire)
Lazy loading : Charger seulement ce qui est nécessaire

Exemple concret :

Application e-commerce avec catalogue produits :

Sans cache : 1000 req/s vers RDS → CPU 80%, latence 200ms
Avec ElastiCache : 950 req/s servies par cache → CPU RDS 8%, latence 5ms

Impact :

-90% charge DB
-90% énergie consommée
+95% performance (bonus)

3. Compression et optimisation des assets

Images :

Format moderne (WebP, AVIF) : -30% vs JPEG
Compression agressive (quality 80 au lieu de 100)
Responsive images (servir 800px si écran 800px, pas 4K)
Lazy loading (charger hors viewport en différé)

Vidéos :

Codec moderne (H.265/HEVC, AV1) : -50% vs H.264
Résolution adaptative (ABR - Adaptive Bitrate)
Thumbnail preview au lieu de autoplay

Code :

Minification JS/CSS (suppression whitespace, comments)
Tree shaking (supprimer code non utilisé)
Code splitting (charger par route, pas tout d’un coup)
Bundling moderne (Vite, esbuild vs Webpack)

Exemple concret :

Site web corporate :

Avant : 5 MB par page (images non optimisées, JS monolithique)
Après optimisation :
- Images WebP + compression : 2 MB → 400 KB
- JS minifié + code splitting : 2 MB → 300 KB
- CSS optimisé : 500 KB → 50 KB
- Fonts subset : 300 KB → 50 KB
- Total : 800 KB (-84%)

Impact :

-84% bande passante
-84% énergie réseau (serveur + client)
Time to Interactive : 8s → 2s (meilleure UX)

4. Architectures async et batch

Traiter en batch plutôt qu’en temps-réel :

Quand le temps-réel n’est pas requis, batcher = efficience.

Exemple : Envoi d’emails

❌ Temps-réel : 1 email envoyé → 1 Lambda invocation → 1000 invocations/jour
✅ Batch : Accumuler pendant 5 min → 1 Lambda traite 50 emails → 20 invocations/jour

Impact : -98% invocations Lambda = -98% énergie

Exemple : Génération de rapports

❌ À la demande : Requête → Calcul lourd → Attente utilisateur
✅ Pré-calculé : Job nocturne → Calcul une fois → Servir depuis cache

Impact : Calcul fait une fois au lieu de N fois

Principes :

Différer ce qui peut l’être
Grouper les opérations
Pré-calculer ce qui est prévisible

Data Patterns : Optimiser la donnée

1. Minimiser le stockage

Principe : Moins de données stockées = moins d’énergie consommée pour stocker, répliquer, sauvegarder.

Compression :

Logs non compressés : 1 TB/jour → 7 TB/semaine
Logs gzip : 100 GB/jour → 700 GB/semaine (-90%)
Logs parquet (columnar) : 50 GB/jour → 350 GB/semaine (-95%)

Déduplication :

Éliminer doublons
S3 Intelligent-Tiering : Automatique
Snapshots incrémentaux : EBS, RDS (seuls les deltas)

Data lifecycle :

S3 Lifecycle:
  - Après 30 jours : Standard → Standard-IA
  - Après 90 jours : Standard-IA → Glacier
  - Après 365 jours : Glacier → Deep Archive
  - Après 2555 jours : Supprimer

Retention policies : Ne garder que ce qui est nécessaire

RGPD : Droit à l’oubli
Réglementaire : Conservation minimale
Technique : Logs anciens peu utiles

Exemple concret :

Application SaaS avec logs :

Sans lifecycle : Logs accumulés → 500 TB au bout de 3 ans → 11,500 €/mois
Avec lifecycle + compression :
- Hot (30 jours) : 3 TB → 70 €/mois
- Warm (60 jours) : 6 TB compressés → 90 €/mois
- Cold (365 jours) : 20 TB en Glacier → 80 €/mois
- Total : 240 €/mois (-98%)

Impact :

-98% coûts
-98% stockage physique
-98% énergie de stockage et réplication

2. Minimiser les transferts réseau

Data transfer = énergie :

Énergie pour transmettre (datacenter → réseau)
Énergie pour router (backbone Internet)
Énergie pour recevoir (client)

Stratégies :

1. CDN / Edge caching :

CloudFront : Cache au plus près des utilisateurs
Moins de traversée de réseaux longue distance
Moins de charge sur origin servers

2. Compression :

gzip / brotli pour HTTP
Économie : -60-80% selon le contenu

3. GraphQL plutôt que REST :

Requêtes précises (demander seulement ce dont on a besoin)
Éviter over-fetching (REST renvoie tout)

# GraphQL : demander seulement ce qu'on veut
query {
  user(id: 123) {
    name
    email
  }
}

# REST : renvoie 50 champs dont on n'a besoin que de 2
GET /api/users/123
→ Retourne tout l'objet user (name, email, address, phone, created_at, ...)

4. Pagination et lazy loading :

Ne charger que ce qui est visible
Infinite scroll au lieu de tout charger

5. Delta syncing :

Synchroniser seulement les changements
Pas de réenvoi complet

Exemple concret :

Application mobile avec synchro :

Avant : Réenvoi complet de la DB à chaque sync → 10 MB/sync × 1000 users × 10/jour = 100 GB/jour
Après : Delta sync → 100 KB/sync × 1000 users × 10/jour = 1 GB/jour

Impact : -99% data transfer, -99% énergie réseau

3. Data processing efficient

Principes :

1. Traiter au plus près des données :

Éviter de transférer pour traiter ailleurs
Lambda@Edge pour processing edge
Aurora : Procédures stockées plutôt que fetch + process + write

2. Traiter une fois, pas N fois :

Materialized views : Pré-calculer
Caching des résultats
Éviter recomputation

3. Columnar storage pour analytics :

Parquet : Lire seulement les colonnes nécessaires
vs CSV : Lire tout le fichier

Query: SELECT user_id, amount FROM transactions WHERE date > '2025-01-01'

CSV (row-based): Lire tout le fichier (100 GB), extraire colonnes nécessaires
Parquet (columnar): Lire seulement colonnes user_id, amount, date (5 GB)

Impact: -95% data read = -95% énergie

4. Sampling pour analytics exploratoires :

Analyser 10% des données pour exploration
Tourner sur 100% seulement pour résultat final
Athena : TABLESAMPLE (10 PERCENT)

Exemple concret :

Data analytics pipeline :

Avant : CSV flat files, scan complet → 2h de processing, $100 Redshift
Après : Parquet partitionné par date, requêtes ciblées → 5 min, $5

Impact :

-96% temps de calcul
-96% coût
-96% énergie consommée

Hardware Patterns : Le matériel compte

1. Graviton : Efficience par design

AWS Graviton (processeurs ARM custom) sont 60% plus efficients énergétiquement que x86 équivalents.

Avantages :

+25% performance à coût égal
-20% coût à performance égale
+60% efficience énergétique (performance/Watt)

Cas d’usage idéaux :

Applications cloud-native (microservices)
Containers (ECS, EKS)
Serverless (Lambda)
Bases de données (RDS, Aurora, ElastiCache)

Migration :

Linux : Généralement transparent (recompilation)
Containers : Multi-arch builds (amd64 + arm64)
Langages : Python, Java, Node.js, Go, Rust → support natif

Exemple concret :

Cluster EKS :

Avant : 50 × m6i.xlarge (x86) → 7,500 €/mois, X kWh
Après : 50 × m7g.xlarge (Graviton3) → 6,000 €/mois, 0.4X kWh

Impact :

-20% coûts
-60% énergie
Performance équivalente ou supérieure

2. Instance types efficients

Certaines familles d’instances sont plus efficientes que d’autres.

Général :

Graviton > Intel dernière gen > Intel ancienne gen > AMD
Générations récentes > anciennes (efficience améliorée)

Spécialisé :

Inf1 (AWS Inferentia) : ML inference 70% moins cher et moins énergivore que GPU
Trainium : ML training optimisé
C7gn : Network-optimized Graviton (400 Gbps)

Stratégie :

Toujours utiliser les générations les plus récentes
Migrer vers Graviton quand compatible
Spécialiser : C pour compute, R pour memory, I pour storage

3. Burstable instances (T3, T4g)

Pour workloads à charge variable, les instances burstables sont plus efficientes.

Principe :

CPU baseline faible (ex: 20%)
Accumulation de crédits CPU quand sous le baseline
Burst jusqu’à 100% CPU quand nécessaire

Avantages :

Payer pour l’usage moyen, pas le pic
Dimensionnement au plus juste
Efficience énergétique (pas de ressources idle)

Exemple :

Application avec charge variable :

m6i.large (On-Demand) : 2 vCPU permanent, utilisation moyenne 30% → 160 €/mois
t3.large (Burstable) : 2 vCPU, 30% baseline, burst aux pics → 80 €/mois

Impact : -50% coût, -50% énergie (dimensionnement juste)

4. Nitro System : Virtualisation efficiente

AWS Nitro est l’hyperviseur custom d’AWS, ultra-efficient.

Avantages :

Overhead virtualisation quasi-nul
Performance quasi-bare-metal
Sécurité renforcée (isolation matérielle)
Efficience énergétique améliorée

Instances Nitro : Toutes les générations récentes (6e, 7e)

Development and Deployment : Intégrer la durabilité

1. CI/CD optimisé

Problème : Pipelines CI/CD peuvent être très consommateurs

Builds fréquents
Tests qui tournent longtemps
Environnements de test éphémères

Optimisations :

1. Cache agressif :

# GitLab CI avec cache
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/
    - dist/

# Économie: Pas de re-download des dépendances à chaque build
# Impact: -90% temps de build, -90% data transfer

2. Builds incrémentaux :

Rebuilder seulement ce qui a changé
Turbo, Nx pour monorepos

3. Parallélisation :

Tests en parallèle → moins de temps total
Mais attention : plus d’instances → trade-off à évaluer

4. Spot Instances pour CI :

GitLab/Jenkins runners sur Spot
-70-90% coût et énergie

5. Auto-scaling runners :

Scale to zero quand pas de build
Scale up pour builds

Exemple concret :

Pipeline CI/CD :

Avant : 10 runners permanents (m5.large) → 1,600 €/mois
Après : Auto-scaling runners (0-20), Spot Instances, cache → 300 €/mois

Impact : -81% coût, -81% énergie

2. Environnements de développement éco-responsables

Dev/Test/Staging représentent souvent 30-40% des coûts Cloud → même proportion d’énergie.

Optimisations :

1. Environnements éphémères :

Créer à la demande (PR, branch)
Détruire après usage
Pas d’environnements permanents “au cas où”

2. Auto-shutdown :

Arrêt automatique soir et week-end
Économie : 75% (40h/168h)

3. Right-sizing :

Dev n’a pas besoin de la config prod
Prod : db.r6i.2xlarge → Dev : db.t3.large

4. Shared environments :

Environnement de dev partagé par équipe
Plutôt qu’un par développeur

5. Mocking et stubs :

Mock les services externes
Éviter environnements complets quand pas nécessaire

Exemple concret :

Organisation avec 50 développeurs :

Avant : 50 environnements complets 24/7 → 25,000 €/mois
Après : 5 environnements partagés + éphémères à la demande + auto-shutdown → 5,000 €/mois

Impact : -80% coût, -80% énergie

3. Infrastructure as Code : Éviter le drift

IaC (Terraform, CloudFormation) = reproductibilité = efficience.

Avantages :

Environnements identiques (pas de config drift)
Teardown facile (supprimer quand inutilisé)
Review de l’infrastructure (détecter le waste)
Automatisation (policies de durabilité)

Exemple : Policy Terraform

# Sentinel policy: Interdire instances < génération 6
policy "enforce-recent-instances" {
  enforcement_level = "hard-mandatory"
  
  rule {
    all instance_types as it {
      it matches "^(m6|c6|r6|t3)" or it matches "graviton"
    }
  }
}

Résultat : Force l’utilisation d’instances récentes (plus efficientes)

4. Observabilité de la durabilité

Mesurer l’impact environnemental comme on mesure les coûts ou la performance.

Métriques :

CO2e par transaction
CO2e par utilisateur/mois
Évolution dans le temps (réduction %)

Outils :

AWS Customer Carbon Footprint Tool :

Dashboard dans AWS Console
Empreinte par service, région, compte
Forecast et tendances

Cloud Carbon Footprint (Open Source) :

Multi-cloud (AWS, Azure, GCP)
Visualisations détaillées
Recommandations d’optimisation

Intégration dans dashboards :

┌─────────────────────────────────────┐
│ Dashboard Observabilité             │
├─────────────────────────────────────┤
│ Performance : ✅ Latency p95 < 200ms│
│ Coûts : ✅ Budget respecté          │
│ Durabilité : ⚠️ +5% CO2 ce mois    │
└─────────────────────────────────────┘

Traiter la durabilité comme un first-class citizen au même titre que perf et coûts.

Cas d’usage : L’impact de la Sustainability

Scénario sans conscience environnementale : Gaspillage invisible

Situation observée chez un client (fintech scale-up) :

Architecture initiale :

200 instances EC2 permanentes (on-premise mindset)
Générations anciennes (m5, m4)
Environnements dev/test 24/7 (80 instances)
Pas de cache, pas de CDN
Batch nocturnes sur instances surdimensionnées
Logs non compressés stockés à l’infini
Data transfer non optimisé

Empreinte carbone estimée : 150 tonnes CO2e/an Coûts : 85,000 €/mois

Waste identifié :

CPU moyen : 15% → 85% de capacité inutilisée
Dev/test 24/7 : 76% du temps idle
Logs : 500 TB non compressés
Data transfer : 100 TB/mois (APIs non optimisées)
Instances anciennes : -40% efficientes vs nouvelles

Transformation avec Sustainability mindset

Programme “Green Cloud” - 6 mois :

Phase 1 : Quick wins (Mois 1-2)

Auto-shutdown dev/test :
- Arrêt soir et week-end
- Économie : 60 instances × 75% temps = -80% énergie pour dev/test
- Impact : -15 tonnes CO2e/an
Compression logs :
- gzip + lifecycle vers Glacier
- 500 TB → 50 TB
- Impact : -10 tonnes CO2e/an
Right-sizing immédiat :
- 80 instances sous-utilisées downsizées
- Impact : -20 tonnes CO2e/an

Phase 2 : Architecture (Mois 3-4)

Migration Graviton :
- 100 instances m5 → m7g (Graviton3)
- +60% efficience énergétique
- Impact : -30 tonnes CO2e/an
Serverless pour APIs :
- 50 instances EC2 → Lambda + API Gateway
- Scale to zero hors utilisation
- Impact : -25 tonnes CO2e/an
CDN et caching :
- CloudFront + ElastiCache
- -70% data transfer
- -60% charge backend
- Impact : -15 tonnes CO2e/an
Batch optimization :
- Algorithmes optimisés (O(n²) → O(n log n))
- Processing 3h → 1h
- Impact : -10 tonnes CO2e/an

Phase 3 : Culture et gouvernance (Mois 5-6)

Monitoring CO2 :
- AWS Customer Carbon Footprint Tool
- Dashboard mensuel par équipe
- OKR : -50% CO2e d’ici fin d’année
Formation équipes :
- Green IT basics
- Sustainable coding practices
- Architecture eco-responsable
Policies :
- Graviton-first (sauf exception validée)
- Auto-shutdown obligatoire dev/test
- Review sustainability dans design docs

Résultats après 6 mois :

Empreinte carbone :

Avant : 150 tonnes CO2e/an
Après : 25 tonnes CO2e/an
Réduction : -83% (-125 tonnes CO2e/an)

Équivalences :

125 tonnes CO2e = 625,000 km en voiture
= 50 vols Paris-New York A/R
= 15 années de consommation électrique d’un foyer français

Coûts :

Avant : 85,000 €/mois
Après : 30,000 €/mois
Économie : -65% (55,000 €/mois = 660,000 €/an)

Performance :

Latence API : 300ms → 80ms (CDN + cache)
Batch processing : 3h → 1h (algo optimisés)
Disponibilité : 99.5% → 99.9% (architecture résiliente)

ROI du programme :

Investissement : 80,000 € (temps équipe + migrations)
Économie année 1 : 660,000 €
ROI financier : 8.25x

ROI environnemental :

125 tonnes CO2e évitées/an
Image de marque améliorée (communication “Green Cloud”)
Conformité anticipée (CSRD, taxonomie verte UE)
Attraction talents (engagement RSE)

Bénéfices indirects :

Architecture plus moderne et maintenable
Équipes sensibilisées (culture de l’efficience)
Avantage compétitif (appels d’offres avec critères ESG)

Outils et services AWS pour Sustainability

Mesure et visibilité

Customer Carbon Footprint Tool : Empreinte carbone dans AWS Console
CloudWatch Carbon Metrics : Intégration métriques CO2 (preview)
Sustainability Pillar - AWS WA Tool : Évaluation Well-Architected

Compute efficient

Graviton (m7g, c7g, r7g) : +60% efficience énergétique
Lambda : Scale to zero, pas de idle
Fargate : Containers sans gestion d’instances
Spot Instances : Utiliser capacité inutilisée

Storage optimisé

S3 Intelligent-Tiering : Optimisation automatique
EBS gp3 : +20% efficient vs gp2
Compression : gzip, parquet, Brotli

Réseau efficient

CloudFront : Edge caching, moins de data transfer
VPC Endpoints : Éviter transit Internet
Direct Connect : Connexion dédiée optimisée

Gouvernance

AWS Compute Optimizer : Recommandations efficience
AWS Instance Scheduler : Auto-shutdown automatisé
AWS Organizations : Policies de durabilité

Checklist d’implémentation Sustainability

Phase 1 : Mesurer (Mois 1)

Activer AWS Customer Carbon Footprint Tool
Établir baseline empreinte carbone actuelle
Analyser répartition par service, région, environnement
Identifier top 3 sources d’émissions
Définir objectifs de réduction (ex: -30% en 12 mois)

Phase 2 : Quick wins (Mois 2-3)

Auto-shutdown environnements dev/test (soir + week-end)
Compression logs + lifecycle S3
Right-sizing instances sous-utilisées
Migration EBS gp2 → gp3
Suppression ressources idle/oubliées
Impact attendu : -30-40% empreinte

Phase 3 : Architecture (Mois 4-6)

Migration vers instances Graviton (compatible workloads)
Serverless pour workloads sporadiques
CDN + caching (CloudFront, ElastiCache)
Optimisation data transfer (compression, GraphQL)
Batch processing optimisé (algo, timing)
Impact attendu : -30-50% empreinte additionnelle

Phase 4 : Culture et gouvernance (Mois 7-12)

Formation équipes (Green IT, sustainable coding)
Intégration sustainability dans design reviews
Policies et guardrails (Graviton-first, auto-shutdown)
Monitoring CO2 dans dashboards quotidiens
OKRs sustainability par équipe
Communication externe (bilan carbone, engagement)

Phase 5 : Optimisation continue (12+ mois)

Review trimestrielle empreinte carbone
Adoption nouveaux services efficients
Migration progressive vers régions renouvelables
Amélioration continue architecture
Benchmark vs industrie
Certification (ISO 14001, B-Corp, etc.)

La Sustainability au-delà d’AWS : Principes universels

Les principes du pilier Sustainability s’appliquent à tout contexte :

Azure :

Azure Carbon Optimization
Azure Sustainability Calculator
B-series burstable VMs
Premium SSD v2 (efficient)

Google Cloud :

Carbon Footprint reporting
Recommandations efficience énergétique
Régions 100% renouvelables (ex: Finland, Iowa)

On-premise :

Virtualisation pour densité
Serveurs Energy Star
PUE datacenter optimisé
Free cooling (air extérieur)

Edge/IoT :

ARM processors (efficient)
Edge computing (processing local)
Protocoles low-power (LoRaWAN, Zigbee)

Development :

Langages efficients (Rust, Go > Python > JavaScript)
Algorithmes optimisés
Code reviews avec focus efficience

Les fondamentaux restent identiques :

Mesurer pour comprendre
Optimiser l’utilisation (right-sizing)
Choisir l’efficient (Graviton, services managés)
Automatiser (shutdown, lifecycle)
Sensibiliser (culture)

Conclusion : Durabilité = Performance + Coûts + Éthique

Le pilier Sustainability est le plus récent du Well-Architected Framework, mais pas le moins important. Il marque une prise de conscience : l’architecture Cloud a un impact environnemental mesurable et optimisable.

La bonne nouvelle ? Durabilité, performance et coûts ne s’opposent pas. Au contraire, ils convergent :

Optimiser l’empreinte carbone = optimiser l’utilisation des ressources
Moins de ressources = moins de coûts
Architectures efficientes = meilleures performances

Les bénéfices sont multiples :

Environnemental :

Réduction 50-80% empreinte carbone (résultats observés)
Contribution concrète aux objectifs climat
Préservation des ressources

Financier :

Économies massives (durabilité = efficience = coûts réduits)
ROI programme Green IT : 5-20x première année
Conformité anticipée (CSRD, taxonomie verte)

Business :

Avantage compétitif (appels d’offres avec critères ESG)
Image de marque renforcée
Attraction et rétention des talents
Différenciation marché

Technique :

Architecture moderne et performante
Dette technique réduite
Culture d’excellence et d’efficience

La question n’est pas “faut-il investir dans la Sustainability ?”, mais “comment ne pas le faire ?”

Comme le dit Bill Gates : “Climate change is the toughest challenge humanity has ever faced. We need innovation at every level.” L’innovation commence par nos architectures.

Le Cloud peut être un accélérateur de transition écologique… ou un gouffre énergétique. À nous de choisir.

Conclusion de la série Well-Architected Framework :

Nous avons exploré les 6 piliers qui constituent une architecture Cloud de qualité :

Operational Excellence : Faire tourner la machine au quotidien
Security : Protéger les systèmes et les données
Reliability : Retomber sur ses pieds après chaque chute
Performance Efficiency : Faire plus avec moins
Cost Optimization : Payer juste, pas moins
Sustainability : Minimiser l’impact environnemental

Ces piliers ne sont pas indépendants. Ils se renforcent mutuellement :

La sécurité améliore la fiabilité
La performance optimise les coûts
La durabilité réduit les dépenses
L’excellence opérationnelle facilite tout le reste

Une architecture bien conçue n’est pas celle qui excelle sur un seul pilier. C’est celle qui trouve le bon équilibre entre tous, en fonction du contexte métier.

Besoin d’accompagnement pour rendre vos architectures plus durables ? Notre équipe d’experts certifiés AWS est disponible. Contactez-nous.