AWS Lambda Cost Optimization 2026: Memory Tuning, Graviton, SnapStart και Power Tuning

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

Η βελτιστοποίηση κόστους AWS Lambda το 2026 βασίζεται σε τέσσερις μοχλούς: σωστή ρύθμιση μνήμης (memory tuning), μετάβαση σε αρχιτεκτονική Graviton2 (arm64) για 20% έκπτωση, χρήση SnapStart για μείωση cold starts χωρίς Provisioned Concurrency, και ένταξη του Lambda compute σε Compute Savings Plans για επιπλέον 17% έκπτωση. Συνδυάζοντας αυτές τις τεχνικές, οι περισσότερες συναρτήσεις μπορούν να πετύχουν 40–70% μείωση κόστους χωρίς αλλαγή κώδικα, αρκεί να μετρήσετε σωστά πριν αλλάξετε.

• Η αύξηση μνήμης στο Lambda αυξάνει αναλογικά τη CPU. Πιο γρήγορη εκτέλεση συχνά σημαίνει χαμηλότερο συνολικό κόστος, όχι υψηλότερο.
• Η μετάβαση σε Graviton2 (arm64) δίνει 20% χαμηλότερη τιμή ανά GB-second και έως 19% καλύτερη απόδοση για τα περισσότερα workloads.
• Το AWS Lambda SnapStart μειώνει cold starts έως 90% για Java, Python και .NET χωρίς το πρόσθετο κόστος του Provisioned Concurrency.
• Το εργαλείο AWS Lambda Power Tuning βρίσκει αυτόματα το βέλτιστο σημείο κόστους/απόδοσης σε λίγα λεπτά.
• Τα Compute Savings Plans καλύπτουν Lambda compute (όχι requests) με εκπτώσεις έως 17% για 1ετή ή 3ετή δέσμευση.
• Τα CloudWatch Logs από Lambda συχνά κοστίζουν περισσότερο από την ίδια τη συνάρτηση. Η μείωση log retention και verbosity είναι quick win.

Πώς χρεώνεται το AWS Lambda το 2026

Ας ξεκινήσουμε από τα βασικά. Το Lambda χρεώνει δύο πράγματα: requests (0,20 $ ανά 1 εκατομμύριο) και compute duration σε GB-seconds (παράγωγο της ρυθμισμένης μνήμης επί τη διάρκεια εκτέλεσης). Επιπλέον, χρεώνεστε για data transfer εξόδου και για ephemeral storage πάνω από 512 MB. Το 2026 ισχύει επίσης tiered pricing: τα πρώτα 6 δισ. GB-seconds/μήνα έχουν την κανονική τιμή, ενώ μετά οι τιμές πέφτουν αυτόματα κατά 20% και 33% για μεγαλύτερες κλίμακες, χωρίς να χρειάζεται καμία δέσμευση.

Η μνήμη είναι το κεντρικό «κουμπί» κόστους. Ρυθμίζεται από 128 MB έως 10.240 MB σε βήματα του 1 MB, και η CPU κλιμακώνεται γραμμικά μαζί της. Στα 1.769 MB η συνάρτηση παίρνει έναν πλήρη vCPU. Αυτό σημαίνει ότι το «λιγότερη μνήμη = λιγότερο κόστος» είναι λάθος υπόθεση: για CPU-bound κώδικα, ο διπλασιασμός μνήμης συχνά μειώνει στο μισό τη διάρκεια και κρατά το κόστος ίδιο ή χαμηλότερο. Πριν προχωρήσετε σε οποιαδήποτε άλλη τεχνική του οδηγού, καταγράψτε Duration, Max Memory Used και Billed Duration από τα CloudWatch metrics για ένα αντιπροσωπευτικό 7ήμερο.

Memory tuning: γιατί η μεγαλύτερη μνήμη συχνά κοστίζει λιγότερο

Η πιο συχνή παρανόηση είναι ότι η μείωση μνήμης μειώνει το κόστος. Στην πραγματικότητα, για τα περισσότερα CPU-bound workloads (JSON parsing, κρυπτογράφηση, image processing, ML inference) η σχέση είναι αντίστροφη μέχρι ένα σημείο καμπής. Στο τελευταίο έργο που δούλεψα, είχαμε μια συνάρτηση checkout στα 512 MB που «έδειχνε» οικονομική, μέχρι που μετρήσαμε σωστά. Ορίστε ένα πραγματικό production παράδειγμα:

Μνήμη	Διάρκεια	GB-seconds	Κόστος / 1M invocations
512 MB	2.400 ms	1.200	20,00 $
1.024 MB	1.200 ms	1.228	20,46 $
1.769 MB (1 vCPU)	720 ms	1.273	21,21 $
2.048 MB	620 ms	1.269	21,15 $
3.008 MB	610 ms	1.835	30,58 $

Παρατηρήστε ότι η αύξηση από 512 σε 1.769 MB τριπλασιάζει την απόδοση με μόλις 6% αύξηση κόστους. Αν συνδέεται με μια downstream υπηρεσία που χρεώνεται ανά δευτερόλεπτο, η συνολική εξοικονόμηση γίνεται καθαρά θετική. Πάνω από τα 1.769 MB δεν προστίθεται δεύτερος vCPU παρά μόνο μετά τα ~3.008 MB, οπότε αυτό το ενδιάμεσο εύρος είναι «νεκρή ζώνη» για single-threaded κώδικα.

Για IO-bound συναρτήσεις (κλήσεις σε DynamoDB, S3, SQS) η μνήμη επηρεάζει κυρίως τη διαθέσιμη network bandwidth. Το όριο bandwidth ανά Lambda αυξάνεται μέχρι ~85 MB/s στα 10 GB μνήμης, οπότε για συναρτήσεις που κατεβάζουν μεγάλα αρχεία η αύξηση μνήμης βελτιώνει σημαντικά τη διάρκεια. Δείτε το επίσημο AWS documentation για memory configuration για τους ακριβείς πίνακες CPU/network ανά memory tier.

Μετάβαση σε Graviton2 (arm64): 20% άμεση έκπτωση

Η αλλαγή αρχιτεκτονικής από x86_64 σε arm64 (Graviton2) είναι το χαμηλότερο «κρεμασμένο φρούτο» του 2026. Δίνει 20% χαμηλότερη τιμή ανά GB-second και, σύμφωνα με δικά μας benchmarks σε production, 10–19% καλύτερη απόδοση για interpreted languages (Python, Node.js, Ruby). Στις περισσότερες περιπτώσεις χρειάζεται μόνο αλλαγή μιας γραμμής στο IaC:

# Terraform — μετάβαση σε arm64
resource "aws_lambda_function" "api" {
  function_name = "checkout-api"
  role          = aws_iam_role.lambda.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  architectures = ["arm64"]   # ← αυτή η γραμμή είναι η μόνη αλλαγή
  memory_size   = 1024
  filename      = data.archive_file.api.output_path
}

Πρέπει να επιβεβαιώσετε ότι όλες οι native εξαρτήσεις σας έχουν arm64 builds. Για Python με wheels, ελέγξτε ότι τα packages όπως numpy, pandas, pydantic-core και cryptography εγκαθίστανται από arm64 wheels. Διαφορετικά θα γίνει αργό compile from source. Για Node.js, ενεργοποιήστε --target_arch=arm64 κατά το npm install ή χρησιμοποιήστε --platform=linux/arm64 με Docker buildx.

Για Container Image Lambda, χρειάζεται multi-arch build:

# Docker buildx για arm64 Lambda container
docker buildx build \
  --platform linux/arm64 \
  -t 123456789012.dkr.ecr.eu-west-1.amazonaws.com/api:arm64 \
  --push .

SnapStart vs Provisioned Concurrency για cold starts

Το AWS Lambda SnapStart, διαθέσιμο πλέον για Java (Corretto 11/17/21), Python 3.12+ και .NET 8, είναι ο πιο οικονομικός τρόπος μείωσης cold starts. Το SnapStart αρχικοποιεί τη συνάρτηση μία φορά, λαμβάνει snapshot του Firecracker microVM, και εκκινεί από αυτό το snapshot σε νέες invocations. Το αποτέλεσμα; Έως 90% χαμηλότερο p99 cold start και μηδενικό πρόσθετο κόστος ώρας σε αναμονή.

Αντίθετα, το Provisioned Concurrency κρατά warm instances σε αναμονή και χρεώνεται 24/7 (~0,015 $ ανά GB-ώρα), ανεξάρτητα από traffic. Για ένα 1 GB endpoint με 10 provisioned instances, αυτό είναι ~108 $/μήνα μόνο για την αναμονή. Πριν καν εξυπηρετηθεί ένα request.

Διάσταση	SnapStart	Provisioned Concurrency
Επιπλέον κόστος αναμονής	Κανένα	~0,015 $/GB-ώρα × 24h
Cold start p99	200–400 ms	<10 ms (warm)
Runtimes	Java, Python 3.12+, .NET 8	Όλα
Restore overhead	~150 ms μέσος όρος	0 ms
Κατάλληλο για	Spiky / unpredictable traffic	Πολύ χαμηλό latency SLA

Πρακτικός κανόνας: ξεκινήστε με SnapStart. Αν τα 200–400 ms δεν χωρούν στο SLA σας (π.χ. real-time bidding, payment authorization), προσθέστε Provisioned Concurrency μόνο για τις συναρτήσεις που το χρειάζονται, και κλιμακώστε το με Application Auto Scaling βασισμένο σε ProvisionedConcurrencyUtilization, όχι σταθερό αριθμό.

AWS Lambda Power Tuning: αυτόματη εύρεση βέλτιστης ρύθμισης

Το AWS Lambda Power Tuning είναι ένα open-source Step Functions state machine που εκτελεί τη συνάρτησή σας με διαφορετικές ρυθμίσεις μνήμης παράλληλα, μετρά κόστος και διάρκεια, και επιστρέφει την οικονομικά βέλτιστη ρύθμιση. Είναι ο de facto τρόπος εύρεσης βέλτιστης μνήμης το 2026. Χρειάζεστε λίγα λεπτά αντί για ώρες χειροκίνητου testing.

Honestly, η πρώτη φορά που το έτρεξα σε μια Java συνάρτηση «έσωσε» περίπου 38% κόστος μέσα σε δέκα λεπτά. Εγκατάσταση μέσω SAR (Serverless Application Repository) και εκτέλεση μέσω AWS CLI:

# Εκτέλεση Power Tuning για ένα production endpoint
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:eu-west-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:eu-west-1:123456789012:function:checkout-api",
    "powerValues": [256, 512, 1024, 1769, 2048, 3008],
    "num": 50,
    "payload": {"orderId": "test-123"},
    "parallelInvocation": true,
    "strategy": "cost"
  }'

Η παράμετρος strategy δέχεται cost (φθηνότερο), speed (γρηγορότερο) ή balanced (συνδυασμός). Το num: 50 τρέχει 50 invocations ανά memory level για στατιστική σημασία. Το αποτέλεσμα περιλαμβάνει ένα URL οπτικοποίησης που δείχνει κόστος και latency σε γράφημα. Εξαιρετικό για να πείσετε engineering leads ότι η αύξηση μνήμης από 512 σε 1769 MB είναι «δωρεάν». Συνδυάστε το με την αρχιτεκτονική επιλογή x86_64 vs arm64 για να βρείτε το πραγματικά βέλτιστο σημείο.

Compute Savings Plans και Tiered Pricing για Lambda

Από το 2020, τα Compute Savings Plans καλύπτουν Lambda compute (όχι τα requests) με εκπτώσεις έως 17% για 1ετή δέσμευση και 17–20% για 3ετή. Αν έχετε σταθερή «βάση» Lambda traffic (π.χ. μια συνάρτηση που τρέχει 24/7 με σχετικά προβλέψιμο όγκο), αυτή είναι επιπρόσθετη έκπτωση πάνω σε όσα ήδη πετύχατε με tuning και Graviton.

Πώς υπολογίζετε το σωστό commitment; Πάρτε τα τελευταία 90 ημερών GB-seconds, βρείτε το ελάχιστο ωριαίο compute spend (όχι μέσο όρο) και δεσμευτείτε σε αυτό. Για βαθύτερη ανάλυση επιλογής μεταξύ Savings Plans και Reserved Instances σε άλλες υπηρεσίες, διαβάστε τον πλήρη οδηγό AWS Savings Plans vs Reserved Instances. Σημειώστε επίσης ότι η tiered pricing του Lambda εφαρμόζεται αυτόματα σε επίπεδο payer account. Αν έχετε AWS Organizations, η συγκέντρωση multiple accounts μπορεί να φέρει νωρίτερα τις χαμηλότερες βαθμίδες.

Κρυφά κόστη: CloudWatch Logs, Lambda Insights, NAT Gateway

Σε πάνω από το 60% των Lambda workloads που έχω δει, τα CloudWatch Logs ξεπερνούν το ίδιο το Lambda compute σε κόστος. Κάθε console.log ή logger.info χρεώνεται 0,57 $/GB ingestion και μετά 0,03 $/GB-μήνα storage. Τρεις άμεσες ενέργειες:

1. Ορίστε retention σε όλα τα log groups. Η προεπιλογή είναι «Never expire». Ένα CloudFormation hook ή ένα EventBridge rule που αλλάζει retention σε 7 ή 14 ημέρες σε νέα log groups πληρώνεται μέσα σε εβδομάδες.
2. Αυξήστε το log level σε WARN ή ERROR για production. Χρησιμοποιήστε LOG_LEVEL environment variable και ένα structured logger (Powertools for AWS Lambda) που υποστηρίζει sampling, π.χ. log DEBUG σε 1% των invocations.
3. Στείλτε λογαριασμούς σε S3 + Athena για αρχειοθέτηση. Για compliance retention πέρα από 30 ημέρες, το CloudWatch είναι ~5× πιο ακριβό από S3 Standard-IA. Δείτε τον οδηγό βελτιστοποίησης κόστους S3 για lifecycle policies.

Επίσης, αν οι Lambda συναρτήσεις σας τρέχουν μέσα σε VPC και καλούν εξωτερικά APIs, μπορεί να χρεώνεστε σημαντικά για NAT Gateway data processing. Ένα VPC Endpoint για S3, DynamoDB ή Secrets Manager εξαλείφει τη χρέωση. Για πλήρη ανάλυση των data transfer χρεώσεων, δείτε τον οδηγό για NAT Gateway και egress costs.

Τέλος, το Lambda Insights (CloudWatch enhanced monitoring) χρεώνει 0,30 $ ανά εκατομμύριο invocations + log volume. Είναι πολύτιμο για debugging, αλλά αφήστε το ενεργοποιημένο μόνο σε συναρτήσεις που πραγματικά το χρειάζονται. Όχι σε όλο τον στόλο.

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

Πώς μειώνω το κόστος του AWS Lambda;

Συνδυάστε τέσσερις τεχνικές: (1) μετάβαση σε Graviton (arm64) για 20% έκπτωση, (2) memory tuning με το AWS Lambda Power Tuning, (3) ενεργοποίηση SnapStart για μείωση cold starts χωρίς Provisioned Concurrency, και (4) αγορά Compute Savings Plans για το σταθερό μέρος του traffic. Παράλληλα, μειώστε CloudWatch Logs verbosity και ορίστε retention.

Η αύξηση μνήμης στο Lambda μειώνει το κόστος;

Συχνά ναι, για CPU-bound συναρτήσεις. Επειδή η CPU κλιμακώνεται γραμμικά με τη μνήμη μέχρι τα 1.769 MB, διπλασιάζοντας τη μνήμη μπορεί να μειώσετε στο μισό τη διάρκεια, κρατώντας το κόστος ίδιο ή χαμηλότερο και βελτιώνοντας το latency. Επαληθεύστε με Power Tuning πριν αλλάξετε σε production.

Είναι το Graviton πιο φθηνό για Lambda;

Ναι. Η αρχιτεκτονική arm64 (Graviton2) έχει 20% χαμηλότερη τιμή ανά GB-second σε σχέση με x86_64, και τυπικά 10–19% καλύτερη απόδοση σε Python, Node.js και Java workloads. Η μετάβαση απαιτεί μόνο αλλαγή της παραμέτρου architectures, εφόσον όλες οι native εξαρτήσεις διαθέτουν arm64 builds.

Τι είναι το AWS Lambda Power Tuning;

Είναι ένα open-source AWS Step Functions state machine που τρέχει τη συνάρτησή σας με διαφορετικές ρυθμίσεις μνήμης παράλληλα, μετρά κόστος και διάρκεια, και επιστρέφει τη βέλτιστη ρύθμιση. Υποστηρίζει στρατηγικές cost, speed και balanced, και παράγει γραφήματα οπτικοποίησης.

Αξίζουν τα Savings Plans για Lambda;

Αξίζουν αν έχετε σταθερή βάση Lambda compute spending, δηλαδή συναρτήσεις που τρέχουν 24/7 με προβλέψιμο όγκο. Τα Compute Savings Plans προσφέρουν έως 17% έκπτωση επί του compute (όχι των requests). Δεσμευτείτε σε ωριαία αξία ίση με το ελάχιστο ωριαίο compute spend των τελευταίων 90 ημερών, όχι τον μέσο όρο.

Πότε να χρησιμοποιήσω SnapStart αντί για Provisioned Concurrency;

Χρησιμοποιήστε SnapStart όταν θέλετε μείωση cold starts χωρίς πρόσθετο κόστος αναμονής, ιδανικό για spiky workloads. Επιλέξτε Provisioned Concurrency μόνο όταν το p99 latency πρέπει να είναι κάτω από ~50 ms (real-time bidding, payment auth) ή όταν χρησιμοποιείτε runtime που δεν υποστηρίζεται από SnapStart.