I can successfully create a new EC2 instance using an AMI. Soon after launching, the EC2 is viewable through the browser and SSH. Consistently, if I try to view it 10 minutes after launch, the EC2 is completely inaccessible. This is reproducible many times and even happens with a static IP address.
What could be causing this?
Perhaps your instance is not providing your AMI what it requires. What AMI are you using, and what kind of instance are you using to host that AMI? Also, does the machine slow down when you try to access it while being connected to it? Or is it just unreachable? I will edit this post adding more information to your issue as soon as you answer to me. ( I cannot add a comment to the OP because I lack the reputation to do so; I hope you understand this ).
edit1: That AMI has quite low requirements. Could you please attach all the information required (together with the output of the required commands like ps, free… etc) in this section of the Bitnami Troubleshooting guide?
Performance TroubleShooting
The most likely thing I can think of is that your region is experiencing technical issues, though I can't prove it in any way. Hopefully, the output you provide after following that guide will guide us in the right direction.
Related
I feel like this is a beginner question, but after messing with it for days I'm completely stumped.
I set up an instance on Amazon AWS last year, and I'd like to SSH into the instance to upgrade some software. I am unable to find the original .pem file anywhere, and everything I find to try to solve the problem — including these directions — refer to selecting the running instance on my EC2 Dashboard.
However, when I log in as a root user, it shows there are no running instances. By default it comes up as N. Virginia, but when I check the other US locations none of them show any running resources. My instance's address (the link I use for mySQL and phpMyAdmin, for example) is in the form of ec2-XXX-XXX-XXX-XXX.ca-central-1.compute.amazonaws.com, if that makes any difference.
Any ideas on next steps? I have all the data on the running instance backed up so I can recreate things as necessary. I admit that I'm a beginner with AWS (obviously) but I super-pinky-promise to store my .pem file in a safe place next time...
By default it comes up as N. Virginia, but when I check the other US
locations none of them show any running resources. My instance's
address (the link I use for mySQL and phpMyAdmin, for example) is in
the form of ec2-XXX-XXX-XXX-XXX.ca-central-1.compute.amazonaws.com, if
that makes any difference.
Your instance is running in the AWS Canada region, as indicated by the region name ca-central-1 in the address, which is why you aren't seeing it in any US region.
I have created an environment in AWS Cloud9 with a Python Lambda function.
This was working fine and for several days I was adding functionality.
However one day the environment failed to open. After several minutes of loading it displayed an error message:
This is taking longer than expected.
If you think there might be an issue, contact AWS Support.
It might be caused by VPC configuration issues.
Please check documentation:
https://docs.aws.amazon.com/cloud9/latest/user-guide/vpc-settings.html?icmpid=docs_ac9_console
I looked at the suggested link, but I don't think the VPC is the issue. I didn't make any changes to it. Moreover I am able to make new environments and open them.
Any ideas how to solve this?
Turns out the problem was the default t2.micro (1 GiB RAM) instance that is used to run Cloud9. I was probably running out of memory. Moving my environment to t2.small (2 GiB RAM) solved the problem.
Documentation on moving environments:
https://docs.aws.amazon.com/cloud9/latest/user-guide/move-environment.html
I had the error message:
"This is taking longer than expected. The delay may be caused by high CPU usage in your environment, or your T2 or T3 instance is running out of burstable CPU capacity credits, or there are VPC configuration issues."
What I did to solve it was to have my internet gateway attached to a VPC and for that VPC to have a public subnet.
I found this link to be useful to help solve this issue particularly when it states the
VPC requirements for AWS Cloud9: https://docs.aws.amazon.com/cloud9/latest/user-guide/vpc-settings.html?icmpid=docs_ac9_console
I agree with the answer above but just to expand with details on what I did:
I created a VPC attached to an Internet Gateway
create a route table and associate with subnet
Route table with routing to the subnet (making it public) and another routing to the internet gateway
This solved my problem.
My solution was different:
I changed the Region to Ohio from N. Virginia and that fixed the problem. But, it could be timing issue where N. Virginia was having problem.
There might have some processes hanging that will blew up memory.
Reboot the instance and try reloading the environment.
I've tried using Cloud9 in my root account with the default VPC and this works great. I love it. However, that's not very secure.
When I tried simulating a more realistic scenario--logging in as an IAM user with Cloud9administrators policy applied, it seemed to allow me to create a C9 environment, but the instance never seemed to actually get going. It just timed out with the message
"This is taking longer than expected. If you think there might be an
issue, contact AWS Support. It might be caused by VPC configuration
issues. Please check documentation."
This is pretty much a show stopper. Is there any way around it? I've also tried using a bigger instance size--small, but this doesn't seem to change anything.
I also noticed that I seem to get similar errors if I create a C9 environment in another VPC (public subnet, so it should be all good but it's not).
I've tried different configurations for this:
In a new VPC (with settings to match)
Default VPC
Different regions: Oregon and North VA (2 big regions which support C9)
My conclusion from this is that it seems to take a long time to spin up even in different environments. It would be helpful if I could get 'gold settings' that are confirmed to work in all situations. In the meantime, I'm planning to test EC2 instance configurations.
In a similar case
When I Changed The Browser (e.g. Safari TO Chrome)
The Message (This is taking ...) clearly disappeared .
I don't have any idea about the reason why Browser_exchange works.
Found myself in a similar position.
Turns out I didn't have an internet gateway attached to the VPC. Further more, the route table associated with the VPC needed a new route for 0.0.0.0/0 that used this gateway.
This finally solved the connection issue.
Hope this helps!
Thanks but the answer turned out to be quite simple actually: AWS doesn't support the default C9 instance type in all its AZs (and doesn't let you know this when you create an environment). If you are unlucky enough to setup your network in an AZ which doesn't support the C9 instance you choose, even if it's the default type, then everything looks OK, but when you try to spin up your C9 environment it will mysteriously error out with little feedback to the user (except for an occasional sad trombone sound effect playing faintly in the background). The answer is to verify that the AZ you choose for your network supports the instance type you select for C9.
Newbie to Amazon Web Services here. I launched an instance from a Public AMI and found that I could not ssh into the instance - I received the error "Connection timed out." I checked the security groups to verify that Port 22 was associated with 0.0.0.0/0. Additionally, I checked the route tables to verify that 0.0.0.0/0 is associated with target gateway attached to the VPC.
I find that only 1/2 status checks have passed - the instance status check failed. I have tried stopping and starting the instance as well as terminated and launching a new instance, both to no avail. The error that I see in the system log is:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1).
From this previous question, it appears that this could be a virtualization issue, but I'm not sure if that was due to something I did on my end when launching the instance or something that occurred from the creators of the AMI? Ec2 1/2 checks passed
Any help would be appreciated!
Can you share any more details about how you deployed the instance? Did you use the AWS Management Console, or one of the command line tools or SDKs to deploy it? Which public AMI did you use? Was it one of the ones provided by Amazon?
Depending on your needs, I would make sure that you use one of the AMIs provided by Amazon, such as Ubuntu, Amazon Linux, CentOS, etc. Here's the links to the docs on AMIs, but you can learn quite a bit by just searching for images. Since you mentioned virtualization types though, I'd suggest reading up briefly on the HVM vs. Paravirtual virtualization types on AWS. Each of the instance types / families uses a certain virtualization type, which is indicated in the chart on this page.
Instance Status Checks
This documentation page covers the instance status checks, which you'll probably want to familiarize yourself with. It's entirely possible that shutting down (not restart, but shutdown) and then starting the instance back up might resolve the instance status check.
Spot Instances - cost savings!
By the way, I'll just mention this since you indicated that you're new to AWS ... if you're just playing around right now, you can save a ton of cost by deploying EC2 Spot Instances, instead of paying the normal, on-demand rates. Depending on current rates, you can save more than 50%, and per-second billing still applies. Although there's the possibility that your EC2 instance could get "interrupted" based on market demand, you can configure your Spot Instance to just "Hibernate" or "Stop" instead of terminating and relaunching. That way, your work is instance state is saved for when it relaunches.
Hope this helps!
1) Use well-known images or contact with the image developer. Perhaps it requires more than one drive or tricky partitioning.
2) make sure you selected proper HVM/PV image according to the instance type.
3) (after checks are passed) make sure the instance has public ip
I have been struggling with this since last 2 days - A. Trying to create AWS Spot Instance with Deep Learning AMI for Linux (free).
B. Upon launching EC2 Instance it says Spot Instance request successfully created but it fails to create the instance.
C. Using Spot Fleet role, and later have been trying to change it to provide Admin access to this role through Policies.
However, the instance is never created and in the History tab I see Event Type = fleetRequestChange goes from Submitted, active, cancelled_terminating within a minute and later cancelled.
I have been reading through its documentation but don't see a reason for it to fail. Verified the Region and AMI as well. Tried changing bid price and with default recommended option as well. But nothing seems to work.
This is the link I'm referring - AWS setup for Deep Learning
Please skip the initial portion of getting credits and you can directly jump to EC2 instance configuration setup.
Kindly help! I am unable to proceed for the past 2 days.
Thank you!
It worked perfectly fine for me.
Launched the Deep Learning AMI (ami-df77b6a7) in the Oregon region
Spot pricing as documented in the article you referenced
I could ssh into the instance after it launched
One thing you could check... Click the Limits link in your EC2 console to confirm that you can launch this type of instance.
Mine said:
Running On-Demand g2.2xlarge instances: 5