The night sky seems eternal and unchanging. But in cosmic time, nothing could be further from the truth.
Vasily Belokurov is one of three winners of the 2026 Kavli Prize in Astrophysics. The award is for uncovering fossil evidence of past galactic mergers that prove how the Milky Way evolved.
No matter the time or vantage point, from a pre-Neolithic cave to a post-lockdown London high-rise, the predictability of the night sky has always been humanity’s symbol of permanence and reassuring stability.
Yet this apparent calm is deceptive. Our galaxy, the Milky Way, emerged from chaos and turbulence, and its constellations are full of migrants, exiles and survivors. Right now, it has begun to stretch and distort again, pulled by a massive companion and heading for an inevitable collision.
How can I be so sure? As a galactic archaeologist, my job is to reconstruct the past of our galaxy and read the signs of its future.
Instead of digging through soil, I use the laws of dynamics and stellar evolution to sift through hundreds of millions of stars—searching for the most ancient and chemically peculiar among them, interpreting their orbits and piecing together the events that shaped the Milky Way. One ancient encounter left scars so deep that, billions of years later, they still define the galaxy around us.
I want to understand what governs the lives of these massive cosmic systems: which changes are nature—the slow internal evolution of a galaxy disk—and which are nurture, imposed by collisions and mergers.
Questions about the source of dark matter underpin it all. This is the invisible substance whose gravity holds galaxies together, but whose true identity remains one of the greatest unsolved puzzles in astrophysics.
The Milky Way is the one galaxy where stellar motions can be measured in extraordinary detail. This allows cosmologists including myself to construct our most precise map yet of dark matter: how far it reaches, how dense it is around the sun, what shape it has, and how smooth or lumpy it may be. If we can build this map in enough detail, we may begin to understand not just where dark matter is, but what it is.
A Cataclysmic Collision
Our work has been transformed by a revolution in open sky surveys. From 2000, the Sloan Digital Sky Survey showed what becomes possible when vast astronomical datasets are made public, enabling discoveries far beyond the goals for which the survey was first built.
And since 2014, Gaia, the European space telescope, has taken this transformation to another level by mapping the positions and motions of nearly 2 billion stars, turning the galaxy into a vast archaeological record. No ruins, no shards, and no bones—only stars that hold the clues.
The clearest giveaway that something cataclysmic took place long ago in our galaxy is the migrants we observe: stars that were not born in the Milky Way.
While native stars mostly travel together, circling the galactic center in the great rotating flow of the disk, migrants cut across that order. They slide past the locals, plunge into the inner galaxy, then fly back out to its outskirts, again and again.
These unusual orbits go hand-in-hand with unusual chemistry. Most of the migrant stars are less enriched in heavier elements than the locally born population. Their chemical composition is a sign of a slower rate of evolution that is typical of a dwarf galaxy.
This makes the migrants doubly valuable. They are both fossils of the Milky Way’s violent past and probes of its outer regions, traveling where the local stars rarely go.
How the Milky Way Was Rewired
One of the central ideas in the theory of cosmic structure formation is that galaxies grow hierarchically. Smaller galaxies fall into larger ones and are torn apart, leaving their stars behind as migrants.
In the Milky Way, the largest ancient structure of this kind is known as Gaia-Sausage-Enceladus. It is the remains of a vanished galaxy that collided with our own between 8 and 11 billion years ago (the “sausage” refers to a pattern in its stars’ motions).
The Milky Way also did not go through that crash unscathed. The collision rewired and reshaped it.
Some of these changes are easily visible in the data. Stars from the old disk were splashed into our galaxy’s halo, becoming exiles in the place where they were born. A new posse of star clusters were also acquired.
At the same time, we think something even more momentous was taking place. The encounter changed the orientation of the Milky Way’s disk, and its alignment with the dark matter halo.
Around the Milky Way, this dark matter forms a vast halo, much larger than the luminous part of our galaxy. We often imagine this halo as a sparse, round cloud, but Gaia has helped show this picture is too simple.
The dark halo can be stretched out of shape by a major encounter. Like a ship beginning to list, the Milky Way started to lean—not suddenly, not visibly, but over billions of years.
View of the Southern sky shows the Milky Way and (far right, close to horizon) two galactic neighbors, the Small and Large Magellanic Clouds. H.H. Heyer/ESO via Wikimedia Commons, CC BY-NC-ND
A New Galactic Dance
Unusually, compared with many galaxies of similar mass, the Milky Way was allowed ample time to recover from the shock of the “sausage merger.” No other cosmic cataclysm appears to have shaken our galaxy since, letting it settle into a quiet, uneventful life. That is, until now.
The Large Magellanic Cloud (LMC), currently our galaxy’s most massive companion, is already pulling at the Milky Way, disturbing its halo again. In an echo of what happened some 10 billion years ago, the Milky Way is being drawn into an accelerating dance with this neighboring dwarf galaxy, recoiling in response to the LMC’s approach.
This is a dance that only one galaxy is likely to survive intact. A new chapter of migration, survival and adaptation has begun.
None of this spoils the beauty of the night sky—it deepens it. The calm band of light above us is not a symbol of permanence, but the visible reminder of a long survival.
The Milky Way has been broken, rebuilt, and is now being disturbed again. Its stars remember the past; their motions reveal the future. What looks eternal is, in truth, a moment in a much longer story.
Amazon EKS runs hundreds of thousands of Kubernetes clusters across more than thirty AWS regions. Operating at that scale has taught us something that has shaped how we build the service and that we think is useful to anyone running Kubernetes at scale: most availability problems do not stem from a component failing. They come from a component reacting to a problem in a way that makes it worse. A cache that goes stale and serves wrong answers. A health check that restarts the very process keeping a cluster alive.
What separates a resilient control plane from a fragile one is not the number of faults. It is whether a fault stays a fault or becomes an outage. This post is the story of how we keep the EKS-managed Kubernetes control plane on the right side of that line at ever-growing scale: the foundational changes we made and why, and what operating at fleet scale taught us about building systems that tolerate faults rather than spreading them. These are the reasons our most demanding customers confidently run their mission-critical workloads on EKS.
How AI and analytics workloads reshaped what “scale” means
Kubernetes was built for a particular rhythm of work. Pods came and went at predictable rates, and controllers had seconds or minutes to reconcile. The system’s design reflected that pace: strong data consistency, ordered watches, and consensus-replicated storage that puts correctness first. It worked beautifully for what it was designed to do, and it still does.
“What separates a resilient control plane from a fragile one is not the number of faults. It is whether a fault stays a fault or becomes an outage.”
But the workloads evolved faster than anyone anticipated. Foundation model training runs scale-up training jobs on thousands of GPU nodes in minutes. Real-time inference services scale from a warm baseline to thousands of replicas, then drop back within the hour. Apache Spark analytics pipelines burst from zero to tens of thousands of executor pods, chew through a dataset, and vanish.
Emerging agentic AI workloads add yet another dimension: autonomous agents that spin up, fan out, execute tasks, and tear down in seconds or less. These workloads share a trait that distinguishes them from traditional microservices: they generate enormous volumes of state transitions within compressed time windows and are deeply intolerant of delays. This velocity of state change pushed us to reinvent some of the mechanics to support a scale that was previously impossible, and to contribute what we could upstream.
How EKS reimagined Kubernetes storage foundation
Every Kubernetes cluster depends on etcd as its source of truth. Every application, every service endpoint, every scheduling decision is stored there. If etcd loses data, the cluster forgets everything it knows. Protecting that state is the most important job for a managed Kubernetes service.
Operating etcd for one cluster is well understood. Operating it for a fleet of millions is a different problem entirely. Hardware fails, networks blip, and disks degrade, so something has to handle those events without a human in the loop. And the operations etcd needs most, like replacing a failed member or recovering after a zonal event, are exactly the ones where a person acting under pressure can make a mistake that causes permanent data loss.
From the beginning, we built an operator agent that runs alongside every etcd instance and automates its entire lifecycle. The agent has two jobs. First, backup and recovery: it takes point-in-time snapshots and stores them durably outside the cluster. If too many instances are lost at once and the survivors cannot form a majority, the agent automatically detects the condition and rebuilds from the latest snapshot. Second, membership management: when an instance fails, the agent removes the terminated member and adds its replacement in an order that protects quorum and prevents split-brain.
A recent, more fundamental change was replacing etcd’s consensus mechanism, Raft, with a purpose-built journal that provides durable, ordered storage independently of etcd. In traditional etcd, a majority of members must agree on every write before it is committed. If two of three are unhealthy, the cluster becomes unavailable.
By offloading durability to the journal, etcd peers no longer negotiate quorum among themselves. Writes commit as soon as the journal acknowledges persistence, and that entire class of etcd quorum-loss failures disappeared. Since the journal handles persistence, etcd no longer needs to fsync writes to local disk, so its data store has moved to an in-memory filesystem. What was a disk-bound system became a compute-bound one, and storage latency was removed entirely from the critical path. For a deeper look at this architecture, read “Under the hood: Amazon EKS ultra scale clusters.”
“What was a disk-bound system became a compute-bound one, and storage latency was removed entirely from the critical path.”
For ultra-scale clusters, we went further and partitioned etcd into resource-specific shards. Each partition operates independently with its own storage budget and throughput capacity. The primary value is failure isolation. In a monolithic deployment, if the events keyspace exceeds its quota because a misbehaving controller creates objects faster than garbage collection can remove them, it blocks writes to everything, including node leases.
Suddenly, healthy nodes appear unhealthy because their lease renewals are being rejected. With partitioned etcd, the events partition hits its quota, but the leases partition continues operating normally. Nodes remain healthy. The scheduler keeps running.
What replacing etcd’s consensus mechanism unlocked
Removing the quorum requirement allowed us to make a change we had wanted for a long time: running etcd on the same host as the API server. In the traditional layout, every read and write crosses the network between separate machines. Each trip is fast on its own, but at thousands per second, the travel time adds up. With collocation, the API server talks to its local etcd over a loopback interface, and pod scheduling and controller reconciliation get measurably faster. For workloads where job controller queue depth is the binding constraint, shaving milliseconds off each API call means many more jobs are processed per second before the queue starts growing.
This is where the operator agent paid off. When etcd runs on the same host, an etcd member comes and goes whenever a control-plane host is replaced, which happens routinely. That only works if membership management is completely safe and automatic, which is exactly what the agent was already doing. We did not have to build a colocation from scratch; we built it on top of infrastructure that had been managing etcd membership safely since day one.
Collocation also taught us a lesson worth passing on: the convenient path needs a failover in case it breaks. The local etcd is the fast path, but if it becomes impaired, the API server fails over to another etcd member that is actively serving other API servers from the same journal. When you optimize for the common case, design just as deliberately for the moment that optimization is not available.
Fixing bottlenecks across the stack
At extreme scale, you have to address bottlenecks across the entire Kubernetes stack, and most of them are not bugs in the traditional sense. They are design choices that were correct at the scale Kubernetes originally targeted and break down only when the numbers get large. Rather than working around them internally, we fix them upstream so the entire community benefits.
One example involved the watch cache, the in-memory layer that distributes state changes from etcd to every controller watching for updates. When a controller starts, it requests a full snapshot of the current state via a mechanism called WatchList, and the existing implementation holds a shared read lock for the duration of the response build.
At hundreds of thousands of objects, that work runs long enough to starve the writer that needs exclusive access, so the cache’s resource version cannot advance. Consistent reads see a stale cache and fail over to etcd, while the response building churns through hundreds of thousands of allocations under the lock. We identified this as a limitation in the watch-cache’s locking model and are working with the community to refactor the underlying data structures and interfaces to eliminate the contention.
The same shape appears elsewhere. In the Horizontal Pod Autoscaler, a single mutex protecting the scaling state becomes a serialization point at high HPA counts, where workers spend nearly all their time blocked rather than doing useful work. A redesigned data store (PR #139142) restores parallelism and raises reconciliation throughput by orders of magnitude. In the scheduler, we identified a bottleneck (issue #138426): every scheduling cycle rebuilds a set of in-use persistent volumes by scanning every node in the cluster, even for pods that do not use storage at all. The fix computes that information lazily, and only for pods that actually need it, restoring throughput at scale.
Each of these started from a real production workload hitting a cliff, and we are working on the fixes upstream so the improvements reach every Kubernetes user.
From engineering to guarantees: EKS Provisioned Control Plane
The engineering described above made the EKS control plane more resilient and performant. But customers had a different problem: they could observe that the control plane kept up today, but they could not reserve its capacity the way they reserve compute or GPU capacity.
A team planning a thousand-node training run could secure the instances weeks in advance, yet had no equivalent mechanism for the orchestration layer that would coordinate them. EKS Provisioned Control Plane fills that gap. It exposes the control plane’s performance as dimensions you size explicitly, backed by the same kind of commitment you expect from the rest of your infrastructure.
You choose a scaling tier that maps to concrete, measurable capabilities: API request concurrency, pod scheduling rate, and cluster database size. The tiers range from XL through 8XL. At the top end, 8XL on Kubernetes 1.34 provides 16,000 concurrent API request seats, 400 pods-per-second scheduling rate, and 16 GB of cluster database storage, all backed by a 99.99% availability SLA measured in one-minute intervals.
Tiers are not static. You step up before a GPU training run or a large sales event, step back down during quiet periods, or grow permanently as your platform matures. Configuration happens through the console, CLI, eksctl, CloudFormation, or Terraform on any cluster, without recreation or downtime.
For AI workloads, orchestration capacity is planned alongside GPU capacity, available when the compute comes online. For analytics platforms submitting hundreds of jobs per minute, the control plane is ready for the burst before it arrives. And for organizations that need environmental consistency across staging, production, and disaster recovery, the same tier guarantees consistent performance characteristics everywhere.
Taking the same foundation to the edge
Some workloads cannot move to the cloud, whether due to data sovereignty requirements, latency constraints, or unreliable connectivity to the Region. Running Kubernetes in these disconnected environments introduces unique challenges: etcd must remain durable on hardware with only a few machines, the cluster must self-heal without reaching the cloud, and observability must survive network partitions that last days.
With the updated architecture for EKS local clusters on instance store Outposts, we brought edge clusters onto the same management plane and software stack as EKS clusters in the cloud.
The control plane lives in an EKS-managed account on the Outpost rather than in the customer’s account, so customers never manage control plane instances, etcd backups, or logging agents themselves, and they cannot accidentally break the thing keeping their cluster alive. The same machine images, container images, and operator agent run in both places, with edge-specific behaviors selected by configuration.
Because it is the same stack, new Kubernetes and EKS platform versions arrive in lockstep with their cloud release, and features like EKS add-ons, Pod Identity, and access entries work the same way they do in a Region.
The hardest part was keeping etcd healthy on hardware with only a few machines that may be cut off from the cloud for days at a time. We solved it by extending the same agent. It keeps a spare copy of the data continuously up to date and promotes it the instant a machine fails, so the cluster heals itself with no human involvement and no connection to the cloud.
Observability survives the disconnect, too: the metrics agent continues collecting and writing to local disk, shedding the least critical data first when space runs short, so the signals that matter most are the last to go. When the link returns, the buffered data is flushed back with its original timestamps.
All of this only works because the system was designed from the start to operate without anyone logged in. That same design is what makes it possible to deploy changes safely across the entire fleet.
Operating safely at fleet scale
Every one of these changes was deployed to a running fleet of hundreds of thousands of clusters. The journal migration and collocation required transitioning each cluster individually. Every migration follows a strict sequence: validate pre-conditions, create a point-in-time snapshot, perform the switchover, validate post-conditions. If any step fails, the system rolls back automatically.
Rollouts proceed cell by cell, zone by zone, region by region, with automated monitoring comparing latency, error rates, and throughput between updated and non-updated clusters. Any statistically significant deviation triggers an automatic halt.
What made all of this possible is that EKS is built to operate without human intervention at the individual cluster level. Through Zero Operator Access, the architecture prevents AWS personnel from having technical pathways to access customer content in the managed control plane. A system designed to work without human access must be observable, recoverable, and automatable from the start, and that same discipline is what enables operating at extreme scale.
Three operational lessons shaped how we approach this work.
The first is that a healthy leader is not the same as a working one. The control plane’s controllers run in an active-passive configuration, and early on, we treated an unhealthy standby as if cluster operations had halted. They had not; what matters is whether a leader exists. But the harder lesson: a leader can quietly stop making progress while still renewing its lease and passing every health check. The signal that caught this was watching the controller’s work queue depth. If the queue fills while the leader looks healthy, the system is falling behind in ways no liveness probe will catch.
“A leader can quietly stop making progress while still renewing its lease and passing every health check. The signal that caught this was watching the controller’s work queue depth.”
The second is that maintenance ordering matters as much as the maintenance itself. etcd defragmentation is blocking, and the pause grows with database size. When it hit the leader, every write stalled. We taught the agent to move leadership to a healthy node before defragmenting, so the disruptive work always lands on a follower while writes keep flowing.
The third is that liveness is not readiness. A process can be alive but not ready while it warms caches, and routing based solely on liveness sends requests to an instance that cannot handle them. Equally, readiness flapping during graceful draining should never trigger a restart. We keep the two signals strictly separate: one decides recovery; the other decides routing.
None of this work is visible from the outside, and that is the point. The largest clusters taught us lessons that made every cluster faster. The riskiest migrations produced safety machinery that protects every upgrade. The upstream fixes we contributed for workloads at the edge of what Kubernetes can handle flow back to every user of the project.
“None of this work is visible from the outside, and that is the point.”
When you deploy on EKS and your pods come up in seconds, even during a burst, even when something behind the scenes goes wrong, that speed is not accidental. It is the accumulated result of years of operating at scales where small problems can become big ones fast, and engineering the system to contain them before they do.
There’s a vast difference between launching satellites and operating an industrial-scale computing infrastructure in orbit.
Imagine if one company could become the railroad, electric utility, and cloud-computing provider of the emerging space economy. That potential fueled excitement around the long-anticipated initial public offering of SpaceX. Investors are not simply betting on rockets anymore. They are betting on an entire orbital ecosystem.
Among the most ambitious and challenging ideas riding this wave of enthusiasm is something that sounds almost like science fiction: orbital data centers. SpaceX may be one of the most well-known companies seeking to build them, but it is not the only one.
But there is a vast difference between launching satellites and operating an industrial-scale computing infrastructure in orbit. Space is unforgiving. Radiation damages electronics. The electronics generate enormous amounts of heat, and getting rid of that heat is surprisingly difficult in space. Repairs are extraordinarily expensive, and every pound launched into orbit still carries a significant cost.
First off, consider what goes into an Earth-based data center, like those that you’ve probably begun to see pop up everywhere. These facilities power cloud computing, video streaming, online banking, scientific computing, and increasingly, artificial intelligence. But a data center is much more than a room full of servers.
A data center needs several things to operate reliably. The first is electric power. Servers, networking equipment, and storage devices consume large amounts of electricity, and that power demand is growing rapidly with AI.
The second is cooling. Almost all the electricity consumed by servers eventually becomes heat. If that heat is not removed quickly and reliably, equipment performance drops, failures increase, and the data center can shut down. Cooling systems often include air handling units, chillers, cooling towers, pumps, and increasingly, liquid-cooling equipment. In many facilities, cooling is the largest energy consumer after the computing equipment itself.
The third is physical infrastructure, including the necessary land, buildings, structural support, backup power, water systems, communication networks, and maintenance access. Data centers also need to be close enough to users and network backbones to provide fast digital services.
In short, Earth-based data centers are large electrical and thermal infrastructure systems built around computing hardware.
Placing Them in Space
So what would it take to build these data centers in space, and why are companies finding this possibility such an interesting business proposition?
As on Earth, these data centers would require massive amounts of power. In space, this power would come from solar panels. The sun always shines in space and can’t be blocked by clouds. However, depending on the orbit the solar panels are put in, the Earth may shadow them for some portion of the orbit.
Another potential advantage found in space is cooling. The cold background of space (roughly -455 degrees Fahrenheit, or -270 degrees Celsius) creates an opportunity: Waste heat from the data center could escape into space through radiators, keeping the electronics cool.
In principle, that design could eliminate some of the bulky and water-intensive cooling infrastructure used on Earth. However, those thermal radiators would require a large amount of surface area, and that would be in addition to the area required by the solar panels.
In space, there is no air to blow across hot equipment and help heat escape. The heat has to leave as infrared radiation, which is a relatively slow process. As a result, removing 10 megawatts of waste heat can require radiator surfaces comparable to the size of two football fields.
A space-based system would avoid competing for local land and water resources, and it would not generate neighborhood noise or require local zoning approval in the same way.
However, space is already getting crowded, and launching thousands of large orbital data centers would accelerate this issue. Orbital debris and micrometeorites are hazards because they can puncture the space data center, and a worst-case collision could destroy it and create even more space debris.
The frequency of space launches necessary to send all the equipment to orbit may also become a concern for some communities. SpaceX has had protests at its launch complex in Boca Chica, Texas from local activists who argue its rocket testing and launches damage the surrounding environment.
All that data would need to be sent between Earth and these data centers—and between the data centers themselves—using radio waves or laser communications systems. Although satellite constellations such as Starlink and Amazon Leo have demonstrated that doing this is possible, the amount of data sent to and from space would balloon.
Additional Challenges
These data centers, along with their solar panels and radiators, cannot be launched in one piece and would need to be assembled in space. This process would require new equipment for in-space servicing, assembly, and manufacturing.
Another key challenge is the refresh cycle of computing hardware. Data-center servers are not built to last forever. Operators on Earth usually replace or upgrade hardware every three to five years as chips improve, workloads change, and equipment ages.
And equipment failures can require replacing components. The refresh and repair processes are relatively straightforward on Earth, where workers can physically remove and replace servers.
In space, refresh and repair becomes much harder. Hardware sent to orbit may be difficult or too expensive to upgrade. If the computing platform cannot be updated, or too many components fail, it may become obsolete long before the surrounding infrastructure reaches the end of its useful life.
In a field where performance improves so rapidly and demand from computing continues to increase, this hurdle could prove a major economic and operational challenge.
Then there is the harshness of space. These data centers would be in a near vacuum, with constant radiation hitting them. And depending on their orbit, they would go from hot when in the sunlight to cold in Earth’s shadow many times a day. All of these challenges, and more, are issues that will need to be addressed.
So, Do They Still Make Sense?
Despite these challenges, companies are moving forward with designing space-based data centers. SpaceX just announced the design for its AI1 Compute Satellite, which it hopes to use as an orbital data center spacecraft. However, this satellite is 100 to 1,000 times less capable than current Earth-based data centers.
Not every computing task makes sense to do in space. Many data center applications depend on fast response times and close connections to users on Earth. Financial transactions, interactive AI services, and most cloud applications are extremely sensitive to delay.
More feasible early applications may be those that are less latency-sensitive and more tightly connected to space operations. Examples could include processing Earth observation data from satellites, military or intelligence data processing, scientific computing related to space missions, or specialized computing for satellites and other space assets.
In other words, the first viable space data centers may serve space-based customers before they compete with mainstream cloud data centers on Earth.
Last week AWS Summit New York City brought together thousands of customers, partners, and builders for a free, one-day event showcasing the latest in cloud and AI innovation. Dr. Swami Sivasubramanian, VP of Agentic AI at AWS unveiled a stack of AI launches in his keynote, all built around one thesis: agents that compound value over time.
Agents for working – You can launch autonomous agents and access a smarter activity feed with new Amazon Quick features, which now let you create and run multi-step agents directly in the desktop app and consolidates email, Slack, calendar, and tasks into a single prioritized view with personalized rules.
Agents for securing – You can shift from reactive to proactive security with AWS Continuum, a new AI-native security service that reasons, validates, and acts at machine speed across the full code vulnerability lifecycle. AWS Security Agent (now part of AWS Continuum) adds new features: threat modeling; pull request code scanning with remediation across major Git platforms; and IDE integrations via Kiro power, Claude Code plugin, and MCP.
Agents for building – You can write, ship, and modernize code in one continuous loop with Kiro, AWS DevOps Agent, and AWS Transform. Kiro introduces a native iOS app; AWS DevOps Agent adds release management capabilities to assess code changes before production; and AWS Transform continuous modernization reduces tech debt autonomously.
Last week’s launches
Here are last week’s launches that caught my attention:
AWS Local Zone in Hanoi, Vietnam – This new Local Zone is one of the first AWS Local Zones in the Asia Pacific with support for Amazon S3 and Amazon EBS Local Snapshots, enabling customers to meet data residency requirements by storing and backing up data locally. To get started, enable the Hanoi Local Zone (ap-southeast-1-han-1a) from the Regions and Zones tab in the AWS Global View or by using the ModifyAvailabilityZoneGroup API.
AWS Blocks, an open-source TypeScript framework for application developers (preview) – AWS Blocks runs a fully functional local environment with Postgres, authentication, and real-time messaging, no AWS account required. When you’re ready to deploy, the same application code runs on production AWS services with zero changes, and you can drop into AWS CDK at any point for direct resource configuration.
Grok 4.3 from xAI in Amazon Bedrock – You can use the Grok 4.3 model on Amazon Bedrock, giving you even more choice as you build generative AI applications across reasoning, agentic, and enterprise workflows. Grok 4.3 runs on a new inference engine in Bedrock designed for price performance, with support for tool calling, structured output, and response streaming.
Amazon S3 annotations: attach rich, queryable context directly to your objects – Amazon S3 now lets you attach up to 1 GB of rich, mutable, and queryable context directly to your objects using annotations, purpose-built for AI agents and autonomous workflows that need to discover, understand, and act on data at scale without maintaining separate metadata systems.
Amazon ECS announces faster service auto scaling – Amazon ECS service auto scaling now detects and responds to load changes faster with support for high resolution (20-second) metrics and metric publishing optimizations. In AWS benchmarking tests, time to trigger scale-out improved from 363 seconds to 86 seconds (76% faster), and total time to scale and provision new tasks improved from 386 seconds to 109 seconds (72% faster).
Amazon EC2 G7 instances accelerated by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs – AWS is the first major cloud provider to support NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs. G7 instances are accelerated by these GPUs with custom sixth-generation Intel Xeon Scalable processors, delivering up to 4.6x AI inference performance and up to 2.1x graphics performance compared to G6 instances.
Strands Agents introduces new capabilities – Strands is an open source toolkit for building production agents. You can now use better context management in Harness SDK, a new isolated execution environment with Strands Shell, and chaos testing and red teaming in Strands Evals.
AWS Management Console Private Access – You can access the AWS Console from VPCs without internet connectivity, allowing enterprises to manage their AWS infrastructure through the console while maintaining strict network security controls in air-gapped environments.
AWS Marketplace Storefront is now generally available – AWS Partners can create and deploy their own branded catalog of solutions and services on their website or application in hours. Channel Partners and Independent Software Vendors can now simplify how they manage their cloud marketplace business and make it easier for customers to discover and purchase their solutions from AWS Marketplace.
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Price reductions
AWS continues to look for ways to increase performance and lower prices for our customers. I noticed a few such efforts last week, so I’d like to share them:
Amazon GameLift Servers introduces free network bandwidth – Amazon GameLift Servers provides network bandwidth in and out of AWS at no additional charge for all instance types from generation 6 and later, including On-Demand and Spot, with no commitment required. You now pay only for your Amazon GameLift Servers instance hours; all network bandwidth is free.
AWS Marketplace reduces listing fee for professional services to 0.5% from 2.5% – This reduction makes it more cost-effective for consulting partners, systems integrators, managed services providers and independent software vendors to transact their services through AWS Marketplace, while retaining the procurement and billing benefits that come with it.
AI companions in games have long been constrained by fixed dialogue. PUBG Ally is a different kind of system. Built by KRAFTON for PUBG: BATTLEGROUNDS, this AI...
AI companions in games have long been constrained by fixed dialogue. PUBG Ally is a different kind of system. Built by KRAFTON for PUBG: BATTLEGROUNDS, this AI teammate is powered by NVIDIA ACE and its suite of efficient models and tooling. PUBG Ally uses automatic speech recognition, a 2B-parameter small language model, and text-to-speech to understand player voice…
When a group of academics started making open-source robotics hardware, a generation of roboticists got years of their lives back. Now, the bigger challenge is getting robots to think—and that’s starting to be open sourced too.
The shift is still early, but companies including Hugging Face, Nvidia, and Alibaba have all made significant bets on open-source robotics in the last two years, releasing tools and models aimed at the higher-level work of getting robots to reason, decide, and act.
The open source movement that accelerated other AI applications is now being applied to the problem of making robots smarter. If these attempts to bring AI to robotics with open-source platforms succeed, the barrier to building a capable robot could fall as fast as the barrier to building an AI application did.
The world ROS built
Open-source robotics software has been around since the mid-1990s, with early projects like Carnegie Mellon University’s Inter-Process Communication package and the Player Project in the early 2000s laying the groundwork. But these were often tied to specific research groups, and the field remained fragmented.
The Robot Operating System, ROS, changed that when it made its debut in 2007. By bundling tools and attracting more users, it became the de facto standard. The story of open-source robotics, in many ways, starts there.
Despite its name, ROS is not actually an operating system. Rather, it is a software framework that sits on top of Linux and handles robotic fundamentals like moving data between components, talking to hardware, building maps, planning paths, and supporting developer tools, such as data logging and visualization. Before ROS, every robotics team wrote that infrastructure themselves. It often took a year or two before a lab could get to the research it actually cared about.
Brian Gerkey, who helped build ROS in the mid-2000s, says he was drawn to the project because of how much open source had already changed the world, pointing out that nearly the entire internet is built on it.
“I’m a tool builder, and I like to share everything as openly as I possibly can, because I think that’s where we get the most impact out of what we build,” says Gerkey, board chair of Open Robotics and now CTO at Intrinsic, a robotics and AI unit of Google.
As it was developing, the AI community largely took the same approach, sharing research, models, and data openly, and the field accelerated faster than almost anyone predicted. Now some of those same advancements are arriving in robotics.
Open-source AI for robotics
Computer vision, once a hard problem, has advanced dramatically in just a few years, says Spencer Huang, Nvidia’s director of product for robotics. What once required significant expertise can now be done in a few lines of code. Simulation tools have become accurate enough to be useful for training, and access to the tooling that once required a specialized lab is now widely available, much of it open source.
“To get into robotics, you no longer need a Ph.D.,” he says. The result is a much larger pool of people who can contribute, and the field is starting to look less like a specialized discipline and more like a platform that anyone can build on.
Nvidia has built out an open-source robotics stack that covers the full development pipeline. Its Cosmos world models generate synthetic training data and simulate physical environments. Its GR00T models give robots the ability to reason through and execute complex tasks. And its Isaac frameworks handle the orchestration that ties training, simulation, and deployment together. Not everyone needs to train the robots from scratch, Huang says, and most people probably shouldn’t.
“If you gate pre-training, the field just never grows,” he says. “We should be able to provide a high-quality, state-of-the-art pre-trained model that anyone can go and take and fine tune for their own purposes.”
All of Nvidia’s open-source models live on Hugging Face, the open-source AI platform that has become the default place to share models and datasets. Hugging Face launched LeRobot, a community platform for robotics AI, in May 2024. Since its launch, the number of robotics datasets on the platform grew from 1,145 at the end of 2024 to more than 58,000 today, making it the single largest dataset category on the hub.
Hugging Face has also moved into hardware, acquiring robotics company Pollen Robotics. The acquisition came from a realization that software alone was not enough, according to Clement Delangue, Hugging Face’s CEO. The goal, as with the software, was to bring more people in.
The contributors to LeRobot include the biggest names in the industry, academic labs, and hobbyists building robots in their spare time. For instance, earlier this year, Alibaba released RynnBrain, an open-source foundation model for physical AI that the company claims outperforms comparable offerings from Google and Nvidia on benchmarks. That diversity of projects, Delangue says, is important.
“It is not just one model or one dataset or one hardware,” he says. “It is a lot of small contributions that everyone can be part of.”
Commercial incentives muddle the field
The stakes, Delangue says, go beyond convenience. A world where only a few proprietary systems control the robots in people’s homes is a concerning one. “Having robots at home that you don’t really understand, that you don’t really control, that a few people in Silicon Valley control is a scary thought,” he says. “Open source gives an alternative path.”
But getting there is not straightforward. The open sourcing happening now looks different from what produced ROS, which emerged largely from academics pooling their work with no commercial stake in the outcome. The biggest contributors today are companies with clear business reasons to want more people building on their platforms. That’s not necessarily a bad thing, says Bill Smart, a professor at Oregon State University, in Corvallis, who was part of the early open-source robotics community. But the incentives are worth being aware of.
He also worries that the lowered barrier to entry has a downside. Researchers coming from AI without a robotics background are sometimes solving problems the field already solved. A newcomer might spend a week training a neural network to move a robot’s hand from one point to another, unaware that the same task can be accomplished with a few lines of code using decades-old techniques. The incentives are not always pointing in the same direction as the progress.
Smart is not without hope though. Whatever the motives behind the open sourcing, he says, the effect is real. More people are in the field than ever before, the tools are genuinely easier to use, and the community is bigger and more diverse than anything that existed when ROS was getting started.
“Anyone can make a robot move now,” he says. “As an old tech guy, that makes me happy and sad, because I’m no longer special.”
Login
