חשבון AWS חודשי של 12,000 דולר קוצץ בחצי תוך חודש אחד
חשבון AWS של לקוח הגיע ל-12,000 דולר בחודש, בעוד שניצול המעבד (CPU) ברוב המופעים נותר מתחת ל-5%. Cost Explorer חשף חריגות: מופע EC2 Cost Explorer שפועל ב-3% CPU במשך שישה חודשים, מופע RDS m5.4xlarge ללא Read Replica שמטפל ב-12 חיבורים מקבילים בלבד מתוך 5000, ו-NAT Gateway לתעבורה יוצאת שעולה 2,000 דולר בחודש, מכיוון שקריאות S3 עברו דרכו במקום דרך VPC Gateway Endpoint. זה לא תרחיש בדיוני — כך נראית תשתית כשהן גדלות אורגנית ללא פיקוח ארכיטקטוני. אנחנו צוות של מהנדסי AWS מוסמכים עם ניסיון של 10+ שנים ו-50+ פרויקטים מוצלחים, המציע שירותי ענן AWS מקיפים החל מביקורת ועד הטמעה. הניסיון שלנו מראה שלאחר ביקורת מקיפה והטמעת ההמלצות, החיסכון האופייני נע בין 40–60% מהחשבון הנוכחי. צרו קשר כדי שנעריך את הפרויקט שלכם תוך יומיים.
כיצד IAM הופך לפרצת אבטחה ומה עושים בנידון
IAM הוא הרכיב הכי מוערך בחסר ב-AWS. db.r5.2xlarge עבור כל המפתחים ו-AdministratorAccess בקבצי ACCESS_KEY_ID — תרחישים קלאסיים שמסתיימים בתקרית או בחשבון מפתיע. במקום משתמשים מבוססי מפתחות, אנחנו משתמשים ב-.env. EC2 מקבל אישורים זמניים דרך Instance Profile (שירות מטא-דאטה) — ללא מפתחות קבועים. עבור EKS — IRSA: ה-pod מקבל הרשאות AWS דרך הערת ServiceAccount, ללא אחסון אישורים ב-Secrets:
apiVersion: v1 kind: ServiceAccount metadata: name: s3-reader annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/s3-read-role pod עם ServiceAccount זה מקבל אוטומטית טוקן זמני עבור Roles, שמתחלף כל 15 דקות.
Permission Boundaries — מגביל עבור מפתחים שיוצרים תפקידי IAM משלהם (למשל עבור Lambda). פרופיל ה-boundary קובע תקרה להרשאות: גם אם מפתח יוצר תפקיד עם apiVersion: v1 kind: ServiceAccount metadata: name: s3-reader annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/s3-read-role , ההרשאות בפועל מוגבלות על ידי ה-boundary.
SCPs ב-AWS Organizations חוסמים פעולות ברמת החשבון. איסור יצירת משאבים מחוץ לאזורים ספציפיים — אף משתמש או תפקיד לא יכול להפעיל מופע ב-s3-read-role, אפילו עם AdministratorAccess. איסור השבתת CloudTrail, MFA חובה עבור root — הכל מוגדר עבור הלקוח. כל ביקורת ה-IAM ואכיפת ההרשאות המינימליות אורכת 3–5 ימים.
מדוע חשבון AWS מזנק באופן בלתי צפוי?
זינוקים בלתי צפויים נובעים בדרך כלל משלושה מקורות: משאבים נטושים (כרכים EBS שאינם בשימוש, כתובות Elastic IP), עלויות העברת נתונים (במיוחד יציאה דרך NAT Gateway), ומופעים עם הקצאת משאבים מופרזת. דפוס נפוץ: מפתח מפעיל סביבת בדיקה ושוכח לסיים אותה. ללא תיוג נכון והתראות Cost Explorer, עלויות אלו מצטברות בשקט. הביקורת שלנו מזהה את כל הנזילות הללו ומספקת תוכנית תיקון ממוקדת לפי עדיפות.
מדוע Karpenter עדיף על Cluster Autoscaler
EKS — Kubernetes מנוהל על AWS. מישור הבקרה מנוהל על ידי AWS, משלמים לשעה לכל קלאסטר ועוד צמתים. צמתי עבודה הם EC2 רגילים או Fargate.
Cluster Autoscaler עובד דרך Auto Scaling Groups, לוקח 3–5 דקות לקבל החלטות, ואינו בוחר ביעילות סוגי מופעים. Karpenter משכתב את התרחיש: הוא עוקב אחר pods ממתינים, מנתח ap-southeast-1, בוחר את סוג המופע האופטימלי דרך EC2 Fleet API, ומשיק צומת תוך 30–60 שניות. הגדרה דרך AdministratorAccess ו-requests:
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: template: spec: requirements: - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] - key: node.kubernetes.io/instance-type operator: In values: ["m5.xlarge", "m5.2xlarge", "m6i.xlarge", "m6i.2xlarge"] limits: cpu: "200" disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 1m NodePool — מאחד עומס באופן פעיל: מעביר pods לצמתים פחותים ומוחק ריקים. זה משפיע ישירות על החשבון. עבור עומסי ייצור, אנחנו משתמשים בשילוב של spot/on-demand דרך NodePools משוקללים: 70% spot, 30% on-demand. Spot מופרע על ידי AWS עם התראה של 2 דקות — מטופל דרך EC2NodeClass וכיבוי מסודר.
RDS: ביצועים וזמינות
Multi-AZ — שכפול סינכרוני ל-standby ב-AZ אחר. Failover אוטומטי, 60–120 שניות. אין לבלבל עם Read Replica: Multi-AZ לזמינות גבוהה, Read Replica להעברת עומסי קריאה.
Parameter Group — פרמטרי מנוע מותאמים אישית. עבור PostgreSQL: apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: template: spec: requirements: - key: karpenter.sh/capacity-type operator: In values: ["spot", "on-demand"] - key: node.kubernetes.io/instance-type operator: In values: ["m5.xlarge", "m5.2xlarge", "m6i.xlarge", "m6i.2xlarge"] limits: cpu: "200" disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 1m , consolidationPolicy: WhenEmptyOrUnderutilized, PodDisruptionBudget, max_connections. RDS אינו מספק גישה ישירה ל-shared_buffers — הכל דרך Parameter Group. שינויים בפרמטרים של work_mem דורשים אתחול מופע (חלון תחזוקה).
RDS Proxy פותר את בעיית איגום החיבורים עבור עומסי serverless. פונקציות Lambda שפותחות אלפי חיבורים למסד הנתונים תחת עומס — RDS Proxy מאגד אותן למאגר. קריטי במיוחד עבור Aurora Serverless.
Performance Insights — כלי מובנה לניתוח שאילתות. מציג את 10 השאילתות המובילות לפי checkpoint_completion_target, אירועי המתנה (cpu, io, lock). זול ומהיר יותר מהקמה ידנית של postgresql.conf.
S3: לא רק אחסון
VPC Gateway Endpoint עבור S3 — תעבורה בין EC2/EKS ל-S3 עוברת ברשת הפנימית של AWS, ועוקפת את NAT Gateway. יצירת Gateway Endpoint היא בחינם, וחוסכת סכומים משמעותיים בנפחים גבוהים. אותו הדבר עבור DynamoDB.
מדיניות מחזור חיים של S3 — העברה אוטומטית של אובייקטים בין מחלקות אחסון:
| גיל האובייקט | מחלקת אחסון | חיסכון לעומת Standard |
|---|---|---|
| נתונים חדשים | S3 Standard | – |
| 30+ ימים | S3 Infrequent Access | 40% |
| 90+ ימים | S3 Glacier Instant Retrieval | 68% |
| 365+ ימים | S3 Glacier Deep Archive | 95% |
עבור גיבויים ולוגים, מדיניות מחזור חיים נכונה מכסה את עצמה כבר בחודש הראשון.
S3 Object Lock (WORM) — לדרישות רגולטוריות. כאשר מצב static מופעל, אפילו משתמש root לא יכול למחוק אובייקט לפני שתום תקופת השמירה.
Lambda וארכיטקטורה מונעת אירועים
Lambda מתאים למשימות עם RPS בלתי צפוי או נמוך: עיבוד אירועי S3, טריגרים של SQS, משימות מתוזמנות דרך EventBridge. בעומסים מתמשכים מעל 1M קריאות בחודש — ECS או EKS זולים יותר.
Cold start — נקודת התורפה העיקרית של Lambda. עבור Python/Node.js — 100–500ms, עבור Java — עד 3 שניות. פתרונות:
- Provisioned Concurrency — שומר N מופעים "חמים" (עולה כסף)
- Snap Start (Java) — שומר snapshot של הפונקציה מאותחלת
- Lambda SnapStart על פונקציות Java 21 — cold start <1 שנייה
Lambda Layers — לתלויות לשימוש חוזר. שכבה עם numpy/pandas משותפת בין פונקציות, מקטינה את גודל חבילת הפריסה, נשמרת במטמון בסביבת הביצוע.
CloudFront: CDN ועוד
Origin Shield — מטמון ביניים בין נקודות הנוכחות של CloudFront ל-origin. מפחית עומס על ה-origin עבור קהל גלובלי: הבקשה עוברת db load, במקום שכל נקודת נוכחות תיצור קשר עם ה-origin בנפרד.
CloudFront Functions לעומת Lambda@Edge — הראשונות פועלות ב-viewer request/response, זמן השהיה <1ms, סביבת JavaScript מוגבלת — מתאימות לשכתוב URLs, מניפולציית כותרות, הפניות A/B. האחרונה — Lambda מלאה ב-origin request/response, המאפשרת גישה ל-DynamoDB ושירותי AWS אחרים להתאמה אישית.
WAF על CloudFront — חסימה ברמת ה-CDN. כללים מנוהלים של AWS (OWASP Top 10, קלטים ידועים רעים) בתוספת כללים מותאמים ל-IP, הגבלת קצב, חסימה גיאוגרפית.
איך להפחית עלויות AWS ללא פגיעה בביצועים?
ביקורת אופטימיזציה טיפוסית מכסה את עצמה כבר בחודש הראשון. להלן גישה שלב אחר שלב שבה אנו משתמשים:
- ניתוח Cost Explorer ו-Trusted Advisor לזיהוי משאבים בטלים, מופעים מופרזים וזינוקי העברת נתונים.
- סילוק משאבים נטושים — כרכי EBS שאינם מחוברים, כתובות Elastic IP שאינן בשימוש, snapshots מיושנים.
- התאמת גודל מופעי EC2 ו-RDS על בסיס מדדי ניצול בפועל.
- הטמעת Savings Plans (לשנה או 3 שנים) או Reserved Instances עבור עומסים צפויים.
- הגדרת auto-scaling ו-Karpenter לאריזה דינמית ושימוש במופעי spot.
- הקמת מדיניות מחזור חיים של S3 ו-VPC Endpoints לקיצוץ עלויות אחסון ורשת.
- ניטור עם תקציבים והתראות למניעת חריגות עתידיות.
חיסכון טיפוסי לאחר ההתערבות שלנו:
| שיטה | חיסכון טיפוסי |
|---|---|
| מופעי Spot עבור עומסים חסרי מצב | 60–80% לעומת on-demand |
| Savings Plans (1–3 שנים) | 30–66% לעומת on-demand |
| Reserved Instances עבור RDS | 40–60% לעומת on-demand |
| מדיניות מחזור חיים של S3 | 40–90% עבור נתונים קרים |
| VPC Endpoints (S3, DynamoDB) | מבטל עלויות NAT Gateway |
| אריזת Karpenter | 20–40% על EC2 |
אנו מספקים דוח שקוף עם סדרי עדיפויות ולוחות זמנים. קבלו ייעוץ כדי להתחיל לחסוך.
מה השירותים שלנו כוללים (תוצרים)
- ביקורת תשתית מלאה על בסיס Well-Architected Framework (IAM, רשת, EKS, RDS, S3, Lambda, CloudFront) — מתועדת עם ממצאי AWS Well-Architected Tool.
- עיצוב ארכיטקטורה המאזן בין אבטחה, ביצועים ועלות.
- הטמעה מלאה באמצעות Terraform/Ansible, GitOps וצינורות CI/CD, עם מסירה כולל תיעוד מלא.
- Runbook, דיאגרמות ונהלי תפעול.
- הכשרת צוות והעברת גישה (AWS Organization, Terraform state).
- אחריות ל-30 יום על השינויים שהוטמעו — אם משהו משתבש, נתקן בחינם.
דוגמה מהשטח: לקוח עם חשבון חודשי של 12,000 דולר. לאחר ביקורת והטמעת VPC Endpoint, Karpenter, מדיניות מחזור חיים של S3 ו-Reserved Instances, החשבון ירד ל-6,000 דולר תוך חודש אחד. הזמינו את אותה תוצאה — צרו קשר במייל או דרך הטופס באתר שלנו לייעוץ על תשתית ה-AWS שלכם.
לוחות זמנים אופייניים וכיצד להזמין
| משימה | לוח זמנים |
|---|---|
| ביקורת IAM ואכיפת הרשאות מינימליות | 3–5 ימים |
| קלאסטר EKS עם Karpenter | 1–2 שבועות |
| הגדרת RDS HA עם ניטור | 3–5 ימים |
| CloudFront + WAF לייצור | 2–4 ימים |
| ביקורת אופטימיזציית עלויות + הטמעה | 1–3 שבועות |
| ארכיטקטורת AWS מלאה מאפס | 4–10 שבועות |
התמחור מחושב באופן אישי לאחר ביקורת של התשתית שלכם. כדי לקבל הערכת פרויקט, צרו קשר — אתם שולחים נתוני Cost Explorer ותצורות נוכחיות, ואנחנו מציעים תוכנית והערכה מדויקת. קבלו ייעוץ כבר עכשיו — כתבו לנו או הזמינו ביקורת AWS מקיפה עוד היום.