AI-narrated article. Prose is preserved with pronunciation adjustments; code and image cues refer to the written article.
Benchmark EKS Auto Mode, Graviton and Spot Without Confounding the Result
This is the AI-narrated article. The prose follows the written post; pronunciation is adjusted, and code and images are announced separately.
Separate architecture, spare capacity and operating ownership so a lower node price becomes a defensible service deployment decision.
TL;DR: EKS Auto Mode, Graviton and Spot change different parts of a deployment decision. Compare architecture on On-Demand capacity first, then evaluate Spot with the same application contract. Use isolated NodePools, explicit placement and verified architecture-specific images. Measure correct work, latency, failures, scale-out and recovery alongside complete attributable cost, including Auto Mode charges. This article provides a practical configuration for an existing approved test cluster, failure diagnosis and cleanup boundaries. It reports a source-verified evaluation design and static configuration review; no cloud performance benchmark, interruption test or savings measurement was executed.
A cheaper node can deliver a more expensive request
Your API runs on x86 On-Demand nodes. A proposed migration combines EKS Auto Mode, Graviton and Spot, then compares the new EC2 hourly price with the old one. That comparison cannot explain whether a saving came from architecture, purchasing spare capacity, different pod packing or transferring infrastructure operations to AWS. It also hides requests lost while replacement capacity becomes ready.
Treat these as separate decisions. First establish whether the application meets its latency and correctness contract on Arm. Then evaluate Spot under the same contract. Finally compare the operating model, including Auto Mode charges and the work your team retains. The outcome should be a deployment policy you can defend, rather than a percentage detached from workload behavior.
This is a source-verified evaluation design and configuration example. No cloud benchmark, interruption experiment or savings result was executed or measured for this article.
Separate the variables before choosing a winner
Use three initial cohorts: Auto Mode x86 On-Demand, Auto Mode Arm On-Demand and Auto Mode Arm Spot. Compare the first pair for an architecture decision; compare the second pair for a capacity decision. A later managed-node-group comparison answers a different ownership question and needs its own baseline.
Keep the application revision, dependency versions, input distribution, response correctness checks and external services constant. An identical multi-platform image manifest still contains different architecture-specific binaries; record both child digests, compiler flags and runtime settings. Docker documents the manifest and build mechanisms.
Equal vCPU counts are a starting constraint, not evidence of equal application capacity. Match instance generation, memory and relevant network/storage capability as closely as possible, then publish the exact types actually selected. For a deployment decision, a second comparison can right-size each architecture independently to the same service objective. Label that as a tuned comparison; do not mix it with the initial controlled result. AWS's Graviton testing whitepaper recommends beginning with customer-visible application performance.
Image. Controlled architecture comparison followed by capacity comparison
Encode a cohort that the scheduler cannot blur
Use an existing, approved test cluster with Auto Mode enabled, a supported Kubernetes version, compatible kubectl and an existing ready NodeClass named default. If the cluster was created without built-in pools, that NodeClass is not automatically created. Have the platform owner select an appropriate existing class rather than copying credentials or subnet settings. The example uses karpenter.sh/v1 and Auto Mode's eks.amazonaws.com NodeClass group, as documented in Create a NodePool.
Save this as cohort-nodepool.yaml. The label and taint isolate the cohort; workload selection must require that label and tolerate the taint. The four-vCPU constraint limits one source of variation but does not pin a processor generation. For the controlled architecture test, add a node.kubernetes.io/instance-type requirement selecting the chosen matched type in each pool, and record generation and CPU manufacturer. Use the flexible family selection below for a separately identified capacity trial. Record eligible and realized instance types separately. Check regional availability and Auto Mode's supported instance reference before approval.
Code example. Refer to the written article for the complete code.
For x86, create a separately named pool with amd64 and cohort x86-od. For Arm Spot, use spot and cohort arm-spot. Replace the name, label and taint together. Explicit capacity requirements matter: allowing both purchase types makes the actual placement an outcome, not a controlled comparison. NodePool limits are resource guardrails, not a currency budget; retain account-level spend controls and monitor provisioning.
Save this as cohort-placement.yaml, a strategic merge patch for an existing disposable Deployment named api-benchmark in namespace benchmark. Its container must already use your verified Arm-compatible image, readiness checks and explicit CPU/memory requests. Keep those settings and resource limits identical across the initial cohorts. Kubernetes schedules from resource requests, while CPU limits govern throttling; changing either introduces another experimental variable.
Code example. Refer to the written article for the complete code.
After budget and platform approval, these commands apply only that test pool and Deployment. They can provision billable nodes. The platform operator owns cluster-scoped NodePool changes; the application operator needs access only to the test namespace and its Deployment. Scope their Kubernetes authorization accordingly rather than distributing cluster-admin access. Inspect existing affinity and tolerations first; this patch replaces the tolerations list and requires a dedicated workload.
Code example. Refer to the written article for the complete code.
Measure the service contract through the whole lifecycle
Drive the real request mix from a separate load generator with enough headroom, using the same offered arrival rate for each cohort. Count offered, completed, failed and timed-out requests independently. A client that waits for every response before sending the next request can reduce its offered load when the server stalls, masking the severity of a regression.
Separate warm steady state from scale-out: image pull, node provisioning, scheduling, readiness and cache warm-up contribute different delays. Repeat runs and rotate cohort order to reduce dependency drift and time-of-day bias. Preserve latency distributions and request counts per run; averaging percentile values obscures what happened. Report confidence intervals appropriate to the sampling design, not an unexplained precision claim.
Define the acceptance gate before observing results: correct responses, required throughput, latency objective and acceptable error rate. Record pending-pod time, throttling, memory pressure and actual placement alongside application metrics. These are diagnostic signals; CPU utilization alone does not establish a customer benefit.
Include the capacity you paid for while recovering
Use total attributable cost divided by successful, correct work completed inside the service contract. State how you allocate shared cluster, load balancer, storage, networking and observability costs. Include idle capacity, scale-out delay, overlapping replacements and repeated work. Keep effective billed rates and list-price scenarios separate.
EKS pricing adds Auto Mode charges to EC2 instance charges; the management charge is independent of the EC2 purchase option. A Spot discount therefore does not apply uniformly to the combined node bill. Operational labor belongs in a separately documented ownership comparison, with explicit assumptions rather than invented hours saved.
Spot availability changes the experiment. Auto Mode handles interruption notices, but application recovery remains your responsibility. EC2's two-minute interruption notices are best effort. A PodDisruptionBudget cannot prevent involuntary disruption. Replayed jobs need idempotency or checkpoints; APIs need adequate surviving capacity and bounded retries.
Diagnose the failed cohort before relaxing its contract
Suppose Arm Spot pods remain Pending while Arm On-Demand succeeds. This illustrative failure does not prove Arm is slow. Inspect Deployment events, NodePool/NodeClass conditions, taints, placement requirements and compatible instance availability using the Auto Mode troubleshooting guide. An overly narrow family or availability-zone constraint can make a cheaper cohort unusable.
Restore the approved On-Demand placement for the disposable workload, then broaden eligible Spot types only after checking application requirements. A Spot-only selector does not fall back to On-Demand. If production policy permits both, evaluate and report the realized capacity mix as a separate cohort. An image execution-format failure instead requires rebuilding and validating the architecture-specific image, not changing scheduling constraints.
At the end, preserve receipts and remove the disposable Deployment before deleting its dedicated NodePools; deleting a pool can terminate its nodes. Have the owner confirm no unrelated workloads use it and verify NodeClaims and billable resources have drained. Retain shared NodeClasses and the existing cluster. These cleanup steps were reviewed, not executed.
Questions that change the deployment decision
Should Graviton and Spot be introduced together? Evaluate architecture first, then capacity, so a failure has an interpretable cause.
Does a lower hourly node price establish savings? Only after service acceptance and complete cost attribution, including recovery and repeated work.
Can the built-in pool serve the Spot cohort? Use a custom, explicitly constrained pool; AWS documents built-in pools as On-Demand in its cost-control guidance.
What has this example validated? Current documented APIs and a static configuration review. It provides no measured performance, savings or cloud deployment result.