1. Go to the Amazon EKS console.
2. Select the EKS cluster that you want to remediate.
3. Click on the “Configuration” tab.
4. Under the “Networking” section, click on “Edit”.
5. Ensure that the “Private networking only” option is unchecked.
6. Under the “High availability” section, click on “Edit”.
7. Select the “Multiple Availability Zones” option.
8. Choose the number of availability zones you want to use.
9. Click on “Save”.
10. Wait for the changes to propagate.

​

1. Open the AWS CLI and ensure that you have the necessary permissions to make changes to the EKS cluster.
2. Check if the EKS cluster is currently configured for high availability by running the following command:
   aws eks describe-cluster --name <cluster-name> --query "cluster.resourcesVpcConfig.endpointPublicAccess"
   
   This command will return a boolean value, where true indicates that the EKS cluster is configured for high availability, and false indicates that it is not.
3. If the EKS cluster is not configured for high availability, you can enable it by modifying the cluster’s endpoint access configuration using the following command:
   aws eks update-cluster-config --name <cluster-name> --resources-vpc-config endpointPublicAccess=true
   
   This command will modify the EKS cluster’s endpoint access configuration to enable high availability.
4. Verify that the EKS cluster is now configured for high availability by running the describe-cluster command again and checking the endpointPublicAccess value.
   aws eks describe-cluster --name <cluster-name> --query "cluster.resourcesVpcConfig.endpointPublicAccess"
   
   This command should now return true, indicating that the EKS cluster is configured for high availability.
5. Repeat these steps for any other EKS clusters that are not configured for high availability.

1. Import the necessary AWS SDK modules in Python:

import boto3
from botocore.exceptions import ClientError

2. Create a boto3 EKS client object:

eks_client = boto3.client('eks')

3. Get the EKS cluster name for which you want to enable high availability:

cluster_name = 'your-cluster-name'

4. Check if the EKS cluster is already highly available:

try:
    response = eks_client.describe_cluster(name=cluster_name)
    if response['cluster']['resourcesVpcConfig']['subnetIds']:
        print('EKS cluster is already highly available.')
    else:
        print('EKS cluster is not highly available.')
except ClientError as e:
    print('Error:', e)

5. If the EKS cluster is not highly available, update the cluster configuration to enable high availability:

try:
    eks_client.update_cluster_config(
        name=cluster_name,
        resourcesVpcConfig={
            'subnetIds': ['subnet-xxxxxxxx', 'subnet-yyyyyyyy', 'subnet-zzzzzzzz']
        }
    )
    print('EKS cluster configuration updated to enable high availability.')
except ClientError as e:
    print('Error:', e)

6. Verify that the EKS cluster is now highly available:

try:
    response = eks_client.describe_cluster(name=cluster_name)
    if response['cluster']['resourcesVpcConfig']['subnetIds']:
        print('EKS cluster is now highly available.')
    else:
        print('EKS cluster is still not highly available.')
except ClientError as e:
    print('Error:', e)

resource "aws_eks_node_group" "HA_NODE_GROUP" {
  cluster_name    = aws_eks_cluster.EKS_CLUSTER.name          # replace with your EKS cluster resource
  node_group_name = "my-ha-nodegroup"                         # adjust name as needed
  node_role_arn   = aws_iam_role.EKS_NODE_ROLE.arn            # replace with your node IAM role

  # IMPORTANT: choose at least 3 subnets in 3 different AZs in the same VPC as the cluster
  subnet_ids = [
    SUBNET_ID_AZ1,  # replace with subnet ID in AZ 1
    SUBNET_ID_AZ2,  # replace with subnet ID in AZ 2
    SUBNET_ID_AZ3   # replace with subnet ID in AZ 3
  ]

  scaling_config {
    min_size     = 3
    desired_size = 3
    max_size     = 5  # adjust to your capacity requirements
  }

  instance_types = ["t3.medium"]  # adjust instance type to fit your workload

  capacity_type = "ON_DEMAND"     # or "SPOT" if desired
}

resource "aws_eks_node_group" "EXISTING_NODE_GROUP" {
  cluster_name    = aws_eks_cluster.EKS_CLUSTER.name
  node_group_name = "EXISTING_NODE_GROUP_NAME"  # replace with your existing node group name
  node_role_arn   = aws_iam_role.EKS_NODE_ROLE.arn
  subnet_ids      = EXISTING_MULTI_AZ_SUBNET_IDS # keep the current multi‑AZ subnets

  scaling_config {
    min_size     = 3
    desired_size = 3
    max_size     = 5  # or keep your existing max_size
  }

  instance_types = ["t3.medium"]  # or keep your existing type
}

• Changing scaling_config does not force replacement of the node group; nodes are scaled in place (but new nodes will be created, incurring cost).
• Changing subnet_ids on an aws_eks_node_group does force node group replacement, causing node recreation and potential workload disruption if not drained/migrated properly first.

• aws_eks_node_group.HA_NODE_GROUP being created with scaling_config min_size = 3, desired_size = 3, max_size = 5 and three subnet_ids in different AZs; or
• For an existing node group, an in‑place update of scaling_config to min_size = 3, desired_size = 3 with no changes to subnet_ids.