מדריך

שחזור אוטומטי (rollback) לפריסת ECS Fargate כושלת ללא סקריפטים מותאמים אישית.

→הפעל את ECS deployment circuit breaker עם שחזור אוטומטי בשירות ה-ECS.

למה: תכונה מובנית של ECS שמבצעת שחזור אוטומטי אם משימות חדשות לא מצליחות להתייצב. תקורה תפעולית מינימלית בהשוואה ל-CodeBuild polling מותאם אישית או הגדרות CodeDeploy מורכבות.

מקור↗

פרוס לאזור ראשי, אמת באמצעות בדיקות אוטומטיות, ולאחר מכן פרוס לאזורים אחרים במקביל.

→השתמש ב-CodePipeline יחיד עם שלבים עוקבים: (1) פריסה לאזור A, (2) שלב בדיקה של CodeBuild המבצע אימות, (3) שלב פריסה מקבילה לאזורים B ו-C.

למה: CodeBuild משמש כשער אוטומטי ותכנותי. Pipeline יחיד פשוט יותר מאשר תזמור מספר Pipelines עם Step Functions.

סקריפט אימות ארוך טווח ב-CodeDeploy lifecycle hook גורם להצלחת פריסה מוקדמת.

→הגדל את מאפיין `timeout` עבור סקריפט ה-lifecycle hook הספציפי בקובץ `AppSpec.yml`א.

למה: ה-timeout מוגדר לכל hook בקובץ ה-AppSpec, לא ברמת קבוצת הפריסה. זה מבטיח שלסקריפט האימות יהיה מספיק זמן להשלמה.

האצת בניית תמונות Docker איטית ב-CodeBuild הנגרמת על ידי הורדה מחדש של תלויות ושכבות תמונה בכל הרצה.

→בתצורת פרויקט CodeBuild, הפעל את `LOCAL_DOCKER_LAYER_CACHE` והגדר מטמון S3 עבור ספריות תלויות (לדוגמה, `.m2`, `node_modules`).

למה: מתמודד ישירות עם שני מקורות האיטיות. מטמון שכבות Docker עושה שימוש חוזר בשכבות תמונה שלא השתנו; מטמון S3 עושה שימוש חוזר בתלויות יישומים שהורדו.

הטמעת פריסת קנרי (canary deployment) עבור פונקציית Lambda עם שחזור אוטומטי מונחה מדדים.

→השתמש ב-AWS SAM עם `DeploymentPreference` (לדוגמה, סוג `Canary10Percent5Minutes`). הוסף אזעקת CloudWatch על מדד `Errors` כטריגר לשחזור.

למה: SAM משתלב באופן מובנה עם CodeDeploy עבור Lambda, ומאפשר אוטומציה של העברת תעבורת כינויים, ניטור ושחזור ללא סקריפטים מותאמים אישית.

מקור↗

הגדר IAM עבור CodePipeline בחשבון A כדי לפרוס משאבים לחשבון B.

→תפקיד ה-Pipeline (חשבון A) מניח תפקיד פעולה (חשבון B). תפקיד הפעולה ב-B סומך על תפקיד ה-Pipeline ויש לו הרשאות פריסה. לדלי ה-S3 ולמפתח ה-KMS ב-A חייבות להיות מדיניות משאבים המעניקה גישה לתפקיד הפעולה ב-B.

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

הטמעת זרימת עבודה של GitOps עבור EKS שבה מצב האשכול מתיישר אוטומטית וברציפות עם מאגר Git.

→פרוס בקר GitOps (לדוגמה, Flux, ArgoCD) באשכול EKS. הגדר אותו לנטר את מאגר ה-Git וליישם/ליישר שינויים.

למה: זוהי תבנית ה-GitOps הסטנדרטית מבוססת "pull". הבקר שבתוך האשכול מטפל ביישור רציף ובזיהוי סחף, שהוא העיקרון המרכזי של GitOps.

אפשר לפרויקט CodeBuild בחשבון כלים מרכזי לפרוס מניפסטים של Kubernetes לאשכולות EKS בחשבונות עומס עבודה נפרדים.

→בכל חשבון עומס עבודה, צור תפקיד IAM חוצה חשבונות שאותו בוטח תפקיד ה-CodeBuild. מפה תפקיד חדש זה לקבוצת Kubernetes RBAC ב-ConfigMap `aws-auth` של אשכול EKS. סקריפט ה-CodeBuild מניח את התפקיד לפני הרצת `kubectl`.

למה: זוהי תבנית הגישה הסטנדרטית והמאובטחת ל-EKS בין חשבונות. היא פועלת לפי עקרון הפריבילגיה המינימלית על ידי יצירת תפקיד ייעודי ומהימן למטרה זו.

בצע הגירת סכימה מורכבת של RDS PostgreSQL או MySQL עם השבתה אפסית או כמעט אפסית.

→השתמש בתכונת Amazon RDS Blue/Green Deployments. צור סביבת ביניים (green) מסונכרנת, החל עליה שינויי סכימה, ולאחר מכן בצע מעבר כדי לקדם אותה לייצור.

למה: זהו השירות המנוהל והייעודי לעדכוני RDS בטוחים וללא השבתה. הוא מטפל בשיבוט, סנכרון, ומעבר מהיר (פחות מדקה) עם אמצעי הגנה מובנים.

פרוס גרסה חדשה של יישום דף יחיד (SPA) ל-S3/CloudFront וודא שמשתמשים יקבלו את הגרסה החדשה באופן מיידי עם עלויות ביטול מטמון מינימליות.

→השתמש ב-hashing מבוסס תוכן עבור שמות קבצי נכסים (לדוגמה, `app.a1b2c3d4.js`). לאחר פריסת נכסים חדשים, בטל את תוקף המטמון (invalidate) רק של הקובץ `index.html` בהפצת CloudFront.

למה: שמות קבצים עם hash הם ייחודיים, ולכן CloudFront מתייחס אליהם כאובייקטים חדשים ושולף אותם מהמקור, תוך עקיפת המטמון. רק קובץ נקודת הכניסה היחיד (`index.html`) דורש ביטול תוקף מטמון, וזה זול משמעותית מביטול תוקף מטמון עם תו כללי (`/*`).

הטמעת pipeline של CI/CD עבור יישום AWS CDK שמתעדכן אוטומטית כאשר הגדרת ה-pipeline עצמה משתנה.

→השתמש בקונסטרוקציה CDK Pipelines (`pipelines.CodePipeline`). קונסטרוקציה זו יוצרת pipeline הכולל שלב `SelfMutate` כברירת מחדל.

למה: CDK Pipelines היא קונסטרוקציה ברמה גבוהה שנבנתה במיוחד עבור תבנית זו. שלב ה-`SelfMutate` מבטיח שה-pipeline תמיד ישקף את ההגדרה העדכנית ביותר מהקוד לפני פריסת שינויי יישומים.

פרוס גרסת יישום חדשה הדורשת שינוי סכימת מסד נתונים תואם לאחור (לדוגמה, הוספת עמודות חדשות) עם השבתה אפסית.

→הטמע תבנית "הרחבה וכיווץ" (או שינוי מקביל). ראשית, פרוס את שינויי סכימת מסד הנתונים התוספתיים ותואמי-האחור. שנית, פרוס את גרסת היישום החדשה המשתמשת בסכימה החדשה. גם גרסאות היישום הישנות וגם החדשות יכולות להתקיים יחד עם מסד הנתונים המעודכן.

למה: תבנית זו מפרידה את פריסות מסד הנתונים והיישומים, ומבטיחה שמצב מסד הנתונים תמיד תואם גם לגרסאות היישום הישנות וגם לחדשות, ובכך מאפשרת פריסות ללא השבתה.

השק בהדרגה תכונה חדשה לפלחי משתמשים ספציפיים ומדוד את ההשפעה על מדדים עסקיים (לדוגמה, יחס המרה) באמצעות בדיקות A/B.

→השתמש ב-Amazon CloudWatch Evidently. צור תכונה עם וריאציות מרובות, השקה לשליטה באחוז ההפצה, וניסוי למדידת ההשפעה הסטטיסטית על מדדים מוגדרים.

למה: Evidently הוא שירות ייעודי עבור סימון תכונות וניסויי A/B, המספק לא רק את מנגנון ההפצה אלא גם את מנוע הניתוח הסטטיסטי למדידת השפעה.

אכיפת תגיות חובה על כל מופעי EC2 בזמן ההשקה בכל רחבי ארגון AWS.

→השתמש במדיניות בקרת שירות (SCP) המונעת `ec2:RunInstances` אלא אם כן מפתחות התגיות הנדרשים קיימים בבקשה.

למה: בקרת מניעה שחוסמת יצירת משאבים שאינם תואמים. חלה על כל החשבונות ולא ניתנת לדריסה על ידי מדיניות IAM מקומית.

מקור↗

נהל וסובב סודות (לדוגמה, אישורי DB) המשמשים יישומים במספר חשבונות ללא השבתה.

→השתמש ב-AWS Secrets Manager עם סיבוב אוטומטי מופעל. הענק גישה בין חשבונות באמצעות מדיניות מבוססת משאבים על הסוד.

למה: Secrets Manager תומך באסטרטגיות סיבוב ללא השבתה (החלפת משתמשים) ומספק שיתוף מאובטח ומובנה בין חשבונות.

פרוס אוטומטית משאבי אבטחה בסיסיים לחשבונות חדשים שנוצרו באמצעות Control Tower Account Factory.

→השתמש באירוע מחזור החיים של Control Tower `CreateManagedAccount` דרך EventBridge כדי להפעיל פונקציית Lambda הפורסת CloudFormation StackSet. לחלופין, השתמש בהתאמות אישיות עבור AWS Control Tower (CfCT).

למה: אוטומציה מונחית אירועים היא התבנית הסטנדרטית והסקלאבילית להרחבת baselines של Control Tower ללא התערבות ידנית לאחר יצירת החשבון.

אפשר גישת SSM Session Manager למופעי EC2 בתת-רשת פרטית ללא גישה לאינטרנט.

→צור נקודות קצה של ממשק VPC (מופעלות על ידי PrivateLink) עבור שירותי `ssm`, `ssmmessages` ו-`ec2messages` ב-VPC.

למה: נקודות קצה של VPC מאפשרות לסוכן ה-SSM לתקשר עם השירות כולו בתוך רשת AWS, ומספקות את תבנית הגישה המאובטחת ביותר ללא צורך ב-NAT או internet gateway.

רכז יומנים עם שמירה לטווח ארוך והגן עליהם מפני מחיקה או שינוי, אפילו על ידי מנהלים.

→אחסן יומנים בדלי S3 עם S3 Object Lock במצב תאימות (compliance mode). אפשר אימות שלמות קבצי יומן של CloudTrail.

למה: Object Lock (מצב תאימות) מספק הגנת WORM שאפילו חשבון ה-root אינו יכול לעקוף. אימות שלמות קבצי יומן מספק בדיקה קריפטוגרפית לשינויים לאחר מסירה.

ספק למפתחים דרך שירות עצמי לאספקת תבניות תשתית מאושרות מראש מבלי להעניק להם הרשאות שירות AWS מלאות.

→השתמש ב-AWS Service Catalog. צור תיק מוצרים מאושרים (מוגדרים על ידי תבניות CloudFormation). השתמש באילוצי השקה כדי ש-Service Catalog יספק משאבים באמצעות תפקיד IAM מועדף המנוהל על ידי צוות הפלטפורמה.

למה: Service Catalog הוא שירות AWS הייעודי ליצירת קטלוגים מנוהלים של שירותי IT. אילוצי השקה הם תכונת המפתח של Governance, המאפשרים למפתחים לספק תשתית מורכבת מבלי שיהיו להם את ההרשאות הבסיסיות בעצמם.

ספק באופן מאובטח סודות ייחודיים למיקרו-שירותים שונים הפועלים כמשימות ECS, תוך הבטחה שכל שירות יוכל לגשת רק לסודותיו שלו.

→צור סודות AWS Secrets Manager נפרדים לכל שירות. בהגדרת משימת ה-ECS, הפנה ל-ARNs של הסודות במאפיין `secrets` של הגדרת הקונטיינר. הגבל את מדיניות תפקיד ביצוע המשימה של IAM כך שתאפשר רק `secretsmanager:GetSecretValue` על ARN הסוד הספציפי של אותו שירות.

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

אפשר לזרימת עבודה של GitHub Actions לגשת ל-AWS באופן מאובטח ללא אחסון אישורים ארוכי טווח.

→הגדר ספק זהויות IAM OIDC עבור GitHub. צור תפקיד IAM עם מדיניות אמון המגבילה את הישות המאוחדת לארגון, מאגר וענף GitHub הספציפיים. השתמש בפעולת `aws-actions/configure-aws-credentials` עם OIDC כדי להניח את התפקיד.

למה: איחוד OIDC הוא השיטה המאובטחת ביותר, המספק אישורים קצרי טווח המוגבלים להרצת זרימת עבודה ספציפית, ובכך מבטל את הסיכון לחשיפת אישורים ארוכי טווח.

נטר באופן רציף את כל מדיניותי ה-IAM ברחבי ארגון AWS כדי לזהות ולקבל התראות על משאבים המשותפים לישויות חיצוניות.

→הפעל את IAM Access Analyzer ברמת הארגון, הגדר את הארגון כאזור האמון. השתמש ב-EventBridge כדי ללכוד ממצאים חדשים ולהפעיל התראות.

למה: IAM Access Analyzer נבנה במיוחד כדי להשתמש בהיגיון אוטומטי למציאת משאבים משותפים חיצונית. הפעלתו ברמת הארגון מספקת תצוגה רציפה ומרכזית ללא סקריפטים מותאמים אישית.

הפחתת טווח ההשפעה של עדכוני CloudFormation כושלים בארכיטקטורת ערימה מונוליטית או מקוננת.

→פרק את הארכיטקטורה לערימות עצמאיות באמצעות הפניות בין ערימות (CloudFormation Exports/Fn::ImportValue).

למה: כשל בערימה אחת (לדוגמה, מסד נתונים) לא יפעיל שחזור של ערימות אחרות שעודכנו בהצלחה (לדוגמה, רשת), ובכך יבודד תחומי כשל.

נהל באופן מרכזי תיקון חוצה חשבונות עם לוחות זמנים שונים עבור סביבות ייצור וסביבות שאינן ייצור.

→השתמש ב-AWS Systems Manager Patch Manager עם baselines תיקון מותאמים אישית, חלונות תחזוקה נפרדים לכל סביבה, ו-Systems Manager Explorer לדיווח תאימות מרכזי.

למה: תומך באופן מובנה בכל הדרישות: הגדרות תיקון מותאמות אישית, תזמון גמיש באמצעות חלונות תחזוקה, ונראות חוצה חשבונות באמצעות Explorer.

הצג תצוגה מקדימה של שינויי תשתית בכל חשבונות היעד לפני ביצוע עדכון CloudFormation StackSet.

→צור ובדוק סט שינויים (change set) של CloudFormation עבור פעולת ה-StackSet לפני הביצוע.

למה: Change sets הם המנגנון המובנה של CloudFormation לצפייה מקדימה בשינויי המשאבים המדויקים (הוספה, שינוי, מחיקה) שעדכון יבצע.

וודא ש-CloudFormation ממתין שסקריפט UserData של מופע EC2 יושלם בהצלחה לפני שממשיך ביצירת הערימה.

→הוסף `CreationPolicy` עם `ResourceSignal` למשאב מופע ה-EC2. קרא לסקריפט העזר `cfn-signal` מתוך UserData עם השלמה מוצלחת.

למה: זהו מנגנון ה-CloudFormation המובנה לתיאום עם סקריפטי תצורה על משאב. אי-איתות בתוך זמן התפוגה מפעיל אוטומטית שחזור ערימה.

זיהוי מתי שינויים ידניים, מחוץ לתחום, גורמים למשאבים פרוסים להיות שונים מהגדרת תבנית ה-CloudFormation שלהם.

→הפעל זיהוי סחף (drift detection) של CloudFormation על הערימה באופן תקופתי. לזיהוי מתמשך, השתמש בכלל AWS Config `cloudformation-stack-drift-detection-check`.

למה: זיהוי סחף הוא התכונה המובנית להשוואת תבנית של ערימה למצבם בפועל של המשאבים שלה. שימוש בכלל Config מאפשר אוטומציה של בדיקה זו.

הגן על משאבים בעלי מצב (stateful) (לדוגמה, דלי S3 או מסד נתונים RDS) מפני מחיקה או החלפה בשוגג באמצעות פעולות ערימת CloudFormation.

→על המשאב, הגדר `DeletionPolicy: Retain` (או `Snapshot` עבור RDS). על הערימה, הפעל `TerminationProtection`. החל `StackPolicy` המונעת פעולות `Update:Replace` ו-`Update:Delete` על המשאב הקריטי.

למה: מספק הגנה מעמיקה: Termination Protection מונע מחיקת ערימה, DeletionPolicy משמר את המשאב אם הערימה נמחקת, ו-Stack Policy מונעת עדכונים הרסניים.

העבר CloudFormation StackSet ממודל תפקיד IAM מורכב ומנוהל עצמית למודל הרשאות פשוט יותר עבור ארגון AWS.

→עדכן את ה-StackSet להשתמש בהרשאות מנוהלות שירות.

למה: הרשאות מנוהלות שירות מנצלות גישה מהימנה של Organizations, מבטלות את הצורך ליצור ולנהל תפקידי IAM בכל חשבון יעד. הן גם מאפשרות פריסה אוטומטית לחשבונות חדשים שנוספו ליחידות ארגוניות ממוקדות.

משאב מותאם אישית של CloudFormation צריך לנהל משימה שלוקחת יותר מזמן הפסיקה של 15 דקות של פונקציית Lambda.

→הפעל מכונת מצבים של AWS Step Functions מפונקציית ה-Lambda של המשאב המותאם אישית. מכונת המצבים מטפלת במשימה ארוכת הטווח באמצעות מצבי Wait או תבנית Task Token ושולחת את התגובה בחזרה לכתובת ה-S3 presigned URL של CloudFormation.

למה: Step Functions נועדה לתזמר זרימות עבודה ארוכות טווח ורב-שלביות, ובכך לעקוף ביעילות את מגבלת זמן התפוגה של Lambda תוך שמירה על אינטגרציה עם CloudFormation.

אכיפת מדיניות מרכזית (לדוגמה, לכל דלי S3 חייבת להיות גרסאות) בכל יישום AWS CDK, ללא קשר לאופן שבו מפתחים מגדירים את המשאבים שלהם.

→צור CDK Aspect המיישם את הממשק `IAspect`. ה-Aspect מבקר בכל הקונסטרוקציות בעץ היישום, מוצא את כל קונסטרוקציות דלי S3, ומחיל את התצורה הנדרשת או מוסיף שגיאת אימות אם היא חסרה.

למה: Aspects הם התבנית הרשמית של CDK ליישום נושאים רוחביים ויישום אימותי מדיניות כקוד באופן מרכזי ללא שינוי קונסטרוקציות בודדות.

מנע מפעולות אוטומטיות, כמו תיקון דרך SSM Maintenance Windows, להתרחש במהלך תקופות זמן ספציפיות ומשתנות (לדוגמה, חסימה פיננסית רבעונית).

→השתמש ב-SSM Change Calendar כדי להגדיר אירועים המסמנים את תקופות החסימה כ"סגורות". קשר את Change Calendar לחלון התחזוקה.

למה: Change Calendar משמש כשער לאוטומציות. הוא חוסם אוטומטית ביצוע במהלך תקופות "סגורות" מבלי לדרוש שינויים ידניים בלוח הזמנים של Maintenance Window, מה שהופך אותו ליעיל ביותר לניהול תקופות חסימה דינמיות.

נהל באופן מרכזי את ההתקנה והגרסאות של חבילת תוכנה מותאמת אישית (לדוגמה, סוכן ניטור) על פני צי של מופעי EC2.

→ארז את התוכנה באמצעות SSM Distributor. השתמש ב-SSM State Manager כדי ליצור שיוך שמחיל את חבילת Distributor על כל המופעים הממוקדים.

למה: Distributor מנהל את מחזור חיי החבילה (כולל גרסאות). State Manager מבטיח שהמצב הרצוי (לדוגמה, "גרסה 1.2 של הסוכן מותקנת") נאכף באופן רציף, ומתקן אוטומטית סחף ומגדיר מופעים חדשים.

שחזור מאסון (DR) עם RPO נמוך (פחות מדקה) ו-RTO נמוך (פחות מ-5 דקות) עבור מסד נתונים Aurora ושכבת יישומים בין אזורים.

→השתמש ב-Aurora Global Database לשכפול מסד נתונים בתת-שנייה. עבור שכבת היישומים, השתמש ב-"warm standby" עם קבוצת Auto Scaling המוגדרת לקיבולת רצויה של 0, כדי שתתרחב אוטומטית בעת מעבר לגיבוי.

למה: Aurora Global Database מספק RPO בתת-שנייה ו-RTO קטן מדקה. שכבת היישומים "warm standby" חסכונית ועדיין עומדת ב-RTO מהיר.

הפחתת זמן התרחבות (scale-out) של קבוצת Auto Scaling עבור מופעים שיש להם זמני אתחול/הפעלה ארוכים.

→צור "AMI מוזהב" (golden AMI) מוכן מראש עם תלויות מותקנות. הגדר "warm pool" בקבוצת Auto Scaling כדי לשמור על מופעים מאותחלים מראש.

למה: Golden AMI ממזער את זמן האתחול. Warm pool ממזער את זמן ההשקה (start לעומת launch). יחד, הם מפחיתים באופן דרמטי את הזמן שנדרש למופע חדש להיות מוכן לשרת תעבורה.

שירות ECS מגדיל את מספר המשימות שלו, אך אינו יכול למקם משימות חדשות מכיוון שאשכול ה-EC2 הבסיסי חסר קיבולת.

→הפעל ECS Cluster Auto Scaling על ידי שיוך ספק קיבולת לקבוצת ה-Auto Scaling של EC2 ולאשכול ה-ECS.

למה: ספקי קיבולת מקשרים את הרחבת שירותי ECS להרחבת מופעי EC2. כאשר משימות נכשלות במיקום עקב חוסר במשאבי אשכול, ספק הקיבולת מרחיב אוטומטית את ה-EC2 ASG.

הרחב באופן דינמי צי של מופעי עובדים של EC2 בהתבסס על מספר ההודעות בתור SQS.

→השתמש במדיניות Auto Scaling של מעקב יעד המבוססת על המדד המותאם אישית: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (כלומר, צבר לכל מופע).

למה: זוהי התבנית המומלצת להרחבה מבוססת SQS. היא שומרת על מספיק עובדים כדי לעבד את הצבר בתוך זמן יעד, ומתרחבת ביעילות עם עומק התור.

צור snapshots עקביים ליישום (לא רק עקביים לקריסה) של כרכים של EBS עבור יישומים בעלי מצב.

→השתמש ב-AWS Backup עם תוכנית גיבוי. בתוכנית, השתמש ב-Systems Manager Run Command כדי להפעיל סקריפטים לפני ה-snapshot כדי להשקיט את היישום (או להפעיל VSS עבור Windows).

למה: AWS Backup מתזמר את כל התהליך. השקטת היישום (ריקון חוצצי קלט/פלט לדיסק) לפני ה-snapshot מבטיחה שלמות נתונים ומצב יישום שניתן לשחזר.

וודא שאירועים קריטיים מכלל EventBridge לא יאבדו כאשר שירות יעד (לדוגמה, Lambda) אינו זמין באופן זמני או נחנק (throttled).

→על יעד כלל ה-EventBridge, הגדר מדיניות ניסיון חוזר (Retry Policy) (לדוגמה, גיל מקסימלי של 24 שעות) ותור אותיות מתות (Dead-Letter Queue - DLQ) באמצעות תור SQS.

למה: מדיניות הניסיון החוזר מטפלת בכשלים זמניים באופן אוטומטי. ה-DLQ משמש כרשת ביטחון סופית, לוכד אירועים שמיצו את כל הניסיונות החוזרים כך שניתן יהיה לעבד אותם מחדש מאוחר יותר, ובכך למנוע אובדן נתונים.

הפעל התראות בזמן אמת על תבניות יומן ספציפיות וכלול מידע הקשרי (לדוגמה, שורות יומן סמוכות) בהתראה.

→השתמש ב-CloudWatch Logs subscription filter כדי להזרים אירועי יומן תואמים לפונקציית Lambda. פונקציית ה-Lambda מעצבת ושולחת התראה מפורטת (לדוגמה, ל-SNS או Chime).

למה: Subscription filters מספקים הזרמת אירועים בזמן אמת. Lambda מאפשרת לוגיקה מותאמת אישית לחילוץ ועיצוב הקשר, מה שפילטרים פשוטים של מדדים אינם יכולים לעשות.

זיהוי צווארי בקבוק של זמן אחזור ביישום מבוזר מבוסס מיקרו-שירותים.

→הפעל מעקב AWS X-Ray בנקודות כניסה (לדוגמה, API Gateway, ALB) ובמשאבי מחשוב (לדוגמה, Lambda, ECS). השתמש ב-X-Ray SDK עבור קריאות יורדות. נתח את מפת השירותים ואת עקבות המעקב.

למה: X-Ray הוא שירות AWS הייעודי למעקב מבוזר. מפת השירותים מציגה ויזואלית את שרשרת הקריאות ומדגישה שירותים עם זמן אחזור גבוה ושיעורי שגיאות.

צור התראה יחידה, ברמה גבוהה, המייצגת את הבריאות המשולבת של יישום רב-שכבתי כדי להפחית רעש התראות.

→צור התראות CloudWatch נפרדות עבור כל שכבה (לדוגמה, שיעור 5xx של ALB, מעבד יישום, חיבורי RDS). לאחר מכן, שלב אותן באמצעות התראת CloudWatch מורכבת עם לוגיקת OR.

למה: התראות מורכבות נועדו להפחית רעש התראות על ידי יצירת התראה לוגית אחת המבוססת על מצבן של מספר התראות בסיסיות.

נתח פטה-בייטים של יומנים עם שאילתות SQL מורכבות (כולל joins) ושמור אותם במשך שנים באופן חסכוני.

→הזרם יומנים ל-Amazon S3 דרך Kinesis Data Firehose. קטלג את הנתונים עם AWS Glue. בצע שאילתות עם Amazon Athena. השתמש במדיניות S3 Lifecycle כדי להעביר נתונים ל-Glacier/Deep Archive לשמירה לטווח ארוך.

למה: זוהי ארכיטקטורת אגם הנתונים הסטנדרטית ללא שרתים. Athena מספקת יכולות SQL חזקות על נתוני S3, ו-S3/Glacier מציעים את אחסון הטווח הארוך החסכוני ביותר.

נטר מדד עם תבניות מחזוריות צפויות (לדוגמה, עליות יומיות/שבועיות) והפעל התראה רק על סטיות אמיתיות מהתבנית.

→הגדר זיהוי חריגות (Anomaly Detection) ב-CloudWatch על המדד. צור אזעקה המופעלת כאשר ערך המדד יוצא מחוץ לטווח הצפוי של המודל.

למה: זיהוי חריגות משתמש בלמידת מכונה כדי ללמוד את התבניות הרגילות של המדד, ויוצר רצועת סף דינמית המתאימה את עצמה למחזורים. זה מפחית false positives מעליות צפויות ומשפר את יחס האות לרעש.

קבל נראות מקיפה לגבי מדדי CPU, זיכרון, דיסק ורשת ברמת קונטיינר עבור עומסי עבודה ב-EKS או ECS ללא התקנה וניהול של כלי צד שלישי.

→הפעל את Amazon CloudWatch Container Insights עבור אשכול ה-EKS/ECS.

למה: Container Insights הוא שירות מנוהל באופן מלא שאוסף, צובר וממחיש באופן אוטומטי מדדי ביצועים מפורטים עבור עומסי עבודה מקונטיינרים, ומספק נראות עמוקה עם תקורה תפעולית מינימלית.

נטר את זמינות וביצועי יישום הפונה לאינטרנט מנקודת מבט של משתמשי קצה, וזהה בעיות רשת ברמת ספק האינטרנט ובעיות רשת גיאוגרפיות.

→הפעל את Amazon CloudWatch Internet Monitor עבור היישום.

למה: Internet Monitor ממנפת נתוני רשת גלובליים של AWS כדי לספק נראות למצב האינטרנט המשפיע על משתמשי הקצה שלך, ובכך מסייעת לאבחן בעיות מחוץ לסביבת ה-AWS שלך.

מדוד את חווית המשתמש האמיתית של יישום אינטרנט על ידי איסוף זמני טעינת עמודים, שגיאות JavaScript ומדדי ביצועים אחרים בצד הלקוח.

→שלב את קטע קוד JavaScript של CloudWatch RUM (Real User Monitoring) ביישום האינטרנט.

למה: RUM הוא שירות מנוהל האוסף נתוני ביצועים ושגיאות בצד הלקוח ישירות מדפדפני המשתמשים, ומספק תובנה אמיתית לגבי חווית המשתמש האמיתית ללא בדיקות סינתטיות.

פלוט מדדי יישום מותאמים אישית מפונקציית AWS Lambda ברזולוציה גבוהה ועם ממדים, מבלי להוסיף את זמן ההשהיה והעלות של קריאות ישירות ל-API של CloudWatch.

→השתמש ב-CloudWatch Embedded Metric Format (EMF) על ידי כתיבת JSON מובנה במיוחד לפלט הסטנדרטי. ספריית לקוח יכולה לפשט זאת.

למה: CloudWatch Logs מחלץ באופן אוטומטי וא-סינכרוני מדדים מרשומות יומן EMF, ללא זמן השהיה נוסף בפונקציית Lambda והפחתת עלות על ידי הימנעות מקריאות API של PutMetricData.

תקן אוטומטית כרכים לא מוצפנים של EBS שזוהו על ידי AWS Config, תוך הבטחת עקביות נתונים במהלך התהליך.

→השתמש בתיקון אוטומטי של AWS Config עם מסמך אוטומציה של Systems Manager. ה-runbook עוצר את המופע, יוצר עותק מוצפן של הכרך, מחליף כרכים ומפעיל מחדש את המופע.

למה: אוטומציית SSM מספקת זרימת עבודה חזקה, רב-שלבית וניתנת לביקורת. עצירת המופע חיונית כדי להבטיח snapshot עקבי נתונים לפני יצירת העותק המוצפן.

הפעל ניסויי הנדסת כאוס מבוקרים (לדוגמה, הזרקת השהיית רשת) עם תנאי עצירה אוטומטיים כדי למנוע השפעה על הייצור.

→השתמש ב-AWS Fault Injection Simulator (FIS) עם תבנית ניסוי. הגדר תנאי עצירה המבוססים על אזעקות CloudWatch המנטרות מדדי יישום מרכזיים.

למה: FIS הוא שירות AWS הייעודי להנדסת כאוס, המספק אמצעי בטיחות (תנאי עצירה) וקטלוג של פעולות הזרקת תקלות מבוקרות.

ערימת CloudFormation תקועה במצב `UPDATE_ROLLBACK_FAILED` מכיוון שמשאב נמחק או השתנה במהלך עדכון כושל, מה שמונע שחזור נקי.

→השתמש בפעולת ה-API `ContinueUpdateRollback`, וציין את המזהה הלוגי של המשאב הבעייתי בפרמטר `ResourcesToSkip`.

למה: זהו הליך השחזור הסטנדרטי כדי לאלץ את השחזור להסתיים על ידי הנחיית CloudFormation להתעלם מהמשאב שהוא אינו יכול לנהל עוד, ובכך להחזיר את הערימה למצב יציב.

קבל התראות תוך דקות מאירועי אבטחה קריטיים, כגון כניסה לחשבון root, שינויי מדיניות IAM או שינויים בקבוצות אבטחה.

→צור כללי Amazon EventBridge התואמים לדפוסי אירועי ניהול ספציפיים של CloudTrail ונתב אותם לנושא SNS לצורך התראה.

למה: EventBridge מקבל אירועי ניהול CloudTrail כמעט בזמן אמת, ומספק את זמן ההשהיה הנמוך ביותר להתראות אבטחה מונחות אירועים בהשוואה לשיטות polling או שיטות מבוססות יומנים.

פונקציית Lambda בעלת תעבורה גבוהה נחנקת (throttled) וגם מרוקנת חיבורי מסד נתונים של RDS כאשר היא מתרחבת.

→בקש הגדלת מגבלת הרצה מקבילה של Lambda. הטמע את Amazon RDS Proxy בין פונקציות ה-Lambda למסד הנתונים של RDS.

למה: הגדלת מקביליות פותרת חניקה. RDS Proxy חיוני עבור יישומים ללא שרתים, מכיוון שהוא מאגד ומשתמש מחדש בחיבורי מסד נתונים, ומונע את העומס על מסד הנתונים ממספר רב של חיבורים זמניים.

הטמעת DNS failover אוטומטי בין אזורים והפעלת runbook שחזור אוטומטי עבור האזור הכושל.

→השתמש בניתוב כשל (failover routing) של Route 53 עם בדיקות תקינות קשורות. צור כלל EventBridge שלוכד את אירוע שינוי מצב בדיקת התקינות של Route 53 ומפעיל runbook אוטומציה של Systems Manager.

למה: ארכיטקטורה זו משלבת מעבר תעבורה אוטומטי (Route 53) עם תגובה אוטומטית לאירועים מונחית אירועים (EventBridge + SSM Automation) לתבנית חוסן מלאה.

מנע ממסד נתונים של RDS להיגמר מהאחסון ולגרום להשבתת יישומים.

→הפעל RDS Storage Autoscaling על ידי הגדרת סף אחסון מרבי. כבקרת משנה, צור אזעקת CloudWatch על מדד `FreeStorageSpace`.

למה: Storage Autoscaling היא תכונה פרואקטיבית ומנוהלת המגדילה אוטומטית את האחסון שהוקצה. אזעקת CloudWatch מספקת רשת ביטחון לניטור והתראה.

צריך לעבד מחדש אצווה של אירועים שקובצו באופן שגוי עקב באג זמני בצרכן.

→הגדר ארכיון EventBridge (EventBridge Archive) על אפיק האירועים מראש. לאחר תיקון הבאג, צור הפעלה חוזרת (Replay) כדי לשלוח מחדש אירועים מחלון הזמן הספציפי של האירוע.

למה: Archive ו-Replay היא תכונה מובנית של EventBridge לאחסון ועיבוד מחדש של אירועים היסטוריים, חיונית לשחזור מכשלי עיבוד זמניים.

אוטומציה של כל תהליך תגובה לאירועים: יצירת אירוע, מעורבות צוות הכוננות, פתיחת ערוץ צ'אט וביצוע runbook תיקון כאשר מופעלת אזעקה קריטית.

→צור תוכנית תגובה של SSM Incident Manager המגדירה את כל שלבי המעורבות והתיקון. הגדר את אזעקת CloudWatch להפעיל תוכנית תגובה זו כפעולתה.

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