Die Woche vom 7. September war die Woche, in der AWS Transform für .NET aufgehört hat, ein Werkzeug zu sein, durch das du dich klickst, und zu einem Schritt geworden ist, den du in eine Pipeline stellst. Eine einzeilige CLI ist generally available geworden, dieselbe Transformation hat angefangen, Unit-Tests für den Code zu erzeugen, den sie umschreibt, und AWS Transform hat GovCloud (US-West) für Server-Migration erreicht. Drumherum haben Lambda Managed Instances ein 90-Minuten-Timeout und Graviton5 bekommen, EBS Volume Clones haben gelernt, Account-Grenzen mit Neuverschlüsselung zu überschreiten, und ein 42U-Single-Rack-Outposts ist GA geworden.

AWS Transform für .NET: CLI, Tests, GovCloud

Drei Launches, eine Richtung. Am 9. September ist AWS Transform for .NET modernization über die CLI generally available geworden: Ein einziger Befehl stößt eine AWS-verwaltete Transformation in AWS Transform custom an, und du kannst sie interaktiv ausführen oder in eine bestehende Pipeline skripten, um sie unbeaufsichtigt laufen zu lassen. Die Transformation umfasst 50.000 kostenlose Agenten-Minuten pro Monat und ist in acht Regionen verfügbar: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt und London.

Am 10. September hat AWS Transform for .NET angefangen, Unit-Tests für modernisierten Code zu erzeugen. Es bewertet die Anwendung parallel zum Standard-.NET-Assessment auf Testbarkeit, plant, welche Klassen und Methoden abgedeckt werden (Geschäftslogik, Controller), und gibt den Testcode als Teil desselben Jobs aus. Opt-in, aktiviert beim Job-Start oder nach Abschluss der Transformation, aktuell über das AWS Toolkit for Visual Studio.

Und am 8. September ist AWS Transform in AWS GovCloud (US-West) angekommen. Der Umfang zählt: Das ist die Server-Migrationsfähigkeit (VMware, Bare Metal, Hyper-V, Datenbank-Workloads, Replikation und Cutover in eine der beiden GovCloud-Regionen). Modernisierung, Custom Transformation und Assessment bleiben vorerst in kommerziellen Regionen.

Die CLI ist das, was zählt: Eine Modernisierung, die in einer IDE lebt, ist ein Projekt, eine Modernisierung, die in CI läuft, ist ein Prozess. Du kannst die Transformation nächtlich auf einem Branch laufen lassen, die Ausgabe gegen die von gestern diffen und den Agenten wie jeden anderen Build-Schritt behandeln, der entweder durchläuft oder nicht. So modernisierst du 80 Services statt 8.

Der Failure Mode, für den du planen musst, sind die Tests. Eine aus dem transformierten Code erzeugte Testsuite kodiert das Verhalten des transformierten Codes. Sie ist ein Regressionsnetz für alles, was du nach der Migration änderst, und das ist wertvoll, aber sie beweist nicht, dass die Migration das Verhalten des .NET-Framework-Originals erhalten hat. Dafür brauchst du weiterhin die alte Suite, oder Charakterisierungstests, die gegen das alte Binary geschrieben wurden und gegen das neue laufen. Nutze die erzeugten Tests als Boden, nicht als Abnahme.

Lambda Managed Instances: 90 Minuten und Graviton5

Am 9. September hat Lambda ein 90-Minuten-Funktions-Timeout auf Lambda Managed Instances hinzugefügt, für asynchrone und Event-Source-Mapping-Invocations, sechsmal die 15-Minuten-Obergrenze, die Lambda-Architektur ein Jahrzehnt lang definiert hat. Synchrone Invocations behalten 15 Minuten. Das längere Limit gilt auch für Schritte innerhalb von Lambda Durable Functions. Am selben Tag haben Managed Instances Graviton5-gestützte C9g-, C9gd-, M9g- und M9gd-Instances bekommen, die AWS mit bis zu 25 % mehr Rechenleistung als Graviton4 angibt.

Managed Instances haben bereits das Preismodell geändert (EC2-Instance-Ökonomie, mehrere gleichzeitige Requests pro Instance), und diese Änderung führt den Gedanken zu Ende: Es ist eine verwaltete Compute-Flotte mit einem funktionsförmigen Programmiermodell. Medien-Transcodes, Monte-Carlo-Läufe und Batch-Inferenz brauchen keine Step-Functions-Kette oder ECS-Task mehr, nur um über Minute fünfzehn hinauszukommen.

Was sich nicht ändert: Asynchrone Invocations sind At-least-once. Ein 90-Minuten-Job, der nach einem Teilausfall wiederholt wird, kostet dich zweimal 90 Minuten und hinterlässt, wenn er unterwegs schreibt, ein halb geschriebenes Ergebnis. Idempotenzschlüssel und Checkpointing zählen bei 90 Minuten mehr, nicht weniger. Und weil Managed Instances als EC2-Kapazität abgerechnet werden, mach den Kostenvergleich mit einem Fargate-Task oder einem AWS-Batch-Job explizit, bevor du einen langlaufenden Workload umziehst; der Gewinn ist operativ, nicht automatisch finanziell.

EBS Volume Clones wechseln Accounts, mit neuen Keys

Am 9. September haben EBS Volume Clones angefangen, Kopien über AWS-Accounts hinweg zu unterstützen, mit Neuverschlüsselung durch einen KMS Key im Ziel-Account. Der Ablauf: Teile das Quell-Volume über AWS RAM, dann erstellt der Ziel-Account eine Kopie in derselben Availability Zone. Funktioniert für alle Volume-Typen, inklusive unverschlüsselter Volumes und Volumes unter Customer Managed Keys.

Der Anwendungsfall, mit dem AWS führt, ist der richtige: eine frische Kopie eines Produktions-Datenbank-Volumes in einem isolierten Entwicklungs-Account. Der alte Weg war Snapshot, Snapshot teilen, Snapshot mit neuem Key kopieren, Volume erstellen, vier Schritte und viel Warten. Der neue Weg ist eine Kopie mit eingebauter Key-Trennung, und das ist, was die Regel "Prod-Keys verlassen Prod nie" einer Landing Zone tatsächlich verlangt.

Zwei Dinge, die ein Plattform-Team aufschreiben sollte. Erstens: "Dieselbe Availability Zone" meint dieselbe physische Zone, und Zonennamen (eu-west-1a) mappen pro Account unterschiedlich. Nutze AZ-IDs (euw1-az1) in jeder Automatisierung, sonst landet die Kopie in einer Zone, die deine Dev-Subnetze nicht abdecken. Zweitens: Produktionsdaten nach Dev zu klonen ist ein Data-Governance-Ereignis, kein Storage-Ereignis. Stelle den RAM-Share hinter eine Freigabe und logge, wer was kopiert hat; einfache Mechanismen brauchen explizite Kontrollen.

Auch diese Woche

Der rote Faden

Jede Schlagzeile dieser Woche hat etwas von "ein Mensch macht es" zu "eine Pipeline macht es" verschoben. Transform läuft aus der CLI und schreibt seine eigenen Tests. Lambda hält einen Job 90 Minuten, damit du aufhörst, um Minute fünfzehn herum Orchestrierung von Hand zu bauen. EBS kopiert ein Prod-Volume mit dem richtigen Key in einer Operation nach Dev. Systems Manager sagt dir, warum die Instance unmanaged ist, statt dich raten zu lassen. Jedes davon entfernt einen menschlichen Schritt aus einem Prozess, der früher einen brauchte. Die Arbeit für ein Plattform-Team ist zu entscheiden, welche dieser Schritte aus gutem Grund da waren (die Freigabe, bevor Prod-Daten Prod verlassen), und sie bewusst zu behalten, jetzt, wo das Tooling dich nicht mehr dazu zwingt.

Lies das als Nächstes

Für die KI- und Agenten-Lesart derselben Woche siehe ercan.ai. Wenn dein Team Hands-on-Hilfe bei AWS, Cloud-Architektur, CI/CD-Pipelines, Linux, GitHub oder GitLab und der Plattformarbeit darum herum braucht, lebt die Consulting-Seite auf ercanermis.com.

Referenzen