In the first week of August, AWS Transform shipped three launches that together cover a migration from the schema you have not converted yet to the technical debt you will find a year after cutover. On 3 August the Windows modernization agent gained offline SQL Server to Aurora PostgreSQL schema transformation and continuous modernization went generally available; on 6 August the migration workflow learned to run post-launch actions through Systems Manager. Around it, Lambda got up to 3,000 Mbps of network bandwidth, Aurora Serverless learned to jump to 12 ACUs in a second, and the load balancers picked up NSA-grade TLS policies.

The thesis for the week: AWS is no longer selling Transform as a rehost tool with an AI label. It is filling in the parts of a migration that used to be a partner's spreadsheet, and that changes what you should expect to do by hand.

AWS Transform: schema, cutover, and the year after

Take the three in migration order. The offline schema transformation accepts SQL Server DDL files, so you do not need a live connection to the source. It assesses database and stored procedure complexity, lets you edit the generated plan, then converts tables, schemas, stored procedures and functions, validates functional equivalence, and deploys the result to Aurora PostgreSQL. Storage object conversion is powered by AWS DMS under the hood. It is US East (N. Virginia) only for now. The offline part matters more than it sounds: the teams that cannot start a database migration are usually the ones whose DBAs will not open a port to a conversion tool. A DDL dump is an easier conversation.

Post-launch actions close the gap between "the server booted in AWS" and "the server is actually ours". You define actions once at the account level, and Transform applies them to every source server, across target accounts in a multi-account migration, running them through AWS Systems Manager right after a test or cutover launch. Predefined actions or your own SSM document. The migration inventory file also gets a structure for per-server review. If you have run MGN at scale, you know the failure mode this removes: a wave of 80 servers lands and someone runs the CloudWatch agent install by hand on 79 of them.

Continuous modernization is the piece aimed at what happens after. It connects to GitHub organizations, GitLab groups and Bitbucket workspaces, runs on demand or on a schedule, ranks findings by technical debt, security, agentic readiness and modernization readiness, and for findings with a fix it opens pull or merge requests with validated changes. The analysis runs in your own account under your credentials, and you can drive it from the web app, the CLI, Kiro, or as an agent plugin. The trade-off is the same one every automated PR tool carries: review capacity. A scheduled scanner that opens PRs faster than the team can read them becomes noise within a quarter. Start with one repository group and a strict rank filter.

Lambda bandwidth: 3,000 Mbps, if you are not in a VPC

Lambda network bandwidth now scales with memory for functions with 2 GB or more, from 625 Mbps at 2 GB to 3,000 Mbps at 10 GB, replacing the flat 625 Mbps ceiling. No extra charge, all commercial Regions. Two caveats carry the launch. First, it is opt-in via a Service Quotas request on the "Network bandwidth per execution environment" quota, after which every non-VPC function in the account scales automatically. Second, and more important, it applies only to functions outside a VPC. Most enterprise functions that move large objects are inside one, because that is where the RDS instance and the private S3 endpoint live. If your heavy S3-to-S3 transforms run in a VPC, this week changed nothing for you. Check with aws lambda get-function-configuration --function-name X --query VpcConfig before you file the quota request.

Aurora Serverless: 12 ACUs in a second

Aurora Serverless now reaches up to 12 ACUs within a second during scale-up, continues to 256, and still scales to zero afterwards. It is on by default for clusters on platform version 3 or 4; versions 1 and 2 can upgrade directly to 4. Check yours with the ServerlessV2PlatformVersion field from describe-db-clusters. AWS frames this around agentic workloads, which is fair: an agent fan-out is exactly the burst that used to spend its first 30 seconds waiting for capacity. The failure mode is cost. A cluster that previously ramped gently now hits 12 ACUs on a spike that would have been absorbed at 2. Put a CloudWatch alarm on ServerlessDatabaseCapacity before you upgrade the platform version, not after the first bill.

Also this week

The throughline

Read the Transform launches next to the Lambda and Aurora ones and the pattern is about where the manual work was hiding. Schema conversion hid behind a firewall rule nobody would approve. Post-launch configuration hid in a runbook. Technical debt hid in the backlog. Lambda's bandwidth ceiling hid behind a quota, and Aurora's ramp hid in the first 30 seconds of every spike. AWS spent the week removing hiding places. The cost of that is the same every time: the defaults get more aggressive, and the platform team has to decide, up front, which of those defaults it actually wants.

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