124

This IP seems to be running a service that provides a lot of useful metadata for my instance, but I'm wondering why 169.254.169.254? What's special about that IP address? And also wondering if the fact of having that IP occupied by that service I'm missing the chance to connect to a server with that IP on the internet?

AlexStack
  • 16,766
  • 21
  • 72
  • 104

1 Answers1

222

169.254.169.254 is an IP address from the reserved IPv4 Link Local Address space 169.254.0.0/16 (169.254.0.0 through 169.254.255.255). Similar to the private address ranges in RFC-1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) in the sense that this block also can't be used on the Internet, Link Local is further restricted to being unreachable via any router¹ -- by design, they only exist on the directly-connected network.

AWS needed to create a service endpoint accessible from any system and the selection of an address in this block allows it to avoid conflict with the commonly used IP address space. Clever choice.

Presumably this specific address within the block was chosen for its aesthetic appeal or being easy to remember.

Fun fact! The adjacent address 169.254.169.253 is a DNS resolver in VPC in addition to the one you're probably familiar with at offset 2 from the base of your VPC supernet. This comes in very handy for configuring software that does its own DNS lookups independent from the OS (like HAProxy), so that the DNS resolver configuration in the software doesn't need to be modified when deployed in different VPCs. There's no documented reason to believe this address represents a "different" resolver than the one within your address block, just a different way of accessing the same thing.

But wait, there's more! 169.254.169.123 provides a stratum-3 NTP time source, allowing instances to maintain their system clock time with ntpd or chrony without requiring Internet access, from the Amazon Time Sync Service. This service also uses Amazon's leap second logic to distribute any leap seconds throughout the day they occur, rather than the clock advancing from 23:59:59 to 23:59:60 to 00:00:00, which can be problematic.

¹unreachable via any router is not a hard constraint in most IP stacks, as link local addresses can be the subject of a static route, but these addresses are not generally considered routable.

Community
  • 1
  • 1
Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • 4
    > DNS lookups independent from the OS (like HAProxy) Exactly my use case! – Rory Hart Jun 17 '17 at 05:13
  • 3
    To reinforce that it's nothing AWS-specific, docs from some other cloud providers: [Vultr](https://www.vultr.com/metadata/); [Digital Ocean](https://developers.digitalocean.com/documentation/metadata/); [Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service); (Google uses `metadata.google.internal`, which I suspect resolves to the same, but I don't use it so can't verify.) – OJFord Sep 01 '19 at 11:26
  • 1
    @OJFord is correct, metadata.google.internal resolves to 169.254.169.254 furthermore, the api http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/dns-servers value returned is indeed 169.254.169.254 – rupert160 Sep 19 '19 at 00:10
  • 4
    @rupert160 yes, but the original question was about AWS. The other cloud providers, as far as I know, all followed the lead established by AWS in the use of this particular address, which has no intrinsic meaning. Copying from AWS has happened in other cases, such as Google Cloud Storage, whose XML API is so "compatible" with S3's that the [GCS "migrating" documentation](https://cloud.google.com/storage/docs/migrating) has an example of request signing including the credential scope `20190301/us-east-1/s3/aws4_request`. – Michael - sqlbot Sep 19 '19 at 00:42
  • 3
    This is the kind of quality I love about SO. Thanks! – prasanthv Feb 04 '21 at 19:53
  • One would think that instance metadata would come from the instance. But, does the use of a link-local address to obtain an instance's own metadata - rather than a loopback/localhost address - mean that the metadata is _actually coming from outside the instance?_ – XML Feb 22 '23 at 00:15
  • @XML yes, it's definitely coming from outside the instance. Everything I've seen indicates that it comes from a service running on the hypervisor. It has to come from outside, because the metadata service is how the instance learns about information that isn't on the disk -- things like its instance ID and availability zone -- something inside needs to reach outside. And instance role credentials actually come from AWS Security Token Service (STS) -- the EC2 infrastructure periodically calls STS `AssumeRole`, then makes the obtained temporary credentials available via the metadata service. – Michael - sqlbot Mar 03 '23 at 13:44