CloudFront Cache Behaviors, TTL आणि Invalidation Step by Step

By Ravindra Bagale, trainer LinkedIn Last updated: 22 October 2026

CloudFront Origins सोप्या भाषेत मध्ये /static/* S3 कडे आणि बाकी ALB कडे पाठवलं. ते करणारा rule म्हणजे cache behavior. हा chapter सखोल: path patterns आणि त्यांचा order, TTLs, Cache-Control headers, cache policies vs origin request policies, cache key, आणि invalidations किंवा versioned names ने files update करणं.

या chapter मध्ये तुम्ही काय शिकाल

Cache behaviors, path patterns आणि order
Cache-Control सह minimum, default आणि maximum TTL
Cache policy vs origin request policy
Cache key: query strings, cookies, headers
Invalidation vs versioned file names

1. गोष्ट: जुनी price list

एक दुकान price list छापतं आणि 20 branch counters ना copies देतं. पुढच्या आठवड्यात prices बदलतात. Head office कडे नवीन list आहे, पण कोणी सांगेपर्यंत branches जुन्या copies च देत राहतात.

CloudFront edges म्हणजे त्या branches. TTL म्हणजे प्रत्येक branch copy किती काळ ठेवते. Invalidation म्हणजे "फेकून द्या" सांगणारा phone call.

2. Cache behaviors आणि path patterns

हे का लागतं?

Images वर्षभर cache होऊ शकतात; login API कधीच cache होऊ नये. एका distribution ला वेगवेगळ्या paths साठी वेगळे rules हवेत.

हे काय आहे?

Cache behavior = path pattern + origin + settings (viewer protocol, allowed methods, cache policy, origin request policy, functions, signed URL गरज). CloudFront behaviors वरून खाली तपासतो आणि पहिला match वापरतो. Default (*) behavior नेहमी शेवटी आणि बाकी सगळं पकडतो.

Order	Path pattern	Origin	Cache
0	/api/*	ALB	CachingDisabled
1	/static/*	S3	1 वर्ष (versioned files)
2	*.jpg	S3	1 दिवस
3	/images/private/*	S3	Signed URL लागतो
Default	*	ALB	कमी, उदा. HTML साठी 60 s

Trap: /images/private/photo.jpg हा /images/private/* (order 3) च्या आधी *.jpg (order 2) ला match होतो, म्हणून private rule कधीच चालत नाही. Specific patterns general च्या वर ठेवा. Patterns case sensitive; * कितीही characters आणि ? नेमका एक.

3. TTL आणि Cache-Control

हे का लागतं?

खूप कमी तर origin वर load. खूप जास्त तर users ना जुन्या files.

हे काय आहे?

Origin Cache-Control: max-age=600 (किंवा फक्त shared caches साठी s-maxage) पाठवू शकतो. Cache policy मधले तीन TTLs त्याला चौकट देतात:

TTL	अर्थ	CachingOptimized value
Minimum	Origin कमी म्हणाला तरी किमान इतका cache	1 s
Default	Origin Cache-Control किंवा Expires पाठवत नाही तेव्हा	86,400 s (1 day)
Maximum	Origin जास्त म्हणाला तरी याहून जास्त नाही	31,536,000 s (1 year)

Origin पाठवतो	Min 0, Default 86400, Max 3600	Edge किती ठेवतो
max-age=600	-	600 s
काही नाही	-	3600 s (default, max ने मर्यादित)
max-age=86400	-	3600 s (max ने मर्यादित)
no-cache / no-store / private	Min 0	Cache नाही

Stack	Cache-Control पाठवा
S3 upload	`aws s3 cp app.3f9a.js s3://b/static/ --cache-control "public,max-age=31536000,immutable"`
Node/Express	`express.static("public",{maxAge:"1y",immutable:true})`
Flask	`resp.headers["Cache-Control"]="public, max-age=600"`
PHP	`header("Cache-Control: public, max-age=600");`
Spring	`ResponseEntity.ok().cacheControl(CacheControl.maxAge(10, TimeUnit.MINUTES))`
.NET	`[ResponseCache(Duration = 600)]`
nginx	`location /static/ { add_header Cache-Control "public, max-age=31536000, immutable"; }`
Apache	`Header set Cache-Control "max-age=600, public"`

4. Cache policy vs origin request policy

हे का लागतं?

App ला चालायला cookie लागू शकते, पण प्रत्येक cookie value cache key चा भाग झाली तर प्रत्येक user ची वेगळी copy आणि hit rate शून्य.

हे काय आहे?

मुद्दा	Cache policy	Origin request policy
काय ठरवते	TTLs + cache key (दोन requests "same" कधी)	Miss वर origin ला पाठवल्या जाणाऱ्या extra values
Hit rate वर परिणाम	हो	नाही
Managed examples	CachingOptimized, CachingDisabled, UseOriginCacheControlHeaders	AllViewer, CORS-S3Origin, AllViewerExceptHostHeader
नियम	Cache key मधल्या values origin ला पण जातात	Origin ला लागतं पण caching ने ignore करावं ते

5. Cache key

हे का लागतं?

Cache key ठरवतो दोन requests एक cached copy share करतात का. मोठा key म्हणजे जास्त copies आणि जास्त misses.

हे काय आहे?

Default key = domain + URL path. Query strings, cookies आणि headers जोडू शकता. Response खरंच बदलतं तेच जोडा.

Request	Cache key मध्ये?	का
/products?page=2	Query string page: हो	दर page वेगळं content
/products?utm_source=fb	utm_*: नाही	Content same; cache फुटेल
Cookie: lang=mr	फक्त cookie lang	भाषेनुसार page वेगळं
Cookie: _ga=...	नाही	फक्त analytics
Accept-Encoding	Policy मध्ये Gzip/Brotli enable करून	Compressed आणि plain copies वेगळ्या

6. Invalidation vs versioned file names

हे का लागतं?

File बदलली. TTL संपेपर्यंत edges कडे जुनी copy. आत्ता update करायला मार्ग हवा.

हे काय आहे?

मुद्दा	Invalidation	Versioned names (app.3f9a.js)
कसं	प्रत्येक edge वरून paths काढायला सांगा	नवीन content = नवीन file name; HTML त्याकडे
खर्च	दर महिना पहिले 1,000 paths free, मग दर path $0.005; /* एक path म्हणून	Free
Speed	बहुतेक काही minutes मध्ये	लगेच: नवीन URL म्हणजे खात्रीने miss
Rollback	परत invalidate	HTML परत जुन्या name कडे
कशासाठी	index.html, emergency fixes	JS, CSS, images (Vite, webpack, Angular आपोआप करतात)

# invalidate one file, then wait for it
aws cloudfront create-invalidation --distribution-id E1ABCDEF2GHIJ --paths "/index.html"
aws cloudfront wait invalidation-completed --distribution-id E1ABCDEF2GHIJ --id I2J3K4L5M6N7O8

Ravindra Bagale's Tip

Common pattern: index.html ला कमी TTL (60 s) किंवा प्रत्येक deploy ला invalidate; प्रत्येक asset versioned आणि वर्षभर cached.

7. Lab: जुनी file, मग fix

कसं करायचं (step by step)

Private S3 origin आणि OAC असलेलं distribution वापरा (Amazon CloudFront म्हणजे काय चा lab), default behavior CachingOptimized.
echo "price v1" > price.txt; aws s3 cp price.txt s3://yourname-cf-lab/price.txt.
curl -s https://dXXXX.cloudfront.net/price.txt दोनदा. अपेक्षित: price v1; दुसऱ्यांदा X-Cache Hit (-I ने तपासा).
बदला: echo "price v2" > price.txt; aws s3 cp price.txt s3://yourname-cf-lab/price.txt.
curl -s https://dXXXX.cloudfront.net/price.txt. अपेक्षित: अजून price v1. का: edge copy 1-day default TTL पर्यंत राहते.
Invalidate: aws cloudfront create-invalidation --distribution-id EXXXX --paths "/price.txt". Output मधला Id लिहा.
aws cloudfront wait invalidation-completed --distribution-id EXXXX --id IXXXX. अपेक्षित: पूर्ण झाल्यावर output शिवाय परत येतं.
curl -sI https://dXXXX.cloudfront.net/price.txt | grep -i x-cache; curl -s https://dXXXX.cloudfront.net/price.txt. अपेक्षित: Miss, price v2.
आता versioned पद्धत: price.v3.txt --cache-control "public,max-age=31536000,immutable" सह upload करून fetch करा. अपेक्षित: लगेच नवीन content, invalidation नाही.
Cache key test: curl -sI "https://dXXXX.cloudfront.net/price.txt?x=1" | grep -i x-cache. अपेक्षित: Hit. का: CachingOptimized query strings ignore करतो, म्हणून ?x=1 same key.

Cleanup

Test objects delete; फक्त या lab साठी distribution बनवलं असेल तर disable करून delete.

8. Interview questions

प्र. Cache behaviors कोणत्या order ने तपासले जातात?

Precedence नुसार वरून खाली; पहिला match होणारा path pattern जिंकतो; Default (*) शेवटी.

प्र. Origin max-age=86400 पाठवतो पण max TTL 3600. किती cache?

3600 seconds. Max TTL मर्यादा घालतो.

प्र. Cache policy vs origin request policy?

Cache policy TTLs आणि cache key ठरवते; origin request policy cache key वर परिणाम न करता origin ला values पाठवते.

प्र. Hit ratio कमी का?

Cache key मध्ये बहुधा सगळ्या cookies, headers किंवा query strings. Response बदलतात तेवढेच ठेवा.

प्र. Invalidation की versioned file names?

Assets साठी versioned names (free, लगेच, सोपा rollback); index.html आणि emergencies साठी invalidation (दर महिना 1,000 free paths).

घरी करून बघा

फक्त "page" query string वर key करणारी custom cache policy बनवा आणि दोन pages test करा.
Default च्या वर CachingDisabled सह /api/* behavior जोडा आणि प्रत्येक वेळी Miss confirm करा.

थोडक्यात सांगायचं तर

Behaviors paths वरून खाली match; पहिला match जिंकतो.
Min/default/max TTL origin च्या Cache-Control ला चौकट देतात.
Cache policy = key + TTL; origin request policy = origin ला extra data.
High hit rate साठी cache key लहान ठेवा.
Assets version करा; फक्त index.html invalidate.

सराव Tasks

या scenario बद्दल

Zurich Insurance Partners हा झुरिच मधला विमा व्यवसाय आहे. Anna Müller त्यांचं IT व cloud काम पाहतात. त्यांचे पैसे CHF मध्ये मोजले जातात आणि AWS resources eu-central-2 Region मध्ये चालतात. खालच्या tasks मध्ये तुम्ही या lesson मध्ये शिकलेलं वापरून त्यांची खरी कामं करता. सगळी नावं, account IDs, IP addresses व numbers सरावासाठी काल्पनिक आहेत.

0 / 10

सोपं Distributions दाखवा

का: Distribution ID व domain नाव शोधा.

काय करायचं: सगळे CloudFront distributions दाखवा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

सोपं /16 मध्ये किती addresses?

का: VPC size ठरवायला ही संख्या लागते.

काय करायचं: Zurich Insurance Partners चा VPC 10.189.0.0/16. एकूण किती IP addresses?

कसं करायचं:

Task मधले numbers लिहून घ्या.
कागदावर step by step काढा.
Box मध्ये फक्त final उत्तर लिहा.
Check answer दाबा.

सोपं SSH चा port

का: Security group rules ला योग्य port हवा.

काय करायचं: SSH साठी security group ने कोणता TCP port उघडावा?

कसं करायचं:

Task मधले numbers लिहून घ्या.
कागदावर step by step काढा.
Box मध्ये फक्त final उत्तर लिहा.
Check answer दाबा.

मध्यम CloudFront cache साफ करा

का: Deploy नंतर invalidate करा म्हणजे visitors ना नव्या files लगेच मिळतात.

काय करायचं: Distribution E2QWRUHAPOMQZL वर सगळे paths (/*) invalidate करा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड Config file पासून distribution बनवा

का: पूर्ण config JSON मध्ये ठेवणं सोपं.

काय करायचं: dist.json पासून CloudFront distribution बनवा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड दोन paths invalidate करा

का: फक्त बदललेलं invalidate करणं स्वस्त व जलद.

काय करायचं: E2QWRUHAPOMQZL वर /index.html व /css/site.css invalidate करा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड CloudFront OAC साठी bucket policy

का: OAC मुळे फक्त तुमचा CloudFront distribution private bucket वाचतो.

काय करायचं: cloudfront.amazonaws.com ला zurichinsure-site/* वर s3:GetObject allow, फक्त aws:SourceArn = arn:aws:cloudfront::131130276334:distribution/E2QWRUHAPOMQZL असेल तेव्हा.

कसं करायचं:

{ "Version": "2012-10-17", "Statement": [ ... ] } ने सुरू करा.
प्रत्येक statement मध्ये Effect, Action व Resource लिहा.
Task ला लागेल तेवढंच द्या (least privilege).
Double quotes व commas नीट वापरा. Check answer दाबा.

अवघड Origin Access Control बनवा

का: OAC मुळे फक्त CloudFront तुमचा private S3 bucket वाचू शकतो.

काय करायचं: oac.json पासून origin access control बनवा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड CloudFront साठी free certificate मागा

का: CloudFront फक्त us-east-1 मधले ACM certificates वापरतो.

काय करायचं: zurichinsure.ch व www.zurichinsure.ch साठी DNS validation ने us-east-1 मध्ये certificate मागा.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड CloudFront signed URL बनवा

का: Signed URLs मुळे फक्त पैसे भरलेले users ठराविक वेळ video पाहू शकतात.

काय करायचं: https://d111.cloudfront.net/course/intro.mp4 ला key pair ID K2JCJMDEHXQW5F, private key private_key.pem ने sign करा, 2026-12-31 ला expire.

कसं करायचं:

Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
aws लिहा, मग service चं नाव, मग operation (action शब्द).
प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

सगळे सराव tasks Task Hub मध्ये पाहा →

उजळणी, तुलना आणि मुलाखत cards

हा lesson काही मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR हा lesson उघडतो.

उजळणी card: Cache behaviors आणि order. Behavior = path pattern + origin + cache settings. वरून खाली तपासले; पहिला match जिंकतो. Default (*) नेहमी शेवटी. Specific patterns general च्या वर. — उजळणी card: Cache behaviors आणि order · PNG download करा

उजळणी card: Min, default आणि max TTL. Origin Cache-Control max-age पाठवतो. Min आणि max TTL ती value मर्यादित करतात. Origin काही पाठवत नाही तेव्हा default TTL. CachingOptimized: 1 s, 1 day, 1 year. — उजळणी card: Min, default आणि max TTL · PNG download करा

उजळणी card: Invalidation vs versioned names. Invalidation प्रत्येक edge वरून paths काढतं. दर महिना पहिले 1,000 paths free, मग $0.005 प्रत्येकी. Versioned names (app.3f9a.js) ला invalidation नको. Deploy नंतर index.html invalidate. — उजळणी card: Invalidation vs versioned names · PNG download करा

तुलना: Cache policy vs Origin request policy. Cache policy: TTLs आणि cache key ठरवते. Origin request policy: Miss वर origin ला पाठवले जाणारे headers, cookies किंवा query strings जोडते. — तुलना: Cache policy vs Origin request policy · PNG download करा

तुलना: Invalidation vs Versioned file names. Invalidation: सगळ्या edges वरून paths काढायला सांगा. Versioned file names: प्रत्येक build ला नवीन file names. — तुलना: Invalidation vs Versioned file names · PNG download करा

मुलाखत card: CloudFront hit ratio कमी आहे. काय तपासता?. Cache key: जास्तीच्या cookies, headers किंवा query strings. TTLs आणि origin चे Cache-Control headers. Origin ला लागणाऱ्या values origin request policy मध्ये हलवा. — मुलाखत card: CloudFront hit ratio कमी आहे. काय तपासता? · PNG download करा

अजून cards: Ravi Sir's Cards.