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.
Related
I am facing this issue from yesterday. This is the exact error: Failed to start feature-config: A e2-micro VM instance is currently unavailable in the us-central1-a zone. Alternatively, you can try your request again with a different VM hardware configuration or at a later time. For more information, see the troubleshooting documentation.
I had scheduled Google Compute Engine to TURN on & off at specific time using Instance scheduler but now I am locked out of it. I cannot even create a machine image to deploy on another zone
I changed the Machine Configuration. As from your answer I could figure out that resources might not be available for the US Central Zone possibly due to traffic. I changed configuration to - n2-highcpu-2 vCPU 2 & Memory -2 GB
At the end, it seems this was a general issue that multiple users experienced in us-central1 among other regions.
In this thread more is talked and it seems it got worse during the weekend.
As some suggestions in the comments, changing the zone/region/hardware can help but not always since this also depends on any constraints you may have.
As the error suggests, there aren't any available resources in that regions. I contacted GCP support after facing the same issue and got the following response:
Google Cloud Support, : Upon further checking, the reason that the e2-medium VM instance is currently unavailable is because there are limited VMs available to a specific zone and regions. Best we can do is to try another time or select a different zone so that the VMs that you desire to use will start. Rest assured that there is nothing wrong with your account and it was on the us-central1 zone who do not have available VMs you selected as of the moment.
If possible, try deploying to a different instance. For those who need an instance in us-central1 (for Qwiklabs?) might have to wait until more instances are available.
Similar issue here, but coming from a terraform apply. I've tried multiple zones and every one says both 'e2-small' and 'e2-micro' instances are unavailable. Seems google completely fumbled the "cloud game" here since AWS doesn't have this problem EVER! (not that I like using AWS, it's just "ick" compared to google).
My AWS Cloud9 instance is stuck connecting since yesterday. It gives the error:
"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"
I have tried changing the instance type to a larger one. I have tried rebooting as well.
It started happening after I put an ENV variable that was super long into the .bashrc file.
I would greatly appreciate any thoughts on how I can fix this!
The change you made in your ENV variable is affecting the VPC configuration you have created and so you get this stuck connecting to your VPC.
My VM in google cloud can't run due to below error has shown.
"Starting VM instance failed. Error: The zone does not have enough
resources available to fulfill the request. Try a different zone, or
try again later."
Then I what to start VM from other zones by changing the zone of my VM by this method but it's required VM running.
The problem is I can't run the VM. How can I use another solution?
It looks like Google's having issues with limited External IPs. Try removing the external IP before starting the instance. Then create an external IP and attach it your instance.
You’ve just encountered a stockout issue. A Stockout means that the particular GCP datacenter in that zone has reached its resource limit.
The Google Cloud Platform team are there to make sure that there are available resources in all zones. This type of issue is rare. When a situation like this occurs or is about to occur, the team is notified immediately, the issue is investigated and quickly fixed.
I recommend deploying and balancing your workload across multiple zones or regions to reduce the likelihood of a stockout. Please review the documentation which outlines how to build resilient and scalable architectures on the Google Cloud Platform.
You may also try again later, once resources will be available again in the region.
This being said, I see that you’ve posted your question on November 9th. That was a long time ago. Can you confirm if your issue is fixed now? It is very rare for stockouts to last this long.
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.
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.