The week of 22 to 28 June 2026 gave platform teams three governance primitives they had been faking with tags and wiki pages: AMI watermarks that survive copies, Regions, and account shares; Lambda MicroVMs that put untrusted code in its own virtual machine; and a corrected Network Firewall default that had been silently dropping legitimate server-to-client packets. On the migration side, AWS Transform now lands workloads in any commercial Region, and OpenSearch and MSK both shipped agent-guided migration paths.

No Summit this week, so the launches are smaller and more useful: each lead item is something you would have written a policy document about last year and hoped people followed.

Migration: any Region, and two more agent-guided paths

AWS Transform for migrations now supports all AWS commercial Regions as migration targets, published 22 June. The target Region is where the landing zone, network, and rehosted servers are deployed, and the announcement adds 16 of them: 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), and Middle East (Tel Aviv). For European readers, Zurich, Milan, and Spain are the ones that turn "the agent cannot land it where legal says it must live" from a blocker into a dropdown.

Two database-adjacent launches in the same week follow the pattern from the MGN rename: the migration logic moves into something an agent drives. Amazon OpenSearch Service now offers AI-assisted migrations (23 June): Migration Assistant gains an agent-guided workflow, usable from Kiro, Claude Code, and others, to plan the move from self-managed Solr, Elasticsearch, or OpenSearch to OpenSearch Serverless or Managed Clusters, deploy the infrastructure, and run historical plus live-traffic migration, with capture-and-replay now covering Solr. Amazon MSK AI Agent Skills (22 June) give Kiro, Claude Code, and Cursor expert guidance for sizing, troubleshooting, monitoring, and migrating external Kafka clusters to MSK Express.

The trade-off with skills as a distribution mechanism is version control: a runbook in your repo has a commit history, a vendor skill pulled at run time is a prompt you cannot diff. Fine for a one-off migration. For forty identical clusters, export what the agent did the first time into something you own.

AMI watermarks: lineage that does not get lost in the copy

Amazon EC2 announced AMI Watermarks on 24 June. You embed a custom identifier in a private AMI, and it carries forward to every AMI derived from it: copies to other Regions, images created from a running instance, and images shared with other accounts. Each watermark carries the original AMI ID, owner, Region, and creation timestamps. The enforcement half is the point: combine watermarks with Allowed AMIs to restrict launches to images carrying an approved watermark, and apply that across the organization with Declarative Policies. EC2 Image Builder can attach a watermark in the pipeline. All Regions including GovCloud and China, no charge.

The hole this closes is specific. Golden AMI programs enforce "launch only from account X" with Allowed AMIs. The first time a team copies the golden image into their own account to add a package, the lineage is gone, and the policy either blocks it (so they stop using the golden image) or allows their account (so the policy means nothing). A watermark that survives the copy lets you say "launch anything descended from the golden image" instead.

Be precise about what it proves. A watermark is provenance, not integrity: it says the image descends from a build you approved, not that nothing changed in the derived image or on the instance afterwards. It replaces tag-based lineage; it does not replace Inspector, SSM compliance, or image signing.

Lambda MicroVMs: a VM per untrusted session

AWS introduced Lambda MicroVMs on 22 June: a serverless primitive that gives each user or job its own Firecracker-isolated VM with its own kernel, suspend and resume with memory and disk state intact for up to 8 hours total runtime, and a dedicated HTTPS endpoint supporting HTTP/2, gRPC, and WebSockets. Limits per MicroVM are 16 vCPUs, 32 GB memory, 32 GB disk, ARM64 only. Per the launch post, you build an image from a Dockerfile with aws lambda-microvms create-microvm-image, launch with aws lambda-microvms run-microvm and an idle policy, and pay baseline compute while it runs. Available in US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo).

I wrote about this at length in AWS Lambda MicroVMs: Serverless Sandboxes. The short version: the design question is not "functions or MicroVMs" but "what in my system runs code I did not write". Notebooks, customer plugins, and anything an LLM generates belong behind a VM boundary with a lifecycle, and until this week that meant your own Firecracker fleet or a container per tenant. The agent angle is at ercan.ai.

Network Firewall fixes a default that broke connections

AWS Network Firewall updated its default drop action on 22 June. New firewall policies now default the stateful action to "Application drop established (server-directed only)". The previous default, "Application drop established (bidirectional)", could silently drop legitimate server-to-client TCP packets such as window updates, keep-alives, and resets, which showed up as intermittent connection failures nobody could reproduce. Existing policies are not changed automatically; AWS points to documentation for updating them, and notes that environments needing the bidirectional action for post-quantum fragmented TLS handshakes can switch or add a to_server flag to their TCP drop rules.

This is the one to action today, because it is a change to a default and not a feature. Every aws_networkfirewall_firewall_policy in your Terraform copied from an old example carries the old default. Grep for the stateful default actions, compare against the new recommendation, and roll the change through staging first. If you have an unexplained intermittent timeout ticket open against something behind Network Firewall, you may have just found its cause.

Also this week

  • GuardDuty AI-powered investigations enter preview in 10 Regions (23 June): each finding gets a disposition with confidence score, MITRE ATT&CK mapping, 90 days of related activity, and a suppression, containment, or remediation recommendation, via console, CLI, API, or the AWS MCP Server.
  • CloudWatch Logs managed syslog ingestion (23 June) accepts RFC 5424, RFC 3164, and Cisco FTD/ASA over TCP, TCP+TLS, or UDP to a VPC endpoint, no agent, with facility, severity, and hostname extracted.
  • OTel Container Insights for EKS (23 June) collects 30-second infrastructure metrics via cAdvisor, Kube State Metrics, and NVIDIA DCGM receivers with Kubernetes labels and a PromQL endpoint, through the CloudWatch Observability add-on v6.2.0 or later.
  • Open governance for MySQL: Oracle announced a steering committee with four non-Oracle seats, one of them AWS. Given the Extended Support extension last week, AWS plans to run MySQL for a long time.

The throughline

Three of this week's four lead items make a property enforceable that used to be aspirational: where an image came from, where untrusted code runs, how a firewall treats the return half of a connection. The fourth, Transform in every commercial Region, does the same for data residency. None of it is exciting. All of it is the kind of control that, once it exists, makes the previous way look negligent in a post-incident review.

Read this next

The agent-side reading of MicroVMs and the GuardDuty investigations is at ercan.ai. For consulting on AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab, and more, the hub is ercanermis.com.

References