Graviton2 made processor choice a cloud software decision
AWS widened the workloads targeted by its Arm processors. Capturing the promised savings still required compatible software, testing against service targets and a carefully planned migration.
On 3 December 2019, AWS announced Graviton2 processors and new EC2 instance families for general use and workloads demanding more compute or memory. A software company would be able to rent the new silicon through a familiar cloud service rather than purchase and install its own servers. That lowered the practical barrier to evaluating a different processor architecture. It also moved some of the work into software delivery: libraries, machine images, monitoring agents and build systems needed to support the architecture before an application could benefit from it.
The announcement put M6g instances into preview and placed general availability of the new families in the coming months. AWS claimed up to 40% better price/performance than comparable M5, C5 and R5 instances. A startup would need to test that claim against its own workloads and total infrastructure costs before estimating savings.
Graviton2 targeted a wider range of workloads
AWS's first Graviton-based A1 instances, launched in November 2018, targeted workloads that could distribute work across smaller machines, such as web servers and containerised microservices. Their largest listed configuration had 16 virtual CPUs. The new Graviton2 families were announced with support for up to 64 virtual CPUs, targeting workloads including application servers, databases, caches, electronic design automation and video encoding. The range of proposed uses had widened substantially.
| Period or category | maximum vCPUs per instance listed at announcement |
|---|---|
| A1 launch, November 2018 | |
| Graviton2 announcement, December 2019 |
Maximum instance capacity in AWS's announcements. A1 was available at its launch; the Graviton2 range was announced with M6g in preview. These counts do not measure relative application performance.
That change did not make virtual CPU counts a performance benchmark. A larger instance offers a different capacity envelope; actual throughput depends on the processor, memory behaviour and software. The commercial significance was the expanding choice available to teams already buying compute from AWS. More workloads could plausibly enter a migration evaluation, including applications for which the initial A1 configurations were too restrictive or poorly matched.
The percentage needed a denominator
The advertised improvement concerned price/performance, with the existing M5, C5 and R5 families as comparators. It did not describe every workload, every purchasing commitment or the cost of storage and data transfer. A useful evaluation would hold the required work and service quality constant: requests completed within a latency target, records processed per hour, or videos encoded at the same settings. The question was how much infrastructure spend produced that output, including the resources needed around the processor. The advertised saving could then be assessed against an application's actual operating requirements.
The difficult dependency might be outside the application
The original A1 launch already distinguished applications written in scripting languages from software compiled to native code, which needed rebuilding for the new architecture. An apparently portable service can still depend on a native compression library, database extension or third-party binary. Packaging that service inside a container does not remove those dependencies. A startup considering Arm therefore needed to inspect what it actually deployed, rather than infer compatibility from the language used for its main application.
AWS's Graviton2 announcement listed operating systems, container services, developer tools and monitoring or security suppliers supporting the new instances. That ecosystem was commercially important because a production service needs to be observable and maintainable after it starts. A working application can still be expensive to operate if its incident response tools or build dependencies lack support. The migration plan needed to include those supporting components and a way to return traffic to a known configuration if problems appeared.
Engineering time belonged in the savings calculation
For a young company with a small cloud bill, building and maintaining another architecture could consume more engineering value than it saved. A service with sustained compute demand had a different calculation. The sensible unit was the workload, allowing a team to move a suitable service while leaving others on their existing machines. Investors assessing an efficiency claim could then examine the migration effort, the ongoing cost of maintaining both environments and the volume of activity over which that work would pay back. A benchmark win mattered only when it could survive normal operations.
A cloud provider could also be the chip designer
Graviton2 used Arm cores and custom silicon designed by AWS, manufactured with a 7-nanometre process. AWS controlled both the processor offering and the cloud channel through which customers would encounter it. That relationship gave the company a direct path from a hardware design to a rentable service. For a semiconductor startup, it illustrated why a route into deployed systems could be as consequential as the chip's specifications.
A specialist chip company still needed software support, customer qualification and a commercial channel. A developer tools business could instead serve the growing need to compile, test and observe applications across architectures. Those are different investment cases: one depends heavily on hardware integration and a small number of major buyers, while the other depends on whether the compatibility problem is frequent and costly enough to justify a separate product. Graviton2 did not settle either case, but made the dependencies easier to identify.
Preview access preceded production availability
AWS announced M6g general availability on 11 May 2020; that later announcement still described C6g and R6g as coming soon. During preview, a company could request access, examine dependencies and plan a comparison. A production rollout required general availability of the relevant instance family. The initial investment signal was a widening architecture choice inside the cloud, with the eventual operating benefit dependent on work still to be done.
Investment implications
- The announced Arm instance range expanded beyond the smaller A1 machines already in service.
- A vendor's price/performance claim needs validation against the application's output and service targets.
- Compatibility work reaches native libraries, deployment tools and operational agents as well as application code.
- M6g entered preview at the announcement; general availability followed later.
Sources
- Announcing New Amazon EC2 M6g, C6g, and R6g Instances Powered by Next-Generation Arm-based AWS Graviton2 Processors (opens in a new tab)
Amazon Web Services
- New – EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors (opens in a new tab)
Amazon Web Services
- New – EC2 M6g Instances, powered by AWS Graviton2 (opens in a new tab)
Amazon Web Services
Published
