{"id":80715,"date":"2026-07-29T13:04:57","date_gmt":"2026-07-29T07:34:57","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=80715"},"modified":"2026-07-30T15:54:58","modified_gmt":"2026-07-30T10:24:58","slug":"guide-to-fixing-cves-in-amazon-eks-worker-nodes-by-updating-node-group-amis","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/guide-to-fixing-cves-in-amazon-eks-worker-nodes-by-updating-node-group-amis\/","title":{"rendered":"Guide to Fixing CVEs in Amazon EKS Worker Nodes by Updating Node Group AMIs"},"content":{"rendered":"

A Practical Guide to Fixing CVEs in Amazon EKS Worker Nodes by Updating Node Group AMIs<\/strong><\/h1>\n

Learn how to identify security vulnerabilities (CVEs) in your EKS worker nodes, update them safely without affecting running applications, and automate the process so your clusters stay secure over time.<\/p>\n

Executive Summary<\/strong><\/h2>\n

When you create an Amazon EKS cluster, the worker nodes run on Amazon Machine Images (AMIs). These AMIs contain the operating system, Linux kernel, container runtime, and other software required for Kubernetes to function.<\/p>\n

Like any operating system, these components receive security updates over time. As new vulnerabilities (CVEs) are discovered, AWS builds and publishes updated EKS-optimized AMIs that include the necessary security fixes.<\/p>\n

One thing that often catches teams by surprise is that AWS doesn’t automatically replace your existing worker nodes when a new AMI is released. If your node group was created several months ago and hasn’t been updated since, it’s probably still running the same AMI it started with.<\/p>\n

Your applications may continue running without any issues, but the operating system underneath them could contain vulnerabilities that have already been fixed in newer AMIs. Most teams don’t notice this until they run a security scan or prepare for a compliance audit.<\/p>\n

The good news is that updating worker nodes is a routine maintenance task. The overall process is simple:<\/p>\n

    \n
  • Check whether your node groups are using an outdated AMI.<\/li>\n
  • Update the managed node group to use the latest EKS-optimized AMI.<\/li>\n
  • Allow EKS to replace the old worker nodes one at a time.<\/li>\n
  • Verify that all workloads are running normally after the update.<\/li>\n<\/ul>\n

    In this guide, we will walk through each step and explain how to perform the update safely with little or no impact on your applications.<\/p>\n

    Understanding the Problem<\/h2>\n

    A common misconception is that Amazon EKS automatically keeps every part of your Kubernetes cluster up to date. That’s only partly true.
    \nAWS manages the Kubernetes control plane for you, which includes components such as:<\/p>\n

      \n
    • Kubernetes API Server<\/li>\n
    • etcd<\/li>\n
    • Scheduler<\/li>\n
    • Control Plane availability and upgrades<\/li>\n<\/ul>\n

      However, the worker nodes are your responsibility. That means you’re responsible for:<\/p>\n

        \n
      • Updating the operating system<\/li>\n
      • Installing security patches<\/li>\n
      • Keeping the Linux kernel up to date<\/li>\n
      • Fixing vulnerabilities found on the EC2 instances running your workloads<\/li>\n<\/ul>\n

        You can think it like this:
        \nEKS Cluster<\/span>
        \n—————-<\/span>
        \nControl Plane<\/span>
        \nManaged by AWS : Automatically patched<\/span>
        \n—————-<\/span>
        \nWorker Nodes<\/span>
        \nManaged by You : Need manual updates<\/span>
        \n—————-<\/span><\/p>\n

        If you will not update your worker nodes, they will continue running an old operating system with known vulnerabilities.<\/p>\n

        What Is a CVE?<\/strong><\/h2>\n

        CVE<\/strong> stands for Common Vulnerabilities and Exposures.
        \n<\/strong>A CVE is simply a publicly documented security flaw.
        \nExample:<\/p>\n

          \n
        • Linux kernel vulnerability<\/li>\n
        • OpenSSL vulnerability<\/li>\n
        • glibc vulnerability<\/li>\n
        • containerd vulnerability<\/li>\n
        • systemd vulnerability<\/li>\n<\/ul>\n

          Assume AWS released an AMI in January.
          \nJanuary : AMI Version 1.0<\/span>
          \nyour workloads are secured.<\/p>\n

          Then in March, researchers discover:
          \nEx: CVE-2026-12345(Linux Kernel Privilege Escalation)<\/span><\/p>\n

          AWS fixes it and releases new AMI:
          \nApril : AMI Version 1.1<\/span><\/p>\n

          But your cluster is still running on AMI Version 1.0<\/p>\n

          Your applications will work perfectly but the operating system underneath is vulnerable and this known as security drift<\/strong>.<\/p>\n

          How to Detect Vulnerable Worker Nodes<\/strong><\/h2>\n

          Before fixing it, you need to first know whether your nodes are outdated or not.
          \nThere are several ways to check that<\/p>\n

          Method 1: Amazon Inspector (Recommended)<\/strong><\/h3>\n

          Amazon Inspector continuously scans EC2 instances for known vulnerabilities.
          \nIt can detect issues like:<\/p>\n

            \n
          • Kernel vulnerabilities<\/li>\n
          • OpenSSL CVEs<\/li>\n
          • Package vulnerabilities<\/li>\n
          • High severity issues<\/li>\n
          • Critical vulnerabilities<\/li>\n<\/ul>\n

            Example findings:
            \nCritical : CVE-2026-12345<\/p>\n

            Affected Package: kernel
            \nAffected Instance: i-xxxxxxxxxx<\/p>\n

            This tells you which worker node is vulnerable.<\/p>\n

            Method 2: Trivy<\/strong><\/h2>\n

            If you are using Trivy(Open Source tool) then it can scan both:<\/p>\n

              \n
            • EC2 AMIs<\/li>\n
            • Container Images<\/li>\n<\/ul>\n

              Example:
              \ntrivy image nginx:latest<\/span><\/p>\n

              Or<\/p>\n

              trivy fs \/<\/span>
              \nThis identifies vulnerable operating system packages.<\/p>\n

              Method 3: AWS EKS AMI Release Notes<\/h2>\n

              AWS publishes release notes every time a new EKS AMI is released.
              \nExample release:
              \nAmazon EKS Optimized AMI : 1.29-20260701
              \nIncludes fixes for:
              \nCVE-2026-1111
              \nCVE-2026-2222
              \nCVE-2026-3333
              \nIf your node groups are using older AMI image then those vulnerabilities are still present.<\/p>\n

              Check Which AMI Your Worker Nodes Are Using<\/strong><\/h2>\n

              Run:<\/strong> aws eks describe-nodegroup –cluster-name my-cluster-name –nodegroup-name my-nodegroup-name\u00a0–query “nodegroup.releaseVersion”<\/span>
              \nExample output you will receive : 1.29.2-20260xx<\/strong><\/p>\n

              This will tell you the current AMI release your node group is running with.<\/p>\n

              Check the Latest Recommended AMI<\/h2>\n

              AWS stores the latest recommended EKS AMI in the Systems Manager Parameter Store.
              \nRun:<\/strong> aws ssm get-parameter –name\/aws\/service\/eks\/optimized-ami\/1.29\/amazon-linux-2\/recommended\/image_id –query “Parameter.Value” –output text<\/span><\/p>\n

              You will get something like: ami-0abc12345
              \nIf your node group’s release version is older than the latest recommended release, it is time to update it.<\/p>\n

              How EKS Updates Worker Nodes<\/h2>\n

              When you are updating a Managed Node Group, EKS does not shut down all nodes at once.
              \nInstead it replaces them gradually.
              \nFor example:
              \nOld Nodes<\/strong><\/p>\n

              Node 1
              \nNode 2
              \nNode 3
              \nNode 4<\/p>\n

              EKS launches a new node first:
              \nNode 1
              \nNode 2
              \nNode 3
              \nNode 4<\/p>\n

              New Node
              \n<\/strong>Once the new node becomes healthy:<\/p>\n

                \n
              • Pods move to the new node.<\/li>\n
              • One old node is drained.<\/li>\n
              • The old node is terminated.<\/li>\n<\/ul>\n

                This process repeats until all nodes get replaced.
                \nApplications remain available during the update if they have deployed with enough replicas and sensible disruption budgets.<\/p>\n

                Rolling Update vs Force Update<\/h2>\n

                Rolling Update (Recommended)
                \n<\/strong>Rolling updates replace one node at a time.
                \nThe process contains:<\/p>\n

                  \n
                1. Launch a new node.<\/li>\n
                2. Wait until it’s healthy.<\/li>\n
                3. Drain an old node.<\/li>\n
                4. Move pods.<\/li>\n
                5. Delete the old node.<\/li>\n
                6. Repeat.<\/li>\n<\/ol>\n

                  This is the safest approach for production.<\/p>\n

                  Force Update
                  \n<\/strong>Sometimes updates become stuck because Kubernetes is not allowed to evict pods.<\/p>\n

                  In such cases, EKS offers a force update.<\/p>\n

                  A force update ignores Pod Disruption Budgets (PDBs) and may interrupt workloads, so it should only be used when there are security risks of delaying the update is greater than the risk of downtime.<\/p>\n

                  Step 1: Check Current AMI Version<\/strong>
                  \naws eks describe-nodegroup –cluster-name my-cluster –nodegroup-name my-nodegroup\u00a0–query “nodegroup.{current:releaseVersion,amiType:amiType}”<\/span>
                  \nExample:
                  \n<\/strong>Current Release: 1.29.2-20260xx<\/p>\n

                  Step 2: Check Pod Disruption Budgets<\/strong>
                  \nBefore updating you need to ensure Kubernetes is allowed to move pods.<\/p>\n

                  Run:<\/strong> kubectl get pdb –all-namespaces<\/span><\/p>\n

                  Example:
                  \nNAME frontend-pdb<\/span>
                  \nMIN AVAILABLE 2<\/span>
                  \nIf you have only one pod but your PDB requires it to stay available, Kubernetes cannot evict it, and the update will stop.<\/p>\n

                  Step 3: Update the Node Group<\/strong>
                  \nIf Terraform manages your infrastructure, update the launch template or AMI reference and apply the changes:
                  \nresource “aws_eks_node_group” “main” {<\/span>
                  \n\u00a0\u00a0cluster_name = aws_eks_cluster.this.name<\/span>
                  \n\u00a0\u00a0node_group_name = “primary”<\/span>
                  \n\u00a0\u00a0launch_template {<\/span>
                  \n\u00a0\u00a0\u00a0\u00a0id = aws_launch_template.node.id<\/span>
                  \n\u00a0\u00a0\u00a0\u00a0version = aws_launch_template.node.latest_version<\/span>
                  \n\u00a0\u00a0}<\/span>
                  \n\u00a0\u00a0update_config {<\/span>
                  \n\u00a0\u00a0\u00a0\u00a0max_unavailable_percentage = 25<\/span>
                  \n\u00a0\u00a0}<\/span>
                  \n}<\/span><\/p>\n

                  Apply the update: terraform apply -target=aws_eks_node_group.main<\/span><\/p>\n

                  If you need an urgent update without using Terraform files then you can use the AWS CLI CMD:
                  \naws eks update-nodegroup-version –cluster-name my-cluster\u00a0–nodegroup-name my-nodegroup
                  \n<\/span><\/p>\n

                  EKS then begins replacing nodes with instances launched from the newer AMI.<\/p>\n

                  Step 4: Monitor the Update<\/strong><\/p>\n

                  Check the update status with below CMD:
                  \naws eks describe-update –name my-cluster –nodegroup-name my-nodegroup\u00a0–update-id <update-id><\/span><\/p>\n

                  Watch nodes joining and leaving the cluster: kubectl get nodes -o wide –watch
                  \n<\/span>You will see new nodes coming up with the updated AMI while older nodes are cordoned, drained, and removed.<\/p>\n

                  Step 5: Verify Everything Is Healthy<\/strong><\/p>\n

                  Once the update completes you have to confirm that there are no workloads stuck because of scheduling or capacity issues.
                  \nkubectl get pods –all-namespaces –field-selector=status.phase!=Running<\/span><\/p>\n

                  If nothing is returned, it is a good sign that all pods are running normally.
                  \nYou can also check Node status, All nodes should report a Ready status.<\/p>\n

                  What If Something Goes Wrong?<\/h2>\n

                  Sometimes, a newly released AMI can cause an unexpected issue, such as a driver problem or incompatibility with your workloads.
                  \nIf that happens, you can roll back by pointing your node group back to the previous launch template version.
                  \nView available launch template versions with Below CMD:
                  \naws ec2 describe-launch-template-versions\u00a0–launch-template-id lt-0123456789abcdef0<\/span><\/p>\n

                  Then update Terraform to use the earlier version:
                  \nlaunch_template {<\/span>
                  \n\u00a0\u00a0id = aws_launch_template.node.id<\/span>
                  \n\u00a0\u00a0version = “5”<\/span>
                  \n}<\/span><\/p>\n

                  Then apply the changes with: terraform apply
                  \n<\/span>EKS will replace the newer nodes with ones created from the old AMI.<\/p>\n

                  Automating the Entire Process<\/strong><\/h2>\n

                  Manually checking AMIs across multiple clusters quickly is difficult.
                  \nA simple automation can handle most of this work.<\/p>\n

                  \"Automation\"

                  Automation<\/p><\/div>\n

                  This ensures your clusters are checked regularly instead of relying on someone to remember.<\/p>\n

                  Best Practices<\/strong><\/h2>\n
                    \n
                  • Update worker nodes regularly not just after an audit.<\/li>\n
                  • Test new AMIs in development or staging before rolling them out in production.<\/li>\n
                  • Keep launch template versions explicit so you can easily roll back if required.<\/li>\n
                  • Review Pod Disruption Budgets before maintenance windows to avoid stalled updates.<\/li>\n
                  • Automate weekly checks for new EKS AMI releases and notify your team when updates are available.<\/li>\n
                  • Remember that updating the control plane does not update worker nodes & both need their own maintenance lifecycle.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

                    A Practical Guide to Fixing CVEs in Amazon EKS Worker Nodes by Updating Node Group AMIs Learn how to identify security vulnerabilities (CVEs) in your EKS worker nodes, update them safely without affecting running applications, and automate the process so your clusters stay secure over time. Executive Summary When you create an Amazon EKS cluster, […]<\/p>\n","protected":false},"author":2167,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0},"categories":[5877],"tags":[1891,5303,8728,3965,8727],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80715"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2167"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=80715"}],"version-history":[{"count":2,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80715\/revisions"}],"predecessor-version":[{"id":80966,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/80715\/revisions\/80966"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=80715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=80715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=80715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}