נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן SAA-C03 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
אפליקציית שלוש שכבות: web, app, DB. בסיס הנתונים חייב להיות בלתי נגיש מהאינטרנט בשום פנים ואופן.
תת-רשתות ציבוריות עבור שכבת ה-web (ALB). תת-רשתות פרטיות עבור שכבות ה-app וה-DB. קבוצת אבטחה של בסיס הנתונים מאפשרת תעבורה רק מקבוצת האבטחה של שכבת ה-app (לא מטווח CIDR).
למה: טבלאות ניתוב של תת-רשתות אוכפות נגישות; הפניות מקבוצת אבטחה לקבוצת אבטחה מקודדות הרשאה מינימלית בשכבת קבוצת האבטחה ושורדות שינויי IP.
מופע EC2 צריך לגשת ל-S3. יש להימנע מאישורי גישה מוטמעים.
תפקיד IAM מצורף באמצעות פרופיל מופע. ה-SDK מאחזר אישורי גישה זמניים מ-IMDSv2.
למה: מפתחות גישה ארוכי טווח על מופעים הם הסיבה מס׳ 1 לדליפות אישורים. תפקידים מסתובבים אוטומטית, לעולם אינם נשמרים.
חסימת מתקפות SSRF שמנסות לקרוא מטא-דאטה של מופעי EC2.
אכיפת IMDSv2 (`HttpTokens=required`) בהפעלת המופע. דחיית בקשות IMDSv1 לא מאומתות.
למה: IMDSv2 דורש אסימון סשן באמצעות PUT לפני שנקודת הקצה של המטא-דאטה מגיבה; מתקפות SSRF שמבצעות רק GETs נחסמות.
שירות A בחשבון A מפעיל Lambda בחשבון B. הרשאה מינימלית.
מדיניות מבוססת משאבים על ה-Lambda היעד, המעניקה `lambda:InvokeFunction` ל-principal של תפקיד חשבון A. הקורא מקבל את התפקיד שלו ומפעיל ישירות - אין צורך בשרשור תפקידים.
למה: מדיניות משאבים היא התבנית הפשוטה ביותר בין חשבונות עבור משאבים מונחי שירות (Lambda, S3, SNS, SQS, KMS).
חשבונות AWS אחרים צריכים להעלות ל-S3 bucket מרכזי.
מדיניות Bucket המעניקה `s3:PutObject` ל-principals של חשבונות חיצוניים. הוספת דרישת ACL של `bucket-owner-full-control` כדי שבעל ה-bucket ישמור על שליטה באובייקטים.
למה: ללא `bucket-owner-full-control` (או `BucketOwnerEnforced` Object Ownership), אובייקטים שהועלו בבעלות חשבון הכותב.
מניעת כל S3 bucket בארגון מלהיות ציבורי.
הפעלת S3 Block Public Access ברמת החשבון (ובארגונים דרך SCPs). עוקף ACLs ומדיניות ברמת ה-bucket.
למה: הגדרת רמת חשבון גוברת על הגדרות לכל bucket - הגנה מפני תצורת שגיאה מקרית.
מפתחים חייבים ליצור תפקידי IAM בעצמם אך אינם יכולים להעניק הרשאות מעבר לקבוצת הרשאות מקסימלית מוגדרת.
גבולות הרשאה (Permission boundaries) על ה-principal של המפתח. הרשאות אפקטיביות = מדיניות זהות ∩ גבול.
למה: SCPs חלים ברמת החשבון/OU; גבולות קובעים היקף ל-principals פרטניים. השתמש בגבולות עבור דפוסי ניהול מואצלים.
הגבלת יחידה ארגונית (OU) לאזורים ספציפיים לצורך עמידה בדרישות מיקום נתונים.
מדיניות בקרת שירות (SCP) בארגונים הדוחה כל פעולה שבה `aws:RequestedRegion` אינו ברשימה המותרת.
למה: SCPs הם המנגנון היחיד שיכול לדחות פעולות שהחשבון עצמו מתיר. IAM אינו יכול לדחות מה ששורש החשבון יכול להעניק.
כניסה יחידה (SSO) לכוח עבודה על פני חשבונות AWS רבים; שילוב עם IdP ארגוני.
AWS IAM Identity Center (לשעבר AWS SSO) עם פדרציית SAML/OIDC ל-IdP הארגוני. ערכות הרשאות ממפות לתפקידים בחשבונות חברים.
למה: Identity Center היא הזהות הקנונית של כוח עבודה מרובה חשבונות. Cognito מיועד למשתמשי קצה של יישומים, לא לעובדים.
בחירת Cognito User Pool לעומת Identity Pool.
User Pool = הרשמה / התחברות / הנפקת JWT למשתמשי אפליקציה. Identity Pool = החלפת אסימונים לאישורי AWS זמניים. רוב האפליקציות משתמשות בשניהם: User Pool מאמת, Identity Pool מאשר גישה ל-AWS.
הוספת שלב אימות מותאם אישית לכניסה ל-Cognito (לדוגמה: דומיין אימייל ברשימה לבנה).
טריגרי Lambda: Pre Sign-up, Pre Authentication, Define/Create/Verify Auth Challenge. אימות או דחייה ב-Lambda.
צורך בשליטה מלאה על סיבוב מפתחות, מחיקה ומסלול ביקורת לכל מפתח.
מפתח KMS בניהול לקוח (CMK). מפתחות בניהול AWS (`aws/<service>`) פשוטים יותר אך אינם מציעים בקרת מדיניות מפתחות או נראות לשימוש מפתח פרטני.
למה: CMKs מאפשרים לך לקבוע היקף גישה לכל מפתח ב-CloudTrail, להגדיר מדיניות מפתחות לשימוש חוצה חשבונות, ולהשבית/לתזמן מחיקה.
חשבון B צריך לפענח אובייקטים ב-S3 המוצפנים באמצעות CMK של חשבון A.
מדיניות מפתח ב-CMK מעניקה `kms:Decrypt` ל-principals של חשבון B. ה-IAM של חשבון B גם זקוק ל-`kms:Decrypt` על ה-ARN של המפתח. שני החצאים נדרשים.
למה: KMS חוצה חשבונות דורש אישור מפורש הן במדיניות המפתח והן בזהות ה-IAM של הקורא (בניגוד לרוב מדיניות המשאבים).
הצפנת נתונים ב-`us-east-1`; פענוח ב-`us-west-2` לאחר שכפול, ללא הצפנה מחדש.
מפתח KMS מרובה אזורים. ראשי באזור אחד, העתק באחר, שניהם עם אותו חומר מפתח ומזהה.
למה: מונע את ריקוד עטיפת הטקסט המוצפן מחדש לצורך מעבר לגיבוי או DR בין אזורים.
הצפנת אובייקטים גדולים ללא קריאות API של KMS לכל אובייקט שישלטו בעלות.
הצפנת מעטפה. KMS מייצר מפתח נתונים (קריאת API אחת); השתמש במפתח הנתונים כדי להצפין את המטען באופן מקומי; אחסן את מפתח הנתונים המוצפן לצד הטקסט המוצפן.
למה: KMS מוגבל קצב ומתומחר לפי בקשה. תבנית המעטפה היא הדרך הקנונית להצפנת נתונים > כמה קילובייטים.
בחירת Secrets Manager לעומת SSM Parameter Store SecureString.
אישורי בסיס נתונים עם סיבוב אוטומטי, שיתוף חוצה חשבונות, סודות גדולים ← Secrets Manager. דגלי תצורה, הגדרות אפליקציה, סודות פשוטים, עלות נמוכה ביותר ← SSM Parameter Store.
למה: ל-Secrets Manager יש פונקציות Lambda מובנות לסיבוב עבור RDS/Aurora/DocumentDB/Redshift; ל-Parameter Store אין סיבוב מקורי אך הוא חינם עבור שכבת Standard.
סיבוב אוטומטי של סיסמת RDS כל 30 יום.
Secrets Manager עם סיבוב מנוהל. תבנית Lambda מובנית מטפלת בסיבוב משתמש יחיד מול נקודת הקצה של RDS. אפליקציות מאחזרות את הסוד בזמן ההתחברות (נשמר במטמון) - אין צורך בפריסה מחדש של האפליקציה.
הפחתת מתקפת הצפה של HTTP בשכבה 7 מבלי לחסום עליות לגיטימיות.
כלל מבוסס קצב של AWS WAF (לדוגמה: 2000 בקשות / 5 דקות לכל IP) על ה-ALB או CloudFront. בשילוב עם קבוצות כללים מנוהלות עבור IPים ידועים כרעים.
למה: כללי קצב של WAF עוקבים אחרי כל IP מקור; חסימה אוטומטית כאשר חורג מהסף; שחרור לאחר החלון.
אפליקציה קריטית למשימה זקוקה להגנה מפני עלויות DDoS ותמיכת SRT 24×7.
AWS Shield Advanced ב-CloudFront / ALB / NLB / Global Accelerator. כולל הגנת עלויות (החזרים עבור הוצאות קנה מידה במהלך התקפה) + גישה לצוות התגובה של Shield.
למה: Shield Standard אוטומטי וחינם; Advanced מוסיף הגנות ו-SLA. CloudFront הוא תמיד הדלת הקדמית המומלצת.
בחירת קבוצת אבטחה לעומת NACL.
Stateful, מתחבר ל-ENI, מאפשר בלבד ← קבוצת אבטחה (ברירת מחדל). Stateless, ברמת תת-רשת, מאפשר + דחייה מפורשת ← NACL. השתמש ב-NACLs עבור כללי דחייה גורפים (חסימת טווחי IP); SGs לכל השאר.
למה: NACLs מעריכים כניסה ויציאה בנפרד. SGs מאפשרים אוטומטית תעבורת חזרה.
EC2 בתת-רשת פרטית חייב להגיע ל-S3/DynamoDB ללא עלות יציאה של NAT.
נקודת קצה של VPC gateway עבור S3 ו-DynamoDB. חינם, כניסת טבלת ניתוב, ללא NAT.
למה: נקודות קצה של Gateway מיועדות רק ל-S3/DynamoDB. חוסך חיובי עיבוד נתונים של NAT ושומר את התעבורה על עמוד השדרה של AWS.
תת-רשת פרטית חייבת להגיע ל-APIs של שירותי AWS (KMS, Secrets Manager, ECR וכו') באופן פרטי.
נקודת קצה של VPC interface (PrivateLink) לכל שירות. ENI ב-VPC שלך, מחויב לפי שעה + לפי GB.
למה: נקודות קצה של Interface עובדות כמעט עבור כל שירות AWS. השתמש כדי להסיר יציאת NAT עבור קריאות שירות.
ספק SaaS חושף את השירות שלו בתוך ה-VPC לחשבונות לקוחות באופן פרטי, ללא VPC peering או תחזוקת ניתוב לקוחות.
שירות נקודת קצה של AWS PrivateLink המגובה על ידי NLB. לקוחות יוצרים נקודות קצה של ממשק כדי לצרוך.
למה: אין חששות מחפיפת CIDR, אין עבודת Meshing של peering, חשיפה חד-כיוונית (הספק לא רואה תעבורת לקוחות).
חיבור 30+ VPCs בין חשבונות ולסביבה מקומית בטופולוגיית Hub-and-Spoke.
AWS Transit Gateway. חיבור יחיד לכל VPC; טבלאות ניתוב מפצלות תעבורה.
למה: חיבור Peer בטופולוגיית Full-mesh דורש N×(N-1)/2 חיבורים. TGW מתרחב ליניארית ותומך בחיבור חוצה חשבונות דרך RAM.
קישוריות היברידית הדורשת רוחב פס צפוי, חביון נמוך והצפנה.
Direct Connect עם Site-to-Site VPN מעל ה-DX (MACsec או IPsec). DX לבדו אינו מוצפן; VPN מעל DX הוא פרטי + מוצפן + עם תנודתיות נמוכה.
למה: VPN רגיל מעל האינטרנט זול אך בעל חביון משתנה. DX לבדו מהיר אך טקסט רגיל בשכבת הקישור.
זיהוי איומים רציף על פני VPC Flow Logs, DNS, CloudTrail, ביקורת EKS, אירועי נתוני S3.
Amazon GuardDuty. ברמת הארגון דרך מנהל מואצל של Organizations.
למה: זיהוי איומים מנוהל. ממצאים ל-Security Hub או EventBridge לאוטומציית תגובה.
גילוי וסיווג PII / PHI ב-S3 buckets.
Amazon Macie. גילוי נתונים רגישים מבוסס ML, בהיקף S3, משתלב עם Security Hub.
סריקת CVE רציפה עבור EC2, תמונות ECR, פונקציות Lambda.
Amazon Inspector v2. מגלה משאבים אוטומטית באמצעות Systems Manager Agent, סורק מול CVEs מפורסמים.
איחוד ממצאים מ-GuardDuty, Inspector, Macie, IAM Access Analyzer ללוח מחוונים אחד.
AWS Security Hub. CSPM עם AWS Foundational Security Best Practices ותקני CIS.
אכיפה שכל כרכי EBS מוצפנים; תיקון אוטומטי של משאבים לא תואמים.
כללי AWS Config (מנוהל `encrypted-volumes`) + Runbook של Systems Manager Automation לתיקון, המופעל באמצעות פעולת תיקון של Config.
יומן ביקורת יחיד ובלתי ניתן לשינוי על פני כל החשבונות בארגון.
נתיב ארגוני (Organization trail) עם אימות קבצי יומן מופעל, הנכתב ל-S3 bucket מרכזי עם מדיניות bucket המונעת מחיקה.
למה: נתיבים ארגוניים מופעלים אוטומטית בכל חשבונות החברים (נוכחיים ועתידיים). חשיפות אימות מוכיחות שהיומנים לא שונו.
מחלקות מרובות זקוקות לגישה מוגבלת לקידומות שונות ב-S3 bucket משותף.
S3 Access Points - אחד לכל מחלקה, כל אחד עם מדיניות גישה משלו ו(אופציונלית) הגבלת VPC.
למה: נקי יותר ממדיניות bucket מתפשטת; לנקודות גישה יש ARN ושמות DNS משלהן.
עומס עבודה של PCI DSS - בידוד קפדני מחשבונות שאינם PCI.
חשבון AWS ייעודי בתוך OU של Organizations עם SCPs המגבילים גישה לשירות / אזור. VPC נפרד, מפתחות KMS, תפקידי IAM. Network Firewall או GWLB לבדיקת יציאה.
למה: גבול חשבון הוא הבידוד החזק ביותר של רדיוס פיצוץ ב-AWS.
תעודת TLS ציבורית עבור `*.example.com` ב-ALB ו-CloudFront. חידוש אוטומטי.
תעודה ציבורית של AWS Certificate Manager (ACM) עם אימות DNS ב-Route 53. מתחדשת אוטומטית 60 יום לפני התפוגה.
למה: חינם לשימוש עם שירותים משולבי AWS. אימות אימייל עובד אך אימות DNS מועדף לאוטומציה.
בסיס נתונים RDS בסביבת ייצור עם מעבר לגיבוי תוך פחות מדקה.
פריסה מרובת אזורים של RDS (או אשכול בסיסי נתונים מרובי אזורים). שכפול סינכרוני לגיבוי; מעבר אוטומטי לגיבוי באמצעות החלפת נקודת קצה DNS.
למה: Multi-AZ מיועד ל-HA, לא להרחבת קריאות. Read replicas מיועדים להרחבת קריאות (ואסינכרוני; השהיה פוטנציאלית).
בחירת Aurora לעומת RDS עבור עומס עבודה חדש של MySQL/PostgreSQL.
Aurora עבור תפוקה גבוהה יותר, מעבר מהיר יותר, עד 15 עותקי קריאה (read replicas), Global Database, Serverless v2. RDS עבור מנועים ישנים יותר (MariaDB, Oracle, SQL Server) או פריסות פשוטות/זולות יותר.
למה: אחסון Aurora משותף בין עותקים (אין השהיית שכפול מהאחסון). מעבר לגיבוי < 30 שניות בדרך כלל.
בסיס נתונים רב-אזורי פעיל-פסיבי עם השהיית שכפול של < 1 שנייה ו-RTO של < 1 דקה.
Aurora Global Database. שכפול ברמת האחסון לעד 5 אזורים משניים; קידום אזור משני לראשי במקרה אסון.
למה: השכפול משתמש בתשתית ייעודית; השהיית מעבר בין אזורים היא בדרך כלל < 1 שנייה. Read replicas באזורים מרוחקים עבור קריאות מקומיות בחביון נמוך.
עומס בסיס נתונים משתנה / בלתי צפוי עם תקופות של חוסר פעילות.
Aurora Serverless v2. מתרחב במרווחים של 0.5 ACU; אירועי קנה מידה תת-שנייה; ללא השהיה מלאה אך מינימום נמוך מאוד.
למה: v2 שומר על החיבור פתוח במהלך אירועי קנה מידה (בניגוד ל-v1). תשלום לפי ACU-שנייה.
קריאות + כתיבות בודדות במילישניות ב-3+ אזורים, עם שכפול של Last-writer-wins.
DynamoDB Global Tables. שכפול מרובה פעילים עם פתרון קונפליקטים של Last-writer-wins.
למה: פעיל-פעיל בכל אזור; ללא מוביל. השתמש כאשר סבילות קונפליקטים ברמת היישום מקובלת.
שחזור טבלת DynamoDB לנקודה ספציפית ב-35 הימים האחרונים לאחר מחיקה בשוגג.
הפעל Point-in-Time Recovery (PITR). השחזור יוצר טבלה חדשה בשנייה הנבחרת.
ניתוב תעבורה לאזור הראשי; מעבר לגיבוי משני בעת כשל בבדיקת תקינות.
מדיניות ניתוב failover ב-Route 53. בדיקת תקינות פעילה בנקודת הקצה הראשית; רשומת גיבוי משרתת כאשר הראשי לא תקין.
למה: בדיקת תקינות בשכבת היישום (נתיב HTTP) תופסת כשלים חלקיים שבדיקות TCP מפספסות.
שליחת כל משתמש לאזור התקין בעל החביון הנמוך ביותר.
ניתוב מבוסס חביון ב-Route 53. בדיקת תקינות לכל נקודת קצה; Route 53 מחזיר את התשובה התקינה בעלת החביון הנמוך ביותר לכל שאילתה.
פריסת קנריות: שליחת 10% ל-v2, 90% ל-v1.
ניתוב משוקלל ב-Route 53. שתי רשומות באותו שם, יעדים שונים, משקלים 10 ו-90.
מופעי EC2 דורשים 3 דקות לאתחול; הרחבת קנה מידה החוצה איטית מדי בעת עליות תעבורה.
Warm pool של Auto Scaling. מופעים מאותחלים מראש נשמרים במצב עצור (זול יותר) ומוכנים להתחיל תוך שניות.
למה: הפעלה קרה + אתחול הם הצוואר בקבוק העיקרי. Warm pool מזיז את העבודה הזו מנתיב קריטי.
בעת הקטנת קנה מידה, רוקן עבודה בתהליך ושמור יומנים לפני שהמופע נסגר.
וו מחזור חיים של Auto Scaling ב-`Terminating:Wait`. הוו מפרסם ל-SNS/EventBridge; המטפל משלים את הריקון וקורא ל-`complete-lifecycle-action`.
הפחתת עלויות מחשוב על צי לא קריטי הסובל הפרעות.
ASG עם מדיניות מופעים מעורבים: קיבולת בסיס ב-On-Demand, קיבולת נוספת ב-Spot, מספר סוגי מופעים ואזורי זמינות לגיוון.
למה: גיוון על פני סוגי מופעים מפחית את סיכון ההפרעה של Spot לעומת מאגר יחיד.
בחירת ALB לעומת NLB.
HTTP/HTTPS, ניתוב נתיב/מארח, אינטגרציית WAF, אימות OIDC ← ALB. TCP/UDP/TLS בקנה מידה קיצוני, IP סטטי לכל אזור זמינות, חביון נמוך ביותר, שמירה על IP מקור של לקוח ← NLB.
הכנסת צי של מכשיר אבטחה של צד שלישי בקו לבדיקת תעבורה בין VPCs.
Gateway Load Balancer (GWLB) עם צי מכשירים כיעדים. תעבורה מוצפנת באמצעות GENEVE; הכנסה שקופה באמצעות ניתוב.
הודעות "רעילות" ממשיכות להיכשל במטפלים ונכנסות מחדש לתור.
SQS Dead-Letter Queue. הגדר `maxReceiveCount` בתור המקור; הודעות החורגות מהספירה עוברות ל-DLQ לבדיקה.
סדר קפדני ועיבוד "בדיוק פעם אחת" לכל קבוצת הודעות.
תור SQS FIFO עם deduplication מבוסס תוכן או `MessageDeduplicationId` מפורש. השתמש ב-`MessageGroupId` עבור קבוצות מסודרות מקבילות.
למה: SQS רגיל הוא "לפחות פעם אחת" ללא הבטחת סדר. ל-FIFO תפוקה נמוכה יותר אלא אם משתמשים במצב תפוקה גבוהה.
Lambda אסינכרוני נכשל ב-timeout במורד הזרם - לכידת אירועים כושלים לצורך הפעלה מחדש.
Lambda Destinations: הגדר יעד כשל כ-SQS / SNS / EventBridge / Lambda אחר. יעדי הצלחה נתמכים גם כן.
למה: נקי יותר מ-DLQ על הפונקציה: יעדים מקבלים את האירוע המלא + מטען התגובה; DLQs מקבלים רק את אירוע הטריגר.
זרימת עבודה מרובת שלבים דורשת ניסיון חוזר לכל משימה עם השהיה אקספוננציאלית וטיפול בשגיאות.
זרימת עבודה סטנדרטית של AWS Step Functions. בלוק `Retry` עם `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. בלוק `Catch` מנתב שגיאות ספציפיות למצב שחזור.
Origin של CloudFront (S3 או ALB) נכשל - חזרה ל-origin משני ללא שינויי DNS.
קבוצת origin של CloudFront עם ראשי + משני. הגדר קריטריוני מעבר לגיבוי (קודי 4xx/5xx). CloudFront מנסה שוב מול המשני.
ריכוז גיבויים על פני EBS, RDS, DynamoDB, EFS, FSx עם מדיניות שמירה אחת.
AWS Backup עם תוכניות גיבוי + בחירת משאבים לפי תגית. העתקה חוצה חשבונות / חוצה אזורים נתמכת. Vault Lock עבור אי-שינוי תאימות.
גיבויים עמידים בפני תוכנות כופר: אפילו מנהל מערכת אינו יכול למחוק לפני תקופת השמירה.
AWS Backup Vault Lock במצב תאימות. אכיפת WORM; אפילו משתמש root לא יכול לקצר את תקופת השמירה.
בחירת תבנית DR לפי דרישת RPO/RTO.
גיבוי ושחזור: RPO שעות, RTO שעות, הכי זול. Pilot Light: RPO דקות, RTO עשרות דקות. Warm Standby: RPO שניות, RTO דקות. Multi-Site Active-Active: RPO ~אפס, RTO שניות, היקר ביותר.
שכפול bucket קריטי בין אזורים עבור DR עם RPO של פחות מ-15 דקות.
S3 Cross-Region Replication (CRR) עם S3 Replication Time Control (RTC). 99.99% מהאובייקטים תוך 15 דקות.
למה: CRR רגיל הוא "best-effort". RTC מוסיף SLA + מדדי שכפול ב-CloudWatch.
הגנה על אובייקטי S3 מפני מחיקה בשוגג והחלפה על ידי תוכנות כופר.
הפעלת S3 Versioning + MFA Delete + Object Lock (מצב governance או compliance) על buckets קריטיים.
למה: Versioning שומר על החלפות/מחיקות; Object Lock חוסם מחיקה לפני תקופת השמירה; MFA Delete מוסיף גורם שני להסרה קבועה.
אפליקציה גלובלית זקוקה למעבר לגיבוי עם RTO אפס על פני שני אזורים.
Active-active על פני אזורים: Global Accelerator או ניתוב חביון של Route 53 לכניסה; DynamoDB Global Tables / Aurora Global Database לנתונים; שכפול בין אזורים לאחסוני אובייקטים.
תעבורת TCP/UDP עם תנודתיות נמוכה לאזור התקין הקרוב ביותר; IPים סטטיים ב-anycast.
AWS Global Accelerator. שני IPים ב-anycast; מנתב לנקודת הקצה הקרובה ביותר על גבי עמוד השדרה של AWS.
למה: טוב יותר מ-Route 53 latency עבור תעבורה שאינה HTTP. מעבר מהיר יותר לגיבוי (anycast) + הוספת IPים סטטיים לרשימה לבנה.
Lambda מעבד הזמנות מ-SQS - הודעה עלולה להימסר פעמיים.
אידמפוטנטיות: אחסון hash של בקשה ב-DynamoDB עם TTL; PUT-IfNotExists בכל ניסיון חוזר. או שימוש בתור FIFO עם deduplication.
פינוי פודים וולונטרי (ריקון צומת, cluster autoscaler) מוריד את כל עותקי הפריסה.
Kubernetes PodDisruptionBudget המציין `minAvailable` או `maxUnavailable`. האשכול מכבד זאת במהלך שיבושים וולונטריים.
בחירת סוג אחסון S3.
גישה תכופה ← Standard. דפוס גישה לא ידוע ← Intelligent-Tiering. גישה לא תכופה מעל 30 יום ← Standard-IA. אזור זמינות יחיד מקובל, לא תכוף ← One Zone-IA. ארכיון, אחזור במילישניות ← Glacier Instant. ארכיון, דקות ← Glacier Flexible. ארכיון, שעות, הכי זול ← Glacier Deep Archive.
bucket בגישה מעורבת עם דפוסים בלתי צפויים; אופטימיזציה אוטומטית לעלות.
S3 Intelligent-Tiering. מנטר גישה; מזיז אובייקטים אוטומטית בין שכבות (Frequent / Infrequent / Archive Instant / Archive / Deep Archive). ללא דמי אחזור.
למה: עמלת ניטור זעירה לכל אובייקט, אך זול יותר מניחוש שגוי. ברירת מחדל לדפוסים לא ידועים.
העלאת אובייקטים גדולים (> 100 MB) באופן אמין ומהיר דרך האינטרנט.
S3 Multipart Upload (חלקים מקבילים) + S3 Transfer Acceleration (קליטה בקצה CloudFront).
למה: חלקים מקבילים ממלאים את רוחב הפס; Transfer Acceleration מוריד את קפיצת ה-WAN לעמוד השדרה של AWS.
בחירת סוג כרך EBS.
לשימוש כללי, ברירת מחדל ← gp3 (3000 IOPS בסיסי, 125 MB/s; ניתן לכוונון). בסיס נתונים עם IOPS גבוהים ← io2 Block Express. תפוקה עוקבת של Big-data ← st1. ארכיון קר ← sc1. כרכי אתחול ← gp3.
למה: gp3 מפריד IOPS/תפוקה מגודל; זול יותר מ-gp2 בביצועים שווים.
מופעי EC2 מרובים חייבים לקרוא ולכתוב לאותו כרך בלוקים.
EBS Multi-Attach עם io2 / io1 (מופעי Nitro בלבד). חיבור מקביל לעד 16 מופעים באותו AZ.
למה: היישום חייב לתאם כתיבות (מערכת קבצים אשכולית). EFS הוא ברירת המחדל לגישה משותפת לקבצים; Multi-Attach מיועד לבסיסי נתונים אשכוליים הזקוקים לבלוקים.
בחירת מערכת קבצים משותפת.
Linux NFS תואם POSIX, רב-אזורי, קנה מידה אוטומטי ← EFS. Windows SMB / משולב AD ← FSx for Windows. HPC, Lustre, מקושר S3 ← FSx for Lustre. תכונות NetApp ONTAP (תמונות מצב, כלי NetApp) ← FSx for ONTAP. ZFS ← FSx for OpenZFS.
EFS - בחירת מצב תפוקה.
עומס עבודה משתנה, מתרחב עם הגודל ← Bursting. תפוקה גבוהה וצפויה ← Provisioned. רגיש ל-Burst אך רוצה הוצאה גמישה ← Elastic (ברירת מחדל למערכות קבצים חדשות, מתרחב אוטומטית).
גיבוי קבצים/בלוקים/קלטות מקומיים המשתלב עם S3 / Glacier.
AWS Storage Gateway: File Gateway (NFS/SMB ← S3), Volume Gateway (iSCSI ← S3 + תמונות מצב EBS), Tape Gateway (VTL ← Glacier).
נכסים סטטיים + תגובות API עם משתמשים גלובליים; הפחתת עומס על Origin.
CloudFront עם מדיניות מטמון מתאימה. Long TTLs עבור נכסים סטטיים; מפתח מטמון כולל רק כותרות/מחרוזות שאילתה חיוניות. השתמש ב-Origin Shield עבור מקורות בעלי קרדינליות גבוהה.
למה: יחס פגיעת מטמון משפיע הן על ביצועים והן על עלות. מפתח מטמון שגוי (לדוגמה, הכללת כל הכותרות) הורס את יחס הפגיעה.
טיפול בבקשה/תגובה בקצה.
קל משקל, בצד המשתמש, תת-מילישנייה (שכתוב כותרות, הפניות, A/B) ← CloudFront Functions. כבד יותר, Node.js / Python, זמן חישוב ארוך יותר, גישת רשת ← Lambda@Edge.
בחירת ElastiCache Redis לעומת Memcached.
שכפול, עמידות, pub/sub, קבוצות ממוינות, מעבר לגיבוי מרובה AZ ← Redis. מרובה תהליכים, מפתח/ערך פשוט, sharding אופקי בלבד ← Memcached.
Redis session store זקוק ל-HA עם מעבר אוטומטי לגיבוי על פני AZs.
קבוצת שכפול של ElastiCache for Redis עם Multi-AZ + מעבר אוטומטי לגיבוי מופעל. ראשי באזור זמינות אחד, עותקים באחרים.
חביון קריאה של DynamoDB ממיקרושניות; מטמון ללא שינויים באפליקציה.
DynamoDB Accelerator (DAX). מטמון מנוהל בתוך ה-VPC; אותו SDK של DynamoDB; קריאה שקופה דרך המטמון.
למה: ElastiCache דורש לוגיקת מטמון ברמת האפליקציה. DAX הוא פתרון "drop-in" ל-DynamoDB.
בחירת אסטרטגיית מטמון.
טעינה עצלה (Cache miss ← אחזור + מילוי): פשוט, אוגר במטמון רק את מה שמבוקש. כתיבה דרך (כתיבה למטמון + ל-DB בעת עדכון): מטמון תמיד טרי, אך כתיבות נוספות. TTL: הגבלת התיישנות בכל אחד מהדפוסים.
בחירת פלטפורמת מחשוב.
מונע אירועים תת-15 דקות, קנה מידה תת-שנייה, ללא תשתית ← Lambda. קונטיינרים ארוכי טווח, ללא ניהול צמתים ← Fargate. קרנל מותאם אישית, GPU, מצב עמיד, הכי זול לאורך זמן ← EC2.
Lambda Java cold-start פוגע בחביון p99.
Lambda SnapStart (Java, Python, .NET). תמונת מצב של סביבת הרצה מאותחלת משוחזרת בהפעלה; עד פי 10 מהיר יותר באתחול קר.
עומס פיצוץ צפוי; cold starts בלתי נסבלים.
Provisioned Concurrency. סביבות מחוממות מראש מוכנות להפעלה בכל תפוקה. שלב עם Application Auto Scaling להרחבת קנה מידה מתוזמנת.
למה: עולה יותר מ-On-Demand אך מבטל את ה-cold start. לא נחוץ לתעבורה יציבה שבה ניצול Provisioned Concurrency נשאר גבוה באופן טבעי.
בחירת סוג API Gateway.
סט תכונות מלא (אימות בקשה, טרנספורמציות, מפתחות API, תוכניות שימוש) ← REST API. עלות נמוכה יותר, חביון נמוך יותר, JWT/OIDC מקורי, פשוט יותר ← HTTP API. דו-כיווני בזמן אמת ← WebSocket API.
אפליקציית מובייל/ווב זקוקה ל-GraphQL עם הרשמות בזמן אמת המגובות על ידי DynamoDB / Lambda.
AWS AppSync. GraphQL מנוהל, הרשמות WebSocket, הרשאה דקת גרגר באמצעות Cognito / IAM / Lambda authorizers.
בחירת Kinesis Data Streams לעומת Firehose לעומת Managed Service for Apache Flink לעומת MSK.
צרכנים מותאמים אישית, חביון במילישניות, הפעלה מחדש, fan-out מרובה צרכנים ← Data Streams. רק מסירה ל-S3/Redshift/OpenSearch עם buffering ← Firehose. עיבוד זרמים (חלונות, joins) ← Managed Service for Apache Flink. תואם Kafka ← MSK.
שאילתות Athena סורקות טרה-בייטים; עלות / זמן מופרזים.
חלוקת הנתונים לפי predicate שאילתה (תאריך, אזור). המרה לפורמט עמודתי Parquet/ORC. שימוש ב-partition projection כדי למנוע נסיעות הלוך ושוב לקטלוג.
למה: Athena מחייבת לפי TB שנסרק. פורמט עמודתי + חלוקה מפחיתים לעיתים קרובות עלות פי 10-100.
שאילתת נתונים הנמצאים ב-S3 מ-Redshift ללא טעינתם.
Redshift Spectrum. סכמה חיצונית מעל Glue Data Catalog; צומתי Spectrum סורקים את S3 ומזרמים תוצאות חזרה לאשכול.
בחירת מצב קיבולת DynamoDB.
עומסי עבודה בלתי צפויים / קוצניים / חדשים ← On-demand. יציבים, צפויים, עמוסים - ורגישים לעלות ← Provisioned עם auto-scaling. החלפת מצבים לכל היותר פעם אחת ב-24 שעות.
שאילתת DynamoDB לפי תכונה שאינה מפתח המחיצה.
Global Secondary Index (GSI) עבור שאילתות על מפתח מחיצה שונה. Local Secondary Index (LSI) עבור מפתח מיון חלופי באותו מפתח מחיצה (LSI חייב להיווצר בזמן יצירת הטבלה).
טבלת סשנים של DynamoDB גדלה ללא גבול; סשנים פגים לאחר 24 שעות.
DynamoDB TTL על תכונת Epoch מספרית. DynamoDB מוחק פריטים שפגו תוקף באופן אסינכרוני, ללא חיוב קיבולת כתיבה.
עומס עבודה של HPC זקוק לחביון הנמוך ביותר האפשרי בין צמתים.
קבוצת מיקום אשכולית (Cluster placement group): מופעים באותו AZ על אותו ארון פיזי. עד 10 Gbps לזרימה יחידה.
למה: Spread placement ← בידוד מקסימלי (HA); Partition ← Big-data (Hadoop, Cassandra); Cluster ← חביון הדוק ביותר.
בחירת אפשרות רכישה של EC2 לצי יציב 24×7.
Compute Savings Plan (שנה או 3 שנים) - 66% הנחה ממחיר המחירון, גמיש על פני משפחת מופעים, גודל, מערכת הפעלה, tenancy, אזור. RIs רק כשאתה צריך שמורת קיבולת.
למה: Savings Plans עדיפים על RIs לרוב מקרי השימוש הממוקדי עלות (גמישים יותר, אותה הנחה).
בחירת Compute Savings Plan לעומת EC2 Instance Savings Plan לעומת SageMaker Savings Plan.
Compute SP: גמישות מקסימלית (מכסה EC2, Fargate, Lambda) - ברירת המחדל הטובה ביותר. EC2 Instance SP: נעול למשפחה, הנחה עמוקה יותר. SageMaker SP: בלעדי ל-SageMaker.
שימוש ב-Spot לחסכון בעלויות על עומסי עבודה סובלניים.
Spot דרך מדיניות מופעים מעורבים של ASG עם אסטרטגיית הקצאה אופטימלית לקיבולת + מספר סוגי מופעים. טיפול בהודעת הפרעה של 2 דקות דרך מטא-דאטה של המופע.
למה: capacity-optimized בוחר מאגרים שהסיכוי שיידרשו מחדש הוא הנמוך ביותר. מספר סוגים מגוונים מפחיתים את סיכון המאגר.
יש Reserved Instances שאינם בשימוש לאחר מיגרציה.
מכירה ב-Reserved Instance Marketplace (RIs רגילים בלבד). או המרה באמצעות Convertible RIs למשפחה אחרת.
למה: Convertible RIs מציעים הנחה מעט נמוכה יותר בתמורה לזכות להחלפה.
הפחתת עלויות מחשוב ללא שכתוב ארכיטקטורה.
הגירה למופעי Graviton (ARM64). זולים בכ-20%, ביצועים-למחיר טובים בכ-40% עבור עומסי עבודה רבים. דורש תמונות קונטיינר מרובות ארכיטקטורות או קבצים בינאריים מקומפלים מחדש.
פונקציות Lambda שבהן סביבת הריצה תומכת ב-ARM.
הגדר ארכיטקטורה ל-`arm64` (Graviton). זול ב-20% למילישנייה מ-x86, ולעתים קרובות מהיר יותר. דורש תלות מקומית תואמת ארכיטקטורה.
עלות Lambda גבוהה מדי; סביבת הריצה מוגבלת CPU.
הגדל זיכרון (מה שמגדיל את ה-CPU והרשת באופן יחסי). השתמש ב-Lambda Power Tuning (כלי Step Functions) כדי למצוא את הנקודה האופטימלית - לעיתים קרובות זיכרון גבוה יותר מהיר יותר וגם זול יותר.
יומנים ואובייקטים ישנים מצטברים ב-S3 Standard.
כללי S3 Lifecycle: מעבר ל-IA לאחר 30 יום, Glacier Flexible לאחר 90 יום, Deep Archive לאחר 180 יום, פג תוקף לאחר תקופת שמירה. שלב עם Intelligent-Tiering לדפוסים לא ידועים.
הצגת הוצאות S3 על פני חשבונות; מציאת מועמדים לאופטימיזציה.
S3 Storage Lens. לוח מחוונים ארגוני עם שימוש, פעילות, המלצות לחיסכון בעלויות. שכבת מדדים מתקדמים לפירוט ברמת קידומת.
דמי עיבוד נתונים של NAT Gateway שולטים בחשבון.
החלף תעבורת שירותי AWS ב-VPC Endpoints (gateway עבור S3/DynamoDB; interface לכל השאר). העבר עומסי עבודה הזקוקים ליציאה לאינטרנט לתת-רשתות ציבוריות רק כשצריך.
למה: NAT Gateway מחייב לפי GB מעובד אפילו עבור תעבורת שירותי AWS. נקודות קצה מבטלות נתיב זה.
הפחתת עלויות העברת נתונים.
אותו AZ, אותו VPC = חינם. חוצה AZ = $0.01/GB לכל כיוון. חוצה אזור = יקר. יציאה לאינטרנט = היקר ביותר אך חינם דרך CloudFront עבור תוכן שניתן לשמירה במטמון. תמיד יציאה דרך CloudFront כאשר אפשרי.
עלויות CloudWatch Logs מאמירות.
הגדר שמירה מפורשת (ברירת המחדל היא "Never expire"). ייצא יומנים ישנים ל-S3 + Glacier. השתמש ב-Logs Insights רק על נתונים חמים. סנן בסוכן (אל תשלח יומני דיבאג בייצור).
מציאת מועמדים להתאמת גודל נכונה על פני EC2, Auto Scaling Groups, EBS, Lambda.
AWS Compute Optimizer. קורא מדדי CloudWatch + ML, ממליץ על הקטנת גודל או החלפת משפחה. חינם להצטרפות ברמת הארגון.
זיהוי עליות הוצאה בלתי צפויות באופן יזום.
AWS Cost Anomaly Detection (בתוך Cost Explorer). מנטורים מבוססי ML לכל שירות / חשבון מקושר / קטגוריית עלויות. התראות דרך SNS / אימייל.
עצירת הוצאות בלתי מבוקרות בחשבון Sandbox.
AWS Budgets עם פעולה: בסף 80%, הפעל התראת SNS; ב-100%, צרף SCP דחייה / מדיניות IAM דרך Budgets Action.
חיוב חוזר לפי צוות או מוצר ללא חשבונות נפרדים.
תגי הקצאת עלויות. הפעל תגים מוגדרים על ידי משתמש בקונסולת החיוב; הצג ב-Cost Explorer + CUR. שלב עם `aws:CreatedBy` לייחוס זהות.
מופעי EC2 לפיתוח/בדיקה פועלים 24×7 - בשימוש רק 9-עד-5.
AWS Instance Scheduler (Lambda שנפרסם באמצעות CloudFormation). תייג מופעים בשמות לוחות זמנים; מפעיל עצירה/הפעלה כמו cron. או פשוט `aws:autoscaling:scheduledActions` ב-ASGs לפיתוח.
למה: הפחתה של כ-70% בהוצאות מחשוב פיתוח עם עצירה מחוץ לשעות העבודה.
מופע RDS לפיתוח בחוסר פעילות בלילות/סופי שבוע.
עצור את מופע ה-RDS (Single-AZ; עד 7 ימים, ואז מופעל אוטומטית). או Aurora Serverless v2 עם ACU מינימלי = 0.5 (אין עצירה מלאה, אך עלות מינימלית בחוסר פעילות).
אופטימיזציה של עלויות צי קונטיינרים.
ניצול יציב וגבוה ← ECS על EC2 (עם Spot/Savings Plans) - הכי זול. קוצני / קצר מועד / ללא ניהול צמתים ← Fargate. Fargate Spot זול ב-70% מ-Fargate עבור עומסי עבודה סובלניים.
הפחתת יציאת S3 / EC2 לאינטרנט.
חזית עם CloudFront. העברת Origin ← Edge חינם; Edge ← משתמש זול יותר מיציאת EC2/S3 ישירה בקנה מידה. הפעל דחיסה + TTLs מתאימים.
העברת 100 TB מ-NFS מקומי ל-S3.
סוכן AWS DataSync מקומי; העברה מתוזמנת ל-S3. מוצפן, עם בדיקת תקינות, מוגבל קצב. Snowball Edge עבור 100 TB+ או רוחב פס נמוך.
העברת > 1 PB מסביבה מקומית ל-AWS; רוחב פס איטי מדי להעברה מקוונת.
AWS Snow Family. Snowball Edge Storage Optimized (80 TB) לטיפוסי; מספר מכשירים במקביל למאות TB. Snowmobile פרש - השתמש במספר Snowballים לקנה מידה של פטה-בייט.
RDS / ElastiCache / OpenSearch / Redshift בסביבת ייצור פועל 24×7.
Reserved Instances לבסיסי נתונים מנוהלים (אין מקביל ל-Savings Plan עבור שירותים אלה). שנה או 3 שנים; תשלום מראש חלקי בדרך כלל בעל NPV הטוב ביותר.
זכיות מהירות וקלות להפחתת עלויות על פני החשבון.
בדיקות עלויות של AWS Trusted Advisor: מאזני עומס לא פעילים, EC2 בשימוש נמוך, EBS לא מחובר, RDS בשימוש נמוך, Redshift לא פעיל. שכבה חינמית מוגבלת; סט מלא עם תמיכת Business / Enterprise.