AWS EC2 Troubleshooting

AWS EC2 Troubleshooting

An Instance Immediately Terminates

  • EBS volume limit was reached. EBS volume limits are soft limits and can be increased by submitting a Service Quotas request.
  • EBS snapshot is corrupt.
  • Root EBS volume is encrypted and you do not have permission to access the KMS key for decryption.
  • A snapshot specified in the block device mapping for the AMI is encrypted and you do not have permissions to access the KMS key for decryption.
  • Instance store-backed AMI used to launch the instance is missing a required part (e.g., image.part.xx file).
  • Resolution
    • Check the State transition reason in the EC2 console (Instance description tab) to identify the exact cause.
    • Delete unused volumes if volume limit is reached.
    • Ensure proper permissions to access the AWS KMS keys for decryption.
    • Verify block device mapping snapshots are accessible.

EC2 Instance Connectivity Issues

  • Error connecting to your instance: Connection timed out
    • Route table for the subnet does not have a route that sends all traffic destined outside the VPC to the Internet gateway for the VPC.
    • Security group does not allow inbound traffic from the public IP address on the proper port.
    • Network ACL does not allow inbound traffic from and outbound traffic to the public IP address on the proper port.
    • Private key used to connect does not match with the key pair selected for the instance during launch.
    • Appropriate user name for the AMI is not used for e.g. user name for Amazon Linux 2/Amazon Linux 2023 AMI is ec2-user, Ubuntu AMI is ubuntu, RHEL AMI is ec2-user, SUSE Linux is ec2-user, Fedora AMI is fedora or ec2-user, Debian AMI is admin.
    • If connecting from a corporate network, the internal firewall does not allow inbound and outbound traffic on port 22 (for Linux instances) or port 3389 (for Windows instances).
    • Instance does not have the same public IP address, which changes during restarts. Associate an Elastic IP address with the instance.
    • CPU load on the instance is high; the server may be overloaded.
    • Instance is in a private subnet without a public IP. Use EC2 Instance Connect Endpoint or Systems Manager Session Manager for connectivity.
  • User key not recognized by the server
    • Private key file used to connect has not been converted to the format required by the server (e.g., PuTTY requires .ppk format).
  • Host key not found, Permission denied (publickey), or Authentication failed, permission denied
    • Appropriate user name for the AMI is not used for connecting.
    • Proper private key file (.pem or .ppk) for the instance is not used.
  • Unprotected Private Key File
    • Private key file is not protected from read and write operations from any other users.
    • Resolution: Set file permissions to 400 using chmod 400 key.pem.
  • Server refused our key or No supported authentication methods available
    • Appropriate user name for the AMI is not used for connecting.
    • Instance does not have the correct public key in ~/.ssh/authorized_keys.

Modern Connectivity Alternatives

  • EC2 Instance Connect Endpoint (EIC Endpoint)
    • Launched in June 2023, allows SSH and RDP connectivity without public IP addresses.
    • No need for an Internet Gateway, bastion host, or agent on the instance.
    • Creates a private tunnel from your client to the instance through the AWS network.
    • Supports both SSH (port 22) and RDP (port 3389) connections.
    • Security group on the instance must allow inbound traffic from the EIC Endpoint.
    • IAM policies control who can use the endpoint to connect to specific instances.
  • EC2 Instance Connect (Browser-based)
    • Provides browser-based SSH connection from the AWS Console.
    • Uses temporary (60-second) SSH keys — no need to manage long-term SSH keys.
    • Supports RSA and ED25519 key pairs.
    • Requires the EC2 Instance Connect package installed on the instance (pre-installed on Amazon Linux 2, Amazon Linux 2023, Ubuntu 20.04+).
  • AWS Systems Manager Session Manager
    • Provides shell access without opening inbound ports (no port 22 needed).
    • No SSH keys required — uses IAM for authentication and authorization.
    • Full audit trail logged in CloudTrail with optional session logging to S3/CloudWatch.
    • Works with instances in private subnets (requires SSM Agent and appropriate IAM role).
    • Supports port forwarding for accessing applications on the instance.
    • Available at no additional charge for EC2 instances.

Failed Status Checks

  • System Status CheckChecks Physical Host
    • Lost network connectivity
    • Loss of system power
    • Software issues on the physical host
    • Hardware issues on the physical host that affect network reachability
    • Resolution
      • Amazon EBS-backed AMI instance — stop and start the instance (migrates to a new host).
      • Instance-store backed AMI — terminate the instance and launch a replacement.
      • Simplified Automatic Recovery — enabled by default on supported instance types; automatically moves the instance to a new host when system status check fails.
  • Instance Status CheckChecks Instance/VM
    • Possible reasons
      • Misconfigured networking or startup configuration
      • Exhausted memory
      • Corrupted file system
      • Failed Amazon EBS volume or physical drive
      • Incompatible kernel
    • Resolution
      • Reboot the instance or make modifications in the operating system or volumes.
      • Use EC2 Serial Console to troubleshoot boot and network configuration issues interactively.
      • Use AWSSupport-TroubleshootSSH automation runbook to automatically diagnose and fix SSH issues.
  • Attached EBS Status CheckChecks EBS Volume Reachability (added 2024)
    • Monitors whether EBS volumes attached to an instance are reachable and can complete I/O operations.
    • Available for all Nitro-based instances.
    • CloudWatch metric: StatusCheckFailed_AttachedEBS
    • Possible reasons
      • EBS volume hardware failure
      • Connectivity issue between the instance and EBS volume
      • EBS infrastructure issues
    • Resolution
      • Check EBS volume status in the console.
      • Detach and reattach the volume, or create a new volume from the latest snapshot.
      • Stop and start the instance to migrate to a new host.

EC2 Serial Console

  • Provides a text-based serial connection to troubleshoot boot and network issues.
  • Works even when the OS is not fully booted, network is down, or SSH is broken.
  • Supported on Nitro-based instances.
  • Must be enabled at the account level before use.
  • Requires a password-based OS user (SSH keys don’t work for serial console).
  • Use Cases:
    • Troubleshoot boot failures (GRUB menu access, kernel issues).
    • Diagnose network misconfigurations that block SSH.
    • Fix firewall rules (iptables/nftables) that locked out SSH.
    • Recover from file system errors.
    • Debug SELinux/AppArmor issues preventing boot.

EC2Rescue and Automated Troubleshooting

  • AWSSupport-TroubleshootSSH Automation Runbook
    • Installs EC2Rescue tool and automatically checks/fixes common SSH issues.
    • Checks SSH daemon configuration, file permissions, and network settings.
    • Can run in read-only mode (inspect) or fix mode (FixAll).
    • Runs via AWS Systems Manager Automation.
  • EC2Rescue for Linux
    • Diagnoses and remediates OS-level issues on EC2 Linux instances.
    • Can be run on an offline instance by attaching its root volume to a rescue instance.
    • Checks: SSH configuration, file system consistency, network settings, kernel issues.
  • AWSSupport-ExecuteEC2Rescue
    • Automation document that creates a rescue instance, moves the root volume, runs EC2Rescue, and reattaches the volume.
    • Useful when instance is completely unreachable.

Instance Capacity Issues

  • InsufficientInstanceCapacity
    • AWS does not currently have enough available capacity to service the request.
    • Issue is mainly from the AWS side and it can be resolved by:
      • Waiting a few minutes and resubmitting the request.
      • Reducing the request for the number of instances.
      • Changing the instance type.
      • Submitting a request without specifying the Availability Zone.
      • Using On-Demand Capacity Reservations to reserve capacity in advance.
      • Using EC2 Capacity Blocks for ML to reserve GPU instances for ML workloads.
  • InstanceLimitExceeded
    • EC2 On-Demand instance limits are now vCPU-based (not count-based). Each instance family has a separate vCPU quota per region.
    • Default vCPU limits vary by instance family (e.g., Running On-Demand Standard instances default: varies by account).
    • Spot Instance limits are also vCPU-based.
    • Resolution: Request a Service Quotas increase on a per-region, per-instance-family basis.

Key Pair and SSH Key Troubleshooting

  • Supported Key Types
    • RSA (2048-bit) — supported for all instance types, required for Windows instances.
    • ED25519 — supported for Linux instances only, provides better performance and security.
  • Common Key Issues
    • Using an ED25519 key with a Windows instance (not supported).
    • Key file permissions too open (must be 400 or 600 on Linux/macOS).
    • Key not converted to .ppk format for PuTTY on Windows.
    • Wrong key pair — instance was launched with a different key pair than the one being used to connect.
  • Recovery Options (if key is lost)
    • Use EC2 Instance Connect to push a temporary key and regain access.
    • Use Systems Manager Session Manager (no SSH key required).
    • Stop the instance, detach root volume, mount on another instance, add public key to authorized_keys, reattach.
    • Use EC2 Serial Console to log in with a password-based user and fix authorized_keys.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has launched an EC2 instance. The instance got terminated as soon as it was launched. Which of the below mentioned options is not a possible reason for this?
    1. The user account has reached the maximum EC2 instance limit (Refer link)
    2. The snapshot is corrupt
    3. The AMI is missing. It is the required part
    4. The user account has reached the maximum volume limit
  2. If you’re unable to connect via SSH to your EC2 instance, which of the following should you check and possibly correct to restore connectivity?
    1. Adjust Security Group to permit egress traffic over TCP port 443 from your IP.
    2. Configure the IAM role to permit changes to security group settings.
    3. Modify the instance security group to allow ingress of ICMP packets from your IP.
    4. Adjust the instance’s Security Group to permit ingress traffic over port 22 from your IP
    5. Apply the most recently released Operating System security patches.
  3. You try to connect via SSH to a newly created Amazon EC2 instance and get one of the following error messages: “Network error: Connection timed out” or “Error connecting to [instance], reason: -> Connection timed out: connect,” You have confirmed that the network and security group rules are configured correctly and the instance is passing status checks. What steps should you take to identify the source of the behavior? Choose 2 answers
    1. Verify that the private key file corresponds to the Amazon EC2 key pair assigned at launch.
    2. Verify that your IAM user policy has permission to launch Amazon EC2 instances. (there is no need for a IAM user and just need ssh keys)
    3. Verify that you are connecting with the appropriate user name for your AMI. (Although it gives different error seems the only other logical choice)
    4. Verify that the Amazon EC2 Instance was launched with the proper IAM role. (role assigned to EC2 is irrelevant for ssh and only controls what AWS resources EC2 can access)
    5. Verify that your federation trust to AWS has been established (federation is for authenticating the user)
  4. A user has launched an EBS backed EC2 instance in the us-east-1a region. The user stopped the instance and started it back after 20 days. AWS throws up an ‘Insufficient Instance Capacity’ error. What can be the possible reason for this?
    1. AWS does not have sufficient capacity in that availability zone
    2. AWS zone mapping is changed for that user account
    3. There is some issue with the host capacity on which the instance is launched
    4. The user account has reached the maximum EC2 instance limit
  5. A user is trying to connect to a running EC2 instance using SSH. However, the user gets an Unprotected Private Key File error. Which of the below mentioned options can be a possible reason for rejection?
    1. The private key file has the wrong file permission
    2. The ppk file used for SSH is read only
    3. The public key file has the wrong permission
    4. The user has provided the wrong user name for the OS login
  6. A user has launched an EC2 instance. However, due to some reason the instance was terminated. If the user wants to find out the reason for termination, where can he find the details?
    1. It is not possible to find the details after the instance is terminated
    2. The user can get information from the AWS console, by checking the Instance description under the State transition reason label
    3. The user can get information from the AWS console, by checking the Instance description under the Instance Status Change reason label
    4. The user can get information from the AWS console, by checking the Instance description under the Instance Termination reason label
  7. You have a Linux EC2 web server instance running inside a VPC. The instance is in a public subnet and has an EIP associated with it so you can connect to it over the Internet via HTTP or SSH. The instance was also fully accessible when you last logged in via SSH and was also serving web requests on port 80. Now you are not able to SSH into the host nor does it respond to web requests on port 80, that were working fine last time you checked. You have double-checked that all networking configuration parameters (security groups route tables, IGW, EIP. NACLs etc.) are properly configured and you haven’t made any changes to those anyway since you were last able to reach the Instance). You look at the EC2 console and notice that system status check shows “impaired.” Which should be your next step in troubleshooting and attempting to get the instance back to a healthy state so that you can log in again?
    1. Stop and start the instance so that it will be able to be redeployed on a healthy host system that most likely will fix the “impaired” system status (for system status check impaired status you need Stop Start for EBS and terminate and relaunch for Instance store. Note: Simplified Automatic Recovery may also handle this automatically on supported instance types.)
    2. Reboot your instance so that the operating system will have a chance to boot in a clean healthy state that most likely will fix the ‘impaired” system status
    3. Add another dynamic private IP address to the instance and try to connect via that new path, since the networking stack of the OS may be locked up causing the “impaired” system status.
    4. Add another Elastic Network Interface to the instance and try to connect via that new path since the networking stack of the OS may be locked up causing the “impaired” system status
    5. Un-map and then re-map the EIP to the instance, since the IGW/NAT gateway may not be working properly, causing the “impaired” system status
  8. A user is trying to connect to a running EC2 instance using SSH. However, the user gets a connection time out error. Which of the below mentioned options is not a possible reason for rejection?
    1. The access key to connect to the instance is wrong (access key is different from ssh private key)
    2. The security group is not configured properly
    3. The private key used to launch the instance is not correct
    4. The instance CPU is heavily loaded
  9. A user is trying to connect to a running EC2 instance using SSH. However, the user gets a Host key not found error. Which of the below mentioned options is a possible reason for rejection?
    1. The user has provided the wrong user name for the OS login
    2. The instance CPU is heavily loaded
    3. The security group is not configured properly
    4. The access key to connect to the instance is wrong (access key is different from ssh private key)
  10. An administrator cannot connect to an EC2 instance via SSH after it was rebooted. The instance is passing both status checks. The security group allows port 22 from the admin’s IP. What should the administrator try FIRST?
    1. Terminate and relaunch the instance
    2. Use EC2 Serial Console to check if the SSH daemon is running and review boot logs
    3. Create a new security group and attach it
    4. Contact AWS Support to restart the underlying host
  11. A company wants to provide shell access to EC2 instances in private subnets without opening port 22 or managing SSH keys. Which solution meets these requirements?
    1. Deploy a bastion host in a public subnet with a public IP
    2. Use EC2 Instance Connect with a public IP assigned to each instance
    3. Use AWS Systems Manager Session Manager with appropriate IAM roles
    4. Set up a VPN connection from the corporate network
  12. An EC2 instance is experiencing I/O errors. The system status check and instance status check both pass, but the attached EBS status check shows “impaired.” What is the most likely cause?
    1. The instance’s operating system has a corrupted file system
    2. The underlying physical host has a hardware failure
    3. The EBS volume attached to the instance is unreachable or unable to complete I/O operations
    4. The instance has exhausted its network bandwidth

AWS Autoscaling Troubleshooting

AWS EC2 Auto Scaling Troubleshooting

⚠️ Important: Launch Configurations Deprecated

AWS has deprecated Launch Configurations. As of October 1, 2024, new AWS accounts cannot create launch configurations using any method (Console, API, CLI, or CloudFormation). Existing accounts can still use them but should migrate to Launch Templates, which support all new EC2 features.

This post has been updated to reflect Launch Templates as the current standard. References to launch configurations are maintained for existing deployments.

Exam Question Scenario

EC2 instances fail to launch with Auto Scaling configuration

Auto Scaling Configuration Overview

  • Auto Scaling configuration requires the following:
    • Launch Template (recommended) or Launch Configuration (deprecated) which allows you to specify:
      • AMI
      • Instance type (or multiple instance types with mixed instances policy)
      • IAM role (optional)
      • Security group(s)
      • Key pair (optional)
      • Network interfaces and subnet settings
      • EBS volume configuration
      • User data scripts
    • Auto Scaling Group (ASG) configuration specifies:
      • VPC and Subnets (Availability Zones) for instance placement
      • Desired, minimum, and maximum capacity
      • Health check type and grace period
      • Scaling policies (target tracking, step, simple, predictive)
      • Instance maintenance policy
      • Load balancer / target group attachments

EC2 Instance Launch Failure Troubleshooting

  • AMI Issues
    • AMI ID does not exist or has been deregistered
    • AMI is still in a pending state and cannot be used to launch instances
    • AMI is in a different region than the Auto Scaling group
    • AMI permissions do not allow the account to launch from it (private/shared AMI)
  • Security Group Issues
    • Security group specified in the launch template does not exist or has been deleted
    • Security group belongs to a different VPC than the one specified in the ASG subnets
  • Key Pair Issues
    • Key pair associated with the launch template does not exist or has been deleted
  • Auto Scaling Group Configuration Issues
    • Auto Scaling group not found or is incorrectly configured
    • Subnet specified in the ASG does not exist or is invalid
    • AZ configured with the Auto Scaling group is no longer supported or unavailable
  • EBS Volume Issues
    • Invalid EBS block device mappings
    • EBS snapshot specified does not exist
    • EBS volume type not supported in the AZ
    • Encrypted EBS volumes require proper KMS key permissions for the service-linked role
  • Instance Type & Capacity Issues
    • Instance type is not supported in the specified AZ
    • InsufficientInstanceCapacity – AWS does not have enough capacity for the requested instance type in the AZ
    • Account-level service limits (vCPU limits) for instance types reached in the region
    • Spot Instance capacity unavailable or Spot price exceeds the maximum price specified
  • Launch Template Issues
    • Launch template version specified does not exist
    • Launch template contains invalid parameters (e.g., unsupported instance type for a region)
    • IAM instance profile specified does not exist or the ASG service role lacks iam:PassRole permission
  • Networking Issues
    • VPC/Subnet has no available IP addresses
    • Placement group constraints cannot be satisfied
    • Network interface configuration conflicts with subnet settings
  • Permission Issues
    • Auto Scaling service-linked role (AWSServiceRoleForAutoScaling) lacks required EC2 permissions
    • Custom service-linked role does not have permissions for encrypted volumes, specific VPCs, or EC2 actions
    • SCP (Service Control Policy) blocking required ec2:RunInstances action

Health Check Failure Troubleshooting

  • Auto Scaling supports multiple health check sources:
    • EC2 Status Checks – Default; checks instance system and instance status
    • ELB Health Checks – Target group health checks when integrated with ALB/NLB
    • VPC Lattice Health Checks – Health checks from VPC Lattice target groups
    • Amazon EBS Health Checks – Monitors attached EBS volume status
    • Custom Health Checks – User-defined via set-instance-health API
  • Common Health Check Issues:
    • Instances marked unhealthy immediately after launch – health check grace period may be too short
    • Application not ready before grace period expires – increase the grace period or fix slow startup
    • ELB health check failing – verify security group allows health check traffic from LB
    • Instances stuck in a launch/terminate loop – check application health and startup scripts
    • Instances failing system status checks – may indicate underlying hardware issues

Scaling Policy Troubleshooting

  • Scaling Not Triggering:
    • CloudWatch alarm not in ALARM state – verify metric and threshold
    • Scaling processes suspended (AlarmNotification, Launch, or Terminate processes)
    • Cooldown period active – scaling actions wait until cooldown expires
    • ASG already at maximum (scale-out) or minimum (scale-in) capacity
  • Predictive Scaling Issues:
    • Insufficient historical data (requires at least 24 hours of load data)
    • Metrics not available in CloudWatch for the prediction
    • Policy in forecast-only mode will not actually scale
  • Target Tracking Issues:
    • Metric math expression errors in custom metrics
    • Scale-in disabled unintentionally
    • Conflicting scaling policies (scale-out and scale-in triggering simultaneously – scale-out takes precedence)

Instance Refresh Troubleshooting

  • Instance refresh allows rolling updates to replace instances with new launch template versions
  • Common Issues:
    • Refresh stuck or slow – minimum healthy percentage too high, leaving no room for replacement
    • New instances failing health checks – launch template changes may have introduced issues
    • Checkpoint failure – application not ready within checkpoint delay period
    • Rollback triggered – instances launched with new configuration failing health checks
    • Cannot start refresh – another refresh or operation already in progress

Warm Pool Troubleshooting

  • Warm pools maintain pre-initialized instances for faster scale-out
  • Common Issues:
    • Instances not entering warm pool – lifecycle hook actions completing with ABANDON result
    • Warm pool instances not transitioning to InService – health check failures during transition
    • Warm pool size not maintained – check MaxGroupPreparedCapacity and min pool size settings
    • Hibernated instances failing to resume – instance type or AMI may not support hibernation

Capacity Rebalancing (Spot) Troubleshooting

  • Capacity Rebalancing proactively replaces Spot Instances at risk of interruption
  • Common Issues:
    • Frequent instance replacements – diversify instance types (recommend 10+ types) across multiple AZs
    • Replacement instances also getting rebalance recommendations – enable attribute-based instance type selection (ABS) for broader diversification
    • Capacity not maintained during rebalancing – ASG temporarily exceeds desired capacity (by design) to launch replacements before terminating at-risk instances

Zonal Shift Troubleshooting

  • Zonal shift (Amazon ARC) allows shifting traffic away from an impaired AZ
  • Common Issues:
    • Zonal shift not available – ensure ASG has zonal shift enabled (AvailabilityZoneImpairmentPolicy)
    • Instances still terminating in shifted zone – check health check behavior setting (IgnoreUnhealthy vs ReplaceUnhealthy)
    • Insufficient capacity after shift – remaining AZs must have capacity to handle full load; consider cross-AZ pre-provisioning

Troubleshooting Commands

  • Use describe-scaling-activities to retrieve error messages:
  • Scaling activities log is retained for 6 weeks
  • Check the StatusCode (Successful, Failed, Cancelled) and StatusMessage fields for details
  • Use --include-deleted-groups to view activities for deleted ASGs

Best Practices to Avoid Launch Failures

  • Use Launch Templates (not launch configurations) for access to all new features
  • Specify multiple instance types (10+) using mixed instances policy or attribute-based instance type selection
  • Configure instances across multiple Availability Zones
  • Use attribute-based instance type selection (ABS) to automatically select instance types matching compute requirements
  • Enable Capacity Rebalancing for Spot Instance workloads
  • Set appropriate health check grace period based on application startup time
  • Monitor ASG activities via CloudWatch metrics and scaling activity history
  • Use instance maintenance policy to control replacement behavior (launch-before-terminate vs terminate-before-launch)

Certification Exam Tips

  • Know the difference between launch templates and launch configurations and that launch configurations are deprecated
  • Understand InsufficientInstanceCapacity errors and the recommendation to use multiple instance types
  • Know health check types (EC2, ELB, VPC Lattice, EBS, Custom) and grace period behavior
  • Understand that scaling activities can be viewed with describe-scaling-activities API
  • Know that conflicting scaling policies resolve in favor of scale-out for availability
  • Understand instance refresh rollback behavior and checkpoint mechanisms

References