Two things happened in the week of 24 August that will still matter in 2028: AWS agreed to acquire DuckLabs, the Amsterdam company behind DuckDB, with the database staying MIT-licensed under its independent foundation; and Amazon ECS started detecting and repairing container instances whose agent lost contact with the control plane. Around them, Lambda had a three-launch Tuesday (preview runtimes, full resource-based policies, PrivateLink for MicroVMs), EKS took up to ten OIDC providers per cluster, and on the migration side AWS Transform entered FedRAMP Class C scope while Elastic Disaster Recovery gained ordered Recovery Plans. EC2 also turned twenty.

DuckLabs: AWS buys the engine for data that fits on one machine

The announcement is careful on the points that matter to anyone who has DuckDB in production: it stays open source under the MIT license, it stays under the independent Foundation, and Hannes Mühleisen and Mark Raasveldt keep leading the technical direction. AWS's stated reason is agents, which explore data the way analysts do, in small iterative queries over a terabyte or less, and its evidence is its own: Amazon Quick already runs DuckDB over S3 Tables and has served more than 2.5 billion queries with a 30% drop in average latency.

The honest reading for a platform team is twofold. First, the in-process engine that your data people already run in notebooks is now going to show up inside Athena, Redshift, EMR, Glue and SageMaker in some form, which means the "small data" path on AWS stops being a Spark cluster waiting for a 2 GB Parquet file. That is good news for cost. Second, every acquisition of an open-source company carries the same question regardless of the press release, and the answer here is the license and the foundation structure. MIT means forks are trivial if governance ever drifts. Keep an eye on where new features land first, the open repo or the AWS services, because that is the tell, not the licence text.

ECS: a health event for the failure you could not see

An ECS container instance whose agent has lost its connection to the control plane is a specific kind of broken: the tasks on it may still be running, the instance passes EC2 status checks, but ECS cannot place, stop or observe anything there. EBS degradation, a thermal event or a network fault can all cause it. ECS now monitors this continuously and emits an AGENT_CONNECTIVITY container instance health change event across Fargate, ECS Managed Instances and ECS on EC2, at no cost in all commercial and GovCloud (US) Regions.

The split is the important part. On Fargate and Managed Instances, ECS does the recovery itself: drains workloads off, provisions replacement capacity, removes the impaired instance. On ECS on EC2 you get the event and the job. That is the right design, because on EC2 the capacity provider is yours and ECS cannot know whether terminating the instance is safe, but it means the launch only helps you if you wire it. An EventBridge rule on the event that calls aws autoscaling set-instance-health --health-status Unhealthy is the minimum viable version. If you wanted a reason to move the leftover EC2 capacity providers to Managed Instances, this is a concrete one: the same week AWS Batch gained Managed Instances as a compute environment through a managedInstancesProvider block in CreateComputeEnvironment.

Lambda's Tuesday: runtimes, policies, private endpoints

Node.js 26 and Python 3.15 arrived as public preview runtimes with a useful design choice: the identifiers are nodejs26.x and python3.15, the same as GA will be, so functions move to GA automatically. The cost of that convenience is the trap in it. A preview runtime is excluded from the Lambda SLA and from AWS Support, and breaking changes are possible, so a function set to python3.15 in a shared SAM template today is a production function on an unsupported runtime tomorrow. Gate it in CI.

Full IAM resource-based policies replace the one-principal-at-a-time permission model with a single policy document covering multiple principals and actions, with the full set of IAM condition keys. Anyone who has managed a function invoked by three services and an external account knows the old model produced a resource policy nobody could read; this makes the policy reviewable and, through CloudFormation and SAM, diffable. And Lambda MicroVMs now support PrivateLink, so VPC resources can create images, launch MicroVMs and hit each MicroVM's HTTP endpoint without leaving the AWS network, which was the blocker for regulated teams using them as agent sandboxes.

Migration and DR: Transform in FedRAMP scope, DRS gets a runbook

AWS Transform is now in scope for FedRAMP Class C (the former Moderate baseline) when used from US East (N. Virginia), targeting US East or US West; the MGN component separately qualifies for Class D. For public-sector migrations that were stuck on tooling compliance, that is the unblock. DRS Recovery Plans let you group servers into sequential steps with wait times, add approval gates, run the whole thing as a non-disruptive drill, and watch progress live. The database-before-app ordering that lived in a wiki page is now an object the service executes, which is also the only way a DR drill ever gets run twice.

Also this week

The throughline

The ECS launch and the DuckDB acquisition are both AWS admitting that a lot of real work happens below the scale its services were designed for. One container instance going quiet is too small for a dashboard and too common to ignore; one terabyte of Parquet is too small for Spark and too common to pretend otherwise. Both fixes are the same shape: notice the small failure or the small dataset, handle it natively, and stop making the customer build a cluster or a cron job to cope. The Lambda runtime preview and the resource policies belong to the same week because they are also about the long tail: the function nobody owns, invoked by four principals, on a runtime someone set in 2026. Platforms earn trust in the long tail, not the keynote.

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