הגדרת AWS CloudFront CDN: מטמון, אבטחה ו-Lambda@Edge
אנו מגדירים את CloudFront כרשת קצה (edge network) ליישום לוגיקה: בדיקות A/B לפי כותרות (headers), הפניות מחדש ללא קריאות למקור (origin), חסימה גיאוגרפית, חוקי WAF. אך גמישות זו הופכת את התצורה למורכבת. לארכיטקטי הפתרונות המוסמכים של AWS יש ניסיון של 5+ שנים עם AWS והם יישמו למעלה מ-50 פרויקטי CDN לשירותים בעלי עומס גבוה, תוך חיסכון של עד $2,500 לחודש ללקוחות בתעבורה יוצאת עבור העברת 5TB אופיינית. תרחיש נפוץ: צוות יוצר הפצה (distribution) עם הגדרות ברירת מחדל, עולה לאוויר, ומגלה שתוכן דינמי נשמר במטמון (כי Cache-Control לא מוגדר במקור), בקשות API מאומתות מחזירות 403 (עוגיות לא מועברות), וביטול מטמון יקר עקב מדיניות מפתח מטמון לא אופטימלית. אנו פותרים בעיות אלו באופן אישי לכל לקוח, וחוסכים עד 70% מעלויות התעבורה היוצאת.
הפצות, מקורות (Origins) והתנהגויות (Behaviors)
מקור (Origin) — מקור נתונים: S3, ALB, שרת HTTP מותאם אישית. עבור S3, אנו משתמשים ב-OAC (Origin Access Control) — הוא תומך בחתימת בקשות דרך SigV4 ועובד עם דליים מוצפנים. גישה זו מפחיתה עלויות אבטחה במאות דולרים לחודש על הפצה אחת.
התנהגות מטמון (Cache Behavior) — כלל המגדיר כיצד CloudFront מטפל בבקשות לפי תבנית נתיב. תצורה אופיינית:
-
Cache-Control→ נכסים סטטיים ב-S3 (עם מטמון) -
/*→ קצה אחורי של ALB (ללא מטמון או TTL מינימלי) -
/api/*→ S3 עם TTL ארוך (לדוגמה, 31536000 שניות) וגרסאות מקור דרך hash בכתובת URL
מדיניות מטמון (Cache Policy) ו-מדיניות בקשת מקור (Origin Request Policy) — מופרדות במכוון. מדיניות מטמון קובעת מה נכנס למפתח המטמון (כותרות, מחרוזות שאילתה, עוגיות). מדיניות בקשת מקור קובעת מה מועבר למקור. טעות נפוצה היא שימוש ב-/static/* עבור כותרות במקום מדיניות מפורשת. זה שובר מטמון: כל Forward: All ייחודי הופך לערך מטמון נפרד, ומפחית את שיעור הפגיעה (hit rate) מ-80% ל-40%.
SSL ודומיינים מותאמים אישית
CloudFront עובד עם תעודות ACM (AWS Certificate Manager). חשוב: התעודה חייבת להיווצר באזור us-east-1 (CloudFront הוא גלובלי, ACM משולב רק עם אזור זה). עבור דומיין מותאם אישית, צור רשומת Alias ב-Route 53 המצביעה על User-Agent. הגדר Minimum TLS Protocol ל-*.cloudfront.net, תוך השבתת גרסאות מיושנות.
Lambda@Edge ופונקציות CloudFront
עבור לוגיקה על CDN, אנו משתמשים בשתי גישות. השוואה:
| מאפיין | פונקציות CloudFront | Lambda@Edge |
|---|---|---|
| סביבת ריצה | JavaScript קל משקל | Node.js, Python |
| גישה לרשת | לא | כן |
| זמן ביצוע מקסימלי | 10 אלפיות שנייה | 5 שניות (צופה) / 30 שניות (מקור) |
| זיכרון | 2 MB | 128-3008 MB |
| אזורים | כל נקודות הקצה (~450 נקודות) | קצוות אזוריים (~13) |
| השהיה (Latency) | מיקרו-שניות | אלפיות שנייה |
| משימות אופייניות | טרנספורמציות URL, כותרות אבטחה, הפניות | בדיקות A/B, אימות, קריאות API חיצוניות |
פונקציות CloudFront מהירות עד פי 100 מ-Lambda@Edge עבור שכתובי URL פשוטים (מיקרו-שניות לעומת אלפיות שנייה). Lambda@Edge חזק יותר אך יקר יותר — אנו בוחרים לפי המשימה.
כיצד להגדיר מטמון לתוכן סטטי ודינמי?
עבור נכסים סטטיים, הגדר TTL ארוך (שנה) וכתובות URL עם גרסאות ו-hash בשם הקובץ (TLSv1.2_2021). עבור תוכן דינמי (API), הגדר TTL קצר (0–60 שניות) או השבת מטמון, תוך העברת כותרות אימות דרך מדיניות בקשת מקור. לדוגמה, הגדר main.abc123.js עבור נכסים סטטיים.
למה CloudFront לא שומר במטמון? סיבות נפוצות
-
Cache-Controlלא מוגדר במקור — CloudFront מניח ששמירה במטמון אינה מותרת. - מדיניות מטמון כוללת כותרות משתנות (לדוגמה,
Cookieעבור כל הבקשות). - שימוש ב-
Forward: Allבמקום מדיניות מפורשת.
ביטול מטמון (Cache Invalidation)
1000 נתיבי ביטול ראשונים בחודש הם בחינם. תו כללי /* נחשב כפעולה אחת, אך ביטול מטמון מלא אורך עד 10 דקות. הגישה הנכונה היא כתובות URL עם גרסאות: הפריסה משנה את ה-URL, קבצים ישנים ממשיכים להישלח מהמטמון. צינור CI/CD מעדכן את index.html עם TTL קצר (60–300 שניות) — בעיית התוכן המיושן נפתרת ללא ביטול. לפי תיעוד CloudFront, זהו הפתרון האופטימלי.
ניטור ועלות
מדדי CloudWatch: Requests, BytesDownloaded, 4xxErrorRate, 5xxErrorRate, CacheHitRate. אם שיעור פגיעת המטמון נמוך מ-60% — בצע אופטימיזציה של מדיניות המטמון או TTL. לוגים בזמן אמת דרך Kinesis Data Firehose → S3 → Athena לניתוח תעבורה.
| מדד | יעד | פעולה בחריגה |
|---|---|---|
| CacheHitRate | > 80% | הגדל TTL, בדוק מפתח מטמון |
| 4xxErrorRate | < 5% | בדוק מקור, מדיניות גישה |
| 5xxErrorRate | < 1% | הרחב מקור, בדוק השהיה |
טעויות אופייניות בהגדרת CloudFront:
- שימוש ב-OAI במקום OAC עבור S3 (OAI לא תומך בדליים מוצפנים).
- אין הגבלות גישה למקור (הפעלת lambdas ישירות).
- התעלמות מחסימה גיאוגרפית: CloudFront מאפשר הגבלת גישה לפי מדינה ברמת ההפצה.
תהליך העבודה
- אנליטיקה — ביקורת על הארכיטקטורה הנוכחית, זיהוי צווארי בקבוק.
- עיצוב — בחירת סכמה (מקורות מרובים, התנהגויות מטמון, מדיניות).
- יישום — הגדרת CloudFront, Lambda@Edge, CloudFront WAF, SSL.
- בדיקות — בדיקת מטמון, זמן תגובה, חסימה גיאוגרפית.
- פריסה — השקה הדרגתית (canary או blue-green).
מה כלול (תוצרים)
- תיעוד תצורת ההפצה, המדיניות והפונקציות.
- הגדרת CI/CD לביטול ופריסה אוטומטיים.
- הדרכת צוות (runbook, פעולות אופייניות).
- תמיכה לאחר השקה (ניטור חודש, ייעוץ).
- גישה למשאבי AWS ולתצורות.
לוחות זמנים
הגדרת הפצה בסיסית לנכסים סטטיים — מספר שעות. תצורה עם מקורות מרובים, WAF, Lambda@Edge ומדיניות מותאמת אישית — 1–3 ימים תלוי במורכבות. צור קשר להערכה מדויקת של הפרויקט שלך — קבל ייעוץ מהנדס. טעינה מואצת מפחיתה נטישת משתמשים, וחוסכת עד 30% בהמרות. הזמן ביקורת CDN וגלה כמה אתה יכול לחסוך.