Why AWS for an e-commerce

Why AWS, and not a plain server

An e-commerce on a single shared server works — until the day it matters. A traffic spike (a sale, a post that takes off), a disk failure, a corrupted database: every incident is paid in lost orders. AWS doesn’t make the problem magic, but it gives you the right tool for each risk.

The big picture

Four services, each on its job. A request comes in through the CDN, the site runs on EC2, the data lives in RDS, and photos are served from S3 — optimized along the way by Lambda.

EC2 — the site

EC2 is a machine you fully control. It’s the right pick when you have legacy PHP (WooCommerce, PrestaShop) or a server-rendered Next.js app: you install what you want, you own the 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 — the managed database

Rule number one: the database does not run on the EC2. A database on the same machine as the site means a disk failure = lost orders, and zero backup the day you need one. RDS runs MySQL or PostgreSQL for you.

# 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 — the product photos

Product images have no business on the EC2 disk: it doesn’t scale, it’s lost on redeploy, and it saturates the machine. They go to S3 — near-indestructible, cheap object storage — and are served through 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 — WebP optimization

This is the brick that changes everything on speed. Merchants upload 5 MB JPEGs straight from the phone. You never serve that to the visitor. On every drop into S3, an event triggers a Lambda that converts to WebP and generates several sizes.

// 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",
      }));
    }
  }
}

Result: a 5 MB image becomes three WebP files of a few dozen KB, served by CloudFront with a one-year cache. The product page goes from slow to instant — with nothing for the merchant to do.

Surviving a Black Friday: ALB, auto scaling and caches

A single EC2, even well-sized, eventually saturates on a peak day. The real defense isn’t a bigger machine, it’s an Application Load Balancer in front of an auto-scaling group: traffic spreads across several identical EC2 instances, and the group adds or removes machines on its own based on load.

The scaling policy I use

I drive the group with target tracking: I set a target (say 50% average CPU, or a request count per instance) and AWS creates the CloudWatch alarms that scale capacity up then back down. For an e-commerce, the most meaningful metric is `ALBRequestCountPerTarget` — the average number of requests per instance behind the load balancer. A detail from the AWS docs: set the target as high as possible with a buffer for spikes, and the group keeps just enough machines running.

# 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 and state: out of the EC2

As soon as there are several EC2s, a problem appears: a visitor’s cart must not live in the memory of a single machine, otherwise the next click lands on another instance and the cart is empty. So the session and hot data (catalog, prices) move out of the EC2 into a shared cache. I use Amazon ElastiCache (Redis/Valkey): every EC2 reads and writes the same session, and the most frequent catalog queries no longer hit RDS on every page.

CloudFront tuning, VPC and payment isolation

On CloudFront, everything happens in the cache behaviors: a single site doesn’t have one caching behavior, but one per content type. I split into at least two: assets (images, CSS, JS) cached hard, and dynamic pages (cart, account) not cached at all.

The exact values of the managed policies are documented: `CachingOptimized` goes up to a one-year max TTL, `CachingDisabled` stays at zero. I lean on them rather than writing my own policies — less config to maintain. Details in the managed cache policies docs.

The VPC: nobody talks to RDS from outside

The whole architecture lives in a VPC split into subnets. The EC2s sit in a public subnet (reachable via the ALB), RDS and ElastiCache in a private subnet with no route to the internet. Security groups do the rest: the RDS SG only accepts port 3306 from the EC2 SG, nothing else.

Payments: get them out of scope

I never let a card number transit through my EC2s. Payment goes to a PCI provider (Stripe, Adyen…) via a client-side hosted field: the card never touches my infra, so my PCI DSS scope shrinks. When part of it must stay with me, the AWS logic is clear — isolate cardholder data in a dedicated account, separate from the rest, to de-scope the non-PCI side. That’s exactly the approach described in this AWS security post on serverless PCI.

Sources & further reading