Μείωση κόστους AWS για startups: τι διορθώνετε πρώτα και πώς το βρίσκετε

Ο πιο γρήγορος τρόπος να ρίξετε το AWS bill είναι να δουλέψετε με βάση την προσπάθεια, όχι το μέγεθος. Πρώτα ownership και alerts, γιατί σταματούν το bill από το να μεγαλώνει όσο το διορθώνετε. Μετά το καθάρισμα: αχρησιμοποίητοι πόροι, NAT και data transfer, storage, logs. Τα commitments, όπως τα Savings Plans, έρχονται τελευταία, όταν η χρήση σας έχει σταθεροποιηθεί.

Σε κάθε σημείο θα βρείτε πού να κοιτάξετε και πόση δουλειά θέλει περίπου. Οι εκτιμήσεις είναι χοντρικές και αφορούν μια μικρή ομάδα με έναν ή δύο AWS λογαριασμούς ανά περιβάλλον.

Πριν ξεκινήσετε: μία εικόνα του bill

Ανοίξτε το Cost Explorer, διάστημα τους τρεις τελευταίους ολόκληρους μήνες, μηνιαία ανάλυση, group by Service. Μετά αλλάξτε σε Usage type. Εκεί κρύβονται οι περισσότερες εκπλήξεις, γιατί ένα service όπως το EC2 σπάει σε ώρες instances, EBS, data transfer και NAT.

Αν ξοδεύετε πάνω από μερικές χιλιάδες τον μήνα, στήστε και ένα export του Cost and Usage Report 2.0 σε S3 και κάντε queries με Athena. Το Cost Explorer σας λέει «τι»· το CUR με resource IDs σας λέει «ποιος πόρος».

-- Athena πάνω σε CUR 2.0: τα 20 ακριβότερα usage types του προηγούμενου μήνα
SELECT line_item_product_code,
       line_item_usage_type,
       ROUND(SUM(line_item_unblended_cost), 2) AS cost
FROM cur2
WHERE line_item_usage_start_date >= date_trunc('month', current_date) - interval '1' month
  AND line_item_usage_start_date <  date_trunc('month', current_date)
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 20;

1. Tagging και ownership (μισή μέρα)

Κάθε πόρος χρειάζεται tag για owner, περιβάλλον και service, και τα tags αυτά πρέπει να ενεργοποιηθούν ως cost allocation tags. Χωρίς αυτά, όλα τα υπόλοιπα της λίστας καταλήγουν σε συζήτηση για το ποιος έχει δικαίωμα να σβήσει τι.

Ορίστε τα μία φορά στο επίπεδο του provider στο Terraform, ώστε να μη βγαίνει τίποτα χωρίς tags:

provider "aws" {
  region = "eu-central-1"

  default_tags {
    tags = {
      owner       = "team-payments"
      environment = "prod"
      service     = "checkout"
    }
  }
}

Μετά ενεργοποιήστε τα keys στο Billing and Cost Management, Cost allocation tags. Το AWS αναφέρει ότι τα νέα tag keys μπορεί να χρειαστούν έως 24 ώρες για να εμφανιστούν και άλλες 24 για να ενεργοποιηθούν, οπότε κάντε το από την πρώτη μέρα. Ξεχωριστοί λογαριασμοί ανά περιβάλλον, όπως περιγράφουμε στο άρθρο για το AWS Organizations από την πρώτη μέρα, σας δίνουν δωρεάν και μια δεύτερη διάσταση που δεν «χαλάει».

2. Budgets και anomaly alerts (μία ώρα)

Βάλτε ένα μηνιαίο budget με forecast alert και ένα anomaly monitor ανά service. Δεν σας γλιτώνει χρήματα άμεσα, αλλά μικραίνει τον χρόνο από το λάθος μέχρι να το δει κάποιος, από έναν μήνα σε μία μέρα.

Στο AWS Budgets η παρακολούθηση και οι ειδοποιήσεις είναι δωρεάν· χρεώνονται μόνο τα action-enabled budgets μετά τα δύο πρώτα και τα budget reports μέσω email.

resource "aws_budgets_budget" "monthly" {
  name         = "monthly-total"
  budget_type  = "COST"
  limit_amount = "3000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["[email protected]"]
  }
}

Προσθέστε Cost Anomaly Detection με AWS-managed monitor στη διάσταση AWS services και στείλτε τα individual alerts σε ένα SNS topic που καταλήγει στο Slack. Προτιμήστε forecast alert αντί για actual spend: όταν το πραγματικό κόστος περάσει το 100%, ο μήνας έχει ήδη χαθεί.

3. Αχρησιμοποίητοι και υπερμεγέθεις πόροι (μία με δύο μέρες)

Σβήστε ό,τι δεν χρησιμοποιεί κανείς και μετά μικρύνετε ό,τι είναι μεγάλο. Συνήθως είναι το μεγαλύτερο γρήγορο κέρδος, και είναι κυρίως ντετεκτιβική δουλειά.

Στο Cost Explorer: group το EC2 by Instance type και το RDS by Usage type, και συγκρίνετε με CPU και memory στο CloudWatch. Τι βρίσκουμε συνήθως:

• EBS volumes χωρίς instance και παλιά snapshots από instances που έχουν σβηστεί.
• Load balancers χωρίς healthy targets και test environments που δεν έχει ανοίξει κανείς εδώ και μήνες.
• Public IPv4 που δεν χρησιμοποιούνται. Το AWS χρεώνει $0.005 την ώρα για κάθε public IPv4, είτε χρησιμοποιείται είτε όχι.
• RDS instances στημένα για ένα φορτίο launch day που δεν ήρθε ποτέ.
• Volumes gp2. Το gp3 έχει έως 20% χαμηλότερη τιμή ανά GB, baseline 3.000 IOPS και 125 MB/s σε κάθε μέγεθος, και η αλλαγή γίνεται online.

# EBS volumes που δεν είναι attached
aws ec2 describe-volumes --filters Name=status,Values=available   --query 'Volumes[].{id:VolumeId,gb:Size,type:VolumeType}' --output table

# Elastic IPs χωρίς association
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null].PublicIp'

# Όσα gp2 volumes έχουν μείνει
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2   --query 'Volumes[].VolumeId' --output text

Κάντε right-sizing σε μικρά βήματα, ένα μέγεθος τη φορά, και παρακολουθήστε το latency για μια εβδομάδα πριν το επόμενο. Ένα μικρότερο instance που φέρνει incident κοστίζει περισσότερο απ' όσο γλιτώνει.

4. NAT gateways και data transfer (μισή μέρα για να το βρείτε)

Αν τα usage types NatGateway-Bytes ή DataTransfer είναι στο top 10, πιθανότατα πληρώνετε για κίνηση προς υπηρεσίες του AWS που περνά από NAT gateway. Τα VPC gateway endpoints για S3 και DynamoDB είναι συχνά η πιο φτηνή διόρθωση όλης της λίστας.

Group by Usage type με φίλτρο «NatGateway» και «DataTransfer». Οι συνήθεις ύποπτοι: container images από το ECR μέσω NAT, logs προς τρίτο provider και πολλή cross-AZ κίνηση μεταξύ services. Τις λεπτομέρειες, και το πώς βρίσκετε ποιο workload φταίει, θα τις βρείτε στο άρθρο για το κρυφό κόστος του NAT gateway.

5. Storage classes και lifecycle rules (μισή μέρα)

Κάθε S3 bucket που μόνο μεγαλώνει χρειάζεται lifecycle rules: μεταφορά παλιών objects σε φθηνότερες κλάσεις, διαγραφή όσων δεν χρειάζεστε, καθάρισμα από ημιτελή multipart uploads και παλιές εκδόσεις.

Δείτε το S3 με group by Usage type (ψάξτε το TimedStorage) και το S3 Storage Lens για την ανάπτυξη ανά bucket. Για δεδομένα με απρόβλεπτη πρόσβαση, το S3 Intelligent-Tiering μεταφέρει objects σε φθηνότερα tiers μετά από 30 και 90 μέρες χωρίς πρόσβαση, όμως τα objects κάτω από 128 KB δεν μετακινούνται ποτέ, άρα δεν βοηθά σε buckets με πολλά μικρά αρχεία.

{
  "Rules": [
    {
      "ID": "app-logs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" }
      ],
      "Expiration": { "Days": 365 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Εφαρμόστε το με aws s3api put-bucket-lifecycle-configuration --bucket my-bucket --lifecycle-configuration file://lifecycle.json. Ελέγξτε πρώτα τις υποχρεώσεις διατήρησης· κάποια logs πρέπει να μένουν για συγκεκριμένο διάστημα.

6. Retention στα CloudWatch Logs (μία ώρα)

Ορίστε retention σε κάθε log group. Από προεπιλογή, το CloudWatch Logs κρατά τα δεδομένα επ' αόριστον, οπότε το storage μεγαλώνει κάθε μήνα είτε τα διαβάζει κανείς είτε όχι.

# Retention 30 ημερών σε όσα log groups δεν έχουν
for lg in $(aws logs describe-log-groups     --query 'logGroups[?!retentionInDays].logGroupName' --output text); do
  aws logs put-retention-policy --log-group-name "$lg" --retention-in-days 30
done

Το retention λύνει το storage, όχι το ingestion. Αν το DataProcessing-Bytes του CloudWatch είναι ψηλά, η λύση είναι λιγότερα logs: χωρίς debug logs στο production και με sampling στα θορυβώδη access logs. Διαλέξτε retention με βάση και τη συμμόρφωση· ο οδηγός μας για GDPR και logging εξηγεί τι κρατάτε και πού.

7. Πρόγραμμα λειτουργίας για τα μη-production (μισή μέρα)

Τα development και staging περιβάλλοντα σπάνια χρειάζεται να τρέχουν νύχτες και Σαββατοκύριακα. Το να τα σταματάτε εκτός ωραρίου είναι από τις πιο απλές εξοικονομήσεις, γιατί η εβδομάδα έχει 168 ώρες και η εργάσιμη χρησιμοποιεί γύρω στις 50.

Φιλτράρετε το Cost Explorer με το tag environment ή ανά λογαριασμό. Στο ECS, κατεβάστε το desired count στο μηδέν με scheduled action· για EC2 και RDS, χρησιμοποιήστε το Instance Scheduler του AWS ή ένα μικρό Lambda από EventBridge. Προσοχή: ένα σταματημένο RDS instance ξεκινά ξανά μόνο του μετά από επτά μέρες.

8. Spot για CI και μη-production (μία με τρεις μέρες)

CI runners, batch jobs και μη-production workloads που αντέχουν διακοπή πρέπει να τρέχουν σε Spot. Το AWS αναφέρει έκπτωση έως 90% σε σχέση με On-Demand, με αντάλλαγμα ειδοποίηση διακοπής δύο λεπτών.

Στο ECS, το Fargate Spot είναι capacity provider που συνδυάζεται με κανονικό Fargate· το AWS το δίνει με έως 70% έκπτωση στην κανονική τιμή του Fargate. Στο EKS, χρησιμοποιήστε Karpenter ή managed node groups με πολλούς τύπους instances, ώστε να μη σταματά το cluster αν τελειώσει ένα Spot pool. Στο production βάλτε Spot μόνο για stateless workloads και αφού έχετε δοκιμάσει διακοπές.

9. Graviton (από ώρες για managed services, έως μέρες για δικά σας images)

Περάστε σε Graviton (Arm) όπου το υποστηρίζει το software σας. Το AWS αναφέρει ότι τα Graviton instances κοστίζουν έως 20% λιγότερο από αντίστοιχα x86.

Ξεκινήστε από managed services όπου αρκεί αλλαγή instance class: RDS, ElastiCache, OpenSearch. Για τα δικά σας containers, φτιάξτε multi-arch images στο CI με docker buildx build --platform linux/amd64,linux/arm64, τρέξτε τα tests σε Arm και αλλάξτε ένα service τη φορά. Native dependencies και παλιά base images είναι τα συνήθη εμπόδια.

10. Savings Plans και Reserved Instances (τελευταία, όταν σταθεροποιηθεί η χρήση)

Δεσμευτείτε μόνο για το baseline που είστε σίγουροι ότι θα τρέχει και σε έναν χρόνο, και μόνο αφού έχετε κάνει το καθάρισμα. Αν δεσμευτείτε πρώτα, απλώς κλειδώνετε τη σπατάλη με έκπτωση.

Για startup, η προεπιλογή μας είναι Compute Savings Plan, γιατί «επιβιώνει» από μια μετάβαση από EC2 σε Fargate, μια αλλαγή Region ή ένα migration σε Graviton. Χρησιμοποιήστε τα Savings Plans recommendations του Cost Explorer με lookback 30 ή 60 ημερών, δεσμευτείτε για λιγότερο από τη σύσταση και κοιτάτε κάθε μήνα τα reports coverage και utilization. Μικρότερες αγορές κάθε τρίμηνο είναι καλύτερες από μία μεγάλη που μπορεί να μετανιώσετε.

Για να κρατήσει

Οι εξοικονομήσεις ξεθωριάζουν αν δεν κοιτάζει κανείς το bill σε τακτά διαστήματα. Βάλτε στο ημερολόγιο ένα cost review 30 λεπτών κάθε μήνα: κορυφαία services, μεγαλύτερες αλλαγές από τον προηγούμενο μήνα, κόστος χωρίς tags, ανοιχτά anomaly alerts. Κρατήστε τις αλλαγές σε Terraform, ώστε το καθάρισμα να μην αναιρεθεί με το επόμενο apply· το πώς οργανώνετε το Terraform state κρίνει πόσο εύκολο θα είναι.

Αν προτιμάτε να περάσει κάποιος τους λογαριασμούς σας με αυτή τη λίστα και να σας δώσει ένα πλάνο με προτεραιότητες, αυτό ακριβώς κάνει το cloud audit μας. Τι ελέγχουμε, βήμα βήμα, θα το βρείτε στο άρθρο για το cloud audit που κάνουμε.

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

Ποιος είναι ο πιο γρήγορος τρόπος να μειώσω το κόστος AWS σε startup;

Ξεκινήστε με ownership και alerts και μετά σβήστε τους αχρησιμοποίητους πόρους: EBS volumes χωρίς instance, public IPv4 που δεν χρησιμοποιούνται, άδειους load balancers και ξεχασμένα test environments. Μετά διορθώστε την κίνηση από NAT gateway με VPC endpoints και ορίστε retention στα CloudWatch Logs. Θέλουν μέρες, όχι εβδομάδες, και κανένα commitment.

Savings Plans ή Reserved Instances για μια startup;

Για compute, το Compute Savings Plan είναι συνήθως η πιο ασφαλής επιλογή, γιατί καλύπτει EC2, Fargate και Lambda, κάθε instance family και κάθε Region. Αγοράστε το μόνο μετά το καθάρισμα και όταν η χρήση έχει σταθεροποιηθεί, για λιγότερο από τη σύσταση του Cost Explorer. Τα Reserved Instances ταιριάζουν σε σταθερές, μακροχρόνιες βάσεις δεδομένων.

Πώς βρίσκω τι ανεβάζει το κόστος στο AWS;

Στο Cost Explorer κάντε group by Service και μετά by Usage type για τους τρεις τελευταίους μήνες. Το Usage type δείχνει ξεχωριστά NAT gateway bytes, data transfer, EBS και log ingestion. Για ανάλυση ανά πόρο, κάντε export το Cost and Usage Report 2.0 σε S3 με resource IDs και τρέξτε queries με Athena.

Είναι ασφαλές το Spot για production;

Μόνο για stateless workloads που αντέχουν να χάσουν ένα instance με ειδοποίηση δύο λεπτών, και αφού το έχετε δοκιμάσει. Το Spot ταιριάζει καλύτερα σε CI runners, batch jobs και μη-production. Στο production, συνδυάστε Spot με On-Demand και πολλούς τύπους instances, ώστε να μη σας ρίξει ένα pool που τελείωσε.