- Newest
- Most votes
- Most comments
Network connectivity is always a 2 part problem.
-
Network path - is there a route from where you're initiating the connection to the destination? You may want to check your route tables at the subnet level, transit gateway level (if applicable) and if you're connecting from on-premises: local router route tables. Think of this as whether there's a paved road between the two systems.
-
Firewalls - they're everywhere... think of these as checkpoints where your packets "stop and show their papers..." your packets either pass through or get dropped. Some things to check:
- does your destination security group permit the incoming connection? does your source have an SG? does it permit the outgoing connections to the destination?
- does either operating system built-in firewall allow both outgoing connections to the destination and does the OS on the destination permit incoming connections?
- do you have a custom NACL assigned to your subnets (from where the connection originates and the destination subnet)? If so, rules must be defined in both directions...
- if you're connecting from on-premises, is there a firewall that requires a rule to allow you to connect to the cloud resource?
It's also possible that the copy may need some configuration within the app in order function, like binding the web server to a new IP...
I reviewed, I try to connect from on-premise, no firewall problem
Are you placing the new instance in the same subnet?
Also, have you tried connecting to the instance using Session Manager? https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-prerequisites.html
Does your instance have a public IP address?
Finally, I made a new fresh instance, thank for your time
What was the issue?
Hello,
From the steps you've outlined, it seems like you've followed the general process to create an AMI from an existing instance and launch a new instance from that AMI. However, there are a few factors that can cause the "Instance reachability check failed" status:
It's advisable to first check the Security Groups and the Network ACLs. If the configurations look good, inspect the instance system logs to identify any potential boot or initialization issues.
- Security Groups: Ensure that the security groups associated with the new instance allow the necessary inbound traffic (e.g., SSH for Linux instances, RDP for Windows instances).
- Network ACLs: If you're in a VPC, ensure the Network Access Control Lists (NACLs) are not blocking the traffic.
- Private IP Addressing: If the original instance was in a VPC and had a private IP, make sure that the new instance is also in the correct subnet and has a reachable IP.
- Elastic IPs: If the original instance was associated with an Elastic IP, make sure you haven't unintentionally associated the same IP to the new instance.
- Instance Initialization: Sometimes, instances can take a bit longer to initialize. You can check the instance's system log through the AWS Management Console for any issues during boot.
- Root Volume & Boot Configuration: The AMI captures the root volume. If there were any issues or misconfigurations on the original instance's root volume, they would be replicated in instances created from that AMI.
- EBS Volume Size: Sometimes, if you've reduced the EBS volume size while launching the new instance from the AMI (as compared to the original instance's root volume size), the new instance might not boot correctly.
- Key Pair: Ensure you've selected the right key pair when launching the new instance, and that you have access to the private key of that pair.
- User Data Scripts: If there were any user data scripts attached to the original instance, make sure they're compatible and don't cause issues on the new instance.
- Platform & AMI Compatibility: Ensure you're using an instance type that's compatible with the AMI. Some older AMIs may not be compatible with newer instance types and vice versa.
- Check Instance Console Output: The AWS Management Console allows you to view the console output of an instance. This can give insights into what might be going wrong during the boot process.
- Storage Configuration: If the original instance had multiple EBS volumes or specific storage configurations, ensure that the new instance mirrors this setup if it's critical for the application's functionality.
After trying out these suggestions, please keep me updated on your progress. I'm here to continue assisting you as you work through this issue.
Same Security Groups Same Network ACL No elastic IP Instance Initialization i can't connect to instance then i can't see log (EC2 serial console ask user and password but i don't have password I use keys Root Volume & Boot Configuration, original instance boot without problems EBS Volume Size same size as original instance Platform & AMI Compatibility same instance type as original one
User Data Scripts no user data scripts
Key Pair No response from server then it don't reach to check pair keys
Finally, I made a new fresh instance, thanks for your time
Relevant content
- asked 8 months ago
- asked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 10 months ago
What was the issue ultimately?