Την πρώτη εβδομάδα του Αυγούστου, το AWS Transform κυκλοφόρησε τρία launches που μαζί καλύπτουν ένα migration από το schema που δεν έχετε μετατρέψει ακόμα ως το τεχνικό χρέος που θα βρείτε έναν χρόνο μετά το cutover. Στις 3 Αυγούστου ο agent Windows modernization απέκτησε offline μετατροπή schema από SQL Server σε Aurora PostgreSQL και το continuous modernization έγινε γενικά διαθέσιμο. Στις 6 Αυγούστου το migration workflow έμαθε να τρέχει post-launch actions μέσω Systems Manager. Γύρω από αυτά, η Lambda απέκτησε έως 3.000 Mbps network bandwidth, το Aurora Serverless έμαθε να πηδά στα 12 ACUs σε ένα δευτερόλεπτο, και οι load balancers πήραν TLS policies επιπέδου NSA.

Η θέση της εβδομάδας: η AWS δεν πουλά πλέον το Transform ως εργαλείο rehost με ετικέτα AI. Συμπληρώνει τα μέρη ενός migration που ήταν παλιά το spreadsheet ενός partner, και αυτό αλλάζει τι πρέπει να περιμένετε να κάνετε με το χέρι.

AWS Transform: schema, cutover, και ο χρόνος μετά

Πάρτε τα τρία με τη σειρά του migration. Η offline μετατροπή schema δέχεται αρχεία DDL του SQL Server, οπότε δεν χρειάζεστε ζωντανή σύνδεση με την πηγή. Αξιολογεί την πολυπλοκότητα βάσης και stored procedures, σάς αφήνει να επεξεργαστείτε το παραγόμενο πλάνο, μετά μετατρέπει πίνακες, schemas, stored procedures και functions, επαληθεύει τη λειτουργική ισοδυναμία, και αναπτύσσει το αποτέλεσμα σε Aurora PostgreSQL. Η μετατροπή των storage objects τροφοδοτείται από το AWS DMS από κάτω. Είναι μόνο US East (N. Virginia) προς το παρόν. Το offline κομμάτι μετράει περισσότερο απ' όσο ακούγεται: οι ομάδες που δεν μπορούν να ξεκινήσουν ένα database migration είναι συνήθως αυτές των οποίων οι DBAs δεν θα ανοίξουν port σε ένα εργαλείο μετατροπής. Ένα DDL dump είναι ευκολότερη συζήτηση.

Τα post-launch actions κλείνουν το κενό ανάμεσα στο "ο server έκανε boot στο AWS" και το "ο server είναι πραγματικά δικός μας". Ορίζετε actions μία φορά σε επίπεδο λογαριασμού, και το Transform τα εφαρμόζει σε κάθε source server, σε όλους τους target accounts ενός multi-account migration, τρέχοντάς τα μέσω AWS Systems Manager αμέσως μετά από ένα test ή cutover launch. Προκαθορισμένα actions ή δικό σας SSM document. Το inventory file του migration αποκτά επίσης δομή για επισκόπηση ανά server. Αν έχετε τρέξει MGN σε κλίμακα, ξέρετε τον τρόπο αστοχίας που αυτό αφαιρεί: ένα wave 80 servers προσγειώνεται και κάποιος τρέχει την εγκατάσταση του CloudWatch agent με το χέρι στους 79 από αυτούς.

Το continuous modernization είναι το κομμάτι που στοχεύει σε αυτό που συμβαίνει μετά. Συνδέεται σε GitHub organizations, GitLab groups και Bitbucket workspaces, τρέχει κατ' απαίτηση ή σε χρονοδιάγραμμα, ιεραρχεί ευρήματα κατά τεχνικό χρέος, ασφάλεια, agentic readiness και modernization readiness, και για ευρήματα με διόρθωση ανοίγει pull ή merge requests με επικυρωμένες αλλαγές. Η ανάλυση τρέχει στον δικό σας λογαριασμό με τα δικά σας credentials, και μπορείτε να την οδηγήσετε από το web app, το CLI, το Kiro, ή ως agent plugin. Το trade-off είναι το ίδιο που κουβαλά κάθε εργαλείο αυτοματοποιημένων PR: χωρητικότητα επισκόπησης. Ένας προγραμματισμένος scanner που ανοίγει PRs ταχύτερα απ' όσο μπορεί να τα διαβάσει η ομάδα γίνεται θόρυβος μέσα σε ένα τρίμηνο. Ξεκινήστε με ένα repository group και ένα αυστηρό φίλτρο κατάταξης.

Lambda bandwidth: 3.000 Mbps, αν δεν είστε σε VPC

Το network bandwidth της Lambda κλιμακώνεται πλέον με τη μνήμη για functions με 2 GB ή περισσότερα, από 625 Mbps στα 2 GB έως 3.000 Mbps στα 10 GB, αντικαθιστώντας το σταθερό ταβάνι των 625 Mbps. Χωρίς επιπλέον χρέωση, σε όλα τα εμπορικά Regions. Δύο επιφυλάξεις συνοδεύουν το launch. Πρώτον, είναι opt-in μέσω αιτήματος Service Quotas στο quota "Network bandwidth per execution environment", μετά το οποίο κάθε non-VPC function στον λογαριασμό κλιμακώνεται αυτόματα. Δεύτερον, και σημαντικότερο, ισχύει μόνο για functions έξω από VPC. Τα περισσότερα enterprise functions που μετακινούν μεγάλα αντικείμενα είναι μέσα σε ένα, γιατί εκεί ζουν το RDS instance και το private S3 endpoint. Αν οι βαριές S3-σε-S3 μετατροπές σας τρέχουν σε VPC, αυτή η εβδομάδα δεν άλλαξε τίποτα για εσάς. Ελέγξτε με aws lambda get-function-configuration --function-name X --query VpcConfig πριν υποβάλετε το αίτημα quota.

Aurora Serverless: 12 ACUs σε ένα δευτερόλεπτο

Το Aurora Serverless φτάνει πλέον έως 12 ACUs μέσα σε ένα δευτερόλεπτο κατά το scale-up, συνεχίζει έως 256, και εξακολουθεί να κλιμακώνεται στο μηδέν μετά. Είναι ενεργό εξ ορισμού για clusters σε platform version 3 ή 4. Οι εκδόσεις 1 και 2 μπορούν να αναβαθμιστούν απευθείας στην 4. Ελέγξτε τη δική σας με το πεδίο ServerlessV2PlatformVersion από το describe-db-clusters. Η AWS το πλαισιώνει γύρω από agentic workloads, που είναι δίκαιο: ένα fan-out agent είναι ακριβώς η έκρηξη που παλιά ξόδευε τα πρώτα 30 δευτερόλεπτά της περιμένοντας χωρητικότητα. Ο τρόπος αστοχίας είναι το κόστος. Ένα cluster που προηγουμένως ανέβαινε ήπια χτυπά τώρα 12 ACUs σε μια αιχμή που θα απορροφιόταν στα 2. Βάλτε CloudWatch alarm στο ServerlessDatabaseCapacity πριν αναβαθμίσετε την platform version, όχι μετά τον πρώτο λογαριασμό.

Επίσης αυτή την εβδομάδα

Το κοινό νήμα

Διαβάστε τα launches του Transform δίπλα σε αυτά της Lambda και της Aurora και το μοτίβο αφορά το πού κρυβόταν η χειρωνακτική δουλειά. Η μετατροπή schema κρυβόταν πίσω από έναν κανόνα firewall που κανείς δεν θα ενέκρινε. Η διαμόρφωση μετά το launch κρυβόταν σε ένα runbook. Το τεχνικό χρέος κρυβόταν στο backlog. Το ταβάνι bandwidth της Lambda κρυβόταν πίσω από ένα quota, και η ανάβαση της Aurora κρυβόταν στα πρώτα 30 δευτερόλεπτα κάθε αιχμής. Η AWS ξόδεψε την εβδομάδα αφαιρώντας κρυψώνες. Το κόστος αυτού είναι κάθε φορά το ίδιο: οι προεπιλογές γίνονται πιο επιθετικές, και η ομάδα platform πρέπει να αποφασίσει, εκ των προτέρων, ποιες από αυτές τις προεπιλογές θέλει πραγματικά.

Διαβάστε στη συνέχεια

Για την ανάγνωση της ίδιας εβδομάδας από την πλευρά του AI και των agents, οι σημειώσεις πεδίου ζουν στο ercan.ai. Η συμβουλευτική σε AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab και άλλα περνά από το ercanermis.com.

Αναφορές