Observability σε 100 AWS accounts, σε πλατφόρμα εθνικής κλίμακας

Το πρόβλημα

Ένα AWS Landing Zone με περίπου εκατό λογαριασμούς. Κάποιοι είχαν είκοσι με σαράντα compute resources, άλλοι λιγότερα από δέκα, και όλοι άλλαζαν από εβδομάδα σε εβδομάδα. Οι πόροι εμφανίζονταν και εξαφανίζονταν πιο γρήγορα από όσο προλάβαινε κανείς να συντηρήσει παρακολούθηση με το χέρι.

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

Ο τρόπος που αποτυγχάνει δεν είναι ένα dashboard που λείπει. Είναι ένας πόρος που δεν παρακολουθεί κανείς, απόλυτα ήσυχος, μέχρι τη στιγμή που δεν είναι.

Τι έφτιαξα

Provisioning alarms που αντιδρούσε στο περιβάλλον αντί να το περιγράφει. Όταν οποιοσδήποτε σε οποιονδήποτε λογαριασμό δημιουργούσε EC2 instance, workload σε ECS ή EKS, application load balancer ή NAT gateway, η παρακολούθηση προσαρτιόταν μόνη της. Χωρίς αίτημα, χωρίς χειροκίνητο βήμα, χωρίς εξάρτηση από αυτόν που το δημιούργησε.

Τα load balancers και τα NAT gateways βρίσκονται σε αυτή τη λίστα σκόπιμα. Τα περισσότερα περιβάλλοντα παρακολουθούν compute και σταματούν εκεί, που είναι όπου πάει η προσοχή αλλά όχι όπου διαρρέουν τα χρήματα. Ένα αδρανές load balancer χρεώνει ήσυχα για πάντα, και η επεξεργασία δεδομένων σε NAT gateway είναι από τους πιο αξιόπιστους τρόπους να εκπλαγείς με έναν λογαριασμό AWS.

Αρχιτεκτονική

Hub and spoke. Κάθε λογαριασμός είχε μόνο έναν κανόνα EventBridge· η λογική ζούσε μία φορά, στον master λογαριασμό, και έφτανε πίσω σε κάθε child μέσω assumed role. Ένα σημείο για αλλαγή συμπεριφοράς, ένα σημείο για debugging, και τίποτα να κρατηθεί σε συγχρονισμό ανάμεσα σε εκατό αντίγραφα.

Child account · ένας από ~100

EC2

ECS

EKS

ALB

NAT Gateway

δημιουργία ή διαγραφή

1

Κανόνας EventBridgeπροωθεί το event εκτός του λογαριασμού

alarms γράφονται πίσω

4

CloudWatchalarms προστίθενται ή αφαιρούνται, μαζί με το dashboard

Master account

2

Custom event busδέχεται events από κάθε λογαριασμό

καλεί

3

Alarm managerπαίρνει cross-account role και προσθέτει ή αφαιρεί alarms

σε alarm

5

SNSειδοποίηση με email

και

6

Slack notifierμορφοποιεί το ίδιο alarm για το κανάλι της ομάδας

1. Κάποιος σε child λογαριασμό δημιουργεί ή διαγράφει EC2 instance, workload σε ECS ή EKS, ALB ή NAT gateway.
2. Ένας κανόνας EventBridge σε εκείνον τον λογαριασμό προωθεί το event σε custom bus στον master λογαριασμό.
3. Το bus καλεί μια Lambda, που παίρνει cross-account role πίσω στον λογαριασμό προέλευσης.
4. Προσθέτει τα alarms, ή τα αφαιρεί αν ο πόρος έχει φύγει. Ίδια διαδρομή και προς τις δύο κατευθύνσεις.
5. Ένα alarm που χτυπά δημοσιεύει σε SNS, που στέλνει το email.
6. Μια δεύτερη Lambda μορφοποιεί το ίδιο event για το Slack.

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

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

Η διαγραφή ακολουθούσε την ίδια διαδρομή

Η αφαίρεση ενός πόρου πυροδοτούσε την ίδια ροή και έπαιρνε μαζί της τα alarms του. Αυτό το μισό συνήθως παραλείπεται, και η παράλειψή του κοστίζει και προς τις δύο κατευθύνσεις: τα ορφανά alarms χρεώνονται κάθε μήνα για πάντα, και χτυπούν πάνω σε μετρικές που σταμάτησαν να αναφέρουν, οπότε το κανάλι γεμίζει θόρυβο για πράγματα που δεν υπάρχουν πια.

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

Η κατασκευή της συμμετρικής διαδρομής είναι η διαφορά ανάμεσα σε κάτι που κάνει καλό demo και σε κάτι που μπορείς να αφήσεις να τρέχει για έναν χρόνο.

Γιατί αυτές οι μετρικές

Τα alarms δεν ήταν γενικής υγιεινής. Παρατεταμένο υψηλό CPU σε συνδυασμό με υψηλή κίνηση δικτύου είναι η υπογραφή του compute που καταναλώνεται από κάτι που δεν ενέκρινε κανείς: ένα credential που διέρρευσε και μετατρέπεται σε λογαριασμό, το μοτίβο κατάχρησης που κάθε μεγάλο περιβάλλον πολλαπλών λογαριασμών οφείλει να θεωρεί δεδομένο ότι κάποια στιγμή θα το συναντήσει.

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

Ένα workload που συμπεριφέρεται περίεργα φαίνεται το ίδιο στις μετρικές είτε η αιτία είναι bug, είτε λάθος ρύθμιση, είτε εισβολέας.

Και αυτή ακριβώς είναι η χρήσιμη ιδιότητα. Τα ίδια alarms που αναδεικνύουν ένα ξεχασμένο περιβάλλον δοκιμών αναδεικνύουν και ένα μη εξουσιοδοτημένο, γιατί σε επίπεδο CPU και δικτύου πρόκειται για το ίδιο γεγονός: κάτι τρέχει που δεν θα έπρεπε. Όταν η κάλυψη είναι αυτόματη, δεν χρειάζεται να ξέρεις εκ των προτέρων ποιο από τα δύο ψάχνεις.

Η αναφορά ήρθε πρώτη

Η αναφορά κατανάλωσης ήταν ξεχωριστό εργαλείο σε δικό της pipeline, φτιαγμένη πάνω σε δεδομένα κόστους και χρήσης, και κατασκευάστηκε πριν από τον αυτοματισμό των alarms. Αυτή η σειρά ήταν σκόπιμη. Δεν μπορείς να αυτοματοποιήσεις λογικά ένα περιβάλλον που δεν βλέπεις ακόμη, και μια αναλυτική εικόνα του πού πήγαιναν τα χρήματα υπήρχε μέσα σε μέρες αντί για το τέλος του έργου.

Έφτανε ως ένα ενιαίο καθημερινό μήνυμα στο κανάλι Slack των υπευθύνων του έργου, όχι ως συνημμένο σε email. Η αναφορά δαπανών αλλάζει συμπεριφορά μόνο αν τη διαβάζουν όσοι μπορούν να δράσουν, και αυτό σημαίνει να φτάνει εκεί όπου βρίσκονται ήδη.

Παράδοση γνώσης

Πριν αποχωρήσω, εκπαίδευσα πρακτικά δύο συναδέλφους στον αυτοματισμό πολλαπλών λογαριασμών και στη ροή cross-account deployment. Ένας αυτοματισμός που δεν μπορεί να χειριστεί κανείς άλλος είναι υποχρέωση μεταμφιεσμένη σε περιουσιακό στοιχείο.

Τεχνολογίες