The week of 7 September was the week AWS Transform for .NET stopped being a tool you click through and became a step you put in a pipeline. A one-line CLI went generally available, the same transformation started generating unit tests for the code it rewrites, and AWS Transform reached GovCloud (US-West) for server migration. Around it, Lambda Managed Instances got a 90-minute timeout and Graviton5, EBS Volume Clones learned to cross account boundaries with re-encryption, and a 42U single-rack Outposts went GA.

AWS Transform for .NET: CLI, tests, GovCloud

Three launches, one direction. On 9 September AWS Transform for .NET modernization became generally available via CLI: a single command triggers an AWS-managed transformation in AWS Transform custom, and you can run it interactively or script it into an existing pipeline to run unattended. The transformation includes 50,000 free agent minutes per month and is available in eight Regions: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt, and London.

On 10 September AWS Transform for .NET started generating unit tests for modernized code. It assesses the application for testability in parallel with the standard .NET assessment, plans which classes and methods to cover (business logic, controllers), and emits the test code as part of the same job. Opt-in, enabled at job start or after transformation completes, currently through the AWS Toolkit for Visual Studio.

And on 8 September AWS Transform arrived in AWS GovCloud (US-West). Scope matters: this is the server migration capability (VMware, bare metal, Hyper-V, database workloads, replication and cutover into either GovCloud Region). Modernization, custom transformation, and assessment stay in commercial Regions for now.

The CLI is the one that matters: a modernization that lives in an IDE is a project, a modernization that runs in CI is a process. You can run the transformation on a branch nightly, diff the output against yesterday's, and treat the agent like any other build step that either passes or does not. That is how you modernize 80 services instead of 8.

The failure mode to plan for is the tests. A test suite generated from the transformed code encodes the behaviour of the transformed code. It is a regression net for everything you change after the migration, which is valuable, but it does not prove the migration preserved the behaviour of the .NET Framework original. For that you still need the old suite, or characterization tests written against the old binary, run against the new one. Use the generated tests as the floor, not as the sign-off.

Lambda Managed Instances: 90 minutes and Graviton5

On 9 September Lambda added a 90-minute function timeout on Lambda Managed Instances for asynchronous and event source mapping invocations, six times the 15-minute ceiling that has defined Lambda architecture for a decade. Synchronous invocations keep 15 minutes. The longer limit also applies to steps inside Lambda durable functions. The same day, Managed Instances gained Graviton5-powered C9g, C9gd, M9g, and M9gd instances, which AWS rates at up to 25% better compute performance than Graviton4.

Managed Instances already changed the pricing model (EC2 instance economics, multiple concurrent requests per instance) and this change finishes the thought: it is a managed compute fleet with a function-shaped programming model. Media transcodes, Monte Carlo runs, and batch inference stop needing a Step Functions chain or an ECS task just to get past minute fifteen.

What does not change: asynchronous invocations are at-least-once. A 90-minute job that gets retried after a partial failure costs you 90 minutes twice and, if it writes as it goes, leaves a half-written result. Idempotency keys and checkpointing matter more at 90 minutes, not less. And because Managed Instances bill as EC2 capacity, do the cost comparison against a Fargate task or an AWS Batch job explicitly before moving a long-running workload; the win is operational, not automatically financial.

EBS Volume Clones cross accounts, with new keys

On 9 September EBS Volume Clones started supporting copies across AWS accounts, re-encrypting with a KMS key in the target account. The flow: share the source volume through AWS RAM, then the target account creates a copy in the same Availability Zone. Works for all volume types, including unencrypted volumes and volumes under customer managed keys.

The use case AWS leads with is the right one: a fresh copy of a production database volume in an isolated development account. The old way was snapshot, share snapshot, copy snapshot with a new key, create volume, four steps and a lot of waiting. The new way is one copy with key separation built in, which is what a landing zone's "prod keys never leave prod" rule actually requires.

Two things a platform team should write down. First, "same Availability Zone" means the same physical zone, and zone names (eu-west-1a) map differently per account. Use AZ IDs (euw1-az1) in any automation, or the copy lands in a zone your dev subnets do not cover. Second, cloning production data into dev is a data governance event, not a storage event. Put the RAM share behind an approval and log who copied what; easy mechanisms need explicit controls.

Also this week

The throughline

Every headline this week moved something from "a person does it" to "a pipeline does it". Transform runs from the CLI and writes its own tests. Lambda holds a job for 90 minutes so you stop hand-rolling orchestration around minute fifteen. EBS copies a prod volume into dev with the right key in one operation. Systems Manager tells you why the instance is unmanaged instead of making you guess. Each one removes a human step from a process that used to need one. The work for a platform team is to decide which of those steps were there for a reason (the approval before prod data leaves prod) and keep them, deliberately, now that the tooling no longer forces you to.

Read this next

For the AI and agent reading of the same week, see ercan.ai. If your team needs hands-on help with AWS, cloud architecture, CI/CD pipelines, Linux, GitHub or GitLab, and the platform work around them, the consulting side lives at ercanermis.com.

References