CloudFront: Edge-এ Caching

এই লেসন শেষে তুমি পারবে

• CDN আসলে কী করে, আর CloudFront কেন একটা site-কে দ্রুত আর চালাতে সস্তা করে, সেটা বোঝাতে: কম latency, origin-এর ওপর চাপ কম, দূরের handshake কম।
• CloudFront-এর স্তরগুলো (edge location, Regional Edge Cache, Origin Shield) বর্ণনা করতে, আর একটা request-কে cache miss, hit, আবার যাচাই আর origin বন্ধ থাকার অবস্থায় শুরু থেকে শেষ পর্যন্ত অনুসরণ করতে।
• ঠিক origin বাছতে (S3 bucket, S3 website endpoint, custom HTTP origin, VPC origin), আর Origin Access Control ও bucket policy দিয়ে S3 origin-কে private রাখতে।
• Cache behaviour দিয়ে কোন path কোন origin-এ যাবে ঠিক করতে, আর cache policy ও origin request policy দিয়ে cache key আর TTL সাজাতে।
• Origin group দিয়ে origin failover, us-east-1-এর ACM certificate দিয়ে HTTPS, আর logging চালু করতে।
• পরীক্ষার প্রশ্নের ভাষা দেখেই CloudFront, S3 Cross-Region Replication আর S3 Transfer Acceleration-এর মধ্যে ঠিকটা বেছে নিতে।

#ব্যবহারকারীর কাছে cache কেন

#দূরত্বের সমস্যা

Fibre-এর ভেতরে আলো মোটামুটি প্রতি millisecond-এ ২০০ km যায়, আর আসল cable কখনো সোজা পথে চলে না। ঢাকা থেকে North Virginia-র (us-east-1) একটা server-এ একটা packet গিয়ে ফিরে আসতে লাগে প্রায় ২৩০ ms। এটা মাত্র একটা round trip, অথচ একটা web page-এর লাগে অনেকগুলো:

• নতুন একটা HTTPS connection খুলতেই একটা round trip যায় TCP handshake-এ, আরেকটা TLS 1.3-এ (পুরোনো TLS-এ দুটো), তারপর আরেকটা request পাঠিয়ে উত্তর পেতে: প্রথম byte আসার আগেই প্রায় ৩টা round trip ≈ ৭০০ ms।
• একটা পণ্যের page কয়েক ডজন ছবি, script আর style sheet নামায়। Browser connection আবার ব্যবহার করে ঠিকই, কিন্তু প্রতিটা request-কে অন্তত একটা round trip অপেক্ষা করতেই হয়।
• Server যত দূরে, পথে তত বেশি packet হারায়, আর প্রতিবার হারালেই TCP থমকে যায়।

এর ওষুধ দ্রুততর server না; ওষুধ হলো কম দূরত্ব। ছবির একটা copy যদি ২০–৩০ ms দূরের কোনো data centre-এ থাকে, ওই একই তিনটা round trip ১০০ ms-এর কমে শেষ হয়।

#CloudFront জিনিসটা কী

Amazon CloudFront হলো AWS-এর content delivery network (CDN): সারা দুনিয়ায় ছড়ানো caching server-এর একটা network, যেটা তোমার ব্যবহারকারী (viewer) আর তোমার server (origin)-এর মাঝখানে বসে। এটা একটা global service: এর জন্য কোনো Region বাছতে হয় না, আর এর configuration প্রতিটা location-এ পৌঁছে দেওয়া হয়।

একটা site বা API-এর সামনে এটা বসালে যা পাও:

• কম latency। Viewer কাছের একটা location-এ connect করে; TLS-ও শেষ হয় সেখানেই, তার কাছাকাছি।
• Origin-এর ঘাড় থেকে চাপ নামে। জনপ্রিয় file cache থেকে যায়, ফলে origin-কে request-এর অল্প একটা অংশ সামলাতে হয়। ঈদের sale বা নির্বাচনের রাতে এটাই দ্রুত site আর বসে যাওয়া site-এর মধ্যে তফাত।
• যা cache হয় না, তার জন্যও দ্রুত পথ। যে request-কে origin-এ যেতেই হবে (একটা API call, checkout), সে লম্বা পথটা পেরোয় AWS backbone দিয়ে, CloudFront আগে থেকে খুলে রাখা connection-এ, public internet দিয়ে না।
• সুরক্ষা। সারা দুনিয়ায় ছড়িয়ে থাকায় CloudFront network-এর বন্যা শুষে নেয়; AWS Shield Standard বিনা পয়সায় সাথেই আসে, আর AWS WAF edge-এই request ছেঁকে নিতে পারে। এটা লেসন ১১.২-এ।
• সস্তায় পৌঁছানো। AWS origin (S3, ALB, EC2) থেকে CloudFront-এ data transfer বিনা পয়সায়, আর internet-এ পাঠানোর জন্য CloudFront-এর নিজের দাম S3-এর চেয়ে কম।

CloudFront শুধু static file-এর জন্য না। Dynamic content-ও (প্রতি request-এ বানানো HTML, API-এর উত্তর) দ্রুত হয়, ওই খুলে রাখা connection আর backbone-এর কারণে; WebSocket আর gRPC traffic-ও এর ভেতর দিয়ে চলে। যেটা সে করে না, সেটা হলো তোমার application চালানো: edge-এ compute বলতে শুধু ছোট ছোট function (লেসন ১১.৩)।

#CloudFront কীভাবে সাজানো

#Edge location আর Regional Edge Cache

তোমার origin-এর সামনে CloudFront-এর দুই স্তরের cache থাকে, চাইলে তৃতীয় একটা:

1. Edge location, যাকে point of presence (PoP)-ও বলে: ১০০-র বেশি শহর আর ৫০-এর বেশি দেশে ৭৫০-এর বেশি, তার ওপর internet provider-দের network-এর ভেতরে বসানো ১,১৪০-এর বেশি ছোট embedded PoP। DNS প্রত্যেক viewer-কে সেই PoP-এ পাঠায় যেটা তাকে সবচেয়ে ভালো সেবা দিতে পারবে, সাধারণত সবচেয়ে কম latency-র টায়। ঢাকার একজন viewer-এর জন্য সেটা সাধারণত পাশের কোনো দেশের PoP, যেমন Kolkata বা Singapore। PoP ছোট, তাই সবচেয়ে জনপ্রিয় object-গুলোই রাখে।
2. Regional Edge Cache: AWS Region-এ বসানো ১৫টা বড় cache, প্রতিটা অনেকগুলো PoP মিলে ব্যবহার করে। কোনো PoP-এ miss হলে সে origin-এ যাওয়ার আগে তার Regional Edge Cache-কে জিজ্ঞেস করে। এরা object অনেক বেশি দিন রাখে, তাই কম চাওয়া জিনিসগুলোর বেলায় কাজে আসে: আজ কেউ খোলেনি এমন পণ্যের ছবি, গত সপ্তাহের খবর, হঠাৎ আবার জনপ্রিয় হয়ে ওঠা একটা video।
3. Origin Shield (ঐচ্ছিক, আলাদা দাম): তুমি যে Region বাছো, তোমার origin-এর সবচেয়ে কাছে, সব Regional Edge Cache-এর সামনে আরও একটা cache স্তর। নিচে “Origin Shield: origin-এর সামনে একটা cache” দেখো।

Regional Edge Cache দিয়ে যাওয়ার নিয়মের তিনটা ব্যতিক্রম জেনে রাখো: PUT, POST, PATCH, OPTIONS আর DELETE PoP থেকে সোজা origin-এ যায়; request-এর মুহূর্তে CloudFront যেগুলোকে dynamic (cache করার মতো না) ধরে, সেগুলোও সোজা যায়; আর S3 origin যদি Regional Edge Cache-এর একই Region-এ থাকে, PoP ওই স্তর বাদ দিয়ে নিজেই S3-এর সাথে কথা বলে।

একটা ছবি এই স্তরগুলো পেরিয়ে কীভাবে যায় দেখো, TTL ফুরোলে কী হয় আর origin বন্ধ থাকলে কী হয় সেটাও:

#Distribution

Distribution হলো CloudFront-এর একটা configuration। একটা বানালেই CloudFront তাকে একটা domain name দেয়, যেমন d111111abcdef8.cloudfront.net। একটা distribution-এ থাকে:

• এক বা একাধিক origin (১০০টা পর্যন্ত), আর failover-এর জন্য ঐচ্ছিক origin group;
• cache behaviour: কোন path কোন origin-এ যাবে, আর কীভাবে cache হবে;
• সাধারণ setting: alternate domain name (তোমার নিজের নাম, যেমন shop.example.com, ১০০টা পর্যন্ত), TLS certificate, default root object, logging, price class (network-এর কোন অংশ ব্যবহার হবে, লেসন ১১.২), একটা AWS WAF web ACL, IPv6, HTTP/2 আর HTTP/3।

Site-টা নিজের নামে চালাতে নামটা alternate domain name হিসেবে যোগ করো, সেই নাম ঢাকে এমন certificate লাগাও, আর DNS-কে distribution-এর দিকে দেখাও: Route 53-এ distribution-এর দিকে একটা Alias record, যেটা zone apex-এও (example.com) চলে আর প্রতি query-তে কোনো খরচ নেই (লেসন ৮.২)। অন্য DNS-এ subdomain হলে d111111abcdef8.cloudfront.net-এর দিকে একটা CNAME।

Distribution-এ কিছু বদলালে সেটা প্রতিটা location-এ পৌঁছাতে কয়েক মিনিট লাগে, তখন status দেখায় “Deploying”।

#Origin

Origin হলো সেই জায়গা, CloudFront-এর কাছে যা নেই সেটা সে যেখান থেকে আনে। যেগুলোর সাথে তোমার দেখা হবে:

প্রতিটা origin-এর জন্য আরও ঠিক করো: ঐচ্ছিক origin path (bucket-এর ভেতরের /production থেকে আনো), প্রতিটা origin request-এ যোগ করার মতো custom header, আর custom origin-এর বেলায় origin protocol policy (শুধু HTTP, শুধু HTTPS, বা viewer যা ব্যবহার করে) আর port। ধীর বা মরা origin-এর সাথে CloudFront কেমন আচরণ করবে, তা ঠিক করে তিনটা timer: connection timeout (default ১০ s, ১–১০), connection attempts (default ৩, ১–৩) আর response timeout (default ৩০ s, ১–১২০)। Default-এ রাখলে একটা মরা origin কিছু ঘটার আগে viewer-কে প্রায় ৩০ সেকেন্ড বসিয়ে রাখতে পারে।

#Cache behaviour: কোন path কোথায় যাবে

Cache behaviour হলো একটা নিয়ম, যেটা একটা path pattern মেলায় আর বলে দেয় মিলে যাওয়া request-এর সাথে কী করতে হবে। একটা distribution-এ এমন নিয়মের একটা list থাকে (৭৫টা পর্যন্ত), যেগুলো precedence-এর ক্রমে মেলানো হয়; প্রথম যেটা মেলে সেটাই খাটে। সবশেষেরটা সবসময় default behaviour, *, যেটা বাকি সব ধরে আর মোছা যায় না।

প্রতিটা behaviour-এ ঠিক করা থাকে:

• কোন origin (বা origin group) ব্যবহার হবে;
• viewer protocol policy: HTTP আর HTTPS দুটোই চলবে, HTTP-কে HTTPS-এ redirect করবে, নাকি শুধু HTTPS;
• allowed method: GET আর HEAD; GET, HEAD আর OPTIONS; বা সাতটাই (সাথে PUT, POST, PATCH আর DELETE); আর OPTIONS-এর উত্তর cache হবে কি না;
• cache policy (cache key আর TTL) আর origin request policy (কী কী পাঠানো হবে), নিচে বিস্তারিত; সাথে ঐচ্ছিক একটা response headers policy (security header, CORS header);
• edge function, signed URL বা cookie, field-level encryption আর compression।

Path pattern বড়-ছোট হাতের অক্ষর আলাদা ধরে, আর * (যেকোনো অক্ষর) ও ? (একটা অক্ষর) বোঝে: /images/*, /api/*, *.mp4।

#S3 origin-কে private রাখা: Origin Access Control

CloudFront-এর পেছনের bucket যদি public হতো, যে কেউ CloudFront এড়িয়ে সোজা S3 থেকে নামিয়ে নিতে পারত: WAF নেই, geo restriction নেই, signed URL নেই, edge-এর log নেই, আর প্রতিটা byte-এর জন্য S3-এর পুরো বিল। Origin Access Control (OAC) সেই দরজা বন্ধ করে:

• Bucket-এ পাঠানো প্রতিটা request CloudFront sign করে AWS Signature Version 4 দিয়ে, CloudFront service হিসেবে, আর জানিয়ে দেয় কোন distribution request করছে। AWS-এর সুপারিশ করা setting-এ (“Sign requests”) S3-এর সাথে connection সবসময় HTTPS।
• Bucket-এ Block Public Access চালু থাকে। তার bucket policy service principal cloudfront.amazonaws.com-কে অনুমতি দেয়, কিন্তু শুধু তোমার distribution-এর হয়ে আসা request-এর জন্য, AWS:SourceArn condition দিয়ে।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::bazaarbari-images-example/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

বাস্তব setup-এ আর পরীক্ষার প্রশ্নে তিনটা খুঁটিনাটি বারবার আসে:

• নিরাপত্তা আসলে ওই condition-এ। এটা না থাকলে যেকোনো account-এর যেকোনো CloudFront distribution, এমনকি কোনো আক্রমণকারীর বানানোটাও, bucket পড়তে পারত।
• SSE-KMS। Object যদি নিজের বানানো KMS key দিয়ে encrypt করা থাকে, তাহলে key policy-কেও cloudfront.amazonaws.com-কে kms:Decrypt-এর অনুমতি দিতে হবে (একই AWS:SourceArn শর্তে), নইলে viewer পাবে 403 (লেসন ১০.৮)।
• Upload। CloudFront দিয়ে PUT নিতে হলে behaviour-কে সব method-এর অনুমতি দিতে হবে, আর bucket policy-তে distribution-এর জন্য s3:PutObject-ও লাগবে। OAC এই dynamic request-গুলো সামলাতে পারে।

OAC-এর জন্য bucket-এর Object Ownership হতে হবে “bucket owner enforced” (নতুন bucket-এ এটাই default), আর website endpoint origin-এর সাথে এটা চলে না: anonymous HTTP endpoint-এ sign করার মতো কিছুই নেই।

#পুরোনো উপায়: origin access identity

২০২২-এর আগে একই কাজ করত origin access identity (OAI): CloudFront-এর একটা বিশেষ user, যাকে bucket policy principal হিসেবে লেখে (arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity …)। পুরোনো Region-এর SSE-S3 bucket পড়তে এটা এখনো চলে, কিন্তু SSE-KMS সামলাতে পারে না, সব রকম upload সামলায় না, আর ডিসেম্বর ২০২২-এর পরে চালু হওয়া S3 Region-এ চলে না। AWS এখন OAI-কে legacy বলে, আর OAC ব্যবহার করতে বলে। পুরোনো exam প্রশ্নে আর কয়েক বছর আগের slide-এ OAI লেখা থাকে; দুটোকেই পড়ো একই অর্থে: “CloudFront private bucket পড়তে পারে, আর কেউ পারে না”।

Outage ছাড়া বদলাতে: bucket policy-তে OAI-এর statement-এর পাশে distribution (OAC)-এর জন্য একটা statement যোগ করো, origin-কে OAC-তে বদলাও, deployment শেষ হওয়া পর্যন্ত অপেক্ষা করো, তারপর OAI-এর statement মুছে দাও।

#Cache key: দুটো request কখন একই

#Key-তে কী থাকে

Cache key হলো সেই মানগুলোর set, যা দেখে CloudFront ঠিক করে একটা request cache-এ আগে থেকে থাকা কোনো কিছুর সাথে মেলে কি না। Default-এ এটা distribution-এর domain name আর URL-এর path। Cache policy দিয়ে এতে যোগ করা যায়:

• query string: কোনোটাই না, সবগুলো, একটা allow list, বা একটা deny list বাদে সব;
• header: কোনোটাই না, বা একটা list (যেমন CloudFront-Viewer-Country, বা normalised Accept-Encoding, যেটা compression চালু থাকলে CloudFront নিজেই যোগ করে, যাতে gzip আর Brotli copy আলাদা cache হয়);
• cookie: কোনোটাই না, সবগুলো, একটা allow list, বা একটা deny list বাদে সব।

যে নিয়মে সবকিছু ঠিক হয়: cache key-তে রাখো ঠিক সেই মানগুলো, যেগুলো response বদলায়, এর বেশি কিছু না।

• যেটা response বদলায় সেটা বাদ দিলে (ছবির মাপ বদলানো server-এর size query string), viewer ভুল copy পায়: zoom page-এ ছোট thumbnail।
• যেটা response বদলায় না সেটা রাখলে (fbclid tracking parameter, পুরো User-Agent, ছবির ওপর session cookie), প্রতিটা ভিন্নতা আলাদা একটা cache করা copy হয়ে যায়। Hit ratio ধসে পড়ে, চাপটা যায় origin-এর ঘাড়ে, আর বিলটা দাও তুমি।

#Cache policy আর origin request policy

প্রতিটা behaviour-এ দুটো আলাদা policy লাগানো থাকে, আর এদের তফাতটা একটা চেনা প্রশ্ন:

CloudFront-এর পেছনের একটা dynamic API সাধারণত CachingDisabled + AllViewer (বা AllViewerExceptHostHeader): কিছুই cache হয় না, আর origin প্রতিটা header, cookie আর query string দেখতে পায়। S3-এর static file সাধারণত CachingOptimized, কোনো origin request policy ছাড়া, বা browser অন্য origin থেকে চাইলে CORS-S3Origin। পুরোনো distribution-এ policy-র বদলে behaviour-এর ভেতরেই “legacy cache settings” থাকে; policy এসে সেগুলোর জায়গা নিয়েছে।

#TTL: একটা copy কতক্ষণ বাঁচে

#Minimum, default আর maximum TTL

TTL (time to live) হলো কতক্ষণ CloudFront একটা copy রাখবে, তারপর আবার origin-এর সাথে মিলিয়ে নিতে হবে। Cache policy-তে তিনটা সংখ্যা থাকে, আর origin-এর নিজের header ঠিক করে দেয় TTL ওই সীমার কোথায় পড়বে:

শেষ সারিটা একটা ফাঁদ: AWS-এর বানানো CachingOptimized policy-র minimum TTL ১ সেকেন্ড, তাই origin-এর no-store উপেক্ষা করে response এক সেকেন্ড cache থাকে। যে response কখনোই cache হওয়া চলবে না, তার জন্য minimum TTL 0 এমন policy নাও, যেমন CachingDisabled বা UseOriginCacheControlHeaders।

আরও দুটো কথা: request-এ viewer নিজে Cache-Control: no-cache পাঠালে সেটা উপেক্ষা করা হয় (user জোর করে CloudFront-কে origin-এ পাঠাতে পারে না), আর TTL হলো সর্বোচ্চ সময়, প্রতিশ্রুতি না: কেউ চায় না এমন object জায়গা খালি করার জন্য আগেই সরিয়ে ফেলা হতে পারে।

#Hit, miss, আবার যাচাই, আর বাসি copy দেওয়া

CloudFront-এর প্রতিটা উত্তরে এমন header থাকে, যা দেখে বোঝা যায় কী ঘটেছে:

• x-cache: Hit from cloudfront: edge-এর cache থেকে দেওয়া।
• x-cache: Miss from cloudfront: Regional Edge Cache বা origin থেকে আনা (যে request কখনো cache হয় না, সেখানেও এটাই দেখায়)।
• x-cache: RefreshHit from cloudfront: copy-র মেয়াদ শেষ হয়ে গিয়েছিল; CloudFront শর্তসাপেক্ষ request দিয়ে origin-কে জিজ্ঞেস করল (ETag সহ If-None-Match, বা If-Modified-Since), origin বলল 304 Not Modified, আর cache-এর copy-টাই দেওয়া হলো, নতুন মেয়াদ সহ। সস্তা: সমুদ্র পেরিয়ে কোনো body আসে না।
• x-cache: Error from cloudfront: একটা error, origin থেকে বা CloudFront নিজে।
• age: copy আনার পর কত সেকেন্ড গেছে। x-amz-cf-pop: কোন PoP উত্তর দিল (SIN2-P1-এর মতো একটা code)। x-amz-cf-id: support আর log-এর জন্য request-এর ID।

Origin-এ পৌঁছানো যাচ্ছে না আর copy-র মেয়াদও শেষ, এমন অবস্থায় origin যদি Cache-Control: stale-if-error=N পাঠিয়ে থাকে (বা minimum TTL 0-এর বেশি হয়), CloudFront error-এর বদলে বাসি copy-টা দিতে পারে। stale-while-revalidate=N আরও এক ধাপ এগোয়: মেয়াদ শেষে CloudFront সঙ্গে সঙ্গে পুরোনো copy দেয়, আর পেছনে পেছনে নতুনটা আনে। Origin-এর error-ও (4xx আর 5xx) cache হয়, default-এ ১০ সেকেন্ড, যাতে বিপদে পড়া origin-এর ওপর request-এর ঢল না নামে; custom error response দিয়ে status code ধরে এটা বদলানো যায় (লেসন ১১.২)।

#CloudFront যা cache করে না

• PUT, POST, PATCH আর DELETE-এর উত্তর কখনো cache হয় না; CloudFront শুধু সেগুলো পৌঁছে দেয়। GET আর HEAD-এর উত্তর cache হয়; OPTIONS-এর উত্তর শুধু তুমি চাইলে।
• যেখানে TTL 0 খাটে: CachingDisabled, বা minimum TTL 0 থাকা অবস্থায় origin-এর no-store।
• একটা GET response-এ ৫০ GB-র চেয়ে বড় file।

এবার নিজে চেষ্টা করো। Cache key আর TTL বদলাও, আর দেখো hit ratio আর origin-এর কী হয়:

#Origin বিপদে পড়লে: origin group

#Origin failover

একটা origin group-এ দুটো origin থাকে: একটা primary, একটা secondary। যে behaviour group-এর দিকে দেখায়, সে প্রতিটা cache miss পাঠায় primary-তে। Primary যদি তোমার বাছা কোনো status code ফেরত দেয় (400, 403, 404, 416, 429, 500, 502, 503, 504-এর যেকোনোটা), বা তার সাথে connect করাই না যায় (503 হিসেবে গোনা হয়), বা সময় পেরিয়ে যায় (504 হিসেবে গোনা হয়), CloudFront একই request secondary-কে পাঠায় আর তার উত্তরটা ফেরত দেয়।

যা জানতে হবে:

• এটা চলে প্রতি request ধরে, কোনো health check নেই, কোনো স্মৃতিও নেই: পরের miss আবার primary-তেই যায়। Primary-র connection timeout আর attempts কমাও, নইলে প্রতিটা miss failover-এর আগে ৩০ সেকেন্ড পর্যন্ত বসে থাকবে।
• এটা খাটে শুধু GET, HEAD আর OPTIONS-এ। Upload আর অন্য লেখার request-এ failover হয় না।
• সাধারণ জুটি হলো একটা bucket আর অন্য Region-এ তার Cross-Region Replication copy (লেসন ১০.৪), বা দুই Region-এ দুটো load balancer। একটা distribution-এ ১০টা পর্যন্ত origin group।

পুরো একটা application-কে অন্য Region-এ সরাতে হলে origin group তার একটা টুকরো মাত্র: Route 53 health check দিয়ে DNS failover (লেসন ৮.৩ আর ৮.৪) বা Global Accelerator (লেসন ১১.৪) সব traffic সরায়, লেখার request-সহ।

#Origin Shield: origin-এর সামনে একটা cache

প্রতিটা Regional Edge Cache miss হলে আলাদা আলাদা করে origin-এ যায়। এমন ১৫টা থাকায় জনপ্রিয় একটা নতুন object অনেকবার origin-এ পৌঁছাতে পারে, আর কিছু origin এটা একদম সহ্য করতে পারে না: live video-র packager, তাৎক্ষণিক ছবির মাপ বদলানো server, সরু link-ওয়ালা তোমার নিজের data centre-এর server। Origin Shield তোমার বাছা Region-এ, origin-এর সবচেয়ে কাছেরটায়, আরও একটা cache বসায়। সব Regional Edge Cache তখন এর ভেতর দিয়ে যায়, আর একই object-এর একসাথে আসা request-গুলোকে এটা জুড়ে একটা origin request বানায়।

• লাভ: মোট hit ratio বাড়ে, origin-এর চাপ অনেক কমে, আর traffic তোমার origin পর্যন্ত পুরোটা CloudFront network-এই থাকে।
• খরচ: যে request বাড়তি স্তর হিসেবে Origin Shield পেরোয়, তার প্রতিটার জন্য একটা charge (একই Region-এর Regional Edge Cache থেকে আসা request-এ charge নেই)।
• এটা origin-এর একটা setting; AWS-এর ভেতরে বা বাইরে, যেকোনো origin-এ চলে, origin group-এর সাথে চলে, আর এমন multi-CDN setup-এও, যেখানে অন্য CDN CloudFront থেকে টানে।
• যে content cache হয় না বা কালেভদ্রে চাওয়া হয়, তার জন্য এর দাম ওঠে না।

#CloudFront-এ HTTPS

সুরক্ষিত করতে হয় দুটো connection: viewer → CloudFront আর CloudFront → origin।

• Viewer protocol policy (প্রতিটা behaviour-এ): HTTP and HTTPS, Redirect HTTP to HTTPS (CloudFront https ঠিকানা দিয়ে 301 দেয়, website-এর জন্য সাধারণত এটাই), বা HTTPS only (HTTP request পায় 403, API-তে এটা প্রায়ই দেখা যায়)।
• Origin protocol policy (custom origin-এ): HTTP only, HTTPS only বা Match viewer। HTTPS হলে origin-এর certificate বৈধ হতে হবে আর origin-এর domain name-এর সাথে মিলতে হবে, নইলে CloudFront দেয় 502 Bad Gateway। OAC সহ S3 REST origin সবসময় HTTPS; website endpoint সবসময় HTTP।
• নিজের domain-এর জন্য distribution-এ certificate লাগে। Default *.cloudfront.net নামের certificate আগেই আছে। shop.example.com-এর জন্য AWS Certificate Manager (ACM)-এ বিনা পয়সার একটা public certificate নাও, us-east-1 (N. Virginia)-এ, তোমার origin যে Region-এই থাকুক। অন্য Region-এ নেওয়া certificate CloudFront console-এ দেখাই যায় না। (ALB origin হলে ALB-এর নিজের certificate থাকে ALB-এর Region-এই, লেসন ৬.৪।) প্রতিটা alternate domain name-কে certificate-এর ঢাকতে হবে।
• SNI নাকি dedicated IP। CloudFront default-এ SNI (Server Name Indication) ব্যবহার করে: TLS handshake-এর সময় browser বলে দেয় সে কোন host name চায়, তাই edge-এর একই address-গুলো অনেক certificate দিতে পারে। এটা বিনা পয়সায়, আর এখনকার সব browser এটা বোঝে। SNI বোঝে না এমন খুব পুরোনো client-এর জন্য আছে dedicated IP, প্রতি certificate-এ মাসে প্রায় $৬০০। সাথে একটা security policy বাছতে হয়, যেটা viewer-এর জন্য সবচেয়ে নিচের TLS version ঠিক করে।

Certificate us-east-1-এ থাকার কারণ আর Lambda@Edge function সেখানে বানানোর কারণ একই (লেসন ১১.৩): CloudFront global, আর তার control plane ওই Region ব্যবহার করে।

#Log আর নজরদারি

CloudFront প্রতিটা request লিখে রাখতে পারে। Standard log (access log) কয়েক মিনিটের মধ্যে দলে দলে পৌঁছায় S3, CloudWatch Logs বা Amazon Data Firehose-এ; logging নিজে বিনা পয়সায়, দাম দাও শুধু যেখানে জমা রাখো তার। প্রতিটা লাইনে থাকে সময়, PoP, client IP, URL, status, byte, কত সময় লাগল আর ফলের ধরন (Hit, Miss, RefreshHit, Error, OriginShieldHit…)। Real-time log কয়েক সেকেন্ডের মধ্যে যায় একটা Kinesis data stream-এ, তুমি যে field আর sampling rate বাছো সেভাবে, প্রতি লাখ log লাইনের হিসাবে দাম; live dashboard আর alarm-এর জন্য এটা। CloudFront CloudWatch metric-ও দেয় (request, byte, 4xx আর 5xx error rate, আর টাকা দিলে cache hit rate আর origin latency), আর AWS CloudTrail configuration-এর বদল লিখে রাখে।

#খরচ কত

Pay-as-you-go CloudFront-এর দাম ধরা হয় viewer-এর কাছে data transfer out-এর জন্য (প্রতি GB, যত বেশি তত সস্তা, মহাদেশ ভেদে আলাদা), HTTP আর HTTPS request-এর জন্য (প্রতি ১০,০০০-এ), আর বাড়তি কিছুর জন্য: মাসে বিনা পয়সার ১,০০০ path-এর পরে invalidation, Origin Shield, real-time log, edge function, dedicated IP certificate। চিরকালের free tier-এ প্রতি মাসে ১ TB transfer out আর ১ কোটি request ধরা আছে। AWS origin থেকে CloudFront-এ transfer বিনা পয়সায়, তাই S3 থেকে CloudFront দিয়ে চালানো ভিড়ের site সাধারণত সোজা S3 থেকে চালানোর চেয়ে সস্তা। Price class, যেটা টাকা বাঁচাতে দুনিয়ার সবচেয়ে দামি অংশগুলো বাদ দেয়, সেটা লেসন ১১.২-এ।

#CloudFront বনাম S3 Cross-Region Replication

দুটোই bucket থেকে দূরের ব্যবহারকারীর কাছে data নেওয়ার উপায়, আর পরীক্ষা এদের পাশাপাশি দাঁড় করাতে ভালোবাসে। অথচ এদের কাজের ধরন একেবারে আলাদা।

Notes আরও একটা জুটি যোগ করে, আর সেটায় একটা সংশোধন লাগে: “দূরের কর্মীদের bucket-এ কম latency-তে upload দরকার” প্রশ্নে CRR কাজে আসে শুধু যদি প্রতিটা অফিস নিজের Region-এর bucket-এ লেখে। সবাইকে যখন একটাই bucket-এ upload করতে হবে, সাধারণ উত্তর S3 Transfer Acceleration (লেসন ১০.৬), যেটা কাছের একটা edge location-এ AWS network-এ ঢোকে। CloudFront distribution দিয়ে PUT করে upload-ও একই ধারণায় চলে, কাজও করে, কিন্তু upload নিয়ে পরীক্ষার প্রশ্ন এটা চায় না।

#কোথায় গোলমাল হয়

• S3 origin থেকে 403। Bucket policy নেই বা ভুল (AWS:SourceArn নেই, ভুল distribution ID), key-টাই নেই (CloudFront bucket list করতে না পারলে S3 404-এর বদলে 403 বলে), /-এর জন্য default root object নেই, বা SSE-KMS আছে কিন্তু key policy-তে statement নেই।
• হালনাগাদের পরেও user পুরোনো file দেখছে। Copy-টা এখনো TTL-এর ভেতরে। Path-টা invalidate করো, বা আরও ভালো, file name-এ version দাও (লেসন ১১.২)। Response-এ age দেখো।
• Hit ratio কম। Cache key-তে বেশি জিনিস: সব query string, সব cookie, User-Agent। Standard log-এ URL-গুলো দেখো।
• একজন user আরেকজনের data দেখছে। ব্যক্তিগত একটা response এমন key দিয়ে cache হয়েছে যাতে session নেই: এমন path-এ CachingDisabled দাও, বা key-তে ঠিক মানটা রাখো।
• 502 Bad Gateway। Custom origin-এর সাথে CloudFront TLS শেষ করতে পারেনি (certificate-এর মেয়াদ শেষ, self-signed, বা origin domain name-এর সাথে মেলে না), বা origin connection কেটে দিয়েছে।
• 504 Gateway Timeout। Origin সময়মতো উত্তর দেয়নি: কোনো security group বা network ACL CloudFront-কে আটকাচ্ছে, server-এর ওপর চাপ বেশি, বা response timeout-এর চেয়ে ধীরে উত্তর আসছে।
• Console-এ certificate দেখা যাচ্ছে না। সেটা us-east-1 ছাড়া অন্য Region-এ নেওয়া।
• Site d111111abcdef8.cloudfront.net-এ চলে, shop.example.com-এ না। Distribution-এ alternate domain name নেই, certificate সেটা ঢাকে না, বা DNS এখনো distribution-এর দিকে দেখায় না।
• “আমার বদলটা চালু হচ্ছে না।” Distribution এখনো deploy হচ্ছে, বা পুরোনো response এখনো cache-এ।

#System design-এ CloudFront

• চেনা static front end। OAC সহ একটা private S3 bucket, ACM certificate আর Route 53 Alias সহ একটা distribution, CachingOptimized, লম্বা TTL আর version দেওয়া file name। সস্তা, দ্রুত, নিরাপদ; বেশির ভাগ serverless web app এখান থেকেই শুরু হয়।
• Site আর API-এর একটাই domain। Path behaviour /api/*-কে caching বন্ধ রেখে ALB বা API Gateway-তে পাঠায়, বাকি সব S3-এ। CORS নেই, certificate একটা, WAF একটা।
• হঠাৎ ভিড় শুষে নেওয়া। গরম dynamic page-এ ছোট TTL (এমনকি ১–৫ সেকেন্ড) একই রকম request-এর বন্যাকে origin-এ পৌঁছানোর আগে একটা সরু ধারায় নামিয়ে আনে। দুর্বল origin হলে Origin Shield যোগ করো।
• Region পেরিয়ে পড়ার ভরসা। CRR দ্বিতীয় একটা bucket হালনাগাদ রাখে; origin group পড়ার request সেখানে সরিয়ে নেয়।
• একই জায়গা থেকে global upload আর download। CloudFront দিয়ে PUT বা Transfer Acceleration দিয়ে upload, edge-এ cache হওয়া download, আর signed URL দিয়ে private content (লেসন ১১.২)।
• এর সীমা জানো। CloudFront HTTP-ভিত্তিক (HTTP, WebSocket, gRPC)। TCP বা UDP application, মূল চাহিদা যখন static IP address, বা HTTP না এমন traffic-এর দ্রুত Region failover হলে Global Accelerator দেখো (লেসন ১১.৪)।

#নিজে করে দেখো

একটা private bucket, OAC সহ একটা distribution বানাও, আর দেখো miss কীভাবে hit হয়ে যায়। ID-গুলো তোমার নিজেরগুলো দিয়ে বদলে নিও।

# 1. A private bucket with a photo (Block Public Access stays on, the default)
aws s3 mb s3://bazaarbari-images-example --region us-east-1
aws s3 cp saree-42.jpg s3://bazaarbari-images-example/img/saree-42.jpg \
  --cache-control "max-age=86400"

# 2. An origin access control that always signs
aws cloudfront create-origin-access-control --origin-access-control-config \
  Name=bazaarbari-oac,SigningProtocol=sigv4,SigningBehavior=always,OriginAccessControlOriginType=s3

# 3. The managed cache policies and their IDs
aws cloudfront list-cache-policies --type managed \
  --query "CachePolicyList.Items[].CachePolicy.[Id,CachePolicyConfig.Name]" --output table

# 4. Create the distribution from a config file (origin + OAC ID + default behaviour with
#    CachingOptimized, ViewerProtocolPolicy redirect-to-https, DefaultRootObject index.html)
aws cloudfront create-distribution --distribution-config file://dist-config.json
aws cloudfront get-distribution --id EDFDVBD6EXAMPLE --query "Distribution.Status"   # Deployed?

# 5. Allow only this distribution in the bucket policy (the JSON from the lesson)
aws s3api put-bucket-policy --bucket bazaarbari-images-example --policy file://oac-policy.json

এবার header-গুলো দেখো। একই request দুবার চালাও:

curl -sI https://d111111abcdef8.cloudfront.net/img/saree-42.jpg | grep -iE "x-cache|age|x-amz-cf-pop|cache-control"
# x-cache: Miss from cloudfront          ← first request
# x-amz-cf-pop: SIN2-P1                  ← the PoP that answered (yours will differ)

curl -sI https://d111111abcdef8.cloudfront.net/img/saree-42.jpg | grep -iE "x-cache|age"
# x-cache: Hit from cloudfront
# age: 12                                ← seconds since the copy was fetched

# Direct access to the bucket must fail
curl -sI https://bazaarbari-images-example.s3.us-east-1.amazonaws.com/img/saree-42.jpg | head -1
# HTTP/1.1 403 Forbidden

# A different query string is the same object only if the cache policy ignores query strings
curl -sI "https://d111111abcdef8.cloudfront.net/img/saree-42.jpg?fbclid=abc" | grep -i x-cache

আরও কাজের কিছু: প্রতিটা setting দেখতে aws cloudfront get-distribution-config --id EDFDVBD6EXAMPLE (update-distribution-এর জন্য যে ETag লাগে সেটাও এতে আসে), aws cloudfront list-distributions --query "DistributionList.Items[].[Id,DomainName,Aliases.Items]", আর certificate-এর জন্য aws acm request-certificate --domain-name shop.example.com --validation-method DNS --region us-east-1। কাজ শেষ হলে distribution মুছে ফেলো: আগে disable করো, deploy শেষ হওয়া পর্যন্ত অপেক্ষা করো, তারপর তার ETag দিয়ে delete-distribution।

#সারসংক্ষেপ

মূল কথা

• CloudFront হলো AWS-এর CDN: একটা global service, যেটা ৭৫০+ edge location (PoP)-এ content cache করে, পেছনে থাকে ১৫টা Regional Edge Cache; এতে latency আর origin-এর চাপ দুটোই কমে। AWS backbone দিয়ে dynamic content-ও দ্রুত হয়, আর edge-এ DDoS সুরক্ষা মেলে।
• একটা request যায় viewer → সবচেয়ে কাছের PoP → Regional Edge Cache → (ঐচ্ছিক Origin Shield) → origin। PUT, POST, PATCH, DELETE আর OPTIONS PoP থেকে সোজা origin-এ যায়, কখনো cache হয় না।
• একটা distribution (d111111abcdef8.cloudfront.net)-এ থাকে origin, origin group, cache behaviour (path pattern, প্রথম যেটা মেলে, default * সবশেষে, বড়-ছোট হাতের অক্ষর আলাদা) আর সাধারণ setting (alternate domain name, certificate, price class, WAF, log)।
• Origin: S3 bucket (REST endpoint, OAC দিয়ে সুরক্ষিত), S3 website endpoint (custom HTTP origin, public, OAC নেই), যেকোনো custom HTTP origin (public ALB, EC2, নিজের data centre), আর private ALB/NLB/EC2-এর জন্য VPC origin।
• OAC: CloudFront request sign করে; bucket private; bucket policy cloudfront.amazonaws.com-কে অনুমতি দেয় AWS:SourceArn = তোমার distribution শর্তে; SSE-KMS হলে KMS key policy-ও লাগে। OAI তার পুরোনো রূপ (SSE-KMS নেই, নতুন Region নেই)।
• Cache key = domain + path, সাথে cache policy যে query string, header আর cookie যোগ করে। ঠিক সেগুলোই রাখো যা response বদলায়। Origin request policy key না বদলেই বাড়তি মান পাঠায়।
• TTL: origin-এর max-age / s-maxage / Expires, minimum আর maximum TTL-এর মধ্যে বেঁধে; origin কিছু না বললে default ২৪ ঘণ্টা। মেয়াদ শেষের copy আবার যাচাই হয় (304 → RefreshHit); origin বন্ধ থাকলে stale-if-error পুরোনো copy দেয়; error default-এ ১০ s cache হয়।
• Origin group: primary আর secondary, প্রতি request ধরে failover, বাছা status code, timeout বা connection ব্যর্থ হলে; শুধু GET/HEAD/OPTIONS। Default-এ connection-এর চেষ্টা ৩ × ১০ s।
• HTTPS: viewer protocol policy (redirect বা শুধু HTTPS), origin protocol policy, us-east-1-এ ACM certificate, SNI (বিনা পয়সায়) বনাম dedicated IP।
• CloudFront বনাম CRR: CloudFront = TTL পর্যন্ত সব জায়গায় cache করা copy, global পড়ার জন্য; CRR = বাছা Region-এ পুরো, প্রায় সঙ্গে সঙ্গে হালনাগাদ copy, DR, compliance আর Region-এর ভেতরে কম latency-র জন্য; একটা bucket-এ দ্রুত upload = Transfer Acceleration।

নিজেকে যাচাই করো: CloudFront-এর মূল কথা৩০টি প্রশ্ন