מדריך מעשי למעבר מ-x86 ל-AWS Graviton בשנת 2026 עם שלבי מיגרציה, benchmark, תמונות Docker רב-ארכיטקטוניות, NodePool של Karpenter ושילוב עם Savings Plans.
עודכן: 4 ביוני, 2026
מעבר ל-AWS Graviton בשנת 2026 חוסך בממוצע 20% עד 40% מעלות מופעי EC2 לעומת מעבדי Intel ו-AMD מקבילים, ומספק יחס מחיר-ביצועים טוב בכ-40% יותר לפי הנתונים הרשמיים של AWS. השבבים מבוססי ARM של AWS, ובמיוחד הדור הרביעי Graviton4 שהפך לזמין באופן כללי במהלך 2024 והורחב למשפחות מופעים נוספות במהלך 2025, הם כיום ברירת המחדל המומלצת לרוב עומסי העבודה המודרניים, מ-Web APIs ועד מסדי נתונים, Kubernetes ו-Spark.
AWS Graviton הוא משפחה של מעבדי ARM מותאמים אישית של AWS, המבוססים על ארכיטקטורת Neoverse של Arm. הדור הראשון הוכרז בשנת 2018, ובשנת 2026 רוב הסביבות הפרודקטיביות מריצות כבר את Graviton3 (משפחות M7g, C7g, R7g) או את Graviton4 (משפחות M8g, C8g, R8g, X8g, I8g) שהפך לזמין באופן כללי בסוף 2024 והתרחב לכל ה-Regions במרוצת 2025.
הסיבה לחיסכון משולשת. ראשית, AWS מפתחת את השבב in-house ולכן אין מרכיב רווח של ספק שלישי כמו Intel או AMD. שנית, ארכיטקטורת ARM64 צורכת פחות חשמל לכל מחזור, כ-60% פחות אנרגיה לאותו עומס, מה שמתורגם לעלות הפעלה נמוכה יותר בדאטה-סנטר. שלישית, AWS מתמחרת את מופעי Graviton בכ-20% פחות לשעה לעומת מופעי M7i או C7i זהים, ובמקביל מספקת יותר ביצועים לכל vCPU. השילוב של תמחור נמוך יותר וביצועים גבוהים יותר מייצר את "יחס מחיר-ביצועים של 40%" שמופיע בכל מצגת של AWS. בפרויקט האחרון שעבדתי עליו הצלחנו לשחזר את המספר הזה ב-benchmarks אמיתיים על Web API ב-Spring Boot, כפי שנראה בהמשך.
החיסכון בפועל תלוי בעומס העבודה, אך הטווח האמין הוא 15% עד 45%. השוואה ישירה של מחירי On-Demand באזור eu-central-1 לדוגמה (יוני 2026) מראה את הפער הברור.
| מופע | vCPU | זיכרון (GiB) | מחיר On-Demand לשעה | חיסכון מול x86 |
|---|---|---|---|---|
| m7i.xlarge (Intel) | 4 | 16 | $0.2016 | בסיס |
| m7a.xlarge (AMD) | 4 | 16 | $0.2304 | +14% יקר יותר |
| m7g.xlarge (Graviton3) | 4 | 16 | $0.1632 | חיסכון 19% |
| m8g.xlarge (Graviton4) | 4 | 16 | $0.1734 | חיסכון 14% + ~30% ביצועים |
| c8g.2xlarge (Graviton4) | 8 | 16 | $0.3072 | ~40% יחס מחיר-ביצועים |
חשוב להבין שהחיסכון הנקוב לשעה הוא רק חלק מהתמונה. כאשר Graviton4 מסיים את אותה עבודה ב-25% פחות זמן, ניתן להריץ פחות מופעים במקביל בשרתי batch או להוריד את גודל ה-ASG ב-Web services. בפועל, צוותי FinOps מדווחים בבלוגים ובכנסים שבשנת 2026 ההשפעה המצטברת על חשבון EC2 השנתי היא 30% עד 40%, תלוי באיזה אחוז מהעומסים הצליחו להעביר ל-ARM64. לקריאה נוספת על איך למדוד חיסכון לאורך זמן, ראו את מדריך Shift-Left FinOps עם Terraform ו-Infracost שמסביר איך לחזות את החיסכון עוד לפני הפריסה.
השאלה הראשונה שצוות FinOps שואל היא "האם הקוד שלנו ירוץ על ARM?". בשנת 2026 התשובה כמעט תמיד חיובית, אך צריך להבחין בין שכבות:
אם עומס העבודה מערב בינה מלאכותית עם GPU כמו אימון מודלים, Graviton אינו רלוונטי. לשם כך משתמשים במופעי G ו-P. במקרה זה, בדקו את המדריך לניהול עלויות GPU בענן שמכסה אסטרטגיות שונות לחלוטין.
אז בואו נצלול לעניין. מיגרציה שמרנית ובטוחה מורכבת מחמישה שלבים. אל תקפצו שלבים, צוותים שניסו לדלג על benchmark הסבו הפסדים בעלויות במקרים של עומסי עבודה latency-sensitive (ראיתי את זה קורה בפרויקט אחד, וזה לא נעים להסביר ל-VP).
AWS Compute Optimizer מציג מאז 2024 המלצה ייעודית "Graviton recommendation" עבור כל מופע ב-Account. הפעלת ה-service חינמית ובדיקתה בקלות:
aws compute-optimizer get-ec2-instance-recommendations \
--filters name=RecommendationSourceType,values=Ec2Instance \
--query 'instanceRecommendations[?recommendationOptions[?contains(instanceType, `g.`)]].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage]' \
--output tableהקימו מופע m8g.xlarge בסביבת staging ופרסו את היישום שלכם עליו עם תעבורה זהה למופע ה-x86. עקבו אחר latency p50/p99, throughput ו-CPU utilization. אם הביצועים שווים או טובים יותר, אפשר להמשיך. אם רעים יותר, הסיבה הנפוצה היא שיישום משתמש ב-instruction set ספציפי של x86 (AVX-512) שאינו קיים ב-ARM.
אם אתם משתמשים ב-Java JAR לדוגמה, ה-JAR עצמו נשאר זהה אך ה-base image של הקונטיינר משתנה. אם אתם בונים בינארי native ב-Go, הוסיפו target:
GOOS=linux GOARCH=arm64 go build -o app-arm64 ./cmd/serverהוסיפו Target Group נפרד מאחורי ה-ALB וכוונו 10% מהתעבורה למופעי Graviton במשך 24-48 שעות. רק לאחר מכן הגדילו ל-50% ולבסוף ל-100%.
עברו ל-Mixed Instances Policy עם InstanceRequirements שמאפשרים גם x86 וגם Graviton כ-fallback. כך אתם נהנים מ-Spot זמינות גבוהה יותר.
הבעיה הנפוצה ביותר במיגרציה היא תמונת Docker שנבנתה רק ל-x86. בשנת 2026 ה-best practice היא תמיד לבנות multi-arch manifest שמכיל גם linux/amd64 וגם linux/arm64. כך אותה תמונה רצה אוטומטית על המופע הנכון.
# הקמת builder תומך multi-arch (פעם אחת)
docker buildx create --name multiarch --use
docker buildx inspect --bootstrap
# בנייה ודחיפה ל-ECR בשני הארכיטקטורות
docker buildx build \
--platform linux/amd64,linux/arm64 \
--tag 123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.4.2 \
--push \
.ה-Dockerfile עצמו לרוב לא צריך שינוי, בתנאי שה-base image הוא רב-ארכיטקטוני. תמונות רשמיות של node, python, openjdk ו-golang הן multi-arch כברירת מחדל. הקפידו ש-Dockerfile לא יקבע FROM amd64/... ספציפי.
ב-Kubernetes על EKS, השינוי המרכזי הוא ב-NodePool של Karpenter (לשעבר Provisioner). הוסיפו תנאי שמעדיף ARM64 ומגדיר מופעי Graviton:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: graviton-pool
spec:
template:
spec:
requirements:
- key: kubernetes.io/arch
operator: In
values: ["arm64"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["m", "c", "r"]
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["7"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: defaultה-pods עצמם צריכים תמונה רב-ארכיטקטונית (ראו סעיף קודם) או לכלול nodeSelector מפורש. הוסיפו לכל Deployment שעדיין משדר רק amd64 nodeSelector שמרני, ולשאר הניחו ל-Kubernetes לבחור אוטומטית. למידע נוסף על אופטימיזציה של Kubernetes, קראו את המדריך ל-Rightsizing ב-Kubernetes.
בכנות, אלה הבעיות שצצות הכי הרבה במיגרציה אמיתית:
ספריות עם C extensions ישנות (numpy ישן, lxml, psycopg2-binary בגרסה מסוימת) לפעמים אין להן wheel ל-aarch64 וה-pip מנסה לקמפל מהמקור, מה שמכשיל את הבנייה. הפתרון: עברו ל-psycopg ל-3, ועדכנו lxml ל-5.x. אם זה לא אפשרי, התקינו מראש את build-essential ב-Dockerfile.
גרסאות ישנות של Datadog Agent (לפני 7.30) או Splunk Forwarder (לפני 9.0) אינן זמינות ל-ARM. עדכנו לגרסה האחרונה לפני המיגרציה.
AMI custom שלכם חייב להיות מסוג arm64. ב-Terraform, שני data source נפרדים:
data "aws_ami" "amazon_linux_2023_arm64" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["al2023-ami-2026*-arm64"]
}
}אם אתם משתמשים ב-RDS PostgreSQL עם extensions של צד שלישי (pg_repack, timescaledb בגרסה ישנה), בדקו תאימות לפני המעבר. רוב התוספים הרשמיים תומכים ב-ARM כבר משנת 2024.
החיסכון של Graviton הוא רק שכבה אחת. כדי להגיע ל-60%+ הנחה כוללת, שלבו אותה עם Compute Savings Plans (גמיש בין משפחות) או EC2 Instance Savings Plans (ספציפי למשפחת Graviton אך עמוק יותר), ועם Spot Instances לעומסים שתומכים בהפסקות.
אסטרטגיה מומלצת לשנת 2026: כסו 50%-60% מבסיס ה-compute היציב שלכם ב-Compute Savings Plans לתקופה של שנה (חיסכון 30% נוסף על מחיר On-Demand של Graviton), והריצו את הפיק והעומסים האסינכרוניים כ-Spot על מופעי Graviton. בפרקטיקה, צוות שעבר מ-m6i.large עם 30% Savings Plans ל-m8g.large עם 50% Savings Plans + 30% Spot חסך 58% מסך חשבון EC2 השנתי. לפרטים נוספים ראו את תיעוד הרשמי של AWS על Compute Savings Plans, ואת דף הביצועים של AWS Graviton שמכיל benchmarks מעודכנים. הקהילה של FinOps Foundation Framework ממליצה לעדכן את ה-Rate Optimization כל רבעון כדי לתפוס שיפורים כמו Graviton4 ברגע שהם מגיעים לאזור שלכם.
ברוב המקרים, לא. שפות מנוהלות כמו Java, Python, Node.js, Go ו-.NET 8+ רצות native על ARM64 ללא שינוי קוד. צריך רק לבנות מחדש את תמונת הקונטיינר עם --platform linux/arm64 ולוודא שכל הספריות הבינאריות תומכות aarch64.
Graviton4 מספק כ-30% יותר ביצועי compute, פי 2 ערוצי זיכרון (DDR5-5600) ועד 50% יותר ליבות בהשוואה ל-Graviton3. עומסי מסדי נתונים ו-Java נהנים במיוחד; עומסי web פשוטים יקבלו 10%-20% שיפור.
כן, RDS, Aurora, ElastiCache, OpenSearch ו-MemoryDB מציעים מחלקות מופע db.m7g, db.r7g ו-db.r8g. החיסכון הוא בדרך כלל 10%-20% במחיר לשעה, ולפי AWS שיפור של 35% ביחס מחיר-ביצועים על Aurora PostgreSQL. המעבר הוא שינוי הגדרה בלבד.
התחילו עם סביבת staging או עומס non-critical כמו batch jobs או cron. הריצו ב-canary של 10% תעבורה ל-7 ימים, עקבו אחר latency p99 ושגיאות, ורק לאחר מכן הרחיבו ל-Production. השתמשו ב-AWS Compute Optimizer לזיהוי מועמדים אוטומטי.
כן. Lambda עם ארכיטקטורת arm64 זמין מאז 2021 ומספק חיסכון של 20% במחיר ל-invocation וביצועים טובים יותר ב-19% בממוצע. השינוי הוא parameter יחיד בהגדרת ה-function (Architectures: [arm64]) ובניית artifact ל-aarch64 אם משתמשים ב-runtime עם קוד native.
מדריך מעשי להחלטה בין Savings Plans ל-Reserved Instances ב-AWS לשנת 2026. השוואה בין הסוגים, חישוב נקודת איזון, תהליך רכישה עם CLI, וטעויות נפוצות שראיתי בכל אודיט FinOps.