【发布时间】：2021-10-07 02:41:34
【问题描述】：
这个 IP 似乎正在为我的实例运行 provides a lot of useful metadata 的服务，但我想知道为什么 169.254.169.254？该IP地址有什么特别之处？ 并且还想知道该服务占用该 IP 的事实是否让我错过了在互联网上使用该 IP 连接到服务器的机会？
【问题讨论】：
【发布时间】：2021-10-07 02:41:34
【问题描述】：
169.254.169.254 是来自保留的IPv4 Link Local Address 空间 169.254.0.0/16（169.254.0.0 到 169.254.255.255）的 IP 地址。与RFC-1918 中的私有地址范围（10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16）类似，在这个块也不能在 Internet 上使用的意义上，Link Local 更进一步仅限于通过任何路由器无法访问¹ - 根据设计，它们仅存在于直接连接的网络上。
AWS 需要创建一个可从任何系统访问的服务端点，并且在此块中选择一个地址可以避免与常用 IP 地址空间发生冲突。明智的选择。
大概是因为它的美学吸引力或易于记忆而选择了街区内的这个特定地址。
有趣的事实！相邻的地址 169.254.169.253 是一个DNS resolver in VPC，除了您可能熟悉的位于 VPC 超网基础偏移 2 处的地址之外。这对于配置独立于操作系统进行自己的 DNS 查找的软件（如 HAProxy）非常方便，因此当部署在不同的 VPC 中时，不需要修改软件中的 DNS 解析器配置。没有证据表明该地址代表了与地址块中的解析器“不同”的解析器，只是访问同一事物的不同方式。
但是等等，还有更多！ 169.254.169.123 提供第 3 层 NTP 时间源，允许实例使用 ntpd 或 chrony 维护其系统时钟时间，而无需访问 Internet，来自 Amazon Time Sync Service。该服务还使用 Amazon 的闰秒逻辑在它们发生的一天中分配任何闰秒，而不是时钟从 23:59:59 提前到 23:59:60 到 00:00:00，这可能会出现问题。
¹无法通过任何路由器访问在大多数 IP 堆栈中并不是硬性限制，因为链接本地地址可以是静态路由的主题，但这些地址通常不被认为是可路由的。
【讨论】：
-
> 独立于操作系统的 DNS 查找（如 HAProxy）正是我的用例！
-
为了强调它不是特定于 AWS 的，来自其他一些云提供商的文档：Vultr; Digital Ocean; Azure; （Google 使用
metadata.google.internal，我怀疑它的解析结果相同，但我不使用它，因此无法验证。） -
@OJFord 是正确的，metadata.google.internal 解析为 169.254.169.254 此外，返回的 api metadata.google.internal/computeMetadata/v1/instance/… 值确实是 169.254.169.254
-
@rupert160 是的，但最初的问题是关于 AWS。据我所知，其他云提供商都遵循 AWS 建立的领先地位，使用这个没有内在意义的特定地址。在其他情况下也发生了从 AWS 复制的情况，例如 Google Cloud Storage，其 XML API 与 S3 非常“兼容”，以至于 GCS "migrating" documentation 有一个请求签名示例，包括凭证范围
20190301/us-east-1/s3/aws4_request。 -
这是我喜欢 SO 的那种品质。谢谢！