Deploy an Amazon EKS cluster with AWS Graviton-based nodes using Rafay
Introduction
Set up Rafay and AWS access
Create an Amazon EKS cluster using a Rafay cluster manifest
Deploy NGINX to the Amazon EKS cluster and clean up
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  1 hr
Last updated:  26 Jun 2026
Skill level:
  Advanced
Reading time:
  1 hr
Last updated:
  26 Jun 2026
Author:Jason Andrews, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization AWS Linux Kubernetes AWS Elastic Kubernetes Service (EKS) Rafay NGINX rctl
Author:
  • Jason Andrews, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization AWS Linux Kubernetes AWS Elastic Kubernetes Service (EKS) Rafay NGINX rctl

Who is this for?

This is an advanced topic for software developers familiar with Kubernetes and AWS who want to learn how to use the Rafay platform to provision and manage EKS clusters backed by AWS Graviton-based instances.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Connect your AWS account to the Rafay platform using a cross-account IAM role
  • Provision an Amazon EKS cluster with an AWS Graviton-based node group using Rafay
  • Deploy and verify workloads on arm64 nodes and clean up all cloud resources

Prerequisites

Before starting, you will need the following:

  • An Amazon Web Services (AWS) account with sufficient IAM permissions to create roles, EKS clusters, EC2 instances, CloudFormation stacks, and related resources.
  • A Rafay account .
  • The AWS CLI installed and configured.

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll provision an Amazon EKS cluster on Arm using the Rafay Kubernetes Operations Platform and validate workloads on AWS Graviton-based nodes. First, you’ll define a declarative cluster manifest in Rafay referencing an existing project, blueprint, and cloud credential. Then, you’ll create the EKS cluster and deploy NGINX pinned to arm64 to confirm scheduling on Graviton-based instances. Finally, you’ll remove the NGINX workload and deprovision the EKS resources to avoid ongoing cloud costs.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
How do I know the AWS connection to Rafay is set up correctly before creating the cluster?
Ensure the cross-account IAM role is configured in AWS and added to Rafay as a cloud credential. In the cluster manifest, reference this credential by name. If it’s missing or has insufficient permissions, cluster creation will fail.
Which fields in the Rafay cluster manifest must match existing configuration?
The project, blueprint name and version, and the cloud credential must already exist in Rafay. If any of these don’t match, the cluster won’t be created.
What result should I expect when the EKS cluster is ready to use?
A running cluster with a Graviton-based (arm64) node group will be available for workloads. Nodes should advertise the label kubernetes.io/arch=arm64, indicating they can run arm64 pods.
How do I verify that the NGINX deployment is running on Graviton nodes?
The provided manifest pins the pods using nodeSelector: kubernetes.io/arch: arm64. After deployment, the pod should schedule and run on nodes labeled arm64. If it remains Pending, verify the node group is active and the selector matches node labels.
What should I clean up to avoid ongoing AWS charges?
Delete the NGINX workload and namespace created for the test, then deprovision the EKS cluster from Rafay. This releases the associated AWS resources.
Next