AWS Windows EC2 instance does not recognize assigned IAM role
Solution 1:
The IAM role does not get bundled with your AMI.
So when you launch your new EC2 instances from your AMI, you must assign the IAM role to the new EC2 instances that are launched. Without the role assigned at launch or afterwards, the CLI cannot find the credentials.
Solution 2:
I had the same problem recently with a Windows EC2 instance deployed from my own AMI. As @Kugel (https://serverfault.com/users/138998/kugel) has mentioned in their answer (Previous answer of this), one can see that the NextHop values when is executed the Get-NetRoute command doesn't changes in the new instance, and the instance remains the previous values for the existent network configurations in the base instance from where the AMI was generated.
Then, to resolve this issue, I have created new Net Routes with the new NextHop values and deleted the oldest ones. Taking as example the output given by @kugel, the creation of the new routes will be:
Set-NetRoute -InterfaceIndex 3 -DestinationPrefix "169.254.169.254/32" -RouteMetric 15 -NextHop 10.2.6.1
Repeat the previous command for the rest of the Destinations prefixes (169.254.169.123/32, 169.254.169.249/32, 169.254.169.250/32, 169.254.169.251/32 and 169.254.169.253/32)
Once the new net routes has been created, you can delete the oldest with the command:
Remove-NetRoute -NextHop 10.2.4.1
The previous command will delete all occurrences that has as NextHop that IP.
References for commands:
Set new route: https://docs.microsoft.com/en-us/powershell/module/nettcpip/set-netroute?view=win10-ps
Delete routes: https://docs.microsoft.com/en-us/powershell/module/nettcpip/remove-netroute?view=win10-ps
Solution 3:
I found this question while having the same issue. What ended up solving it for me is this answer which I have quoted below so as to not have an answer with just a link.
There is a script call InitializeInstance.ps1 that resets some configuration information.
For example, if the instance has changed subnets it might not work correctly due to cached routing rules. The InitializeInstance.ps1 can correct this.
As the top comment on that answer points out:
In Windows Instance, this script is located here: C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1