Cloud Cost Management for E-commerce: Cut Costs Without Cutting Performance

E-commerce cloud spend spikes because traffic is structurally unpredictable — Black Friday can deliver 8x normal order volume, and auto-scaling groups scale out faster than they scale back in, leaving over-provisioned capacity running for days after a sale ends (AWS, 2024). Most cloud workloads are predictable. An internal dashboard serves the same 200 employees at the same rate every weekday. E-commerce is different — it has hard traffic peaks that arrive with almost no warning (a viral post, a flash sale, a news mention) and guaranteed seasonal surges that double or triple baseline load.

Five cost drivers are specific to e-commerce and rarely affect other workloads at the same scale:

1. Seasonal and promotional traffic spikes

A WooCommerce or Magento store doing 1,000 orders a day in October might hit 8,000 orders on Black Friday. Auto-scaling handles the load, but the scaling events trigger new instance launches, larger database connection pools, and more CDN origin pulls — all of which cost money. The bigger problem: auto-scaling groups often scale out faster than they scale in, leaving over-provisioned capacity running for hours or days after a sale ends.

2. Image-heavy product catalogs

A mid-size fashion retailer might have 20,000 SKUs, each with 6–10 product images in multiple resolutions. That's 120,000–200,000 image files in S3 or Azure Blob Storage, served through a CDN on every page load. S3 storage is cheap ($0.023/GB), but the combination of storage, CDN egress ($0.085/GB for CloudFront), and origin request charges adds up to $100–$300/month for image delivery alone — before you account for product video, lookbooks, or user-generated content. Converting images to WebP cuts that figure by 55–65% with no visible quality difference at typical screen sizes.

3. CDN costs at scale

CDNs reduce origin load and improve performance, but they're not free. CloudFront charges $0.085/GB for the first 10 TB of data transfer per month. Akamai and Fastly charge more. A store serving 50 TB/month of assets pays $4,250 in CDN data transfer alone — often without visibility into whether 40% of that traffic is uncached repeat requests hitting the origin anyway. For a full breakdown of how egress pricing works across providers, see our cloud egress costs guide. For hosting cost breakdowns by GMV tier, see our e-commerce hosting cost guide.

4. Search, recommendations, and real-time personalization

Headless e-commerce stacks often include Elasticsearch or OpenSearch for product search, a recommendation engine (SageMaker, Vertex AI, or a third-party API), and a personalization layer. Each of these runs continuously. An OpenSearch cluster sized for peak traffic costs $200–$600/month on AWS even when search volume is a fraction of peak. Most teams never resize it between seasons.

5. Database scaling for checkout and inventory

Checkout is the one place e-commerce teams never compromise on performance — for good reason. But the result is databases sized for peak transaction throughput, running that way year-round. An RDS PostgreSQL db.r6g.2xlarge instance that handles Black Friday checkout peaks costs $700–$900/month on-demand. A db.r6g.large handles normal load for $180/month. The difference — $520–$720/month — sits idle for 10 months of the year.

For a $1,500/month e-commerce bill, compute and database together represent 55–65% of total spend — the rest splits across CDN, storage, caching, and search (SpendArk internal data, 2025). Below is a representative breakdown for a WooCommerce or Magento store doing $1–$5M in annual revenue, self-hosted on AWS. Headless stacks (Next.js commerce + Shopify Plus API) look similar but shift more spend toward CDN and serverless.

At the $1,500/month tier, a representative breakdown looks like this:

• EC2 / ECS (web tier + workers): $480–$540 — typically 2–4 t3.medium or c6g.large instances for the application layer, plus worker nodes for background jobs
• RDS (PostgreSQL or MySQL): $280–$380 — a db.r6g.large or db.m6g.large with Multi-AZ; often sized 1–2 tiers above what off-peak load actually needs
• CloudFront + S3 (images, assets): $180–$280 — depends heavily on catalog size, image optimization, and cache hit rate
• ElastiCache / Redis (sessions, cart, cache): $80–$140 — cache.r6g.large; often running larger than needed because "cache nodes should never be the bottleneck"
• OpenSearch / Elasticsearch (product search): $120–$200 — sized for peak, running year-round
• Load balancer, NAT Gateway, data transfer: $80–$120 — the line items nobody reviews
• Backups, snapshots, logging: $40–$80

Of that $1,500, approximately $300–$500 is recoverable without touching uptime or user experience — mainly through database right-sizing between seasons, cache configuration, and CDN cache hit rate improvements. If you want to benchmark your infrastructure spend against similar-scale products, our guide to cloud cost per user covers typical ranges for both API-heavy and media-heavy workloads at each user tier.

The average e-commerce store that scales up for Black Friday retains 60–80% of that extra capacity into the following month — paying peak-season prices during the lowest-traffic period of the year (SpendArk internal data, 2025). Black Friday is the defining cloud cost event for e-commerce. Engineering teams rightfully prepare: they increase auto-scaling group minimums, pre-warm CloudFront distributions, scale up RDS instances, and pre-provision ElastiCache nodes. All of that is correct. The problem is what happens in December.

The manual scale-up before Black Friday is almost never followed by a manual scale-down after it. Teams are exhausted from the peak, attention shifts to the holidays, and over-provisioned infrastructure runs at full cost through January. The fix is a post-sale runbook. Thirty minutes of work. It saves $400–$900/month every January.

Auto-scaling groups that don't scale in

Auto-scaling scale-out events are triggered by CPU or request thresholds. Scale-in events use the same thresholds but with a cooldown period — and cooldown defaults in AWS Auto Scaling are 300 seconds (5 minutes). During a Black Friday sale where traffic drops suddenly, the cooldown means instances stay running longer than necessary. More problematically, teams often manually increase the Auto Scaling group minimum instance count before the sale and forget to lower it afterward. That minimum floor keeps instances running regardless of load.

Estimated cost: An extra c6g.2xlarge instance ($0.272/hr on-demand) left running for 30 days costs $196. Two extra instances is $392. For teams that scale to 10 instances for Black Friday from a baseline of 3, forgetting to reset the minimum wastes $1,100–$1,400/month in January.

Pre-warming costs that outlast the event

CloudFront pre-warming (requesting CloudFront to allocate additional capacity for your distribution) is free to request but requires traffic to keep the edge caches populated. The real cost is the origin infrastructure pre-warmed to handle direct traffic if the CDN misses. Teams often pre-scale origin servers to handle peak CDN miss rates — which are highest right when a sale starts, before caches warm up. After 48 hours, CDN hit rates normalize to 85–95%, and the origin over-provisioning becomes pure waste.

Reserved capacity vs on-demand for peak events

One common mistake: buying Reserved Instances for peak traffic rather than for baseline. Reserved Instances should cover your stable minimum. Black Friday extra capacity should be on-demand or — where workloads allow — spot. The math is simple: a 1-year Reserved Instance for a c6g.2xlarge costs $139/month. If you only need that instance for 2 months (November–December), you're paying $139 × 12 = $1,668 for $272 × 2 = $544 of actual usage. On-demand for the 2-month peak costs less than half the reserved price for that specific capacity.

The fix: Create a post-sale runbook that runs 48 hours after each major sale event. It should reset Auto Scaling group minimums to baseline, downsize RDS to off-peak instance type, and review ElastiCache node count. This 30-minute runbook saves $400–$900/month every January.

Implementing all five of the following optimizations typically recovers $440–$1,450/month on a $1,000–$3,000/month e-commerce cloud bill — without touching the customer-facing stack or reducing reliability (SpendArk analysis, 2025). These apply to WooCommerce, Magento, headless commerce (Next.js + Shopify/Contentful), and custom stacks on AWS or Azure. Ordered by effort-to-savings ratio — fastest wins first.

1. Improve CDN cache hit rate (savings: $80–$300/mo)

Most e-commerce teams deploy a CDN but never check cache hit rate. CloudFront shows this metric in the console under "Cache statistics." A hit rate below 70% means the CDN is forwarding most requests to your origin — you're paying for CDN infrastructure and still running origin servers at full load. Common causes: missing or overly short cache-control headers, query string variations that create unique cache keys, and cookie-based cache invalidation that passes every authenticated request to the origin.

Setting correct cache-control headers on static assets (images, JS, CSS) with long TTLs (1 year with content hashing), configuring CloudFront to ignore irrelevant query strings, and separating authenticated from unauthenticated caching policies typically raises cache hit rate from 55–65% to 85–92%. At 50 TB/month in CDN traffic, going from a 60% to a 90% hit rate reduces origin bandwidth by 15 TB — saving roughly $135/month in EC2 egress charges plus reduced origin instance requirements.

2. Compress and convert product images at the origin (savings: $60–$200/mo)

Product images are served millions of times. A JPEG product photo at 800×800 pixels averages 120–200 KB unoptimized. Converted to WebP with quality 80, the same image is 45–80 KB — a 55–65% reduction. Served 500,000 times per month, the unoptimized image costs $9.60 in S3 egress ($0.09/GB × 100 GB); the WebP version costs $3.84 at the same request volume. Across a catalog of 10,000 images each served hundreds of times, the monthly savings on storage egress alone is $50–$150.

Additionally, smaller images improve Time to First Byte and Core Web Vitals, which affects conversion rate. Tools: AWS Lambda@Edge or CloudFront Functions for on-the-fly image transformation, or build-time conversion via Sharp (Node.js) or Pillow (Python). Cloudflare Images ($5/month for 100,000 transformations) handles this entirely if you're not on a pure AWS stack.

3. Add application-layer caching for product data and sessions (savings: $100–$250/mo)

Product catalog data changes infrequently — prices, descriptions, and inventory levels update in batches, not per-request. Yet many WooCommerce and Magento setups hit the database for product data on every page render. Adding Redis (ElastiCache cache.r6g.large: ~$110/month) to cache product pages, search results, and session data can reduce RDS query load by 60–80% — which means you can right-size the database to a smaller instance class.

The math: if Redis caching lets you drop from an RDS db.r6g.2xlarge ($0.576/hr, ~$418/month) to a db.r6g.large ($0.288/hr, ~$209/month), you save $209/month on RDS while paying $110/month for ElastiCache — a net saving of $99/month with better read performance. Most e-commerce teams that add caching and right-size the database together save $150–$300/month net.

4. Right-size databases between seasons (savings: $150–$500/mo)

This is the single highest-dollar-value optimization for most e-commerce teams and the one most frequently skipped. Database instance sizing decisions made in October for Black Friday are rarely revisited in February. The process takes 15 minutes:

• Check average CPU utilization in AWS CloudWatch for the past 30 days (off-peak). If it's below 30%, you're one size class too large.
• Check average memory usage. RDS provides FreeableMemory as a metric. If FreeableMemory averages above 2 GB, you have unused memory headroom.
• Check DatabaseConnections. If peak connections are below 50% of your instance's connection limit, you can downsize.

Dropping one RDS instance class (e.g., db.r6g.2xlarge → db.r6g.xlarge) saves $209/month. Dropping two classes (db.r6g.2xlarge → db.r6g.large) saves $314/month. For a store that scaled to a db.r6g.4xlarge for Black Friday ($836/month), returning to a db.r6g.xlarge ($306/month) saves $530/month — in under 20 minutes of work, with a maintenance window of about 5 minutes for the instance resize.

5. Move batch jobs to spot instances (savings: $50–$200/mo)

E-commerce generates predictable batch workloads: nightly order processing reports, inventory sync jobs, email campaign generation, sales tax calculation batches, and review aggregation. These jobs run on a schedule, can tolerate interruption and retry, and typically don't need to complete within seconds. That's the exact profile spot instances are designed for.

AWS Spot instances save 70–90% over on-demand for the same instance type. A c6g.2xlarge at $0.272/hr on-demand costs $0.027–$0.055/hr on spot. Running batch jobs for 8 hours/night on a c6g.2xlarge costs $65/month on-demand, $8–$16/month on spot — a saving of $49–$57/month for a single batch job. Teams running multiple batch pipelines (recommendation model retraining, search index updates, catalog feed generation) recover $150–$200/month from this change alone. On Azure, use spot VMs or serverless Functions with consumption pricing for equivalent savings.

Reserved instances and AWS Savings Plans save 30–40% on 1-year commitments — but only when applied to stable, year-round baseline capacity. Applying them to seasonal peak capacity is the single most common reserved instance mistake in e-commerce (AWS Cost Optimization Hub data, 2024). E-commerce's variable traffic pattern makes the reserved vs on-demand decision more nuanced than for SaaS. For a deeper comparison of all three pricing models, see our guide on reserved vs spot vs on-demand instances. Here's a practical framework for e-commerce specifically:

Use reserved / Savings Plans for baseline capacity

Every e-commerce store has a floor — the minimum infrastructure that runs 24/7 regardless of traffic. For a $1,500/month store, that's typically:

• 2 web/application servers (always running for redundancy)
• 1 RDS primary instance (always running for writes)
• 1 ElastiCache node (session and cache layer)
• 1 NAT Gateway and load balancer

This baseline runs year-round. Cover it with a 1-year AWS Compute Savings Plan — which applies to any EC2 instance regardless of family or size — and save 30–37% on covered compute. On Azure, use Reserved VM Instances for the stable VM layer. The break-even for a no-upfront 1-year Savings Plan is immediate from month one.

Dollar example: If baseline compute costs $500/month on-demand, a Compute Savings Plan at the 1-year no-upfront rate reduces that to roughly $315–$350/month — saving $150–$185/month with zero architectural changes.

Use on-demand for seasonal ramp-up

The additional capacity you provision for Black Friday, Cyber Monday, summer sales, or product launches should be on-demand. You don't know exactly how many instances you'll need, you won't run them year-round, and on-demand gives you the flexibility to scale in as soon as the event ends. Committing to reserved capacity for seasonal spikes means paying for it in the off-season — the exact mistake described in the Black Friday section above.

Use spot for batch and background workloads

Order processing exports, search index rebuilds, recommendation model training, catalog feed generation, and email list processing are all interruptible. Move these to AWS Spot or Azure Spot VMs and save 70–90% on that compute. Use SQS or Azure Service Bus as a queue so jobs can be retried automatically if a spot instance is interrupted. Managed spot-aware services like AWS Batch or ECS with Spot capacity providers handle the retry logic for you.

RDS reserved instances: use with care

Unlike EC2 Savings Plans, RDS Reserved Instances are locked to a specific instance class and region. Reserving a db.r6g.2xlarge for a year and then downsizing to a db.r6g.xlarge 3 months later means paying for capacity you no longer use. The safer approach for e-commerce databases: reserve the off-peak instance size (what you run in January–September), and scale up to on-demand for the peak season. You pay on-demand rates for 2–3 months of peak while saving 40% for the other 9–10 months.