I have a few EC2 t2 instances, some of them are micro, and some are small and medium. All of these EC2 machines are accessible on port 22 via SSH.
Following are the specifications of my t2 machines:
OS Ubuntu 14 or Ubuntu 16
EBS attached
Type classes are t2 micro, small, medium
SSH access is given via port 22 in security group inbound rules.
I have decided to upgrade these machines to t3 or t3a class instances to save some cost. I have followed these steps as per the documentation:
Stop the instance
Instance Settings -> Change Instance type to t3
Start the Instance
Everything works fine, no error anywhere in these 3 steps. But after the instance is in the Running state with both system and instance checks passed, I am not able to SSH on these machines. Error is
ssh: connect to host machine_ip_here port 22: Connection refused
Then I tried the following methods:
Revert the class type from t3 to t2 again, and SSH starts working.
Created a new t2 machine with the latest OS (Ubuntu 22) and upgrade that to t3, and SSH was working fine after the upgrade.
Created a new t3 machine, and verify SSH is working, detach its EBS, and then detach the root EBS of my t2 machine and connect it to the t3 new machine, SSH stop working.
What exactly is missing here?
Restarting a EC2 instance might make this EC2 instance's IP change, please check if IP is the same first.
Before any actions, I would check the Instance log screenshot to verify that the instance boot process finished successfully. Also, check compatibility to understand if your resizing options make sense https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/resize-limitations.html
When encountering the issue of not being able to SSH into an EC2 t3 instance after upgrading from t2, two things need to be checked:
Security group rules: Verify that the inbound rules in the security
group allow access on port 22 from the new IP address.
ENA drivers: Ensure that the Elastic Network Adapter (ENA) drivers
are enabled.
In general, I suggest checking these two troubleshooting articles to get a better idea what might go wrong with boot process.
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-status-check-failure/
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-linux-status-check-failure-os-errors/
Related
The network is working before and I have not change anything on vm. After few months, I can not access the vm instance.
The vm instance is running
I will get "Request timed out" when ping to external network ip address.
I can not access SSH. The SSH port was open properly.
When troubleshooting my connection status of SSH in browser, it is stuck on Network status.
What should I do to know the reason of problem? After I restart the vm instance few times, it will running normally for a period, but the problem will appear again.
Any idea to make sure the vm instance will not disconnect from external network with this reason again?
Here are the resource consuming of my vm
In this case, VESTACP minimum system requirements for VM instances should be okay. But you can also consider the workload process for your VM instance.
I recommend switching to a higher N1 machine types to provide good performance for the workload and machine requirements.
I have an Elastic Beanstalk application running for several years using an RDS database (now attached to the EB itself but set up separately).
This has been running without issues for ages. There's a security group attached to the load balancer, that allows traffic on port 5432 (postgreSQL).
Now I've set up a new environment which is identical, but since I want to use Amazon Linux 2, I cannot clone the existing environment (a cloned environment works as well, BTW). So I've carefully set up everything the same way - I've verified that the SG:s are the same, that all environment properties are set, that the VPC and subnets are identical.
However, as soon as my EB instances try to call RDS, it just gets stuck and times out, producing a HTTP 504 for the calling clients.
I've used the AWS Reachability Analyzer to analyze the path from the EB's EC2 instance to the ENI used by the RDS database instance, and that came out fine - there is reachability, at least VPC and SG-wise. Still, I cannot get the database calls to work.
How would one go about to debug this? What could cause a postgresQL connection with valid parameters, from an instance which is confirmed to reach the RDS ENI, to fail for this new instance, while the existing, old, EB application still runs fine?
The only differences in configuration are (new vs original):
Node 14 on Amazon Linux 2 vs Node 10 on original Amazon Linux ("v1")
Application load balancer vs classic load balancer
Some Nginx tweaks from the old version removed as they weren't compatible nor applicable
If the path is reachable, what could cause the RDS connectivity to break, when all DB connection params are also verified to be valid?
Edit: What I've now found is that RDS is attached to subnet A, and an EB having an instance in subnet A can connect to it, but not an instance in subnet B. With old EBs and classic load balancers, a single AZ/subnet could be used, but now at least two must be chosen.
So I suspect my route tables are somehow off. What could cause a host in 10.0.1.x not to reach a host in 10.0.2.x if they're both in the same VPC comprising of these two subnets, and Reachability Analyzer thinks there is a reachable path? I cannot find anywhere that these two subnets are isolated.
check the server connection information
nslookup myexampledb.xxxx.us-east-1.rds.amazonaws.com
verify information
telnet <RDS endpoint> <port number>
nc -zv <RDS endpoint> <port number>
note: keep in mind to replace your endpoint/port to your endpoint available in database settings
Launching an AWS EC2 instance seems quite straightforward although when it comes to connecting to the newly launched instance things get sticky. The process for connecting to an instance proposed by such a tech giant is very counter-intuitive.
As a short reminder I should add that an "instance" is technically a virtual machine running on Amazon's Elastic Compute Cloud (EC2), for more info one could have a look at this link.
The ec2 instance referred to in this discussion is Ubuntu Server 20.04 LTS (HVM).
The instruction for working with EC2 Linux instances is given here.
AWS EC2 proposes three different ways of connecting to an instance:
EC2 Instance connect (browser-based SSH connection),
Session Manager
SSH Client
Now with regard to connecting to the above-mentioned instance there are only certain connections that establish correctly and the rest of the proposed methods fail, here is the list of connection successes and failures :
Ubuntu instance, security group source "Custom=0.0.0.0/0", Connection establishes using both EC2 Instance Connect (browser-based SSH connection) and SSH client.
Ubuntu instance, security group source "My IP=$IP", Connection establishes only using SSH client (terminal on Ubuntu and PuTTY on windows) and not using EC2 instance connect.
Both above cases have been tried on Ubuntu 20.04 and Windows 10 as local machine and the problem remains similar on both machines. I went through most of the failure cases discussed in the troubleshooting documents proposed here and verified them on my instance. Yet the problem persists. I should also add that I never tried "session manager" connection method although opening its tab already would give some info about "not installed" agents and features.
Any idea regarding this problem? Somebody out there facing the same issue?
From Docs
(Amazon EC2 console browser-based client) We recommend that your instance allows inbound SSH traffic from the recommended IP block published for the service.
Reason for this -> EC2 Instance Connect works by making an HTTPS connection between your web browser and the backend EC2 Instance Connect service on aws. Then, EC2 Instance Connect establishes a "mostly normal" SSH connection to the target instance in other words the request is going from backend ec2 instance connect and not your browser that is why it needs IP address from accepted ranges of that region .
Browser based EC2 Instance Connect uses specific IP ranges for browser-based SSH connections to your instance. These IP ranges differ between AWS Regions. To find the AWS IP address range for EC2 Instance Connect in a specific Region, use the following( just replace your region with your region) ( for Linux required curl and jq as prerequisite)
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="Your region") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix'
whatever the value is returned just add up to your security rule and it will work.
Ubuntu instance, security group source "Custom=0.0.0.0/0", Connection establishes using both EC2 Instance Connect (browser-based SSH connection) and SSH client.
this works because 0.0.0.0/0 allows connection from all the IP ranges( which includes your region IP too).
for more details try reading this troubleshoot
About 6 months ago I created an AWS EC2 instance to mess around with on the free tier. After months of having no issues remoting into my AWS EC2 server, I've recently been unable to access it via SSH. I am using the following command:
ssh -i my-key-pair.pem ec2-user#ec2-**-**-***-***.us-****-*.compute.amazonaws.com
...and after a minute or two, am getting this response
ssh: connect to host ec2-**-**-***-***.us-****-*.compute.amazonaws.com port 22: Operation timed out
What's strange is that
1) I can read and write to my RDS database just fine
2) I can ping into the server
3) My port 22 is open
4) The instance is running and healthy
5) In the Inbound section of the security group of the EC2 server it allows for all traffic and SSH from any location via port 22.
6) I'm using the same key-pair as always
I went through this documentation (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) and can confirm that the VPC, subnet, network ACL and route tables all line up (I haven't changed anything with those since the SSH stopped working). Any insight would be extremely helpful!
Sometimes the instance fails, you can check the screen of it via AWS
console.
Run another instance in the same security group and try to
connect to it and then from there to your original one - to verify if
ssh is still open (even if you do not have the ssh key, the error
will not be 'timeout')
You can create a snapshot of your instance and
attach it as another volume in a new one and you can investigate
logs, maybe something went wrong.
You can restart the instance, if
for example i ran out of memory it will most likely work after the
reboot (hopefully for a long enough time for you to investigate).
You can contact AWS support.
I'm trying to connect to a Windows instance in EC2 through RDP but it gives me the message
Remote Desktop to server is not enabled
The remote Computer is turned off
The remote computer is not available on the network.
The weird thing is that the connection worked fine last week and nothing has changed.
The instance can be reached through a VPN connection. I think this is the problem because I have read many posts and everything seems setted up correctly (for example the RDP port on the security group and other things)
Hope someone can help me.
As you have quoted it worked last week but now, these are the things which you can check
Your public IP may be changed i.e. In the RD port - IP Access for the Instance in Security Group; RD port could have been to your old IP and now your IP could have been changed, recheck your public IP and verify that against that in SG of the Instance
As it is from VPC, the Security Group of the Instances can be completely changed / RD rules removed
Your instance's Firewall is enabled and blocking
Your corporate firewall is blocking to connect to your instance.
Attach an Elastic IP and re-check.