Pourquoi AWS pour un e-commerce

Pourquoi AWS, et pas un simple serveur

Un e-commerce sur un seul serveur mutualisé, ça marche — jusqu’au jour où ça compte. Un pic de trafic (une promo, un post qui marche), une panne disque, une base corrompue : chaque incident se paie en commandes perdues. AWS ne rend pas le problème magique, mais il te donne les bons outils pour chaque risque.

La vue d’ensemble

Quatre services, chacun sur son rôle. Une requête entre par le CDN, le site tourne sur EC2, les données vivent dans RDS, et les photos sont servies depuis S3 — optimisées au passage par Lambda.

EC2 — le site

EC2, c’est une machine que tu contrôles entièrement. C’est le bon choix quand tu as du PHP historique (WooCommerce, PrestaShop) ou une app Next.js en rendu serveur : tu installes ce que tu veux, tu maîtrises la configuration.

# sur l'EC2 : Next.js en production, garde-fou au reboot
$ npm ci && npm run build
$ pm2 start "npm run start" --name shop
$ pm2 save && pm2 startup   # relance apres un redemarrage de l'instance

RDS — la base managée

La règle numéro un : la base ne tourne pas sur l’EC2. Une base sur la même machine que le site, c’est une panne disque = commandes perdues, et zéro sauvegarde le jour où il faut. RDS gère MySQL ou PostgreSQL pour toi.

# la base ne tourne PAS sur l'EC2 — elle est managee par RDS
DATABASE_URL=mysql://app:•••@shop-db.abc123.eu-west-3.rds.amazonaws.com:3306/shop

S3 — les photos produit

Les images produit n’ont rien à faire sur le disque de l’EC2 : ça ne scale pas, ça se perd au redéploiement, et ça sature la machine. Elles vont dans S3 — un stockage objet quasi infaillible et bon marché — et sont servies via CloudFront.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: "eu-west-3" });
// une photo produit part sur S3 — jamais sur le disque de l'EC2
await s3.send(new PutObjectCommand({
  Bucket: "shop-produits",
  Key: `produits/${sku}/original.jpg`,
  Body: fileBuffer,
  ContentType: "image/jpeg",
}));

Lambda — l’optimisation WebP

C’est la brique qui change tout côté vitesse. Les commerçants uploadent des JPEG de 5 Mo sortis du téléphone. On ne sert jamais ça au visiteur. À chaque dépôt dans S3, un événement déclenche une Lambda qui convertit en WebP et génère plusieurs tailles.

// handler Lambda — declenche a chaque upload dans le bucket S3
import { S3Client, GetObjectCommand, PutObjectCommand } from "@aws-sdk/client-s3";
import sharp from "sharp";
const s3 = new S3Client({});
export async function handler(event) {
  for (const rec of event.Records) {
    const Bucket = rec.s3.bucket.name;
    const Key = decodeURIComponent(rec.s3.object.key);
    if (!Key.endsWith("original.jpg")) continue;   // evite la boucle infinie
    const obj = await s3.send(new GetObjectCommand({ Bucket, Key }));
    const input = Buffer.from(await obj.Body.transformToByteArray());
    // 3 tailles, converties en WebP
    for (const w of [400, 800, 1600]) {
      const out = await sharp(input).resize(w).webp({ quality: 80 }).toBuffer();
      await s3.send(new PutObjectCommand({
        Bucket,
        Key: Key.replace("original.jpg", `${w}.webp`),
        Body: out,
        ContentType: "image/webp",
        CacheControl: "public, max-age=31536000, immutable",
      }));
    }
  }
}

Résultat : une image de 5 Mo devient trois WebP de quelques dizaines de Ko, servies par CloudFront avec un cache d’un an. La page produit passe de lente à instantanée — sans que le commerçant n’ait rien à faire.

Tenir un Black Friday : ALB, auto-scaling et caches

Un EC2 unique, même bien dimensionné, finit par saturer un jour de pic. La vraie parade, ce n’est pas une plus grosse machine, c’est un Application Load Balancer devant un groupe d’auto-scaling : le trafic se répartit sur plusieurs EC2 identiques, et le groupe ajoute ou retire des machines tout seul selon la charge.

La politique de scaling que j’utilise

Je pilote le groupe en target tracking : je fixe une cible (par exemple 50 % de CPU moyen, ou un nombre de requêtes par instance) et AWS crée les alarmes CloudWatch qui montent puis redescendent la capacité. Pour un e-commerce, la métrique la plus parlante est `ALBRequestCountPerTarget` — le nombre moyen de requêtes par instance derrière le load balancer. Détail cité par la doc AWS : mets une cible aussi haute que possible, avec une marge pour les à-coups, et le groupe garde juste ce qu’il faut de machines.

# cible : 1000 requetes/instance/minute derriere l'ALB
$ aws autoscaling put-scaling-policy \
    --auto-scaling-group-name shop-asg \
    --policy-name shop-req-tracking \
    --policy-type TargetTrackingScaling \
    --target-tracking-configuration '{
      "PredefinedMetricSpecification": {
        "PredefinedMetricType": "ALBRequestCountPerTarget",
        "ResourceLabel": "app/shop-alb/abc123/targetgroup/shop-tg/def456"
      },
      "TargetValue": 1000.0
    }'

Sessions et état : sortis de l’EC2

Dès qu’il y a plusieurs EC2, un problème surgit : le panier d’un visiteur ne doit pas vivre dans la mémoire d’une seule machine, sinon le prochain clic tombe sur une autre instance et le panier est vide. La session et les données chaudes (catalogue, prix) sortent donc de l’EC2 vers un cache partagé. J’utilise Amazon ElastiCache (Redis/Valkey) : chaque EC2 lit et écrit la même session, et les requêtes catalogue les plus fréquentes ne tapent plus RDS à chaque page.

CloudFront fin, VPC et isolation du paiement

Sur CloudFront, tout se joue dans les cache behaviors : un même site n’a pas un seul comportement de cache, mais un par type de contenu. Je découpe au minimum en deux : les assets (images, CSS, JS) qu’on cache fort, et les pages dynamiques (panier, compte) qu’on ne cache pas.

Les valeurs exactes des policies managées sont documentées : `CachingOptimized` monte à un an de TTL max, `CachingDisabled` reste à zéro. Je m’appuie sur elles plutôt que d’écrire mes propres policies — moins de config à maintenir. Détails dans la doc des managed cache policies.

Le VPC : personne ne parle à RDS depuis dehors

Toute l’archi vit dans un VPC découpé en sous-réseaux. Les EC2 sont dans un sous-réseau public (joignables via l’ALB), RDS et ElastiCache dans un sous-réseau privé, sans route vers Internet. Les security groups font le reste : le SG de RDS n’accepte le port 3306 que depuis le SG des EC2, rien d’autre.

Le paiement : le sortir du scope

Je ne fais jamais transiter un numéro de carte par mes EC2. Le paiement part chez un prestataire PCI (Stripe, Adyen…) via un champ hébergé côté client : la carte ne touche pas mon infra, donc mon scope PCI DSS fond. Quand une partie doit rester chez moi, la logique AWS est claire — isoler les données cardholder dans un compte dédié, séparé du reste, pour « dé-scoper » le non-PCI. C’est exactement l’approche décrite dans ce billet sécurité AWS sur le PCI en serverless.

Sources & ressources