The week of 31 August gave anyone running workloads on both AWS and Azure the two things they had been building themselves: AWS Interconnect multicloud with Microsoft Azure entered public preview, a managed private connection between the two clouds, and AWS Transform can now land migrated block storage directly on Amazon FSx for NetApp ONTAP. The same week Amazon Linux 2027 went into public preview with SELinux enforcing by default, Graviton5 R9g and R9gd instances went GA, and Lambda SnapStart reached container images. On the model side, Claude Fable 5.1 became available on AWS; that one is covered in depth at ercan.ai.

AWS Interconnect: multicloud networking as a product

Until now, connecting an AWS VPC to an Azure VNet privately meant one of two things: a pair of IPsec tunnels over the internet, or a colocation cage with Direct Connect on one side, ExpressRoute on the other, and a router you own in the middle. AWS Interconnect multicloud replaces both with a connection you create from the console, CLI or API. AWS first showed it at re:Invent 2025 as an open specification; Azure is the latest provider to adopt it. The preview runs in US East (N. Virginia), US West (N. California), Asia Pacific (Sydney) and Europe (Frankfurt). The announcement states no bandwidth tiers or pricing, so treat any number you hear as unconfirmed.

Why this is a migration story and not just a networking one: the hardest phase of an Azure-to-AWS move is the middle, when the database is on one side and half the services are on the other, and the latency and egress of a VPN tunnel decide how long you can live there. A private, managed link lowers the cost of a slow, careful migration, which is the only kind that works. The failure mode is the same as every managed network product: it becomes load-bearing for traffic nobody planned, so set route filters on day one and tag the flows that are supposed to be temporary. The wire is here; the code conversion side of an Azure exit still sits with the .NET and Windows agents in AWS Transform, and that gap is the one to watch.

AWS Transform: block storage straight to FSx for ONTAP

FSx for NetApp ONTAP is now a GA target for block storage in AWS Transform migrations, alongside EBS. You move the block volumes in the same wave as compute and networking, with no intermediate storage platform and no separate storage migration tool, and AWS says access patterns and operational processes carry over for workloads coming from NetApp ONTAP, other block storage or VMware.

This matters for the migrations that stall on storage. A VMware estate with a SAN behind it usually ends up with EBS volumes sized to the old LUNs, losing deduplication, snapshots and the replication the storage team relied on, and the storage team pushes back. Landing on ONTAP keeps their tooling and their SnapMirror relationships intact. The trade-off is cost per GB versus EBS and one more service to operate; the decision rule is simple: if the source team currently manages ONTAP, keep ONTAP, and if they manage raw disks, go to EBS. Also in the same week, Aurora MySQL added multi-source replication and delayed replication (version 8.4.8 and up), which is the consolidation tool for merging shards or regional databases into one cluster, and DocumentDB now upgrades directly from 3.6 and 4.0 to 8.0 without the intermediate hops.

Amazon Linux 2027: SELinux enforcing, kernel 7.1, AWS-LC

AL2027 builds on the AL2023 baseline with a 7.1 or later kernel, current toolchains and language runtimes, Neuron driver support, AWS-LC for cryptography, and SELinux in enforcing mode by default. Preview AMIs are in the console in all commercial Regions for x86-64 and ARM, container base images are on the ECR Public Gallery, and feedback goes through the AL2027 GitHub repository.

SELinux enforcing by default is the line to plan around. AL2023 shipped it permissive, and a lot of software that "works on AL2023" works because a denial was logged instead of enforced. Build your AL2027 test image now, run your real workload, and read ausearch -m AVC -ts recent before you decide whether you need a policy module or a different base image. The cryptography change is subtler: AWS-LC is API-compatible with the OpenSSL you expect for most uses, but anything that loads engine modules or depends on an obscure cipher deserves a test. Preview is the cheap time to find both.

Graviton5 R9g: the first instances with a verified isolation engine

R9g and R9gd went GA in US East (N. Virginia and Ohio), US West (Oregon) and Europe (Frankfurt), with AWS claiming up to 25% better compute than R8g, up to 30% faster databases and a 5x larger cache. They run on the sixth-generation Nitro System and are the first instances to carry the Nitro Isolation Engine, which AWS says uses formal verification to provide mathematical assurance of workload isolation. Benchmark the performance claim on your own database tier; read the isolation claim carefully, because "formally verified" is a statement about a specific model, and the scope of that model is what an auditor will ask about.

Also this week

The throughline

This week AWS went after the reasons migrations stall rather than the reasons they start. The network between clouds was a project; now it is a resource. The SAN was the storage team's veto; now it lands on the product they already run. The database consolidation was a DMS task; now it is a replication setting. None of those launches is a headline on its own, and together they remove three of the most common reasons a migration plan says "phase 2" and means "never". AL2027 is the reminder that the destination keeps moving too: the OS you migrate onto this year wants SELinux enforcing next year, and the preview is your warning.

Read this next

For the AI and agent reading of the same week, the field notes live at ercan.ai. Consulting on AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab and more runs through ercanermis.com.

References