SYS.DOCS // DOCS

AWS Clusters

An AWS cluster runs K3s on EC2 instances in your own AWS account, with its own control plane nodes rather than EKS. Edka creates the VPC, the instances and their volumes through the role of a connected AWS account, and installs the AWS cloud controller manager, the EBS CSI driver, the AWS Load Balancer Controller and, for autoscaled pools, the cluster autoscaler. Everything stays in your account, and AWS bills it to you.

Prerequisites

An AWS account connected under Settings > Integrations > AWS. See AWS.
Enough EC2 quota in the region: the cluster’s vCPUs under Running On-Demand Standard instances, and one Elastic IP per control plane node, plus one for a NAT gateway with an Elastic IP.

Create a cluster

Open Clusters and click Create Cluster.
Under Provider, choose AWS.
Enter a Name, then pick the AWS account and the Region.
Under Control plane, choose the Availability:
- Single: one instance.
- High availability: three instances in the first three availability zones of the region.
Pick the instance Type, the Kubernetes version and the OS: Debian 13 (Trixie) or Ubuntu 24.04 LTS.
On the Pools tab, set each worker pool’s availability zone, EC2 instance type and size. See Node pools and autoscaling.
Review the Networking, NAT and Backups tabs, then click Create Cluster.

The summary next to the form lists the instances, root volumes, Elastic IPs and public IPv4 addresses the cluster starts with, at AWS on-demand prices excluding tax. It leaves out data transfer, persistent volumes and the load balancers of your Services.

The cluster reaches Active when the nodes are Ready and the add-ons are installed, usually within five minutes.

What Edka creates in your account

Resource	Details
VPC	The cluster’s private network range, from /16 to /20, with an internet gateway
Subnets	A public subnet in each availability zone in use, and a private subnet in each when the NAT gateway is on
Security groups	One for the nodes, one for the control plane and one for the NAT gateway. SSH and the Kubernetes API accept only the networks you allow and Edka’s own
Control plane instances	In the public subnets, each with an Elastic IP
Worker instances	In the private subnets without a public IPv4 address when the NAT gateway is on, otherwise in the public subnets with one
Root volumes	An encrypted 40 GiB gp3 volume per instance
Auto Scaling groups	One per autoscaled pool, with a launch template, for the instances above the pool’s minimum
IAM roles	An instance role for the control plane nodes, limited to the cluster’s own resources and to the permissions boundary of the stack

Every instance requires IMDSv2 with a hop limit of one, so pods cannot reach the instance metadata service. Every resource carries the tag cluster=<cluster name>.

Storage

The default storage class is ebs-gp3: encrypted gp3 EBS volumes that are created in the availability zone of the node the pod lands on, and that can be expanded. A volume stays in its zone, so a pod that uses it schedules onto a node in that zone.

Load balancers

A Service of type LoadBalancer gets a network load balancer from the AWS Load Balancer Controller, internet-facing and targeting the nodes. For an internal load balancer, annotate the Service:

metadata:
    annotations:
        service.beta.kubernetes.io/aws-load-balancer-scheme: internal

While an OS update or a reboot drains a node, Edka takes the node out of every load balancer first, so new connections go to the other nodes.

Node pools and autoscaling

Each worker pool runs one EC2 instance type in one availability zone. Its nodes are named <cluster>-pool-<pool>-worker<n>.

An autoscaled pool scales between its minimum and maximum, from zero if you like. The cluster autoscaler adds instances through the pool’s Auto Scaling group when pods cannot be scheduled. The new nodes are named <cluster>-<pool>-<instance ID>. When a node has been idle for about ten minutes, the autoscaler removes it.

To run a pod on a pool, select its label:

spec:
    nodeSelector:
        edka.io/nodepool: <pool name>

NAT gateway

With the NAT gateway on, the workers run in private subnets without public IPv4 addresses, and their outbound traffic leaves through NAT gateway instances that Edka runs in the public subnets. The default instance type is t4g.small.

Single runs one instance. High availability runs a standby that takes over the route when the active instance stops answering.
With an Elastic IP, outbound traffic leaves from one fixed address that moves with the active instance.

EC2 cannot move an instance to another subnet, so turning the NAT gateway on or off replaces the workers one at a time. Each worker is drained, terminated and recreated with the same name in the other subnet, and must be Ready before the next one moves. On a cluster with a single worker, its pods wait for the replacement.

Operations

Kubernetes upgrades, OS updates, join token rotation and CA rotation work as on Hetzner clusters. With a high availability control plane, the control plane nodes restart one at a time and the Kubernetes API keeps answering.

When a node does not come back from an OS update, Edka reboots its instance through EC2. This needs ec2:RebootInstances, which stacks created from an older template lack. See Update the stack.

Backups

Cluster backups and Roll back work on AWS clusters. A rollback restores the cluster in place, and the volumes stay attached to their instances.

Restore as new and Recover are available for Hetzner clusters only. A backup set of an AWS cluster rolls that cluster back.

Delete a cluster

Deleting an AWS cluster removes its instances, load balancers, Auto Scaling groups, Elastic IPs, VPC and key pair. The EBS volumes of its persistent volume claims stay in your account, and AWS bills them until you delete them in the EC2 console. See Delete a Cluster.

Not available on AWS

Metal node pools and pools of existing servers
Encrypted local storage
The Cilium host firewall and public IPv6
A load balancer for the Kubernetes API
Restore as new and Recover from a backup set

Troubleshooting

An operation fails with “The role Edka uses in the AWS account lacks a permission this needs”. The account’s stack is older than the feature. Update the stack, then retry.

An operation fails with a quota error. The error names the quota to raise in the Service Quotas console. See Troubleshooting.

A pod with a volume stays Pending. The volume lives in another availability zone than the nodes that have room. Add capacity in that zone, or check the events with kubectl describe pod <pod>.