Treat core components as API-managed add-ons, and always update them with PRESERVE.

AWS tests each add-on version against each supported Kubernetes version and reports health, so updates are a compatibility check, not guesswork.

Amazon VPC CNIPod networking

CoreDNScluster DNS

kube-proxyService rules

EBS CSI driverblock volumes

EFS CSI drivershared files

Pod Identity Agentworkload credentials

CloudWatch Observabilitymetrics and logs

GuardDuty agentruntime detection

Conflict resolution on update

PRESERVE

Keeps the field values you customised; only untouched fields change.

OVERWRITE

AWS defaults win. Your custom settings, such as prefix delegation, are silently reverted.

A third value, NONE, leaves existing configuration alone and fails if there is a conflict.

install, configure, update

$ aws eks describe-addon-versions --kubernetes-version 1.31 \
    --addon-name vpc-cni --query 'addons[].addonVersions[].addonVersion'
$ aws eks update-addon --cluster-name shop-eu --addon-name vpc-cni \
    --addon-version v1.19.0-eksbuild.1 --resolve-conflicts PRESERVE \
    --configuration-values '{"env":{"ENABLE_PREFIX_DELEGATION":"true"}}'
$ aws eks describe-addon --cluster-name shop-eu --addon-name vpc-cni \
    --query addon.health

Managed add-ons: versioned, health-checked, and safe to update

EKS managed add-ons turn the installation and lifecycle of core components into API operations. You can list available add-ons and versions for your Kubernetes version, install one, update it, configure it through configuration values, and query its health. AWS tests each add-on version against each supported cluster version before publishing it, so an update is a version-compatibility question rather than a manual research task.

The detail that causes incidents is conflict resolution. If you have customised an add-on, for example turning on prefix delegation for the VPC CNI, updating with OVERWRITE resets those fields to AWS defaults and can break Pod networking cluster-wide immediately after a routine update. PRESERVE keeps your values. The robust habit is to put customisation in the add-on's configuration values (managed through Terraform), always update with PRESERVE, and diff the applied configuration before and after.

Some teams deliberately run a different CNI such as Cilium or Calico for advanced policy or eBPF features, and therefore do not use the managed VPC CNI add-on. That is a legitimate choice (Deck 7), but you then own installation and upgrades for that component.

Reveal the two resolution cards with the right arrow. On upgrade day, add-ons are step three of the sequence: after the control plane and before the nodes, which Module 6 covers.