Find a missing EC2 instance in AWS using just the command line
Today we found ourselves in a position where we had a Windows server – with only the Server Core experience installed – somewhere in EC2 but we could not figure out what AWS account it actually lived in. This meant that we were limiting to finding the missing EC2 instance in AWS using just the command line.
Most cloud providers offer an instance metadata endpoint that you can query to get some basic info about the instance itself. It usually operates on http://169.254.169.254 (that IP is not a placeholder, it’s literally the IP you query) and AWS is no different. As per the AWS documentation, if you hit http://169.254.169.254/latest/meta-data/ you can get some information about the running instance which was exactly what we needed.
The first thing we knew is that we needed to be in PowerShell, since the basic Windows command line doesn’t have an HTTP client.
Microsoft Windows [Version 10.0.20348.1070]
(c) Microsoft Corporation. All rights reserved.
C:\Users\nexxai>powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows
PS C:\Users\nexxai>Next, we tried to use the Invoke-WebRequest cmdlet, except being Server Core, it did not have the Internet Explorer (lol) components installed that this cmdlet apparently needs.
Thinking on our feet, we considered that maybe the Invoke-RestMethod cmdlet didn’t have the IE dependency since it was strictly used for REST-based calls and may have be implemented without any IE components. Success.
PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/We tried a couple of different endpoints, but then saw the iam entry and gave it a shot.
PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/iam/
info
security-credentials/Then naturally we checked out info.
PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/iam/infoI can’t share the results of this command for obvious reasons, but contained within the results was the ARN of the IAM role that the EC2 instance was associated with, which – and here’s the important part – includes the account number! Yes!
After some more digging, it turns if you have the AWS CLI installed on the VM (unsure if this is installed by default), you can also run aws sts get-caller-identity which will show the account the instance is running in.
Once we were able to get the account number, we were quickly able to locate the rogue instance and deal with the original problem we were searching it out for. I hope you never have to try and find a missing EC2 instance using just the command line, but if so, hopefully we’ve just made it a little easier to do so.