Die Woche vom 22. bis 28. Juni 2026 hat Plattform-Teams drei Governance-Primitive gegeben, die sie bisher mit Tags und Wiki-Seiten vorgetäuscht haben: AMI-Wasserzeichen, die Kopien, Regionen und Account-Shares überleben; Lambda MicroVMs, die nicht vertrauenswürdigen Code in eine eigene virtuelle Maschine stecken; und einen korrigierten Network-Firewall-Default, der lautlos legitime Server-zu-Client-Pakete verworfen hat. Auf der Migrationsseite landet AWS Transform Workloads jetzt in jeder kommerziellen Region, und OpenSearch und MSK haben beide agentengeführte Migrationspfade ausgeliefert.

Kein Summit diese Woche, also sind die Launches kleiner und nützlicher: Jedes Hauptthema ist etwas, worüber du letztes Jahr ein Policy-Dokument geschrieben und gehofft hättest, dass die Leute sich daran halten.

Migration: jede Region, und zwei weitere agentengeführte Pfade

AWS Transform for migrations unterstützt jetzt alle kommerziellen AWS-Regionen als Migrationsziele, veröffentlicht am 22. Juni. Die Zielregion ist die, in der Landing Zone, Netzwerk und rehostete Server deployt werden, und die Ankündigung fügt 16 davon hinzu: US West (N. California), Africa (Cape Town), Asia Pacific (Bangkok, Hong Kong, Hyderabad, Jakarta, Kuala Lumpur, Melbourne, New Zealand, Taipei), Canada (Calgary), Europe (Milan, Spain, Zurich), Mexico (Querétaro) und Middle East (Tel Aviv). Für europäische Leser sind Zürich, Mailand und Spanien die, die "der Agent kann es nicht dort landen, wo Legal sagt, dass es liegen muss" von einem Blocker zu einem Dropdown machen.

Zwei datenbanknahe Launches in derselben Woche folgen dem Muster der MGN-Umbenennung: Die Migrationslogik wandert in etwas, das ein Agent steuert. Amazon OpenSearch Service bietet jetzt KI-gestützte Migrationen (23. Juni): Migration Assistant bekommt einen agentengeführten Workflow, nutzbar aus Kiro, Claude Code und anderen, um den Umzug von selbst verwaltetem Solr, Elasticsearch oder OpenSearch auf OpenSearch Serverless oder Managed Clusters zu planen, die Infrastruktur zu deployen und historische plus Live-Traffic-Migration durchzuführen, wobei Capture-and-Replay jetzt Solr abdeckt. Amazon MSK AI Agent Skills (22. Juni) geben Kiro, Claude Code und Cursor Expertenanleitung für Sizing, Troubleshooting, Monitoring und die Migration externer Kafka-Cluster nach MSK Express.

Der Trade-off bei Skills als Verteilungsmechanismus ist Versionskontrolle: Ein Runbook in deinem Repo hat eine Commit-History, ein zur Laufzeit gezogener Vendor-Skill ist ein Prompt, den du nicht diffen kannst. Für eine einmalige Migration in Ordnung. Für vierzig identische Cluster exportiere, was der Agent beim ersten Mal getan hat, in etwas, das dir gehört.

AMI-Wasserzeichen: Herkunft, die in der Kopie nicht verloren geht

Amazon EC2 hat am 24. Juni AMI Watermarks angekündigt. Du bettest einen eigenen Identifier in ein privates AMI ein, und er wandert in jedes davon abgeleitete AMI weiter: Kopien in andere Regionen, Images aus einer laufenden Instance und Images, die mit anderen Accounts geteilt werden. Jedes Wasserzeichen trägt die ursprüngliche AMI-ID, den Owner, die Region und die Erstellungszeitstempel. Die Durchsetzungshälfte ist der Punkt: Kombiniere Wasserzeichen mit Allowed AMIs, um Launches auf Images mit einem freigegebenen Wasserzeichen zu beschränken, und wende das organisationsweit mit Declarative Policies an. EC2 Image Builder kann ein Wasserzeichen in der Pipeline anhängen. Alle Regionen inklusive GovCloud und China, kostenlos.

Das Loch, das das schließt, ist konkret. Golden-AMI-Programme erzwingen "nur aus Account X starten" mit Allowed AMIs. Sobald ein Team das Golden Image zum ersten Mal in den eigenen Account kopiert, um ein Paket hinzuzufügen, ist die Herkunft weg, und die Policy blockiert es entweder (also hören sie auf, das Golden Image zu nutzen) oder erlaubt ihren Account (also bedeutet die Policy nichts). Ein Wasserzeichen, das die Kopie überlebt, lässt dich stattdessen sagen: "Starte alles, was vom Golden Image abstammt."

Sei präzise bei dem, was es beweist. Ein Wasserzeichen ist Provenienz, nicht Integrität: Es sagt, dass das Image von einem Build abstammt, den du freigegeben hast, nicht, dass sich im abgeleiteten Image oder danach auf der Instance nichts geändert hat. Es ersetzt tag-basierte Herkunft; es ersetzt nicht Inspector, SSM Compliance oder Image Signing.

Lambda MicroVMs: eine VM pro nicht vertrauenswürdiger Session

AWS hat am 22. Juni Lambda MicroVMs eingeführt: ein Serverless-Primitiv, das jedem Nutzer oder Job eine eigene, Firecracker-isolierte VM mit eigenem Kernel gibt, mit Suspend und Resume bei intaktem Memory- und Disk-Zustand für bis zu 8 Stunden Gesamtlaufzeit und einem dedizierten HTTPS-Endpunkt mit HTTP/2, gRPC und WebSockets. Die Limits pro MicroVM sind 16 vCPUs, 32 GB Memory, 32 GB Disk, nur ARM64. Laut Launch-Beitrag baust du ein Image aus einem Dockerfile mit aws lambda-microvms create-microvm-image, startest mit aws lambda-microvms run-microvm und einer Idle Policy und zahlst Baseline-Compute, solange sie läuft. Verfügbar in US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) und Asia Pacific (Tokyo).

Ich habe darüber ausführlich in AWS Lambda MicroVMs: Serverless bekommt eine zustandsbehaftete, isolierte Sandbox geschrieben. Die Kurzfassung: Die Designfrage ist nicht "Functions oder MicroVMs", sondern "was in meinem System führt Code aus, den ich nicht geschrieben habe". Notebooks, Kunden-Plugins und alles, was ein LLM erzeugt, gehören hinter eine VM-Grenze mit Lifecycle, und bis diese Woche hieß das: eine eigene Firecracker-Flotte oder ein Container pro Tenant. Der Agenten-Blickwinkel steht auf ercan.ai.

Network Firewall korrigiert einen Default, der Verbindungen kaputtgemacht hat

AWS Network Firewall hat am 22. Juni seine Default-Drop-Action aktualisiert. Neue Firewall-Policies setzen die Stateful Action jetzt standardmäßig auf "Application drop established (server-directed only)". Der vorherige Default, "Application drop established (bidirectional)", konnte legitime Server-zu-Client-TCP-Pakete wie Window Updates, Keep-alives und Resets lautlos verwerfen, was sich als sporadische Verbindungsfehler zeigte, die niemand reproduzieren konnte. Bestehende Policies werden nicht automatisch geändert; AWS verweist für deren Aktualisierung auf die Dokumentation und merkt an, dass Umgebungen, die die bidirektionale Action für fragmentierte Post-Quantum-TLS-Handshakes brauchen, umschalten oder ein to_server-Flag an ihre TCP-Drop-Regeln anhängen können.

Das ist der Punkt, den du heute angehen solltest, weil es eine Änderung an einem Default ist und kein Feature. Jede aws_networkfirewall_firewall_policy in deinem Terraform, die aus einem alten Beispiel kopiert wurde, trägt den alten Default. Greppe nach den Stateful Default Actions, vergleiche mit der neuen Empfehlung und rolle die Änderung zuerst durch Staging. Wenn du ein ungeklärtes Ticket zu sporadischen Timeouts gegen etwas hinter Network Firewall offen hast, hast du vielleicht gerade die Ursache gefunden.

Auch diese Woche

  • GuardDuty KI-gestützte Investigations gehen in 10 Regionen in Preview (23. Juni): Jeder Befund bekommt eine Disposition mit Confidence Score, MITRE-ATT&CK-Mapping, 90 Tage zugehöriger Aktivität und eine Empfehlung zu Suppression, Containment oder Remediation, über Console, CLI, API oder den AWS MCP Server.
  • CloudWatch Logs Managed Syslog Ingestion (23. Juni) nimmt RFC 5424, RFC 3164 und Cisco FTD/ASA über TCP, TCP+TLS oder UDP an einem VPC Endpoint an, ohne Agent, mit extrahierter Facility, Severity und Hostname.
  • OTel Container Insights für EKS (23. Juni) sammelt 30-Sekunden-Infrastrukturmetriken über cAdvisor-, Kube-State-Metrics- und NVIDIA-DCGM-Receiver mit Kubernetes-Labels und einem PromQL-Endpunkt, über das CloudWatch Observability Add-on v6.2.0 oder neuer.
  • Open Governance für MySQL: Oracle hat ein Steering Committee mit vier Nicht-Oracle-Sitzen angekündigt, einer davon AWS. Angesichts der Extended-Support-Verlängerung letzte Woche plant AWS, MySQL noch lange zu betreiben.

Der rote Faden

Drei der vier Hauptthemen dieser Woche machen eine Eigenschaft durchsetzbar, die bisher ein Wunsch war: woher ein Image kommt, wo nicht vertrauenswürdiger Code läuft, wie eine Firewall die Rückrichtung einer Verbindung behandelt. Das vierte, Transform in jeder kommerziellen Region, tut dasselbe für Datenresidenz. Nichts davon ist aufregend. Alles davon ist die Art Kontrolle, die, sobald sie existiert, den bisherigen Weg in einem Post-Incident-Review fahrlässig aussehen lässt.

Lies das als Nächstes

Die Agenten-Lesart von MicroVMs und den GuardDuty Investigations steht auf ercan.ai. Für Consulting zu AWS, Cloud, CI/CD-Pipelines, Linux, GitHub/GitLab und mehr ist ercanermis.com die Anlaufstelle.

Referenzen