Make your app fast: cache hot data in memory with Azure Cache for Redis, and serve content from edge locations near your users with Azure Front Door — including caching and purging after a deploy.
Both speed things up by avoiding repeated work, at different layers. Azure Cache for Redis caches DATA in memory so your app skips slow database hits. Front Door caches CONTENT at edge locations worldwide so users download from nearby. Why together: one cuts backend load, the other cuts distance and latency.
echo "Azure Cache for Redis = in-memory data cache, near your app"echo "Azure Front Door = global edge network (CDN + routing)"Azure Cache for Redis is a managed Redis — an extremely fast in-memory store. 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 Basic-tier cache (takes a few minutes to provision)
az redis create \
--resource-group learn-rg \
--name learn-redis-7f3k \
--location eastus \
--sku Basic --vm-size c0Get the host name your app connects to
az redis show --resource-group learn-rg --name learn-redis-7f3k \
--query '{host:hostName, sslPort:sslPort}'The common way apps use a cache: look in the cache first; on a miss, read the database and store the result for next time with an expiry (TTL). Why: subsequent reads are served from memory until the entry expires. This is logic in your app — these are the Redis commands it runs.
Connect with redis-cli over TLS using the access key
KEY=$(az redis list-keys --resource-group learn-rg \
--name learn-redis-7f3k --query primaryKey --output tsv)redis-cli -h learn-redis-7f3k.redis.cache.windows.net -p 6380 \
--tls -a $KEYInside redis-cli — cache a value for 300 seconds, then read it back
SET user:100 "Alice" EX 300GET user:100TTL user:100Front Door serves your content from edge locations around the world, routing each user to the closest healthy backend and caching static responses. Why: a user in Tokyo gets cached files from a Tokyo edge instead of your origin in the US — far faster, and it shields your origin from load and offers HTTPS.
Create a Front Door profile
az afd profile create --resource-group learn-rg \
--profile-name learn-fd --sku Standard_AzureFrontDoorCreate an endpoint (gives you a *.azurefd.net hostname)
az afd endpoint create --resource-group learn-rg \
--profile-name learn-fd --endpoint-name learn-siteAn "origin" is where Front Door fetches content when it is not cached — your storage website or load balancer. A route ties an endpoint to an origin group and sets caching. Why: cache static assets aggressively for speed, and let dynamic responses pass through.
Create an origin group, then add your storage website as the origin
az afd origin-group create --resource-group learn-rg \
--profile-name learn-fd --origin-group-name site-origins \
--probe-request-type GET --probe-protocol Https \
--probe-interval-in-seconds 60 --probe-path / \
--sample-size 4 --successful-samples-required 3 \
--additional-latency-in-milliseconds 50az afd origin create --resource-group learn-rg \
--profile-name learn-fd --origin-group-name site-origins \
--origin-name storage-site \
--host-name learnstore7f3k.z13.web.core.windows.net \
--origin-host-header learnstore7f3k.z13.web.core.windows.net \
--priority 1 --weight 1000 --enabled-state EnabledBecause Front Door holds cached copies, a freshly deployed file can keep serving the old version until it expires. A purge tells Front Door to drop cached copies now. Why: you run one after every deploy so users get the new build immediately.
Purge everything after a deploy (or list specific paths)
az afd endpoint purge --resource-group learn-rg \
--profile-name learn-fd --endpoint-name learn-site \
--content-paths '/*'