Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Rotate the EKS cluster certificate authority (CA)

In public key infrastructure (PKI), a certificate authority (CA) is a trusted entity that issues and signs digital certificates. These certificates establish identity and enable encrypted communication between systems using TLS (Transport Layer Security). When a client connects to a server, the server presents a certificate signed by a CA. The client verifies the server’s certificate against the CAs it trusts before allowing the connection to proceed.

In Amazon Elastic Kubernetes Service (Amazon EKS), a CA is created for each EKS cluster at the time of cluster creation. This follows the same model as upstream Kubernetes: each EKS cluster has its own CA that signs certificates for the API server. This is what enables control plane components, worker nodes, and clients to authenticate to the API server and establish encrypted connections to the EKS cluster.

These certificate authorities (CAs) have a defined validity period. CA rotation is the process of replacing your EKS cluster’s certificate authority before it expires, ensuring your cluster remains operational and accessible. We have built-in safeguards that automatically manage this process. If you do not initiate CA rotation yourself, we will automatically append a successor CA and activate it before the outgoing CA expires, ensuring your cluster remains available.

During CA rotation, a successor CA is appended to your EKS cluster. EKS distributes the successor CA to all AWS managed components (control plane, EKS Auto Mode instances, and AWS Fargate nodes) automatically. You are responsible for updating the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients (such as kubeconfig files and CI/CD pipelines) to trust the successor CA before it is activated. After the successor CA is activated, the EKS cluster transitions to signing certificates with the successor CA. The outgoing CA is then retired.

CA rotation is required for every EKS cluster because CAs have a finite validity period. The validity period depends on when the cluster’s CA was created. For more detail, see the frequently asked questions section. EKS safeguards ensure your cluster itself remains available throughout the rotation lifecycle, but a successful rotation also depends on you updating the worker nodes that you manage and external clients so they maintain connectivity after the successor CA is activated.

The APIs, console experience, notifications, and step-by-step guidance in the sections that follow are designed to support you through this process. The full scope of responsibilities is covered in the shared responsibility model section.

How CA rotation works

CA rotation in Amazon EKS is a multi-stage process. We have automatic safeguards in place to preserve EKS cluster availability throughout the entire rotation lifecycle regardless of whether you act or not. A successful rotation, where all your components maintain connectivity, requires the steps described in the following sections.

Stage 1: Append a successor CA

A successor CA is appended to the EKS cluster. From this point, the EKS cluster trusts both the outgoing CA and the successor CA simultaneously. Certificates continue to be issued by the outgoing CA. No disruption occurs.

You can append a successor CA yourself at any time using the AWS CLI, EKS API, Console, or infrastructure as code (IaC) such as AWS CloudFormation, as long as your cluster is in an active state. If you do not, we will automatically append one on your behalf.

The successor CA cannot be activated until AWS completes distribution to AWS managed components in EKS (Stage 2). This is the right time to start identifying the worker nodes and external clients that need to be updated. Identifying all systems that connect to your EKS cluster’s API server can take time, particularly in environments with multiple teams, CI/CD pipelines, and monitoring tools. Starting this process early gives you the most flexibility to coordinate updates on your own timeline.

Stage 2: Distribute the successor CA

After the successor CA is appended, AWS updates managed components in your EKS cluster (the control plane, EKS Auto Mode instances, and AWS Fargate nodes) to recognize and trust both CAs. You can track the progress of this through the CA’s distribution status. The successor CA cannot be activated until distribution is complete.

After we have completed CA distribution to managed components, you are responsible for updating two groups: the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients to trust the successor CA. This ensures they will continue to connect to the API server after the successor CA is activated. If any components are not updated before activation of the successor CA, CA rollback is available to restore connectivity while you complete the remaining updates.

Stage 3: Activate the successor CA

After we have completed distribution of the successor CA to all AWS managed components in EKS, the successor CA can be activated. We recommend activating the successor CA on your own timeline. Give yourself enough time to discover and update the worker nodes you manage and external clients to trust the successor CA. After activation of the successor CA, the EKS cluster issues certificates signed by the successor CA. The outgoing CA remains trusted but is no longer used for signing. A rollback window is available for a limited period after activation, allowing you to revert to the outgoing CA if needed. Rollback is covered in detail in a later section.

You can activate the successor CA yourself when you are confident the worker nodes that you manage and clients have been updated. If you do not, we will activate the successor CA automatically as the expiration deadline approaches.

The dual trust period

The time between appending a successor CA (Stage 1) and retiring the outgoing CA is called the dual trust period. During this time, the EKS cluster trusts both CAs simultaneously. This is what makes the rotation non-disruptive: components can be updated incrementally because the EKS cluster accepts certificates signed by either CA.

The dual trust period gives you time to identify and update all the worker nodes that you manage and external clients without needing to coordinate all changes simultaneously.

It is important to understand how activation of the successor CA affects connectivity. When a client connects to the API server, it verifies the server’s identity by checking that the server’s certificate was signed by a CA it trusts.

After the successor CA is activated, the API server presents its certificate signed by the successor CA. Clients that have updated their trust bundle to include the successor CA will verify successfully and connect as normal. Clients that have not updated their trust bundle will not recognize the server’s certificate and will not be able to establish a connection.

The following diagram shows the TLS connection flow after successor CA activation.

This is why updating worker nodes and external clients before activation of the successor CA is important: they need the successor CA in their trust bundle to verify the API server’s identity and connect. The dual trust period and CA rollback provide you time and a safety net to complete this.

Shared responsibility model

CA rotation in Amazon EKS follows the same shared responsibility model that applies broadly across AWS. AWS is responsible for the security and availability of the cloud infrastructure, and you are responsible for the security and configuration of your workloads within it. For more information about how shared responsibility applies to Amazon EKS, see the EKS security best practices.

In the context of CA rotation, this means:

AWS is responsible for

You are responsible for

We cannot perform these actions on your behalf. External clients exist outside the AWS operational boundary. Worker nodes that are not managed by EKS Auto Mode or Fargate have their CA trust configuration set at launch time or through bootstrap processes that only you control. This is consistent with how TLS trust works: the client holds its own trust store, and only the client’s administrator can update it.

The sections that follow expand on each side: what AWS does for you, and what you need to do along with step-by-step guidance on how to do it.

What AWS does for you

AWS manages the following throughout the CA rotation lifecycle for your EKS cluster:

Automatic CA creation

If you do not append a successor CA on your own timeline, we will automatically append one as your EKS cluster’s outgoing CA approaches expiration. This ensures the rotation process begins with enough time for you to discover and update your clients before the expiration deadline.

Control plane updates

We automatically update the EKS cluster control plane to trust the successor CA. After activation of the successor CA, the control plane issues certificates signed by the successor CA. No action is required from you for the control plane.

EKS Auto Mode and Fargate updates

We automatically update EKS Auto Mode nodes and Fargate pods to trust the successor CA. These components are fully managed by us and require no action from you during CA rotation.

EKS Capabilities updates

We automatically update EKS Capabilities (AWS Controllers for Kubernetes (ACK), Argo CD, and kro (Kube Resource Orchestrator)) to trust the successor CA. These managed resources communicate with your cluster’s API server and are updated as part of the CA distribution process. No action is required from you for the managed resources in EKS Capabilities. For more information, see EKS Capabilities.

Distribution status tracking

As we update managed components in your EKS cluster, you can monitor progress through the CA’s distribution status. This tells you whether we have completed our side of the rotation. The successor CA cannot be activated until distribution is complete.

Built-in safeguards

We have built-in safeguards to protect your EKS cluster during rotation:

These safeguards ensure that EKS cluster availability is preserved throughout the rotation lifecycle regardless of whether you act or not.

Notifications

We notify you at each stage of the CA rotation lifecycle. Notifications are delivered through AWS Health, Cluster Insights, and email. Each notification tells you what happened, what action (if any) is required from you, and where your EKS cluster is in the rotation timeline.

You can also configure your own notifications using Amazon EventBridge to integrate CA rotation events into your existing monitoring and alerting workflows.

What you need to do (and why)

A successful CA rotation requires you to update the components that AWS cannot reach on your behalf. These fall into two categories:

External clients

Any system that connects to your EKS cluster’s API server from outside the cluster. This includes developer workstations, CI/CD pipelines (Jenkins, GitHub Actions, GitLab, ArgoCD), monitoring and observability tools, automation scripts, and any application that uses a kubeconfig to communicate with the API server.

These systems each maintain their own trust configuration. When the successor CA is activated, the API server presents certificates signed by the successor CA. Updating these clients to trust the successor CA before activation of the successor CA ensures they maintain connectivity. If a client is missed, CA rollback can restore access while you complete the update.

Worker nodes (non-EKS Auto Mode, non-Fargate)

Worker nodes that are not managed by EKS Auto Mode or Fargate have their CA trust configuration set at launch time or through the kubelet bootstrap process. These nodes need to be refreshed so they trust the successor CA. The action required depends on the type of worker node:

Managed node groups

Perform a node group version update, which triggers a rolling replacement of nodes. New nodes bootstrap with the updated CA trust configuration automatically.

Karpenter-controlled nodes

If drift detection is enabled, Karpenter will cycle nodes within its configured drift window and new nodes will pick up the successor CA without manual action. If drift detection is disabled or set to a long window, treat these nodes the same as self-managed nodes.

Self-managed nodes

Replace nodes so they bootstrap with the updated CA trust configuration. This typically involves updating the launch template with the updated CA data and triggering a rolling replacement through your Auto Scaling group.

Hybrid nodes

Update the trust configuration on each hybrid node to include the successor CA. The specific process depends on how your hybrid nodes were bootstrapped and how their trust configuration is managed.

You can identify which types of worker nodes are running in your EKS cluster using Cluster Insights. Detailed step-by-step guidance for updating each type is provided in a later section.

We provide CA rollback as a safety net if any worker nodes are missed. However, updating all worker nodes before activation of the successor CA avoids connectivity interruptions entirely. Nodes not updated before the successor CA is activated will lose connectivity to the EKS cluster’s API server until they are replaced or CA rollback is performed.

Why only you can do this

External clients exist outside the AWS operational boundary. A CI/CD pipeline running in your corporate network, a developer’s laptop, a monitoring tool hosted on premises: AWS has no mechanism to reach into these systems and update their trust configuration.

Non-EKS Auto Mode worker nodes have their trust configuration controlled through launch templates, user data scripts, or bootstrap processes that you own. Updating them requires either replacing the nodes or modifying their configuration, both of which are actions within your infrastructure.

This is a constraint of the TLS trust model used by Kubernetes today. There is no protocol-level mechanism for the API server to query whether a client has updated its trust bundle. The server can only present its certificate when a client connects. If the client trusts the CA that signed it, the connection succeeds. If not, it fails. There is no pre-activation verification path that would allow AWS to confirm readiness of your components on your behalf.

When to start

Start identifying your external clients as early as possible. This is the most time-consuming part of CA rotation, particularly in environments with multiple teams that independently deploy workloads to the EKS cluster. The earlier you begin client discovery, the more time you have to coordinate updates across teams without pressure.

Detailed guidance on how to update each type of client and worker node is provided in the sections that follow.

Prerequisites

Before starting CA rotation, confirm the following:

No additional IAM permissions are required beyond those needed to manage your EKS cluster. If you can call EKS APIs for your EKS cluster today, you can perform CA rotation.

Getting started

You can perform CA rotation using the AWS CLI or the Amazon EKS console. Ensure you are running AWS CLI version 2.x or later (aws --version to check).

Using the AWS CLI

The following walkthrough covers the end-to-end CA rotation process using the AWS CLI and EKS APIs.

Step 1: Check your active CA

View the active certificate authority on your EKS cluster.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Expected output:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

This shows the CA that was created when your EKS cluster was created. It is currently in use (signing certificates) and distribution is complete (all AWS managed components in EKS trust it).

Step 2: View CA details and expiration

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Expected output:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

The validity block shows when the CA was created (notBefore) and when it expires (notAfter). rollbackAvailable indicates whether you can revert to a previous CA after activation of the successor CA. For the initial CA created with your EKS cluster, this will be false because there is no previous CA to revert to.

Step 3: Append a successor CA

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

This appends a successor CA to your EKS cluster. The response includes an updateId you can use to track progress.

Step 4: Track the update

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Wait until the update status is Successful.

Step 5: Verify distribution status

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

You should now see two CAs. The successor CA will have signingStatus: NOT_USED and distributionStatus will progress from IN_PROGRESS to COMPLETE after AWS has updated all managed components in your EKS cluster.

Do not proceed until the successor CA’s distribution status is COMPLETE.

Step 6: Update your kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

This updates your local kubeconfig to trust both CAs. After this, your kubectl commands will continue to work after the successor CA is activated.

Step 7: Update the worker nodes that you manage and external clients

This is covered in detail in the next section. After all the worker nodes that you manage and external clients have been updated to trust the successor CA, proceed to activation.

Step 8: Activate the successor CA

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

After activation of the successor CA, your EKS cluster issues certificates signed by the successor CA. Verify connectivity to confirm all components are working as expected.

Using the Amazon EKS console

The Amazon EKS console provides a guided experience for CA rotation. You can view your CA status, append a successor CA, monitor distribution progress, and activate the successor CA directly from the console.

The following image shows the certificate authority details view in the Amazon EKS console during an active rotation. The active CA and successor CA are both displayed with their signing status, expiration date, and days until expiration.

The following image shows the rotation progress view in the Amazon EKS console. Each step of the rotation process is displayed with its current state, including append, distribution, updating worker nodes and external clients, activation, and deletion of the outgoing CA.

Updating your Kubernetes clients

After the successor CA has been appended and AWS has completed distribution to managed components in your EKS cluster (distributionStatus: COMPLETE), you need to update your own components to trust the successor CA. A "client" in this context is any system that connects to your EKS cluster’s API server. This includes your local kubectl configuration, CI/CD pipelines, monitoring tools, automation scripts, and your worker nodes.

The updated CA data for your EKS cluster (which now contains both the current and successor CAs) can be retrieved using:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Use this value to update the trust configuration of each client type in the following subsections.

Kubeconfig (developer workstations, CI/CD pipelines, automation)

Run the following to update your local kubeconfig:

aws eks update-kubeconfig --name my-cluster --region us-west-2

This automatically retrieves the latest CA data and updates your kubeconfig. Any system that uses this kubeconfig will trust both CAs.

For CI/CD pipelines and automation that generate their own kubeconfig (for example, using the EKS APIs directly or storing kubeconfig as a secret), update the certificate-authority-data field with the value retrieved from describe-cluster.

Managed node groups

Perform a node group version update to trigger a rolling replacement of nodes:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

New nodes bootstrap with the updated CA data automatically. The rolling replacement ensures nodes are replaced one at a time without disrupting running workloads.

If you manage your node groups through Terraform or CloudFormation, CA rotation does not create drift in your IaC state. The CA lifecycle is managed through dedicated EKS APIs that are separate from your cluster resource configuration. For more detail on how CA rotation interacts with infrastructure as code, see the Infrastructure as code section.

Karpenter-controlled nodes

If drift detection is enabled in your Karpenter NodePool, Karpenter will automatically detect that nodes are running with outdated CA data and cycle them within its configured disruption window. New nodes will pick up the successor CA without manual action.

Verify drift detection is enabled in your NodePool configuration:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

If disruption is configured with a consolidation policy, drift detection is active by default. Karpenter will replace nodes that have drifted from their desired state, which includes CA data changes.

If drift detection is enabled, verify that your disruption budget allows all Karpenter-controlled nodes to be replaced before the successor CA activation date. If the budget is too restrictive (for example, a narrow maintenance window with a low replacement percentage), not all nodes might be replaced in time.

If drift detection is disabled or your disruption budgets restrict replacements to a window that exceeds your rotation timeline, you can manually trigger node replacement by cordoning and draining nodes:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter will provision a replacement node that bootstraps with the updated CA data.

Self-managed nodes

For self-managed nodes, you need to update the CA data in the launch template or user data script that your nodes use during bootstrap:

New nodes will bootstrap with the updated CA data and trust both the current and successor CAs.

AWS Fargate pods (EKS Fargate launch type)

AWS Fargate pods in your EKS cluster work differently from other EKS data plane launch modes (managed node groups, self-managed nodes, Karpenter-controlled nodes).

When a pod connects to the API server, two things happen: the pod authenticates itself using its service account token (proving its identity to the API server), and the pod verifies the API server’s identity by checking that the server’s certificate was signed by a CA it trusts. The CA data stored in the pod’s environment is what makes this verification possible. If the API server starts presenting certificates signed by a successor CA that the pod does not trust, the pod will reject the connection.

In other EKS data plane launch modes (managed node groups, self-managed nodes, Karpenter-controlled nodes), the CA data lives on the node. When you replace the node, the new node bootstraps with the updated CA data. Pods scheduled onto that new node receive the updated CA data, allowing them to verify the API server regardless of which CA signed its certificate.

In Fargate, each pod runs in its own dedicated compute environment with its own kubelet process. This kubelet bootstraps with the CA data at the time the pod is created. There is no shared node underneath, and you do not have direct access to the underlying compute.

No customer action is required for AWS Fargate nodes in EKS during CA rotation. AWS naturally recycles pods in Fargate nodes through its patching process. After a successor CA is appended, pre-existing Fargate pods are recycled as part of this process. They will trust the successor CA without any action from you. Since AWS appends the successor CA well ahead of any AWS-initiated CA activation timeline in EKS, Fargate pods will have been recycled and trust the successor CA by the time AWS activates the successor CA. There is a built-in safeguard that prevents activation of the successor CA until Fargate pods have finished recycling.

This means both managed data plane options (EKS Auto Mode and Fargate) for an EKS cluster have the same user experience for CA rotation: no customer action is required for your worker nodes. You are still responsible for updating any external clients that connect to the API server.

This is an edge case. Given the rotation timeline (successor CA appended years before expiration), the natural patching cycle will complete well before activation of the successor CA in the vast majority of scenarios. The safeguard exists as a preventive measure for the unlikely case where a customer attempts early activation.

External clients (monitoring tools, third-party integrations)

Any application or tool that connects to your EKS cluster’s API server using a kubeconfig or certificate trust configuration needs to be updated with the updated CA data. This includes:

For each of these, replace the stored CA data with the updated value from describe-cluster.

How to verify a client has been updated

After updating a client, confirm it can still communicate with the API server:

kubectl get nodes

If the command succeeds, your kubeconfig trusts the active CA data. After activation of the successor CA, run the same command to confirm continued connectivity.

Infrastructure as code

You can perform CA rotation alongside your existing infrastructure as code (IaC) without creating drift or requiring changes to your IaC configurations.

Why CA rotation does not affect your IaC state

The CA lifecycle is managed through dedicated EKS APIs (create-certificate-authority, activate-certificate-authority, delete-certificate-authority) that are entirely separate from the EKS cluster resource configuration. Whether CA rotation is initiated by you, or automatically by AWS, no property tracked by your IaC tooling on the EKS cluster resource is modified.

This means:

The certificateAuthority.data field returned by describe-cluster is a read-only output. It reflects the current combined trust bundle (both CAs during the dual trust period) but is not a configurable property. IaC tools do not track it as something to reconcile.

Attribution fields (createdBy, activatedBy) on each CA record allow you to distinguish between operations you initiated and operations AWS initiated automatically, which supports audit and change management workflows.

Using CloudFormation with CA rotation

CA rotation can be triggered through CloudFormation using a WriteOnly property on the AWS::EKS::Cluster resource. This property triggers activation but is not stored in the stack’s state, so subsequent stack updates without it do not attempt to revert or deactivate.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

This first stack update appends a successor CA to your cluster. Wait for the successor CA’s distribution status to reach COMPLETE before proceeding.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

This second stack update triggers activation of the successor CA. Because ActiveCertificateAuthorityId is a WriteOnly property, it is not returned on read and CloudFormation will not detect drift if the active CA changes outside of CloudFormation (for example, through auto-activation by AWS).

Important: The CA rotation CloudFormation integration follows a different pattern than typical CloudFormation resources. A certificate authority in EKS is not an independent resource with its own ARN. It exists as part of the cluster’s certificate lifecycle and is authorized through the cluster itself, similar to how an IAM role policy is authorized through its parent role (AWS::IAM::RolePolicy) or an EIP association is authorized through its instance (AWS::EC2::EIPAssociation). Customers managing CA rotation through CloudFormation should be aware of this distinction.

Managed node groups and IaC

Performing a node group version update to refresh nodes with the updated CA trust configuration is an operational action. New nodes automatically bootstrap with the active CA trust data from the cluster. If your IaC templates do not hardcode CA data in launch templates or user data, no template changes are required.

CA rollback

After activating a successor CA, you can rollback to the previous CA if you discover connectivity issues with the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) or external clients. Rolling back re-activates the previous CA as the signing authority for your EKS cluster.

When CA rollback is available

CA rollback is available after CA activation as long as:

You can check whether CA rollback is available at any time using the rollbackAvailable field returned by describe-certificate-authority:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

When CA rollback is not available

CA rollback is not available after final auto-activation. If AWS activates the successor CA for the final time (45 days before CA expiration), the rotation must proceed forward. Final auto-activation only occurs if the first auto-activation was previously rolled back. It exists as a last resort safeguard to ensure the EKS cluster does not reach CA expiration without a valid CA in place.

How to rollback

To rollback, re-activate the previous CA:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

What happens during CA rollback

When to consider CA rollback

CA rollback is a safety mechanism for situations where successor CA activation reveals a connectivity issue you did not catch beforehand:

After rolling back, you retain the full dual trust period to identify and fix the issue before re-activating the successor CA.

Recovery without CA rollback

If you activate the successor CA before updating your managed node groups and the CA rollback window is no longer available (for example, after the final auto-activation deadline), you can recover by performing a rolling update on the affected node groups. However, the initial rolling update attempt will fail because disconnected nodes cannot receive pod eviction commands from the API server.

Recovery steps

Considerations and limitations

Regional availability

CA rotation is available in all AWS commercial Regions where Amazon EKS is supported.

Maximum two CAs

An EKS cluster can have at most two CAs at any time: the active CA and one successor. You cannot append a second successor CA until the previous rotation is complete.

No certificate revocation

CA rotation does not support revoking individual certificates. This is consistent with upstream Kubernetes, which does not implement certificate revocation (CRL or OCSP). Rotation replaces the entire CA, which naturally invalidates all certificates signed by the outgoing CA after it is removed from the trust bundle.

AWS-appended CAs cannot be deleted

If AWS automatically appended a successor CA, you cannot delete it. This safeguard ensures the rotation process cannot be interrupted by accidental deletion. Customer-appended CAs can be deleted as long as they are not the active signing CA.

CA validity period

The original CA created with your cluster has a 10-year validity period. Successor CAs created through the rotation process have 5-year validity periods. All future CAs for your cluster will follow the 5-year validity period. Check your CA’s expiration using describe-certificate-authority.

EC2 user data size during dual trust

During the dual trust period, your cluster’s trust bundle increases in size due to containing two CA certificates (approximately 2.8 KB combined, or approximately 1.9 KB with gzip compression). For worker nodes where custom user data is provided in EC2 launch templates, verify that your total user data size does not exceed the EC2 user data limit of 16KB. If your existing user data is close to this limit, the addition of a second CA might cause launch template creation to fail and prevent new nodes from being provisioned. Consider compressing your user data content using gzip to reduce size.

Version upgrades during CA rotation

EKS cluster version upgrades and CA rotation are independent operations. However, you cannot perform both simultaneously. If a CA rotation operation is in progress, a version upgrade will be rejected until the CA operation completes, and vice versa.

Bring Your Own CA (BYOCA)

Using your own AWS Private CA to back your EKS cluster’s certificates is not currently supported.

Frequently asked questions

How do I get started with CA rotation?

To get started, run aws eks list-certificate-authorities --cluster-name my-cluster to view your active CA and its expiration. If you are ready to begin rotation, run aws eks create-certificate-authority --cluster-name my-cluster to append a successor CA. The full step-by-step process is covered in the Getting Started section. You can also perform CA rotation through the Amazon EKS console.

Is there any cost associated with CA rotation?

No. CA rotation is available at no additional cost for all EKS clusters.

What happens if I don’t rotate my CA before it expires?

We have automatic safeguards that prevent your EKS cluster from reaching CA expiration without a valid CA in place. If you do not initiate CA rotation yourself, we will automatically append and activate a successor CA before expiration, ensuring your cluster remains available.

However, a successful rotation also requires you to update the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients to trust the successor CA. If these components are not updated before the successor CA is activated, they will lose connectivity to the API server.

In Kubernetes, if a CA is not rotated before it expires, all certificates signed by that CA become invalid. The API server can no longer be reached by any client, and the cluster becomes unavailable.

How much time do I have to complete CA rotation?

The overall time to complete CA rotation depends on both AWS automated safeguards and your own update process.

AWS provides definitive timelines for what it manages. A successor CA is appended approximately 2 years before your outgoing CA expires. If you do not activate the successor CA yourself, we will auto-activate it approximately 6 months before expiration. If you rollback after auto-activation, we will perform a final auto-activation 45 days before expiration. These safeguards ensure your EKS cluster remains available regardless of whether you act.

A successful CA rotation also depends on you updating the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients to trust the successor CA before activation of the successor CA. How long this takes depends on your data plane’s worker node configuration, your external client footprint, and how long it takes for you to perform discovery and updates of these components.

Does CA rotation cause downtime for my cluster?

No. Your EKS cluster remains available throughout the entire CA rotation lifecycle. The control plane continues to serve requests at every stage. During the dual trust period, both the outgoing and successor CAs are trusted simultaneously, allowing components to be updated incrementally without interruption to cluster operations. If you rolled back to the previous CA due to discovering client-side issues, AWS performs a final roll forward approximately 45 days prior to the outgoing CA’s expiration as a safeguard.

It is important to distinguish between the EKS cluster (control plane) and your data plane components. The control plane is fully managed by AWS and remains available throughout rotation.

For EKS Auto Mode and Fargate, AWS updates worker nodes automatically. There is no risk of connectivity loss for your worker nodes in these data plane launch modes. You are still responsible for updating any external clients that connect to the API server.

For managed node groups, self-managed nodes, Karpenter-controlled instances (without drift detection enabled), and hybrid nodes, you are responsible for replacing or updating those nodes before activation of the successor CA. If they are not replaced, those nodes will lose connectivity to the control plane after the successor CA is activated, even though the control plane itself remains fully operational.

Will my workloads be disrupted during CA rotation?

Running workloads (pods) are not disrupted by CA rotation itself. Pods communicate with each other through the cluster network, which is not affected by a CA change. The CA is used for communication between components and the API server, not for pod-to-pod traffic.

If your worker nodes need to be replaced as part of updating them to trust the successor CA (for example, managed node groups performing a rolling update, or Karpenter replacing drifted nodes), pods on those nodes will be rescheduled as part of the normal node replacement process. This is standard Kubernetes behavior during node replacement, not a side effect of CA rotation. Ensure you have Pod Disruption Budgets (PDBs) configured for critical workloads to control how pods are evicted during node replacements.

When will my cluster’s CA expire?

You can check when your cluster’s CA expires using the AWS CLI, EKS APIs, or the Amazon EKS console. For example, you can run the following:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

You can find your CA’s ID by running aws eks list-certificate-authorities --cluster-name my-cluster.

What is the validity period of my cluster’s CA?

The original CA created with your cluster has a 10-year validity period. Successor CAs created through the rotation process have 5-year validity periods. All future CAs for your cluster will follow the 5-year validity period. You can check your CA’s expiration using describe-certificate-authority.

Can I initiate a CA rotation myself before AWS does it automatically?

Yes. You can append a successor CA at any time using aws eks create-certificate-authority --cluster-name my-cluster. You do not need to wait for AWS to initiate rotation. Starting early gives you more time to identify and update your worker nodes and external clients on your own schedule.

Can I rollback after activating a successor CA?

Yes, CA rollback is available after activation of the successor CA as long as the rollback window has not expired. CA rollback re-activates the previous CA as the signing authority. It is not available after final auto-activation (45 days before CA expiration). You can check the rollbackAvailable field on your CA using describe-certificate-authority. See the CA Rollback section for details.

How do I know when it’s safe to activate the successor CA?

It is safe to activate the successor CA when all the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients have been updated to trust the successor CA. You can verify this by confirming that each client can successfully communicate with the API server using the updated trust configuration. AWS does not provide a single indicator that all clients are ready, as it cannot see into your external systems. Start the discovery process early to give yourself time to identify all clients.

How do I monitor CA rotation progress across multiple clusters?

You can accomplish this programmatically using the AWS CLI or EKS API. Use aws eks list-certificate-authorities for each cluster. The following fields provide situational awareness for fleet-level monitoring:

The following example script checks CA rotation status across a list of clusters:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

You can extend this to cover multiple regions and accounts, and filter for clusters that have a successor CA appended, are awaiting your action, or are approaching auto-activation deadlines.

Notifications are also delivered per-cluster through AWS Health and email at each stage of the rotation lifecycle.

What happens if I activate the successor CA before updating all my clients?

Any client that has not been updated to trust the successor CA will lose connectivity to the EKS cluster. After activation of the successor CA, the API server presents certificates signed by the successor CA. Clients that do not trust it will fail their TLS verification and be unable to connect. If this happens, you can rollback to the previous CA (if the rollback window is still available) to restore connectivity while you fix the remaining clients.

What happens if I miss the CA expiration deadline?

AWS prevents this from happening. Automatic safeguards ensure your EKS cluster does not reach CA expiration without a valid CA in place. We will append a successor CA if you have not done so, and will auto-activate it approximately 6 months before expiration. If you rolled back after the first auto-activation, AWS performs a final roll forward 45 days before expiration. Your cluster will remain available.

However, if the worker nodes that you manage (non-EKS Auto Mode, non-Fargate) and external clients have not been updated to trust the successor CA by the time auto-activation occurs, those components will lose connectivity to the API server.

Can I lose access to my cluster during CA rotation?

Your EKS cluster (control plane) remains available throughout the entire CA rotation lifecycle. AWS safeguards ensure the cluster itself does not become unavailable.

However, individual clients you manage can lose access if they are not updated to trust the successor CA before activation of the successor CA. For example, if your kubeconfig, CI/CD pipeline, or monitoring tool still references only the outgoing CA, those clients will be unable to connect after the successor CA is activated. If this happens, CA rollback can restore access while you update the affected clients.

Do I need to restart my pods?

Running workload pods are not directly affected by CA rotation. The kubelet on each node handles API server communication, so workload pods will continue to run without interruption as long as your nodes are updated. However, in-cluster controllers and operators that use client-go to communicate with the API server might need to be restarted after activation of the successor CA, as client-go does not dynamically re-read the CA trust bundle. For AWS Fargate nodes specifically, AWS handles the update automatically through the natural pod recycling process.

Will my trust bundle change during rotation?

Yes. During CA rotation, your cluster’s trust bundle will contain two certificate authorities simultaneously: the outgoing CA and the successor CA. This is expected behavior during the dual trust period and is how the rotation process maintains connectivity for all components.

Applications and clients should be configured to trust a CA bundle rather than pin to a single CA certificate. CA pinning (strict validation against a single CA) is not recommended, as it will cause failures when the trust bundle is updated. This applies to any client-side TLS configuration that connects to your EKS cluster’s API server.

Why is my notification timeline different from what this documentation describes?

If your cluster was created in 2018-2019, your cluster will receive automated notifications on an adjusted timeline. Your first notification will include the relevant dates and next steps specific to your cluster. The standard notification milestones are calculated relative to your cluster’s CA expiration date. For clusters in this range, those calculated dates precede the availability of this feature, so an adjusted schedule is applied.