It is easy to assume that once you work with containers, host security stops mattering. The truth is the opposite: every Kubernetes node is a machine that boots from an image, and a breach on the host compromises every pod it hosts. The node AMI is therefore a critical piece of your security posture.
You have three paths: use the official optimised AMIs as they come, use them as a base and customise them, or build your own. For serious production workloads, customising or building on a hardened base is the recommended route.
What a good node AMI should carry
- An optimised base for the container runtime, with containerd and the kubelet correctly configured.
- CIS hardening of the operating system and, where it applies, of the CIS Benchmark for Kubernetes itself.
- Up-to-date patching of the kernel and components, with periodic rebuilds.
- The agents you need —logs, metrics, security— preinstalled for a fast boot.
- No baked-in secrets or credentials; identity via IAM Roles for Service Accounts (IRSA) or an equivalent.
- Minimal configuration: strip out packages and services a node does not need.
Image options for EKS
| Option | Advantage | When to choose it |
|---|---|---|
| EKS optimised AMI (AL2023) | Official, maintained by AWS | General starting point |
| Bottlerocket | Minimal container-oriented OS, immutable | Maximum security and smallest surface |
| Custom AMI | Full control over hardening and agents | Strict compliance requirements |
Pick your node base according to your balance between control and convenience.
Bottlerocket: containers first
Bottlerocket is a minimalist operating system from AWS designed exclusively to run containers. Its attack surface is tiny, it is immutable and it updates by image —not by hot patching— which fits the immutable infrastructure philosophy beautifully. If your priority is node security with the least maintenance effort, it deserves a serious evaluation.
Upgrading nodes without pain
A hardened node AMI is only useful if you keep the nodes current. The immutable pattern shines here:
- Replace, do not patch: publish a new AMI version and rotate the nodes.
- Rolling update of the node group: drain with cordon and drain and replace node by node.
- Managed Node Groups or Karpenter to automate the replacement with new AMIs.
- PodDisruptionBudgets so that rotation does not affect the availability of your services.
Common mistakes
- Running the default optimised AMI for months without updating it.
- Baking cluster credentials into the image instead of using federated identity.
- Forgetting to harden the kubelet itself and the filesystem permissions.
- Not restricting SSH access to nodes: ideally, zero SSH and access only via SSM.
Frequently asked questions
Do I need a custom AMI or is the EKS optimised one enough?
To get started, the official optimised AMI is a good point of departure. If you have strict compliance or security requirements, customise it or build your own with your own hardening and agents.
Does Bottlerocket replace a normal Linux AMI?
For nodes that only run containers, yes: it offers a smaller attack surface and immutable updates. It is not suitable for workloads that need a general-purpose OS.
How do I upgrade nodes when I publish a new AMI?
With a rolling update of the node group: nodes are drained and replaced progressively, respecting PodDisruptionBudgets so the service is not affected.
At imaxe.cloud we design hardened base images that make an ideal foundation for your Kubernetes nodes.
