We’re bringing Edera’s hypervisor-backed workload isolation to AWS Graviton, with bare-metal support in our upcoming release of Edera. Customers will have another infrastructure option for running isolated workloads, including build jobs, customer-supplied code, and code generated by AI agents.

Graviton is AWS’s arm64 processor family. For customers considering it, we want the decision to come down to application performance, operating cost, and capacity requirements, rather than whether their security runtime supports the hardware. This work lets customers consider Graviton without replacing Edera or designing a different workload isolation approach for their arm64 fleet.

More Choice in Where Your Compute Budget Goes

Compute costs grow with every build, request, and execution a platform handles. At sufficient scale, improving the cost of completing that work can change the economics of the service. arm64 support gives customers another option to compare against their existing infrastructure.

The opportunity is lower cost per completed workload while keeping Edera’s isolation in place. A build platform can compare how many representative builds it completes within its required turnaround time. An execution service can compare the cost of handling its customer workload at the concurrency and latency it needs. The decision can be based on the service customers actually operate, not a processor benchmark detached from their application.

We are not attaching a universal savings percentage to this release. The benefit is being able to make that comparison with the intended runtime and security configuration already included. Customers can move workloads that benefit from Graviton and leave others where they are, rather than treating arm64 adoption as an all-or-nothing fleet migration.

Shared Infrastructure for Workloads You Cannot Trust

A service running code from multiple customers has to account for the possibility that some of that code is malicious or compromised. The same applies to build systems that execute third-party dependencies and agent platforms that run generated code. The platform needs to separate those workloads without making every customer or job a dedicated physical infrastructure deployment.

Edera gives each zone its own Linux kernel and a hypervisor-enforced memory boundary. Bringing that architecture to Graviton lets customers run isolated environments on shared arm64 hosts, rather than putting every workload behind the same host-kernel boundary.

For a platform operator, this creates more room to consolidate suitable workloads. Capacity can be managed across the service while execution remains separated into zones. The business can grow the shared worker fleet as demand increases, with workload isolation built into how those workers run.

This does not replace identity, network policy, or secrets management. It addresses the execution boundary underneath those controls, giving customers a way to use shared compute without relying on a shared workload kernel as the only line of separation.

Less Custom Software for the Operating Team to Maintain

A hardware migration becomes much more expensive when it requires a special operating system that the team must maintain indefinitely. We did not need that for this bring-up. The Linux control domain runs a stock distribution long-term-support kernel, and the assigned device uses an unmodified driver inside the guest.

The platform changes belong in Xen, where the hardware discovery and virtualization behavior needed to be implemented. We have not made this support depend on a private Linux patch that customers must account for every time they update their distribution kernel.

That reduces the number of exceptions an operating team has to carry. Kernel updates, troubleshooting, and vendor support are easier to manage when the Linux environment has not accumulated another set of platform-specific modifications.

Customers still need arm64-compatible application images and dependencies. What this work avoids is turning that application preparation into a separate Linux maintenance project as well. Edera handles the virtualization layer while the application team focuses on getting its software running and performing well on the target architecture.

Physical Device Access with Memory Protection

Some workloads need direct access to hardware, not just CPU and memory. The underlying work includes ACPI-based PCI device assignment, allowing a guest to use a physical device through its normal driver while Xen controls the device’s access to memory through the IOMMU.

That protection is important because a device can read and write memory independently of the guest CPU. Assigning a device without constraining those accesses would undermine the isolation the customer chose Edera to provide.

Our working device-assignment path brings those requirements together. The guest can load its driver and bring the interface up, while the SMMU, arm's IOMMU, applies the memory translations managed by Xen. This gives us a basis for supporting device-dependent workloads without treating direct hardware access as an exception to memory isolation.

Device availability and support will still depend on the deployment. The value is that the arm64 platform work includes the machinery needed for protected device assignment, rather than stopping at getting ordinary CPU workloads to boot.

Graviton First, with Room to Expand

The immediate product target is Graviton bare metal. Xen needs access to arm’s hardware virtualization privilege level, so this initial support is not for ordinary virtualized Graviton instances. Customers planning a deployment should size their evaluation around bare-metal capacity.

The implementation is built around standard arm server firmware interfaces, including UEFI and ACPI, rather than a Graviton-specific hardware description. That gives us a foundation for qualifying additional arm64 server platforms over time. The changes are in our Xen tree today, with upstreaming planned.

For customers, the outcome is more choice without having to replace the isolation they already rely on. They can consider arm64 for its application economics, share suitable infrastructure across isolated workloads, and do so without adopting a custom Linux kernel for this support.

That is what we are building toward with our upcoming release of Edera. Graviton becomes another place to run the platform, and customers get to decide where it earns a place in their fleet.

Want to see how Edera's arm64 support fits into your infrastructure? Get in touch with our team to talk through your Graviton deployment plans, bare-metal capacity needs, or device assignment requirements.

For the full technical breakdown of how we built bare-metal arm64 support, see our companion technical blog.