Embrace the Power of ARM and AWS Graviton with Qovery – It's Now GA!
Why Choose AWS Graviton?
AWS Graviton processors are specifically designed for cloud workloads running in Amazon EC2, offering incredible advantages over traditional AMD64 instances. Here are some of the key benefits of AWS Graviton that will surely make you smile.
Best Price Performance
AWS Graviton-based instances can deliver up to a whopping 40% better price performance over comparable current generation x86-based instances for a broad range of workloads. That means more bang for your buck!
Here are some exciting benchmarks to take a look at:
- Amazon Graviton3 vs. Intel Xeon vs. AMD EPYC Performance
- Comparing Graviton (ARM) Performance to Intel and AMD for MySQL
- Evaluating Graviton 2 for data-intensive applications: An Arm vs. Intel comparison
You'll see that performance uplift is domain application specific, but the price/performance ratio is always positive for Graviton processors over Intel equivalent.
Improved Power Efficiency and Low Carbon Footprint
Feel good about your contribution to the environment, as Graviton-based instances use up to 60% less energy for the same performance than comparable EC2 instances.
How To Use AWS Graviton With Qovery
Creating a New EKS Cluster or K3S Instance with AWS Graviton
Ready to harness the power of AWS Graviton with Qovery? Creating a new EKS cluster or K3S instance with AWS Graviton is as easy as pie. Just follow these simple steps:
- Log in to your Qovery account and head over to the "Clusters" (cloud icon) section.
- Click on the "Add Cluster" button.
- Choose "Amazon EKS" or "K3S" – whichever tickles your fancy.
- In the "Instance Type" dropdown menu, select your preferred AWS Graviton instance type (T4g, M7g, C7g, R7g, or X2gd).
- Complete the remaining fields for your cluster configuration, and click on the "Create Cluster" button.
Voilà! Once your cluster is ready, it will run on AWS Graviton instances.
Migrating from AMD64 to AWS Graviton (ARM) for existing workload
We've got your back if you're considering migrating your existing workloads from an AMD64 cluster to an AWS Graviton-based cluster. Follow these steps:
- Create a new EKS cluster or K3S instance with AWS Graviton instances (as described earlier).
- Head to your "Project" section
- Locate the environment you want to migrate and click the "Clone" button.
- Choose the new AWS Graviton-based cluster as your "Target Cluster".
- Click "Clone" and watch the magic happen as Qovery replicates your apps to the new cluster.
- Give your application a test run on the new cluster to ensure everything works just as it should. (You would need to target ARM for all your apps and make the appropriate change if necessary - contact us on our forum if you need some help)
- When you're satisfied with the migration, it's time to bid farewell to the old AMD64 cluster and decommission it.
Downsides of AWS Graviton and ARM
While AWS Graviton and ARM offer numerous advantages, it's essential to consider some potential downsides before deciding. We believe in being transparent with our users, so here are a few things you should be aware of:
Compatibility
Although ARM and AWS Graviton are gaining popularity and support, some software applications and libraries may not yet support ARM architecture. Before migrating, it's crucial to verify that your application's dependencies and tools are compatible with ARM.
Performance
It's essential to analyze your application's performance needs and run tests to determine the best architecture for your use case.
While AWS Graviton processors generally provide better performance for many workloads, there may be cases where specific applications perform better on traditional x86 architecture. It's essential to analyze your application's performance needs and run tests to determine the best architecture for your use case.
Transition Effort
Migrating from AMD64 to ARM may require some effort, primarily if your application relies on libraries or tools that need to be updated or replaced. While Qovery can help simplify the migration process, planning and allocating resources for this transition is important.
Conclusion
We wholeheartedly recommend embracing AWS Graviton / ARM for improved cost performance, enhanced power efficiency (resulting in a lower carbon footprint), and bringing a smile to your CFO's face! 😊 However, it's crucial to ensure your apps are fully compatible before taking the leap.
With Qovery's support for ARM and AWS Graviton instances, there's never been a better time to explore new possibilities for your cloud workloads. While there are numerous benefits to adopting these more efficient, cost-effective processors, it's crucial to consider the potential downsides and make an informed decision based on your specific needs.
Whether you're creating a new EKS cluster or K3S instance with AWS Graviton or migrating from AMD64 to ARM, our platform is designed to make the process as smooth as possible. And remember, we're always here to lend a helping hand. If you need assistance with the migration or have any questions, don't hesitate to get in touch with us. Our friendly team is eager to guide you through the process and help you make the best choice for your unique requirements. So go ahead, explore the power of ARM and AWS Graviton with Qovery, and let's make your cloud journey an amazing one!
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)