Make your app fast: cache hot data in memory with ElastiCache (Redis), and serve files and pages from edge locations near your users with the CloudFront CDN — including cache policies and invalidations.
Both services speed things up by avoiding repeated work, at different layers. ElastiCache caches DATA in memory so your app skips slow database hits. CloudFront caches CONTENT at edge locations worldwide so users download from nearby. Why together: one cuts backend load, the other cuts distance/latency.
echo "ElastiCache = in-memory data cache (Redis / Memcached), inside your VPC"echo "CloudFront = global content delivery network at the edge"ElastiCache runs managed Redis or Memcached — extremely fast in-memory stores. Why: reading a value from memory takes microseconds vs milliseconds from a database, so caching frequent reads (sessions, leaderboards, computed results) slashes latency and database load.
Create a small single-node Redis cluster (lives in your private subnets)
aws elasticache create-cache-cluster \
--cache-cluster-id my-redis \
--engine redis \
--cache-node-type cache.t3.micro \
--num-cache-nodes 1Get the endpoint your app connects to
aws elasticache describe-cache-clusters --cache-cluster-id my-redis \
--show-cache-node-info \
--query 'CacheClusters[0].CacheNodes[0].Endpoint'The common way apps use a cache: look in the cache first; on a miss, read the database and store the result in the cache for next time. Why: subsequent reads are served from memory until the entry expires (its TTL). This is logic in your app — these are the Redis commands it would run.
Connect with redis-cli (from a server in the VPC)
redis-cli -h my-redis.abc.cache.amazonaws.comInside redis-cli — cache a value for 300 seconds, then read it back
SET user:100 "Alice" EX 300GET user:100TTL user:100CloudFront copies your content to "edge locations" around the world and serves each user from the closest one. Why: a user in Tokyo gets files from a Tokyo edge instead of your bucket in Virginia — far faster, and it shields your origin from load. The origin is usually an S3 bucket or a load balancer.
Create a distribution in front of an S3 bucket (the "origin")
aws cloudfront create-distribution \
--origin-domain-name my-site-bucket-7f3k.s3.amazonaws.comThe output includes a *.cloudfront.net domain — point your DNS (Route 53 alias) at that to serve your site through the CDN over HTTPS.
A cache policy controls how long CloudFront keeps a copy (the TTL) and which parts of a request (query strings, headers, cookies) make a response "different." Why: cache static assets aggressively for speed, but tell CloudFront not to cache personalized or query-dependent responses incorrectly.
List the AWS-managed cache policies (good starting points)
aws cloudfront list-cache-policies --type managed \
--query 'CachePolicyList.Items[].CachePolicy.CachePolicyConfig.Name'"CachingOptimized" caches static content; "CachingDisabled" for dynamic.
Because CloudFront holds copies, a freshly deployed file can still serve the old version until its TTL expires. An invalidation tells CloudFront to drop cached copies now. Why: you run one after every deploy so users get the new build immediately. Note: the first 1,000 paths per month are free.
Invalidate everything after a deploy (or list specific paths)
aws cloudfront create-invalidation \
--distribution-id E1234567890ABC \
--paths "/*"More surgical: only the changed files
aws cloudfront create-invalidation --distribution-id E1234567890ABC \
--paths "/index.html" "/assets/app.js"