AWS Savings Plans vs RIs: Πλήρης Οδηγός 2026

Η Μεγάλη Σύγχυση: Savings Plans ή Reserved Instances;

Ομολογώ, αυτό είναι το ερώτημα που έχω ακούσει ίσως πιο συχνά από οποιοδήποτε άλλο σε meetings FinOps τα τελευταία δύο χρόνια. Αν διαχειρίζεστε έναν λογαριασμό AWS με μηνιαία δαπάνη άνω των 10.000€, σχεδόν σίγουρα έχετε σταθεί κάποια στιγμή μπροστά σ' αυτό το δίλημμα: να δεσμευτείτε με Reserved Instances (RIs) ή να πάτε με τα πιο ευέλικτα Savings Plans;

Η απάντηση, δυστυχώς, δεν είναι μονοσήμαντη. Και το 2026 — με τις αλλαγές στην τιμολόγηση του Graviton, τις νέες οικογένειες instances (M7i, R8g, C8gn) και την ολοένα αυξανόμενη χρήση serverless workloads — η επιλογή έχει γίνει ακόμα πιο περίπλοκη.

Σ' αυτόν τον οδηγό θα αναλύσουμε τις πραγματικές διαφορές, θα δείξουμε υπολογισμούς με νούμερα του 2026, και θα σας δώσω ένα πρακτικό πλαίσιο απόφασης που έχει δοκιμαστεί σε δεκάδες οργανισμούς. Το στοίχημα είναι μεγάλο: η λάθος επιλογή μπορεί κάλλιστα να σας κοστίσει 15-40% επιπλέον στον ετήσιο λογαριασμό — κι αυτό σε ένα cloud spend της τάξης των €100.000/μήνα, μιλάμε για πολύ σοβαρά λεφτά.

Τα Βασικά: Τι Είναι το Κάθε Ένα;

Reserved Instances (RIs)

Τα Reserved Instances είναι, στην ουσία, μια δέσμευση για συγκεκριμένη οικογένεια instance, region και — προαιρετικά — availability zone, για περίοδο 1 ή 3 ετών. Σε αντάλλαγμα, λαμβάνετε έκπτωση έως και 72% σε σχέση με το On-Demand κόστος. Αρκετά γενναιόδωρο, αν το καλοσκεφτείτε.

Υπάρχουν δύο βασικοί τύποι:

Standard RIs: Η μεγαλύτερη έκπτωση, αλλά και περιορισμένη ευελιξία. Το καλό; Μπορείτε να τα πουλήσετε στο AWS Marketplace αν δεν τα χρειάζεστε πλέον.
Convertible RIs: Μικρότερη έκπτωση (έως 66%), αλλά έχετε τη δυνατότητα να τα ανταλλάξετε με άλλη οικογένεια, OS ή tenancy, αρκεί η νέα αξία να είναι ίση ή μεγαλύτερη.

Savings Plans

Τα Savings Plans είναι κάτι λίγο διαφορετικό: μια δέσμευση σε ωριαία δαπάνη (USD/hour) για 1 ή 3 χρόνια. Δεν δεσμεύεστε σε συγκεκριμένο instance type — δεσμεύεστε απλώς σε ποσό δαπάνης. Υπάρχουν τρεις παραλλαγές:

Compute Savings Plans: Η πιο ευέλικτη επιλογή, με διαφορά. Εφαρμόζονται αυτόματα σε EC2 (κάθε region, κάθε οικογένεια), Fargate και Lambda. Έκπτωση έως 66%.
EC2 Instance Savings Plans: Δεσμεύεστε σε συγκεκριμένη οικογένεια και region (π.χ., m7i στο eu-central-1). Έκπτωση έως 72%.
SageMaker Savings Plans: Για ML workloads. Έκπτωση έως 64% σε SageMaker instances.

Σύγκριση Μιας Σελίδας: Τα 8 Κρίσιμα Σημεία

Χαρακτηριστικό	Standard RIs	Convertible RIs	EC2 Instance SP	Compute SP
Μέγιστη έκπτωση	72%	66%	72%	66%
Δέσμευση	Instance family + region	Instance family + region (αλλάζει)	Instance family + region ($/h)	$/h σε οποιαδήποτε περιοχή
Ευελιξία μεγέθους	Ναι (εντός οικογένειας)	Ναι	Ναι	Ναι
Αλλαγή οικογένειας	Όχι	Ναι	Όχι	Ναι (αυτόματα)
Αλλαγή region	Μόνο regional RIs	Ναι	Όχι	Ναι
Κάλυψη Fargate	Όχι	Όχι	Όχι	Ναι
Κάλυψη Lambda	Όχι	Όχι	Όχι	Ναι
Μεταπώληση	Ναι (Marketplace)	Όχι	Όχι	Όχι

Πραγματικοί Υπολογισμοί: Πόσο Εξοικονομείτε στην Πράξη (2026)

Σενάριο 1: Σταθερό workload σε m7i.2xlarge, eu-west-1

Ας πάρουμε κάτι συγκεκριμένο. Έστω λοιπόν ότι τρέχετε συνεχώς 10 instances τύπου m7i.2xlarge στο eu-west-1. Με βάση την τιμολόγηση του Απριλίου 2026:

On-Demand: $0.4032/hour × 10 × 730h = $2.943/μήνα
Standard RI (3y All Upfront): ~60% έκπτωση → $1.177/μήνα
EC2 Instance SP (3y All Upfront): ~60% έκπτωση → $1.177/μήνα
Compute SP (3y All Upfront): ~54% έκπτωση → $1.354/μήνα

Ετήσια εξοικονόμηση: $21.192 (RI/EC2 SP) vs $19.068 (Compute SP). Η διαφορά είναι $2.124/έτος. Με μια πρώτη ματιά το RI κερδίζει — αλλά μην ξεχνάτε, τα Compute SP καλύπτουν επιπρόσθετα και τα Lambda και Fargate σας. Και αυτό αλλάζει την εξίσωση.

Σενάριο 2: Μικτό workload με migration από x86 σε Graviton

Πιο ρεαλιστικά τώρα: πολλοί οργανισμοί το 2026 μεταναστεύουν από m6i σε m7g (Graviton3) ή m8g (Graviton4). Αν δεσμευτείτε με Standard RI σε m6i και μεταναστεύσετε σε 6 μήνες, θα πληρώνετε ουσιαστικά δύο φορές για κάποιους πόρους. Όχι αστείο.

Πιθανές λύσεις:

Convertible RIs: Αλλαγή από m6i σε m7g με ένα API call — αλλά χάνετε 6% σε έκπτωση.
Compute Savings Plans: Η δέσμευση είναι σε $/hour, οπότε όταν αλλάζετε σε Graviton, η φθηνότερη τιμή του Graviton απορροφά αυτόματα περισσότερη κάλυψη. Αυτή είναι, κατά την προσωπική μου άποψη, συχνά η καλύτερη στρατηγική για το 2026.

Όροι Πληρωμής: All Upfront, Partial, No Upfront

Τόσο τα RIs όσο και τα Savings Plans προσφέρουν τρεις όρους πληρωμής:

All Upfront: Πληρώνετε τα πάντα μπροστά. Μέγιστη έκπτωση. Κακό για cash flow.
Partial Upfront: 50% μπροστά, το υπόλοιπο μηνιαία. Καλό trade-off γενικά.
No Upfront: Μηνιαία χρέωση. Μικρότερη έκπτωση (~3-5% διαφορά), αλλά καμία εκταμίευση upfront.

Για τις περισσότερες ελληνικές και ευρωπαϊκές εταιρείες που λειτουργούν με προϋπολογισμό OpEx, το No Upfront είναι συχνά η πιο λογική επιλογή. Η διαφορά σε έκπτωση σπάνια δικαιολογεί το hit στο cash flow — και, ειλικρινά, οι CFOs που έχω γνωρίσει δεν έχουν ποτέ παραπονεθεί για λίγο παραπάνω ρευστότητα.

Το Πλαίσιο Απόφασης σε 5 Βήματα

Βήμα 1: Αναλύστε το baseline σας

Πηγαίνετε στο AWS Cost Explorer → Reservations → Recommendations και Savings Plans → Recommendations. Το AWS θα σας προτείνει ποσά δέσμευσης βάσει των τελευταίων 7, 30 ή 60 ημερών. Το 60-day look-back είναι συνήθως το πιο αντιπροσωπευτικό (το 7-day είναι συχνά υπερβολικά ευαίσθητο σε καμπάνιες marketing ή batch jobs που τρέχουν για λίγες μέρες).

Εναλλακτικά, με AWS CLI:

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type "COMPUTE_SP" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "SIXTY_DAYS"

Βήμα 2: Ταξινομήστε το workload σας

Steady-state, σταθερή οικογένεια, 3+ έτη: Standard RI (μέγιστη έκπτωση)
Steady-state, αλλά αλλάζει instance family: Convertible RI ή Compute SP
Μικτό (EC2 + Fargate + Lambda): Compute SP
Highly dynamic / auto-scaling: Compute SP με συντηρητική δέσμευση (70-80% του baseline)
ML workloads με SageMaker: SageMaker SP

Βήμα 3: Υπολογίστε το "commitment floor"

Κανόνας νούμερο ένα: μην δεσμευτείτε ποτέ στο 100% της τρέχουσας χρήσης. Στοχεύστε σε 70-80% του μέσου όρου των τελευταίων 60 ημερών. Αυτό το ποσοστό ονομάζεται commitment floor — το σταθερό ελάχιστο που είστε βέβαιοι ότι θα καταναλώνετε, ανεξαρτήτως τι συμβαίνει με το traffic σας.

Ένα γρήγορο παράδειγμα σε Python (boto3):

import boto3
from datetime import datetime, timedelta

ce = boto3.client('ce', region_name='us-east-1')

end = datetime.utcnow().date()
start = end - timedelta(days=60)

response = ce.get_cost_and_usage(
    TimePeriod={'Start': str(start), 'End': str(end)},
    Granularity='HOURLY',
    Metrics=['UnblendedCost'],
    Filter={
        'Dimensions': {
            'Key': 'SERVICE',
            'Values': ['Amazon Elastic Compute Cloud - Compute']
        }
    }
)

hourly_costs = [
    float(r['Total']['UnblendedCost']['Amount'])
    for r in response['ResultsByTime']
]

# 20th percentile -> conservative commitment floor
hourly_costs.sort()
p20 = hourly_costs[int(len(hourly_costs) * 0.20)]
print(f"Commitment floor (20th percentile): ${p20:.2f}/hour")

Η λογική πίσω από αυτό: το 20th percentile σημαίνει ότι στο 80% των ωρών ξοδεύετε τουλάχιστον αυτό το ποσό — άρα είναι αρκετά ασφαλής δέσμευση.

Βήμα 4: Χτίστε μια σκάλα δεσμεύσεων (laddering)

Αντί να αγοράσετε ένα μεγάλο 3-ετές SP στην αρχή, σπάστε το σε τμήματα που λήγουν σε διαφορετικές ημερομηνίες:

Μήνας 0: αγοράστε 3-ετές SP για το 40% της δαπάνης
Μήνας 6: αγοράστε 3-ετές SP για άλλο 20%
Μήνας 12: αγοράστε 3-ετές SP για άλλο 20%

Έτσι δεν δεσμεύεστε ποτέ ολοκληρωτικά σε τιμές που μπορεί να πέσουν — και, ιστορικά, το AWS μειώνει τιμές περίπου 1-2 φορές το χρόνο σε δημοφιλείς οικογένειες.

Βήμα 5: Παρακολουθήστε και προσαρμόστε

Ρυθμίστε ένα AWS Budget με alert όταν το coverage rate πέσει κάτω από 70% ή όταν το utilization rate πέσει κάτω από 95%:

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "SP-Utilization-Alert",
    "BudgetType": "SAVINGS_PLANS_UTILIZATION",
    "TimeUnit": "MONTHLY",
    "CostTypes": {"IncludeTax": false},
    "BudgetLimit": {"Amount": "95", "Unit": "PERCENTAGE"}
  }'

Συχνά Λάθη που Κοστίζουν Χιλιάδες

Λάθος 1: Υπερδέσμευση σε περιβάλλον που αλλάζει

Ο κλασικός FinOps εφιάλτης. Αγοράζετε 3-ετή RIs για m5.large, και 6 μήνες αργότερα η ομάδα μηχανικών αποφασίζει να μεταναστεύσει τα πάντα σε Graviton. Τα RIs σας τώρα "κολλάνε" και μπορεί να κοστίσουν ακόμα περισσότερα απ' ό,τι αν δεν τα είχατε καν αγοράσει. Το έχω δει τρεις φορές μέσα σε ένα χρόνο.

Λύση: Ξεκινήστε με Compute SP ή Convertible RIs μέχρι να έχετε σταθερή αρχιτεκτονική.

Λάθος 2: Αγνόηση των region-specific τιμών

Τα EC2 Instance SPs κλειδώνουν την τιμή στο region αγοράς. Αν μεταφέρετε workload από eu-west-1 σε eu-central-1 (κάτι αρκετά συχνό για λόγους GDPR/data residency), το SP δεν ακολουθεί.

Λάθος 3: Αγορά μόνο στο τέλος του οικονομικού έτους

Κάτι που παρατηρώ συνέχεια: πολλές εταιρείες αγοράζουν όλες τις δεσμεύσεις τον Δεκέμβριο για λόγους προϋπολογισμού. Αυτό δημιουργεί ένα "wall of renewals" τρία χρόνια αργότερα, και αφήνει το οικοσύστημα ευάλωτο σε market fluctuations. Κατανεμήστε τις αγορές μέσα στη χρονιά.

Λάθος 4: Παράβλεψη των Spot Instances

Τα Savings Plans και τα Spot Instances δεν είναι ανταγωνιστικά — είναι συμπληρωματικά. Χρησιμοποιήστε SPs για το baseline σας και Spot για burst capacity. Το συνολικό blended saving μπορεί άνετα να φτάσει το 85%.

Case Study: SaaS Εταιρεία με Ετήσιο AWS Bill €1.2M

Ένας Έλληνας πελάτης μας (50-άτομη SaaS εταιρεία, μηνιαίο AWS bill ~€100.000) εφάρμοσε την εξής στρατηγική τον Ιανουάριο του 2026:

50% της δαπάνης σε 3-ετή Compute Savings Plans (No Upfront) → 54% έκπτωση
25% σε 1-ετή EC2 Instance SP για συγκεκριμένα production DB instances (r7g) → 40% έκπτωση
15% σε Spot για batch processing και CI/CD → 70-80% έκπτωση
10% σε On-Demand για spikes και experimentation → 0% έκπτωση

Αποτέλεσμα: Blended savings ~52% → εξοικονόμηση €624.000/έτος, χωρίς καμία αλλαγή στην αρχιτεκτονική. Και, ίσως το πιο σημαντικό, χωρίς stress για την ομάδα engineering.

FAQ: Οι Ερωτήσεις που Όλοι Κάνουν

Μπορώ να ακυρώσω ένα Savings Plan ή RI αν δεν το χρησιμοποιώ πλέον;

Τα Savings Plans δεν ακυρώνονται — είναι μη αναστρέψιμη δέσμευση. Τα Standard RIs μπορείτε να τα πουλήσετε στο AWS Marketplace (με αμοιβή 12%). Τα Convertible RIs δεν πωλούνται, αλλά μπορείτε να τα μετατρέψετε σε άλλη οικογένεια.

Τα Savings Plans καλύπτουν RDS, ElastiCache ή DynamoDB;

Όχι. Τα Savings Plans καλύπτουν μόνο EC2, Fargate, Lambda και SageMaker. Για RDS, ElastiCache, Redshift, OpenSearch και DynamoDB χρειάζεστε ξεχωριστά Reserved Instances/Reserved Capacity ανά service. Ένα σημείο που προκαλεί σύγχυση, ομολογουμένως.

Τι γίνεται αν αγοράσω SP και το AWS μειώσει τις τιμές On-Demand;

Ιστορικά, όταν το AWS μειώνει τις On-Demand τιμές, μειώνει ανάλογα και τις SP/RI τιμές για νέες αγορές. Οι υπάρχουσες δεσμεύσεις σας, όμως, δεν ενημερώνονται αυτόματα. Γι' αυτόν ακριβώς τον λόγο το laddering (βήμα 4 παραπάνω) είναι τόσο κρίσιμο.

Ποια είναι η διαφορά μεταξύ "coverage" και "utilization";

Coverage: Τι ποσοστό της συνολικής σας χρήσης EC2 καλύπτεται από SP/RI. Στόχος: 70-85%. Utilization: Τι ποσοστό της αγορασμένης δέσμευσης χρησιμοποιείτε πραγματικά. Στόχος: 95-100%. Χαμηλό utilization σημαίνει ουσιαστικά ότι χάνετε χρήματα σε αχρησιμοποίητες δεσμεύσεις.

Πρέπει να περιμένω για τη νέα γενιά Graviton πριν αγοράσω SP;

Όχι, αν χρησιμοποιείτε Compute Savings Plans. Αυτά εφαρμόζονται αυτόματα σε οποιαδήποτε οικογένεια, οπότε όταν μεταναστεύσετε σε Graviton, η έκπτωση ακολουθεί. Αν όμως σκέφτεστε EC2 Instance SP, καλύτερα να περιμένετε για την οικογένεια που θα χρησιμοποιήσετε μακροπρόθεσμα.

Συμπέρασμα: Η Default Επιλογή για το 2026

Αν δεν έχετε ιδιαίτερες απαιτήσεις, το Compute Savings Plans σε 1-ετή No Upfront είναι, κατά τη γνώμη μου, η πιο ασφαλής προεπιλογή για το 2026. Θυσιάζετε 6-8% έκπτωση σε σχέση με τις πιο επιθετικές επιλογές, αλλά κερδίζετε:

Ευελιξία σε instance families και regions
Αυτόματη κάλυψη Lambda και Fargate
Γρήγορη προσαρμογή σε Graviton migrations
Καμία εκταμίευση upfront

Μόλις σταθεροποιήσετε την αρχιτεκτονική σας (συνήθως μετά από 12-18 μήνες), αντικαταστήστε σταδιακά τα expiring SPs με πιο επιθετικές 3-ετείς δεσμεύσεις ή Standard RIs για τα workloads που ξέρετε με βεβαιότητα ότι θα υπάρχουν για πολύ καιρό ακόμα.

Κλείνοντας: η βέλτιστη στρατηγική δεν είναι να βρείτε τον "σωστό" τύπο δέσμευσης — είναι να χτίσετε μια χαρτοφυλακιακή προσέγγιση που ισορροπεί δέσμευση και ευελιξία ανάλογα με τη δική σας ωριμότητα και το ρίσκο που είστε πρόθυμοι να αναλάβετε. Αυτό είναι και το τελικό κλειδί για ένα υγιές FinOps.