Amazon EKS

Amazon EKS is AWS’s managed Kubernetes service. AWS runs the control plane; Ankra provisions the cluster, then manages everything on top - node groups, Kubernetes upgrades, addons, stacks, GitOps, and AI-assisted operations. This page covers EKS specifically. For the shared concepts across all managed providers - live options, discovery/import, and day-2 API patterns - see Managed Kubernetes.

Already running EKS? You can bring it into Ankra two ways. A managed import uses your AWS credential: in Clusters, click Create cluster and choose Import existing, or run ankra cluster managed discover --provider eks and ankra cluster managed import --provider eks. Ankra fetches the kubeconfig and installs the agent, so there is nothing to run on the cluster, and the cluster gains the same node-pool and upgrade operations as clusters Ankra created. The Helm import needs no cloud credential and works for any cluster: run the one helm command the Import dialog gives you - see Import an existing cluster.

Why EKS with Ankra

Automatic IAM setup - Ankra creates the required IAM roles for the cluster and node groups, so you do not have to wire them by hand.
Bring your own network, or don’t - specify subnet_ids and security_group_ids, or let Ankra use your default VPC subnets.
Live pricing and options - regions, Kubernetes versions, and EC2 instance types are fetched live with your AWS credential, including spot and autoscaling where available.

Prerequisites

An AWS credential stored in Ankra (access keys or an IAM role) with permissions for EKS, EC2, and IAM role management. The IAM-role wizard’s Provisioning (EKS clusters) access level creates a correctly scoped role for you. See AWS Credentials. GitOps is optional: connect a repository at creation and Ankra commits the cluster’s stack definitions to Git.

Creating an EKS cluster

Portal
CLI
API

Create Cluster

Go to Clusters → Create Cluster and pick AWS’s Cloud Managed action.

Credential & Region

Select the AWS credential and a region (for example eu-west-1). Regions load live from AWS.

Node Groups

Define one or more worker groups: name, instance type (with live pricing), count, labels, and autoscaling bounds.

Kubernetes & Networking

Pick a Kubernetes version or keep the default, optionally set subnets and security groups, and enable control-plane logging if you want it.

GitOps (optional) & Create

Optionally connect a Git repository, then create. Ankra runs EKS preflight checks, creates the IAM roles, provisions the cluster, retrieves the kubeconfig, and installs the Ankra Agent.

ankra cluster managed create \
  --provider eks \
  --name my-eks-cluster \
  --credential-id <aws-credential-id> \
  --location eu-west-1 \
  --node-pool-name workers \
  --node-pool-size m5.large \
  --node-pool-count 2

Subnets, security groups and control-plane logging are set from the portal or the API. Node-group autoscaling bounds take --autoscaling --autoscaling-min <n> --autoscaling-max <n> (CLI v0.9.0 or later).

curl -X POST https://platform.ankra.app/org/clusters/managed/eks \
  -H "Authorization: Bearer $ANKRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-eks-cluster",
    "credential_id": "<aws-credential-id>",
    "location": "eu-west-1",
    "kubernetes_version": "1.32",
    "node_pools": [
      {
        "name": "workers",
        "size": "m5.large",
        "count": 2,
        "autoscaling": {"enabled": true, "min_count": 2, "max_count": 5}
      }
    ],
    "eks": {"enable_control_plane_logging": true}
  }'

EKS options

Field	Description
`eks.subnet_ids`	Subnets to place the cluster in (defaults to your default VPC subnets)
`eks.security_group_ids`	Security groups to attach
`eks.enable_control_plane_logging`	Enable EKS control-plane logging

EKS creates the IAM roles for the cluster and node groups automatically and uses your default VPC subnets when subnet_ids is omitted. Control planes routinely take 10-15 minutes to provision; node groups follow after.

Verify

The create progress view follows the control plane, the node pools, kubeconfig retrieval and the Ankra Agent install. The cluster shows Online once the agent has connected. Then point kubectl at it through Ankra - this needs a Cluster Access grant - and check that every node is Ready:

ankra cluster kubeconfig add <cluster-name> --use
kubectl get nodes

See Accessing Clusters with kubectl.

Day-2 operations

Node groups, upgrades, and deletion work from the CLI, portal, or API. The CLI examples use --provider eks:

# scale a pool to a fixed count
ankra cluster managed node-pool scale <cluster_id> workers --provider eks --count 5

# upgrade the cluster
ankra cluster managed upgrade <cluster_id> --provider eks --version 1.32

# delete the cluster
ankra cluster managed delete <cluster_id> --provider eks

Autoscaling bounds are set from the portal, with ankra cluster managed node-pool update --autoscaling --autoscaling-min <n> --autoscaling-max <n>, or with the PATCH .../node-pools/{name} endpoint. See Managed Kubernetes - day-2 operations for the shared mechanics.

Importing an existing EKS cluster

Already running EKS? Discover clusters in your AWS account and adopt them into Ankra without touching them. Discovery and import run from the portal, the CLI (ankra cluster managed discover|import --provider eks) or the API - see Managed Kubernetes - importing existing clusters.

Get Started

Concepts

Create and Run Clusters

Ship Your App

Stacks and Add-ons

Observe and Troubleshoot

Ankra AI

Connect Tools

Source Control

Security and Access

Cost and Backups

Organisation and Account

Reference

Why EKS with Ankra

Prerequisites

Creating an EKS cluster

EKS options

Verify

Day-2 operations

Importing an existing EKS cluster

​Why EKS with Ankra

​Prerequisites

​Creating an EKS cluster

​EKS options

​Verify

​Day-2 operations

​Importing an existing EKS cluster

​Related

Why EKS with Ankra

Prerequisites

Creating an EKS cluster

EKS options

Verify

Day-2 operations

Importing an existing EKS cluster

Related