AWS: ‏Lambda, ניטור ואיך נמנעים מחשבונית מפתיעה

החלק האחרון בסדרת AWS. הוא נשען על roles של IAM מIAM, ה-CLI ו-S3 ועל השרתים ומסדי הנתונים מEC2, ‏VPC ו-RDS.

Lambda: קוד בלי שרתים

AWS Lambda מריצה את הקוד שלנו בתגובה לאירועים בלי שננהל שרת כלשהו. כותבים פונקציה, מחברים trigger, ו-Lambda מריצה אותה ומתרחבת אוטומטית לפי הביקוש. ‏triggers טיפוסיים הם בקשת HTTP דרך API Gateway, קובץ שנוחת ב-S3, הודעה בתור או לוח זמנים.

פונקציה היא פשוט handler. זו ב-Python ומחזירה ברכה:

import json

def lambda_handler(event, context):
    name = event.get("name", "world")
    return {"statusCode": 200, "body": json.dumps({"message": f"Hello, {name}!"})}

זה Python רגיל: אפשר לנסות מקומית עם lambda_handler({"name": "Dana"}, None).

מה כדאי לדעת:

• תשלום לפי שימוש: מחייבים על בקשות ועל זמן ריצה (מול הזיכרון שהגדרנו), ושום דבר כשהיא לא רצה.
• מגבלות: הרצה אחת נמשכת עד 15 דקות, ולכן Lambda מתאימה למשימות קצרות.
• חסרת מצב (stateless): שום דבר לא שורד בין הרצות. שומרים מצב ב-S3 או במסד נתונים.
• Cold starts: פונקציה שלא רצה זמן מה עלולה להתחיל לאט יותר בבקשה הראשונה.
• ה-execution role קובע לאילו דברים ב-AWS הפונקציה יכולה לגעת. נותנים לה רק מה שהיא צריכה.

Lambda מתאימה לקוד דבק ולעבודה מונחית אירועים: לשנות גודל של תמונה כשהיא נוחתת ב-S3, להריץ ניקוי לילי, לענות ל-webhook.

מתבוננים במה שקורה

• Amazon CloudWatch אוסף metrics ‏(CPU, מספר בקשות…) ו-logs (הפלט של Lambda, לוגים של שרתים דרך agent), ומגדיר alarms שמתריעים כשמדד עובר סף. ‏Dashboards מציגים אותם במסך אחד.
• AWS CloudTrail רושם את קריאות ה-API בחשבון: מי עשה מה, מתי ומאיפה. כשמשהו משתנה בלי שציפינו, כאן מגלים מי שינה.

ה-alarm הראשון שכדאי הוא התראת התקציב, וההרגל הראשון הוא להסתכל ב-CloudWatch Logs כש-Lambda נכשלת: השגיאה כמעט תמיד מודפסת שם.

בוחרים: במה משתמשים בשביל…

צריך…	פונים אל
לשמור קבצים, גיבויים, נכסי אתר	S3
להריץ שרת ששולטים בו	EC2
להריץ פונקציה קצרה בתגובה לאירוע	Lambda
להריץ containers בלי לנהל שרתים	ECS או EKS (עם Fargate)
מסד נתונים רלציוני מנוהל	RDS (או Aurora)
לשלוט במי יכול לעשות מה	IAM ו-IAM Identity Center
לבודד ולחבר את המשאבים	VPC ו-security groups
להגיש תוכן מהר בכל העולם	CloudFront
לראות metrics, לוגים והתראות	CloudWatch
לבקר מי שינה מה	CloudTrail
לעקוב אחרי הוצאות ולהגביל אותן	Budgets ו-Cost Explorer

נמנעים מהחשבונית המפתיעה

כמעט כל סיפור אימה הוא אחד מאלה:

• משאב שרץ ונשכח: ‏instance של EC2, מסד נתונים של RDS, ‏NAT gateway או load balancer שאף אחד לא כיבה. הם מחויבים לפי שעה.
• Access keys שדלפו ומשמשים להרצת כורי קריפטו. לא יוצרים מפתחות ארוכי טווח, אף פעם לא עושים להם commit, ומוחקים את אלה שיש.
• שאריות אחרי “מחיקה”: כוננים של EBS, ‏snapshots וכתובות Elastic IP שנשארים אחרי terminate של שרת.
• ה-Region הלא נכון: משאבים ב-Region שלא מסתכלים עליו. בודקים את הבורר, או משתמשים ב-Tag Editor ובפירוט החיוב לפי Region.
• העברת נתונים: הוצאת נתונים מ-AWS או בין Regions עולה כסף.

ההרגלים שמונעים אותם: תקציב ביום הראשון, tag עם שם הפרויקט על כל דבר שיוצרים, ניקוי באותו יום שמסיימים ניסוי, ובדיקה שבועית של דף Bills בזמן הלמידה.

לאן ממשיכים

בונים משהו קטן שנוגע בכמה חלקים: ‏bucket פרטי ב-S3 שמעלים אליו קבצים עם ה-CLI, פונקציית Lambda שרצה כשקובץ מגיע, ולוג ב-CloudWatch שמראה אותה עובדת. ואז מוחקים הכול ובודקים את החשבונית.

הצעדים הבאים: להעלות את האפליקציה מ-Docker מאפס לגיבור ל-ECS, ולהפוך פריסות לאוטומטיות עם היסודות של Actions ב-GitHub מאפס לגיבור. התיעוד הרשמי מצוין: מתחילים בדף AWS Free Tier, ב-IAM best practices וב-AWS CLI user guide.