如何知道機器是否是 EC2 實例

我想在作為 EC2 實例的主機上執行一些腳本，但我不知道如何確定主機確實是 EC2 實例。

我做了一些測試，但這還不夠：

• 測試二進制 ec2_userdata 是否可用（但這並不總是正確的）
• 測試“ http://169.254.169.254/latest/meta-data ”的可用性（但這總是正確的嗎？這個“神奇的IP”是什麼？）

首先，我覺得有必要發布一個新答案，因為現有答案存在以下細微問題，並且在收到關於我對@qwertzguy 答案的評論的問題後。以下是目前答案的問題：

1. @MatthieuCerda接受的答案肯定不能可靠地工作，至少在我檢查過的任何 VPC 實例上都不能。（在我的實例上，我獲得了一個 VPC 名稱hostname -d，用於內部 DNS，而不是其中包含“amazonaws.com”的任何內容。）
2. @qwertzguy投票最高的答案不適用於沒有此文件**的新 m5 或 c5 實例。**亞馬遜忽略了記錄此行為更改 AFAIK，儘管有關此主題的文件頁面確實說“……如果/sys/hypervisor/uuid 存在……”。我詢問了 AWS 支持，此更改是否是故意的，請參見下文 †。
3. @Jer的答案不一定適用於任何地方，因為instance-data.ec2.internalDNS 查找可能不起作用。在我剛剛測試的一個 Ubuntu EC2 VPC 實例上，我看到： $ curl http://instance-data.ec2.internal curl: (6) Could not resolve host: instance-data.ec2.internal 這會導致依賴此方法的程式碼錯誤地斷定它不在 EC2 上！
4. @tamale使用dmidecode的答案可能有效，但取決於您 a.)dmidecode在您的實例上可用，並且 b.) 在您的程式碼中具有 root 或sudo無密碼能力。
5. 從@spkane檢查 /sys/devices/virtual/dmi/id/bios_version的答案是危險的誤導！我檢查了一個 Ubuntu 14.04 m5 實例，並得到了bios_version一個1.0. 這個文件根本沒有記錄在亞馬遜的 doc 上，所以我真的不會依賴它。
6. @Chris-Montanaro的第一部分答案是檢查不可靠的 3rd-party URL 並whois在結果上使用在多個層面上存在問題。請注意，該答案中建議的 URL 現在是 404 頁面！即使您確實找到了有效的第 3 方服務，它也會比較慢（與在本地檢查文件相比）並且可能會遇到速率限制問題或網路問題，或者您的 EC2 實例甚至可能沒有外網訪問。
7. @Chris-Montanaro檢查http://169.254.169.254/的答案中的第二個建議要好一些，但另一位評論者指出，其他雲提供商使此實例元數據 URL 可用，因此您必須小心避免錯誤積極的一面。而且它仍然會比本地文件慢得多，我已經看到這個檢查在負載很重的實例上特別慢（幾秒鐘才能返回）。此外，您應該記住將-mor--max-time參數傳遞給 curl 以避免它長時間掛起，特別是在非 EC2 實例上，該地址可能會導致無處和掛起（如@algal 的回答）。

另外，我沒有看到有人提到亞馬遜記錄在案的檢查（可能的）文件的備份/sys/devices/virtual/dmi/id/product_uuid。

誰知道確定您是否在 EC2 上執行會如此復雜？！好的，既然我們列出了列出的方法的（大部分）問題，這裡有一個建議的 bash 片段來檢查您是否在 EC2 上執行。我認為這應該適用於幾乎所有 Linux 實例，Windows 實例是讀者的練習。

#!/bin/bash

# This first, simple check will work for many older instance types.
if [ -f /sys/hypervisor/uuid ]; then
 # File should be readable by non-root users.
 if [ `head -c 3 /sys/hypervisor/uuid` == "ec2" ]; then
   echo yes
 else
   echo no
 fi

# This check will work on newer m5/c5 instances, but only if you have root!
elif [ -r /sys/devices/virtual/dmi/id/product_uuid ]; then
 # If the file exists AND is readable by us, we can rely on it.
 if [ `head -c 3 /sys/devices/virtual/dmi/id/product_uuid` == "EC2" ]; then
   echo yes
 else
   echo no
 fi

else
 # Fallback check of http://169.254.169.254/. If we wanted to be REALLY
 # authoritative, we could follow Amazon's suggestions for cryptographically
 # verifying their signature, see here:
 #    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html
 # but this is almost certainly overkill for this purpose (and the above
 # checks of "EC2" prefixes have a higher false positive potential, anyway).
 if $(curl -s -m 5 http://169.254.169.254/latest/dynamic/instance-identity/document | grep -q availabilityZone) ; then
   echo yes
 else
   echo no
 fi

fi

顯然，您可以通過更多的備份檢查來擴展它，並包括對處理的偏執狂，例如偶然發生以“ec2”開頭的誤報/sys/hypervisor/uuid等等。但這對於說明目的和幾乎所有非病態案例來說是一個足夠好的解決方案。

$$ † $$從 AWS 支持那裡得到了關於 c5/m5 實例更改的解釋：

C5 和 M5 實例使用新的管理程序堆棧，並且相關的核心驅動程序不會像其他/舊實例類型使用的 Xen 驅動程序那樣在 sysfs（安裝在 /sys）中創建文件。檢測作業系統是否在 EC2 實例上執行的最佳方法是考慮您連結的文件中列出的不同可能性。

引用自：https://serverfault.com/questions/462903