> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Is ha enabled remediation ### Triage and Remediation ### Remediation To remediate the misconfiguration of EKS Clusters not having high availability in AWS, you can follow the below steps using the AWS console: 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. By following these steps, you can remediate the misconfiguration of EKS Clusters not having high availability in AWS. # To remediate the misconfiguration of EKS clusters not having high availability in AWS using AWS CLI, follow these steps: 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 --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 --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 --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. By following these steps, you can remediate the misconfiguration of EKS clusters not having high availability in AWS using AWS CLI. To remediate the misconfiguration of EKS Clusters not having high availability in AWS using Python, follow the steps below: 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) ``` Note: Replace 'subnet-xxxxxxxx', 'subnet-yyyyyyyy', 'subnet-zzzzzzzz' with the IDs of the subnets in which you want to launch your EKS worker nodes. These subnets should be in different availability zones to enable high availability. 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) ``` With these steps, you can remediate the misconfiguration of EKS clusters not having high availability in AWS using Python. ```hcl theme={null} 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 } ``` To **scale an existing multi‑AZ node group** managed by Terraform instead of creating a new one, update only its `scaling_config` block so it matches the verified CLI remediation: ```hcl theme={null} 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 } ``` Notes: * 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. For verification, `terraform plan` should show: * `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`.