Timeout when trying to retrieve EC2 instance-id metadata from within it - amazon-web-services

I'm launching a Windows 10 EC2 instance and trying to retrieve it's instance-id from the CMD with the command:
curl http://169.254.169.254/latest/meta-data/instance-id
This worked until yesterday, but now it fails every time, raising a Timeout error.
curl: (7) Failed to connect to 169.254.169.254 port 80: Timed out
I've looked up aws's documentation about retrieving EC2 metadata and didn't found anything regarding an expiration time for the retrieving attempt. Also, I've tried to create an AMI from my instance and launch a new instance based on this AMI to try some sort of "refresh" of a possible expiration time, and it didn't worked.
I've searched within the IAM Roles for something related to retrieving metadata permission, but nothing seems to fit my issue.
I've also tried the answers from here but nothing was specific enough to my problem.
What could have happened? This worked for about two months straight and suddenly it stopped working.
Workaround for fixing
Another post, regarding a similar problem, got an answer that fixed my problem.
I simply ran C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 and the script applied the default specifications of a newborn EC2 windows instance. I still don't know why this problem happened, but this solution works for someone that doesn't have anything to loose on configuration specifications.

From the workaround that you shared, it seems the reason why you were not able to get the Instance ID was somehow the routes for your Instance got misconfigured. To retrieve Instance ID from the metadata, the route 169.254.169.254 must point to the right gateway of the Instance. This problem generally occurs with Windows Server 2016 or above when you try to launch an Instance from a custom AMI, in a subnet which is different from the parent Instance from which the AMI was created.
When you ran the command, it scheduled the InitializeInstance.ps1 script, and during the next boot it re-configured the routes.
In, future if you see any such issue, make sure the IP 169.254.169.254 is pointing to the correct gateway, which you can check using the command ipconfig /all and route print commands, in case you find that the routes are mis-configured, you can use the route delete and route add commands with proper parameters to make the routes correct or simply schedule the InitializeInstance.ps1 script, which will correct the routes when the Instance boots up the next time.
Please refer: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch.html

Related

Unable to start command: error impersonating: Logon failure: the user has not been granted the requested logon type at this computer

I deployed SSM agents to a few instances, some Linux and some Windows- This was done last week and I was able to connect to all of them. Now it's a few days later and I'm trying to connect to them again using SSM, I can connect to the Linux instances fine, but when trying to connect to the windows instances I get this error
Unable to start command: error impersonating: Logon failure: the user has not been granted the requested logon type at this computer.
I'm using a Mac, so is this causing an issue somehow? When I first deployed SSM to these Windows instances I tested it and I was able to connect to them. Now it's a few days later and I'm getting that error.
I redeployed those instances to see if SSM would work and I was able to connect to them again- today, I'm getting the exact same error for the Windows instances again. I can't find anything in their Docs or online as to why the Windows instances are giving this error
I'm not an Active Directory expert, but it ended up being an issue with Active Directory. The windows instances were joined to a domain and when I launched the new instances with the SSM agent, DNS was still pointing to the old instances IP addresses, so that's why it was having trouble connecting. Once I deleted the old records and replaced them with the new IPs, it works fine.

AWS EB can't talk to the app servers... what could block that

We had a working env yesterday morning. One person was working with some VPC peering stuff. And somehow it seems blocked the ELB from being able to talk to the application servers. So we can't deploy.
We get this error
Command failed on instance. An unexpected error has occurred [ErrorCode: 0000000001].
And EB can't retrieve any logs from the app server either. So clearly it is getting blocked. The IAM of the instance has AWSElasticBeanstalkWebTier and is the same IAM used in another env that works.
Also, I can RDP to the app instance from my laptop. Though I added my IP to one of the security groups for the instance. I audited the SG's for the working env, and don't see anything specific for EB.
Everything points to something with the VPC... but what should I look at?
So turns out that that error message doesn't always mean it can't talk to the instance. We had updated the AMI a while back and used the wrong one... it wasn't compatible with the platform. So nothing worked right, including getting the logs. So the fix was to sync up the AMI and the EB platform.

Creating a ec2 server instance with the name tag

Our project creates aws ec2 virtual server using com.amazonaws.services.ec2.model.RunInstancesRequest from the aws java sdk. For now, to give a name to each instance, we sleep for 5 seconds and then create a com.amazonaws.services.ec2.model.Tag to apply using a com.amazonaws.services.ec2.model.CreateTagsRequest.
It works, most of the time. Sometimes we have servers without names and need to recreate them manually. I've been looking at the documentation but couldn't find a straightfoward way to give the server a name directly in the runInstances request.
Am I missing something?
You can pass tagSpecifications to the run instances request.

Unable to SSH into my EC2 instance from a different computer

A little backstory, I have an AWS instance made with Bitnami that I set up on my Windows Machine back home. I am currently out of the country and have no way to access that machine at the moment. One month later, I visit the website getting a 500 error and (only my Macbook on me). I've tried to SSH into it from my Macbook and no luck. I get the error:
Username is not in the sudoers file. This incident will be reported.
I've also tried another way to SSH into my aws but then I just get
Permission denied (publickey).
I do have the public/private keys I made with me so I am not sure if I had to set up some additional permissions to SSH from a different computer. On top of that, I got an email stating that someone attempted to access remote hosts on the internet without authorization. If I visit my Public IP address of my instance, it goes straight to a spam page.
At this point, I am not sure if I am just missing something in my steps or have missed a step. If someone can help me, I would really appreciate it.
Is there some way to get my instance back up and running? If not, is there some way I can back up the wordpress files on that instance that's down and use it to create another one on my Macbook currently? Please let me know.
If you have the private key that your AWS instance has been installed with, place the key in ~/.ssh .
Then, run the following command to set the permissions of the key to read and write only to your user (it's a mandatory step):
chmod 600 ~/.ssh/keyname
Then, run the following command to connect to your instance:
ssh -i ~/.ssh/keyname user#instance_ip
And it should connect successfully.
If you're not sure which user to connect to and you have access to AWS EC2 Console, then look for that server, right-click it and choose "Connect" and it will usually show the correct user to use when connecting to it by SSH.

CloudFormation template to bring up EC2 instance

Using CloudFormation template, I brought up a Windows 2012 EC2 instance. Instance came up fine. I read that metadata related to this instance is all recorded in the Ec2config logs which is in one of the sub-folders of C:\Programfiles\Amazon\ directory.
Following are the steps that I am doing after EC2 instance comes up:
Rename the Administrator password (which doesn't work yet).
Set the time zone
Rename the hostname
Adding that server to the domain controller.
There should be some kind of logs on that EC2 instance about all these steps right? However, I can't find any. Any suggestions where I should be looking for the logs please?
You need to run cloud-init scripts to achieve all the tasks. I recommend writing PowerShell scripts for this.
Just refer the below repo, you will find useful template and scripts which do same activities.
https://github.com/aws-quickstart/quickstart-microsoft-sql