In der ersten Augustwoche hat AWS Transform drei Launches ausgeliefert, die zusammen eine Migration vom Schema, das du noch nicht konvertiert hast, bis zur technischen Schuld abdecken, die du ein Jahr nach dem Cutover finden wirst. Am 3. August hat der Windows-Modernisierungs-Agent Offline-Schematransformation von SQL Server nach Aurora PostgreSQL bekommen, und Continuous Modernization ist generally available geworden; am 6. August hat der Migrations-Workflow gelernt, Post-Launch Actions über Systems Manager auszuführen. Drumherum hat Lambda bis zu 3.000 Mbit/s Netzwerkbandbreite bekommen, Aurora Serverless hat gelernt, in einer Sekunde auf 12 ACUs zu springen, und die Load Balancer haben TLS-Policies auf NSA-Niveau aufgenommen.

Die These der Woche: AWS verkauft Transform nicht mehr als Rehost-Tool mit KI-Etikett. Es füllt die Teile einer Migration, die früher das Spreadsheet eines Partners waren, und das ändert, was du von Hand zu tun erwarten solltest.

AWS Transform: Schema, Cutover und das Jahr danach

Nimm die drei in Migrationsreihenfolge. Die Offline-Schematransformation akzeptiert SQL-Server-DDL-Dateien, du brauchst also keine Live-Verbindung zur Quelle. Sie bewertet die Komplexität von Datenbank und Stored Procedures, lässt dich den erzeugten Plan bearbeiten, konvertiert dann Tabellen, Schemas, Stored Procedures und Functions, validiert funktionale Äquivalenz und deployt das Ergebnis nach Aurora PostgreSQL. Die Konvertierung von Storage-Objekten läuft unter der Haube über AWS DMS. Vorerst nur US East (N. Virginia). Der Offline-Teil zählt mehr, als es klingt: Die Teams, die eine Datenbankmigration nicht starten können, sind meistens die, deren DBAs einem Konvertierungstool keinen Port öffnen. Ein DDL-Dump ist ein leichteres Gespräch.

Post-Launch Actions schließen die Lücke zwischen "der Server ist in AWS gebootet" und "der Server ist wirklich unserer". Du definierst Actions einmal auf Account-Ebene, und Transform wendet sie auf jeden Quellserver an, über Ziel-Accounts in einer Multi-Account-Migration hinweg, und führt sie über AWS Systems Manager direkt nach einem Test- oder Cutover-Launch aus. Vordefinierte Actions oder dein eigenes SSM-Dokument. Die Migrations-Inventory-Datei bekommt außerdem eine Struktur für die Prüfung pro Server. Wer MGN im großen Maßstab betrieben hat, kennt den Failure Mode, den das beseitigt: Eine Wave von 80 Servern landet, und jemand führt die CloudWatch-Agent-Installation auf 79 davon von Hand aus.

Continuous Modernization ist das Stück, das auf das Danach zielt. Es verbindet sich mit GitHub-Organisationen, GitLab-Gruppen und Bitbucket-Workspaces, läuft auf Abruf oder nach Zeitplan, ordnet Befunde nach technischer Schuld, Sicherheit, Agentic Readiness und Modernization Readiness, und für Befunde mit Fix öffnet es Pull oder Merge Requests mit validierten Änderungen. Die Analyse läuft in deinem eigenen Account unter deinen Credentials, und du kannst sie aus der Web-App, der CLI, Kiro oder als Agenten-Plugin steuern. Der Trade-off ist derselbe, den jedes automatisierte PR-Tool trägt: Review-Kapazität. Ein geplanter Scanner, der PRs schneller öffnet, als das Team sie lesen kann, wird innerhalb eines Quartals zu Rauschen. Beginne mit einer Repository-Gruppe und einem strikten Rangfilter.

Lambda-Bandbreite: 3.000 Mbit/s, wenn du nicht in einer VPC bist

Die Lambda-Netzwerkbandbreite skaliert jetzt mit dem Speicher für Funktionen ab 2 GB, von 625 Mbit/s bei 2 GB bis 3.000 Mbit/s bei 10 GB, und ersetzt die flache Obergrenze von 625 Mbit/s. Kein Aufpreis, alle kommerziellen Regionen. Zwei Vorbehalte begleiten den Launch. Erstens ist es Opt-in über einen Service-Quotas-Antrag auf die Quota "Network bandwidth per execution environment", nach dem jede Nicht-VPC-Funktion im Account automatisch skaliert. Zweitens, und wichtiger: Es gilt nur für Funktionen außerhalb einer VPC. Die meisten Enterprise-Funktionen, die große Objekte bewegen, sind in einer, weil dort die RDS-Instance und der private S3-Endpunkt leben. Wenn deine schweren S3-zu-S3-Transformationen in einer VPC laufen, hat diese Woche für dich nichts geändert. Prüfe mit aws lambda get-function-configuration --function-name X --query VpcConfig, bevor du den Quota-Antrag stellst.

Aurora Serverless: 12 ACUs in einer Sekunde

Aurora Serverless erreicht beim Hochskalieren jetzt bis zu 12 ACUs innerhalb einer Sekunde, geht weiter bis 256 und skaliert danach weiterhin auf null. Es ist standardmäßig an für Cluster auf Plattformversion 3 oder 4; Versionen 1 und 2 können direkt auf 4 upgraden. Prüfe deine mit dem Feld ServerlessV2PlatformVersion aus describe-db-clusters. AWS rahmt das um agentische Workloads, was fair ist: Ein Agenten-Fan-out ist genau der Burst, der früher seine ersten 30 Sekunden mit Warten auf Kapazität verbracht hat. Der Failure Mode sind Kosten. Ein Cluster, der bisher sanft hochgefahren ist, trifft jetzt 12 ACUs bei einer Spitze, die bei 2 absorbiert worden wäre. Setze einen CloudWatch-Alarm auf ServerlessDatabaseCapacity, bevor du die Plattformversion upgradest, nicht nach der ersten Rechnung.

Auch diese Woche

Der rote Faden

Lies die Transform-Launches neben denen von Lambda und Aurora, und das Muster handelt davon, wo sich die manuelle Arbeit versteckt hat. Schemakonvertierung hat sich hinter einer Firewall-Regel versteckt, die niemand genehmigen wollte. Post-Launch-Konfiguration hat sich in einem Runbook versteckt. Technische Schuld hat sich im Backlog versteckt. Lambdas Bandbreitenobergrenze hat sich hinter einer Quota versteckt, und Auroras Hochfahren in den ersten 30 Sekunden jeder Spitze. AWS hat die Woche damit verbracht, Verstecke zu beseitigen. Der Preis dafür ist jedes Mal derselbe: Die Defaults werden aggressiver, und das Plattform-Team muss vorab entscheiden, welche dieser Defaults es wirklich will.

Lies das als Nächstes

Für die KI- und Agenten-Lesart derselben Woche leben die Field Notes auf ercan.ai. Consulting zu AWS, Cloud, CI/CD-Pipelines, Linux, GitHub/GitLab und mehr läuft über ercanermis.com.

Referenzen