Ampere ARM on OCI: Porting Apps for Price Performance

Every OCI cost review we run ends up staring at the same line: compute. And in almost every estate, a meaningful slice of that compute is stateless application servers, API backends, queue workers, and container fleets that do not care in the slightest what instruction set they run on, as long as the binaries match. Those workloads are paying x86 prices for work that ARM does cheaper. Oracle has priced its Ampere shapes aggressively enough that the question is no longer whether ARM saves money, but how much of your estate can take advantage of it and how safely you can get there.

This article sits in our series on application development and serverless on OCI. We will cover what the A1 and A2 shapes actually are, why the price performance story holds up, which workloads port in an afternoon and which should stay on x86, a numbered porting framework we use on engagements, multiarch container builds, ARM node pools on OKE, how to benchmark honestly, and the pitfalls that turn an easy win into a rollback.

What the Ampere A1 and A2 shapes are

OCI offers ARM compute on processors from Ampere Computing. The A1 shapes run on the Ampere Altra processor: physical cores with no simultaneous multithreading, which means one OCPU is one whole core rather than a hardware thread. A1 is a flexible shape, so you choose OCPU count and memory independently, scaling from a single core up to large instances with hundreds of gigabytes of memory, in both virtual machine and bare metal forms. The A2 shapes run on the newer AmpereOne processor and bring higher core counts, faster memory, and stronger per core throughput for the workloads that need the headroom.

Two properties matter more than the spec sheet. First, the flexible shape model means you stop buying compute in fixed bundles: an eccentric service that wants 3 OCPUs and 40 GB of memory simply gets that, with no rounding up to the next size. Second, the absence of multithreading changes how utilisation reads: an A1 core at 80 percent is doing 80 percent of a real core's work, whereas an x86 OCPU at the same number is sharing silicon between two threads. Plenty of teams discover their throughput per OCPU goes up on ARM purely because the unit they were buying changed underneath them.

The price performance story

The arithmetic is blunt. A1 compute lists at roughly a cent per OCPU per hour, with memory billed separately at a small fraction of a cent per gigabyte. Against the AMD based E series flexible shapes, the per core list price difference typically lands between 30 and 50 percent in favour of Ampere, before any throughput gains are counted. For a stateless fleet of dozens of cores running around the clock, that difference compounds into real money every month, and it stacks with the universal credits discount your contract already carries.

Then there is the tier nobody should ignore: OCI's Always Free allowance includes 4 Ampere A1 OCPUs and 24 GB of memory per tenancy, usable as one instance or several, forever, on top of the trial credits. That is a genuinely useful environment, enough to run a small production service, a staging cluster, or the proof of concept that settles the porting argument with measurements instead of meetings. We routinely tell clients to burn their porting risk down on the free tier before a single paid OCPU is committed.

What ports easily and what fights back

The easy movers

Anything that runs on a managed runtime is most of the way there already. Java has had first class ARM support in mainstream JDK builds for years, and the JIT produces excellent aarch64 code; for typical Spring or Micronaut services the port is a base image change. Go cross compiles to arm64 with a single environment variable and produces static binaries that just run. Python and Node.js interpreters are fully supported, with the caveat that native extension wheels must exist for arm64, which they now do for the overwhelming majority of popular packages. And containerised services in general are the sweet spot, because the container boundary makes the architecture an image tag rather than a server rebuild, whether they land on OKE or on OCI Container Instances.

The hard cases

The friction is always at the edges of the stack, never the middle. Vendor binaries shipped only for x86, agents, database drivers, licensed engines, are a hard stop until the vendor ships arm64 builds, so inventory them first. Native code with architecture assumptions, hand written SIMD intrinsics, assembly hot paths, or build systems that hardcode x86 flags, needs real porting work and real testing. Old runtimes pinned by an application that cannot upgrade may predate usable ARM support. And anything that depends on x86 only instruction set extensions for performance, certain media codecs and scientific kernels, may run on ARM but lose the throughput advantage that justified the move. None of this makes a portfolio unportable; it makes a portion of the portfolio later rather than never, and the inventory tells you which portion.

A six step porting framework

This is the sequence we run with clients. The steps are ordered so that the cheap discoveries happen before the expensive commitments.

Multiarch builds with buildx

The technical heart of the migration is the image build. Docker Buildx builds one logical image for several architectures and pushes a manifest list, so every consumer pulls the right variant automatically. A minimal version looks like this.

docker buildx create --name multiarch --use

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag fra.ocir.io/mytenancy/shop/api:1.4.2 \
  --push .

Under one tag, OCIR now stores both variants, and a node pulls whichever matches its architecture. Two practical notes. Emulated cross builds through QEMU work but can run several times slower than native; for heavy compile steps, give the pipeline a native ARM builder, either a self hosted runner on an A1 instance or the ARM runners GitHub now hosts, and let each architecture build natively. And pin base images by digest of the manifest list, not of a single architecture variant, or your multiarch tag quietly stops being multiarch. The pipeline mechanics around this, OCIR pushes and OKE rollouts from GitHub, are covered in our guide to CI/CD to OKE with GitHub Actions.

ARM node pools on OKE

On OKE, ARM adoption is gradual by design, because a cluster happily mixes architectures. You add a node pool on a flexible A1 or A2 shape next to the existing x86 pools, and Kubernetes labels every node with its architecture automatically. Workloads with multiarch images schedule anywhere; workloads still x86 only are kept off the ARM pool with a simple node selector or affinity rule until their images catch up. The same pattern in reverse, tainting the ARM pool and tolerating it from ported workloads, gives you a controlled canary surface. Watch the DaemonSets: every agent that runs on every node, logging, monitoring, security, must itself be multiarch before the first ARM node joins, or it will sit in a pull error loop on the new pool. Cluster autoscaling works per pool, so the cost win compounds as the scaler grows the cheap pool and shrinks the expensive one.

How to benchmark honestly

Most ARM versus x86 arguments are settled with someone else's benchmark, which is to say not settled at all. Run your own, and keep the method boring. Use your application and your traffic shape, not a synthetic suite, because instruction mix decides everything. Normalise to cost per unit of work: requests per second per dollar per hour, or jobs per hour per dollar, since a chip that is 10 percent slower but 40 percent cheaper wins by a margin raw latency will never show. Hold the software constant, same runtime version, same settings, same data, and vary only the architecture. Warm up managed runtimes properly before measuring, run long enough to capture garbage collection and cache behaviour, and repeat runs to see variance. Then record the losing cases with as much care as the winning ones: a workload that regresses on ARM is not a failure of the project, it is the project working, because the framework exists precisely to sort the estate into movers and stayers.

Ampere or the x86 E series

The honest comparison is not which processor is better, but which is better for a given slice of the estate.

In practice the answer is a portfolio split, not a winner. The serverless layers of the platform make the same point from the other direction: when compute is consumed through Functions or Container Instances, the shape decision shrinks toward invisibility, a tradeoff we explore in serverless versus containers on OCI.

Common pitfalls

The failures we see are rarely about the processor. The forgotten sidecar: the application image is multiarch but a logging agent or service mesh proxy is not, and the pod fails on the ARM pool. Audit every container in the pod spec, not just yours. The wrong image variant in CI: a pipeline that builds only amd64 and deploys to an ARM pool produces exec format errors that look baffling at two in the morning and obvious at ten. Capacity assumptions: popular ARM shapes can be in heavy demand in some regions, so request limits and reserve capacity ahead of a large cutover rather than during it. Benchmarking the wrong unit: comparing one ARM OCPU to one x86 OCPU and forgetting that one is a core and the other a thread, which understates the ARM result. Skipping the rightsizing pass: teams that lift their x86 instance sizes across unchanged leave a second round of savings on the table, because the flexible shape exists precisely so the size can follow the measurement. Every one of these is avoidable with the inventory and canary steps above.

Bringing it together

Ampere on OCI is one of the rare cost levers that does not ask you to degrade anything: same region, same network, same Kubernetes, lower price per unit of work for the workloads that fit. The work is real but bounded, an inventory, a build pipeline change, a test pass, a canary, and the platform meets you halfway with flexible shapes, mixed architecture clusters, and a free tier big enough to prove the case. The estates that win treat it as a rolling programme: every new service ships multiarch by default, every quarter another slice of the old fleet moves, and the compute bill bends down without a single big bang weekend. If you want help scoring your estate, building the benchmark, or running the cutover, that is exactly the work of our OCI compute practice, and it starts with an assessment of what you run today and what it costs.