In the week of 27 July AWS Transform dropped the assumption that a migration starts in vSphere. The 29 July change log entry renames the workflow to "Migrations (including VMware)" and opens discovery, wave planning, landing zone, network migration, and server rehost to Hyper-V, bare metal, and other platforms. The same week, AWS Interconnect to Oracle Cloud Infrastructure went GA, Transit Gateway policy-based routing let forwarding decisions use source, port, and protocol, IAM Identity Center extended multi-Region replication to its built-in directory, and CloudWatch started running Prometheus collectors for you.

AWS Transform for migrations: the hypervisor stops mattering

The migrate servers documentation now says it plainly: you can migrate from on-premises data centres, other cloud providers, or other AWS Regions, physical or virtual, on VMware, Hyper-V, KVM, or anything else, and the hypervisor is irrelevant as long as the guest OS is on the AWS Transform MGN supported list. The replication engine was always MGN, which never cared about the source; what changed is that the agentic workflow around it, discovery, 7Rs recommendations, wave planning, network conversion, now accepts those sources too. The same entry adds post-launch actions to rehost: SSM documents, predefined or custom, that the agent recommends and runs on each server as it launches as a test or cutover instance, defined at the account level or per server in the inventory file under mgn:launch:post-actions:<ACTION_NAME>:<FIELD_NAME>.

For anyone sizing a Hyper-V or bare-metal estate for AWS, this is the week the tooling caught up with the sales pitch. Two cautions. First, the change is a docs entry, not a What's New post, so there is no Region list or pricing note to cite; verify in your workspace Region before planning around it. Second, agentless replication is still unsupported, so every source server needs an agent, and on bare metal there is no vCenter path to paper over the boxes you cannot log in to. Confirm credentials per server at inventory validation, not when the MGN connector times out. The post-launch actions are the quiet win: the "install the CloudWatch agent, join the domain, run the compliance scan" checklist that used to be a runbook becomes part of the wave, and mustSucceedForCutover lets you make it a gate.

Interconnect to OCI, and routing that reads more than the destination

AWS Interconnect - multicloud reached GA on 29 July for Oracle Cloud Infrastructure, provisioned from the console, CLI, or API, with Google Cloud also supported at GA and Microsoft Azure expected later in 2026. OCI built its side on an open specification AWS published on GitHub. Availability is us-east-1 for OCI, and the announcement gives no bandwidth tiers or pricing, so the documentation is the next stop.

The comparison is with what teams do today: a Direct Connect into a colocation facility, a cross-connect to the other provider, two BGP sessions, and a wiki page about who to call when it breaks. Interconnect replaces that with a managed object, and concentrates the risk in one product, in one Region at launch. The database-in-OCI, application-in-AWS pattern that Oracle licensing keeps producing is the obvious customer. For anything else, wait for the Region list to grow.

Policy-based routing on Transit Gateway, GA on 30 July at no extra charge, is the piece that makes a hub-and-spoke network capable of saying "this source, on this port, goes through the firewall; everything else goes direct." You attach a policy table to an attachment, write an ordered rule set that matches on source and destination IP, port, and protocol, and each rule sends matching packets to a named route table, first match wins. The failure mode is the one PBR has always had: a policy table is a second place where routing is decided, and "look up the destination in the route table" stops being a sufficient mental model. Document the rules next to the route tables, and resist using PBR for anything a route table can express.

Direct Connect gained BGP route visibility the same day: accepted and advertised routes on private, transit, and public VIFs, with prefix, AS path, communities, and address family, via the console or ListVirtualInterfaceRoutes. Anyone who has debugged an asymmetric path by asking the network team to run show ip bgp on their side knows why this matters.

Identity Center replicates its own directory

Multi-Region support in IAM Identity Center previously required an external identity provider. From 29 July an organization instance using the built-in Identity Center directory can replicate identities and entitlements from its primary Region to additional Regions you choose, across the 17 enabled-by-default commercial Regions. If the primary Region is disrupted, users keep access to their accounts through entitlements already provisioned elsewhere. Administration stays in the primary Region, the instance must use a multi-Region customer managed KMS key, and the only cost is KMS.

Identity Center is the component whose failure stops every human from fixing anything else, and without an external IdP it has been a single-Region dependency since launch. The prerequisite is the catch: a multi-Region CMK has to exist before you enable replication, and an instance created with the default AWS-owned key needs a key change first. Plan that as its own change, with a rollback.

CloudWatch runs the Prometheus collector

CloudWatch managed collectors, GA on 31 July, scrape Prometheus metrics from EKS (Kubernetes service discovery), ECS (Cloud Map DNS), EC2 (direct), and MSK and OpenSearch Service (open monitoring endpoints) without an OpenTelemetry Collector you run. You hand over a scrape config and a connection; CloudWatch provisions and scales the collector, delivers metrics in OpenTelemetry format, and lets you query them with PromQL alongside vended metrics. Collectors are billed by the hour on top of standard OpenTelemetry metric ingestion, and the feature is available wherever the CloudWatch OTLP endpoint is, except Asia Pacific (New Zealand).

The self-managed collector was the part of the observability stack most likely to be down when you needed metrics, usually because its node was the one in trouble. Moving it out of the cluster is correct. The question is cost at cardinality: the hourly fee is predictable, ingestion is not, and a scrape config lifted from a Prometheus server that kept everything will ingest everything. Keep your metric_relabel_configs drop rules, and read the ingestion line on the first bill before adding the second cluster.

Also this week

The throughline

Every headline this week widens an input AWS used to constrain. Transform takes any hypervisor. Interconnect takes another cloud. Transit Gateway takes five-tuple matches instead of a destination. Identity Center takes its own directory into more Regions. Managed collectors take the scrape config you already have. The cost is paid in the same currency each time: more inputs means more places the configuration can be wrong, and fewer of them visible in a route table. The BGP visibility launch is the tell: AWS added observability to Direct Connect the same day it added policy routing to Transit Gateway, because it knows what the second one does to debugging.

Read this next

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

References