Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwenden von Instance Metadata Service for Snow mit EC2 Amazon-kompatiblen Instances auf einem Snowball Edge
<a name="imds"></a>

IMDS for Snow bietet den Instance Metadata Service (IMDS) für EC2 Amazon-kompatible Instances auf Snow. Instance-Metadaten sind Kategorien von Informationen über Instances. Dazu gehören Kategorien wie *Hostname*, *Ereignisse* und *Sicherheitsgruppen*. Mit IMDS for Snow können Sie Instance-Metadaten verwenden, um auf Benutzerdaten zuzugreifen, die Sie beim Start Ihrer Amazon EC2 -kompatiblen Instance angegeben haben. Sie können beispielsweise IMDS for Snow verwenden, um Parameter für die Konfiguration Ihrer Instance anzugeben, oder diese Parameter in ein einfaches Skript aufnehmen. Sie können generische Dateien erstellen AMIs und Benutzerdaten verwenden, um die beim Start bereitgestellten Konfigurationsdateien zu ändern.

Informationen zu Instanz-Metadaten und Benutzerdaten sowie EC2 Snow-kompatiblen Instances finden Sie unter [Unterstützte Instanz-Metadaten und Benutzerdaten](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html) in diesem Handbuch.

**Wichtig**  
Sie können nur innerhalb der Instance selbst auf Instance-Metadaten und Benutzerdaten zugreifen. Die Daten sind nicht durch Authentifizierungs- oder kryptografische Verfahren geschützt. Jeder, der direkten Zugriff auf die Instance hat, und möglicherweise auch jede Software, die auf der Instance läuft, kann deren Metadaten einsehen. Daher sollten Sie sensible Daten wie Passwörter oder langlebige Verschlüsselungscodes nicht als Benutzerdaten speichern.

**Anmerkung**  
Die Beispiele in diesem Abschnitt verwenden die IPv4 Adresse des Instanz-Metadatendienstes: 169.254.169.254. Wir unterstützen das Abrufen von Instanz-Metadaten unter Verwendung der Link-Local-Adresse nicht. IPv6 

**Topics**
+ [IMDS-Versionen auf einem Snowball Edge](imds-versions.md)
+ [Beispiele für das Abrufen von Instanz-Metadaten mit IMDSv1 und IMDSv2 auf einem Snowball Edge](imds-code-examples.md)

# IMDS-Versionen auf einem Snowball Edge
<a name="imds-versions"></a>

Mit IMDS Version 2 oder IMDS Version 1 können Sie von einer laufenden Instanz aus auf Instanz-Metadaten zugreifen:
+ Instance Metadata Service Version 2 (IMDSv2), eine sitzungsorientierte Methode
+ Instance Metadata Service Version 1 (IMDSv1), eine Anfrage-Antwort-Methode

Je nach Version Ihrer Snow-Software können Sie IMDSv2, oder IMDSv1 beide verwenden. Dies hängt auch vom Typ des AMI ab, das in der EC2 -kompatiblen Instance ausgeführt wird. Einige AMIs, z. B. solche, auf denen Ubuntu 20.04 ausgeführt wird, erfordern. IMDSv2 Der Instanz-Metadatendienst unterscheidet zwischen IMDSv1 und IMDSv2 Anfragen anhand des Vorhandenseins von `PUT` Oder-Headern. `GET` IMDSv2verwendet diese beiden Header. IMDSv1 verwendet nur den `GET` Header.

AWS befürwortet die Verwendung von IMDSv2 statt IMDSv1 , weil IMDSv2 beinhaltet eine höhere Sicherheit. Weitere Informationen finden [Sie unter Umfassender Schutz vor offenen Firewalls, Reverse-Proxys und SSRF-Schwachstellen mit Verbesserungen am Instanz-Metadatendienst](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/). EC2 

## IMDSv2 auf einer Schneeballkante
<a name="imdsv2"></a>

Wenn Sie IMDSv2 Instanz-Metadaten anfordern, muss die Anfrage diesen Regeln entsprechen:

1. Verwenden Sie eine `PUT`-Anfrage, um eine Sitzung mit dem Instance-Metadaten-Service zu starten. Die `PUT` Anfrage gibt ein Sitzungstoken zurück, das in nachfolgenden `GET` Anfragen an den Instanz-Metadatendienst enthalten sein muss. Das Sitzungstoken, das die Sitzungsdauer definiert. Die Sitzungsdauer kann mindestens eine Sekunde und maximal sechs Stunden betragen. Während dieser Dauer können Sie dasselbe Sitzungstoken für nachfolgende Anfragen verwenden. Nach Ablauf dieser Dauer müssen Sie ein neues Sitzungstoken für future Anfragen erstellen. Das Token ist erforderlich, um mithilfe von auf Metadaten zuzugreifen IMDSv2.

1. Nehmen Sie das Token in alle `GET`-Anfragen an den Instance-Metadaten-Service auf.

   1. Das Token ist ein instanzspezifischer Schlüssel. Das Token ist auf anderen EC2 -kompatiblen Instances nicht gültig und wird zurückgewiesen, wenn Sie versuchen, es außerhalb der Instanz zu verwenden, auf der es generiert wurde.

   1. Die `PUT`-Anfrage muss einen Header enthalten, der die Time To Live (TTL) für das Token in Sekunden bis zu maximal sechs Stunden (21 600 Sekunden) angibt. Das Token stellt eine logische Sitzung dar. Die TTL gibt die Gültigkeitsdauer des Token und damit die Dauer der Sitzung an.

   1. Nachdem ein Token abgelaufen ist, müssen Sie eine neue Sitzung mit einer anderen `PUT`-Anfrage erstellen, um auf die Instance-Metadaten zuzugreifen.

   1. Sie können auswählen, ob Sie ein Token wiederverwenden oder bei jeder Anforderung einen neues Token erstellen möchten. Für eine kleine Anzahl von Anfragen kann es einfacher sein, bei jedem Zugriff auf den Instance-Metadaten-Service ein Token zu generieren und sofort zu verwenden. Aus Effizienzgründen können Sie jedoch eine längere Dauer für das Token festlegen und es wiederverwenden, anstatt jedes Mal eine `PUT`-Anfrage stellen zu müssen, wenn Sie Instance-Metadaten anfordern müssen. Es gibt keine praktische Begrenzung der Anzahl der gleichzeitigen Tokens, die jeweils eine eigene Sitzung darstellen.

HTTP `GET` und `HEAD` Methoden sind in Anfragen zu IMDSv2 Instanz-Metadaten zulässig. `PUT`Anfragen werden abgelehnt, wenn sie einen `X-Forwarded-For` Header enthalten.

Standardmäßig hat die Antwort auf `PUT` Anfragen ein Response-Hop-Limit (Time-to-Live) von 1 auf IP-Protokollebene. IMDS for Snow ist nicht in der Lage, das Hop-Limit für `PUT` Antworten zu ändern.

Das folgende Beispiel verwendet ein Linux-Shell-Skript und ruft die IMDSv2 Metadatenelemente der Instanz auf oberster Ebene ab. Dieses Beispiel:

1. Erstellt mithilfe der `PUT` Anfrage ein Sitzungstoken mit einer Dauer von sechs Stunden (21.600 Sekunden).

1. Speichert den Sitzungs-Token-Header in einer Variablen mit dem Namen`TOKEN`.

1. Fordert mithilfe des Tokens die Metadatenelemente der obersten Ebene an.

Verwenden Sie zwei Befehle, um das EC2 -kompatible Token zu generieren. Sie können die Befehle separat oder als einen Befehl ausführen.

Generieren Sie zuerst ein Token mit dem folgenden Befehl.

**Anmerkung**  
`X-aws-ec2-metadata-token-ttl-seconds`ist ein erforderlicher Header. Wenn dieser Header nicht enthalten ist, erhalten Sie den Fehlercode **400 — Fehlende oder ungültige Parameter**.

```
    [ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
```

Verwenden Sie dann das Token, um mithilfe des folgenden Befehls Metadatenelemente der obersten Ebene zu generieren.

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```

**Anmerkung**  
Wenn beim Erstellen des Tokens ein Fehler auftritt, wird in der Variablen statt eines gültigen Tokens eine Fehlermeldung gespeichert und der Befehl funktioniert nicht.

Sie können das Token speichern und die Befehle kombinieren. Das folgende Beispiel kombiniert die beiden obigen Befehle und speichert den Sitzungs-Token-Header in einer Variablen namens`TOKEN`.

**Example von kombinierten Befehlen**  

```
    [ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
    && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```

Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Der folgende Beispielbefehl ruft die ID des AMI ab, das zum Starten der Instance verwendet wurde, und speichert sie in dem im vorherigen Beispiel `$TOKEN` erstellten.

**Example der Wiederverwendung eines Tokens**  

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id                        
```

## IMDSv1 auf einer Schneeballkante
<a name="imdsv1"></a>

IMDSv1 verwendet das Request‐Response-Modell. Um Instanz-Metadaten anzufordern, senden Sie eine `GET` Anfrage an den Instanz-Metadatendienst.

```
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/                   
```

Ihre Instance-Metadaten sind in Ihrer laufenden Instance verfügbar, sodass Sie nicht die EC2 Amazon-Konsole oder die verwenden müssen AWS CLI , um darauf zuzugreifen. Dies kann sehr hilfreich sein, wenn Sie ein Skript schreiben möchten, das in der Instance ausgeführt werden soll. So können Sie z. B. über die Instance-Metadaten auf die lokale IP-Adresse Ihrer Instance zugreifen, um die Verbindung zu einer externen Anwendung zu verwalten. Instance-Metadaten werden in vier Kategorien unterteilt. Eine Beschreibung der einzelnen Instance-Metadatenkategorien finden Sie unter [Unterstützte Instance-Metadaten und Benutzerdaten](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html) in diesem Handbuch. 

Verwenden Sie den folgenden IPv4 URI, um alle Kategorien von Instanz-Metadaten innerhalb einer laufenden Instance anzuzeigen:

```
    http://169.254.169.254/latest/meta-data/
```

Die IP-Adressen sind lokale Adressen (Link-local Addresses) und nur von der Instance aus gültig. Weitere Informationen finden Sie unter [Link-local address](https://en.wikipedia.org/wiki/Link-local_address) in Wikipedia.

Alle Instance-Metadaten werden als Text zurückgegeben (HTTP-Inhaltstyp `text/plain`).

Eine Anfrage nach einer bestimmten Metadatenressource gibt den entsprechenden Wert oder einen HTTP-Fehlercode **404 — Not Found** zurück, falls die Ressource nicht verfügbar ist.

Eine Anfrage nach einer allgemeinen Metadatenressource (wenn der URI mit einem `/` Zeichen endet) gibt eine Liste verfügbarer Ressourcen zurück oder einen HTTP-Fehlercode **404 — Not Found**, wenn es keine solche Ressource gibt. Die Listenelemente befinden sich in separaten Zeilen, die durch Zeilenvorschübe (ASCII-Zeichencode 10) abgeschlossen werden.

Für Anfragen, die mit gestellt wurden IMDSv1, können die folgenden HTTP-Fehlercodes zurückgegeben werden:
+ **400 ‐ Fehlende oder ungültige Parameter** — Die `PUT` Anfrage ist nicht gültig.
+ **401 ‐ Nicht autorisiert** — Die `GET` Anfrage verwendet ein ungültiges Token. Die empfohlene Aktion ist das Erzeugen eines neuen Token.
+ **403 ‐ Forbidden** — Die Anfrage ist nicht zulässig oder der Instanz-Metadatendienst ist deaktiviert.

# Beispiele für das Abrufen von Instanz-Metadaten mit IMDSv1 und IMDSv2 auf einem Snowball Edge
<a name="imds-code-examples"></a>

Die folgenden Beispiele enthalten Befehle, die Sie für eine Linux-Instance verwenden können.

**Example zum Abrufen der verfügbaren Versionen der Instanz-Metadaten**  
In diesem Beispiel werden die verfügbaren Versionen der Instance-Metadaten abgerufen. Jede Version bezieht sich auf einen Instance-Metadaten-Build, wenn neue Instance-Metadatenkategorien veröffentlicht wurden. Es stehen frühere Versionen zur Verfügung, für den Fall dass Skripte angewendet werden, die auf den Strukturen und Daten dieser früheren Versionen aufbauen.  
IMDSv2  

```
    [ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current  Dload  Upload   Total   Spent    Left  Speed
    100        56         100      56      0       0       3733     0    --:--:-- --:--:-- --:--:--  3733
    *   Trying 169.254.169.254...
    * TCP_NODELAY set
    * Connected to 169.254.169.254 (169.254.169.254) port 80 (#0)
    > GET / HTTP/1.1
    > Host: 169.254.169.254
    > User-Agent: curl/7.61.1
    > Accept: */*
    > X-aws-ec2-metadata-token: MDAXcxNFLbAwJIYx8KzgNckcHTdxT4Tt69TzpKExlXKTULHIQnjEtXvD
    >
    * HTTP 1.0, assume close after body
    < HTTP/1.0 200 OK
    < Date: Mon, 12 Sep 2022 21:58:03 GMT
    < Content-Length: 274
    < Content-Type: text/plain
    < Server: EC2ws
    <
    1.0
    2007-01-19
    2007-03-01
    2007-08-29
    2007-10-10
    2007-12-15
    2008-02-01
    2008-09-01
    2009-04-04
    2011-01-01
    2011-05-01
    2012-01-12
    2014-02-25
    2014-11-05
    2015-10-20
    2016-04-19
    2016-06-30
    2016-09-02
    2018-03-28
    2018-08-17
    2018-09-24
    2019-10-01
    2020-10-27
    2021-01-03
    2021-03-23
    * Closing connection 0
```
IMDSv1  

```
    [ec2-user ~]$ curl http://169.254.169.254/
    1.0
    2007-01-19
    2007-03-01
    2007-08-29
    2007-10-10
    2007-12-15
    2008-02-01
    2008-09-01
    2009-04-04
    2011-01-01
    2011-05-01
    2012-01-12
    2014-02-25
    2014-11-05
    2015-10-20
    2016-04-19
    2016-06-30
    2016-09-02
    2018-03-28
    2018-08-17
    2018-09-24
    2019-10-01
    2020-10-27
    2021-01-03
    2021-03-23
    latest
```

**Example zum Abrufen der Metadatenelemente der obersten Ebene**  
In diesem Beispiel werden die Metadatenelemente der obersten Ebene abgerufen. Informationen zu Metadatenelementen der obersten Ebene finden Sie in diesem Handbuch unter [Unterstützte Instanz-Metadaten und Benutzerdaten](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html).  
IMDSv2  

```
    [ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ 
    ami-id
    hostname
    instance-id
    instance-type
    local-hostname
    local-ipv4
    mac
    network/
    reservation-id
    security-groups
```
IMDSv1  

```
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ 
    ami-id
    hostname
    instance-id
    instance-type
    local-hostname
    local-ipv4
    mac
    network/
    reservation-id
    security-groups
```

**Example zum Abrufen von Werten von Metadaten der obersten Ebene**  
In den folgenden Beispielen werden die Werte einiger der Metadatenelemente der obersten Ebene abgerufen, die im vorherigen Beispiel abgerufen wurden. Die IMDSv2 Anfragen verwenden das gespeicherte Token, das im vorherigen Beispielbefehl erstellt wurde, vorausgesetzt, es ist nicht abgelaufen.  
`ami‐id` IMDSv2  

```
    curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890                    
```
`ami-id` IMDSv1  

```
    curl http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890                    
```
`reservation-id` IMDSv2  

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321
```
`reservation-id` IMDSv1  

```
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id \
    r-0efghijk987654321
```
`local-hostname` IMDSv2  

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/local-hostname ip-00-000-00-00                    
```
`local-hostname` IMDSv1  

```
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname ip-00-000-00-00
```