AWS Well-Architected Framework : Le pilier Performance Efficiency, l'art de l'optimum

Publié le 16 octobre 2025 par Mathieu Roger

Introduction : Performance ≠ Puissance brute

Quand on parle de performance, le réflexe classique est de penser “plus de CPU, plus de RAM, plus de tout”. C’est l’approche bulldozer : écraser les problèmes sous la puissance brute.

Le pilier Performance Efficiency du AWS Well-Architected Framework nous enseigne une approche radicalement différente : la performance, c’est l’efficience. Ce n’est pas utiliser le maximum de ressources, c’est utiliser les bonnes ressources, au bon moment, dans la bonne quantité.

Une architecture performante n’est pas celle qui a les plus grosses instances. C’est celle qui :

Répond aux besoins métiers avec le minimum de ressources nécessaires
S’adapte dynamiquement à la demande (scale up quand nécessaire, scale down quand possible)
Choisit les services adaptés à chaque cas d’usage
Reste à jour avec les innovations technologiques
Mesure et optimise en continu

C’est la différence entre un SUV qui consomme 15L/100km pour transporter une personne et une voiture hybride qui s’adapte au terrain et à la charge.

Qu’est-ce que le pilier Performance Efficiency ?

Définition et périmètre

Le pilier Performance Efficiency définit la capacité à utiliser les ressources informatiques de manière optimale pour :

Répondre aux exigences métiers
S’adapter aux évolutions de la demande
Maintenir cette efficience dans le temps

Il s’articule autour de cinq domaines de conception :

Selection : Choisir la bonne architecture et les bons services
Compute : Optimiser les ressources de calcul
Storage : Choisir le stockage adapté aux patterns d’accès
Database : Sélectionner le moteur de base de données optimal
Network : Optimiser la distribution et la latence réseau

Les principes directeurs

Démocratisation des technologies avancées : Le Cloud met à disposition des services managés qui intègrent des technologies complexes (ML, Big Data, IoT) sans nécessiter d’expertise spécialisée.

Portée mondiale en quelques minutes : Déployer dans plusieurs régions pour rapprocher les services des utilisateurs finaux.

Architecture serverless : Se concentrer sur la valeur métier, pas sur la gestion de l’infrastructure.

Expérimentation fréquente : Tester différentes configurations, itérer rapidement.

Affinité mécanique : Comprendre comment fonctionnent les services pour les utiliser au mieux de leurs capacités.

Métriques de la performance

La performance se mesure selon plusieurs dimensions :

Latence : Temps de réponse

p50, p95, p99 (percentiles)
TTFB (Time To First Byte)
End-to-end response time

Throughput : Débit

Requêtes par seconde (RPS)
Transactions par seconde (TPS)
Bits par seconde (bps)

Efficience : Ratio performance/ressources

Performance par euro dépensé
Performance par vCPU
Performance par Watt (Green IT)

Disponibilité : Capacité à répondre

% de requêtes réussies
Taux d’erreur (4xx, 5xx)

Selection : Choisir la bonne architecture

1. Compute : Le bon outil pour le bon job

Le Cloud offre un spectre de services de compute allant du contrôle maximal (EC2) à l’abstraction totale (Lambda). Choisir le bon service pour chaque workload est crucial.

EC2 (Elastic Compute Cloud) : Machines virtuelles

Quand ? : Workloads legacy, contrôle fin, besoins spécifiques (GPU, FPGA)
Avantages : Flexibilité maximale, contrôle total
Inconvénients : Gestion de l’infrastructure (patching, scaling, monitoring)

ECS/EKS (Containers) : Orchestration de conteneurs

Quand ? : Applications microservices, portabilité, écosystème Docker/Kubernetes
Avantages : Déploiements rapides, isolation, densité
Inconvénients : Complexité de l’orchestration

Lambda (Serverless) : Functions as a Service

Quand ? : Événements sporadiques, pics imprévisibles, microservices stateless
Avantages : Zero administration, scaling infini, paiement à la requête
Inconvénients : Cold starts, timeout 15 min, pas d’état persistant

Fargate : Containers serverless

Quand ? : Containers sans gérer les instances sous-jacentes
Avantages : Simplicité des containers + serverless
Inconvénients : Moins flexible que ECS/EKS sur EC2

Tableau de décision :

Critère	EC2	ECS/EKS	Lambda	Fargate
Contrôle	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐	⭐⭐
Simplicité	⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Coût (workload constant)	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐
Coût (workload sporadique)	⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Temps de démarrage	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐

Exemple concret :

Application web e-commerce avec différents composants :

Frontend web : ECS sur Fargate (containers, scaling automatique)
API Backend : Lambda (microservices, scaling infini, paiement à l’usage)
Traitement d’images : Lambda avec S3 trigger (événementiel)
Batch nocturne : EC2 Spot Instances (gros compute, tolérant aux interruptions)
ML Training : EC2 avec GPU (P3/P4 instances pour calculs intensifs)

Hybridation intelligente : Mixer les approches selon les besoins de chaque composant.

2. Types d’instances EC2 : Spécialisation

AWS propose plus de 500 types d’instances EC2, regroupés en familles :

General Purpose (T3, M6i) :

Ratio équilibré CPU/RAM
Workloads variés, applications web
T3 avec burstable CPU (économique pour workloads variables)

Compute Optimized (C6i, C7g) :

Ratio CPU élevé
Applications intensives en calcul, HPC, batch processing
C7g (Graviton3) : +25% perf/prix vs C6i

Memory Optimized (R6i, X2iedn) :

Ratio RAM élevé
Bases de données in-memory, caches, big data
X2iedn : jusqu’à 4 To de RAM par instance

Storage Optimized (I4i, D3) :

IOPS/débit disque élevé
Bases de données NoSQL, data warehousing
I4i : jusqu’à 2M IOPS par instance

Accelerated Computing (P4d, G5, Inf1) :

GPU, FPGA, Inferentia
ML training (P4d), ML inference (Inf1), gaming/streaming (G5)

Exemple de dimensionnement :

Application initiale : m5.large (2 vCPU, 8 GB RAM) → 200€/mois

Après analyse :

CPU : 15% d’utilisation moyenne
RAM : 75% d’utilisation
Pattern : Memory-bound, pas CPU-bound

Optimisation : Passer à r6i.large (2 vCPU, 16 GB RAM) → 180€/mois

Meilleur ratio RAM/prix
Performance améliorée (plus de cache disponible)
Économie : 20€/mois + meilleure perf

AWS Compute Optimizer : Service qui analyse l’utilisation et recommande les types d’instances optimaux.

3. Graviton : L’architecture ARM sur AWS

Les instances Graviton (processeurs ARM conçus par AWS) offrent un excellent rapport performance/prix :

Graviton3 (C7g, M7g, R7g) :

+25% performance vs génération Intel/AMD équivalente
-20% de coût vs instances x86
+60% efficience énergétique (Green IT)

Compatibilité :

Linux natif (Ubuntu, Amazon Linux 2, RHEL)
Containers (multi-arch builds)
Langages : Python, Java, Node.js, Go, Rust, .NET

Migration : Généralement transparente pour les applications cloud-native.

Exemple concret :

Cluster EKS :

Avant : 10x m6i.xlarge (x86) → 1500€/mois
Après : 10x m7g.xlarge (Graviton3) → 1200€/mois
Économie : 300€/mois (20%), performance équivalente ou supérieure

4. Spot Instances et Savings Plans

EC2 Spot Instances : Capacité inutilisée AWS à -70% de réduction

Quand ? : Workloads tolérants aux interruptions
Cas d’usage : Batch, CI/CD, big data, ML training
Stratégie : Diversifier les types d’instances et AZ

Savings Plans : Engagement 1 ou 3 ans pour -40% à -70%

Compute Savings Plans : Flexibilité maximale (famille, taille, région)
EC2 Instance Savings Plans : Engagement sur famille spécifique

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

Moins flexible que Savings Plans
Peut être vendu sur le marketplace

Exemple d’optimisation :

Facture EC2 initiale : 10,000€/mois (on-demand)

Stratégie mixte :

60% baseline : Savings Plans (3 ans) → 4,000€/mois (au lieu de 6,000€)
30% variable : On-demand → 3,000€/mois
10% batch : Spot Instances → 300€/mois (au lieu de 1,000€)

Total : 7,300€/mois au lieu de 10,000€ → 27% d’économie

Storage : Le bon stockage pour le bon pattern

Le stockage n’est pas uniforme. Choisir le bon service selon le pattern d’accès est crucial pour la performance et le coût.

1. Les différents types de stockage AWS

Block Storage (EBS) :

Volumes attachés à des instances EC2
Faible latence, IOPS élevées
Cas d’usage : OS, bases de données, applications nécessitant faible latence

Types EBS :

gp3 (General Purpose SSD) : Équilibré, 3000 IOPS baseline, configurable
io2 Block Express : Ultra haute performance, jusqu’à 256,000 IOPS, 99.999% durabilité
st1 (Throughput Optimized HDD) : Gros volumes séquentiels, data warehouses
sc1 (Cold HDD) : Archivage peu fréquent, le moins cher

File Storage (EFS, FSx) :

Stockage partagé, accessible par plusieurs instances
EFS : Linux, NFSv4, élastique, multi-AZ
FSx for Windows : Windows File Server managé
FSx for Lustre : HPC, calcul haute performance

Object Storage (S3) :

Stockage d’objets (fichiers) avec API HTTP
Durabilité 11 9s (99.999999999%)
Scalabilité infinie
Classes de stockage selon la fréquence d’accès

Classes S3 :

S3 Standard : Accès fréquent, milliseconde latency
S3 Intelligent-Tiering : Automatique selon l’accès
S3 Standard-IA (Infrequent Access) : Accès occasionnel, -50% vs Standard
S3 One Zone-IA : Accès rare, une seule AZ, -80% vs Standard
S3 Glacier Instant Retrieval : Archivage avec retrieval milliseconde
S3 Glacier Flexible Retrieval : Archivage, retrieval minutes/heures
S3 Glacier Deep Archive : Archivage long terme, retrieval 12h, le moins cher

Exemple d’optimisation S3 :

Application avec 100 TB de données :

10 TB : accès quotidien → S3 Standard → 2,300€/mois
30 TB : accès mensuel → S3 Standard-IA → 1,500€/mois
60 TB : archivage légal → S3 Glacier Deep Archive → 600€/mois

Total : 4,400€/mois au lieu de 23,000€ (tout en Standard) → 81% d’économie

S3 Lifecycle Policies : Automatiser la transition entre classes

Règle:
  - 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 (7 ans) : Supprimer

2. Patterns d’accès et optimisation

Read-heavy workloads :

Stratégie : Cache agressif
Services : CloudFront (CDN), ElastiCache (Redis/Memcached)
Pattern : Cache-Aside, Write-Through

Write-heavy workloads :

Stratégie : Bufferiser les écritures
Services : Kinesis Data Streams, SQS
Pattern : Write-Behind, Event Sourcing

Sequential access :

Stratégie : Throughput-optimized storage
Services : S3, EBS st1, FSx for Lustre

Random access :

Stratégie : IOPS-optimized storage
Services : EBS io2, Instance Store, DynamoDB

Exemple concret :

Application de streaming vidéo :

Vidéos originales : S3 Standard (upload une fois, stream souvent)
Vidéos transcodées : S3 Standard (accès fréquent)
Thumbnails : S3 + CloudFront (cache CDN global)
Vidéos anciennes (<6 mois) : S3 Standard-IA (accès occasionnel)
Vidéos très anciennes : S3 Glacier (archivage réglementaire)

Résultat : -60% de coût stockage, latence optimisée via CloudFront

3. Compression et déduplication

Compression : Réduire la taille des données

Gain : -50% à -90% selon le type de données
CPU overhead : généralement négligeable
Formats : gzip, brotli, zstd, parquet (pour données structurées)

Exemple :

Logs JSON non compressés : 1 TB/jour → 250€/mois (S3)
Logs gzip compressés : 100 GB/jour → 25€/mois
Économie : 225€/mois (90%)

Déduplication : Éliminer les doublons

Services : S3 Intelligent-Tiering (automatique)
Snapshots EBS : incrémentaux automatiquement (seuls les blocs changés)

Database : Le bon moteur pour le bon workload

Le choix de la base de données a un impact majeur sur la performance. AWS propose 15+ services de bases de données, chacun optimisé pour un cas d’usage.

1. Types de bases de données

Relationnelles (RDS, Aurora) :

ACID, transactions, requêtes complexes (JOIN)
Moteurs : PostgreSQL, MySQL, MariaDB, Oracle, SQL Server
Cas d’usage : Applications transactionnelles, ERP, CRM

NoSQL Key-Value (DynamoDB) :

Ultra faible latence (millisecondes), scaling infini
Cas d’usage : Session stores, carts, gaming leaderboards

NoSQL Document (DocumentDB) :

Compatible MongoDB, documents JSON
Cas d’usage : Catalogues produits, profils utilisateurs

In-Memory (ElastiCache) :

Redis/Memcached, latence sub-milliseconde
Cas d’usage : Caching, session store, pub/sub, leaderboards

Time-Series (Timestream) :

Optimisé pour séries temporelles (IoT, monitoring)
Requêtes analytiques rapides sur données temporelles

Graph (Neptune) :

Relations complexes, requêtes de graphe
Cas d’usage : Réseaux sociaux, recommendation engines, fraud detection

Ledger (QLDB) :

Immutable, cryptographiquement vérifiable
Cas d’usage : Blockchain-like, audit trails

Tableau de sélection :

Besoin	Base de données	Raison
Transactions ACID, relations complexes	Aurora/RDS	Relationnel éprouvé
Ultra faible latence (<10ms)	DynamoDB	NoSQL distribué
Cache haute performance	ElastiCache	In-memory
Time-series (IoT, metrics)	Timestream	Optimisé temporel
Graphes, relations	Neptune	Graph database
Analytics, big data	Redshift	Data warehouse
Recherche full-text	OpenSearch	Moteur de recherche

2. Aurora : La base relationnelle réinventée

Aurora est la base de données relationnelle cloud-native d’AWS, compatible MySQL et PostgreSQL.

Avantages vs RDS classique :

Performance : 5x plus rapide que MySQL, 3x plus rapide que PostgreSQL
Scalabilité : jusqu’à 128 TB, 15 read replicas
Disponibilité : 99.99%, réplication dans 3 AZ automatique
Serverless : Aurora Serverless v2 (scaling automatique)

Architecture Aurora :

┌────────────────────────────────────┐
│   Storage Layer (distribué)        │
│   - 6 copies dans 3 AZ             │
│   - Auto-repair, auto-backup       │
│   - Shared across replicas         │
└────────────────────────────────────┘
         ▲
         │
    ┌────┴────┐
    │         │
┌───┴───┐ ┌──┴────┐
│Writer │ │Readers│
│ (1)   │ │(0-15) │
└───────┘ └───────┘

Aurora Serverless v2 :

Scaling automatique de 0.5 à 128 ACU (Aurora Capacity Units)
Latence milliseconde pour le scaling
Paiement à la seconde
Idéal pour workloads variables ou imprévisibles

Exemple concret :

Application SaaS avec trafic variable :

RDS PostgreSQL : db.r6i.2xlarge permanent → 1,200€/mois
Aurora Serverless v2 : 0.5-16 ACU selon charge → 400€/mois (moyenne)
Économie : 67% + meilleure performance aux pics

3. DynamoDB : NoSQL à l’échelle

DynamoDB est la base NoSQL managée d’AWS, avec performance prévisible même à pétabyte scale.

Caractéristiques :

Latence : single-digit milliseconds
Throughput : illimité
Pas de serveur à gérer
Global Tables (multi-region)

Modes de capacité :

On-Demand :

Paiement par requête (Read/Write)
Scaling automatique instantané
Idéal pour trafic imprévisible

Provisioned :

Capacité réservée (RCU/WCU)
Auto-scaling configurable
Moins cher pour trafic prévisible constant

DynamoDB Accelerator (DAX) :

Cache in-memory compatible DynamoDB
Latence microseconde
Pas de changement de code

Exemple concret :

API de gaming avec leaderboard :

DynamoDB : partition key = game_id, sort key = score
GSI (Global Secondary Index) pour requêtes par user_id
DAX pour cache des top 100 (requêtes ultra-fréquentes)
Résultat : latence p99 < 5ms, scaling infini

Optimisation DynamoDB :

Hot partitions : Distribuer la charge avec partition key appropriée
Burst capacity : Exploiter la capacité burst temporaire
Sparse indexes : GSI seulement sur items filtrés
TTL : Supprimer automatiquement les données anciennes

4. ElastiCache : Performance in-memory

ElastiCache offre Redis et Memcached managés pour des performances sub-millisecond.

Redis :

Structures de données riches (strings, hashes, lists, sets, sorted sets)
Persistence optionnelle
Pub/Sub, Lua scripting
Replication, clustering

Memcached :

Cache simple key-value
Multi-threaded (meilleur CPU utilization)
Plus simple, moins de features

Patterns de caching :

1. Cache-Aside (Lazy Loading) :

def get_user(user_id):
    # Tentative cache
    user = cache.get(f"user:{user_id}")
    if user:
        return user
    
    # Cache miss → DB
    user = db.query("SELECT * FROM users WHERE id=?", user_id)
    cache.set(f"user:{user_id}", user, ttl=3600)
    return user

2. Write-Through :

def update_user(user_id, data):
    # Écriture simultanée DB + cache
    db.update("users", user_id, data)
    cache.set(f"user:{user_id}", data, ttl=3600)

3. Write-Behind :

def update_user(user_id, data):
    # Écriture immédiate cache, asynchrone DB
    cache.set(f"user:{user_id}", data, ttl=3600)
    queue.send({"action": "update", "table": "users", "id": user_id, "data": data})

Exemple concret :

E-commerce avec catalogue produits :

Sans cache : 500ms latency, 1000 RPS max sur RDS
Avec ElastiCache : 5ms latency, 10,000+ RPS
Cache hit ratio : 95%
Réduction charge DB : -95%

Sizing ElastiCache :

Estimer la working set size (données chaudes)
Prévoir 20-30% overhead mémoire
Monitoring evictions (si trop d’evictions → scale up)

Network : Optimiser la distribution

La performance réseau est souvent le goulot d’étranglement invisible.

1. CloudFront : CDN global

CloudFront est le CDN (Content Delivery Network) d’AWS avec 400+ points de présence mondiaux.

Avantages :

Cache au plus près des utilisateurs (latence réduite)
Offload du backend (déchargement de la bande passante)
Protection DDoS (AWS Shield intégré)
Compression automatique (gzip, brotli)

Cas d’usage :

Sites web statiques (HTML, CSS, JS, images)
API avec cache (GET idempotent)
Streaming vidéo (HLS, DASH)
Téléchargements de fichiers

Configuration optimale :

Behaviors:
  - PathPattern: "*.js|*.css|*.png|*.jpg"
    CachingPolicy: CachingOptimized
    TTL: 31536000 # 1 an (avec cache busting via query string)
  
  - PathPattern: "/api/*"
    CachingPolicy: CachingOptimizedForUncompressedObjects
    TTL: 300 # 5 minutes
    AllowedMethods: [GET, HEAD, OPTIONS]
  
  - PathPattern: "/api/write/*"
    CachingPolicy: CachingDisabled
    AllowedMethods: [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]

Exemple concret :

Site e-commerce global :

Sans CloudFront : latence 300ms (US → Paris), 10 TB/mois sortie EC2 → 920€/mois
Avec CloudFront : latence 30ms (edge local), 10 TB/mois CloudFront → 850€/mois + 90% cache hit
Backend : 1 TB/mois seulement (cache miss) → 92€/mois
Résultat : -80% latence, économies, meilleure UX

2. VPC et réseau interne

Placement Groups : Colocaliser les instances pour ultra-faible latency

Cluster : Même rack, <25 Gbps, pour HPC
Spread : AZ différentes, pour HA
Partition : Groupes séparés, pour big data (Hadoop, Cassandra)

Enhanced Networking : SR-IOV pour haute performance réseau

Jusqu’à 100 Gbps sur certaines instances
Latence réduite, jitter faible
ENA (Elastic Network Adapter) activé par défaut sur instances récentes

VPC Endpoints : Accès privé aux services AWS

Pas de transit par Internet Gateway
Latence réduite, sécurité accrue
Gateway Endpoints (S3, DynamoDB) : gratuit
Interface Endpoints (autres services) : payant

Exemple :

Application avec gros volumes S3 :

Via Internet : latence 100ms, coûts data transfer
Via VPC Gateway Endpoint : latence 10ms, gratuit
Gain : 90% latence, 100% économie sur data transfer

3. Global Accelerator : Routing optimal

AWS Global Accelerator route le trafic via le réseau backbone AWS plutôt que l’Internet public.

Avantages :

-60% amélioration latence (vs Internet public)
Anycast IPs statiques (2 IPs pour le monde entier)
Failover automatique entre régions
DDoS protection (AWS Shield Standard)

Quand utiliser :

Applications temps-réel (gaming, VoIP)
Applications multi-régions
Besoin d’IPs statiques
Performances critiques

Différence avec CloudFront :

CloudFront : Cache (statique/dynamique), HTTP/HTTPS
Global Accelerator : Proxy (TCP/UDP), pas de cache, tous protocoles

4. Direct Connect : Connexion dédiée

AWS Direct Connect : connexion réseau dédiée entre datacenter on-premise et AWS.

Avantages :

Bande passante prévisible (1 Gbps à 100 Gbps)
Latence réduite et stable
Coûts data transfer réduits
Accès privé (pas via Internet)

Cas d’usage :

Architectures hybrides (on-premise + Cloud)
Migration de gros volumes
Applications sensibles à la latence
Conformité/sécurité (pas de transit Internet)

Mesure et optimisation continue

1. Observabilité : Mesurer pour optimiser

Application Performance Monitoring (APM) :

AWS X-Ray : Tracing distribué
CloudWatch Application Insights : Monitoring applicatif automatisé
Services tiers : New Relic, Datadog, Dynatrace

Métriques clés à surveiller :

Application :

Latence (p50, p95, p99)
Throughput (requêtes/seconde)
Taux d’erreur
Apdex score (satisfaction utilisateur)

Infrastructure :

CPU, mémoire, disque, réseau
Queue depth, connection pools
Cache hit ratio
Database query performance

Business :

Conversions, transactions
Page load time
Revenue per hour
User engagement

Tableau de bord unifié : Créer un dashboard unique avec toutes les métriques critiques, corrélées :

Vue temps réel (last 15 min)
Alertes visuelles (rouge/orange/vert)
Drill-down vers détails (traces, logs)

2. Load Testing : Valider avant la production

Types de tests :

Load Test : Performance sous charge normale/pic

Identifier les goulots d’étranglement
Valider les SLAs
Dimensionner l’auto-scaling

Stress Test : Limite du système

Trouver le breaking point
Observer le comportement en dégradation
Valider les mécanismes de résilience

Soak Test : Performance sur durée longue

Détection des memory leaks
Stabilité dans le temps
Performance de garbage collection

Spike Test : Réaction aux pics soudains

Valider l’auto-scaling
Temps de warm-up
Comportement des queues

Outils :

AWS Distributed Load Testing : Solution managée
JMeter, Gatling, Locust : Open-source
Artillery, k6 : Modernes et developer-friendly

Exemple de scénario :

E-commerce Black Friday :

Scenario:
  - Ramp-up: 0 à 10,000 utilisateurs en 10 minutes
  - Sustain: 10,000 utilisateurs pendant 2 heures
  - Spike: Montée à 50,000 utilisateurs en 5 minutes (annonce flash sale)
  - Sustain spike: 50,000 utilisateurs pendant 30 minutes
  - Ramp-down: Retour à 10,000 en 10 minutes

Métriques à observer:
  - Latency p95 doit rester < 500ms
  - Error rate < 0.1%
  - Auto-scaling doit réagir en < 5 minutes
  - Database CPU doit rester < 70%

3. AWS Compute Optimizer

Service qui analyse l’utilisation des ressources et recommande des optimisations.

Ce qu’il analyse :

EC2 instances : Type, taille
EBS volumes : Type, IOPS provisionnées
Lambda functions : Memory allocation
Auto Scaling Groups : Configuration

Recommandations :

Over-provisioned : Downsize pour économiser
Under-provisioned : Upsize pour performance
Type optimal : Changer de famille (ex: m5 → c5 si CPU-bound)

Exemple :

Analyse de 100 instances EC2 :

40% over-provisioned → Économie potentielle : 12,000€/an
10% under-provisioned → Risque performance
30% optimales
20% recommendations Graviton → +8,000€/an économie + meilleure perf

Adoption progressive :

Trier par économies potentielles
Commencer par les non-prod (dev, staging)
Valider avec load tests
Déployer en prod avec canary
Monitorer et ajuster

4. Optimisation continue : Culture et processus

Performance reviews régulières :

Trimestrielles : Review complète de l’architecture
Mensuelles : Analyse des métriques de performance
Hebdomadaires : Suivi des tendances

Performance budgets : Définir des budgets de performance comme on définit des budgets de coûts :

Page load time < 2s (p95)
API latency < 200ms (p95)
Time to interactive < 3s

Si dépassement → freeze des features, focus optimisation

Boucles de feedback :

Développeurs voient les métriques de performance de leur code
Incidents de performance analysés en post-mortem
Apprentissages partagés en équipe
Optimisations célébrées

Cas d’usage : L’impact de la Performance Efficiency

Scénario sans optimisation : Gaspillage silencieux

Situation observée chez un client :

Architecture initiale :

Application web sur EC2 : m5.2xlarge (8 vCPU, 32 GB RAM) x 10 instances
Load Balancer ALB
RDS PostgreSQL : db.r5.2xlarge (8 vCPU, 64 GB RAM)
Pas de cache, pas de CDN
Instances fixes 24/7

Analyse de l’utilisation :

CPU moyen : 12% (sous-utilisé à 88%)
RAM moyenne : 35% (sous-utilisée à 65%)
RDS CPU moyen : 18%
Trafic : 80% de requêtes identiques (catalogues produits)
Peak hours : 10h-18h en semaine, quasi-nul nuit et week-end

Coûts mensuels :

EC2 : 10 x 300€ = 3,000€
RDS : 1,200€
Data transfer : 500€
Total : 4,700€/mois

Problèmes :

Surcoût : Payer pour 88% de CPU inutilisé
Performance : Latence 300-500ms (pas de cache, pas de CDN)
Rigidité : Scaling manuel seulement
Gâchis énergétique : Serveurs idle consomment 24/7

Transformation avec Performance Efficiency

Nouvelle architecture :

Compute :
- Passer à c6i.large (2 vCPU, 4 GB RAM) : CPU-optimized, suffisant vu la charge
- Auto Scaling : 2 instances minimum, 8 maximum
- Scaling schedule : scale down la nuit et week-end
Cache :
- ElastiCache Redis : cache.t3.medium
- Cache-aside pattern : 90% cache hit ratio
CDN :
- CloudFront devant ALB
- Cache statique (images, CSS, JS) : 95% hit ratio
Base de données :
- Aurora Serverless v2 (au lieu de RDS)
- Scaling automatique 0.5-8 ACU selon la charge
Storage :
- Images produits sur S3 + CloudFront
- Lifecycle policy : anciennes images vers S3-IA

Résultats mesurés :

Performance :

Latence : 300ms → 50ms (85% amélioration)
Throughput : 500 req/s → 2,000 req/s (4x)
Page load time : 4s → 1.2s
Cache hit ratio : 0% → 90%

Coûts mensuels :

EC2 (moyenne 4 instances) : 4 x 100€ = 400€
ElastiCache : 50€
CloudFront : 200€
Aurora Serverless : 300€ (moyenne)
S3 + lifecycle : 50€
Total : 1,000€/mois

Économie : 3,700€/mois (79%) + amélioration massive de la performance

ROI :

Investissement migration : 20 jours homme = 15,000€
Économie annuelle : 44,400€
ROI : 3 mois

Bénéfices indirects :

Satisfaction utilisateur : +40% (page load time)
Conversion : +12% (performance = UX = ventes)
Green IT : -75% consommation énergétique
Équipe : Déploiements plus rapides, scaling automatique

Stratégies avancées de Performance Efficiency

1. Serverless-first mindset

Privilégier le serverless quand possible :

Lambda + API Gateway :

Pour APIs avec trafic variable
Zero maintenance
Scaling infini
Paiement à la requête

Step Functions :

Orchestration de workflows
Gestion d’état sans serveur
Retry, error handling natif

EventBridge :

Bus d’événements
Découplage complet
Intégrations natives (100+ services)

Exemple : Pipeline de traitement d’images

S3 upload (image)
  → Lambda (validation)
  → SQS queue
  → Lambda (resize)
  → Lambda (watermark)
  → S3 (processed)
  → EventBridge (notification)

Coût : $0.20 par 1000 images (vs $200/mois EC2 idle)

2. Right-sizing continu

AWS Cost Explorer : Analyse des recommandations

EC2 instance right-sizing
Idle resources detection
Reserved Instances recommendations

Automatisation :

Lambda function : Analyser CloudWatch metrics hebdomadairement
Si CPU < 20% pendant 7 jours → Tag “candidate-downsize”
Notification équipe avec recommandation
Review et validation humaine

3. Multi-region intelligemment

Quand multi-region ?

Latence : Rapprocher des utilisateurs globaux
Compliance : Data residency requirements
Disaster Recovery : RTO/RPO critiques

Stratégies :

Active-Active : Trafic réparti, plus complexe, plus cher
Active-Passive : Région primaire, failover secondaire
Route 53 Geolocation : Routing par géographie

Réplication données :

Aurora Global Database : <1s lag
DynamoDB Global Tables : Active-active
S3 Cross-Region Replication : Asynchrone

4. Architectures event-driven

Découpler avec événements pour performance et résilience :

Pattern :

Service A → EventBridge → Service B
                        → Service C
                        → Service D

Avantages :

Scaling indépendant
Pas de couplage temporel
Retry natif
Observabilité (event logs)

Services :

EventBridge : Bus événements
SNS : Pub/Sub
SQS : Queue FIFO/standard
Kinesis : Streaming temps réel

Outils et services AWS pour Performance Efficiency

Compute

Lambda : Serverless compute
Fargate : Containers serverless
EC2 : Instances optimisées par workload
AWS Batch : Batch computing managé

Storage

S3 : Object storage avec classes multiples
EBS : Block storage optimisé (gp3, io2)
EFS : File storage élastique
FSx : File systems spécialisés

Database

Aurora : Relationnel haute performance
DynamoDB : NoSQL ultra-scalable
ElastiCache : In-memory caching
MemoryDB : Redis durable

Network

CloudFront : CDN global
Global Accelerator : Routing optimisé
VPC : Réseau isolé
Direct Connect : Connexion dédiée

Monitoring & Optimization

CloudWatch : Métriques et logs
X-Ray : Tracing distribué
Compute Optimizer : Recommandations ML
Cost Explorer : Analyse et right-sizing

Checklist d’implémentation Performance Efficiency

Phase 1 : Mesurer (2 semaines)

Implémenter observabilité complète (métriques, logs, traces)
Établir baseline de performance actuelle
Identifier les goulots d’étranglement
Analyser patterns d’utilisation (CPU, RAM, réseau, I/O)
Calculer les coûts actuels par service

Phase 2 : Quick wins (1 mois)

Activer Compute Optimizer et analyser recommandations
Right-size les instances sous-utilisées
Implémenter ElastiCache pour workloads read-heavy
Activer CloudFront pour contenu statique
Configurer S3 lifecycle policies
Passer les workloads variables en Serverless (Lambda)

Phase 3 : Architecture (3 mois)

Migrer bases de données vers services managés (Aurora, DynamoDB)
Implémenter auto-scaling sur tous les tiers
Découpler avec SQS/SNS/EventBridge
Multi-AZ pour haute disponibilité
VPC endpoints pour services AWS

Phase 4 : Optimisation avancée (6+ mois)

Tester et adopter instances Graviton
Spot Instances pour workloads tolérants
Multi-region pour latence globale
Performance budgets et monitoring continu
Culture d’optimisation (reviews trimestrielles)

Conclusion : Performance et efficience, pas performance ou efficience

Le pilier Performance Efficiency nous rappelle une vérité essentielle : plus n’est pas toujours mieux. La vraie performance, c’est l’adéquation parfaite entre ressources et besoins.

Une architecture performante :

S’adapte : Scale up pour les pics, scale down pour économiser
Choisit : Les bons services pour les bons workloads
Mesure : Observer, analyser, optimiser en continu
Évolue : Adopte les innovations plutôt que de rester figée

Les bénéfices sont multiples :

Business :

Meilleure expérience utilisateur (latence réduite)
Coûts maîtrisés (pas de gaspillage)
Agilité accrue (scaling automatique)

Technique :

Architecture moderne et maintenable
Résilience (services managés)
Observabilité (comprendre son système)

Environnemental :

Réduction de l’empreinte carbone
Efficience énergétique (utilisation optimale)

La question n’est pas “combien de puissance ?”, mais “quelle est la juste puissance ?”

Comme le dit Jeff Bezos : “We choose to optimize for simplicity, which sometimes leads us to use less efficient but more understandable solutions.” La performance ultime n’est pas toujours la bonne solution. L’efficience, elle, l’est toujours.

Prochainement dans cette série : Le pilier Cost Optimization du AWS Well-Architected Framework — comment maîtriser les coûts sans sacrifier la qualité.

Besoin d’un audit de performance ou d’accompagnement pour optimiser vos architectures Cloud ? Notre équipe d’experts certifiés AWS est disponible. Contactez-nous.