0Pricing
AWS Solutions Architect · บทเรียน

พฤติกรรมแคชและการตั้งค่า TTL

กำหนดพฤติกรรมแคชตามเส้นทาง ตั้งค่า TTL ขั้นต่ำ ค่าเริ่มต้น และค่าสูงสุด พร้อมใช้ส่วนหัวควบคุมแคชเพื่อปรับการแคชอย่างละเอียด

พฤติกรรมแคชและการตั้งค่า TTL เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

ลักษณะการทำงานของแคชคืออะไร

ลักษณะการทำงานของแคชคือกฎที่บอก CloudFront ว่าควรจัดการคำขอสำหรับรูปแบบเส้นทาง URL ที่แตกต่างกันอย่างไร ลักษณะการทำงานของแคชแต่ละรายการจะจับคู่รูปแบบเส้นทาง (เช่น /images/*, /api/*, *.css) กับต้นทางและการกำหนดค่าแคชที่เจาะจง

การกระจายเนื้อหาหนึ่งรายการมี ลักษณะการทำงานของแคชเริ่มต้นหนึ่งรายการ (จับคู่กับเส้นทางทั้งหมดที่ไม่ได้ตรงกับลักษณะการทำงานที่เฉพาะเจาะจงกว่า) และมีลักษณะการทำงานเพิ่มเติมตามเส้นทางได้สูงสุด 25 รายการ CloudFront จะประเมินลักษณะการทำงานจากเฉพาะเจาะจงที่สุดไปหาทั่วไปที่สุดตามลำดับ แล้วจึงใช้ค่ามาตรฐานเริ่มต้นหากไม่ตรงกับรายการใด

การจับคู่รูปแบบเส้นทาง

รูปแบบเส้นทางรองรับอักขระตัวแทน: * จับคู่อักขระชุดใดก็ได้ รวมถึงเครื่องหมายทับ และ ? จับคู่อักขระเดี่ยว ตัวอย่าง:

  • /images/* — URL ทั้งหมดที่ขึ้นต้นด้วย /images/
  • *.jpg — คำขอทั้งหมดที่ลงท้ายด้วย .jpg ไม่ว่าจะอยู่ที่ใดในเส้นทาง
  • /api/v2/* — เส้นทาง API v2 ทั้งหมด
  • /static/??.css — ไฟล์ CSS แบบคงที่ที่มีอักขระสองตัวพอดีก่อน .css

ระบบจะประเมินลักษณะการทำงานตามลำดับที่แสดงในการกำหนดค่าการกระจายเนื้อหา ให้วางรูปแบบที่เฉพาะเจาะจงกว่าไว้ก่อน ลักษณะการทำงานเริ่มต้น (*) จะจับคู่เป็นลำดับสุดท้ายเสมอ

นโยบายแคชเทียบกับนโยบายคำขอต้นทาง

CloudFront แยกตรรกะการแคชออกเป็นนโยบายสองประเภท:

  • นโยบายแคช: กำหนดสิ่งที่ CloudFront ใช้เป็น คีย์แคช ซึ่งเป็นการรวมกันของส่วนหัว สตริงคำค้นหา และคุกกี้ที่ใช้ตัดสินว่าวัตถุที่แคชไว้ตรงกับคำขอหรือไม่ นอกจากนี้ยังกำหนดขอบเขต TTL ด้วย
  • นโยบายคำขอต้นทาง: กำหนดส่วนหัว สตริงคำค้นหา และคุกกี้ที่จะส่งต่อไปยังต้นทาง แม้สิ่งเหล่านั้นจะไม่ได้เป็นส่วนหนึ่งของคีย์แคชก็ตาม (เพื่อส่งส่วนหัวการตรวจสอบสิทธิ์ไปยังต้นทาง โดยไม่ทำให้แคชแยกตามโทเค็น)

AWS มีนโยบายที่จัดการไว้ให้ (เช่น CachingOptimized, CachingDisabled) ซึ่งครอบคลุมกรณีการใช้งานส่วนใหญ่ หรือคุณจะสร้างนโยบายแบบกำหนดเองก็ได้

การตั้งค่า TTL ใน CloudFront

CloudFront จะใช้ค่า TTL สามค่าจากนโยบายแคช:

  • TTL ขั้นต่ำ: ระยะเวลาที่สั้นที่สุดที่ CloudFront จะแคชวัตถุ ไม่ว่าส่วนหัวจากต้นทางจะระบุไว้อย่างไรก็ตาม (ค่าเริ่มต้น 0)
  • TTL เริ่มต้น: ระยะเวลาที่ CloudFront จะแคชวัตถุเมื่อต้นทางไม่ได้ส่งส่วนหัว Cache-Control หรือ Expires (ค่าเริ่มต้น 86,400 วินาที = 1 วัน)
  • TTL สูงสุด: ระยะเวลาที่ยาวนานที่สุดที่ CloudFront จะแคชวัตถุ โดยจำกัดคำสั่ง Cache-Control max-age ของต้นทาง (ค่าเริ่มต้น 31,536,000 = 1 ปี)

ค่าทั้งสามนี้เป็นขอบเขตของระยะเวลาการแคชจริงที่ต้นทางส่งมาผ่านส่วนหัว Cache-Control

ส่วนหัว Cache-Control จากต้นทาง

เมื่อต้นทางส่งส่วนหัว Cache-Control: max-age=3600 CloudFront จะแคชวัตถุเป็นเวลา 3,600 วินาที ตราบใดที่ค่านี้อยู่ภายในขอบเขต TTL ขั้นต่ำและสูงสุดของนโยบายแคช หากต้นทางส่ง Cache-Control: no-cache หรือ Cache-Control: no-store CloudFront จะตรวจสอบกับต้นทางก่อนให้บริการสำเนาที่แคชไว้ทุกครั้ง

สำหรับทรัพยากรแบบคงที่ที่แทบไม่มีการเปลี่ยนแปลง ให้ตั้งค่า max-age เป็นเวลานาน (เช่น 31536000 = 1 ปี) และใช้ การทำให้แคชหมดความถูกต้องด้วยชื่อไฟล์ โดยใส่แฮชของเนื้อหาไว้ในชื่อไฟล์ (เช่น app.a3f4b5.js) เพื่อให้ URL เปลี่ยนเมื่อเนื้อหาเปลี่ยน และทำให้แคชเวอร์ชันเก่าหมดความถูกต้องโดยอัตโนมัติ

# S3 object metadata with long cache TTL
aws s3 cp app.a3f4b5.js s3://my-bucket/ \
  --cache-control 'max-age=31536000, immutable' \
  --content-type 'application/javascript'

การแยกลักษณะการทำงานแบบคงที่และแบบไดนามิก

รูปแบบลักษณะการทำงานของแคชที่มีประสิทธิภาพคือการแยกเนื้อหาแบบคงที่ออกจากเนื้อหาแบบไดนามิก:

  • /static/*, *.css, *.js, *.jpg → ต้นทาง S3 ใช้นโยบาย CachingOptimized (TTL สูง ไม่มีคุกกี้หรือสตริงคำค้นหาในคีย์แคช)
  • /api/* → ต้นทาง ALB ใช้นโยบาย CachingDisabled (ดึงข้อมูลจากต้นทางทุกครั้ง และส่งต่อส่วนหัวหรือคุกกี้ทั้งหมด)
  • /* (ค่าเริ่มต้น) → ต้นทาง ALB ใช้การแคชระดับปานกลาง

วิธีนี้จะแยกชั้นเนื้อหาแบบคงที่ที่เหมาะกับการแคชออกจากชั้น API แบบไดนามิก ทำให้อัตราการพบข้อมูลในแคชของเนื้อหาแบบคงที่สูงขึ้น ขณะเดียวกันก็ทำให้มั่นใจว่าการตอบกลับจาก API เป็นข้อมูลล่าสุดเสมอ

การทำให้แคชหมดความถูกต้อง

เมื่อคุณอัปเดตเนื้อหาใน S3 หรือต้นทาง และต้องการให้ CloudFront ให้บริการเวอร์ชันใหม่ทันทีโดยไม่ต้องรอให้ TTL หมดอายุ คุณสามารถสร้าง การทำให้แคชหมดความถูกต้องได้ ระบุเส้นทางที่ต้องการทำให้หมดความถูกต้อง (เช่น /images/logo.png หรือ /images/*) แล้ว CloudFront จะนำวัตถุเหล่านั้นออกจากแคชของตำแหน่งขอบทั้งหมด

การทำให้แคชหมดความถูกต้องมีค่าใช้จ่าย: 1,000 เส้นทางแรกต่อเดือนใช้งานได้ฟรี ส่วนเส้นทางเพิ่มเติมจะคิดค่าใช้จ่ายต่อเส้นทาง การทำให้แคชหมดความถูกต้องด้วยอักขระตัวแทน (เช่น /*) จะนับเป็นหนึ่งเส้นทาง แนวทางปฏิบัติที่ดีคือใช้ชื่อไฟล์แบบมีเวอร์ชันสำหรับทรัพยากรแบบคงที่ แทนการทำให้แคชหมดความถูกต้องบ่อยครั้ง เพื่อลดค่าใช้จ่ายและความล่าช้า

# Create a cache invalidation for updated images
aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths '/images/logo.png' '/css/main.css'

องค์ประกอบของคีย์แคช

คีย์แคชคือตัวระบุเฉพาะที่ CloudFront ใช้ค้นหาการตอบกลับที่แคชไว้ โดยค่าเริ่มต้น คีย์แคชจะมีเพียงเส้นทาง URL การเพิ่มองค์ประกอบอื่นจะเพิ่มจำนวนรายการแคชที่แตกต่างกัน:

  • สตริงคำค้นหา: /search?q=aws และ /search?q=s3 จะเป็นรายการแคชแยกกัน หาก q อยู่ในคีย์แคช
  • ส่วนหัว: การใส่ Accept-Encoding ช่วยให้ CloudFront แคชเวอร์ชัน gzip และเวอร์ชันที่ไม่ใช่ gzip แยกกัน
  • คุกกี้: การใส่คุกกี้เซสชันจะสร้างรายการแคชแยกตามผู้ใช้ ซึ่งเท่ากับเป็นการปิดใช้แคช

ลดองค์ประกอบของคีย์แคชให้น้อยที่สุดเพื่อให้แคชมีประสิทธิภาพสูงสุด ควรใส่เฉพาะองค์ประกอบที่ทำให้เนื้อหาการตอบกลับแตกต่างกันจริง ๆ

การบีบอัดที่ตำแหน่งขอบ

CloudFront สามารถ บีบอัดวัตถุแบบข้อความ (HTML, CSS, JavaScript, JSON) โดยใช้ gzip หรือ Brotli ก่อนส่งให้ผู้ชมโดยอัตโนมัติ วิธีนี้ช่วยลดขนาดข้อมูลที่ส่งลง 60–80% และทำให้หน้าเว็บโหลดเร็วขึ้นโดยไม่ต้องเปลี่ยนแปลงต้นทาง

หากต้องการเปิดใช้การบีบอัด ให้ตรวจสอบว่านโยบายแคชมี Accept-Encoding อยู่ในคีย์แคช (CloudFront จำเป็นต้องแคชเวอร์ชัน gzip และเวอร์ชันที่ไม่ใช่ gzip แยกกัน) และเปิดใช้ Compress Objects Automatically ในลักษณะการทำงานของแคช CloudFront จะบีบอัดวัตถุที่มีขนาดใหญ่กว่า 1,000 ไบต์และเล็กกว่า 10 MB

อัตราการพบข้อมูลในแคชและการตรวจสอบ

อัตราการพบข้อมูลในแคชคือเปอร์เซ็นต์ของคำขอที่ให้บริการจากแคชของ CloudFront โดยไม่ต้องไปยังต้นทาง อัตราที่สูง (80% ขึ้นไป) หมายถึงค่าใช้จ่ายของต้นทางที่ต่ำลงและประสิทธิภาพที่ดีขึ้น ตรวจสอบค่าได้ผ่านรายงาน สถิติแคช ในคอนโซล CloudFront หรือผ่านเมตริก CloudWatch CacheHitRate

วิธีเพิ่มอัตราการพบข้อมูลในแคช ได้แก่ เพิ่มค่า TTL ลดจำนวนส่วนหัวหรือคุกกี้ในคีย์แคช ใช้การปรับรูปแบบสตริงคำค้นหาให้เป็นมาตรฐาน (ส่งต่อเฉพาะสตริงคำค้นหาที่แอปพลิเคชันใช้งานจริง) และตั้งค่าส่วนหัว Cache-Control ที่เหมาะสมจากต้นทาง

# Get CloudFront metrics for cache hit rate
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=EDFDVBD6EXAMPLE \
  --start-time 2026-06-19T00:00:00Z \
  --end-time 2026-06-20T00:00:00Z \
  --period 3600 \
  --statistics Average \
  --region us-east-1

การตั้งค่าต้นทางและโพรโทคอลแยกตามลักษณะการทำงาน

ลักษณะการทำงานของแคชแต่ละรายการสามารถชี้ไปยัง ต้นทางที่แตกต่างกัน ทำให้การกระจายเนื้อหา CloudFront รายการเดียวให้บริการเนื้อหาจากแบ็กเอนด์หลายแห่งได้ ตัวอย่างเช่น:

  • /static/* → ต้นทาง S3 (บัคเก็ตส่วนตัวผ่าน OAC)
  • /api/* → ต้นทาง ALB ใน us-east-1
  • /media/* → ต้นทาง CDN ของ MediaPackage สำหรับการสตรีมวิดีโอ

ลักษณะการทำงานแต่ละรายการยังสามารถกำหนดนโยบายโพรโทคอลของผู้ชม วิธี HTTP ที่อนุญาต และการเชื่อมโยงฟังก์ชัน (ฟังก์ชัน CloudFront หรือ Lambda@Edge) ได้อย่างอิสระ ทำให้การกระจายเนื้อหาเพียงรายการเดียวเป็นชั้นส่งมอบที่ยืดหยุ่นและใช้งานได้หลากหลาย

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า ลักษณะการทำงานของแคชจะจับคู่รูปแบบเส้นทาง URL กับต้นทางและกฎการแคช ขอบเขต TTL ขั้นต่ำ/เริ่มต้น/สูงสุดจะควบคุมระยะเวลาที่แคชเก็บเนื้อหาไว้ โดยส่วนหัว Cache-Control ของต้นทางจะมีผลเหนือกว่าเมื่อมีการระบุไว้ และ การทำให้แคชหมดความถูกต้องจะล้างเนื้อหาที่ล้าสมัยออกจากตำแหน่งขอบทั้งหมดทันที ลดองค์ประกอบของคีย์แคชให้น้อยที่สุดเพื่อเพิ่มอัตราการพบข้อมูลในแคช บทถัดไป เราจะสำรวจ URL ที่มีลายเซ็น คุกกี้ที่มีลายเซ็น และการจำกัดตามภูมิศาสตร์

คำถามที่พบบ่อย

บทเรียน “พฤติกรรมแคชและการตั้งค่า TTL” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “พฤติกรรมแคชและการตั้งค่า TTL” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “พฤติกรรมแคชและการตั้งค่า TTL”

กำหนดพฤติกรรมแคชตามเส้นทาง ตั้งค่า TTL ขั้นต่ำ ค่าเริ่มต้น และค่าสูงสุด พร้อมใช้ส่วนหัวควบคุมแคชเพื่อปรับการแคชอย่างละเอียด คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “พฤติกรรมแคชและการตั้งค่า TTL” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ดิสทริบิวชันและต้นทางของ CloudFront
  2. พฤติกรรมแคชและการตั้งค่า TTL
  3. URL ที่ลงนาม คุกกี้ที่ลงนาม และการจำกัดตามภูมิศาสตร์
  4. CloudFront ร่วมกับ WAF และ Lambda@Edge
← กลับไปที่ AWS Solutions Architect