Metadata connection problem
This specific problem occurs when an AMI image is created in one subnet (let’s say 10.0.5.0/24) and it is launched in a different subnet (10.0.13.0/24). The AMI image retains the old gateway information in the route table and the instance will be unable to connect to the metadata service address 169.254.169.254. Note that this only pertains to Windows Server instances. I was not able to reproduce this problem with Linux.
How to check
First, open the command prompt and check the instance’s gateway with ipconfig command.
Ethernet adapter Ethernet 2: Connection-specific DNS Suffix . : us-west-1.compute.internal Link-local IPv6 Address . . . . . : IPv4 Address. . . . . . . . . . . : 10.0.5.17 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.0.5.1
Note the Default Gateway and check the route table with route print command. You should see something like this for Persistent Routes.
=========================================================================== Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 10.0.13.1 25 169.254.169.251 255.255.255.255 10.0.13.1 25 169.254.169.250 255.255.255.255 10.0.13.1 25 ===========================================================================
Entry for 169.254.169.254 has wrong gateway information!
How to fix
It’s quite easy to fix this issue. Update the entries with the right gateway information. Issue the following command in administrator mode command prompt.
route change 169.254.169.254 mask 255.255.255.255 10.0.5.1 metric 25 -p
Do the same for 169.254.169.251 and 169.254.169.250. I actually don’t know why these entries are there, but I’d update them just the same. The -p option at the end is for persistent setting which means it won’t be reset on reboot. Try to see if you can connect to metadata service address 169.254.169.254. If the connection fails, you have other underlying problems. Check your VPC configuration and security group settings.