Scale without blowing the budget

The starting point

We start from the e-commerce architecture: EC2 for the site, RDS for the database, S3 + CloudFront for images. To scale, you don’t grow one machine forever — you put several behind a load balancer, and offload the database.

Scale up then back down

The key to controlled cost is elasticity: add instances when traffic rises, remove them when it falls. You only pay for peak capacity during the peak.

# auto-scaling : grossir au trafic, redescendre ensuite
resource "aws_autoscaling_policy" "cpu" {
  name        = "scale-on-cpu"
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0   # vise 60% de CPU : au-dela, on ajoute une instance
  }
}

Offload the database

The database is almost always the first bottleneck. Before adding web servers, cache what’s read on repeat — often 80% of queries hit 20% of the data.

// soulager la base : mettre en cache ce qui est lu en boucle
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);      // pas de requete DB
const rows = await db.query("SELECT ...");   // fallback base
await redis.set(key, JSON.stringify(rows), "EX", 60);
return rows;

Keep cost tied to traffic

Which scaling policy to pick

“Auto-scaling” isn't one button. There are several ways to trigger adding instances, and the choice changes behavior during a spike. On my e-commerce architecture I almost always start from target tracking: I set a target — say 50% average CPU, or a request count per instance — and EC2 Auto Scaling creates and manages the CloudWatch alarms itself to hold that target. AWS explicitly recommends it for scaling on average CPU or request count per target.

Anticipating the predictable spike: predictive scaling

Target tracking is reactive: it waits for CPU to climb before acting, and a fresh instance takes a minute or two to boot. For a spike I can see coming — Monday-morning sale, a 6pm campaign — I add predictive scaling. It analyzes up to 14 days of history, derives an hourly 48-hour forecast, and provisions before the load lands. Two things to remember: it starts in “forecast only” mode (it forecasts without scaling, so you can validate first), and it only scales out — to come back down you keep your dynamic policies. Predictive handles the predictable, target tracking absorbs the unexpected on top.

The economics of hit ratio

A cache is only worth its hit ratio: the share of requests served from cache instead of from the origin. That number isn't cosmetic — it drives the bill directly. At 80% hit, only one request in five reaches the database or EC2; at 95%, it's one in twenty. Going from 80% to 95% isn't “15% better”: it quarters the load that lands behind — potentially one fewer read replica, or two fewer EC2 instances during the peak.

In practice there are two caches to watch. On ElastiCache/Redis, the AWS guide on which metrics to monitor recommends alarming on evictions and memory: when Redis evicts keys for lack of room, your hit ratio drops and the database eats it all again. In front of static assets, CloudFront has its own lever: increase the cache hit ratio by lengthening max-age, trimming the query strings and cookies pulled into the cache key, and enabling Origin Shield as an extra layer in front of the origin.

Sources & further reading