I'm really not a fan of EC2 exposing instance meta data as a RESTful HTTP API running on Local-Link IP addresses. If its only supposed to be queried locally, why aren't these just environment variables? Perhaps they are dynamic and that won't work but come on!
At the very least, run it on localhost:10101 or something. Don't give us another range to have to filter!
One of the biggest selling points of EC2 (at least for me) is that you get a real VM with a real kernel and userspace, and not some "user-friendly" thing the provider made with loads of alien services running as root. So EC2 can't define vars inside your instances + as you said, they can be dynamic.
localhost:SOMETHING will also not work for same reason - they would need to run a service inside your instance.
There is one more popular solution to the metadata problem - providing it as an emulated cdrom, which would be also vulnerable in this case. And it can't be dynamic.
That IP for the metadata is internal to Amazons AWS. Under normal circumstances it isn't exposed to the outside network. Because Pocket is remembering URLs and fetching them for us, it leaks it's own private network in the responses.
Both of those solutions require Amazon to do "something" to the instance itself and thus limit the kinds of machines you can run on EC2. Custom kernels, FreeBSD, etc..
Their current metadata approach works across OSes.
And, yes, the data are dynamic. Things like AWS access keys change over time and can be accessible via the metadata if you've given the instances IAM profiles. I'm surprised the author didn't mention this.
I agree that the approach feels uncomfortable in general but it seems like the best approach for the functionality they wanted.
At the very least, run it on localhost:10101 or something. Don't give us another range to have to filter!