> ## 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. # Underutilized ec2 instance remediation ### Triage and Remediation ### Remediation To remediate the misconfiguration of underutilized EC2 instances in AWS, you can follow the below steps: 1. Log in to your AWS Management Console. 2. Go to the EC2 Dashboard. 3. Click on the "Instances" option from the left-hand side menu. 4. Select the underutilized EC2 instance(s) that you want to remediate. 5. Click on the "Actions" button and select "Create Image" from the dropdown list. 6. Enter the required details for creating an image of the instance and click on the "Create Image" button. 7. Once the image is created, go to the "AMIs" section from the left-hand side menu. 8. Select the newly created AMI and click on the "Launch" button. 9. Follow the on-screen instructions to launch a new instance from the AMI. 10. Once the new instance is launched, you can terminate the underutilized instance(s) to save costs. By creating an AMI of the underutilized EC2 instance and launching a new instance from it, you can ensure that the new instance is properly configured and optimized for your workload. This will help you avoid underutilization of your EC2 instances and reduce your AWS costs. # To remediate EC2 instances that are underutilized in AWS using AWS CLI, you can follow these steps: 1. Identify the underutilized EC2 instances by checking their CPU utilization metrics. You can use the following AWS CLI command to get the CPU utilization metrics for all running instances in your account: ``` aws cloudwatch get-metric-statistics --namespace "AWS/EC2" --metric-name "CPUUtilization" --dimensions "Name=InstanceId,Value=INSTANCE_ID" --start-time START_TIME --end-time END_TIME --period 300 --statistics "Average" ``` Replace INSTANCE\_ID with the ID of the instance you want to check, START\_TIME and END\_TIME with the time range you want to check. 2. Once you have identified the underutilized instances, you can take the following actions: * Resize the instance: If the instance is underutilized because it has too few resources, you can resize the instance to a larger size using the `modify-instance-attribute` AWS CLI command. ``` aws ec2 modify-instance-attribute --instance-id INSTANCE_ID --instance-type INSTANCE_TYPE ``` Replace INSTANCE\_ID with the ID of the instance you want to resize and INSTANCE\_TYPE with the new instance type. * Terminate the instance: If the instance is underutilized because it is no longer needed, you can terminate the instance using the `terminate-instances` AWS CLI command. ``` aws ec2 terminate-instances --instance-ids INSTANCE_ID ``` Replace INSTANCE\_ID with the ID of the instance you want to terminate. 3. Monitor the CPU utilization metrics of your instances regularly to ensure they are not underutilized or overutilized. You can set up CloudWatch alarms to notify you when the CPU utilization exceeds or falls below a certain threshold. By following these steps, you can remediate the misconfiguration of underutilized EC2 instances in AWS. To remediate EC2 instances that are underutilized in AWS using Python, you can follow the below steps: 1. Identify underutilized instances: * Use AWS SDK for Python (Boto3) to get the list of all EC2 instances. * For each instance, get its CPU utilization metric using CloudWatch. * If the average CPU utilization is below a certain threshold (e.g. 20%) for a certain period (e.g. 7 days), mark the instance as underutilized. 2. Stop underutilized instances: * Use Boto3 to stop the identified underutilized instances. * Before stopping the instance, make sure that it is not being used for any critical application or service. 3. Schedule start/stop instances: * Use AWS Lambda and CloudWatch Events to schedule start/stop instances based on the usage pattern. * For example, you can start instances during peak hours and stop them during off-hours to save costs. 4. Resize underutilized instances: * Use AWS Auto Scaling to resize instances based on their usage pattern. * For example, you can increase the instance size during peak hours and decrease it during off-hours to optimize costs. 5. Monitor and optimize: * Monitor the instances regularly to ensure that they are not underutilized or overutilized. * Optimize the instances based on the usage pattern and workload requirements to minimize costs and maximize performance. Note: It is important to ensure that the remediation process does not affect the availability and performance of critical applications or services running on the EC2 instances. ```hcl theme={null} # Resize an underutilized EC2 instance to a smaller type resource "aws_instance" "APP_INSTANCE" { ami = "AMI_ID" # replace with the desired AMI ID instance_type = "NEW_SMALLER_TYPE" # e.g., "t3.micro"; must be compatible with current architecture/root device subnet_id = "SUBNET_ID" # replace with your subnet # ...other required arguments (security groups, key_name, etc.) } ``` Changing `instance_type` on an existing `aws_instance` will cause downtime while AWS stops and starts the instance to apply the new type, but it does not normally force replacement of the instance itself (EBS-backed, HVM, compatible type, etc.). ```hcl theme={null} # Terminate an unused EC2 instance managed by Terraform # Option 1: Scale the resource to zero (if defined with count) resource "aws_instance" "APP_INSTANCE" { count = 0 # set from 1 (or higher) down to 0 to destroy all instances ami = "AMI_ID" instance_type = "INSTANCE_TYPE" subnet_id = "SUBNET_ID" # ...other arguments } ``` or, if the instance is a single resource without `count`, you terminate it by removing its `aws_instance` block from Terraform entirely and running `terraform apply`. This is destructive and irreversible: the instance and any instance-store volumes are lost; EBS volumes with `delete_on_termination = true` on their attachments will also be deleted, so ensure backups first. ```hcl theme={null} # If the instance is part of an Auto Scaling Group, downsize via the launch template resource "aws_launch_template" "APP_LT" { name_prefix = "APP_LT_" image_id = "AMI_ID" instance_type = "NEW_SMALLER_TYPE" # downsized type here # ...other launch template settings } resource "aws_autoscaling_group" "APP_ASG" { name = "APP_ASG" max_size = 3 min_size = 1 desired_capacity = 1 vpc_zone_identifier = ["SUBNET_ID"] launch_template { id = aws_launch_template.APP_LT.id version = "$Latest" } # ...other ASG settings } ``` All uppercase placeholders (e.g., `APP_INSTANCE`, `AMI_ID`, `NEW_SMALLER_TYPE`, `SUBNET_ID`) must be replaced with your real names/IDs and chosen smaller instance type that is compatible with the existing instance (architecture, virtualization, and root device). Changing `instance_type` or changing/removing the `aws_instance` or `aws_autoscaling_group`/`aws_launch_template` definitions will show in `terraform plan` as: * a `~` (update in-place) on the EC2 instance or launch template for a resize, and * a `-` (destroy) for terminated instances (or ASG instances recreated with the new type).