נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן SAP-C02 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
הקמת סביבת AWS עם למעלה מ-100 חשבונות עם מנגנוני הגנה, רישום וזהות עקביים מהיום הראשון.
AWS Control Tower כאזור נחיתה. Account Factory מספק חשבונות; מנגנוני הגנה מחייבים + מומלצים מאוד אוכפים קווי בסיס; ארכיון יומנים מרכזי + חשבונות ביקורת נוצרים אוטומטית.
למה: Control Tower מקודד את תבנית הריבוי חשבונות המעוצבת היטב. בנייה מאפס באמצעות Organizations בלבד משחזרת את אותה אינסטלציה באופן ידני.
צורך להוסיף מנגנוני הגנה ומשאבים מותאמים אישית מעבר לברירות המחדל של Control Tower בכל החשבונות.
התאמות אישיות עבור AWS Control Tower (CfCT). Pipeline של תבניות CloudFormation + SCPs נפרסים באמצעות StackSets ליחידות ארגוניות (OUs).
למה: CfCT מרחיב את Control Tower מבלי לשבור את מחזור החיים שלו. כללי Config מותאמים אישית, קווי בסיס אבטחתיים, רשתות - הכל בבקרת גרסאות וניתן לשחזור.
אכיפת הצפנת S3 KMS + תיקון אוטומטי של דליים לא תואמים ב-300 חשבונות בפחות מ-15 דקות.
חבילת תאימות ארגונית של AWS Config באמצעות מנהל מואצל. כלל Config + מסמך SSM Automation לתיקון אוטומטי.
למה: חבילות תאימות פורסות כללי Config + תיקון בכל הארגון מחשבון אחד. גישות מבוססות Lambda לכל חשבון או SCP בלבד מפספסות גילוי בזמן אמת או תיקון.
יומני CloudTrail עמידים לשינויים בכל החשבונות נשמרים 7 שנים; רק צוות האבטחה יכול לקרוא.
Organization trail שמספק ל-S3 bucket בחשבון רישום ייעודי. Object Lock במצב Compliance עם שמירה של 7 שנים. SCP מגביל גישת bucket לתפקידי IAM של אבטחה.
למה: Object Lock במצב Compliance חוסם מחיקה גם על ידי root. Org trail אוסף מכל החשבונות באופן אוטומטי. חשבון רישום ייעודי מבודד את רדיוס הפיצוץ.
איחוד (Federate) של 150 חשבונות ל-AD הארגוני באמצעות SAML; הקצאת הרשאות לפי קבוצת AD.
IAM Identity Center עם IdP חיצוני של SAML 2.0. סטים של הרשאות ממופים לקבוצות AD באמצעות הקצאת SCIM. הקצאות חשבון באמצעות קבוצות.
למה: Identity Center מרכז את האיחוד בכל חשבונות הארגון. סטים של הרשאות ניתנים לשימוש חוזר בין חשבונות; SCIM שומר על מצב המשתמש/קבוצה מסונכרן.
הענקת גישה למשאבים המתויגים עם מרכז העלות של המשתמש, עם יכולת הרחבה לאלפי משתמשים.
בקרת גישה מבוססת תכונות (ABAC) ב-Identity Center. העברת תכונות AD באמצעות SAML; סטים של הרשאות מפנים ל-`aws:PrincipalTag/CostCenter` מול `aws:ResourceTag/CostCenter`.
למה: ABAC מתרחב ללא שינויי מדיניות לכל משתמש. הוספת מרכז עלות חדש היא רק תג - ללא שכתוב IAM.
חשבון CI/CD מקבל על עצמו תפקיד פריסה ב-50 חשבונות עומס עבודה כדי להריץ CloudFormation.
תפקיד IAM לכל חשבון עומס עבודה עם מדיניות אמון המאפשרת את ישות חשבון ה-CI/CD. CI/CD מקבל על עצמו באמצעות STS AssumeRole. השתמש במזהה חיצוני אם כלי צד שלישי יוזם.
למה: מזהה חיצוני מונע את בעיית הנציג המבולבל. שרשור תפקידים מגביל את משך הסשן לשעה אחת גם אם התפקיד מאפשר יותר.
צוות הרשת המרכזי הבעלים של ה-VPC; 30 חשבונות "חישורים" פורסים עומסי עבודה לתת-רשתות משותפות.
AWS RAM משתף תת-רשתות לחשבונות משתתפים. המשתתפים משיקים משאבים מבלי להיות הבעלים של ה-VPC; הצוות המרכזי שומר על שליטה בטבלת ניתוב + NAT.
למה: VPC-ים משותפים מבטלים התפשטות VPC-ים לכל חשבון + שכפול IPAM. המשתתפים אינם יכולים למחוק את ה-VPC או לשנות ניתוב.
חיבור VPC-ים על פני 5 אזורים + סביבה מקומית עם ניתוב דטרמיניסטי ובדיקה מרכזית.
Transit Gateway בכל אזור. TGW peering לתקשורת בין-אזורית. Inspection VPC עם מכשירים נגישים דרך טבלאות ניתוב של TGW.
למה: TGW peering מונע רשת מלאה של VPN/peering בין-אזורי. טבלאות ניתוב לכל חיבור מאפשרות לאבטחה לבדוק זרימות ספציפיות מבלי לשבור אחרות.
בניית רשת פרטית גלובלית על פני אזורים + אתרי סניפים עם ניתוב מונחה מדיניות - מעבר ל-TGW peering.
AWS Cloud WAN. מדיניות רשת ליבה ב-JSON מגדירה באופן הצהרתי סגמנטים, אזורים, חיבורים ושיתוף.
למה: Cloud WAN מחליף עיצוב TGW מסוג "hub-of-hubs" עם עמוד שדרה גלובלי מנוהל יחיד. סגמנטים מספקים בידוד לוגי בין אזורים.
מרכז נתונים מקומי זקוק לקישור של 10 Gbps ל-AWS עם עמידות לכשלים בקישור וללא חשיפה לאינטרנט.
שני חיבורי Direct Connect במיקומי DX נפרדים. כל אחד עם VIF פרטי שמסתיים ב-Direct Connect Gateway → TGW. מעבר כשלים (BGP failover) בין חיבורים.
למה: Direct Connect יחיד הוא נקודת כשל בודדת. מיקומי DX שונים מגנים מפני הפסקות שירות באתר כולו. DX Gateway מאפשר ל-VIF אחד להגיע למספר אזורים/VPC-ים.
קישור Direct Connect כראשי; צורך במעבר כשלים אוטומטי של VPN.
VPN Site-to-Site מחובר לאותו TGW כמו שער ה-DX. AWS מעדיף נתיבי DX BGP; VPN משתלט כאשר DX BGP נסוג.
למה: העדפת נתיב BGP הופכת את מעבר הכשלים לאוטומטי. VPN שהוגדר מראש מונע עיכוב בהקצאה במהלך ההשבתה.
הרגולטור דורש הצפנת שכבה 2 בין סביבה מקומית ל-AWS דרך Direct Connect.
Direct Connect עם MACsec על חיבור ייעודי של 10 Gbps או 100 Gbps. מפתח משותף מוגדר בשני הקצוות.
למה: IPsec פועל בשכבה 3; MACsec מצפין בשכבה 2 בקצב קו, ועונה לדרישות רגולטורים המחייבים הצפנת קישור פיזי.
תעבורת מזרח-מערב בין VPC-ים חייבת לעבור בדיקה עם שמירת מצב (stateful inspection).
Centralized inspection VPC עם AWS Network Firewall. טבלאות ניתוב של TGW מכוונות תעבורה חוצת VPC-ים דרך ה-firewall VPC לפני הגעה ליעד.
למה: Network Firewall הוא מנוע כללי Suricata מנוהל לבדיקה עם שמירת מצב. ריכוזיות מונעת התפשטות Firewall לכל VPC.
אכיפת תצורת WAF + Network Firewall בסיסית בכל חשבון בארגון באופן אוטומטי.
AWS Firewall Manager עם מנהל מואצל. מדיניות עבור WAF, Shield Advanced, Network Firewall, קבוצות אבטחה מיושמות בכל הארגון.
למה: Firewall Manager מצרף אוטומטית מדיניות למשאבים חדשים. בלעדיו, כל חשבון סוטה מהבסיס ככל שנוספים חשבונות.
ריכוז ממצאי Security Hub מ-100+ חשבונות בחלון ניהול אחד.
מנהל מואצל של Security Hub. אזור צבירה אוסף ממצאים מכל חשבונות החברים + כל האזורים המופעלים לקונסולה אחת.
למה: ללא אגרגציה, הממצאים נשארים לכל חשבון/אזור. מנהל מואצל מונע שימוש בחשבון הניהול עבור פעולות אבטחה.
הפעלת GuardDuty בכל הארגון עם ניטור מרכזי ונראות חיוב לכל חשבון.
GuardDuty עם מנהל מואצל. הפעלה אוטומטית בחשבונות חדשים באמצעות האינטגרציה הארגונית. ממצאים מצטברים לחשבון המנהל.
למה: הפעלה אוטומטית סוגרת את הפער בחשבונות חדשים שיווצרו, שאחרת לא ינוטרו.
גילוי מתמיד של PII בכל דלי S3 ב-200 חשבונות.
Macie עם מנהל מואצל. הפעלה אוטומטית בכל הארגון. ממצאים זורמים ל-Security Hub לבדיקה מאוחדת.
למה: Macie אינו יכול לקרוא בין חשבונות ללא הגדרה מפורשת. תצורת רמת הארגון מבטיחה שכל דלי נכלל.
חקירת ממצא GuardDuty על ידי קורלציה של CloudTrail + VPC Flow Logs בין חשבונות.
מנהל מואצל של Amazon Detective בחשבון אבטחה ייעודי. חשבונות חברים תורמים לגרף ההתנהגות.
למה: Detective בונה אוטומטית את גרף ההתנהגות מ-VPC Flow Logs, CloudTrail, GuardDuty. מנהל מואצל (לא ניהול) עוקב אחר המלצות AWS.
זיהוי מתי כל משאב בארגון משותף עם חשבון חיצוני.
IAM Access Analyzer עם הארגון כאזור אמון, מואצל לחשבון אבטחה. ממצאים על גישה חוצת חשבונות ב-S3, תפקידי IAM, מפתחות KMS, Lambda, SQS, Secrets.
למה: Access Analyzer משתמש באימות פורמלי, לא בהתאמת תבניות. אזור אמון ברמת הארגון מתייחס לחשבונות אחים כנאמנים.
מקסום ניצול Savings Plan על פני 50 חשבונות עם דפוסי עומס עבודה לא תואמים.
חיוב מאוחד ב-Organizations עם Savings Plans + RI sharing מופעל. תוכניות שנרכשו בחשבון המשלם משותפות לכל הארגון.
למה: שיתוף מאחד שימוש כך שקיבולת בלתי מנוצלת בחשבון אחד מקזזת דרישה באחר. השבת שיתוף רק לבידוד הקצאת עלויות.
אפשר לצוותי אפליקציות שירות עצמי של תשתית מאושרת (VPCs, RDS) ללא הרשאות מנהל IAM.
פורטפוליו של AWS Service Catalog. מוצרי CloudFormation מאושרים מראש עם אילוצים. שתף פורטפוליו בין חשבונות באמצעות Organizations.
למה: מספק שירות עצמי עם מנגנוני הגנה. מדיניות אילוצים מסתירה מורכבות (סוגי מופעים, תגים) בעוד מוצרים נושאים את היקף ה-IAM להשקה.
אכיפת תגי `CostCenter` ו-`Environment` מחייבים באופן עקבי בכל הארגון.
מדיניות תגים של Organizations מצורפת ליחידות ארגוניות (OUs). הגדר ערכים מותרים + רישיות. שלב עם כלל Config `required-tags` לאכיפה.
למה: מדיניות תגים מאמתת; כללי Config מזהים אי-תאימות. SCPs יכולים למנוע יצירת משאבים חסרי תגים.
מניעת פעולות משתמש root בחשבונות חברים (דרישת תאימות).
SCP מונע כל פעולה כאשר `aws:PrincipalArn` תואם `arn:aws:iam::*:root`.
למה: SCPs חלים גם על root. IAM אינו יכול למנוע root. אין צורך בפעולות root למעט שחזור חשבון.
אכיפת תוכניות AWS Backup בכל החשבונות עם שמירה עקבית.
מדיניות גיבוי של Organizations מצורפת ליחידות ארגוניות (OUs). הגדר תוכניות + קריטריוני בחירה; החל אוטומטית על משאבים בטווח.
למה: שכפול תוכנית Backup לכל חשבון מוביל לסחף. מדיניות ארגונית אוכפת מקור אמת אחד.
למעלה מ-100 VPC-ים, כל אחד עם NAT Gateway, מנפחים את העלות. רוצים נקודת יציאה אחת.
Centralized egress VPC עם NAT Gateway. VPC-ים "חישורים" מנתבים 0.0.0.0/0 → TGW → egress VPC → NAT.
למה: NAT אחד במקום 100 מקצץ עלויות באופן דרמטי. כללי העברת נתונים בין-אזוריים של TGW חלים, לכן יש לתכנן בקפידה עבור תעבורה בין-אזורית.
EC2 ב-VPC צריך לפתור שמות מארחים מקומיים; סביבה מקומית חייבת לפתור DNS פרטי של VPC.
נקודות קצה נכנסות (inbound) ויוצאות (outbound) של Route 53 Resolver. כללי העברה שולחים שאילתות `corp.local` ל-on-prem; DNS מקומי מעביר `*.compute.internal` לנקודת הקצה הנכנסת.
למה: נקודות קצה של Resolver הן ENIs זמינים מאוד בשני אזורי זמינות. העברה מותנית מעניקה פתרון דו-כיווני מבלי לחשוף DNS לאינטרנט.
שירותים פנימיים זקוקים ל-DNS שניתן לפתור ממספר VPC-ים על פני חשבונות.
אזור מארח פרטי (private hosted zone) של Route 53 משויך ל-VPCs ממספר חשבונות באמצעות שיוך VPC חוצה חשבונות.
למה: PHZ אחד ששותף באמצעות שיוך חוצה חשבונות עדיף על שכפולים לכל VPC שנוטים להיסחף.
עומסי עבודה של Windows זקוקים ל-AD מלא עם יחסי אמון (trust) ליער מקומי.
AWS Managed Microsoft AD. יצירת אמון יער דו-כיווני עם AD מקומי דרך DX/VPN.
למה: Managed AD הוא Microsoft AD אמיתי (DC-ים בשני AZ-ים, סכימה ניתנת להרחבה). AD Connector הוא רק proxy; Simple AD חסר תמיכה באמון.
אפליקציות ב-AWS צריכות לאמת מול AD מקומי קיים ללא שכפול זהויות.
AD Connector. פועל כ-proxy מ-VPC ל-AD מקומי דרך DX/VPN.
למה: שום נתוני ספרייה לא עוזבים את הסביבה המקומית; בקשות אימות עוברות דרך. ההשהיה תלויה בקישור.
עומס עבודה רגיש להשהיה חייב לרוץ במרכז נתונים ספציפי אך להיות מנוהל באמצעות AWS APIs.
AWS Outposts rack/server. אותם AWS APIs (EC2, EBS, ECS, EKS, RDS subset) רצים ב-on-prem. מתחבר לאזור הורה (parent Region).
למה: להשהיה מקומית של פחות ממילי-שנייה למערכות מקומיות או שמירת נתונים מקומית כאשר Local Zones אינם מכסים. אזור זמינות יחיד - חבר שני Outposts עבור HA.
הפחתת השהיה למשתמשי קצה במטרופולין רחוק מאזור ההורה (parent Region).
AWS Local Zones. פרוס מחשוב, אחסון קרוב למרכזי אוכלוסייה; מישור הנתונים מנותב בחזרה לאזור ההורה עבור מישור הבקרה.
למה: Local Zones מארחים EC2/EBS/RDS/ELB ליד ערים גדולות. זול יותר מ-Outposts כאשר בעלות מלאה על מרכז נתונים אינה נחוצה.
אפליקציה דורשת השהיה של מילי-שניות בודדות למשתמשי מובייל ב-5G.
AWS Wavelength Zones ברשתות 5G של ספקים. פרוס EC2/EBS בקצה הספק; תעבורה נשארת ברשת הספקית הסלולרית.
למה: מבטל לחלוטין את ה-hop דרך האינטרנט הציבורי עבור מקרי שימוש ב-5G כמו AR/VR, הסקה בזמן אמת, גיימינג.
מבקר תאימות זקוק לתצורה העדכנית של כל משאב בכל הארגון.
מצבר AWS Config בחשבון הביקורת, מוגדר לכל הארגון בכל האזורים.
למה: Config aggregator הוא התצוגה הארגונית לקריאה בלבד. מצברים אינם מפעילים את Config בחשבונות חברים - זה נפרד.
יומני CloudWatch מ-50 חשבונות צריכים לנחות בארכיון S3 אחד להכנסת SIEM.
Subscription filters בכל חשבון ← Kinesis Data Stream / Firehose חוצה חשבונות ← S3 בחשבון רישום.
למה: Subscription filters מאפשרים לקבוצות יומנים לדחוף בזמן אמת. Firehose מטפל באצווה (batching), דחיסה, וחלוקת S3.
יצירת דוחות ראיות עבור SOC 2, PCI, HIPAA באופן רציף בכל הארגון.
AWS Audit Manager. מסגרות מובנות מראש ממפות בקרות לראיות AWS (Config, CloudTrail, Security Hub). מנהל מואצל בחשבון אבטחה.
למה: Audit Manager אוסף אוטומטית ראיות לכל בקרה. חוסך מאות שעות של איסוף צילומי מסך ידני לכל מחזור ביקורת.
פריסת תפקיד IAM בסיסי לכל חשבון קיים + עתידי בארגון.
CloudFormation StackSets עם הרשאות מנוהלות שירות + פריסה אוטומטית בחשבונות חדשים. כוון לכל הארגון או ליחידות ארגוניות ספציפיות.
למה: Self-managed StackSets דורשים IAM בכל חשבון. Service-managed מנצלים הרשאות ארגוניות והם ברירת המחדל עבור Organizations.
לאחר חודשים של הפעלת StackSets, חושדים ששינויים ידניים גרמו לסחף.
יזימת זיהוי סחף (drift detection) ב-StackSet. סקירת תוצאות לכל מופע stack מבלי לשנות משאבים.
למה: זיהוי סחף משווה תצורת משאבים חיה לתבנית. פריסה מחדש של StackSets ל"תיקון" סחף עלולה לגרום לשינויים בלתי צפויים.
עומס עבודה משתנה וקופצני של מסד נתונים - צרכי הקיבולת משתנים פי 10 תוך דקות.
Aurora Serverless v2. הגדר ACU מינימלי/מקסימלי; Aurora מתרחב תוך שניות ללא הפסקות חיבור.
למה: v2 מתרחב על ידי הוספת קיבולת למופע הקיים - ללא מעבר כשלים. Aurora מסופק אינו יכול להתרחב במהירות זו; Serverless v1 מתרחב לאט יותר ומשהה חיבורים.
אפליקציה גלובלית עם RPO <1s ו-RTO <1min עבור מעבר כשלים של DB בין אזורים.
Aurora Global Database. שכפול מבוסס אחסון, השהיית שכפול טיפוסית <1s. קידום משני תוך שניות.
למה: Global DB שולח דפים, לא טרנזקציות - תת-שנייה בין אזורים. עותקים לקריאה בין אזורים באמצעות שכפול לוגי אינם יכולים להשתוות לכך.
שכפול מסד נתונים סביבת ייצור לבדיקה ללא תשלום עבור עותק מלא.
שיבוט Aurora. Copy-on-write - שיבוט ראשוני בחינם; רק דפים ששונו מחויבים.
למה: שיבוטים הם נקודתיים, מיידיים, מבודדים. Snapshot+restore לוקח שעות ומחייב אחסון מלא באופן מיידי.
שחזור משגיאה לוגית (DROP TABLE בייצור) תוך דקות, לא שעות.
Aurora MySQL Backtrack. מריץ אחורה את האשכול במקום לנקודת זמן קודמת ללא שחזור מגיבוי.
למה: Backtrack הוא במקום ומהיר. שחזורי PITR יוצרים אשכול חדש - איטי יותר ודורשים העברת אפליקציה.
ניתוב שאילתות דיווח למופעי קריאה ספציפיים עם זיכרון גדול יותר.
Aurora custom endpoints. הגדר נקודת קצה המצביעה על תת-קבוצה של קוראים (הגדולים יותר).
למה: נקודת קצה ברירת המחדל של הקוראים מפזרת באופן שווה בין כל הקוראים. נקודות קצה מותאמות אישית מחלקות את האשכול לפי סוג עומס העבודה.
טבלת DynamoDB חווה שיאי partition חמים המגבילים חלק מהקריאות/כתיבות.
מסופק עם auto-scaling + adaptive capacity (אוטומטי). עצב מחדש מפתח מחיצה אם מפתח יחיד הוא נקודת ההתחממות.
למה: Adaptive capacity מקצה מחדש תפוקה בין מחיצות ללא פעולה. אך אם מפתח אחד חם, רק עיצוב סכימה מחדש (מפתח מורכב, write sharding) יעזור.
תופעת לוואי בכל כתיבה ל-DynamoDB - דחיפה ל-OpenSearch לצורך אינדוקס חיפוש.
DynamoDB Streams + Lambda trigger. Lambda מבצע אצווה (batches) של רשומות stream וכותב ל-OpenSearch.
למה: Streams לוכדים שינויים ברמת הפריט למשך 24 שעות. מודל טריגר מקורי - Kinesis Data Streams adapter קיים לשמירה/אנליטיקה ארוכה יותר.
כתיבה דו-פאזית על פני מספר פריטי DynamoDB חייבת להיות אטומית.
TransactWriteItems / TransactGetItems. סמנטיקת ACID על פני עד 100 פריטים.
למה: טרנזקציות מקוריות מונעות את מורכבות ה-saga המבוזר. העלות היא פי 2 מהקיבולת הרגילה לכל פריט - השתמש רק כאשר נדרשת אטומיות.
העברת אשכול MongoDB באירוח עצמי לשירות מנוהל תוך שמירה על ה-API.
Amazon DocumentDB. API תואם MongoDB. השתמש ב-mongodump/mongorestore או DMS להעברה.
למה: DocumentDB תואם API ל-MongoDB 4.0/5.0 (רוב האופרטורים, לא כולם). ודא תאימות דרייבר/תכונות לפני התחייבות.
מנוע המלצות צריך לנווט בגרף חברתי של 100 מיליון צמתים.
Amazon Neptune. גרף תכונות (Gremlin) או RDF (SPARQL).
למה: מסד נתונים גרפי ייעודי. מודל יחסים ב-DynamoDB או RDS אפשרי אך ביצועי השאילתות יורדים עם עומק הקפיצה.
צי IoT פולט 10 מיליון נקודות נתונים של סדרות עיתיות לשנייה עם שמירה בתדירות מעורבת.
Amazon Timestream. אחסון בזיכרון (recent), אחסון מגנטי (historical) - טיפול שכבות אוטומטי.
למה: סדרות עיתיות ייעודיות - עלות הרחבה של DynamoDB/RDS גבוהה מדי בקצב זה. טיפול שכבות שמירה מובנה מפחית עלויות אחסון.
ספר חשבונות בנקאי זקוק לאימות קריפטוגרפי של כל שינוי רשומה.
Amazon QLDB. יומן (journal) בלתי ניתן לשינוי, ניתן לאימות קריפטוגרפי. השתמש בייצוא SHA-256 digest עבור הוכחות.
למה: QLDB הוא ספר חשבונות ייעודי. DynamoDB Streams נותנים היסטוריית שינויים אך ללא שרשור קריפטוגרפי מובנה.
עומס עבודה של ניתוח יומנים עם שיאים בלתי צפויים ותפעול ללא מגע יד אדם.
Amazon OpenSearch Serverless. הפרדת מחשוב/אחסון; מתרחב אוטומטית ל-OCUs.
למה: ללא קביעת גודל אשכול או ניהול shard. עבור עומסי עבודה צפויים ומתמשכים, דומיינים מסופקים זולים יותר.
אנליטיקה בקנה מידה של פטא-בייט עם מחשוב אלסטי ושיתוף נתונים בין צוותים.
צמתי Redshift RA3 עם אחסון מנוהל. שיתוף נתונים בין אשכולות (ללא העתקה).
למה: RA3 מפריד בין מחשוב לאחסון - הגדל כל אחד באופן עצמאי. שיתוף נתונים מבטל ETL בין אשכולות של צוותים.
אשכול Redshift קיים + S3 data lake - האם לבצע שאילתות S3 מ-Redshift, או להשתמש ב-Athena?
Redshift Spectrum כאשר נדרשות הצלבות (joins) בין טבלאות אשכול ונתוני S3. Athena כאשר יש צורך ב-ad-hoc serverless על S3 בלבד.
למה: Spectrum מריץ שאילתות S3 דרך מחשוב Redshift. Athena משלם לפי TB שנסרק. בחר לפי המקום בו נמצאים הנתונים הדומיננטיים.
צוותים שונים זקוקים לנראות שונה של שורות/עמודות בטבלאות Glue Catalog זהות.
AWS Lake Formation עם פילטרים ברמת שורה + ברמת עמודה + ברמת תא. הענק באמצעות תגי LF.
למה: מדיניות IAM/S3 אינה יכולה לבצע ברמת שורה. Lake Formation אוכף גישה עדינה באמצעות מטא-נתונים של Glue Catalog + צרכני Athena/Redshift Spectrum/EMR.
עבודת Glue יומית מעבדת נתונים מצטברים; אסור לעבד מחדש קבצים של אתמול.
Glue job bookmarks. עקוב אחר מפתחות S3 / שורות DB שעובדו; המשך מנקודת הבדיקה האחרונה המוצלחת.
למה: Bookmarks מונעים עיבוד כפול ללא מעקב מצב ידני. השבת עבור ריצות עיבוד מחדש מלאות.
בחירת Kafka מנוהל מול Kinesis Data Streams עבור הזרמת אירועים.
MSK כאשר קיימים לקוחות/אקוסיסטם של Kafka. Kinesis לאינטגרציה הדוקה עם AWS (טריגרים של Lambda, Firehose, KCL) ואפשרות serverless.
למה: שניהם מזרמים באופן עמיד עם יכולת הפעלה חוזרת. MSK שומר על API ואקוסיסטם של Kafka; Kinesis עולה פחות עבור זרמים קטנים ומשתלב באופן מקורי.
תפוקת Kafka משתנה; רצון לניהול אשכול ללא מגע יד אדם.
MSK Serverless. מתרחב אוטומטית למחיצות ותפוקה; תשלום לפי מחיצה + נתונים.
למה: ללא קביעת גודל ברוקר. עבור תפוקה גבוהה מתמשכת, MSK מסופק זול יותר.
חיבור SQS → פילטר → Step Functions ללא כתיבת Lambda מתווכת.
EventBridge Pipes. מקור ← פילטר אופציונלי ← העשרה אופציונלית ← יעד.
למה: מחליף Lambda טיפוסית כ"דבק". מפחית קוד, עלות ושטח תפעולי.
הפעלה חוזרת של אירועי השבוע שעבר דרך צרכן חדש ללא פליטה מחדש מהמקור.
ארכיון + הפעלה חוזרת של EventBridge. ארכיון לוכד אירועים תואמים; הפעל אותם מחדש ליעד מאוחר יותר.
למה: הפעלה חוזרת מובנית מונעת צורך במאגר אירועים נפרד. שימושי לשחזור תקלות וקליטת צרכנים חדשים.
מאות מפיקים פולטים אירועים; צרכנים זקוקים ל-bindings מטיפוסים.
EventBridge Schema Registry עם גילוי אוטומטי. יצירת bindings קוד מטיפוסים חזקים (Java, Python, TypeScript).
למה: גילוי לומד סכימות מאירועים נצפים. Bindings נותנים בטיחות בזמן קומפילציה.
אורקסטרציה קצרת זרימות עבודה בנפח גבוה (>100k/sec) המחויבת בתת-שנייה.
Step Functions Express workflows. חיוב לפי מילי-שנייה לביצוע; מקסימום 5 דקות.
למה: זרימות עבודה סטנדרטיות עמידות + היסטוריה מתועדת, מחויבות לכל מעבר מצב. Express מחליף נתיב ביקורת בעלות נמוכה יותר עבור זרימות קצרות.
עיבוד 10 מיליון אובייקטי S3 במקביל באמצעות Step Function.
מצב Distributed Map. ביצועי ילד מקבילים עד 10,000 במקביל; קורא מקור מ-S3 ישירות.
למה: Inline Map מוגבל ל-40 מקבילות. Distributed Map מתרחב למשימות בגודל S3 bucket מבלי להגיע למכסות שירות.
תור FIFO דורש >300 הודעות/שנייה.
SQS FIFO עם מצב תפוקה גבוה מופעל. עד 70k הודעות/שנייה לכל API לכל אזור; חלוקה לפי `MessageGroupId`.
למה: FIFO סטנדרטי מוגבל ל-300 הודעות/שנייה ללא אצווה. מצב תפוקה גבוה מחלק סדר לפי מזהה קבוצה.
מספר צרכנים, כל אחד זקוק לתפוקת קריאה מלאה באותו Kinesis stream.
Enhanced Fan-Out (EFO). כל צרכן מקבל צינור ייעודי של 2 MB/s/shard באמצעות HTTP/2 push.
למה: ברירת המחדל של סקר (polling) חולקת את מגבלת 2 MB/s/shard בין צרכנים. EFO מבטל את התחרות בעלות גבוהה יותר.
Firehose ל-S3; שאילתות data lake סורקות יותר מדי כי החלוקה היא לפי זמן קליטה, לא זמן אירוע.
חלוקה דינמית של Firehose. חלץ זמן אירוע / מזהה דייר מ-JSON; כתוב לקידומת S3 `year=YYYY/month=MM/tenant=X/`.
למה: גיזום מחיצות (partition pruning) של Athena/Spectrum על זמן אירוע מקצץ באופן דרמטי עלויות וזמני סריקה.
לקוח מובייל/ווב זקוק לעדכונים בזמן אמת ושליפת שדות סלקטיבית.
AWS AppSync (GraphQL) עם מנויים. מבוסס WebSocket.
למה: לקוחות GraphQL שולפים רק שדות מבוקשים ונרשמים לדלתאות. REST/HTTP API Gateway כופה over-fetch ו-polling.
API פנימי אסור שיהיה נגיש מהאינטרנט הציבורי.
נקודת קצה פרטית של API Gateway באמצעות interface VPC endpoint. מדיניות משאבים מגבילה ל-VPCs ספציפיים.
למה: APIs פרטיים נגישים רק מ-VPC + רשתות מחוברות. APIs ציבוריים דורשים WAF + אימות כדי להיות בטוחים.
נעילת מקור S3 כך שרק CloudFront יוכל לקרוא ממנו.
Origin Access Control (OAC). מחליף OAI מורש; תומך ב-SSE-KMS ובכל תכונות S3.
למה: OAI אינו תומך באובייקטי SSE-KMS. AWS ממליץ על OAC לכל הפצות חדשות.
הגבלת זמן גישה לסרטונים בתשלום ספציפיים ב-S3.
CloudFront signed URLs (לכל URL) או signed cookies (מספר URLs). קבוצת מפתחות מהימנה חותמת על בקשות.
למה: URLs S3 חתומים מראש עוקפים את שמירת המטמון של CloudFront. CloudFront signed URLs שומרים במטמון בקצה וגם מגבילים גישה.
טרנספורמציה קלה לבקשות צופים: שכתוב כותרת, הפניה מחדש, ניתוב A/B.
CloudFront Functions. JS, תת-מילי-שנייה, כל ה-POPs בקצה.
למה: Lambda@Edge הוא Node/Python מלא בקצה האזורי - כבד ויקר יותר. Functions זולים פי 10 למניפולציה פשוטה.
הפעלת עומסי עבודה מרובי דיירים שאינם מהימנים ב-EKS עם בידוד חזק.
בידוד לכל pod של EKS Fargate. כל pod רץ ב-micro-VM ייעודי.
למה: Managed node groups חולקים קרנל - הסלמת הרשאות עוברת בין דיירים. בידוד קרנל של Fargate הוא החזק ביותר ב-EKS.
השהיית auto-scaling של אשכול EKS איטית מדי; התפשטות סוגי מופעים של קבוצות צמתים.
Karpenter. Provisioner בוחר סוגי מופעים בזמן אמת על בסיס דרישות ה-pod הממתינות.
למה: Cluster Autoscaler מרחיב ASGs שהוגדרו מראש, איטי ומוגבל. Karpenter מרחיב EC2 שרירותיים תוך שניות עם גיוון.
pod של EKS זקוק ל-IAM עם הרשאות מינימליות (הימנע משיתוף תפקיד מופע צומת).
IAM Roles for Service Accounts (IRSA) באמצעות ספק OIDC. הוסף הערה ל-ServiceAccount עם ARN התפקיד.
למה: EKS Pod Identity הוא החלופה החדשה יותר - מודל אמון פשוט יותר. IRSA בוגר ועובד בין אזורים.
התחלת משימות ECS-on-EC2 אורכת 5-7 דקות במהלך scale-out - צורך בפחות מ-60 שניות.
ECS Capacity Provider עם יעד קנה מידה מנוהל ~80% ב-`CapacityProviderReservation`. שמור על חיץ סרק.
למה: חיץ שמור פירושו שמשימות חדשות נוחתות על קיבולת קיימת באופן מיידי בזמן ש-ASG משיק החלפות.
Lambda מופעל על ידי SQS אך רק 5% מההודעות תואמות - הפעלות מבוזבזות.
מיפוי מקור אירוע עם קריטריוני סינון. Lambda מופעל רק עבור הודעות תואמות.
למה: פילטר לפני Lambda מונע עלות לכל הפעלה עבור הודעות לא רלוונטיות. סינון נתמך ב-SQS, Kinesis, DynamoDB, MQ, Kafka.
אפליקציית ייצור זקוקה לנקודת קצה של LLM עם תקורה תפעולית נמוכה.
Amazon Bedrock עבור מודלי יסוד מנוהלים (Claude, Llama, Titan). SageMaker רק כאשר אתה צריך לארח מודלים מותאמים אישית או open-weights מכווננים היטב.
למה: Bedrock הוא API בלבד - ללא תשתית. SageMaker היא פלטפורמת ML מלאה - בחר כאשר אתה הבעלים של מחזור החיים של אימון/כוונון עדין.
בחירת AI מנוהל לראייה / NLP ללא אימון מודל.
Rekognition (תוויות תמונה/וידאו, פנים, מיתון תוכן). Comprehend (סנטימנט, ישויות, שפות, זיהוי PII). Translate. Polly. Transcribe.
למה: שירותי AI של AWS שהוכשרו מראש מדלגים על כל מחזור חיי ה-ML עבור משימות נפוצות. השתמש ב-SageMaker רק כאשר מוצר מדף אינו מתאים.
יישום ווב תומך באימייל/סיסמה + Google + Apple + SAML SSO ארגוני.
Cognito User Pool עם hosted UI. הגדר OIDC + SAML IdPs. האפליקציה מקבלת Cognito JWT.
למה: User Pool מאגד IdPs לאסימון אחד. Identity Pool רק מחליף אסימונים באישור AWS - לגישת AWS API, לא לאימות.
טבלאות גלובליות של DynamoDB עם כתיבות סימולטניות לאותו מפתח בשני אזורים.
הכותב האחרון מנצח לפי חותמת זמן. האפליקציה מתכננת כתיבות אידמפוטנטיות או מחלקת כתיבות לפי אזור.
למה: שכפול GT הוא מרובה מאסטרים אסינכרוני. פתרון קונפליקטים מבוסס חותמת זמן - אפליקציות חייבות לסבול עקביות בסופו של דבר.
צי EC2 מוגדש יתר על המידה בכל הארגון; צורך בהמלצות right-sizing אוטומטיות.
AWS Compute Optimizer מופעל ברמת הארגון. סקירת המלצות מול חלונות ניצול; ייצוא ל-S3 למעקב.
למה: Compute Optimizer משתמש ב-ML על מדדי CloudWatch. right-sizing ידני מפספס אותות של צורת עומס העבודה.
זיהוי קפיצות עלות בלתי צפויות תוך שעות, לא בסוף החודש.
AWS Cost Anomaly Detection. למידת מכונה מנטרת הוצאות לפי שירות / חשבון; מתריע באמצעות SNS / אימייל כאשר סף נחצה.
למה: תקציבים מופעלים על ספים מתוכננים. זיהוי חריגות תופס הפתעות (מפתח שנפרץ, משימת אימון שיצאה מכלל שליטה) ימים/שבועות מוקדם יותר.
כאשר חשבון מגיע ל-100% מהתקציב החודשי, עצור אוטומטית משאבים שאינם חיוניים.
פעולות AWS Budget. החלת מדיניות IAM מגבילה + הפעלת Lambda באמצעות SNS לעצירת EC2/RDS לא חיוניים.
למה: פעולות תקציבים עוברות ממצב "התראה בלבד" ל"אכיפה". שילוב עם Cost Anomaly Detection לזיהוי הוצאות לא מתוכננות.
נראות ארגונית מלאה להזדמנויות אופטימיזציית עלויות S3.
S3 Storage Lens עם מדדים מתקדמים + היקף ארגוני. חושף מועמדים לשכבות קרות, הזדמנויות לשכבות IT, העלאות מרובות חלקים נטושות.
למה: השכבה החינמית מכסה מדדים בסיסיים; השכבה המתקדמת מציגה שכפול, פעילות, המלצות אופטימיזציה. מרכז בחשבון ביקורת/אבטחה.
חשבון S3 ממשיך לגדול למרות פעולות מחיקה.
כלל מחזור חיים מבטל `incomplete multipart uploads` לאחר 7 ימים. בדוק עם `s3api list-multipart-uploads`.
למה: העלאות שנכשלו משאירות חלקים שמחויבים כאחסון אך אינם נראים ברשימת הקונסולה. דליפת עלויות נפוצה.
נתוני ארכיון קרים נגישים לכל היותר פעם ברבעון.
S3 Glacier Flexible Retrieval (שחזור תוך 1-12 שעות). עבור "מעולם לא נגיש" השתמש ב-Deep Archive (שחזור תוך 12 שעות, עלות נמוכה ביותר).
למה: Standard-IA שומר גישה של מילי-שניות; שכבות Glacier מחליפות זמן גישה בהפחתת עלות של כ-80-95%.
קיצוץ עלות יציאת NAT Gateway עבור תעבורת S3 + DynamoDB.
Gateway VPC endpoints עבור S3 + DynamoDB (חינם). ניתוב תעבורה דרך נקודת הקצה, עקיפת NAT.
למה: NAT מחויב לפי GB; gateway endpoints הם חינם. עבור שירותי AWS אחרים, interface endpoints מפחיתים אך אינם מבטלים עלות.
עומס עבודה עמוס בתקשורת בין אזורי זמינות; עלות העברת נתונים שולטת בחשבון.
מקם מיקרו-שירותים באותו AZ היכן שניתן. השתמש ב-VPC Lattice או service mesh עם ניתוב AZ-affinity.
למה: מעבר אזור זמינות עולה $0.01/GB לכל כיוון. תקשורת מיקרו-שירותים בקנה מידה גדול מצטברת. החלף קצת HA בעלות נמוכה יותר כאשר 99.95% מספיקים.
תעבורת יציאה לאינטרנט היא הפריט הגדול ביותר בחשבון.
קדמו הכל עם CloudFront. יציאת CloudFront לאינטרנט זולה יותר מיציאת EC2/ALB ישירה.
למה: תמחור יציאת CloudFront מדורג ונמוך משמעותית מיציאה אזורית. שמירת מטמון (Caching) מפחיתה את יציאת המקור עוד יותר.
בחירה בין Compute Savings Plan לבין EC2 Instance Savings Plan לבין Reserved Instances.
Compute SP: גמיש ביותר (כל אזור, משפחה, OS) - הנחה מעט נמוכה יותר. EC2 Instance SP: נעול למשפחה אזורית - הנחה עמוקה יותר. RI: מקרים נדירים הדורשים שמירת קיבולת.
למה: Compute SP מכסה Lambda + Fargate + EC2. RIs עולים על SPs רק כאשר שמירת קיבולת חשובה; ברוב המקרים SPs מנצחים.
צי אצווה חסר מצב רץ על Spot - שיעור ההפרעות גבוה מדי.
Spot Fleet עם אסטרטגיה ממוטבת קיבולת על פני סוגי מופעים רבים + AZs.
למה: אסטרטגיית המחיר הנמוך ביותר מתרכזת במאגר יחיד - הפרעה גבוהה. אסטרטגיה ממוטבת קיבולת בוחרת מאגרים עם קיבולת זמינה עמוקה ביותר.
הפחתת עלויות מחשוב בשכבת ווב חסרת מצב בכ-20% ללא שכתוב.
מעבר ל-Graviton (ARM) - `c7g`, `m7g`, Lambda ARM, Aurora Graviton. בדיקת תאימות עבור בינאריים מקומפלים.
למה: Graviton מציע ביצועים-מחיר טובים בכ-20% לרוב עומסי העבודה. Java/Python/Node "פשוט עובדים"; קוד מקורי עשוי לדרוש קומפילציה מחדש.
קיצוץ עלויות של שירות Fargate ארוך טווח אך סובלני להפרעות.
Fargate Spot באמצעות אסטרטגיית ספק קיבולת. ערבוב Spot + on-demand למשימות HA.
למה: Fargate Spot זול בכ-70%. משימות מקבלות אזהרה של 2 דקות לפני סיום - חבר עם ניקוז חינני.
עלות אחסון יומני CloudWatch גדלה מחודש לחודש.
הגדר שמירה לכל קבוצת יומנים (ברירת המחדל היא לנצח). לטווח ארוך, ייצא ל-S3 + מחק ב-CW. השתמש במחלקת גישה לא תדירה ליומנים.
למה: עלויות CW Logs $0.03/GB קליטה + אחסון לנצח. S3 Standard-IA ב-$0.0125/GB זול יותר לגישת ארכיון.
החלפת ניטור מקוטע במעקב אחיד (unified observability) על פני שירותים.
CloudWatch ServiceLens למפת שירותים; X-Ray לעקבות; CloudWatch Logs Insights ל-ad-hoc; Container Insights ל-ECS/EKS; RUM לדפדפן; Synthetics ל-canaries.
למה: ערימה מקורית של AWS מונעת סוכנים לכל מארח. שילוב עם OpenTelemetry SDK לניידות.
עקוב אחר בקשה על פני שירותים ב-5 חשבונות.
X-Ray cross-account observability. חשבונות מקור משתפים עקבות עם חשבון ניטור מרכזי באמצעות OAM.
למה: ללא OAM, עקבות מתפצלות לכל חשבון. אגרגציה חוצת חשבונות מרכזת את תצוגת נתיב הבקשה.
צפייה במדדים + יומנים + עקבות ממספר חשבונות בקונסולת CloudWatch אחת.
CloudWatch Observability Access Manager (OAM). חשבונות מקור מקשרים לחשבון ניטור באמצעות sink + link.
למה: OAM הוא בד האובסרבביליטי הקנוני מרובה החשבונות. מבטל דילוג בין קונסולות לכל חשבון.
איטיות באשכול Aurora - זיהוי ה-SQL המובילים לפי אירוע המתנה.
Performance Insights מופעל על האשכול. SQL מוביל לפי עומס + ניתוח המתנה ללא dump יומן שאילתות.
למה: PI דוגם אירועי המתנה עם תקורה נמוכה. מדדי CloudWatch אומרים לך שמשהו איטי, PI אומר לך מה.
זיהוי אוטומטי של חריגות ב-DynamoDB / RDS / Lambda / ECS ללא כתיבת ספי אזעקה.
Amazon DevOps Guru. זיהוי חריגות מבוסס ML על מדדי תפעול + אירועים מתואמים.
למה: ספים סטטיים מפספסים מצבים נדירים. DevOps Guru לומד קווי בסיס ומתריע על סטיות מהנורמלי.
עדכון 5,000 מופעי EC2 בלוח זמנים ללא סקריפטים לכל מופע.
SSM Patch Manager עם קווי בסיס לתיקונים + חלונות תחזוקה. מיקוד מבוסס תגים; אישור אוטומטי של תיקוני אבטחה לאחר N ימים.
למה: Patch Manager מרכז את כל מחזור חיי התיקונים. סקריפטים בניהול עצמי נוטים לסטות ומפספסים מופעים חדשים.
תיקון אוטומטי של כשלי כללי Config (למשל, SG פתוח) ללא אישור אנושי.
פעולת תיקון Config המפעילה מסמך SSM Automation. מובנה מראש `AWS-DisablePublicAccessForSecurityGroup` וכו'.
למה: Config מזהה; SSM Automation פועל. לולאה הדוקה יותר מ-SNS ← אדם ← טיקט.
Pipeline זהב של AMI/container-image חייב להיות ניתן לשחזור ועדכני בתיקונים.
EC2 Image Builder pipeline. AMI מקור ← מתכון (רכיבים) ← בדיקה ← הפצה לאזורים/חשבונות.
למה: מחליף סקריפטים אד-הוק של Packer במחזור חיים מנוהל. קביעת לוח זמנים לבנייה מחדש לרענון תיקונים חודשי.
סריקת CVE רציפה על פני EC2 + תמונות ECR + Lambda.
Amazon Inspector v2 עם הפעלה ארגונית מלאה. ממצאים זורמים ל-Security Hub.
למה: Inspector v2 מכסה תלויות EC2 + תמונות קונטיינר + Lambda בשירות אחד. התאמת CVE ידנית בלתי אפשרית בקנה מידה.
אימות שאפליקציה מרובת שכבות יכולה לעמוד ב-RTO של שעה / RPO של 15 דקות.
AWS Resilience Hub. הגדר מדיניות ← הערך אפליקציה ← המלצות + runbooks אוטומטיים.
למה: Resilience Hub מפורמל את דרישות RTO/RPO עם בדיקות קונקרטיות. runbooks ידניים של DR נוטים לסטות.
בדיקה ש-auto-scaling ו-failover עובדים תחת תקלות אמיתיות, לא כאלה שמשוערות.
AWS Fault Injection Service (FIS). ניסויים בתבניות - השמדת מופעים, הגבלת APIs, הזרקת השהיה. הרצה במהלך Game Days.
למה: הנדסת כאוס כשירות. כשל אמיתי חושף הנחות שבירות; קריאת runbooks לא עושה זאת.
מעבר כשלים מרובה אזורים - בדיקת מוכנות אוטומטית + פינוי אזורי.
Route 53 Application Recovery Controller. בדיקות מוכנות + בקרות ניתוב למעבר כשלים מבוסס תאים.
למה: בדיקות תקינות רגילות של Route 53 מעריכות נקודות קצה. ARC מוסיף מישורי בקרה אקטיבי/המתנה למעבר כשלים מפורש ומבוקר.
שדרוג גרסה ראשית של RDS עם יכולת חזרה אחורה (rollback).
פריסות RDS Blue/Green. הקמת שיבוט ירוק עם גרסה חדשה; הפעלת binlog מחדש; החלפה תוך פחות מדקה.
למה: שדרוג גרסה ראשית במקום הוא בלתי הפיך. Blue/Green שומר על ה-DB הישן פעיל עד להצלחת המעבר.
הפחתת רדיוס פיצוץ של פריסות כושלות עם חזרה אוטומטית (auto-rollback).
CodeDeploy עם תצורת Canary (למשל, `CodeDeployDefault.ECSCanary10Percent5Minutes`). אזעקת CloudWatch מפעילה חזרה אחורה.
למה: Canary מכיל שבירה ל-10% למשך 5 דקות. "הכל בבת אחת" מקסימום פיצוץ; גלגול מפזר אך ללא שער מבוסס תעבורה.
פונקציות Lambda שהוקצו להן יותר מדי זיכרון.
Compute Optimizer עבור Lambda. המלצות לטיפול בזיכרון מפרופילי הפעלה.
למה: מכונת המצבים AWS Lambda Power Tuning היא החלופה - Compute Optimizer הוא ללא מגע יד אדם.
יצירת מדיניות IAM של הרשאות מינימליות מפעילות CloudTrail שנצפתה.
יצירת מדיניות IAM Access Analyzer. מנתח CloudTrail עבור התפקיד; פולט מדיניות של הפעולות שנעשה בהן שימוש בלבד.
למה: עדיף על טחינה ידנית של `iam:Get*` וכו'. השתמש במדיניות שנוצרה כנקודת התחלה, ואז עיין.
חיבור נכשל מ-EC2 ל-RDS - גלה מדוע ללא לכידת חבילות.
VPC Reachability Analyzer. ניתוח סטטי של טבלאות ניתוב, SGs, NACLs, NAT, peering. מחזיר את החוסם.
למה: מהיר יותר מ-tcpdump. מזהה את התצורה הספציפית (איזה כלל SG, איזה NACL deny).
בדיקה אילו נתיבים מהאינטרנט יכולים להגיע למשאבים פנימיים.
VPC Network Access Analyzer. ביטויי טווח מתארים נתיבים אסורים (למשל, אינטרנט ← שכבת DB). מחזיר נתיבים תואמים.
למה: Reachability Analyzer הוא נקודה לנקודה; Network Access Analyzer הוא תאימות בטווח רחב.
ניצחונות מהירים בעלויות בכל הארגון.
בדיקות אופטימיזציית עלויות של Trusted Advisor (דורש תמיכת Business/Enterprise). ELBs סרק, EC2 בשימוש נמוך, EIPs לא בשימוש, ניצול RI.
למה: השכבה החינמית של TA מוגבלת; Business+ פותח את כל הבדיקות. תצוגת ארגון עם מנהל מואצל מראה ממצאים מצטברים.
הצפות חיבורי Lambda → RDS מרוקנות חיבורי DB.
RDS Proxy. איגום חיבורים בין Lambda ל-RDS/Aurora. מעבר כשלים מהיר יותר (הפחתה של כ-66%).
למה: מקביליות Lambda יוצרת חיבור אחד לכל הפעלה במקרה הגרוע ביותר. Proxy מרבה (multiplexes) למאגר קטן.
שיעור איבוד מטמון (cache miss rate) בתוכן "זנב ארוך" במקור גבוה מדי - המקור תחת עומס.
CloudFront Origin Shield באזור קרוב למקור. מבטל כפילויות של בקשות על פני קצוות לפני הגעה למקור.
למה: ללא Origin Shield כל POP מחמיץ באופן עצמאי למקור. Shield מפחית את שיעור פגיעות המקור בכ-70%.
Lift-and-shift של 200 שרתי on-prem ל-EC2 עם השבתה מינימלית.
AWS Application Migration Service (MGN). שכפול ברמת בלוקים רציפה; העברה לכל שרת תוך דקות.
למה: MGN הוא כלי ה-rehost המומלץ של AWS (החליף את SMS + CloudEndure). העברה לכל שרת מאפשרת הגירה מבוססת גלים.
העברת Oracle מקומי ל-Aurora PostgreSQL עם השבתה מינימלית.
Schema Conversion Tool (SCT) לשכתוב סכימה + פרוצדורות. AWS DMS לטעינה מלאה + CDC.
למה: SCT מטפל בקוד; DMS מטפל בנתונים. CDC שומר על סנכרון המקור עד למעבר.
גילוי כל מסדי הנתונים המקומיים והערכת מורכבות ההגירה.
AWS DMS Fleet Advisor. מלאי (Inventory) + הערכת ציים הטרוגניים בקנה מידה.
למה: Fleet Advisor מאחד גילוי + קביעת גודל לזרימת עבודה אחת לפני הפעלת עבודות DMS.
קטגורית 500 אפליקציות לאסטרטגיית הגירה.
מסגרת שבעת ה-Rs: Retire (השבתה), Retain (השאר בסביבה מקומית), Relocate (העברת VMware Cloud), Rehost (MGN), Replatform (RDS במקום DB בניהול עצמי), Repurchase (זרוק ו-SaaS), Refactor (מיקרו-שירותים).
למה: פורטפוליו גדול יותר מערבב את כל ה-7. מיפוי לכל אפליקציה מוקדם מונע חוב הגירה של "מידה אחת מתאימה לכולם".
בניית מלאי ההגירה עם תלויות לפני תחילת גלים.
AWS Application Discovery Service. ללא סוכן (vCenter scan) או מבוסס סוכן (לכל שרת). פולט מפת תלויות.
למה: ללא מיפוי תלויות, תכנון גלים מפספס צימודים הדוקים. Discovery חושף אותם אוטומטית.
מעקב אחר מאות הגירות שרת + DB בתהליך על פני MGN, DMS, ידני.
AWS Migration Hub כחלון ניהול יחיד. מאגד סטטוס מ-MGN, DMS, Refactor Spaces.
למה: קונסולות לכל כלי מפרקות סטטוס. Migration Hub מאחד ותומך בדיווח פורטפוליו.
העברת 100 TB מאתר מרוחק ללא רוחב פס WAN שמיש.
AWS Snowball Edge Storage Optimized. שלח את המכשיר, העתק מקומית, החזר ל-AWS. מספר מכשירים במקביל עבור >80 TB.
למה: Snowmobile (45 PB) מיועד לאקסה-בייט; Snowcone (8 TB) לקטן. Edge הוא סוס העבודה בקנה מידה של פטא-בייט.
שכפול נתונים רציף NFS מקומי → S3 עם מגבלות רוחב פס.
סוכן AWS DataSync. משימות מתוזמנות; הגבלת רוחב פס לכל משימה; מצב אימות לשלמות.
למה: DataSync בנוי במיוחד ומהיר פי 10 מ-rsync בניהול עצמי על פני WAN. Snowball הוא לא מקוון; DataSync הוא מקוון.
יישום מקומי מצפה ל-NFS/SMB אך הנתונים צריכים לנחות ב-S3.
File Gateway ב-Storage Gateway. מטמון מקומי + S3 backend; אובייקטים נגישים גם באמצעות S3 API.
למה: Volume Gateway חושף iSCSI; Tape Gateway מדמה VTL. File Gateway הוא גשר ה-NAS ל-S3.
חנות עתירת VMware רוצה קיבולת בצד AWS ללא שינוי כלי vSphere/NSX.
VMware Cloud on AWS. אותה ערימת vSphere על מארחי AWS חשופים. השתמש ב-HCX להגירה חיה.
למה: שומר על כלי תפעול. גשר לפני refactor. לאחר מכן, העבר בהדרגה לשירותי AWS מקוריים.
קונטיינריזציה של מונולית Java/.NET מדור קודם ללא שכתוב.
AWS App2Container CLI. בודק אפליקציה פועלת, מייצר ארטיפקטים של קונטיינר + מניפסטים של ECS/EKS.
למה: A2C לוכד תצורת זמן ריצה (env, ports, dependencies) לתמונה עובדת. קונטיינריזציה ידנית מפספסת תלויות לא ברורות.
מודרניזציה של COBOL mainframe - המרה למיקרו-שירותי Java.
שירות AWS Mainframe Modernization עם Blu Age (refactor) או Micro Focus (replatform). בחר בהתבסס על סבילות לאמולציית זמן ריצה.
למה: Refactor פותח דפוסי cloud-native; Replatform מהיר יותר אך מדמה את המיינפריים. שניהם מפחיתים את עלות רישיון המיינפריים.
פירוק מונולית במשך 18 חודשים ללא הקפאת פיתוח.
תבנית Strangler Fig. הצב API Gateway/ALB לפני המונולית; נתב נקודות קצה ספציפיות למיקרו-שירותים חדשים ככל שהם מופרדים.
למה: שכתובים "במפץ גדול" לרוב נכשלים. Strangler מפריד את המעבר לפי נתיב, ושומר על המונולית פונקציונלית במהלך המעבר.
רצון לחלץ מיקרו-שירותים באופן הדרגתי ללא בעלות על מישור הניתוב.
AWS Migration Hub Refactor Spaces. הפשטת אפליקציה/ניתוב/שירות מנוהלת על פני API Gateway + VPCs.
למה: חוסך כתיבת האינסטלציה של ה-strangler fig. ניתוב מובנה + קישוריות VPC לחילוץ הדרגתי.
PostgreSQL בניהול עצמי ב-EC2 → RDS עבור פעולות מנוהלות.
DMS למעבר עם CDC. השתמש ב-RDS Custom רק אם אתה זקוק לגישת OS או הרחבות ספציפיות לספק.
למה: RDS מטפל בגיבויים/תיקונים/HA. RDS Custom הוא פתרון חירום לצרכים מדור קודם אך מחזיר את עומס התפעול.
מעבר מ-RDS MySQL ל-Aurora MySQL עבור ביצועים + עלות.
Aurora read replica מ-RDS, ואז קדום. או DMS לזמן השבתה אפס כאשר הפרשי גרסאות חשובים.
למה: נתיב עותק לקריאה הוא הפשוט ביותר בתוך המנוע. DMS מטפל בהבדלי גרסאות ובהעברות הטרוגניות.
ארגון רוצה מימון הגירת AWS + מסגרת של שיטות עבודה מומלצות.
AWS Migration Acceleration Program (MAP). שלבים: Assess (MRA), Mobilize (שותף MAP + כלים), Migrate & Modernize.
למה: MAP פותח מימון ומתודולוגיה מובנית. דילוג על MAP מפספס את שניהם.
אומדן עלות לפני הגירה עבור הספונסר המנהל.
AWS Pricing Calculator (תצורה מתוכננת) + Migration Evaluator (מבוסס נתונים ממלאי מקומי).
למה: Pricing Calculator נותן תמחור "מה אם". Migration Evaluator קולט נתוני vSphere/Hyper-V כדי לחזות חיסכון בפועל.
השבתת שרתי SFTP באירוח עצמי; שותפי ספקים צריכים להמשיך להשתמש ב-SFTP.
AWS Transfer Family (SFTP/FTPS/FTP) המגובה על ידי S3 או EFS.
למה: שירות פרוטוקול מנוהל. משתמשים ממופים ל-IAM; נקודות קצה של VPC בלבד. מונע הפעלת שירותי SSH של EC2.
Lift-and-shift של שיתופי קבצים של Windows עם אינטגרציית AD.
Amazon FSx for Windows File Server. מצורף ל-AD; SMB; DataSync לסנכרון מקוון מ-on-prem; Snowball לכמויות גדולות.
למה: FSx for Windows הוא אזור הנחיתה המקורי ל-AD. EFS מיועד ללינוקס בלבד; S3 חסר סמנטיקת SMB.
העברת עומסי עבודה של NetApp ONTAP תוך שמירה על כל תכונות NetApp (snapshots, FlexClone).
Amazon FSx for NetApp ONTAP. APIs מקוריים של ONTAP; מרובה פרוטוקולים NFS+SMB; שכפול SnapMirror מ-on-prem.
למה: טעמי FSx אחרים אינם חושפים תכונות ספציפיות ל-ONTAP. Lift-and-shift NetApp ללא ארכיטקטורה מחדש של גיבויים/שכפול.
מעבר מבוסס DNS מסכן "נתקעים" של מטמון DNS.
מעבר מאחורי CloudFront / ALB / Global Accelerator. החלף backend מבלי לשנות DNS ציבורי.
למה: מטמונים מכבדים TTL אך לקוחות/חומות אש שומרים מטמון באגרסיביות. כתובת ציבורית יציבה מבודדת מנתקעים של DNS.
הגירת תעבורה הדרגתית מ-on-prem ל-AWS לבקרת סיכונים.
Route 53 weighted routing. התחל 1% ← AWS, הגבר בהדרגה. בדיקות תקינות למעבר כשלים אוטומטי.
למה: ניתוב משוקלל מאפשר הגירת בסגנון canary בשכבת ה-DNS. ARC מוסיף שערים מפורשים למעברים עם סיכון גבוה יותר.
מעקב אחר רישיונות BYOL של Windows / Oracle / SQL Server על פני עומסי עבודה שהועברו.
AWS License Manager. הגדר כללים; אכוף בהשקה; שתף באמצעות RAM בכל הארגון.
למה: אי-ציות ל-BYOL יקר. License Manager מונע פריסת יתר בשוגג.
לאחר ההגירה, מופעי RDS של פיתוח/בדיקה מוגדשים יתר על המידה למשך הלילה.
העבר פיתוח/בדיקה ל-Aurora Serverless v2 עם ACU מינימלי נמוך. Auto-scale down כאשר סרק.
למה: חוסך עלויות סרק ליליות ללא מורכבות תזמון מופעים.
הפעלת Kubernetes בסביבה מקומית עם אותם כלים כמו EKS במהלך הגירה.
EKS Anywhere על חומרת on-prem. אותן גרסאות Kubernetes + ECR + אינטגרציית AWS Outposts.
למה: מישור בקרה עקבי מפחית סחף מיומנויות מפעיל. הגירה ל-EKS מאוחר יותר היא העברת עומס עבודה, לא שכתוב כלים.