ARM cloud instances are the Graviton, Cobalt and Axion types of the three providers: the same size as an x86 type at a lower hourly rate, on AWS by its own account up to 20 percent cheaper than comparable x86 instances and on Lambda with duration charges 20 percent lower. The saving comes from the rate per vCPU and, where performance per core is higher, from a smaller size. The fix belongs to the team that builds images and maintains deployments, because a change of architecture starts in the build pipeline and does not end in the console.

Symptom

The bill carries the architecture in the type name. On AWS lineItem/UsageType separates EUC1-BoxUsage:m6i.large from EUC1-BoxUsage:m7g.large, product/physicalProcessor names the processor, and Lambda bills Lambda-GB-Second against Lambda-GB-Second-ARM; RDS, ElastiCache and OpenSearch classes with a g in the name, such as db.m7g.large or cache.m7g.large, are the ARM variants. On Azure the Cobalt sizes appear as D4ps v6, D4pls v6 or E4ps v6 in MeterName, the x86 sizes as D4s v5 or D4s v6. On Google Cloud the SKUs read C4A Instance Core running in Frankfurt or T2A Instance Core running against N2 Instance Core running. An estate in which almost every compute hour runs on x86 types while the workloads live on Linux and in containers pays the premium for no reason. The families are explained in virtual machines and instance families.

The type name carriesthe architecturex86 lines: m6i,Lambda-GB-Second,D4s v5, N2ARM lines: m7g,Lambda-GB-Second-ARM,D4ps v6, C4A and T2AAlmost every compute houron x86 while the workloadslive on Linux andin containersPays the premiumfor no reason
The architecture sits in the type name, and compute hours almost all on x86 for Linux and container workloads are the symptom

How to detect it

AWS

The architecture per instance is in describe-instances:

aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,Architecture,PlatformDetails]' --output table

Which types offer ARM in the region: aws ec2 describe-instance-types --filters Name=processor-info.supported-architecture,Values=arm64 --query 'InstanceTypes[].InstanceType'. Compute Optimizer computes its recommendations with Graviton types only on request and shows the price difference and the migration effort per instance, derived from the workload it infers, low for EMR for instance and high for software without an ARM version:

aws compute-optimizer get-ec2-instance-recommendations --recommendation-preferences cpuVendorArchitectures=AWS_ARM64 \
  --query 'instanceRecommendations[].[currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].migrationEffort,recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value]' --output table

The functions, databases and caches on x86:

aws lambda list-functions --query 'Functions[?Architectures[0]!=`arm64`].[FunctionName,Runtime,PackageType,MemorySize]' --output table
aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,DBInstanceClass,Engine,EngineVersion]' --output table
aws elasticache describe-cache-clusters --query 'CacheClusters[].[CacheClusterId,CacheNodeType,Engine]' --output table

In billing data the x86 share is the sum of BoxUsage hours without a g in the type's family token against all BoxUsage hours, and for Lambda the ratio of the two GB-second usage types (AWS Cost and Usage Report).

Azure

The Cobalt 100 series Dpsv6, Dplsv6 and Epsv6 have been generally available since October 2024; Microsoft claims up to 50 percent better price performance than its own previous ARM generation, not than x86 (announcement). The estate by size, with the ARM sizes recognisable by the p in the family token:

az vm list --query "[].{name:name, size:hardwareProfile.vmSize, os:storageProfile.osDisk.osType}" -o table
az vm list-skus --location germanywestcentral --resource-type virtualMachines \
  --query "[?contains(name,'ps_v6') || contains(name,'pls_v6') || contains(name,'pds_v6')].name" -o tsv

AKS node pools show their size with az aks nodepool list --cluster-name <cluster> --resource-group <rg> --query "[].{name:name, size:vmSize, os:osType}" -o table. Azure Advisor has no recommendation for a change of architecture; its resize recommendation stays within the VM's architecture. In the cost export the share is the sum of Quantity per MeterName with a p in the size against all Virtual Machines rows (Azure cost exports).

Google Cloud

C4A runs on Google's Axion processor, T2A on Ampere Altra; Google claims for Axion up to 50 percent more performance and up to 60 percent better energy efficiency than comparable current-generation x86 instances, with no price figure (announcement). The x86 instances in the estate:

gcloud compute instances list --filter="NOT machineType ~ '/(c4a|t2a)-'" \
  --format="table(name,zone.basename(),machineType.basename(),status)"

GKE node pools: gcloud container node-pools list --cluster=<cluster> --location=<location> --format="table(name,config.machineType,config.imageType)". The machine type recommender recommends within the architecture; there is no recommender for the change. In the billing export the share is the sum of usage.amount on Instance Core running SKUs without C4A or T2A in the name (Google Cloud billing export).

How to fix it

  1. Check compatibility per workload, with the checklist AWS sets out for Lambda and which holds for all of them: every dependency has an arm64 version; container images are multi-architecture images (docker buildx build --platform linux/amd64,linux/arm64); layers, extensions, monitoring and security agents and licensed software run on ARM; the image or AMI is an arm64 variant; CI builds and tests both architectures (Lambda architectures).
  2. Migrate in this order: stateless services behind a load balancer first, with a mixed pool and a comparison of response times; then functions, on Lambda with aws lambda update-function-configuration --function-name <fn> --architectures arm64, versioned and rolled out through a weighted alias; then managed services, where the change is a class change with a restart: aws rds modify-db-instance --db-instance-identifier <id> --db-instance-class db.m7g.large --apply-immediately, aws elasticache modify-replication-group --replication-group-id <id> --cache-node-type cache.m7g.large --apply-immediately, for OpenSearch aws opensearch update-domain-config with a Graviton instance type; then Kubernetes pools, as an additional ARM pool with a taint, tolerations and multi-architecture images before the x86 pool shrinks; stateful servers last, rebuilt.
  3. On Azure and Google Cloud the VM itself cannot be switched: an x86 image does not run on a Cobalt or Axion size, so a new VM comes from an arm64 image and replaces the old one, as with a change of generation.
  4. Change the templates: launch templates, scale sets, instance templates, node pool definitions, so the next environment comes up on ARM.

The new rate applies from the start of the new type; none of the three CLIs offers a dry run for these changes, so the list from the first step comes before every call.

yes: Lambda, RDS,ElastiCache, OpenSearchno: an Azure orGoogle Cloud VMCompatibility checklist perworkload: arm64 versions,multi-architecture images,agents and licencesMigrate in order: statelessservices, functions, managedservices, Kubernetes pools,stateful servers lastSwitchablein place?Change the architectureor class, with a restartA new VM from an arm64image replaces the old oneChange the templates so thenext environment comesup on ARM
Compatibility is checked first, the migration runs stateless to stateful, and only AWS resources switch in place

Risks and side effects

  • A dependency without an arm64 build stops the migration there; native extensions, old drivers and proprietary agents are the usual cases. The test in the mixed pool finds them before the x86 pool is gone.
  • Performance per core differs by workload in both directions; the size of the ARM instance is measured, not carried over.
  • A commitment on x86 stays: an EC2 Instance Savings Plan and a Standard Reserved Instance apply to their family, a Compute Savings Plan covers Graviton too; Azure reservations apply per size group; resource-based committed use discounts on Google Cloud per machine family (choosing between commitment types).
  • Third-party licences are sometimes limited to x86 or priced per core; the change alters the core count.
  • Windows workloads drop out: Dpsv6 supports Windows client VMs, and the server and database world on ARM is Linux at all three providers.

How to verify the saving

Before: per resource, the hours and the amount of the x86 line, BoxUsage:m6i.large, D4s v5, N2 Instance Core running, in the last full month, for Lambda the GB-seconds on Lambda-GB-Second. After: the same resource or its replacement on the ARM line in the first full month, with the same work, measured in requests or jobs, and a lower amount; the x86 share of all compute hours is the figure for the estate. The price difference from Compute Optimizer or from the instance comparison is the estimate, the team's consent makes it accepted, the change implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. Where an x86 commitment is left behind, its utilisation shows whether the saving is real.

Sources

Read on 2026-10-21. AWS Graviton, Lambda instruction set architecture, Lambda functions powered by Graviton2, AWS blog of 2021-09-29, Compute Optimizer EC2 recommendations, get-ec2-instance-recommendations, describe-instance-types, Azure Cobalt 100 VMs generally available, Dpsv6 series, Google Axion, General-purpose machine family.