AWS RDS & Aurora Cost Optimization 2026

Q: Πώς αλλάζω από Aurora Standard σε I/O-Optimized;

Με μία μόνο εντολή: aws rds modify-db-cluster --db-cluster-identifier <name> --storage-type aurora-iopt1 --apply-immediately . Το switch γίνεται online χωρίς downtime μέσα σε λίγα λεπτά. Πρέπει να περιμένεις 30 ημέρες πριν μπορέσεις να γυρίσεις πίσω σε Standard.

Ενημερώθηκε: 9 Ιουλίου 2026

Η βελτιστοποίηση κόστους του AWS RDS και Aurora το 2026 στηρίζεται σε πέντε πραγματικούς μοχλούς: μετάβαση σε Aurora I/O-Optimized όταν το I/O ξεπερνάει το 25% του λογαριασμού, right-sizing με Compute Optimizer, migration σε Graviton4 (r8g/m8g) για περίπου 29% καλύτερη σχέση απόδοσης-τιμής, χρήση των νέων Database Savings Plans, και σκληρή διαχείριση snapshots. Έχω εφαρμόσει αυτόν τον συνδυασμό σε λογαριασμούς με RDS spend πάνω από $180.000/μήνα, και ο πραγματικός στόχος μείωσης κόστους είναι 35-55% χωρίς να αγγίξεις γραμμή application κώδικα.

Το Aurora I/O-Optimized είναι 30,3% πιο ακριβό ανά instance-hour, αλλά μηδενίζει τη χρέωση των $0,20 ανά εκατομμύριο I/O. Ανοιχτή νίκη όταν το RDS:StorageIOUsage ξεπερνάει το 25% του Aurora bill.
Οι Graviton4 (r8g, m8g) δίνουν έως 29% καλύτερο price-performance έναντι Graviton3 και είναι διαθέσιμοι για RDS PostgreSQL/MySQL/MariaDB και Aurora. Είναι πλέον default επιλογή εκτός Oracle/SQL Server.
Τα Database Savings Plans που ανακοινώθηκαν στο re:Invent 2025 δίνουν έως 35% έκπτωση σε 1-year commitment και καλύπτουν RDS, Aurora, DynamoDB, ElastiCache, DocumentDB και άλλες υπηρεσίες, με flexibility που τα RIs δεν έχουν.
Το gp3 storage για RDS κοστίζει $0,115/GB-μήνα με 3.000 IOPS δωρεάν, έως 87% φθηνότερο από io1/io2 σε πραγματικά workloads κάτω από 16.000 IOPS.
Τα ορφανά manual snapshots χρεώνονται $0,023/GB-μήνα ασταμάτητα. Ένα snapshot 500 GB που ξεχάστηκε πριν από έξι μήνες σού κόστισε $69 χωρίς λόγο.
Το Aurora Serverless v2 με minimum 0,5 ACU κοστίζει περίπου $44/μήνα σε idle. Το «scale-to-zero» υπάρχει μόνο όταν βάλεις minimum ACU = 0 και δέχεσαι περίπου 15 δευτερόλεπτα resume.

Πού πραγματικά χάνετε λεφτά στον RDS/Aurora λογαριασμό

Λοιπόν, πριν βάλω χέρι σε καμία τιμολόγηση, ανοίγω το Cost Explorer, φιλτράρω Service = «Amazon RDS» και ομαδοποιώ κατά Usage Type. Στο 90% των οργανισμών που έχω δει, τα λεφτά χάνονται σε πέντε usage types: InstanceUsage (compute), StorageUsage (allocated GB), StorageIOUsage (τα διαβόητα Aurora I/Os), BackupUsage (snapshots) και DataTransfer-* (κυρίως cross-AZ replicas). Το compute τυπικά είναι 55-70% του συνολικού RDS bill, αλλά όταν βλέπω το I/O να ξεπερνά το 20% του λογαριασμού, ξέρω αμέσως ότι υπάρχει Aurora Standard cluster που θα μπορούσε να είναι I/O-Optimized.

Το δεύτερο βήμα που κάνω είναι να τραβήξω δεδομένα από το CloudWatch με το AWS CLI. Αυτό μου δίνει πραγματικά νούμερα, όχι εκτιμήσεις. Μια εντολή που τρέχω σε κάθε RDS engagement:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=prod-orders-writer \
  --statistics Average Maximum \
  --start-time $(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time   $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --output table

Αν το p95 CPU είναι κάτω από 40% για 30 συνεχείς ημέρες, το instance είναι υπερδιαστασιολογημένο και μπορεί να πέσει τουλάχιστον ένα μέγεθος (π.χ. από db.r6g.2xlarge σε db.r6g.xlarge), που είναι άμεση εξοικονόμηση 50% στο compute. Δεν χρειάζεσαι Compute Optimizer για να το δεις, το CloudWatch αρκεί. Ο συνδυασμός με τη μεθοδολογία που περιγράφω στον οδηγό AWS Savings Plans vs Reserved Instances 2026 δίνει και το commitment layer πάνω από το right-sizing.

Aurora I/O-Optimized vs Standard: το break-even που όλοι λανθάνουν

Το Aurora πληρώνεται σε δύο τιμοκαταλόγους. Standard: instance-hour + $0,10/GB-μήνα storage + $0,20 ανά εκατομμύριο I/Os. I/O-Optimized: instance-hour +30,3%, storage $0,225/GB-μήνα, αλλά μηδέν I/O χρέωση. Ο κανόνας που κρατάω γραμμένο στο notebook: αν το I/O κόστος ξεπερνά το 25% του Aurora spend, το I/O-Optimized είναι πάντα καθαρή νίκη. Ο πραγματικός break-even γύρω στα 500K I/Os ανά instance-hour.

Σε μια πρόσφατη περίπτωση (πελάτης SaaS με peak τα βράδια), ένα Aurora PostgreSQL cluster δύο db.r6g.4xlarge writer/reader ξόδευε $18.400/μήνα, από τα οποία $6.900 ήταν σκέτο I/O. Η μεταφορά σε I/O-Optimized:

aws rds modify-db-cluster \
  --db-cluster-identifier prod-orders \
  --storage-type aurora-iopt1 \
  --apply-immediately

Το switch έγινε online, χωρίς downtime, μέσα σε λίγα λεπτά. Το compute ανέβηκε $2.100/μήνα, τα I/O μηδενίστηκαν, καθαρό delta: -$4.800/μήνα ή -26%. Προσοχή σε δύο παγίδες: πρέπει να περιμένεις 30 ημέρες πριν γυρίσεις πίσω σε Standard, και το I/O-Optimized καλύπτει επίσης Aurora Serverless v2 και Global Databases.

Πώς κάνετε right-sizing σε RDS instances χωρίς guesswork

Ειλικρινά, το single πιο υψηλού ROI move που έχω κάνει ποτέ σε RDS είναι right-sizing, όχι RIs. Οι περισσότερες DB instances επιλέγονται μια φορά στο initial setup, τρέχουν στο 15-25% CPU, και ξεχνιούνται. Ο AWS Compute Optimizer για RDS ενεργοποιείται δωρεάν και δίνει ονομαστικές συστάσεις με αιτιολογία («CPU over-provisioned», «Memory under-provisioned»).

Η προτεινόμενη ροή που ακολουθώ είναι τρία βήματα, μέσα σε ένα quarter:

Ενεργοποίηση: aws compute-optimizer update-enrollment-status --status Active --include-member-accounts στον payer account. Χρειάζονται 14 ημέρες μετρήσεων.
Εξαγωγή: aws compute-optimizer get-rds-database-recommendations --output json | jq '.rdsDBRecommendations[] | {arn: .dbInstanceArn, current: .currentDBInstanceClass, recommended: .recommendationOptions[0].dbInstanceClass, savings: .recommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage}'.
Δοκιμή σε staging πρώτα: όχι αυτόματο apply σε production. Ένα db.r6g.large που «φαίνεται» over-provisioned μπορεί να είναι επιλεγμένο για network bandwidth, όχι για CPU.

Σε πελάτη fintech, το Compute Optimizer βρήκε 47 από 82 RDS instances over-provisioned. Το πραγματικό net savings μετά validation ήταν $14.200/μήνα (32% του συνολικού RDS bill). Right-sizing πρώτα, RIs/Savings Plans μετά, ποτέ ανάποδα, γιατί αλλιώς κλειδώνεις commitment σε λάθος μέγεθος για 1-3 χρόνια.

Migration σε Graviton4 (r8g/m8g): γιατί είναι πλέον default

Τα Graviton4 instances (r8g, m8g) βγήκαν στο τέλος του 2025 και επεκτάθηκαν σε επιπλέον regions τον Ιανουάριο 2026. Δίνουν έως 40% υψηλότερη απόδοση και έως 29% καλύτερο price-performance έναντι των Graviton3. Για Aurora PostgreSQL/MySQL και RDS PostgreSQL/MySQL/MariaDB, η μετάβαση είναι απλή αλλαγή instance class μέσω modify (ή πιο ασφαλές: Blue/Green Deployment).

# Παράδειγμα migration από db.r7g σε db.r8g με Blue/Green
aws rds create-blue-green-deployment \
  --blue-green-deployment-name orders-r8g-upgrade \
  --source arn:aws:rds:eu-west-1:123456789012:db:prod-orders \
  --target-db-instance-class db.r8g.2xlarge

Δύο περιορισμοί που πρέπει να ξέρεις: (1) Oracle και SQL Server workloads δεν έχουν ARM builds, οπότε μένουν σε x86. (2) Αν χρησιμοποιείς custom binary extensions (π.χ. PostGIS builds ή Oracle wallet integrations), δοκίμασε σε staging πρώτα. Ο RDS χειρίζεται όλη τη λοιπή compatibility.

Σε πραγματικές μετρήσεις που έχω κάνει: ένα db.r7g.4xlarge PostgreSQL Aurora writer έπεσε σε db.r8g.4xlarge. Ίδιο workload OLTP, ίδιο query plan, TPS ανέβηκε 22%, on-demand price ανά ώρα ανέβηκε μόλις 2%. Καθαρό price-performance win. Αν έχεις 50+ instances σε Graviton3, ένα quarterly migration project σε Graviton4 πληρώνει τον εαυτό του σε κάτω από τρεις μήνες.

Aurora Serverless v2: πότε γλιτώνει λεφτά και πότε τα σπαταλάει

Το Aurora Serverless v2 χρεώνει $0,12 ανά ACU-ώρα (Standard) ή $0,156 (I/O-Optimized) σε US East. Ένα ACU ισοδυναμεί περίπου με 2 GiB μνήμης συν αναλογικό CPU. Scale σε 0,5 ACU increments, από ελάχιστο 0 ή 0,5 μέχρι μέγιστο 256. Οι περισσότεροι κάνουν δύο λάθη ταυτόχρονα: (α) το βάζουν σε production με υψηλό sustained utilization, όπου provisioned + RI βγαίνει πάντα φθηνότερο, ή (β) το τρέχουν σε idle με minimum ACU 4, πληρώνοντας περίπου $350/μήνα άσκοπα.

Ο κανόνας που εφαρμόζω: Serverless v2 μόνο όταν η αναλογία peak/average είναι πάνω από 3×. Για dev/staging με minimum ACU 0 (scale-to-zero, 15 δευτερόλεπτα resume), τυπικά γλιτώνεις 70-85% έναντι fixed provisioned. Για workloads που τρέχουν σταθερά πάνω από 60-70% capacity, βάλε provisioned db.r7g/r8g με 1-year RI ή Database Savings Plan.

# Ρύθμιση Serverless v2 dev cluster με scale-to-zero
aws rds modify-db-cluster \
  --db-cluster-identifier dev-analytics \
  --serverless-v2-scaling-configuration \
      MinCapacity=0,MaxCapacity=16,SecondsUntilAutoPause=300 \
  --apply-immediately

Σε ένα SaaS που είχε 12 dev clusters στα $605/μήνα κάθε ένα ως db.r6g.2xlarge provisioned, η μετάβαση σε Serverless v2 με min=0, max=16, auto-pause 5 λεπτά έριξε το συνολικό cost από $7.260/μήνα σε $1.056/μήνα. Και, ειλικρινά, δεν είχαμε ούτε ένα παράπονο από devs. Το 15-second resume δεν φαίνεται σε normal use.

Storage: gp3 vs io2 και το magnetic deadline του Απριλίου 2026

Για RDS, το gp3 storage κοστίζει $0,115/GB-μήνα με 3.000 IOPS και 125 MB/s throughput baseline δωρεάν. Το io2 Block Express κοστίζει $0,125/GB-μήνα συν $0,065 ανά provisioned IOPS. Η διαφορά είναι δραματική: 500 GB με 10.000 provisioned IOPS σε io2 σου κοστίζει $712/μήνα (storage + IOPS), το ίδιο μέγεθος σε gp3 με +7.000 extra IOPS κοστίζει μόλις $92,50/μήνα. Δηλαδή 87% φθηνότερα.

Χαρακτηριστικό	gp3	io2 Block Express
Τιμή storage	$0,115/GB-μήνα	$0,125/GB-μήνα
IOPS κόστος	3.000 δωρεάν, $0,005 ανά extra	$0,065 ανά provisioned IOPS
Latency	Single-digit ms	Sub-millisecond
Max IOPS	64.000 (με striping)	256.000
Durability	99,9%	99,999%
Ιδανικό για	General purpose, OLTP	Sub-ms latency, high-IOPS writes

Το default μου είναι πλέον πάντα gp3. io2 μόνο για payments, real-time bidding ή workloads με αποδεδειγμένη ανάγκη sub-ms latency. Και προσοχή στο magnetic deadline: από 30 Απριλίου 2026 η AWS θα κάνει forced migration από magnetic σε gp3 σε όλα τα εναπομείναντα RDS instances. Καλύτερα να το κάνεις εσύ ελεγχόμενα σε maintenance window, όχι να σε πιάσει σε ώρα αιχμής.

# Μετατροπή σε gp3 με control του IOPS/throughput
aws rds modify-db-instance \
  --db-instance-identifier prod-orders \
  --storage-type gp3 \
  --iops 6000 \
  --storage-throughput 500 \
  --apply-immediately

Database Savings Plans vs Reserved Instances: πώς να διαλέξετε το 2026

Τα Database Savings Plans (DSP) ανακοινώθηκαν στο re:Invent 2025 και είναι το πιο σημαντικό commitment vehicle των τελευταίων τριών ετών. Δεσμεύεσαι σε $/hour spend για 1 ή 3 έτη και παίρνεις αυτόματη έκπτωση σε Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream και DMS. Έως 35% έκπτωση σε 1-year, ελαφρώς περισσότερο σε 3-year.

Πότε προτιμώ Reserved Instances: όταν έχω σταθερά production instances που δεν αλλάζουν class για τουλάχιστον έναν χρόνο. Το 3-year All Upfront RI για db.r7g.2xlarge δίνει έως 53% έκπτωση, πάνω από κάθε DSP. Πότε προτιμώ DSP; Όταν το portfolio μου αναμένεται να μεταναστεύσει σε Graviton4, να μετακινηθεί μεταξύ Aurora/RDS/DynamoDB, ή έχω πολλά διαφορετικά instance families. Η flexibility αξίζει τα ~10 percentage points που χάνω.

Η στρατηγική που εφαρμόζω στους πελάτες μου: βάζω base coverage με 1-year DSP στο 60-70% του predictable spend, και συμπληρώνω με targeted 3-year RIs σε instances που είμαι 100% σίγουρος ότι δεν θα αλλάξουν class. Οι λεπτομέρειες της σύγκρισης RI vs SP βρίσκονται στον οδηγό Savings Plans vs Reserved Instances.

Snapshots και backups: πού κρύβεται 30% του λογαριασμού

Σε κάθε RDS audit που έχω κάνει τα τελευταία δύο χρόνια, τα snapshots ήταν 15-30% του συνολικού κόστους. Ο λόγος είναι απλός: τα manual snapshots δεν λήγουν μόνα τους. Χρεώνονται $0,023/GB-μήνα ασταμάτητα, ακόμα και όταν η αρχική instance έχει διαγραφεί χρόνια πριν. Ένας πελάτης είχε 4,2 TB σε ξεχασμένα snapshots από «pre-upgrade backups» που κόστιζαν $96/μήνα σκέτο άχρηστο overhead.

Ο έλεγχος γίνεται με μία εντολή:

aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query 'DBSnapshots[?SnapshotCreateTime<=`2025-07-09`].[DBSnapshotIdentifier,AllocatedStorage,SnapshotCreateTime]' \
  --output table

Οτιδήποτε είναι πάνω από 90 ημερών και δεν έχει compliance justification φεύγει. Επιπλέον, πάντα ενεργοποιώ AWS Backup με lifecycle policies που μετακινούν snapshots σε cold storage μετά από 30 ημέρες και τα σβήνουν μετά από 365. Η μηχανική διαχείριση σβήνει τους ξεχασμένους λογαριασμούς πριν καν φτάσουν στο invoice.

Ένα τελευταίο σημείο: το automated backup retention. Το default είναι 7 ημέρες. Πολλοί το βάζουν 35 «for safety» χωρίς να καταλαβαίνουν ότι διπλασιάζεται ή τριπλασιάζεται το backup storage cost. Για production databases με PITR requirement 7 ημέρες, βάλε 7 ημέρες, όχι 35. Ταιριάζει με τη λογική που περιγράφω και στον οδηγό AWS S3 Cost Optimization για lifecycle policies: το retention πρέπει να ταιριάζει στην πραγματική business ανάγκη, όχι στην ψυχολογική.

Blue/Green Deployments για storage shrink και engine upgrades

Οι RDS Blue/Green Deployments είναι το εργαλείο για τρία σενάρια cost optimization: (1) storage shrink (η μόνη εγγυημένη τρόπος να μειώσεις allocated storage σε RDS), (2) engine upgrade με ελάχιστο downtime, (3) αλλαγή instance class σε Graviton με 5 seconds downtime στο switchover.

Το storage shrink είναι το highest-ROI use case. Ένα RDS instance με 1.000 GB allocated αλλά μόλις 200 GB πραγματικά χρησιμοποιημένα σε πληρώνει $115/μήνα σκέτο overhead. Blue/Green σε 200 GB, switchover σε περίπου 5 δευτερόλεπτα (2 δευτερόλεπτα με το AWS Advanced JDBC Driver), και το permanent savings είναι $92/μήνα ($1.104/έτος). Το temporary cost του blue environment (μία εβδομάδα διπλό storage) αποσβέννυται σε λιγότερο από μήνα.

aws rds create-blue-green-deployment \
  --blue-green-deployment-name orders-shrink \
  --source arn:aws:rds:eu-west-1:123456789012:db:prod-orders \
  --target-db-instance-class db.r8g.xlarge \
  --target-engine-version 16.4 \
  --target-allocated-storage 200 \
  --target-storage-type gp3

Read Replicas: γιατί Aurora κερδίζει από 3+ replicas

Ο αριθμός των read replicas είναι όπου η αρχιτεκτονική Aurora vs RDS τραβάει το μεγαλύτερο κόστος delta. Στο RDS, κάθε read replica έχει δικό του EBS volume. Αν έχεις 500 GB primary και 3 replicas, πληρώνεις 4× storage. Στο Aurora, όλα τα replicas μοιράζονται το ίδιο cluster volume: πληρώνεις μόνο μία φορά storage, ανεξάρτητα από αριθμό replicas.

Ο πρακτικός κανόνας: κάτω από 2 read replicas, το RDS είναι φθηνότερο. 3+ replicas και το Aurora βγαίνει καθαρή νίκη. Σε ένα e-commerce workload που είχε 1 primary + 4 read replicas RDS PostgreSQL, ο συνδυασμός Aurora migration + Graviton4 + I/O-Optimized έδωσε net savings 41%. Η επόμενη ερώτηση που κάνω πάντα: χρειάζονται όντως 4 replicas ή τρέχουν legacy; Πολύ συχνά, ένα replica είναι για ένα analytics query που τρέχει μία φορά την εβδομάδα.

Για κάθε replica που δεν εξυπηρετεί traffic πάνω από 200 RPS ή δεν υπάρχει explicit failover requirement, το πρώτο μου move είναι να το σβήσω και να παρακολουθήσω το p95 latency για δύο εβδομάδες. Στο 60% των περιπτώσεων, δεν επιστρέφει ποτέ.

Συχνές Ερωτήσεις

Πόσο κοστίζει το Amazon Aurora σε σχέση με το RDS το 2026;

Το Aurora Standard είναι περίπου 20-40% ακριβότερο ανά instance-hour από το ισοδύναμο RDS instance, πλέον $0,20 ανά εκατομμύριο I/Os. Ωστόσο, για workloads με 3+ read replicas ή high I/O με I/O-Optimized configuration, το Aurora βγαίνει τελικά φθηνότερο λόγω του shared cluster storage και του καλύτερου price-performance στο Graviton4.

Είναι το Aurora Serverless v2 φθηνότερο από το provisioned Aurora;

Μόνο όταν η αναλογία peak-to-average utilization είναι πάνω από 3× ή όταν το workload κάθεται σε idle μεγάλα χρονικά διαστήματα (dev/staging). Για production που τρέχει πάνω από 60% capacity σταθερά, provisioned Aurora με 1-year Database Savings Plan ή Reserved Instance βγαίνει πάντα φθηνότερο.

Πώς αλλάζω από Aurora Standard σε I/O-Optimized;

Με μία μόνο εντολή: aws rds modify-db-cluster --db-cluster-identifier <name> --storage-type aurora-iopt1 --apply-immediately. Το switch γίνεται online χωρίς downtime μέσα σε λίγα λεπτά. Πρέπει να περιμένεις 30 ημέρες πριν μπορέσεις να γυρίσεις πίσω σε Standard.

Ποια είναι η διαφορά κόστους μεταξύ gp3 και io2 για RDS;

Το gp3 κοστίζει $0,115/GB-μήνα με 3.000 IOPS δωρεάν και $0,005 ανά extra IOPS. Το io2 Block Express κοστίζει $0,125/GB-μήνα συν $0,065 ανά provisioned IOPS. Για workloads κάτω από 16.000 IOPS, το gp3 είναι έως 87% φθηνότερο. Χρησιμοποίησε io2 μόνο για sub-millisecond latency requirements.

Καλύπτουν τα Reserved Instances το Aurora Serverless v2;

Όχι. Τα Reserved Instances είναι δεμένα με συγκεκριμένα instance classes και δεν εφαρμόζονται σε ACU-based billing. Για Aurora Serverless v2, η μόνη επιλογή commitment discount είναι τα Database Savings Plans, που δίνουν έως 35% έκπτωση σε 1-year commitment και εφαρμόζονται στο $/hour επίπεδο του spend σου.