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.

# Instance-Metadaten verwenden, um Ihre EC2-Instance zu verwalten
<a name="ec2-instance-metadata"></a>

*Instance-Metadaten* sind Daten über eine Instance, mit denen Sie die ausgeführte Instance konfigurieren und verwalten können. Instance-Metadaten enthalten Folgendes:

**Eigenschaften der Instance-Metadaten**  
Instance-Metadaten sind in [Kategorien](#instancedata-data-categories) unterteilt (z. B. Host-Name, Ereignisse und Sicherheitsgruppen).

**Dynamische Daten**  
Dynamische Daten sind Metadaten, die beim Start der Instance generiert werden, wie z. B. ein Instance-Identitätsdokument. Weitere Informationen finden Sie unter [Kategorien von dynamischen Daten](#dynamic-data-categories).

**Benutzerdaten**  
Sie können Instance-Metadaten auch verwenden, um auf *Benutzerdaten* zuzugreifen, die Sie beim Start Ihrer Instance angegeben haben. Sie können beispielsweise Parameter für die Konfiguration Ihrer Instance angeben oder ein einfaches Skript einbinden. Sie können auch generische Konfigurationsdateien erstellen AMIs und Benutzerdaten verwenden, um die beim Start bereitgestellten Konfigurationsdateien zu ändern. Wenn Sie beispielsweise Webserver für verschiedene kleine Unternehmen betreiben, können sie alle dasselbe generische AMI verwenden und ihren Inhalt aus dem Amazon-S3-Bucket abrufen, den Sie beim Start in den Benutzerdaten angeben. Um jederzeit einen neuen Kunden hinzuzufügen, erstellen Sie einen Bucket für den Kunden, fügen Sie dessen Inhalt hinzu und starten Ihr AMI mit dem eindeutigen Bucket-Namen, der Ihrem Code in den Benutzerdaten zur Verfügung steht. Wenn Sie mehrere Instances mit demselben `RunInstances`-Aufruf starten, sind die Benutzerdaten für alle Instances in dieser Reservierung verfügbar. Jede Instance, die Teil derselben Reservierung ist, hat eine eindeutige `ami-launch-index`-Nummer, sodass Sie Code schreiben können, der die Aktivitäten der Instances steuert. Beispielsweise kann sich der erste Host selbst als ursprünglichen Knoten in einem Cluster auswählen. Ein detailliertes AMI-Startbeispiel finden Sie unter [Identifizieren Sie jede Instance, die in einer einzelnen Anfrage gestartet wurde](AMI-launch-index-examples.md).

**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.

**Topics**
+ [

## Instance-Metadatenkategorien
](#instancedata-data-categories)
+ [

## Kategorien von dynamischen Daten
](#dynamic-data-categories)
+ [

# Auf Instance-Metadaten für eine EC2-Instance zugreifen
](instancedata-data-retrieval.md)
+ [

# Konfigurieren der Optionen des Instance-Metadaten-Services
](configuring-instance-metadata-options.md)
+ [

# Befehle beim Starten einer EC2-Instance mit Eingabe von Benutzerdaten ausführen
](user-data.md)
+ [

# Identifizieren Sie jede Instance, die in einer einzelnen Anfrage gestartet wurde
](AMI-launch-index-examples.md)

## Instance-Metadatenkategorien
<a name="instancedata-data-categories"></a>

Instance-Metadaten-Eigenschaften werden in Kategorien unterteilt. Um Instance-Metadaten abzurufen, geben Sie die Kategorie in der Anfrage an, und die Metadaten werden in der Antwort zurückgegeben.

Wenn neue Kategorien veröffentlicht werden, wird ein neuer Instance-Metadaten-Build mit einer neuen Versionsnummer erstellt. In der folgenden Tabelle wird in der Spalte **Version, als die Kategorie veröffentlicht wurde** die Build-Version angegeben, als die Instance-Metadatenkategorie freigegeben wurde. Um zu vermeiden, dass Sie Ihren Code jedes Mal aktualisieren müssen, wenn Amazon EC2 einen neuen Instance-Metadaten-Build veröffentlicht, verwenden Sie `latest` in Ihren Metadaten-Anfragen, nicht die Versionsnummer. Weitere Informationen finden Sie unter [Abrufen der verfügbaren Versionen der Instance-Metadaten](configuring-instance-metadata-service.md#instance-metadata-ex-1).

Wenn Amazon EC2 eine neue Instance-Metadatenkategorie veröffentlicht, sind die Instance-Metadaten für die neue Kategorie möglicherweise nicht für vorhandene Instances verfügbar. Bei Instances, die auf dem [Nitro-System](instance-types.md#instance-hypervisor-type) erstellt wurden, können Sie Instance-Metadaten nur für die Kategorien abrufen, die beim Start verfügbar waren. Bei Instances mit dem Xen-Hypervisor können Sie die Instance [stoppen und dann starten](Stop_Start.md), um die für die Instance verfügbaren Kategorien zu aktualisieren.

In der folgenden Tabelle werden die Kategorien von Instance-Metadaten aufgeführt. Einige der Kategorienamen enthalten Platzhalter für Daten, die für Ihre Instance eindeutig sind.. *mac*Stellt beispielsweise die MAC-Adresse für die Netzwerkschnittstelle dar. Sie müssen die Platzhalter durch tatsächliche Werte ersetzen, wenn Sie die Instance-Metadaten abrufen.


| Kategorie | Description | Version, als die Kategorie veröffentlicht wurde | 
| --- | --- | --- | 
| ami-id  | Die für den Start der Instance verwendete AMI-ID | 1,0 | 
| ami-launch-index  | Wenn Sie mehrere Instances mit demselben RunInstances-Aufruf starten, gibt dieser Wert die Startreihenfolge für jede Instance an. Der Wert für die zuerst gestartete Instance ist 0. Wenn Sie Instances mit Auto Scaling oder EC2-Flotte starten, ist dieser Wert immer 0. | 1,0 | 
| ami-manifest-path  | Der Pfad zu der AMI-Manifestdatei in Amazon S3. Wenn Sie für den Start der Instance ein Amazon EBS-Backed AMI verwendet haben, wird als Ergebnis ausgegebe unknown. | 1,0 | 
| ancestor-ami-ids  | Das AMI IDs aller Instances, die zur Erstellung dieses AMI neu gebündelt wurden. Dieser Wert ist nur vorhanden, wenn die AMI-Manifestdatei einen ancestor-amis-Schlüssel enthalten hat. | 2007-10-10 | 
| autoscaling/target-lifecycle-state |  Wert, der den Zielzustand des Auto-Scaling-Lebenszyklus anzeigt, in den eine Auto-Scaling-Instance übergeht. Wird verwendet, wenn die Instance nach dem 10. März 2022 in einen der Ziel-Lebenszyklusstatus wechselt. Mögliche Werte: `Detached` \$1 `InService` \$1 `Standby` \$1 `Terminated` \$1 `Warmed:Hibernated` \$1 `Warmed:Running` \$1 `Warmed:Stopped` \$1 `Warmed:Terminated`. Siehe [Abrufen des Ziellebenszyklusstatus durch Instance-Metadaten](https://docs.aws.amazon.com/autoscaling/ec2/userguide/retrieving-target-lifecycle-state-through-imds.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.   | 2021-07-15 | 
| block-device-mapping/ami | Das virtuelle Gerät, das das Dateisystem enthält. root/boot  | 2007-12-15 | 
| block-device-mapping/ebsN  | Die virtuellen Geräte, die mit einem Amazon EBS-Volume verknüpft sind. Amazon EBS-Volumes sind nur in Metadaten enthalten, wenn sie beim Starten der Instance – oder als die Instance zuletzt gestartet wurde – vorhanden waren. N zeigt dabei den Index für das Amazon EBS-Volume an (z. B. ebs1 oder ebs2). | 2007-12-15 | 
| block-device-mapping/ephemeralN  | Die virtuellen Geräte für alle Speichervolumes, die keine NVMe Instanzen sind. N gibt den Index jedes Volumes an. Die Anzahl der Instance-Speicher-Volumes in der Blockgerät-Zuweisung entspricht möglicherweise nicht der tatsächlichen Anzahl der Instance-Speicher-Volumes für die Instance. Der Instance-Typ bestimmt die Anzahl der Instance-Speicher-Volumes, die für eine Instance verfügbar sind. Wenn die Anzahl der Instance-Speicher-Volumes in einer Blockgerät-Zuweisung die für eine Instance verfügbare Anzahl übersteigt, werden die überzähligen Instance-Speicher-Volumes ignoriert. | 2007-12-15 | 
| block-device-mapping/root  | Die virtuellen Laufwerke oder Partitionen, die den Root-Laufwerken oder Partitionen auf dem virtuellen Laufwerk zugeordnet sind, wobei das Root-Dateisystem (/ oder C:) der angegebenen Instance zugeordnet ist. | 2007-12-15 | 
| block-device-mapping/swap  | Die virtuellen Geräte, die mit swap verknüpft sind. Nicht immer vorhanden. | 2007-12-15 | 
| events/maintenance/history | Enthält eine JSON-Zeichenfolge mit Informationen zu den Ereignissen, wenn es abgeschlossene oder abgebrochene Wartungsereignisse für die Instance gibt. | 2018-08-17 | 
| events/maintenance/scheduled | Enthält eine JSON-Zeichenfolge mit Informationen zu den Ereignissen, wenn es aktive Wartungsereignisse für die Instance gibt. Weitere Informationen finden Sie unter [Geplante Ereignisse, die sich auf Ihre Amazon-EC2-Instances auswirken, anzeigen](viewing_scheduled_events.md). | 2018-08-17 | 
| events/recommendations/rebalance | Die ungefähre Zeit in UTC, zu der die Empfehlungsbenachrichtigung des EC2-Instance-Neuausgleichs für die Instance ausgesendet wird. Das Folgende ist ein Beispiel für die Metadaten für diese Kategorie: \$1"noticeTime": "2020-11-05T08:22:00Z"\$1. Diese Kategorie ist erst verfügbar, nachdem die Benachrichtigung gesendet wurde. Weitere Informationen finden Sie unter [Empfehlung zum Neuausgleich einer EC2-Instance](rebalance-recommendations.md). | 2020-10-27 | 
| hostname | Wenn die EC2-Instance die IP-basierte Benennung (IPBN) verwendet, ist dies der private IPv4-DNS-Hostname der Instance. Wenn die EC2-Instance die ressourcenbasierte Benennung (RBN) verwendet, ist dies der RBN. Wenn mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dieser Wert auf das Gerät eth0 (das Gerät mit der Gerätenummer 0). Weitere Informationen zu IPBN und RBN finden Sie unter [Hostnamen und Domains der EC2-Instance](ec2-instance-naming.md). | 1,0 | 
|  iam/info  | Wenn der Instance eine IAM-Rolle zugeordnet ist, enthält Informationen darüber, wann das Instanzprofil zuletzt aktualisiert wurde, einschließlich des LastUpdated Datums der Instanz, und. InstanceProfileArn InstanceProfileId Andernfalls nicht vorhanden. | 2012-01-12 | 
|  iam/security-credentials/role-name  | Wenn der Instance eine IAM-Rolle zugeordnet role-name ist, ist dies der Name der Rolle und role-name enthält die temporären Sicherheitsanmeldedaten, die der Rolle zugeordnet sind (weitere Informationen finden Sie unter[Abrufen von Sicherheitsanmeldeinformationen aus Instance-Metadaten](instance-metadata-security-credentials.md)). Andernfalls nicht vorhanden. | 2012-01-12 | 
| identity-credentials/ec2/info | Informationen zu den Anmeldeinformationen in identity-credentials/ec2/security-credentials/ec2-instance. | 2018-05-23 | 
| identity-credentials/ec2/security-credentials/ec2-instance | Anmeldeinformationen für die Instance-Identitätsrolle, die es der On-Instance-Software ermöglichen, sich selbst zu identifizieren AWS , um Funktionen wie EC2 Instance Connect und AWS Systems Manager Standard-Host-Management-Konfiguration zu unterstützen. An diese Anmeldeinformationen sind keine Richtlinien angehängt, sodass sie über die Identifizierung der Instance für die Funktion hinaus keine zusätzlichen AWS API-Berechtigungen haben. AWS Weitere Informationen finden Sie unter [Instance-Identitäts-Rollen für Amazon-EC2-Instances](iam-roles-for-amazon-ec2.md#ec2-instance-identity-roles). | 2018-05-23 | 
| instance-action | Weist die Instance an, zur Vorbereitung einer Bündelung einen Neustart durchzuführen. Zulässige Werte: none \$1 shutdown \$1 bundle-pending. | 2008-09-01 | 
| instance-id | Die ID dieser Instance | 1,0 | 
| instance-life-cycle | Die Kaufoption dieser Instance. Weitere Informationen finden Sie unter [Abrechnungs- und Kaufoptionen von Amazon EC2](instance-purchasing-options.md). | 01.10.2019 | 
| instance-type  | Der Typ der Instance. Weitere Informationen finden Sie unter [Amazon EC2-Instance-Typen](instance-types.md). | 2007-08-29 | 
| ipv6  | Die IPv6 Adresse der Instanz. In Fällen, in denen mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dies auf die Netzwerkschnittstelle des eth0-Geräts (das Gerät, für das die Gerätenummer 0 ist) und die erste zugewiesene IPv6 Adresse. Wenn auf der Netzwerkschnittstelle [0] keine IPv6 Adresse vorhanden ist, ist dieses Element nicht gesetzt und führt zu einer HTTP 404-Antwort. | 2021-01-03 | 
|  kernel-id  | Die ID des mit dieser Instance gestarteten Kernels (falls zutreffend) | 2008-02-01 | 
|  local-hostname  | Wenn mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dieser Wert auf das Gerät eth0 (das Gerät mit der Gerätenummer 0). Wenn die EC2-Instance die IP-basierte Benennung (IPBN) verwendet, ist dies der private IPv4-DNS-Hostname der Instance. Wenn die EC2-Instance die ressourcenbasierte Benennung (RBN) verwendet, ist dies der RBN. Weitere Informationen zur Benennung von IPBN-, RBN- und EC2-Instances finden Sie unter [Hostnamen und Domains der EC2-Instance](ec2-instance-naming.md). | 2007-01-19 | 
|  local-ipv4  | Die private IPv4 Adresse der Instanz. Wenn mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dieser Wert auf das Gerät eth0 (das Gerät mit der Gerätenummer 0). Wenn es sich um eine IPv6 reine Instanz handelt, ist dieses Element nicht festgelegt und führt zu einer HTTP 404-Antwort. | 1,0 | 
|  mac  | Die Media Access Control-Adresse (MAC) der Instance. Wenn mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dieser Wert auf das Gerät eth0 (das Gerät mit der Gerätenummer 0). | 01.01.2011 | 
| metrics/vhostmd | Nicht mehr verfügbar. | 2011-05-01 | 
|  network/interfaces/macs/mac/device-number  | Die eindeutige Gerätenummer, die mit dieser Schnittstelle verknüpft ist. Die Gerätenummer entspricht dem Gerätenamen; device-number 2 steht z. B. für das Gerät eth2. Diese Kategorie entspricht den Feldern DeviceIndex und device-index, die von der Amazon EC2 API und den EC2-Befehlen für die AWS CLI verwendet werden. | 01.01.2011 | 
|  network/interfaces/macs/mac/interface-id  | Die ID der Netzwerkschnittstelle. | 01.01.2011 | 
|  network/interfaces/macs/mac/ipv4-associations/public-ip  | Die privaten IPv4 Adressen, die jeder öffentlichen IP-Adresse zugeordnet und dieser Schnittstelle zugewiesen sind. | 01.01.2011 | 
| network/interfaces/macs/mac/ipv6s | Die der Schnittstelle zugewiesenen IPv6 Adressen. | 2016-06-30 | 
| network/interfaces/macs/mac/ipv6-prefix | Das der Netzwerkschnittstelle zugewiesene IPv6 Präfix. |  | 
|  network/interfaces/macs/mac/local-hostname  |  Der private IPv4 DNS-Hostname der Instanz. Wenn mehrere Netzwerkschnittstellen vorhanden sind, bezieht sich dieser Wert auf das Gerät eth0 (das Gerät mit der Gerätenummer 0). Wenn es sich um eine IPv6 reine Instanz handelt, ist dies der ressourcenbasierte Name. Weitere Informationen zu IPBN und RBN finden Sie unter [Hostnamen und Domains der EC2-Instance](ec2-instance-naming.md).  | 2007-01-19 | 
|  network/interfaces/macs/mac/local-ipv4s  | Die privaten IPv4 Adressen, die der Schnittstelle zugeordnet sind. Wenn es sich um eine IPv6 reine Netzwerkschnittstelle handelt, ist dieses Element nicht festgelegt und führt zu einer HTTP 404-Antwort. | 01.01.2011 | 
|  network/interfaces/macs/mac/mac  | Die MAC-Adresse der Instance | 01.01.2011 | 
|  network/interfaces/macs/mac/network-card  | Der Index der Netzwerkkarte. Einige Instance-Typen unterstützen mehrere Netzwerkkarten. | 01.11.2020 | 
| network/interfaces/macs/mac/owner-id  | Die ID des Eigentümers der Netzwerkschnittstelle. In Umgebungen mit mehreren Schnittstellen kann eine Schnittstelle von einem Drittanbieter wie Elastic Load Balancing zugewiesen werden. Der Datenverkehr auf einer Schnittstelle wird immer dem Eigentümer der Schnittstelle in Rechnung gestellt. | 01.01.2011 | 
|  network/interfaces/macs/mac/public-hostname  | Das öffentliche DNS der Schnittstelle (IPv4). Diese Kategorie wird nur ausgegeben, wenn das Attribut enableDnsHostnames auf true gesetzt ist. Weitere Infomationen finden Sie unter [DNS-Attribute für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) im Amazon VPC-Benutzerhandbuch. Wenn die Instanz nur eine öffentliche IPv6 Adresse und keine öffentliche IPv4 Adresse hat, ist dieses Element nicht gesetzt und führt zu einer HTTP 404-Antwort. |  01.01.2011 | 
|  network/interfaces/macs/mac/public-ipv4s  | Die öffentliche IP-Adresse oder die Elastic IP-Adressen, die dem Adapter zugeordnete sind. Eine Instanz kann mehrere IPv4 Adressen enthalten.  | 01.01.2011 | 
| network/interfaces/macs/mac/security-groups  | Sicherheitsgruppen, zu denen die Netzwerkschnittstelle gehört. | 01.01.2011 | 
|  network/interfaces/macs/mac/security-group-ids  | Die IDs Sicherheitsgruppen, zu denen die Netzwerkschnittstelle gehört. | 01.01.2011 | 
|  network/interfaces/macs/mac/subnet-id  | Die ID für das Subnetz, in der sich die Schnittstelle befindet. | 01.01.2011 | 
|  network/interfaces/macs/mac/subnet-ipv4-cidr-block  | Der IPv4 CIDR-Block des Subnetzes, in dem sich die Schnittstelle befindet. | 01.01.2011 | 
| network/interfaces/macs/mac/subnet-ipv6-cidr-blocks  | Der IPv6 CIDR-Block des Subnetzes, in dem sich die Schnittstelle befindet. | 2016-06-30  | 
|  network/interfaces/macs/mac/vpc-id  | Die ID für die VPC, in der sich die Schnittstelle befindet. | 01.01.2011 | 
| network/interfaces/macs/mac/vpc-ipv4-cidr-block | Der primäre IPv4 CIDR-Block der VPC. | 01.01.2011 | 
| network/interfaces/macs/mac/vpc-ipv4-cidr-blocks | Die IPv4 CIDR-Blöcke für die VPC. | 2016-06-30  | 
| network/interfaces/macs/mac/vpc-ipv6-cidr-blocks | Der IPv6 CIDR-Block der VPC, in dem sich die Schnittstelle befindet. | 2016-06-30  | 
|  placement/availability-zone | Die Availability Zone, in der die Instance gestartet wurde | 2008-02-01 | 
|  placement/availability-zone-id | Die statische Availability Zone-ID, in der die Instance gestartet wird. Die Availability Zone-ID ist für alle Konten konsistent. Sie kann sich jedoch von der Availability Zone unterscheiden, die je nach Konto variieren kann. | 01.10.2019 | 
|  placement/group-name  | Der Name der Platzierungsgruppe, in der die Instance gestartet wird. | 24.08.2020 | 
|  placement/host-id  | Die ID des Hosts, auf dem die Instance gestartet wird. Gilt nur für Dedicated Hosts. | 24.08.2020 | 
|  placement/partition-number  | Die Nummer der Partition, in der die Instance gestartet wird. | 24.08.2020 | 
|  placement/region  | Die AWS Region, in der die Instance gestartet wird. | 24.08.2020 | 
|  product-codes  | AWS Marketplace Produktcodes, die der Instance zugeordnet sind, falls vorhanden.  | 2007-03-01 | 
|  public-hostname  | Das öffentliche DNS der Instanz (IPv4). Diese Kategorie wird nur ausgegeben, wenn das Attribut enableDnsHostnames auf true gesetzt ist. Weitere Infomationen finden Sie unter [DNS-Attribute für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) im Amazon VPC-Benutzerhandbuch. Wenn die Instanz nur eine öffentliche IPv6 Adresse und keine öffentliche IPv4 Adresse hat, ist dieses Element nicht gesetzt und führt zu einer HTTP 404-Antwort. | 2007-01-19 | 
|  public-ipv4  | Die öffentliche IPv4 Adresse. Wenn eine Elastic IP-Adresse mit der Instance verknüpft ist, ist der zurückgegebene Wert die Elastic IP-Adresse. | 2007-01-19 | 
|  public-keys/0/openssh-key  | Der öffentliche Schlüssel. Nur verfügbar, wenn bei der Instance-Startzeit angegeben. | 1,0 | 
|  ramdisk-id  | Die ID des RAM-Datenträgers, der beim Start angegeben wurde (falls zutreffend) | 2007-10-10 | 
|  reservation-id  | Die ID der Reservierung | 1,0 | 
|  security-groups  |  Die Namen der Sicherheitsgruppen für die Instance. Nach dem Start können Sie die Sicherheitsgruppen von Instances ändern. Solche Änderungen spiegeln sich hier und innetwork/interfaces/macs/**mac**/security-groups wider.  | 1,0 | 
|  services/domain  |  Die Domain für AWS Ressourcen für die Region.  | 2014-02-25 | 
|  services/partition  |  Die Partition, in der sich die Ressource befindet. Für AWS Standardregionen lautet die Partition`aws`. Wenn Sie Ressourcen in anderen Partitionen haben, lautet die Partition `aws-partitionname`. Die Aufteilung der Ressourcen in der Region China (Peking) lautet beispielsweise `aws-cn`.  | 2015-10-20 | 
|  spot/instance-action  |  Die Aktion (in den Ruhezustand versetzen, anhalten oder beenden) sowie den ungefähren Zeitpunkt in UTC, an dem die Aktion ausgeführt wird. Dieses Element ist nur vorhanden, wenn die Spot-Instance für das Versetzen in den Ruhezustand, das Anhalten oder das Beenden markiert wurde. Weitere Informationen finden Sie unter [instance-action](spot-instance-termination-notices.md#instance-action-metadata).  | 15.11.2016 | 
|  spot/termination-time  |  Die ungefähre Zeit in UTC, zu der das Betriebssystem für Ihre Spot-Instance das Signal zum Beenden empfängt. Dieses Element ist nur vorhanden und enthält einen Zeitwert (z. B. 2015-01-05T18:02:00Z), wenn die Spot-Instance von Amazon EC2 zum Beenden markiert wurde. Das Element für den Beendigungszeitpunkt enthält keinen Wert, wenn Sie die Spot-Instance selbst beenden. Weitere Informationen finden Sie unter [termination-time](spot-instance-termination-notices.md#termination-time-metadata).  | 2014-11-05 | 
| system | Der zugrunde liegende Virtualisierungstyp (Hypervisor) der Instance. | 24.09.2022 | 
| tags/instance | Die Instance-Tags, die der Instance zugeordnet sind. Nur verfügbar, wenn Sie explizit Zugriff auf Tags in Instance-Metadaten zulassen. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS). | 23.03.2021 | 

## Kategorien von dynamischen Daten
<a name="dynamic-data-categories"></a>

In der folgenden Tabelle werden die Kategorien von dynamischen Daten aufgeführt.


| Kategorie | Description | Version, als die Kategorie veröffentlicht wurde | 
| --- | --- | --- | 
| fws/instance-monitoring  | Wert, der angibt, ob der Kunde eine detaillierte einminütige Überwachung aktiviert hat. CloudWatch Zulässige Werte: enabled \$1 disabled | 2009-04-04 | 
| instance-identity/document  | JSON-Wert mit Instance-Attributen, z. B. Instance-ID, private IP-Adresse, usw. Siehe [Instanzidentitätsdokumente für EC2 Amazon-Instances](instance-identity-documents.md).  | 2009-04-04 | 
| instance-identity/pkcs7  | Wird verwendet, um die Authentizität und den Inhalt des Dokuments mithilfe der Signatur zu überprüfen. Siehe [Instanzidentitätsdokumente für EC2 Amazon-Instances](instance-identity-documents.md).  | 2009-04-04 | 
| instance-identity/signature  | Die Daten können von Dritten verwendet werden, um den Ursprung und die Authentizität zu überprüfen. Siehe [Instanzidentitätsdokumente für EC2 Amazon-Instances](instance-identity-documents.md).  | 2009-04-04 | 

# Auf Instance-Metadaten für eine EC2-Instance zugreifen
<a name="instancedata-data-retrieval"></a>

Sie können auf EC2-Instance-Metadaten innerhalb der Instance selbst oder über die EC2-Konsole SDKs, API oder die zugreifen. AWS CLI Informationen zum Abrufen der aktuellen Instance-Metadateneinstellungen für eine Instance über die Konsole oder Befehlszeile finden Sie unter [Abfragen von Instance-Metadatenoptionen für vorhandene Instances](#query-IMDS-existing-instances).

Sie können Benutzerdaten für Instances mit einem EBS-Stamm-Volume ändern. Die Instances muss angehalten werden. Eine Anleitung für die Konsole finden Sie unter [Instance-Benutzerdaten aktualisieren](user-data.md#user-data-modify). Ein Linux-Beispiel, das die verwendet, finden Sie unter AWS CLI. [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) Ein Windows-Beispiel, das die Tools für Windows verwendet PowerShell, finden Sie unter[Benutzerdaten und die Tools für Windows PowerShell](user-data.md#user-data-powershell).

**Anmerkung**  
Beachten Sie, dass für HTTP-Anfragen für den Abruf von Instance-Metadaten und Benutzerdaten keine Gebühren berechnet werden.

## Überlegungen zum Instance-Zugriff auf Instance-Metadaten
<a name="imds-considerations"></a>

Beachten Sie Folgendes, um Probleme mit Instanzmetadaten zu vermeiden.

**Fehler beim Starten der Instance aufgrund von IMDSv2 Erzwingungsmaßnahmen (`HttpTokensEnforced=enabled`)**  
Bevor Sie die IMDSv2 Erzwingung aktivieren, müssen Sie die gesamte Software auf der Instance unterstützen IMDSv2. Danach können Sie die Standardeinstellung auf disable IMDSv1 (`httpTokens=required`) ändern und anschließend die Erzwingung aktivieren. Weitere Informationen finden Sie unter [Übergang zur Verwendung von Instance-Metadatenservice Version 2](instance-metadata-transition-to-version-2.md).

**Befehlsformat**  
Das Befehlsformat ist unterschiedlich, je nachdem, ob Sie Instance Metadata Service Version 1 (IMDSv1) oder Instance Metadata Service Version 2 (IMDSv2) verwenden. Standardmäßig können Sie beide Instance-Metadaten-Services verwenden. Um die Verwendung von IMDSv2 zu erzwingen, lesen Sie [Instance-Metadaten-Services für den Zugriff auf Instance-Metadaten verwenden](configuring-instance-metadata-service.md).

**Falls IMDSv2 erforderlich, IMDSv1 funktioniert nicht**  
Wenn Sie es verwenden IMDSv1 und keine Antwort erhalten, IMDSv2 ist dies wahrscheinlich erforderlich. Um zu überprüfen, ob dies erforderlich IMDSv2 ist, wählen Sie die Instanz aus, um ihre Details anzuzeigen. Der **IMDSv2**Wert gibt entweder **Erforderlich** (Sie müssen verwenden IMDSv2) oder **Optional** (Sie können entweder IMDSv2 oder verwendenIMDSv1) an. 

**(IMDSv2) Wird verwendet/latest/api/token, um das Token abzurufen**  
Das Ausgeben von `PUT`-Anfragen an einen beliebigen versionsspezifischen Pfad, beispielsweise `/2021-03-23/api/token`, führt dazu, dass der Metadatenservice „403-Verboten“-Fehler zurückgibt. Dieses Verhalten ist beabsichtigt.

**Metadaten-Version**  
Um zu vermeiden, dass Sie Ihren Code jedes Mal aktualisieren müssen, wenn Amazon EC2 einen neuen Instance-Metadaten-Build veröffentlicht, empfehlen wir, `latest` im Pfad zu verwenden, nicht die Versionsnummer.

**IPv6 Unterstützung**  
Um Instanz-Metadaten mithilfe einer IPv6 Adresse abzurufen, stellen Sie sicher, dass Sie die IPv6 Adresse des IMDS `[fd00:ec2::254]` anstelle der IPv4 Adresse `169.254.169.254` aktivieren und verwenden. Bei der Instance muss es sich um eine [Nitro-basierte Instance handeln](instance-types.md#instance-hypervisor-type), die in einem [Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) gestartet wurde, das Folgendes unterstützt. IPv6

**(Windows) Erstellen Sie eine benutzerdefinierte Version AMIs mit Windows Sysprep**  
Um sicherzustellen, dass IMDS funktioniert, wenn Sie eine Instance von einem benutzerdefinierten Windows-AMI starten, muss das AMI ein standardisiertes Image sein, welches mit Windows Sysprep erstellt wurde. Andernfalls funktioniert der IMDS nicht. Weitere Informationen finden Sie unter [Ein Amazon-EC2-AMI mit Windows Sysprep erstellen](ami-create-win-sysprep.md).

**Erwägen Sie in einer Container-Umgebung eine Neukonfiguration oder Erhöhung des Hop-Limits auf 2.**  
Die AWS SDKs Verwendung IMDSv2 ruft standardmäßig auf. Wenn der IMDSv2 Anruf keine Antwort erhält, AWS SDKs wiederholen einige den Anruf und verwendenIMDSv1, falls er immer noch nicht erfolgreich ist. Dies kann zu einer Verzögerung führen, insbesondere in einer Container-Umgebung. *Wenn AWS SDKs das Hop-Limit in einer Container-Umgebung bei 1 liegt, erhält der Anruf bei Bedarf möglicherweise überhaupt keine Antwort, da das Aufrufen des Containers als zusätzlicher Netzwerk-Hop betrachtet wird.* IMDSv2  
Um diese Probleme in einer Container-Umgebung zu vermeiden, sollten Sie die Konfiguration so ändern, dass Einstellungen (wie z. B. AWS-Region) direkt an den Container übergeben werden, oder erwägen Sie, das Hop-Limit auf 2 zu erhöhen. Weitere Informationen über die Auswirkung des Hop-Limits finden Sie unter [Erweitern Sie den EC2-Instance-Metadata-Service um Verbesserungen bei der Abwehr von offenen Firewalls, Reverse-Proxys und SSRF-Schwachstellen](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/). Weitere Informationen zum Ändern des Hop-Limits finden Sie unter [Ändern des PUT-Antwort-Hop-Limits](configuring-IMDS-existing-instances.md#modify-PUT-response-hop-limit).

**Begrenzen von Paketen pro Sekunde (PPS)**  
Für Services, die [Link-Local](using-instance-addressing.md#link-local-addresses)-Adressen verwenden, gilt eine Obergrenze von 1 024 Paketen pro Sekunde (PPS). Dieses Limit umfasst die Summe von [Route-53-Resolver-DNS-Abfragen](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits), Instance Metadata Service (IMDS)-Anfragen, [Amazon Time Service Network Time Protocol (NTP)](set-time.md)-Anfragen und [Windows-Licensing-Service-Anfragen (für Microsoft Windows-basierte Instances)](https://aws.amazon.com/windows/resources/licensing/). 

**Zusätzliche Überlegungen zum Zugriff auf Benutzerdaten**
+ Benutzerdaten werden als Opaque-Daten behandelt: Was Sie eingeben, wird auch ausgegeben. Die Interpretation der Benutzerdaten und die Instance ist Aufgabe der Instance.
+ Benutzerdaten müssen mit Base64 codiert werden. Je nachdem, welches Tool oder SDK Sie verwenden, wird die Base64-Kodierung möglicherweise für Sie durchgeführt. Beispiel:
  + Die Amazon EC2-Konsole kann die base64-Codierung für Sie durchführen oder base64-codierte Eingaben entgegennehmen.
  + [AWS CLI Version 2 führt standardmäßig](https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam) die Base64-Kodierung von Binärparametern für Sie durch. AWS CLI Version 1 führt die Base64-Kodierung des Parameters für Sie durch. `--user-data`
  + Die AWS SDK für Python (Boto3) führt die Base64-Kodierung des Parameters für Sie durch. `UserData`
+ Benutzerdaten sind auf 16 KB an Rohdaten, bevor diese base64-codiert werden, begrenzt. Die Länge einer Zeichenfolge *n* nach base64-Codierung ist ceil(*n*/3)\$14.
+ Benutzerdaten müssen base64-decodiert werden, wenn Sie sie abrufen. Wenn Sie die Daten über Instance-Metadaten oder die Konsole abrufen, werden sie automatisch für Sie dekodiert.
+ Wenn Sie eine Instance anhalten, ihre Benutzerdaten ändern und die Instance wieder starten, werden die aktualisierten Benutzerdaten nicht automatisch ausgeführt, wenn Sie die Instance starten. Bei Windows-Instances können Sie die Einstellungen so konfigurieren, dass aktualisierte Benutzerdatenskripte einmalig beim Starten der Instance oder bei jedem Neustart oder Start der Instance ausgeführt werden.
+ Benutzerdaten sind ein Instance-Attribut. Wenn Sie ein AMI auf der Grundlage einer Instance erstellen, sind die Instance-Benutzerdaten nicht im AMI enthalten.

## Auf Instance-Metadaten innerhalb einer EC2-Instance zugreifen
<a name="instancedata-inside-access"></a>

Da Ihre Instance-Metadaten von der ausgeführten Instance verfügbar sind, müssen Sie nicht die Amazon-EC2-Konsole oder die AWS CLI verwenden. 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.

Alle folgenden Daten werden als Instance-Metadaten betrachtet, der Zugriff erfolgt jedoch auf unterschiedliche Weise. Wählen Sie die Registerkarte aus, die den Typ der Instance-Metadaten darstellt, auf die Sie zugreifen möchten, um weitere Informationen zu erhalten.

------
#### [ Metadata ]

Instance-Metadaten-Eigenschaften werden in Kategorien unterteilt. Eine Beschreibung der einzelnen Instance-Metadatenkategorien finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).

Um von einer laufenden Instanz aus auf die Eigenschaften der Instanz-Metadaten zuzugreifen, rufen Sie die Daten aus dem folgenden IPv4 oder ab. IPv6 URIs Die IP-Adressen sind Link-lokale Adressen und nur von der Instance aus gültig. Weitere Informationen finden Sie unter [Link-lokale Adressen](using-instance-addressing.md#link-local-addresses).

**IPv4**

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

**IPv6**

```
http://[fd00:ec2::254]/latest/meta-data/
```

------
#### [ Dynamic data ]

Verwenden Sie eine der folgenden Methoden, um dynamische Daten aus einer laufenden Instanz abzurufenURIs.

**IPv4**

```
http://169.254.169.254/latest/dynamic/
```

**IPv6**

```
http://[fd00:ec2::254]/latest/dynamic/
```

**Beispiele: Zugriff mit cURL**  
Die folgenden Beispiele verwenden `cURL`, um die High-Level-Instance-Identitätskategorien abzurufen.

*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" http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```

*IMDSv1*

```
[ec2-user ~]$ curl http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```

**Beispiele: Zugriff mit PowerShell**  
In den folgenden Beispielen werden PowerShell die Identitätskategorien für Instanzen auf hoher Ebene abgerufen.

*IMDSv2*

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```

*IMDSv1*

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```

Weitere Informationen zu dynamischen Daten und Beispiele dafür, wie sie abgerufen werden können, finden Sie unter [Instanzidentitätsdokumente für EC2 Amazon-Instances](instance-identity-documents.md).

------
#### [ User data ]

Verwenden Sie eine der folgenden Methoden, um Benutzerdaten aus einer Instanz abzurufen URIs. Um Benutzerdaten mithilfe der IPv6 Adresse abzurufen, müssen Sie sie aktivieren, und die Instance muss eine [Nitro-basierte Instance](instance-types.md#instance-hypervisor-type) in einem Subnetz sein, das dies unterstützt. IPv6

**IPv4**

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

**IPv6**

```
http://[fd00:ec2::254]/latest/user-data
```

Eine Anfrage für Benutzerdaten geben die Daten unverändert zurück (Content-Type `application/octet-stream`). Wenn die Instance keine Benutzerdaten hat, gibt die Anfrage `404 - Not Found` zurück.

**Beispiele: Zugriff mit cURL zum Abrufen von kommagetrenntem Text**  
Die folgenden Beispiele verwenden `cURL`, um Benutzerdaten abzurufen, die als kommagetrennter Text angegeben wurden.

*IMDSv2*

```
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" http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```

*IMDSv1*

```
curl http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```

**Beispiele: Access with zum Abrufen von PowerShell kommagetrenntem Text**  
In den folgenden Beispielen werden Benutzerdaten abgerufen PowerShell , die als kommagetrennter Text angegeben wurden.

*IMDSv2*

```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```

*IMDSv1*

```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} `
-Method PUT -Uri http://169.254.169.254/latest/api/token} -Method GET -uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```

**Beispiele: Zugriff mit cURL zum Abrufen eines Skripts**  
Die folgenden Beispiele verwenden `cURL`, um Benutzerdaten abzurufen, die als Skript angegeben wurden.

*IMDSv2*

```
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" http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

*IMDSv1*

```
curl http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

**Beispiele: Access with, PowerShell um ein Skript abzurufen**  
In den folgenden Beispielen PowerShell werden Benutzerdaten abgerufen, die als Skript angegeben wurden.

*IMDSv2*

```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
<powershell>
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

*IMDSv1*

```
Invoke-RestMethod -uri http://169.254.169.254/latest/user-data
<powershell>
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

------

## Abfragen von Instance-Metadatenoptionen für vorhandene Instances
<a name="query-IMDS-existing-instances"></a>

Sie können die Instance-Metadatenoptionen für vorhandene Instances abfragen.

------
#### [ Console ]

**So fragen Sie die Instance-Metadatenoptionen für eine vorhandene Instance ab**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie Ihre Instance aus und überprüfen Sie die folgenden Felder:
   + **IMDSv2**— Der Wert ist entweder **erforderlich** oder **optional**.
   + **Tags in Instance-Metadaten zulassen** – Der Wert ist entweder **Aktiviert** oder **Deaktiviert**.

1. Wenn Sie die Instance ausgewählt haben, wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadatenoptionen ändern**.

   Im Dialogfeld wird angezeigt, ob der Instance-Metadatenservice für die ausgewählte Instance aktiviert oder deaktiviert ist.

------
#### [ AWS CLI ]

**So fragen Sie die Instance-Metadatenoptionen für eine vorhandene Instance ab**  
Verwenden Sie den Befehl [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html).

```
aws ec2 describe-instances \
    --instance-id i-1234567898abcdef0 \
    --query 'Reservations[].Instances[].MetadataOptions'
```

------
#### [ PowerShell ]

**Um die Instanz-Metadatenoptionen für eine bestehende Instanz mithilfe der Tools für abzufragen PowerShell**  
Verwenden Sie das cmdlet [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).

```
(Get-EC2Instance `
    -InstanceId i-1234567898abcdef0).Instances.MetadataOptions
```

------

## Antworten und Fehlermeldungen
<a name="instance-metadata-returns"></a>

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

Eine Anfrage für eine spezifische Metadatenressource gibt den entsprechenden Wert oder einen HTTP-Fehlercode `404 - Not Found` zurück, wenn die Ressource nicht verfügbar ist.

Eine Anfrage für eine allgemeine Metadatenressource (der URI endet auf „/”) gibt eine Liste der verfügbaren Ressourcen oder einen HTTP-Fehlercode `404 - Not Found` zurück, wenn keine entsprechenden Ressourcen vorhanden sind. Die Listenelemente stehen jeweils in einer eigenen Zeile, d. h. sie sind durch Zeilenvorschübe (ASCII 10) getrennt.

Wenn eine IMDSv1 Anfrage keine Antwort erhält, IMDSv2 ist dies wahrscheinlich erforderlich.

Bei Anfragen, die über gestellt wurden IMDSv2, können die folgenden HTTP-Fehlercodes zurückgegeben werden:
+ `400 - Missing or Invalid Parameters` – Die `PUT`-Anfrage ist nicht gültig.
+ `401 - Unauthorized` – 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 IMDS ist deaktiviert.
+ `404 - Not Found` – Die Ressource ist nicht verfügbar oder es gibt keine solche Ressource.
+ `503` – Die Anforderung konnte nicht abgeschlossen werden. Wiederholen Sie die Anforderung.

Wenn das IMDS einen Fehler zurückgibt, druckt **curl** die Fehlermeldung in der Ausgabe und gibt einen Erfolgsstatuscode zurück. Die Fehlermeldung wird in der `TOKEN`-Variablen gespeichert, was dazu führt, dass **curl**-Befehle, die das Token verwenden, fehlschlagen. Wenn Sie **curl** mit der **-f** Option aufrufen, wird im Falle eines HTTP-Serverfehlers ein Fehlerstatuscode zurückgegeben. Wenn Sie die Fehlerbehandlung aktivieren, kann die Shell den Fehler auffangen und das Skript beenden.

## Drosselung abfragen
<a name="instancedata-throttling"></a>

Wir drosseln die Abfragen an den IMDS pro Instance und begrenzen die Anzahl gleichzeitiger Verbindungen von einer Instance zum IMDS. 

Wenn Sie das IMDS zum Abrufen von AWS Sicherheitsanmeldedaten verwenden, vermeiden Sie es, bei jeder Transaktion oder gleichzeitig von einer großen Anzahl von Threads oder Prozessen aus nach Anmeldeinformationen zu fragen, da dies zu einer Drosselung führen kann. Wir empfehlen stattdessen, die Anmeldeinformationen im Cache zu speichern, bis sie sich ihrer Ablaufzeit nähern. Weitere Informationen über die IAM-Rolle und die der Rolle zugeordneten Sicherheitsanmeldeinformationen finden Sie unter [Abrufen von Sicherheitsanmeldeinformationen aus Instance-Metadaten](instance-metadata-security-credentials.md).

Wenn es beim Zugriff auf den IMDS zu einer Drosselung kommt, versuchen Sie Ihre Abfrage mit einer exponentiellen Backoff-Strategie erneut.

# Instance-Metadaten-Services für den Zugriff auf Instance-Metadaten verwenden
<a name="configuring-instance-metadata-service"></a>

Sie können mit einer der folgenden Methoden auf Instance-Metadaten aus einer laufenden Instance zugreifen:
+ Instanz-Metadatendienst Version 2 (IMDSv2) — eine sitzungsorientierte Methode

  Beispiele finden Sie unter [Beispiele für IMDSv2](#instance-metadata-retrieval-examples).
+ Instanz-Metadatendienst Version 1 (IMDSv1) — eine Methode request/response 

  Beispiele finden Sie unter [Beispiele für IMDSv1](#instance-metadata-retrieval-examples-imdsv1).

Standardmäßig können Sie entweder IMDSv1 oder oder IMDSv2 beide verwenden.

Sie können den Instanz-Metadatendienst (IMDS) auf jeder Instanz so konfigurieren, dass er nur IMDSv2 Aufrufe akzeptiert, was dazu führt, dass IMDSv1 Aufrufe fehlschlagen. Informationen darüber, wie Sie Ihre Instance für die Verwendung konfigurieren IMDSv2, finden Sie unter[Konfigurieren der Optionen des Instance-Metadaten-Services](configuring-instance-metadata-options.md).

Die `GET` Header `PUT` oder sind einzigartig für IMDSv2. Wenn diese Header in der Anfrage enthalten sind, dann ist die Anfrage für vorgesehen. IMDSv2 Wenn keine Header vorhanden sind, wird davon ausgegangen, dass die Anfrage dafür bestimmt ist. IMDSv1

Eine ausführliche Übersicht über finden [Sie unter IMDSv2 Erweiterter Schutz vor offenen Firewalls, Reverse-Proxys und SSRF-Sicherheitslücken mit Verbesserungen am EC2-Instanz-Metadatendienst](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).

**Topics**
+ [

## Funktionsweise von Instance-Metadatenservice Version 2
](#instance-metadata-v2-how-it-works)
+ [

## Verwenden Sie ein unterstütztes AWS SDK
](#use-a-supported-sdk-version-for-imdsv2)
+ [

## Beispiele für IMDSv2
](#instance-metadata-retrieval-examples)
+ [

## Beispiele für IMDSv1
](#instance-metadata-retrieval-examples-imdsv1)

## Funktionsweise von Instance-Metadatenservice Version 2
<a name="instance-metadata-v2-how-it-works"></a>

IMDSv2 verwendet sitzungsorientierte Anfragen. Bei sitzungsorientierten Anforderungen erstellen Sie ein Sitzungs-Token, das die Sitzungsdauer definiert, die mindestens eine Sekunde und maximal sechs Stunden betragen kann. Während der angegebenen Dauer können Sie dasselbe Sitzungs-Token für nachfolgende Anfragen verwenden. Nach Ablauf der angegebenen Dauer müssen Sie ein neues Sitzungs-Token erstellen, das Sie für zukünftige Anfragen verwenden können.

**Anmerkung**  
Die Beispiele in diesem Abschnitt verwenden die IPv4 Adresse des Instance Metadata Service (IMDS):. `169.254.169.254` Wenn Sie Instanz-Metadaten für EC2-Instances über die IPv6 Adresse abrufen, stellen Sie sicher, dass Sie stattdessen die IPv6 Adresse aktivieren und verwenden:. `[fd00:ec2::254]` Die IPv6 Adresse des IMDS ist mit Befehlen kompatibel. IMDSv2 Die IPv6 Adresse ist nur auf [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) in einem [Subnetz zugänglich, das von IPv6 -unterstützt wird](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (Dual-Stack oder nur). IPv6 

In den folgenden Beispielen wird ein Shell-Skript verwendet, IMDSv2 um die Metadatenelemente der Instanz auf oberster Ebene abzurufen. Jedes Beispiel:
+ Erstellt ein Sitzungs-Token mit einer Dauer von sechs Stunden (21 600 Sekunden) unter Verwendung der `PUT`-Anfrage.
+ Speichern den Sitzungs-Token-Header in einer Variablen namens `TOKEN` (Linux-Instances) oder `token` (Windows-Instances)
+ aFordert die Top-Level-Metadatenelemente über das Token an.

### Linux-Beispiel
<a name="how-imdsv2-works-example-linux"></a>

Sie können zwei separate Befehle ausführen oder kombinieren.

**Separate Befehle**

Generieren Sie zuerst ein Token mit dem folgenden Befehl.

```
[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 mit dem folgenden Befehl Metadatenelemente der obersten Ebene zu generieren.

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

**Kombinierte Befehle**

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.

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

```
[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" http://169.254.169.254/latest/meta-data/
```

Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Im folgenden Beispielbefehl, der die ID des AMIs abruft, mit dem die Instance gestartet wurde, wird das im vorherigen Beispiel in `$TOKEN` gespeicherte Token wiederverwendet.

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

### Windows-Beispiel
<a name="how-imdsv2-works-example-windows"></a>

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
```

Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Im folgenden Beispielbefehl, der die ID des AMIs abruft, mit dem die Instance gestartet wurde, wird das im vorherigen Beispiel in `$token` gespeicherte Token wiederverwendet.

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} `
	-Method GET -uri http://169.254.169.254/latest/meta-data/ami-id
```

Wenn Sie IMDSv2 Instanz-Metadaten anfordern, muss die Anfrage Folgendes enthalten:

1. Verwenden Sie eine `PUT`-Anfrage, um eine Sitzung mit dem Instance-Metadaten-Service zu starten. Die `PUT`-Anfrage gibt ein Token zurück, das in nachfolgenden `GET`-Anfragen an den Instance-Metadaten-Service enthalten sein muss. Das Token wird für den Zugriff auf Metadaten mit IMDSv2 benötigt.

1. Nehmen Sie das Token `GET` in alle Anfragen an den IMDS auf. Wenn die Token-Verwendung auf `required` festgelegt ist, erhalten Anfragen ohne gültiges Token oder mit abgelaufenem Token einen `401 - Unauthorized`-HTTP-Fehlercode.
   + Das Token ist ein Instance-bezogener Schlüssel. Das Token ist in anderen EC2-Instances nicht gültig und wird abgelehnt, wenn Sie versuchen, es außerhalb der Instance zu verwenden, in der es erzeugt wurde.
   + 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.
   + Nachdem ein Token abgelaufen ist, müssen Sie eine neue Sitzung mit einem anderen `PUT` erstellen, um auf die Instance-Metadaten zuzugreifen.
   + 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 IMDS 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 Beschränkung für die Anzahl gleichzeitiger Token, von denen jedes für eine eigene Sitzung steht. IMDSv2 ist jedoch immer noch durch normale IMDS-Verbindungs- und Drosselungsgrenzen eingeschränkt. Weitere Informationen finden Sie unter [Drosselung abfragen](instancedata-data-retrieval.md#instancedata-throttling).

In IMDSv2 Instance-Metadatenanfragen sind HTTP `GET`- und `HEAD`-Methoden zulässig. `PUT`-Anfragen werden abgelehnt, wenn sie einen X-Forwarded-For-Header enthalten.

Standardmäßig hat die Antwort auf `PUT`-Anfragen auf IP-Protokollebene ein Antworthop-Limit (Time To Live) von `1`. Wenn Sie ein größeres Hop-Limit benötigen, können Sie es mit dem Befehl anpassen. [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) AWS CLI Beispielsweise benötigen Sie möglicherweise eine größeres Hop-Limit für die Abwärtskompatibilität mit Container-Services, die auf der Instance ausgeführt werden. Weitere Informationen finden Sie unter [Modifizieren von Instance-Metadatenoptionen für vorhandene Instances](configuring-IMDS-existing-instances.md).

## Verwenden Sie ein unterstütztes AWS SDK
<a name="use-a-supported-sdk-version-for-imdsv2"></a>

Um IMDSv2 verwenden zu können, müssen Ihre EC2-Instances eine AWS SDK-Version verwenden, die die Verwendung von unterstützt. IMDSv2 Die neuesten Versionen aller unterstützen die AWS SDKs Verwendung von. IMDSv2

**Wichtig**  
Wir empfehlen Ihnen, über die SDK-Versionen auf dem Laufenden zu bleiben, um über die neuesten Features, Sicherheitsupdates und zugrunde liegenden Abhängigkeiten informiert zu sein. Die fortgesetzte Verwendung einer nicht unterstützten SDK-Version wird nicht empfohlen und erfolgt nach Ihrem Ermessen. Weitere Informationen finden Sie in den [Wartungsrichtlinien für AWS SDKs und Tools](https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html) im *AWS SDKs Referenzhandbuch für Tools*.

Im Folgenden sind die Mindestversionen aufgeführt, die die Verwendung von unterstützen IMDSv2:
+ [AWS CLI](https://github.com/aws/aws-cli) – 1.16.289
+ [AWS Tools for Windows PowerShell](https://github.com/aws/aws-tools-for-powershell)    –  4.0.1.0
+ [AWS SDK für .NET](https://github.com/aws/aws-sdk-net) – 3.3.634.1
+ [AWS SDK für C\$1\$1](https://github.com/aws/aws-sdk-cpp) – 1.7.229
+ [AWS SDK für Go](https://github.com/aws/aws-sdk-go) – 1.25.38
+ [AWS SDK for Go v2](https://github.com/aws/aws-sdk-go-v2) — 0.19.0
+ [AWS SDK für Java](https://github.com/aws/aws-sdk-java) – 1.11.678
+ [AWS SDK for Java 2.x](https://github.com/aws/aws-sdk-java-v2) – 2.10.21
+ [AWS SDK für JavaScript in Node.js](https://github.com/aws/aws-sdk-js) — 2.722.0
+ [AWS SDK für Kotlin](https://github.com/awslabs/aws-sdk-kotlin) – 1,1.4
+ [AWS SDK für PHP](https://github.com/aws/aws-sdk-php) – 3.147.7
+ [AWS SDK für Python (Botocore)](https://github.com/boto/botocore) — 1.13.25
+ [AWS SDK für Python (Boto3)](https://github.com/boto/boto3) – 1.12.6
+ [AWS SDK für Ruby](https://github.com/aws/aws-sdk-ruby) – 3.79.0

## Beispiele für IMDSv2
<a name="instance-metadata-retrieval-examples"></a>

Führen Sie die folgenden Beispiele auf Ihrer Amazon EC2 EC2-Instance aus, um die Instance-Metadaten für IMDSv2 abzurufen.

Auf Windows-Instanzen können Sie Windows verwenden PowerShell oder cURL oder wget installieren. Wenn Sie ein Drittanbieter-Tool in einer Windows-Instance installieren, sollten Sie die zugehörige Dokumentation unbedingt sorgfältig lesen; die Methode für die Aufrufe und die Ausgabe können von dieser Dokumentation abweichen.

**Topics**
+ [

### Abrufen der verfügbaren Versionen der Instance-Metadaten
](#instance-metadata-ex-1)
+ [

### Anfordern der Top-Level-Metadatenelemente
](#instance-metadata-ex-2)
+ [

### Die Werte für Metadatenelemente abrufen
](#instance-metadata-ex-2a)
+ [

### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
](#instance-metadata-ex-3)
+ [

### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
](#instance-metadata-ex-4)
+ [

### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
](#instance-metadata-ex-5)
+ [

### Anfordern der Subnetz-ID für eine Instance
](#instance-metadata-ex-6)
+ [

### Abrufen von Instance-Tags für eine Instance
](#instance-metadata-ex-7)

### Abrufen der verfügbaren Versionen der Instance-Metadaten
<a name="instance-metadata-ex-1"></a>

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. Die Build-Versionen der Instance-Metadaten korrelieren nicht mit den Amazon-EC2-API-Versionen. 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.

------
#### [ cURL ]

```
[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" 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
...
latest
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri 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
...
latest
```

------

### Anfordern der Top-Level-Metadatenelemente
<a name="instance-metadata-ex-2"></a>

In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen zu den einzelnen Punkten in der Antwort finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).

Beachten Sie, dass Tags nur dann in dieser Ausgabe enthalten sind, wenn Sie den Zugriff zugelassen haben. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

------
#### [ cURL ]

```
[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" http://169.254.169.254/latest/meta-data/    
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```

------

### Die Werte für Metadatenelemente abrufen
<a name="instance-metadata-ex-2a"></a>

Die folgenden Beispiele zeigen die Werte einiger der Top-Level-Metadatenelemente, die im vorherigen Beispiel abgerufen wurden. Diese Anfragen verwenden das gespeicherte Token, das mit dem Befehl im vorherigen Beispiel erstellt wurde. Das Token darf nicht abgelaufen sein.

------
#### [ cURL ]

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

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

```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```

```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```

------

### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
<a name="instance-metadata-ex-3"></a>

In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.

------
#### [ cURL ]

```
[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" http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```

------

### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
<a name="instance-metadata-ex-4"></a>

In diesem Beispiel werden die Formate abgerufen, in denen der öffentliche Schlüssel 0 verfügbar ist.

------
#### [ cURL ]

```
[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" http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```

------

### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
<a name="instance-metadata-ex-5"></a>

In diesem Beispiel wird der öffentliche Schlüssel 0 abgerufen (im Format für OpenSSH-Schlüssel).

------
#### [ cURL ]

```
[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" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```

------

### Anfordern der Subnetz-ID für eine Instance
<a name="instance-metadata-ex-6"></a>

In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.

------
#### [ cURL ]

```
[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" http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```

------
#### [ PowerShell ]

```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```

```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```

------

### Abrufen von Instance-Tags für eine Instance
<a name="instance-metadata-ex-7"></a>

Wenn der Zugriff auf Instance-Tags in den Instance-Metadaten aktiviert ist, können Sie die Tags für eine Instance aus den Instance-Metadaten abrufen. Weitere Informationen finden Sie unter [Abrufen von Tags aus Instance-Metadaten](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

## Beispiele für IMDSv1
<a name="instance-metadata-retrieval-examples-imdsv1"></a>

Führen Sie die folgenden Beispiele auf Ihrer Amazon EC2 EC2-Instance aus, um die Instance-Metadaten für IMDSv1 abzurufen.

Auf Windows-Instanzen können Sie Windows verwenden PowerShell oder cURL oder wget installieren. Wenn Sie ein Drittanbieter-Tool in einer Windows-Instance installieren, sollten Sie die zugehörige Dokumentation unbedingt sorgfältig lesen; die Methode für die Aufrufe und die Ausgabe können von dieser Dokumentation abweichen.

**Topics**
+ [

### Abrufen der verfügbaren Versionen der Instance-Metadaten
](#instance-metadata-ex-1-imdsv1)
+ [

### Anfordern der Top-Level-Metadatenelemente
](#instance-metadata-ex-2-imdsv1)
+ [

### Die Werte für Metadatenelemente abrufen
](#instance-metadata-ex-2a-imdsv1)
+ [

### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
](#instance-metadata-ex-3-imdsv1)
+ [

### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
](#instance-metadata-ex-4-imdsv1)
+ [

### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
](#instance-metadata-ex-5-imdsv1)
+ [

### Anfordern der Subnetz-ID für eine Instance
](#instance-metadata-ex-6-imdsv1)
+ [

### Abrufen von Instance-Tags für eine Instance
](#instance-metadata-ex-7-imdsv1)

### Abrufen der verfügbaren Versionen der Instance-Metadaten
<a name="instance-metadata-ex-1-imdsv1"></a>

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. Die Build-Versionen der Instance-Metadaten korrelieren nicht mit den Amazon-EC2-API-Versionen. 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.

------
#### [ cURL ]

```
[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
...
latest
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri 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
...
latest
```

------

### Anfordern der Top-Level-Metadatenelemente
<a name="instance-metadata-ex-2-imdsv1"></a>

In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen zu den einzelnen Punkten in der Antwort finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).

Beachten Sie, dass Tags nur dann in dieser Ausgabe enthalten sind, wenn Sie den Zugriff zugelassen haben. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/    
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/    
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```

------

### Die Werte für Metadatenelemente abrufen
<a name="instance-metadata-ex-2a-imdsv1"></a>

Die folgenden Beispiele zeigen die Werte einiger der Top-Level-Metadatenelemente, die im vorherigen Beispiel abgerufen wurden.

------
#### [ cURL ]

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

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

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```

------

### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
<a name="instance-metadata-ex-3-imdsv1"></a>

In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
```

------

### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
<a name="instance-metadata-ex-4-imdsv1"></a>

In diesem Beispiel werden die Formate abgerufen, in denen der öffentliche Schlüssel 0 verfügbar ist.

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```

------

### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
<a name="instance-metadata-ex-5-imdsv1"></a>

In diesem Beispiel wird der öffentliche Schlüssel 0 abgerufen (im Format für OpenSSH-Schlüssel).

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```

------

### Anfordern der Subnetz-ID für eine Instance
<a name="instance-metadata-ex-6-imdsv1"></a>

In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.

------
#### [ cURL ]

```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```

------
#### [ PowerShell ]

```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```

------

### Abrufen von Instance-Tags für eine Instance
<a name="instance-metadata-ex-7-imdsv1"></a>

Wenn der Zugriff auf Instance-Tags in den Instance-Metadaten aktiviert ist, können Sie die Tags für eine Instance aus den Instance-Metadaten abrufen. Weitere Informationen finden Sie unter [Abrufen von Tags aus Instance-Metadaten](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).

# Übergang zur Verwendung von Instance-Metadatenservice Version 2
<a name="instance-metadata-transition-to-version-2"></a>

Wenn Sie Ihre Instances so konfigurieren möchten, dass sie nur Aufrufe von Instance Metadata Service Version 2 (IMDSv2) akzeptieren, empfehlen wir Ihnen, die folgenden Tools und den folgenden Übergangspfad zu verwenden.

**Topics**
+ [

## Tools für den Übergang zu IMDSv2
](#tools-for-transitioning-to-imdsv2)
+ [

## Empfohlener Pfad zur Anforderung IMDSv2
](#recommended-path-for-requiring-imdsv2)

## Tools für den Übergang zu IMDSv2
<a name="tools-for-transitioning-to-imdsv2"></a>

Mit den folgenden Tools können Sie den Übergang Ihrer Software von zu identifizieren, zu überwachen und IMDSv1 zu IMDSv2 verwalten. Anweisungen zur Verwendung dieser Tools finden Sie unter[Empfohlener Pfad zur Anforderung IMDSv2](#recommended-path-for-requiring-imdsv2).

**AWS Software**  
Die neuesten Versionen der AWS SDKs AWS CLI und unterstützen IMDSv2. Um IMDSv2 zu verwenden, aktualisieren Sie Ihre EC2-Instances, sodass sie die neuesten Versionen verwenden. Informationen zu den AWS SDK-Mindestversionen, die dies unterstützen IMDSv2, finden Sie unter. [Verwenden Sie ein unterstütztes AWS SDK](configuring-instance-metadata-service.md#use-a-supported-sdk-version-for-imdsv2)  
Alle Amazon Linux 2- und Amazon Linux 2023-Softwarepakete IMDSv2 werden unterstützt. Amazon Linux 2023 ist IMDSv1 standardmäßig deaktiviert.

**IMDS-Paket-Analysator**  
IMDS Packet Analyzer ist ein Open-Source-Tool, das IMDSv1 Aufrufe während der Startphase und der Laufzeitvorgänge Ihrer Instance identifiziert und protokolliert. Durch die Analyse dieser Protokolle können Sie genau identifizieren, welche Software Ihre Instances IMDSv1 aufruft, und bestimmen, welche Software aktualisiert werden muss, damit sie IMDSv2 nur auf Ihren Instances unterstützt wird. Sie können IMDS-Paket-Analysator von der Befehlszeile aus ausführen oder als Service installieren. Weitere Informationen finden Sie [AWS ImdsPacketAnalyzer](https://github.com/aws/aws-imds-packet-analyzer)unter *GitHub*.

**CloudWatch**  
CloudWatch bietet die folgenden zwei Metriken für die Überwachung Ihrer Instances:  
`MetadataNoToken`— IMDSv2 verwendet tokengestützte Sitzungen, tut dies aber IMDSv1 nicht. Die `MetadataNoToken` Metrik verfolgt die Anzahl der Aufrufe des Instance Metadata Service (IMDS), die verwendet werden. IMDSv1 Indem Sie diese Metrik bis zum Wert Null nachverfolgen, können Sie feststellen, ob und wann Ihre Software auf IMDSv2 aktualisiert wurde.  
`MetadataNoTokenRejected`— Nach der Deaktivierung IMDSv1 können Sie anhand der `MetadataNoTokenRejected` Metrik verfolgen, wie oft ein IMDSv1 Anruf versucht und abgelehnt wurde. Indem Sie diese Metrik verfolgen, können Sie feststellen, ob Ihre Software aktualisiert werden muss, um sie verwenden IMDSv2 zu können.  
Für jede EC2-Instance schließen sich diese Metriken gegenseitig aus. Wenn aktiviert IMDSv1 ist (`httpTokens = optional`), wird nur ausgegeben`MetadataNoToken`. Wenn deaktiviert IMDSv1 ist (`httpTokens = required`), wird nur ausgegeben`MetadataNoTokenRejected`. Wann Sie diese Metriken verwenden sollten, finden Sie unter[Empfohlener Pfad zur Anforderung IMDSv2](#recommended-path-for-requiring-imdsv2).  
Weitere Informationen finden Sie unter [Instance-Metriken](viewing_metrics_with_cloudwatch.md#ec2-cloudwatch-metrics).

**Starten APIs**  
**Neue Instances:** Verwenden Sie die [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API, um neue Instances zu starten, für die die Verwendung von erforderlich ist IMDSv2. Weitere Informationen finden Sie unter [Konfigurieren von Instance-Metadatenoptionen für neue Instances](configuring-IMDS-new-instances.md).  
**Bestehende Instanzen:** Verwenden Sie die [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API, um die Verwendung von IMDSv2 auf vorhandenen Instanzen vorzuschreiben. Weitere Informationen finden Sie unter [Modifizieren von Instance-Metadatenoptionen für vorhandene Instances](configuring-IMDS-existing-instances.md).  
**Neue Instances, die von Auto Scaling Scaling-Gruppen gestartet wurden:** Um die Verwendung von IMDSv2 für alle neuen Instances zu verlangen, die von Auto Scaling Scaling-Gruppen gestartet werden, können Ihre Auto Scaling Scaling-Gruppen entweder eine Startvorlage oder eine Startkonfiguration verwenden. Wenn Sie [eine Startvorlage erstellen](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html) oder [eine Startkonfiguration erstellen](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html), müssen Sie die `MetadataOptions`-Parameter so konfigurieren, dass die Verwendung von IMDSv2 erforderlich ist. Die Auto-Scaling-Gruppe startet neue Instances mit der neuen Startvorlage oder Startkonfiguration, bestehende Instances sind davon jedoch nicht betroffen.   
**Bestehende Instances in einer Auto Scaling Scaling-Gruppe:** Verwenden Sie die [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API, um die Verwendung von IMDSv2 auf vorhandenen Instances vorzuschreiben, oder beenden Sie die Instances, und die Auto Scaling Scaling-Gruppe startet neue Ersatz-Instances mit den Einstellungen der Instance-Metadaten-Optionen, die in der neuen Startvorlage oder Startkonfiguration definiert sind.

**AMIs**  
AMIs konfiguriert mit dem `ImdsSupport` Parameter, der auf gesetzt ist, `v2.0` startet IMDSv2 standardmäßig Instances, die dies erfordern. Amazon Linux 2023 ist konfiguriert mit`ImdsSupport = v2.0`.  
**Neu AMIs:** Verwenden Sie den CLI-Befehl [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html), um den `ImdsSupport` Parameter auf zu setzen, `v2.0` wenn Sie ein neues AMI erstellen.  
**Existierend AMIs:** Verwenden Sie den [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html)CLI-Befehl, um den `ImdsSupport` Parameter auf festzulegen, `v2.0` wenn Sie ein vorhandenes AMI ändern.  
Weitere Informationen finden Sie unter [Konfigurieren des AMI](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-ami-configuration).

**Kontrollen auf Kontoebene**  
Sie können Standardwerte für alle Instanz-Metadatenoptionen auf Kontoebene konfigurieren. Die Standardwerte werden automatisch angewendet, wenn Sie eine Instance starten. Weitere Informationen finden Sie unter[IMDSv2 Als Standard für das Konto festlegen](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).  
Sie können die Anforderung zur Nutzung auch IMDSv2 auf Kontoebene durchsetzen. Wenn die IMDSv2 Durchsetzung aktiviert ist:  
+ **Neue Instanzen: Instances**, die so konfiguriert sind, dass sie mit IMDSv1 aktivierter Option gestartet werden, können nicht gestartet werden
+ **Bestehende Instances mit IMDSv1 deaktiviertem Status:** Versuche, sie IMDSv1 auf vorhandenen Instances zu aktivieren, werden verhindert.
+ **Bestehende Instanzen mit IMDSv1 aktivierter Option:** Bestehende Instanzen, die IMDSv1 bereits aktiviert sind, sind davon nicht betroffen.
Weitere Informationen finden Sie unter [IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

**IAM-Richtlinien und SCPs**  
Sie können eine IAM-Richtlinie oder eine AWS Organizations Service Control Policy (SCP) verwenden, um Benutzer wie folgt zu kontrollieren:  
+ Eine Instance kann nicht mithilfe der [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API gestartet werden, es sei denn, die Instance ist für die Verwendung konfiguriert. IMDSv2
+ Eine bestehende Instanz kann nicht mithilfe der [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API geändert werden, um sie erneut zu aktivierenIMDSv1.
Die IAM-Richtlinie oder die SCP muss die folgenden IAM-Bedingungsschlüssel enthalten:  
+ `ec2:MetadataHttpEndpoint`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpTokens`
Wenn ein Parameter im API- oder CLI-Aufruf nicht mit dem Status übereinstimmt, der in der Richtlinie angegeben ist, die den Bedingungsschlüssel enthält, schlägt der API- oder CLI-Aufruf mit einer `UnauthorizedOperation` Antwort fehl.  
Darüber hinaus können Sie eine zusätzliche Schutzebene auswählen, um die Änderung von IMDSv1 auf IMDSv2 zu erzwingen. Auf der Zugriffsverwaltungsebene für die APIs, die über EC2-Rollenanmeldedaten aufgerufen werden, können Sie einen Bedingungsschlüssel entweder in IAM-Richtlinien oder in AWS Organizations Dienststeuerungsrichtlinien () SCPs verwenden. Insbesondere wenn Sie den Bedingungsschlüssel `ec2:RoleDelivery` mit einem Wert von `2.0` in Ihren IAM-Richtlinien verwenden, erhalten API-Aufrufe, die mit den EC2-Rollenanmeldedaten von IMDSv1 abgerufen wurden, eine Antwort. `UnauthorizedOperation` Das Gleiche kann mit der von einer SCP erzwungenen Bedingung weiter gefasst werden. Dadurch wird sichergestellt, dass die über übermittelten Anmeldeinformationen IMDSv1 nicht tatsächlich zum Aufrufen verwendet werden können, APIs da bei API-Aufrufen, die nicht der angegebenen Bedingung entsprechen, eine `UnauthorizedOperation` Fehlermeldung ausgegeben wird.  
Beispiele für IAM-Richtlinien finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata). Weitere Informationen zu SCPs finden Sie im *AWS Organizations Benutzerhandbuch* unter [Richtlinien zur Servicesteuerung](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

**Deklarative Richtlinien**  
Verwenden Sie deklarative Richtlinien (eine Funktion von AWS Organizations), um die Standardeinstellungen für IMDS-Konten, einschließlich deren IMDSv2 Durchsetzung, in Ihrem gesamten Unternehmen zentral festzulegen. *Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im Benutzerhandbuch.AWS Organizations *

## Empfohlener Pfad zur Anforderung IMDSv2
<a name="recommended-path-for-requiring-imdsv2"></a>

**Topics**
+ [

### Schritt 1: Identifizieren Sie Instanzen mit IMDSv2 =optional und überprüfen Sie die Nutzung IMDSv1
](#path-step-1)
+ [

### Schritt 2: Aktualisieren Sie die Software auf IMDSv2
](#path-step-2)
+ [

### Schritt 3: Keine Instanzen erforderlich IMDSv2
](#path-step-3)
+ [

### Schritt 4: Stellen Sie IMDSv2 =required als Standard ein
](#path-step-4)
+ [

### Schritt 5: Erzwingen Sie, dass Instanzen Folgendes benötigen IMDSv2
](#path-step-5)

### Schritt 1: Identifizieren Sie Instanzen mit IMDSv2 =optional und überprüfen Sie die Nutzung IMDSv1
<a name="path-step-1"></a>

Um Ihren IMDSv2 Migrationsumfang einzuschätzen, identifizieren Sie Instanzen, die so konfiguriert sind, dass sie entweder IMDSv1 oder zulassen IMDSv2, und prüfen Sie IMDSv1 Aufrufe.

1. **Identifizieren Sie Instanzen, die so konfiguriert sind, dass sie entweder IMDSv1 oder IMDSv2:**

------
#### [ Amazon EC2 console ]

   1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Wählen Sie im Navigationsbereich **Instances** aus.

   1. Um nur die Instanzen zu sehen, die so konfiguriert sind, dass sie IMDSv1 oder zulassen IMDSv2, fügen Sie den Filter **IMDSv2 = optional** hinzu.

   1. Um zu sehen, ob dies **optional** oder für alle Instanzen **erforderlich IMDSv2 ** ist, öffnen Sie alternativ das **Einstellungsfenster** (Zahnradsymbol) **IMDSv2**, schalten Sie die Option ein und wählen Sie **Bestätigen**. Dadurch wird die **IMDSv2**Spalte zur **Instanzen-Tabelle** hinzugefügt.

------
#### [ AWS CLI ]

   Verwenden Sie den Befehl [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) und filtern `metadata-options.http-tokens = optional` Sie wie folgt nach:

   ```
   aws ec2 describe-instances --filters "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].[InstanceId]" --output text
   ```

------

1. ** IMDSv1 Audit-Aufrufe für jede Instanz:**

   Verwenden Sie die CloudWatch Metrik`MetadataNoToken`. Diese Metrik zeigt die Anzahl der IMDSv1 Aufrufe an das IMDS auf Ihren Instances. Weitere Informationen finden Sie unter [Instanz-Metriken](https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics).

1. **Identifizieren Sie die Software auf Ihren Instances, die IMDSv1 Anrufe tätigt:**

   Verwenden Sie den [Open-Source-IMDS Packet Analyzer](https://github.com/aws/aws-imds-packet-analyzer), um IMDSv1 Aufrufe während der Startphase und der Laufzeitvorgänge Ihrer Instance zu identifizieren und zu protokollieren. Verwenden Sie diese Informationen, um die Software zu identifizieren, die aktualisiert werden muss, damit Ihre Instances IMDSv2 nur einsatzbereit sind. Sie können IMDS-Paket-Analysator von der Befehlszeile aus ausführen oder als Service installieren.

### Schritt 2: Aktualisieren Sie die Software auf IMDSv2
<a name="path-step-2"></a>

Aktualisieren Sie alle SDKs, und Software CLIs, die Rollenanmeldedaten auf Ihren Instances verwendet, auf IMDSv2 -kompatible Versionen. Weitere Informationen zur Aktualisierung der CLI finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) im *Benutzerhandbuch für AWS Command Line Interface *.

### Schritt 3: Keine Instanzen erforderlich IMDSv2
<a name="path-step-3"></a>

Nachdem Sie anhand der `MetadataNoToken` Metrik bestätigt haben, dass keine IMDSv1 Aufrufe mehr erforderlich sind, konfigurieren Sie Ihre vorhandenen Instances so, dass sie erforderlich sind IMDSv2. Konfigurieren Sie außerdem alle neuen Instanzen so, dass sie erforderlich sind IMDSv2. Mit anderen Worten, deaktivieren Sie es IMDSv1 auf allen vorhandenen und neuen Instanzen.

1. **Konfigurieren Sie bestehende Instanzen so, dass sie Folgendes erfordernIMDSv2:**

------
#### [ Amazon EC2 console ]

   1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Wählen Sie im Navigationsbereich **Instances** aus.

   1. Wählen Sie Ihre Instance aus.

   1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.

   1. Wählen Sie für **IMDSv2**die Option **Erforderlich** aus.

   1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

   Verwenden Sie den [modify-instance-metadata-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl, um anzugeben, IMDSv2 dass nur verwendet werden soll. 

------
**Anmerkung**  
Sie können diese Einstellung bei laufenden Instances ändern. Die Änderung wird sofort wirksam, ohne dass ein Neustart der Instanz erforderlich ist.

   Weitere Informationen finden Sie unter [Erfordern die Verwendung von IMDSv2](configuring-IMDS-existing-instances.md#modify-require-IMDSv2).

1. **Achten Sie nach der Deaktivierung IMDSv1 auf Probleme:**

   1. Verfolgen Sie anhand der `MetadataNoTokenRejected` CloudWatch Metrik, wie oft ein IMDSv1 Anruf versucht und abgelehnt wurde.

   1. Wenn die `MetadataNoTokenRejected` Metrik IMDSv1 Aufrufe einer Instanz aufzeichnet, bei der Softwareprobleme auftreten, bedeutet dies, dass die Software aktualisiert werden muss, damit sie verwendet IMDSv2 werden kann.

1. **Konfigurieren Sie neue Instanzen so, dass sie Folgendes erfordernIMDSv2:**

------
#### [ Amazon EC2 console ]

   1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Folgen Sie den Schritten, um [eine Instanz zu starten](ec2-launch-instance-wizard.md).

   1. Erweitern Sie **Erweiterte Details** und wählen Sie als **Metadaten-Version** **nur V2 aus (Token erforderlich)**.

   1. Überprüfen Sie im Bereich **Summary** (Übersicht) die Konfiguration Ihrer Instance und wählen Sie dann **Launch instance** (Instance starten) aus.

      Weitere Informationen finden Sie unter [Konfigurieren der Instance beim Start](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-instance-settings).

------
#### [ AWS CLI ]

   AWS CLI: Verwenden Sie den Befehl [run-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/run-instances.html) und geben Sie an, dass dies erforderlich IMDSv2 ist.

------

### Schritt 4: Stellen Sie IMDSv2 =required als Standard ein
<a name="path-step-4"></a>

Sie können IMDSv2 =required als Standardkonfiguration entweder auf Konto- oder Organisationsebene festlegen. Dadurch wird sichergestellt, dass alle neu gestarteten Instances automatisch so konfiguriert werden, dass sie Folgendes benötigen IMDSv2.

1. **Legen Sie den Standard auf Kontoebene fest:**

------
#### [ Amazon EC2 console ]

   1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Wählen Sie im Navigationsbereich **Dashboard (Dashboard)**.

   1. Wählen Sie auf der Karte **Kontoattribute** unter **Einstellungen** die Option **Datenschutz und Sicherheit** aus.

   1. **Wählen Sie unter **IMDS-Standardeinstellungen** die Option Verwalten aus.**

   1. **Wählen Sie für **Instance-Metadaten-Service** die Option Aktiviert aus.**

   1. Wählen Sie für die **Metadatenversion** **nur V2 aus (Token erforderlich)**.

   1. Wählen Sie **Aktualisieren** aus.

------
#### [ AWS CLI ]

   Verwenden Sie den [modify-instance-metadata-defaults](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-defaults.html)CLI-Befehl und geben Sie `--http-tokens required` und an`--http-put-response-hop-limit 2`.

------

   Weitere Informationen finden Sie unter [IMDSv2 Als Standard für das Konto festlegen](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).

1. **Alternativ können Sie mithilfe einer deklarativen Richtlinie den Standard auf Organisationsebene festlegen:**

   Verwenden Sie eine deklarative Richtlinie, um den Organisationsstandard für auf erforderlich festzulegen. IMDSv2 Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im *AWS Organizations Benutzerhandbuch*.

### Schritt 5: Erzwingen Sie, dass Instanzen Folgendes benötigen IMDSv2
<a name="path-step-5"></a>

Sobald Sie bestätigt haben, dass keine IMDSv1 Abhängigkeit von einer Ihrer Instances besteht, empfehlen wir Ihnen, dies für alle neuen Instances durchzusetzen IMDSv2 .

Verwenden Sie zur Durchsetzung eine der folgenden Optionen IMDSv2:

1. ** IMDSv2 Mit einer Kontoeigenschaft durchsetzen**

   Sie können die Verwendung von für jedes Konto IMDSv2 auf Kontoebene erzwingen AWS-Region. Wenn diese Option erzwungen wird, können Instances nur gestartet werden, wenn sie so konfiguriert sind, dass sie dies erfordern IMDSv2. Diese Durchsetzung gilt unabhängig davon, wie die Instance oder das AMI konfiguriert ist. Weitere Informationen finden Sie unter [IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level). Um diese Einstellung auf Organisationsebene anzuwenden, legen Sie eine deklarative Richtlinie fest. Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im *AWS Organizations Benutzerhandbuch*.

   Um zu verhindern, dass die Durchsetzung rückgängig gemacht wird, sollten Sie eine IAM-Richtlinie verwenden, um den Zugriff auf die API zu verhindern. [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html) Weitere Informationen finden Sie unter [Verwenden einer IAM-Richtlinie](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-iam-policy).
**Anmerkung**  
Diese Einstellung ändert nicht die IMDS-Version vorhandener Instances, blockiert jedoch die Aktivierung vorhandener Instances, die derzeit IMDSv1 deaktiviert sind. IMDSv1 
**Warnung**  
Wenn die IMDSv2 Erzwingung aktiviert `httpTokens` ist und weder `required` in der Instance-Konfiguration beim Start noch in den Kontoeinstellungen oder in der AMI-Konfiguration auf festgelegt ist, schlägt der Instance-Start fehl. Informationen zur Problembehebung finden Sie unter [Das Starten einer IMDSv1 -fähigen Instance schlägt fehl](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).

1. **Alternativ können Sie die IMDSv2 Erzwingung mithilfe der folgenden IAM- oder SCP-Bedingungsschlüssel erzwingen:**
   + `ec2:MetadataHttpTokens`
   + `ec2:MetadataHttpPutResponseHopLimit`
   + `ec2:MetadataHttpEndpoint`

   Diese Bedingungsschlüssel steuern die Verwendung der [RunInstances[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) APIs und der entsprechenden. CLIs Wenn eine Richtlinie erstellt wird und ein Parameter im API-Aufruf nicht mit dem in der Richtlinie über den Bedingungsschlüssel angegebenen Status übereinstimmt, schlägt der API- oder CLI-Aufruf mit einer `UnauthorizedOperation`-Antwort fehl.

   Beispiele für IAM-Richtlinien finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata).

# Zugriff auf den Instance-Metadaten-Service einschränken
<a name="instance-metadata-limiting-access"></a>

Sie können die Verwendung lokaler Firewall-Regeln in Betracht ziehen, um den Zugriff auf den Instance Metadata Service (IMDS) für einige oder alle Prozesse zu deaktivieren.

Bei [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) kann das IMDS von Ihrem eigenen Netzwerk aus erreicht werden, wenn eine Netzwerk-Appliance innerhalb Ihrer VPC, beispielsweise ein virtueller Router, Pakete an die IMDS-Adresse weiterleitet und die Standard-[Quell-/Zielprüfung](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck) der Instance deaktiviert ist. Um zu verhindern, dass eine Quelle von außerhalb Ihrer VPC den IMDS erreicht, empfehlen wir Ihnen, die Konfiguration der Netzwerk-Appliance so zu ändern, dass Pakete mit der IPv4 Zieladresse des IMDS `169.254.169.254` und, falls Sie den IPv6 Endpunkt aktiviert haben, der IPv6 Adresse des IMDS verworfen werden. `[fd00:ec2::254]`

## IMDS-Zugriff für Linux-Instances einschränken
<a name="instance-metadata-limiting-access-linux"></a>

**Verwendung von iptables zur Einschränkung des Zugriffs**

Das folgende Beispiel verwendet Linux-iptables und sein `owner`-Modul, um zu verhindern, dass der Apache-Webserver (basierend auf seiner Standardinstallationsbenutzer-ID von `apache`) auf 169.254.169.254 zugreift. Es verwendet eine *Ablehnungsregel*, um alle Instanz-Metadatenanfragen (unabhängig davon, ob IMDSv1 oder IMDSv2) von Prozessen, die unter diesem Benutzer ausgeführt werden, abzulehnen.

```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
```

Oder Sie können erwägen, nur bestimmten Benutzern oder Gruppen Zugriff zu gewähren, indem Sie *Zulassungsregeln* verwenden. Zulassungsregeln können aus Sicherheitssicht einfacher zu verwalten sein, da Sie eine Entscheidung darüber treffen müssen, welche Software Zugriff auf Instance-Metadaten benötigt. Wenn Sie *Zulassungsregeln* verwenden, ist es weniger wahrscheinlich, dass Sie Software versehentlich den Zugriff auf den Metadaten-Service erlauben (auf den sie nicht zugreifen soll), wenn Sie später die Software oder Konfiguration auf einer Instance ändern. Sie können außerdem Gruppen mit Zulassungsregeln kombinieren, sodass Sie Benutzer zu einer zugelassenen Gruppe hinzufügen und aus dieser entfernen können, ohne die Firewall-Regel ändern zu müssen.

Das folgende Beispiel verhindert den Zugriff auf den IMDS durch alle Prozesse, mit Ausnahme von Prozessen, die im Benutzerkonto `trustworthy-user` ausgeführt werden.

```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner trustworthy-user --jump REJECT
```

**Anmerkung**  
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen. 
Standardmäßig sind iptables-Regeln nicht über Systemneustarts hinweg persistent. Sie können durch die Verwendung von Betriebssystemfeatures, die hier nicht beschrieben werden, persistent gestaltet werden.
Das iptables `owner`-Modul überprüft nur dann die Gruppenzugehörigkeit, wenn die Gruppe die Primärgruppe eines bestimmten lokalen Benutzers ist. Andere Gruppen werden nicht abgeglichen.

**Verwendung von PF oder IPFW zur Einschränkung des Zugriffs**

Wenn Sie FreeBSD oder OpenBSD verwenden, können Sie überlegen, PF oder IPFW zu verwenden. Die folgenden Beispiele beschränken den Zugriff auf den IMDS auf den Root-Benutzer.

**PF**

```
$ block out inet proto tcp from any to 169.254.169.254
```

```
$ pass out inet proto tcp from any to 169.254.169.254 user root
```

**IPFW**

```
$ allow tcp from any to 169.254.169.254 uid root
```

```
$ deny tcp from any to 169.254.169.254
```

**Anmerkung**  
Die Reihenfolge der PF- und IPFW-Befehle ist von Bedeutung. PF verwendet standardmäßig die letzte übereinstimmende Regel und IPFW die erste übereinstimmende Regel.

## IMDS-Zugriff für Windows-Instances einschränken
<a name="instance-metadata-limiting-access-windows"></a>

**Verwenden der Windows-Firewall zur Zugriffsbeschränkung**

Im folgenden PowerShell Beispiel wird die integrierte Windows-Firewall verwendet, um zu verhindern, dass der Internet Information Server-Webserver (basierend auf seiner standardmäßigen Installationsbenutzer-ID von`NT AUTHORITY\IUSR`) auf 169.254.169.254 zugreift. Es verwendet eine *Ablehnungsregel*, um alle Instanz-Metadatenanforderungen (unabhängig davon, ob IMDSv1 oderIMDSv2) von Prozessen, die unter diesem Benutzer ausgeführt werden, abzulehnen.

```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("NT AUTHORITY\IUSR")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $BlockPrincipalSDDL = "D:(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service from IIS" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $BlockPrincipalSDDL
```

Oder Sie können erwägen, nur bestimmten Benutzern oder Gruppen Zugriff zu gewähren, indem Sie *Zulassungsregeln* verwenden. Zulassungsregeln können aus Sicherheitssicht einfacher zu verwalten sein, da Sie eine Entscheidung darüber treffen müssen, welche Software Zugriff auf Instance-Metadaten benötigt. Wenn Sie *Zulassungsregeln* verwenden, ist es weniger wahrscheinlich, dass Sie Software versehentlich den Zugriff auf den Metadaten-Service erlauben (auf den sie nicht zugreifen soll), wenn Sie später die Software oder Konfiguration auf einer Instance ändern. Sie können außerdem Gruppen mit Zulassungsregeln kombinieren, sodass Sie Benutzer zu einer zugelassenen Gruppe hinzufügen und aus dieser entfernen können, ohne die Firewall-Regel ändern zu müssen.

Das folgende Beispiel verhindert den Zugriff auf Instance-Metadaten durch alle Prozesse, die als OS-Gruppe ausgeführt werden, die in der Variable `blockPrincipal` angegeben ist (in diesem Beispiel die Windows-Gruppe `Everyone`), mit Ausnahme der in `exceptionPrincipal` angegebenen Prozesse (in diesem Beispiel eine Gruppe namens `trustworthy-users`). Sie müssen für Prinzipale den Zugriff verweigern und ablehnen, da die Windows-Firewall im Gegensatz zur `! --uid-owner trustworthy-user`-Regel in Linux-iptables keinen Mechanismus zur Verfügung stellt, um nur einen bestimmten Prinzipal (Benutzer oder Gruppe) zuzulassen, indem alle anderen abgelehnt werden.

```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("Everyone")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $exceptionPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("trustworthy-users")
PS C:\> $ExceptionPrincipalSID = $exceptionPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $PrincipalSDDL = "O:LSD:(D;;CC;;;$ExceptionPrincipalSID)(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service for $($blockPrincipal.Value), exception: $($exceptionPrincipal.Value)" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $PrincipalSDDL
```

**Anmerkung**  
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen. 

**Verwenden von netsh-Regeln zur Zugriffsbeschränkung**

Sie können erwägen, die gesamte Software mit `netsh`-Regeln zu blockieren. Diese sind jedoch viel weniger flexibel.

```
C:\> netsh advfirewall firewall add rule name="Block metadata service altogether" dir=out protocol=TCP remoteip=169.254.169.254 action=block
```

**Anmerkung**  
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen. 
`netsh`-Regeln müssen von einer Eingabeaufforderung mit erhöhten Rechten aus festgelegt werden und können nicht so konfiguriert werden, dass sie bestimmte Prinzipale verweigern oder zulassen.

# Konfigurieren der Optionen des Instance-Metadaten-Services
<a name="configuring-instance-metadata-options"></a>

Der Instance Metadata Service (IMDS) wird lokal auf jeder EC2-Instance ausgeführt. Die *Instance-Metadatenoptionen* beziehen sich auf eine Reihe von Konfigurationen, welche die Zugänglichkeit und das Verhalten des IMDS auf einer EC2-Instance steuern.

Sie können die folgenden Optionen für Instance-Metadaten für jede Instance konfigurieren:

**Instance Metadata Service (IMDS)**: `enabled` \$1 `disabled`  
Sie können den IMDS auf einer Instance aktivieren oder deaktivieren. Wenn diese Option deaktiviert ist, können Sie oder ein anderer Code nicht auf die Instance-Metadaten auf der Instance zugreifen.  
Das IMDS hat zwei Endpunkte auf einer Instanz: IPv4 (`169.254.169.254`) und IPv6 (). `[fd00:ec2::254]` Wenn Sie das IMDS aktivieren, wird der IPv4 Endpunkt automatisch aktiviert. Wenn Sie den IPv6 Endpunkt aktivieren möchten, müssen Sie dies explizit tun.

** IPv6 IMDS-Endpunkt**: \$1 `enabled` `disabled`  
Sie können den IPv6 IMDS-Endpunkt auf einer Instanz explizit aktivieren. Wenn der IPv6 Endpunkt aktiviert ist, bleibt der IPv4 Endpunkt aktiviert. Der IPv6 Endpunkt wird nur auf [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) in [Subnetzen unterstützt, die IPv6 von -unterstützt werden](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (Dual Stack oder IPv6 nur).

**Metadaten-Version**: `IMDSv1 or IMDSv2 (token optional)` \$1 `IMDSv2 only (token required)`  
Bei der Anforderung von Instanz-Metadaten ist für IMDSv2 Aufrufe ein Token erforderlich. IMDSv1Für Aufrufe ist kein Token erforderlich. Sie können eine Instanz so konfigurieren, dass sie entweder IMDSv1 oder IMDSv2 -Aufrufe zulässt (wobei ein Token optional ist) oder dass sie nur IMDSv2 Aufrufe zulässt (wenn ein Token erforderlich ist).

**Metadaten-Antwort-Hop-Limits**: `1`   – `64`  
Das Hop-Limit ist die Anzahl der Netzwerk-Hops, die PUT-Antwort ausführen darf. Sie können das Hop-Limit auf ein Minimum von `1` und ein Maximum von `64` festlegen. In einer Container-Umgebung kann ein Hop-Limit von `1` zu Problemen führen. Informationen zur Behebung dieser Probleme finden Sie in den Informationen zu Containerumgebungen unter [Überlegungen zum Instance-Zugriff auf Instance-Metadaten](instancedata-data-retrieval.md#imds-considerations).

**Zugriffs auf Tags in Instance-Metadaten**: `enabled` \$1 `disabled`  
Sie können den Zugriff auf die Tags der Instance in den Metadaten der Instance aktivieren oder deaktivieren. Weitere Informationen finden Sie unter [Tags für Ihre EC2-Instances mithilfe von Instance-Metadaten anzeigen](work-with-tags-in-IMDS.md).

Informationen zum Anzeigen der aktuellen Konfiguration einer Instance finden Sie unter [Abfragen von Instance-Metadatenoptionen für vorhandene Instances](instancedata-data-retrieval.md#query-IMDS-existing-instances).

## Konfigurieren der Instance-Metadaten-Optionen
<a name="where-to-configure-instance-metadata-options"></a>

Die Optionen für Instance-Metadaten können wie folgt auf verschiedenen Ebenen konfiguriert werden:
+ **Konto** – Sie können Standardwerte für die Instance-Metadatenoptionen auf Kontoebene für jede AWS-Region festlegen. Wenn eine Instance gestartet wird, werden die Optionen für die Instance-Metadaten automatisch auf die Werte auf Kontoebene festgelegt. Sie können diese Werte beim Start ändern. Standardwerte auf Kontoebene wirken sich nicht auf bestehende Instances aus.
+ **AMI** – Wenn Sie ein neues AMI registrieren oder ein vorhandenes AMI ändern, können Sie den Parameter `imds-support` auf `v2.0` setzen. Wenn eine Instance mit diesem AMI gestartet wird, wird die Version der Instance-Metadaten automatisch auf IMDSv2 und das Hop-Limit auf 2 gesetzt.
+ **Instance** – Sie können alle Optionen für Instance-Metadaten einer Instance beim Start ändern und dabei die Standardeinstellungen überschreiben. Sie können auch nach dem Start auf einer ausgeführten oder angehaltenen Instance die Instance-Metadaten-Optionen ändern. Beachten Sie, dass Änderungen möglicherweise durch eine IAM- oder SCP-Richtlinie eingeschränkt werden.

Weitere Informationen erhalten Sie unter [Konfigurieren von Instance-Metadatenoptionen für neue Instances](configuring-IMDS-new-instances.md) und [Modifizieren von Instance-Metadatenoptionen für vorhandene Instances](configuring-IMDS-existing-instances.md).

## Rangfolge der Optionen für Instance-Metadaten
<a name="instance-metadata-options-order-of-precedence"></a>

Der Wert für jede Instance-Metadatenoption wird beim Start der Instance in einer hierarchischen Rangfolge festgelegt. Die Hierarchie mit der höchsten Priorität an oberster Stelle sieht wie folgt aus:
+ **Priorität 1: Instance-Konfiguration beim Start** – Werte können entweder in der Startvorlage oder in der Instance-Konfiguration angegeben werden. Alle hier angegebenen Werte haben Vorrang vor Werten, die auf Kontoebene oder im AMI angegeben wurden.
+ **Priorität 2: Kontoeinstellungen** — Wenn beim Start der Instance kein Wert angegeben wird, wird er durch die Einstellungen auf Kontoebene bestimmt (die für jede Instanz festgelegt sind). AWS-Region Einstellungen auf Kontoebene enthalten entweder einen Wert für jede Metadatenoption oder geben an, dass überhaupt keine Präferenz ausgewählt wird.
+ **Priorität 3: AMI-Konfiguration** – Wenn beim Start der Instance oder auf Kontoebene kein Wert angegeben wird, wird er durch die AMI-Konfiguration bestimmt. Dies gilt nur für `HttpTokens` und `HttpPutResponseHopLimit`.

Jede Metadatenoption wird separat bewertet. Die Instance kann mit einer Mischung aus direkter Instance-Konfiguration, Standardeinstellungen auf Kontoebene und der Konfiguration aus dem AMI konfiguriert werden.

Sie können den Wert jeder Metadatenoption nach dem Start einer laufenden oder angehaltenen Instance ändern, sofern die Änderungen nicht durch eine IAM- oder SCP-Richtlinie eingeschränkt sind.

**Anmerkung**  
Die Einstellung für die IMDSv2 Durchsetzung auf Kontoebene wird bewertet, nachdem die IMDS-Einstellungen der Instanz anhand der Rangfolge festgelegt wurden. Wenn die IMDSv2 Durchsetzung aktiviert ist, schlagen Instances fehl, die mit aktiviert wurden. IMDSv1 Weitere Informationen zur Durchsetzung finden Sie unter[IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

**Warnung**  
Wenn die IMDSv2 Erzwingung aktiviert `httpTokens` ist und weder `required` in der Instance-Konfiguration beim Start noch in den Kontoeinstellungen oder in der AMI-Konfiguration darauf festgelegt wurde, schlägt Ihr Start fehl.

**Beispiel 1 — Ermitteln Sie Werte für Metadatenoptionen**

In diesem Beispiel wird eine EC2-Instance in einer Region gestartet, für die das `HttpPutResponseHopLimit` auf `1` auf Kontoebene festgelegt ist. Das angegebene AMI hat `ImdsSupport` auf `v2.0` eingestellt. Beim Start werden keine Metadatenoptionen direkt auf der Instance angegeben. Die Instance wird mit den folgenden Metadatenoptionen gestartet:

```
"MetadataOptions": {
    ...
    "HttpTokens": "required",
    "HttpPutResponseHopLimit": 1,
    ...
```

Diese Werte wurden wie folgt bestimmt:
+ **Beim Start wurden keine Metadatenoptionen angegeben:** Beim Start der Instance wurden weder in den Instance-Startparametern noch in der Startvorlage spezifische Werte für die Metadatenoptionen angegeben.
+ **Kontoeinstellungen haben als Nächstes Vorrang:** Wenn beim Start keine spezifischen Werte angegeben wurden, haben die Einstellungen auf Kontoebene innerhalb der Region Vorrang. Das bedeutet, dass die auf Kontoebene konfigurierten Standardwerte angewendet werden. In diesem Fall wurde der `HttpPutResponseHopLimit` auf `1` gesetzt.
+ **AMI-Einstellungen haben letzten Vorrang:** Wenn beim Start oder auf Kontoebene kein bestimmter Wert angegeben wurde für `HttpTokens` (die Instance-Metadatenversion), wird die AMI-Einstellung angewendet. In diesem Fall wurde anhand der AMI-Einstellung `ImdsSupport: v2.0` festgelegt, dass `HttpTokens` auf `required` eingestellt war. Beachten Sie, dass die AMI-Einstellung `ImdsSupport: v2.0` zwar für die Einstellung `HttpPutResponseHopLimit: 2` vorgesehen ist, sie jedoch durch die Einstellung `HttpPutResponseHopLimit: 1` auf Kontoebene, die höhere Priorität hat, außer Kraft gesetzt wurde.

**Beispiel 2 — Ermitteln Sie Werte für Metadatenoptionen**

In diesem Beispiel wird die EC2-Instance mit den gleichen Einstellungen wie im vorherigen Beispiel 1 gestartet, allerdings `HttpTokens` mit der Einstellung `optional` direkt auf der Instance beim Start. Die Instance wird mit den folgenden Metadatenoptionen gestartet:

```
"MetadataOptions": {
    ...
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    ...
```

Der Wert für `HttpPutResponseHopLimit` wird auf die gleiche Weise wie in Beispiel 1 bestimmt. Der Wert für `HttpTokens` wird jedoch wie folgt bestimmt: Metadatenoptionen, die beim Start auf der Instance konfiguriert wurden, haben Vorrang. Obwohl das AMI mit `ImdsSupport: v2.0` konfiguriert war (mit anderen Worten `HttpTokens` ist auf`required` gesetzt), hatte der Wert, der beim Start auf der Instance angegeben wurde (`HttpTokens` gesetzt auf `optional`), Vorrang.

**Beispiel 3 — Ermitteln Sie Werte für Metadatenoptionen, wenn HttpTokensEnforced diese Option aktiviert ist**

In diesem Beispiel hat das Konto in der Region `HttpTokens = required` und`HttpTokensEnforced = enabled`.

Betrachten Sie die folgenden Versuche, eine EC2-Instance zu starten:
+ Startversuch mit `HttpTokens` Einstellung auf `optional` — Der Start schlägt fehl, weil die Durchsetzung auf Kontoebene aktiviert ist (`HttpTokensEnforced = enabled`) und der Startparameter Vorrang vor der Standardeinstellung für das Konto hat.
+ Startversuch mit `HttpTokens` Einstellung auf `required` — Der Start ist erfolgreich, weil er den Vorschriften für die Durchsetzung auf Kontoebene entspricht. 
+ Startversuch ohne Angabe eines `HttpTokens` Werts — Der Start ist erfolgreich, da der Standardwert auf der `required` Grundlage der Kontoeinstellungen voreingestellt ist. 

### Version der Instance-Metadaten festlegen
<a name="metadata-version-order-of-precedence"></a>

Wenn eine Instance gestartet wird, lautet der Wert für die *Version der Instance-Metadaten* entweder **IMDSv1 oder IMDSv2 (Token optional)** (`httpTokens=optional`) oder **IMDSv2nur (Token erforderlich) (`httpTokens=required`)**.

Beim Start der Instance können Sie den Wert für die Metadatenversion entweder manuell angeben oder den Standardwert verwenden. Wenn Sie den Wert manuell angeben, überschreibt er alle Standardwerte. Wenn Sie den Wert nicht manuell angeben möchten, wird er durch eine Kombination von Standardeinstellungen bestimmt.

Das folgende Flussdiagramm zeigt, wie die Metadatenversion für eine Instance beim Start durch die Einstellungen auf den verschiedenen Konfigurationsebenen bestimmt wird und wo die Durchsetzung bewertet wird. Die folgende Tabelle enthält die spezifischen Einstellungen auf jeder Ebene.

![\[Ein Flussdiagramm, das die Evaluierungspunkte für die Version und IMDSv2 Durchsetzung der Instanz-Metadaten zeigt.\]](http://docs.aws.amazon.com/de_de/AWSEC2/latest/UserGuide/images/imds-defaults-launch-flow.png)


Die Tabelle zeigt, wie die Metadatenversion für eine Instance beim Start (angezeigt durch **Resultierende Instance-Konfiguration** in Spalte 4) durch die Einstellungen auf den verschiedenen Konfigurationsebenen bestimmt wird. Die Rangfolge erfolgt von links nach rechts, wobei die erste Spalte den höchsten Vorrang hat, und zwar wie folgt:
+ Spalte 1: **Startparameter** – Stellt die Einstellung für die Instance dar, die Sie beim Start manuell angeben.
+ Spalte 2: **Standard auf Kontoebene** – Stellt die Einstellung für das Konto dar.
+ Spalte 3: **AMI-Standard** – Stellt die Einstellung auf dem AMI dar.


| Startparameter | Standard auf Kontoebene | Standard-AMI | Resultierende Instance-Konfiguration | 
| --- | --- | --- | --- | 
| Nur V2 (Token erforderlich) | Keine Präferenz | Nur V2 | Nur V2 | 
| Nur V2 (Token erforderlich) | Nur V2 | Nur V2 | Nur V2 | 
| Nur V2 (Token erforderlich) | V1 oder V2 | Nur V2 | Nur V2 | 
| V1 oder V2 (Token optional) | Keine Präferenz | Nur V2 | V1 oder V2 | 
| V1 oder V2 (Token optional) | Nur V2 | Nur V2 | V1 oder V2 | 
| V1 oder V2 (Token optional) | V1 oder V2 | Nur V2 | V1 oder V2 | 
| Nicht gesetzt | Keine Präferenz | Nur V2 | Nur V2 | 
| Nicht gesetzt | Nur V2 | Nur V2 | Nur V2 | 
| Nicht gesetzt | V1 oder V2 | Nur V2 | V1 oder V2 | 
| Nur V2 (Token erforderlich) | Keine Präferenz | Null | Nur V2 | 
| Nur V2 (Token erforderlich) | Nur V2 | Null | Nur V2 | 
| Nur V2 (Token erforderlich) | V1 oder V2 | Null | Nur V2 | 
| V1 oder V2 (Token optional) | Keine Präferenz | Null | V1 oder V2 | 
| V1 oder V2 (Token optional) | Nur V2 | Null | V1 oder V2 | 
| V1 oder V2 (Token optional) | V1 oder V2 | Null | V1 oder V2 | 
| Nicht gesetzt | Keine Präferenz | Null | V1 oder V2 | 
| Nicht gesetzt | Nur V2 | Null | Nur V2 | 
| Nicht gesetzt | V1 oder V2 | Null | V1 oder V2 | 

## Verwenden Sie IAM-Bedingungsschlüssel, um die Optionen für Instance-Metadaten einzuschränken
<a name="iam-condition-keys-and-imds"></a>

Sie können auch IAM-Bedingungsschlüssel in einer IAM-Richtlinie oder SCP wie folgt verwenden:
+ Zulassen, dass eine Instance nur gestartet wird, wenn sie so konfiguriert ist, dass sie die Verwendung von IMDSv2 erzwingt
+ Beschränken der Anzahl der zulässigen Hops
+ Deaktivieren des Zugriffs auf Instance-Metadaten

**Topics**
+ [

## Konfigurieren der Instance-Metadaten-Optionen
](#where-to-configure-instance-metadata-options)
+ [

## Rangfolge der Optionen für Instance-Metadaten
](#instance-metadata-options-order-of-precedence)
+ [

## Verwenden Sie IAM-Bedingungsschlüssel, um die Optionen für Instance-Metadaten einzuschränken
](#iam-condition-keys-and-imds)
+ [

# Konfigurieren von Instance-Metadatenoptionen für neue Instances
](configuring-IMDS-new-instances.md)
+ [

# Modifizieren von Instance-Metadatenoptionen für vorhandene Instances
](configuring-IMDS-existing-instances.md)

**Anmerkung**  
Sie sollten vorsichtig vorgehen und sorgfältige Tests durchführen, bevor Sie Änderungen vornehmen. Beachten Sie die folgenden Punkte:  
Wenn Sie die Verwendung von erzwingen IMDSv2, werden Anwendungen oder Agenten, die IMDSv1 beispielsweise den Zugriff auf Instanzmetadaten verwenden, unterbrochen.
Wenn Sie den gesamten Zugriff auf Instance-Metadaten deaktivieren, werden Anwendungen oder Agenten, die auf Instance-Metadaten angewiesen sind, den Zugriff auf die Funktion verlieren.
Denn IMDSv2 müssen Sie `/latest/api/token` beim Abrufen des Tokens verwenden.
(Nur Windows) Wenn Ihre PowerShell Version älter als 4.0 ist, müssen Sie [auf Windows Management Framework 4.0 aktualisieren](https://devblogs.microsoft.com/powershell/windows-management-framework-wmf-4-0-update-now-available-for-windows-server-2012-windows-server-2008-r2-sp1-and-windows-7-sp1/), um die Verwendung von IMDSv2 zu erfordern.

# Konfigurieren von Instance-Metadatenoptionen für neue Instances
<a name="configuring-IMDS-new-instances"></a>

Sie können die folgenden Instance-Metadatenoptionen für neue Instances konfigurieren.

**Topics**
+ [

## Erfordert die Verwendung von IMDSv2
](#configure-IMDS-new-instances)
+ [

## Aktivieren Sie das IMDS IPv4 und die Endpoints IPv6
](#configure-IMDS-new-instances-ipv4-ipv6-endpoints)
+ [

## Deaktivieren des Zugriffs auf Instance-Metadaten
](#configure-IMDS-new-instances--turn-off-instance-metadata)
+ [

## Zulassen des Zugriffs auf Tags in Instance-Metadaten
](#configure-IMDS-new-instances-tags-in-instance-metadata)

**Anmerkung**  
Diese Einstellung wird auf Kontoebene konfiguriert, entweder direkt im Konto oder mithilfe einer deklarativen Richtlinie. Sie müssen in jeder AWS-Region konfiguriert werden, in der Sie die Optionen für Instance-Metadaten konfigurieren möchten. Mithilfe einer deklarativen Richtlinie können Sie die Einstellung auf mehrere Regionen gleichzeitig, sowie auf mehrere Konten gleichzeitig anwenden. Wenn eine deklarative Richtlinie verwendet wird, können Sie die Einstellung nicht direkt in einem Konto ändern. In diesem Thema wird beschrieben, wie Sie die Einstellung direkt in einem Konto konfigurieren. Informationen zur Verwendung deklarativer Richtlinien finden Sie unter [Deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im *AWS Organizations -Benutzerhandbuch*.

## Erfordert die Verwendung von IMDSv2
<a name="configure-IMDS-new-instances"></a>

Sie können die folgenden Methoden verwenden, um die Verwendung von IMDSv2 auf Ihren neuen Instances vorzuschreiben.

**Topics**
+ [

### IMDSv2 Als Standard für das Konto festlegen
](#set-imdsv2-account-defaults)
+ [

### IMDSv2 Auf Kontoebene durchsetzen
](#enforce-imdsv2-at-the-account-level)
+ [

### Konfigurieren der Instance beim Start
](#configure-IMDS-new-instances-instance-settings)
+ [

### Konfigurieren des AMI
](#configure-IMDS-new-instances-ami-configuration)
+ [

### Verwenden einer IAM-Richtlinie
](#configure-IMDS-new-instances-iam-policy)

### IMDSv2 Als Standard für das Konto festlegen
<a name="set-imdsv2-account-defaults"></a>

Sie können die Standardversion für den Instanz-Metadaten-Service (IMDS) jeweils AWS-Region auf Kontoebene festlegen. Das heißt, wenn Sie eine *neue* Instance starten, wird die Instance-Metadatenversion automatisch auf den Standard auf Kontoebene gesetzt. Sie können den Wert jedoch beim Start oder nach dem Start manuell überschreiben. Weitere Informationen darüber, wie sich Einstellungen auf Kontoebene und manuelle Überschreibungen auf eine Instance auswirken, finden Sie unter [Rangfolge der Optionen für Instance-Metadaten](configuring-instance-metadata-options.md#instance-metadata-options-order-of-precedence).

**Anmerkung**  
*Durch das Festlegen der Standardeinstellung auf Kontoebene werden bestehende Instances nicht zurückgesetzt.* Wenn Sie beispielsweise die Standardeinstellung auf Kontoebene auf festlegen, sind alle vorhandenen Instanzen IMDSv2, die auf festgelegt sind, nicht betroffen IMDSv1 . Wenn Sie den Wert für bestehende Instances ändern möchten, müssen Sie den Wert für die Instances selbst manuell ändern.

Sie können den Kontostandard für die Version der Instanz-Metadaten auf festlegen, IMDSv2 sodass alle *neuen* Instances im Konto mit IMDSv2 erforderlich gestartet werden und deaktiviert IMDSv1 werden. Bei diesem standardmäßigen Konto gelten beim Start einer Instance die folgenden Standardwerte für die Instance:
+ Konsole: Die **Metadatenversion** ist **nur auf V2 festgelegt (Token erforderlich)** und das **Limit für den Metadaten-Response-Hop** ist auf **2** festgelegt.
+ AWS CLI: `HttpTokens` ist auf `required` gesetzt und `HttpPutResponseHopLimit` ist auf `2` gesetzt. 

**Anmerkung**  
Bevor Sie den Kontostandard auf festlegen IMDSv2, stellen Sie sicher, dass Ihre Instances nicht von abhängig sind IMDSv1. Weitere Informationen finden Sie unter [Empfohlener Pfad zur Anforderung IMDSv2](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2).

------
#### [ Console ]

**Um es IMDSv2 als Standard für das Konto für die angegebene Region festzulegen**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Um das zu ändern AWS-Region, verwenden Sie die Regionsauswahl in der oberen rechten Ecke der Seite.

1. Wählen Sie im Navigationsbereich **Dashboard (Dashboard)**.

1. Wählen Sie auf der Karte **Kontoattribute** unter **Einstellungen** die Option **Datenschutz** und Sicherheit aus.

1. Wählen Sie neben **IMDS-Standardeinstellungen** die Option **Verwalten** aus.

1. Gehen Sie auf der Seite **IMDS-Standardwerte verwalten** wie folgt vor:

   1. Für den **Instance-Metadaten-Services** wählen Sie die Option **Aktivieren**.

   1. Wählen Sie für **Metadatenversion** die Option **Nur V2 (Token erforderlich)** aus.

   1. Geben Sie für **Metadaten-Antwort-Hop-Limit** den Wert **2** an, wenn Ihre Instances Container hosten sollen. Wählen Sie andernfalls **Keine Präferenz** aus. Wenn keine Präferenz angegeben wird, ist der Wert beim Start standardmäßig **2**, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig **1**.

   1. Wählen Sie **Aktualisieren** aus.

------
#### [ AWS CLI ]

**Um es IMDSv2 als Standard für das Konto für die angegebene Region festzulegen**  
Verwenden Sie den [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html)Befehl und geben Sie die Region an, in der die Einstellungen auf IMDS-Kontoebene geändert werden sollen. Schließen Sie die Einstellung `--http-tokens` auf `required` ein und legen Sie `--http-put-response-hop-limit` auf `2` fest, wenn Ihre Instances Container hosten werden. Geben Sie andernfalls `-1` an, dass keine Präferenz angegeben werden soll. Wenn `-1` (keine Präferenz) angegeben wird, ist der Wert beim Start standardmäßig `2`, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig `1`.

```
aws ec2 modify-instance-metadata-defaults \
    --region us-east-1 \
    --http-tokens required \
    --http-put-response-hop-limit 2
```

Es folgt eine Beispielausgabe.

```
{
    "Return": true
}
```

**So zeigen Sie die Standard-Kontoeinstellungen für die Instance-Metadatenoptionen für die angegebene Region an**  
Verwenden Sie den [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html)Befehl und geben Sie die Region an.

```
aws ec2 get-instance-metadata-defaults --region us-east-1
```

Es folgt eine Beispielausgabe.

```
{
    "AccountLevel": {
        "HttpTokens": "required",
        "HttpPutResponseHopLimit": 2
    },
    "ManagedBy": "account"
}
```

Das `ManagedBy`-Feld gibt die Entität an, die die Einstellung konfiguriert hat. `account` zeigt in diesem Beispiel an, dass die Einstellung direkt im Konto konfiguriert wurde. Ein Wert von `declarative-policy` würde bedeuten, dass die Einstellung durch eine deklarative Richtlinie konfiguriert wurde. Weitere Informationen finden Sie unter [Deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im *AWS Organizations -Benutzerhandbuch*.

**Um es IMDSv2 als Standard für das Konto für alle Regionen festzulegen**  
Verwenden Sie den [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html)Befehl, um die Einstellungen auf IMDS-Kontoebene für alle Regionen zu ändern. Schließen Sie die Einstellung `--http-tokens` auf `required` ein und legen Sie `--http-put-response-hop-limit` auf `2` fest, wenn Ihre Instances Container hosten werden. Geben Sie andernfalls `-1` an, dass keine Präferenz angegeben werden soll. Wenn `-1` (keine Präferenz) angegeben wird, ist der Wert beim Start standardmäßig `2`, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig `1`.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens required \
            --http-put-response-hop-limit 2 \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

Es folgt eine Beispielausgabe.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**So zeigen Sie die Standard-Kontoeinstellungen für die Instance-Metadatenoptionen für alle Regionen an**  
Verwenden Sie den Befehl [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html).

```
echo -e "Region   \t Level          Hops    HttpTokens" ; \
echo -e "-------------- \t ------------   ----    ----------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 get-instance-metadata-defaults \
            --region $region \
            --output text)
        echo -e "$region \t $output" 
    );
done
```

Es folgt eine Beispielausgabe.

```
Region           Level          Hops    HttpTokens
--------------   ------------   ----    ----------
ap-south-1       ACCOUNTLEVEL   2       required
eu-north-1       ACCOUNTLEVEL   2       required
eu-west-3        ACCOUNTLEVEL   2       required
...
```

------
#### [ PowerShell ]

**Um es IMDSv2 als Standard für das Konto für die angegebene Region festzulegen**  
Verwenden Sie das [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html)Cmdlet und geben Sie die Region an, in der die Einstellungen auf IMDS-Kontoebene geändert werden sollen. Schließen Sie die Einstellung `-HttpToken` auf `required` ein und legen Sie `-HttpPutResponseHopLimit` auf `2` fest, wenn Ihre Instances Container hosten werden. Geben Sie andernfalls `-1` an, dass keine Präferenz angegeben werden soll. Wenn `-1` (keine Präferenz) angegeben wird, ist der Wert beim Start standardmäßig `2`, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig `1`.

```
Edit-EC2InstanceMetadataDefault `
    -Region us-east-1 `
    -HttpToken required `
    -HttpPutResponseHopLimit 2
```

Es folgt eine Beispielausgabe.

```
True
```

**So zeigen Sie die Standard-Kontoeinstellungen für die Instance-Metadatenoptionen für die angegebene Region an**  
Verwenden Sie das [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html)Cmdlet und geben Sie die Region an.

```
Get-EC2InstanceMetadataDefault -Region us-east-1 | Format-List
```

Es folgt eine Beispielausgabe.

```
HttpEndpoint            : 
HttpPutResponseHopLimit : 2
HttpTokens              : required
InstanceMetadataTags    :
```

**Um es IMDSv2 als Standard für das Konto für alle Regionen festzulegen**  
Verwenden Sie das [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html)Cmdlet, um die Einstellungen auf IMDS-Kontoebene für alle Regionen zu ändern. Schließen Sie die Einstellung `-HttpToken` auf `required` ein und legen Sie `-HttpPutResponseHopLimit` auf `2` fest, wenn Ihre Instances Container hosten werden. Geben Sie andernfalls `-1` an, dass keine Präferenz angegeben werden soll. Wenn `-1` (keine Präferenz) angegeben wird, ist der Wert beim Start standardmäßig `2`, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig `1`.

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region   = $_
        Modified = (Edit-EC2InstanceMetadataDefault `
                -Region $_ `
                -HttpToken required `
                -HttpPutResponseHopLimit 2)
    } 
} | `
Format-Table Region, Modified -AutoSize
```

Erwartete Ausgabe

```
Region         Modified
------         --------
ap-south-1         True
eu-north-1         True
eu-west-3          True
...
```

**So zeigen Sie die Standard-Kontoeinstellungen für die Instance-Metadatenoptionen für alle Regionen an**  
Verwenden Sie das cmdlet [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html).

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region = $_
        HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
        HttpTokens              = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
    }
} | `
Format-Table -AutoSize
```

Beispielausgabe

```
Region         HttpPutResponseHopLimit HttpTokens
------         ----------------------- ----------
ap-south-1                           2 required
eu-north-1                           2 required
eu-west-3                            2 required                    
...
```

------

### IMDSv2 Auf Kontoebene durchsetzen
<a name="enforce-imdsv2-at-the-account-level"></a>

Sie können die Verwendung von jeweils IMDSv2 auf Kontoebene durchsetzen AWS-Region. Wenn diese Option erzwungen wird, können Instances nur gestartet werden, wenn sie so konfiguriert sind, dass sie dies erfordernIMDSv2. Diese Durchsetzung gilt unabhängig davon, wie die Instance oder das AMI konfiguriert ist.

**Anmerkung**  
Bevor Sie die IMDSv2 Durchsetzung auf Kontoebene aktivieren, stellen Sie sicher, dass Ihre Anwendungen und Ihr AMIs Support IMDSv2 Weitere Informationen finden Sie unter [Empfohlener Pfad zur Anforderung IMDSv2](instance-metadata-transition-to-version-2.md#recommended-path-for-requiring-imdsv2). Wenn die IMDSv2 Erzwingung aktiviert `httpTokens` ist und weder `required` in der Instance-Konfiguration beim Start noch in den Kontoeinstellungen oder in der AMI-Konfiguration auf festgelegt ist, schlägt der Instance-Start fehl. Informationen zur Problembehebung finden Sie unter [Das Starten einer IMDSv1 -fähigen Instance schlägt fehl](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).

**Anmerkung**  
Diese Einstellung ändert nicht die IMDS-Version vorhandener Instances, blockiert jedoch die Aktivierung IMDSv1 vorhandener Instances, die derzeit IMDSv1 deaktiviert sind.

------
#### [ Console ]

**Um dies IMDSv2 für das Konto in der angegebenen Region durchzusetzen**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Um das zu ändern AWS-Region, verwenden Sie die Regionsauswahl in der oberen rechten Ecke der Seite.

1. Wählen Sie im Navigationsbereich **Dashboard (Dashboard)**.

1. Wählen Sie auf der Karte **Kontoattribute** unter **Einstellungen** die Option **Datenschutz und Sicherheit** aus.

1. Wählen Sie neben **IMDS-Standardeinstellungen** die Option **Verwalten** aus.

1. Gehen Sie auf der Seite **IMDS-Standardwerte verwalten** wie folgt vor:

   1. Wählen Sie für **Metadatenversion** die Option **Nur V2 (Token erforderlich)** aus.

   1. Wählen Sie für „**Erzwingen IMDSv2**“ die Option **Aktiviert** aus.

   1. Wählen Sie **Aktualisieren** aus.

------
#### [ AWS CLI ]

**Um dies IMDSv2 für das Konto in der angegebenen Region durchzusetzen**  
 Verwenden Sie den [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html)Befehl und geben Sie die Region an, in der die Durchsetzung erfolgen soll IMDSv2. 

```
aws ec2 modify-instance-metadata-defaults \
    --region us-east-1 \
    --http-tokens required \
    --http-tokens-enforced enabled
```

Es folgt eine Beispielausgabe.

```
{
"Return": true
}
```

**Um die IMDSv2 Erzwingungseinstellungen für das Konto in einer bestimmten Region anzuzeigen**  
Verwenden Sie den [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html)Befehl und geben Sie die Region an.

```
aws ec2 get-instance-metadata-defaults --region us-east-1
```

Es folgt eine Beispielausgabe.

```
{
    "AccountLevel": {
        "HttpTokens": "required",
        "HttpTokensEnforced": "enabled"
    },
    "ManagedBy": "account"
}
```

Das `ManagedBy`-Feld gibt die Entität an, die die Einstellung konfiguriert hat. `account` zeigt in diesem Beispiel an, dass die Einstellung direkt im Konto konfiguriert wurde. Ein Wert von `declarative-policy` würde bedeuten, dass die Einstellung durch eine deklarative Richtlinie konfiguriert wurde. Weitere Informationen finden Sie unter [Declarative Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im *AWS Organizations User Guide*.

**Um das Konto IMDSv2 für alle Regionen durchzusetzen**  
Verwenden Sie den [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html)Befehl, um die Durchsetzung IMDSv2 in allen Regionen durchzusetzen.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens-enforced enabled \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

Es folgt eine Beispielausgabe.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**Um die IMDSv2 Durchsetzungseinstellungen für das Konto in allen Regionen einzusehen**  
Verwenden Sie den Befehl [get-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-metadata-defaults.html).

```
echo -e "Region   \t Level           HttpTokensEnforced" ; \
echo -e "-------------- \t ------------   ----------------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 get-instance-metadata-defaults \
            --region $region \
            --query 'AccountLevel.HttpTokensEnforced' \           
            --output text)
        echo -e "$region \t ACCOUNTLEVEL $output" 
    );
done
```

Es folgt eine Beispielausgabe.

```
Region           Level          HttpTokensEnforced
--------------   ------------   ------------------
ap-south-1       ACCOUNTLEVEL   enabled
eu-north-1       ACCOUNTLEVEL   enabled
eu-west-3        ACCOUNTLEVEL   enabled
...
```

------
#### [ PowerShell ]

**Um die Durchsetzung IMDSv2 für das Konto in der angegebenen Region durchzusetzen**  
Verwenden Sie das [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html)Cmdlet und geben Sie die Region an, in der die Durchsetzung erfolgen soll. IMDSv2 

```
Edit-EC2InstanceMetadataDefault `
    -Region us-east-1 `
    -HttpToken required `
    -HttpPutResponseHopLimit 2
```

Es folgt eine Beispielausgabe.

```
@{
    Return = $true
}
```

**Um die IMDSv2 Durchsetzungseinstellungen für das Konto in einer bestimmten Region anzuzeigen**  
Verwenden Sie den Get-EC2InstanceMetadataDefault Befehl und geben Sie die Region an.

```
Get-EC2InstanceMetadataDefault -Region us-east-1
```

Es folgt eine Beispielausgabe.

```
@{
    AccountLevel = @{
        HttpTokens = "required"
        HttpTokensEnforced = "enabled"
    }
    ManagedBy = "account"
}
```

Das `ManagedBy`-Feld gibt die Entität an, die die Einstellung konfiguriert hat. `account` zeigt in diesem Beispiel an, dass die Einstellung direkt im Konto konfiguriert wurde. Ein Wert von `declarative-policy` würde bedeuten, dass die Einstellung durch eine deklarative Richtlinie konfiguriert wurde. Weitere Informationen finden Sie unter [Declarative Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im *AWS Organizations User Guide*.

**Um das Konto IMDSv2 für alle Regionen durchzusetzen**  
Verwenden Sie den [modify-instance-metadata-defaults](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-defaults.html)Befehl, um die Durchsetzung IMDSv2 in allen Regionen durchzusetzen.

```
echo -e "Region          \t Modified" ; \
echo -e "--------------  \t ---------" ; \
for region in $(
    aws ec2 describe-regions \
        --region us-east-1 \
        --query "Regions[*].[RegionName]" \
        --output text
    ); 
    do (output=$(
        aws ec2 modify-instance-metadata-defaults \
            --region $region \
            --http-tokens-enforced enabled \
            --output text)
        echo -e "$region        \t $output"
    );
done
```

Es folgt eine Beispielausgabe.

```
Region                   Modified
--------------           ---------
ap-south-1               True
eu-north-1               True
eu-west-3                True
...
```

**Um es IMDSv2 als Standard für das Konto für alle Regionen festzulegen**  
Verwenden Sie das [Edit-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataDefault.html)Cmdlet, um die Einstellungen auf IMDS-Kontoebene für alle Regionen zu ändern. Schließen Sie die Einstellung `-HttpToken` auf `required` ein und legen Sie `-HttpPutResponseHopLimit` auf `2` fest, wenn Ihre Instances Container hosten werden. Geben Sie andernfalls `-1` an, dass keine Präferenz angegeben werden soll. Wenn `-1` (keine Präferenz) angegeben wird, ist der Wert beim Start standardmäßig `2`, wenn das AMI die Einstellung `ImdsSupport: v2.0` hat; andernfalls ist er standardmäßig `1`.

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region   = $_
        Modified = (Edit-EC2InstanceMetadataDefault `
                -Region $_ `
                -HttpToken required `
                -HttpPutResponseHopLimit 2)
    } 
} | `
Format-Table Region, Modified -AutoSize
```

Erwartete Ausgabe

```
Region         Modified
------         --------
ap-south-1         True
eu-north-1         True
eu-west-3          True
...
```

**So zeigen Sie die Standard-Kontoeinstellungen für die Instance-Metadatenoptionen für alle Regionen an**  
Verwenden Sie das cmdlet [Get-EC2InstanceMetadataDefault](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceMetadataDefault.html).

```
(Get-EC2Region).RegionName | `
    ForEach-Object {
    [PSCustomObject]@{
        Region = $_
        HttpPutResponseHopLimit = (Get-EC2InstanceMetadataDefault -Region $_).HttpPutResponseHopLimit
        HttpTokens              = (Get-EC2InstanceMetadataDefault -Region $_).HttpTokens
    }
} | `
Format-Table -AutoSize
```

Beispielausgabe

```
Region         HttpPutResponseHopLimit HttpTokens
------         ----------------------- ----------
ap-south-1                           2 required
eu-north-1                           2 required
eu-west-3                            2 required                    
...
```

------

### Konfigurieren der Instance beim Start
<a name="configure-IMDS-new-instances-instance-settings"></a>

Wenn Sie [eine Instance starten](ec2-launch-instance-wizard.md), können Sie die Instance so konfigurieren, dass die Verwendung von erforderlich ist, IMDSv2 indem Sie die folgenden Felder konfigurieren:
+ Amazon-EC2-Konsole: Stellen Sie **Metadata version** (Metadatenversion) auf **V2 only (token required)** (Nur V2 (Token erforderlich)) ein.
+ AWS CLI: Stellen Sie `HttpTokens` auf `required` ein.

Wenn Sie angeben, dass dies erforderlich IMDSv2 ist, müssen Sie auch den IMDS-Endpunkt (Instance Metadata Service) aktivieren, indem Sie **Metadaten zugänglich** auf **Aktiviert** (Konsole) oder `HttpEndpoint` auf `enabled` (AWS CLI) setzen.

In einer Container-Umgebung empfehlen wir, IMDSv2 das Hop-Limit auf zu `2` setzen, sofern dies erforderlich ist. Weitere Informationen finden Sie unter [Überlegungen zum Instance-Zugriff auf Instance-Metadaten](instancedata-data-retrieval.md#imds-considerations).

------
#### [ Console ]

**Um die Verwendung von IMDSv2 auf einer neuen Instance zu verlangen**
+ Wenn Sie eine neue Instance in der Amazon-EC2-Konsole starten, erweitern Sie **Erweiterte Details** wie folgt:
  + Für **Metadaten zugänglich** wählen Sie **Aktiviert**.
  + Wählen Sie für **Metadatenversion** die Option **Nur V2 (Token erforderlich)** aus.
  + (Container-Umgebung) Wählen Sie für **Metadata-Antwort-Hop-Limit** den Wert **2** aus.

  Weitere Informationen finden Sie unter [Erweiterte Details](ec2-instance-launch-parameters.md#liw-advanced-details).

------
#### [ AWS CLI ]

**Um die Verwendung von IMDSv2 auf einer neuen Instanz zu verlangen**  
Im folgenden Beispiel für [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) wird eine `c6i.large`-Instance gestartet, bei der `--metadata-options` auf `HttpTokens=required` gesetzt ist. Wenn Sie einen Wert für `HttpTokens` angeben, müssen Sie auch `HttpEndpoint` auf `enabled` einstellen. Da der Secure-Token-Header auf `required` für Anfragen zum Abrufen von Metadaten eingestellt ist, muss die Instanz IMDSv2 bei der Anforderung von Instanz-Metadaten verwendet werden.

In einer Containerumgebung empfehlen wir, IMDSv2 das Hop-Limit auf `2` with `HttpPutResponseHopLimit=2` zu setzen, sofern dies erforderlich ist.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
	...
    --metadata-options "HttpEndpoint=enabled,HttpTokens=required,HttpPutResponseHopLimit=2"
```

------
#### [ PowerShell ]

**Um die Verwendung von IMDSv2 auf einer neuen Instance zu verlangen**  
Das folgende [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)Cmdlet-Beispiel startet eine `c6i.large` Instanz mit `MetadataOptions_HttpEndpoint` set to `enabled` und dem `MetadataOptions_HttpTokens` Parameter to. `required` Wenn Sie einen Wert für `HttpTokens` angeben, müssen Sie auch `HttpEndpoint` auf `enabled` einstellen. Da der Secure-Token-Header auf `required` für Anfragen zum Abrufen von Metadaten festgelegt ist, muss die Instanz ihn IMDSv2 bei der Anforderung von Instanzmetadaten verwenden.

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint enabled `
    -MetadataOptions_HttpTokens required
```

------
#### [ CloudFormation ]

Informationen zur Angabe der Metadatenoptionen für eine Instanz, die verwendet CloudFormation wird, finden Sie in der entsprechenden [AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)Eigenschaft im *AWS CloudFormation Benutzerhandbuch*.

------

### Konfigurieren des AMI
<a name="configure-IMDS-new-instances-ami-configuration"></a>

Wenn Sie ein neues AMI registrieren oder ein vorhandenes AMI ändern, können Sie den Parameter `imds-support` auf `v2.0` setzen. Bei Instances, die über dieses AMI gestartet werden, ist **Metadatenversion** auf **Nur V2 (Token erforderlich)** (Konsole) eingestellt, oder `HttpTokens` ist auf `required` eingestellt (AWS CLI). Bei diesen Einstellungen setzt die Instanz voraus, dass diese bei der Anforderung von Instanz-Metadaten verwendet IMDSv2 wird.

Hinweis: Wenn Sie `imds-support` auf `v2.0` einstellen, wird bei Instances, die über dieses AMI gestartet werden, auch **Metadata response hop limit** (Limit für Metadaten-Antwort-Hop) (Konsole) oder `http-put-response-hop-limit` (AWS CLI) auf **2** eingestellt.

**Wichtig**  
Verwenden Sie diesen Parameter nur, wenn Ihre AMI-Software ihn unterstütztIMDSv2. Nachdem Sie den Wert auf `v2.0` gesetzt haben, können Sie das nicht mehr rückgängig machen. Die einzige Möglichkeit, Ihr AMI „zurückzusetzen“, besteht darin, ein neues AMI aus dem zugrunde liegenden Snapshot zu erstellen.

**Um ein neues AMI zu konfigurieren für IMDSv2**  
Verwenden Sie eine der folgenden Methoden, um ein neues AMI für zu konfigurierenIMDSv2.

------
#### [ AWS CLI ]

Das folgende [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html)-Beispiel registriert ein AMI mit dem angegebenen Snapshot eines EBS-Stamm-Volumes als `/dev/xvda` des Geräts. Geben Sie `v2.0` den `imds-support` Parameter so an, dass Instances, die über dieses AMI gestartet werden, diesen benötigen, IMDSv2 wenn Instance-Metadaten angefordert werden.

```
aws ec2 register-image \
    --name my-image \
    --root-device-name /dev/xvda \
    --block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0123456789example} \
    --architecture x86_64 \
    --imds-support v2.0
```

------
#### [ PowerShell ]

Das folgende [Register-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2Image.html)Cmdlet-Beispiel registriert ein AMI, das den angegebenen Snapshot eines EBS-Root-Volumes als Gerät verwendet. `/dev/xvda` Geben Sie `v2.0` den `ImdsSupport` Parameter so an, dass Instances, die über dieses AMI gestartet werden, diesen benötigen, IMDSv2 wenn Instance-Metadaten angefordert werden.

```
Register-EC2Image `
    -Name 'my-image' `
    -RootDeviceName /dev/xvda `
    -BlockDeviceMapping  ( 
    New-Object `
        -TypeName Amazon.EC2.Model.BlockDeviceMapping `
        -Property @{ 
        DeviceName = '/dev/xvda'; 
        EBS        = (New-Object -TypeName Amazon.EC2.Model.EbsBlockDevice -Property @{ 
                SnapshotId = 'snap-0123456789example'
                VolumeType = 'gp3' 
                } )      
        }  ) `
    -Architecture X86_64 `
    -ImdsSupport v2.0
```

------

**So konfigurieren Sie ein vorhandenes AMI für IMDSv2**  
Verwenden Sie eine der folgenden Methoden, um ein vorhandenes AMI für zu konfigurierenIMDSv2.

------
#### [ AWS CLI ]

Im folgenden [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html)Beispiel wird ein vorhandenes AMI IMDSv2 nur für geändert. Geben Sie `v2.0` den `imds-support` Parameter so an, dass Instances, die über dieses AMI gestartet werden, diesen benötigen, IMDSv2 wenn Instance-Metadaten angefordert werden.

```
aws ec2 modify-image-attribute \
    --image-id ami-0abcdef1234567890 \
    --imds-support v2.0
```

------
#### [ PowerShell ]

Das folgende [Edit-EC2ImageAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2ImageAttribute.html)Cmdlet-Beispiel ändert ein vorhandenes AMI nur für. IMDSv2 Geben Sie `v2.0` den `imds-support` Parameter so an, dass Instances, die über dieses AMI gestartet werden, diesen benötigen, IMDSv2 wenn Instance-Metadaten angefordert werden.

```
Edit-EC2ImageAttribute `
    -ImageId ami-0abcdef1234567890 `
    -ImdsSupport 'v2.0'
```

------

### Verwenden einer IAM-Richtlinie
<a name="configure-IMDS-new-instances-iam-policy"></a>

Sie können eine IAM-Richtlinie erstellen, die eine der folgenden Aktionen ausführt:
+ Hindert Benutzer daran, neue Instances zu starten, es sei denn, sie benötigen IMDSv2 die neue Instance.
+ Hindert Benutzer daran, die ModifyInstanceMetadataOptions API aufzurufen, um die Metadatenoptionen einer laufenden Instanz zu ändern. Beschränken Sie den Zugriff auf die Eigenschaft ModifyInstanceMetadataOptions HttpTokens, um unbeabsichtigte Aktualisierungen laufender Instanzen zu verhindern.
+ Verhindern Sie, dass Benutzer die ModifyInstanceMetadataDefaults API aufrufen, um die Kontostandardeinstellungen von HttpTokens und zu ändern. httpTokensEnforced Durch die Beschränkung des Zugriffs auf diese beiden Eigenschaften wird sichergestellt, dass nur autorisierte Rollen die Kontostandardwerte ändern können.

**Um die Verwendung von IMDSv2 auf allen neuen Instances mithilfe einer IAM-Richtlinie zu erzwingen**  
Gehen Sie wie folgt vor, um sicherzustellen, dass Benutzer nur Instances starten können, für die IMDSv2 bei der Anforderung von Instance-Metadaten die Verwendung von erforderlich ist:
+ Beschränken Sie den Zugriff `ModifyInstanceMetadataOptions` sowohl auf die `ModifyInstanceMetadataDefaults` API als auch auf die `httpTokensEnforced` Eigenschaften `httpTokens` und.
+ Stellen Sie dann den Kontostandard auf `httpTokens = required` und ein`httpTokensEnforced = enabled`.

  Die IAM-Beispielrichtlinie finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata).

## Aktivieren Sie das IMDS IPv4 und die Endpoints IPv6
<a name="configure-IMDS-new-instances-ipv4-ipv6-endpoints"></a>

Das IMDS hat zwei Endpunkte auf einer Instanz: IPv4 (`169.254.169.254`) und (). IPv6 `[fd00:ec2::254]` Wenn Sie das IMDS aktivieren, wird der IPv4 Endpunkt automatisch aktiviert. Der IPv6 Endpunkt bleibt auch dann deaktiviert, wenn Sie eine Instance in einem Subnetz starten, das IPv6 nur für das Subnetz zuständig ist. Um den IPv6 Endpunkt zu aktivieren, müssen Sie dies explizit tun. Wenn Sie den IPv6 Endpunkt aktivieren, bleibt der IPv4 Endpunkt aktiviert.

Sie können den IPv6 Endpunkt beim Start der Instance oder danach aktivieren.

**Anforderungen für die Aktivierung des IPv6 Endpunkts**
+ Der ausgewählte Instance-Typ ist eine [Nitro-basierte Instance](instance-types.md#instance-hypervisor-type).
+ Das ausgewählte Subnetz unterstützt IPv6, wobei es sich bei dem Subnetz entweder um ein [Dual-Stack-Netzwerk oder IPv6 ](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) um ein reines Subnetz handelt.

Verwenden Sie eine der folgenden Methoden, um eine Instance mit aktiviertem IPv6 IMDS-Endpunkt zu starten.

------
#### [ Console ]

**Um den IPv6 IMDS-Endpunkt beim Start der Instanz zu aktivieren**
+ [Starten Sie die Instance](ec2-launch-instance-wizard.md) in der Amazon-EC2-Konsole mit den folgenden Angaben unter **Advanced details** (Erweiterte Details):
  + Wählen Sie für den ** IPv6 Metadaten-Endpunkt** die Option **Aktiviert** aus.

Weitere Informationen finden Sie unter [Erweiterte Details](ec2-instance-launch-parameters.md#liw-advanced-details).

------
#### [ AWS CLI ]

**Um den IPv6 IMDS-Endpunkt beim Start der Instanz zu aktivieren**  
Im folgenden [Run-Instance-Beispiel wird eine `c6i.large` Instance](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) gestartet, bei der der IPv6 Endpunkt für das IMDS aktiviert ist. Um den IPv6 Endpunkt zu aktivieren, geben Sie für den `--metadata-options` Parameter Folgendes an. `HttpProtocolIpv6=enabled` Wenn Sie einen Wert für `HttpProtocolIpv6` angeben, müssen Sie auch `HttpEndpoint` auf `enabled` einstellen.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
    ...
    --metadata-options "HttpEndpoint=enabled,HttpProtocolIpv6=enabled"
```

------
#### [ PowerShell ]

**Um den IPv6 IMDS-Endpunkt beim Start der Instanz zu aktivieren**  
Das folgende [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)Cmdlet-Beispiel startet eine `c6i.large` Instanz, bei der der IPv6 Endpunkt für das IMDS aktiviert ist. Um den IPv6 Endpunkt zu aktivieren, geben Sie as an. `MetadataOptions_HttpProtocolIpv6` `enabled` Wenn Sie einen Wert für `MetadataOptions_HttpProtocolIpv6` angeben, müssen Sie auch `MetadataOptions_HttpEndpoint` auf `enabled` einstellen.

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint enabled `
    -MetadataOptions_HttpProtocolIpv6 enabled
```

------

## Deaktivieren des Zugriffs auf Instance-Metadaten
<a name="configure-IMDS-new-instances--turn-off-instance-metadata"></a>

Sie können den Zugriff auf die Instance-Metadaten deaktivieren, indem Sie den IMDS deaktivieren, wenn Sie eine Instance starten. Sie können den Zugriff später wieder aktivieren, indem Sie den IMDS erneut aktivieren. Weitere Informationen finden Sie unter [Aktivieren des Zugriffs auf Instance-Metadaten](configuring-IMDS-existing-instances.md#enable-instance-metadata-on-existing-instances).

**Wichtig**  
Sie können wählen, ob Sie den IMDS beim Start oder nach dem Start deaktivieren möchten. Wenn Sie den IMDS *beim Start* deaktivieren, funktioniert Folgendes möglicherweise nicht:  
Möglicherweise haben Sie keinen SSH-Zugriff auf Ihre Instance. Auf den `public-keys/0/openssh-key`, den öffentlichen SSH-Schlüssel Ihrer Instance, kann nicht zugegriffen werden, da der Schlüssel normalerweise über die EC2-Instance-Metadaten bereitgestellt und abgerufen wird.
EC2-Benutzerdaten sind nicht verfügbar und werden beim Start der Instance nicht ausgeführt. EC2-Benutzerdaten werden auf dem IMDS gehostet. Wenn Sie den IMDS deaktivieren, deaktivieren Sie effektiv den Zugriff auf Benutzerdaten.
Sie können den IMDS nach dem Start wieder aktivieren, um auf diese Funktion zuzugreifen.

------
#### [ Console ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten beim Start**
+ [Starten Sie die Instance](ec2-launch-instance-wizard.md) in der Amazon-EC2-Konsole mit den folgenden Angaben unter **Advanced details** (Erweiterte Details):
  + Für **Metadaten zugänglich** wählen Sie **Deaktiviert**.

Weitere Informationen finden Sie unter [Erweiterte Details](ec2-instance-launch-parameters.md#liw-advanced-details).

------
#### [ AWS CLI ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten beim Start**  
Starten Sie die Instance, wobei `--metadata-options` auf `HttpEndpoint=disabled` eingestellt ist.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type c6i.large \
    ... 
    --metadata-options "HttpEndpoint=disabled"
```

------
#### [ PowerShell ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten beim Start**  
Das folgende [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)Cmdlet-Beispiel startet eine Instanz mit der `MetadataOptions_HttpEndpoint` Einstellung auf. `disabled`

```
New-EC2Instance `
    -ImageId ami-0abcdef1234567890 `
    -InstanceType c6i.large `
    -MetadataOptions_HttpEndpoint disabled
```

------
#### [ CloudFormation ]

Informationen zum Angeben der Metadatenoptionen für eine Instanz, die Sie verwenden CloudFormation, finden Sie in der [AWS::EC2::LaunchTemplate MetadataOptions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)entsprechenden Eigenschaft im *CloudFormation Benutzerhandbuch*. 

------

## Zulassen des Zugriffs auf Tags in Instance-Metadaten
<a name="configure-IMDS-new-instances-tags-in-instance-metadata"></a>

Standardmäßig gibt es keinen Zugriff auf Instance-Tags in den Instance-Metadaten. Sie müssen den Zugriff für jede Instance explizit zulassen. Wenn der Zugriff erlaubt ist, müssen die Instance-Tag-*Schlüssel* bestimmten Zeichenbeschränkungen entsprechen, andernfalls schlägt der Instance-Start fehl. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

# Modifizieren von Instance-Metadatenoptionen für vorhandene Instances
<a name="configuring-IMDS-existing-instances"></a>

Sie können die Instance-Metadatenoptionen für vorhandene Instances ändern.

Sie können auch eine IAM-Richtlinie erstellen, die verhindert, dass Benutzer die Instance-Metadatenoptionen für vorhandene Instances ändern. Um zu kontrollieren, welche Benutzer die Optionen für Instanz-Metadaten ändern können, geben Sie eine Richtlinie an, die verhindert, dass alle Benutzer außer Benutzern mit einer bestimmten Rolle die [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API verwenden. Die IAM-Beispielrichtlinie finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata).

**Anmerkung**  
Wenn zur Konfiguration der Instance-Metadatenoptionen eine deklarative Richtlinie verwendet wurde, können Sie diese nicht direkt im Konto ändern. Weitere Informationen finden Sie unter [Deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im *AWS Organizations -Benutzerhandbuch*.

## Erfordern die Verwendung von IMDSv2
<a name="modify-require-IMDSv2"></a>

Verwenden Sie eine der folgenden Methoden, um die Optionen für Instanzmetadaten auf einer vorhandenen Instanz so zu ändern, dass diese Option bei der Anforderung von Instanz-Metadaten erforderlich IMDSv2 ist. Wann IMDSv2 ist erforderlich, IMDSv1 kann nicht verwendet werden.

**Anmerkung**  
Bevor Sie verlangen, dass dies verwendet IMDSv2 wird, stellen Sie sicher, dass die Instanz keine IMDSv1 Aufrufe tätigt. Die `MetadataNoToken` CloudWatch Metrik verfolgt IMDSv1 Anrufe. Wenn für eine Instance keine IMDSv1 Nutzung `MetadataNoToken` aufgezeichnet wird, ist die Instance bereit, sie zu nutzen IMDSv2.

------
#### [ Console ]

**Um die Verwendung von IMDSv2 auf einer vorhandenen Instanz vorzuschreiben**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie Ihre Instance aus.

1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.

1. Führen Sie im Dialogfeld **Instance-Metadatenoptionen ändern** Folgendes aus:

   1. Für den **Instance-Metadatenservice** wählen Sie die Option **Aktivieren**.

   1. Wählen Sie für **IMDSv2**die Option **Erforderlich** aus.

   1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

**Um die Verwendung von IMDSv2 auf einer vorhandenen Instanz zu verlangen**  
Verwenden Sie den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl und setzen Sie den `http-tokens` Parameter auf`required`. Wenn Sie einen Wert für `http-tokens` angeben, müssen Sie auch `http-endpoint` auf `enabled` einstellen.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Um die Verwendung von IMDSv2 auf einer vorhandenen Instanz zu verlangen**  
Verwenden Sie das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet und setzen Sie den `HttpTokens` Parameter auf. `required` Wenn Sie einen Wert für `HttpTokens` angeben, müssen Sie auch `HttpEndpoint` auf `enabled` einstellen.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpTokens required `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Stellen Sie die Verwendung von wieder her IMDSv1
<a name="modify-restore-IMDSv1"></a>

Wenn dies für eine Instanz erforderlich IMDSv2 ist, schlägt die Verwendung einer IMDSv1 Anfrage fehl. Wann IMDSv2 ist optional, dann IMDSv1 funktionieren IMDSv2 sowohl als auch. Setzen Sie daher zum Wiederherstellen IMDSv1 IMDSv2 den Wert auf optional (`httpTokens = optional`). Verwenden Sie dazu eine der folgenden Methoden.

Die `httpTokensEnforced` IMDS-Eigenschaft verhindert auch Versuche, die Aktivierung IMDSv1 auf einer vorhandenen Instanz durchzuführen. Wenn die Option für ein Konto in einer Region aktiviert ist, führt der Versuch, den Wert `httpTokens` auf zu `optional` setzen, zu einer `UnsupportedOperation` Ausnahme. Weitere Informationen finden Sie unter[Fehlerbehebung](#troubleshoot-modifying-an-imdsv1-enabled-instance-fails).

**Wichtig**  
Wenn Ihre Instance-Starts aufgrund von IMDSv2 Zwangsmaßnahmen fehlschlagen, haben Sie zwei Möglichkeiten, um sicherzustellen, dass Starts erfolgreich sind:  
**Instances nur als IMDSv2 -only starten** — Wenn die Software, die auf den Instances ausgeführt wird, IMDSv2 Only verwendet (keine Abhängigkeit von IMDSv1), können Sie die Instances als IMDSv2 Only starten. Konfigurieren Sie dies IMDSv2 nur, indem Sie `httpTokens = required` entweder in den Startparametern oder in den Metadaten die Standardeinstellungen für das Konto in der Region festlegen. 
**Erzwingung deaktivieren** — Wenn Ihre Software weiterhin davon abhängt IMDSv1, legen Sie `disabled` für `httpTokensEnforced` das Konto in der Region die Einstellung auf fest. Weitere Informationen finden Sie unter [IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

------
#### [ Console ]

**Um die Nutzung von IMDSv1 auf einer Instanz wiederherzustellen**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie Ihre Instance aus.

1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.

1. Führen Sie im Dialogfeld **Instance-Metadatenoptionen ändern** Folgendes aus:

   1. Vergewissern Sie sich, dass für den **Instance-Metadatenservice** die Option **Aktivieren** ausgewählt ist.

   1. Wählen **IMDSv2**Sie für **Optional**.

   1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

**Um die Verwendung von IMDSv1 auf einer Instanz wiederherzustellen**  
Sie können den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl mit `http-tokens` set to verwenden, `optional` um die Verwendung von IMDSv1 bei der Anforderung von Instance-Metadaten wiederherzustellen.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens optional \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**Um die Verwendung von IMDSv1 auf einer Instanz wiederherzustellen**  
Sie können das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet mit der `HttpTokens` Einstellung auf verwenden, `optional` um die Verwendung von IMDSv1 bei der Anforderung von Instanzmetadaten wiederherzustellen.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpTokens optional `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Ändern des PUT-Antwort-Hop-Limits
<a name="modify-PUT-response-hop-limit"></a>

Für bestehende Instances können Sie die Einstellungen für das `PUT`-Antwort-Hop-Limit ändern.

Derzeit AWS SDKs unterstützen nur die AWS CLI und die Änderung des PUT-Antwort-Hop-Limits.

------
#### [ AWS CLI ]

**So ändern Sie das PUT-Antwort-Hop-Limit**  
Verwenden Sie den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl und setzen Sie den `http-put-response-hop-limit` Parameter auf die erforderliche Anzahl von Hops. Im folgenden Beispiel wird das Hop-Limit auf `3` gesetzt. Beachten Sie, dass Sie beim Angeben eines Werts für `http-put-response-hop-limit` auch `http-endpoint` auf `enabled` setzen müssen.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-put-response-hop-limit 3 \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**So ändern Sie das PUT-Antwort-Hop-Limit**  
Verwenden Sie das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet und setzen Sie den `HttpPutResponseHopLimit` Parameter auf die erforderliche Anzahl von Hops. Im folgenden Beispiel wird das Hop-Limit auf `3` gesetzt. Beachten Sie, dass Sie beim Angeben eines Werts für `HttpPutResponseHopLimit` auch `HttpEndpoint` auf `enabled` setzen müssen.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpPutResponseHopLimit 3 `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Aktivieren Sie das IMDS und die Endpoints IPv4 IPv6
<a name="enable-ipv6-endpoint-for-existing-instances"></a>

Das IMDS hat zwei Endpunkte auf einer Instanz: IPv4 (`169.254.169.254`) und (). IPv6 `[fd00:ec2::254]` Wenn Sie das IMDS aktivieren, wird der IPv4 Endpunkt automatisch aktiviert. Der IPv6 Endpunkt bleibt auch dann deaktiviert, wenn Sie eine Instance in einem Subnetz starten, das IPv6 nur für das Subnetz zuständig ist. Um den IPv6 Endpunkt zu aktivieren, müssen Sie dies explizit tun. Wenn Sie den IPv6 Endpunkt aktivieren, bleibt der IPv4 Endpunkt aktiviert.

Sie können den IPv6 Endpunkt beim Start der Instance oder danach aktivieren.

**Anforderungen für die Aktivierung des IPv6 Endpunkts**
+ Der ausgewählte Instance-Typ ist eine [Nitro-basierte Instance](instance-types.md#instance-hypervisor-type).
+ Das ausgewählte Subnetz unterstützt IPv6, wobei es sich bei dem Subnetz entweder um ein [Dual-Stack-Netzwerk oder IPv6 ](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) um ein reines Subnetz handelt.

Derzeit AWS SDKs unterstützen nur die AWS CLI und die Aktivierung des IPv6 IMDS-Endpunkts nach dem Start der Instance.

------
#### [ AWS CLI ]

**Um den IPv6 IMDS-Endpunkt für Ihre Instance zu aktivieren**  
Verwenden Sie den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl und setzen Sie den `http-protocol-ipv6` Parameter auf`enabled`. Beachten Sie, dass Sie beim Angeben eines Werts für `http-protocol-ipv6` auch `http-endpoint` auf `enabled` setzen müssen.

```
aws ec2 modify-instance-metadata-options \
	--instance-id i-1234567890abcdef0 \
	--http-protocol-ipv6 enabled \
	--http-endpoint enabled
```

------
#### [ PowerShell ]

**Um den IPv6 IMDS-Endpunkt für Ihre Instance zu aktivieren**  
Verwenden Sie das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet und setzen Sie den `HttpProtocolIpv6` Parameter auf. `enabled` Beachten Sie, dass Sie beim Angeben eines Werts für `HttpProtocolIpv6` auch `HttpEndpoint` auf `enabled` setzen müssen.

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpProtocolIpv6 enabled `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Aktivieren des Zugriffs auf Instance-Metadaten
<a name="enable-instance-metadata-on-existing-instances"></a>

Sie können den Zugriff auf Instance-Metadaten aktivieren, indem Sie den HTTP-Endpunkt des IMDS auf Ihrer Instance aktivieren, unabhängig davon, welche Version des IMDS Sie verwenden. Sie können diese Änderung jederzeit rückgängig machen, indem Sie den HTTP-Endpunkt deaktivieren.

Verwenden Sie eine der folgenden Methoden, um den Zugriff auf Instance-Metadaten für eine Instance zu aktivieren.

------
#### [ Console ]

**So aktivieren Sie den Zugriff auf Instance-Metadaten**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie Ihre Instance aus.

1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.

1. Führen Sie im Dialogfeld **Instance-Metadatenoptionen ändern** Folgendes aus:

   1. Für den **Instance-Metadatenservice** wählen Sie die Option **Aktivieren**.

   1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

**So aktivieren Sie den Zugriff auf Instance-Metadaten**  
Verwenden Sie den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl und setzen Sie den `http-endpoint` Parameter auf`enabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint enabled
```

------
#### [ PowerShell ]

**So aktivieren Sie den Zugriff auf Instance-Metadaten**  
Verwenden Sie das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet und setzen Sie den `HttpEndpoint` Parameter auf. `enabled`

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpEndpoint enabled).InstanceMetadataOptions
```

------

## Deaktivieren des Zugriffs auf Instance-Metadaten
<a name="disable-instance-metadata-on-existing-instances"></a>

Sie können den Zugriff auf Instance-Metadaten deaktivieren, indem Sie den HTTP-Endpunkt des IMDS auf Ihrer Instance deaktivieren, unabhängig davon, welche Version des IMDS Sie verwenden. Sie können diese Änderung jederzeit rückgängig machen, indem Sie den HTTP-Endpunkt aktivieren.

Verwenden Sie eine der folgenden Methoden, um den Zugriff auf Instance-Metadaten für eine Instance zu deaktivieren.

------
#### [ Console ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie Ihre Instance aus.

1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.

1. Führen Sie im Dialogfeld **Instance-Metadatenoptionen ändern** Folgendes aus:

   1. Für den **Instance-Metadatenservice** entfernen Sie die Option **Aktivieren**.

   1. Wählen Sie **Speichern**.

------
#### [ AWS CLI ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten**  
Verwenden Sie den [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl und setzen Sie den `http-endpoint` Parameter auf`disabled`.

```
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint disabled
```

------
#### [ PowerShell ]

**So deaktivieren Sie den Zugriff auf Instance-Metadaten**  
Verwenden Sie das [Edit-EC2InstanceMetadataOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMetadataOption.html)Cmdlet und setzen Sie den `HttpEndpoint` Parameter auf. `disabled`

```
(Edit-EC2InstanceMetadataOption `
    -InstanceId i-1234567890abcdef0 `
    -HttpEndpoint disabled).InstanceMetadataOptions
```

------

## Zulassen des Zugriffs auf Tags in Instance-Metadaten
<a name="modify-access-to-tags-in-instance-metadata-on-existing-instances"></a>

Sie können den Zugriff auf Tags in den Instance-Metadaten einer laufenden oder angehaltenen Instance erlauben. Sie müssen den Zugriff für jede Instance explizit zulassen. Wenn der Zugriff erlaubt ist, müssen die Instance-Tag-*Schlüssel* bestimmten Zeichenbeschränkungen entsprechen, andernfalls schlägt der Instance-Start fehl. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).

## Fehlerbehebung
<a name="troubleshoot-modifying-an-imdsv1-enabled-instance-fails"></a>

### Das Ändern einer Instanz mit IMDSv1 -enabled schlägt fehl
<a name="modifying-an-imdsv1-enabled-instance-fails"></a>

#### Description
<a name="modifying-an-imdsv1-enabled-instance-fails-description"></a>

Sie erhalten die folgende Fehlermeldung:

`You can't launch instances with IMDSv1 because httpTokensEnforced is enabled for this account. Either launch the instance with httpTokens=required or contact your account owner to disable httpTokensEnforced using the ModifyInstanceMetadataDefaults API or the account settings in the EC2 console.`

#### Ursache
<a name="modifying-an-imdsv1-enabled-instance-fails-cause"></a>

Dieser Fehler wird ausgelöst, wenn Sie versuchen, eine bestehende Instance so zu ändern, dass sie IMDSv1 aktiviert wird (`httpTokens = optional`) in einem Konto, für das die EC2-Kontoeinstellungen oder eine deklarative AWS Organisationsrichtlinie die Verwendung von IMDSv2 () erzwingen. `httpTokensEnforced = enabled` 

#### Lösung
<a name="modifying-an-imdsv1-enabled-instance-fails-solution"></a>

Wenn Sie IMDSv1 Unterstützung für bestehende Instances benötigen, müssen Sie die IMDSv2 Durchsetzung für das Konto in der Region deaktivieren. Um die IMDSv2 Durchsetzung zu deaktivieren, stellen Sie `HttpTokensEnforced` auf ein`disabled`. Weitere Informationen finden Sie [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html)in der Amazon EC2 API-Referenz. Wenn Sie diese Einstellung lieber über die Konsole konfigurieren möchten, finden Sie weitere Informationen unter[IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).

Wir empfehlen, IMDSv2 nur (`httpTokens=required`) zu verwenden. Weitere Informationen finden Sie unter [Übergang zur Verwendung von Instance-Metadatenservice Version 2](instance-metadata-transition-to-version-2.md).

 

# Befehle beim Starten einer EC2-Instance mit Eingabe von Benutzerdaten ausführen
<a name="user-data"></a>

Wenn Sie eine Amazon-EC2-Instance starten, können Sie Benutzerdaten an die Instance weitergeben, die zur Durchführung automatischer Konfigurationsaufgaben oder zur Ausführung von Skripten nach dem Start der Instance verwendet werden.

Wenn Sie an komplexeren Automatisierungsszenarien interessiert sind, sollten Sie dies in Betracht ziehen CloudFormation. Weitere Informationen finden Sie unter [Bereitstellen von Anwendungen in Amazon EC2 mit CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/deploying.applications.html) im *AWS CloudFormation -Benutzerhandbuch*.

Auf Linux-Instances können Sie zwei Arten von Benutzerdaten an Amazon EC2 übergeben: Shell-Skripte und Cloud-Init-Direktiven. Sie können diese Daten auch als Klartext an den Launch Instance Wizard weiterleiten, entweder als Datei (dies ist hilfreich für den Start von Instances mithilfe der Befehlszeilen-Tools) oder als base64-kodierten Text (für API-Aufrufe).

Auf Windows-Instances verarbeiten die Start-Agenten Ihre Benutzerdaten-Skripts.

**Überlegungen**
+ Benutzerdaten werden als Opaque-Daten behandelt: Was Sie eingeben, wird auch ausgegeben. Die Interpretation der Daten ist Aufgabe der Instance.
+ Benutzerdaten müssen mit Base64 codiert werden. Die Amazon-EC2-Konsole kann die base64-Codierung für Sie durchführen oder base64-codierte Eingaben annehmen. Wenn Sie die Benutzerdaten über Instance-Metadaten oder die Konsole abrufen, werden sie automatisch für Sie base64-dekodiert.
+ Benutzerdaten sind auf 16 KB an Rohdaten, bevor diese base64-codiert werden, begrenzt. Die Länge einer Zeichenfolge *n* nach base64-Codierung ist ceil(*n*/3)\$14.
+ Benutzerdaten sind ein Instance-Attribut. Wenn Sie ein AMI auf der Grundlage einer Instance erstellen, sind die Instance-Benutzerdaten nicht im AMI enthalten.

## Benutzerdaten in der AWS-Managementkonsole
<a name="user-data-console"></a>

Sie können Instance-Benutzerdaten angeben, wenn Sie die Instance starten. Wenn das Root-Volume der Instance ein EBS-Volume ist, können Sie die Instance auch anhalten und ihre Benutzerdaten aktualisieren.

### Instance-Benutzerdaten beim Start mit dem Launch Wizard angeben
<a name="user-data-launch-instance-wizard"></a>

Sie können Benutzerdaten angeben, wenn Sie eine Instance mit dem Launch Wizard in der EC2-Konsole starten. Um Benutzerdaten beim Start anzugeben, folgen Sie dem Verfahren zum [Starten einer Instance](ec2-launch-instance-wizard.md). Das Feld **User data** (Benutzerdaten) befindet sich im Abschnitt [Erweiterte Details](ec2-instance-launch-parameters.md#liw-advanced-details) des Launch Instance Wizard. Geben Sie Ihr PowerShell Skript in das Feld **Benutzerdaten** ein und schließen Sie dann den Vorgang zum Starten der Instanz ab.

Im folgenden Screenshot des Feldes **Benutzerdaten** erstellt das Beispielskript eine Datei im temporären Windows-Ordner und verwendet das aktuelle Datum und die Uhrzeit im Dateinamen. Wenn Sie `<persist>true</persist>` einfügen, wird das Skript bei jedem Neustart oder Start der Instance ausgeführt. Wenn Sie das Kontrollkästchen **Benutzerdaten wurden bereits mit Base64 codiert** leer lassen, führt die Amazon-EC2-Konsole die Base64-Codierung für Sie durch.

![\[Textfeld für erweiterte Details für Benutzerdaten.\]](http://docs.aws.amazon.com/de_de/AWSEC2/latest/UserGuide/images/configure_ec2config_userdata.png)


Weitere Informationen finden Sie unter [Instance-Benutzerdaten beim Start mit dem Launch Wizard angeben](#user-data-launch-instance-wizard). Ein Linux-Beispiel, das den verwendet AWS CLI, finden Sie unter[Benutzerdaten und die AWS CLI](#user-data-api-cli). Ein Windows-Beispiel, das die Tools für Windows verwendet PowerShell, finden Sie unter[Benutzerdaten und die Tools für Windows PowerShell](#user-data-powershell).

### Anzeigen und Aktualisieren der Instance-Benutzerdaten
<a name="user-data-view-change"></a>

Sie können die Instance-Benutzerdaten für jede beliebige Instance anzeigen und die Instance-Benutzerdaten für eine angehaltene Instance aktualisieren.

**So aktualisieren Sie die Benutzerdaten für eine Instance mit der Konsole**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie die Instance und dann **Aktionen**, **Instance-Status**, **Instance anhalten** aus.
**Warnung**  
Wenn Sie eine Instance beenden, gehen die Daten auf den Instance-Speicher-Volumes verloren. Um diese Daten beizubehalten, sichern Sie sie auf einem persistenten Speicher.

1. Wenn Sie zur Bestätigung aufgefordert werden, wählen Sie **Stop** aus. Das Anhalten der Instance kann einige Minuten dauern.

1. Wählen Sie mit der ausgewählten Instance **Aktionen**, **Instance-Einstellungen**, **Benutzerdaten bearbeiten** aus. Die Benutzerdaten können nicht geändert werden, solange die Instance ausgeführt wird; Sie können die Benutzerdaten nur anzeigen.

1. Aktualisieren Sie die Benutzerdaten im Dialogfeld **View/Change User Data (Benutzerdaten anzeigen/ändern)** und wählen Sie dann die Option **Save (Speichern)**. Um die Benutzerdaten-Skripts bei jedem Neustart oder Starten der Instance auszuführen, fügen Sie `<persist>true</persist>` hinzu, wie im folgenden Beispiel gezeigt:  
![\[Dialogfeld für Benutzerdaten bearbeiten.\]](http://docs.aws.amazon.com/de_de/AWSEC2/latest/UserGuide/images/view-change-user-data.png)

1. Starten Sie die Instance. Wenn Sie die Ausführung von Benutzerdaten für nachfolgende Neustarts oder Starts aktiviert haben, werden die aktualisierten Benutzerdaten-Skripts als Teil des Instance-Startprozesses ausgeführt.

## So verarbeitet Amazon-EC2-Benutzerdaten für Linux-Instances
<a name="userdata-linux"></a>

In den folgenden Beispielen werden Benutzerdaten verwendet, um Befehle auszuführen, die beim Start der Instance einen LAMP-Server einrichten. In jedem Beispiel werden die folgenden Aufgaben ausgeführt:
+ Die Softwarepakete der Bereitstellung werden aktualisiert.
+ Der Webserver, `php` und `mariadb`-Pakete werden installiert.
+ Der `httpd`-Service wird gestartet und aktiviert.
+ Der Benutzer `ec2-user` wird der Apache-Gruppe hinzugefügt.
+ Eigentümer und Dateiberechtigungen für das Webverzeichnis und die darin enthaltenen Daten werden festgelegt.
+ Zum Testen des Webservers und der PHP-Engine wird eine einfache Webseite erstellt.

**Topics**
+ [

### Voraussetzungen
](#user-data-requirements)
+ [

### Benutzerdaten und Shell-Skripts
](#user-data-shell-scripts)
+ [

### Instance-Benutzerdaten aktualisieren
](#user-data-modify)
+ [

### Benutzerdaten und Cloud-Init-Anweisungen
](#user-data-cloud-init)
+ [

### Benutzerdaten und die AWS CLI
](#user-data-api-cli)
+ [

### Kombinieren von Shell-Skripts und cloud-init-Anweisungen
](#user-data-mime-multi)

### Voraussetzungen
<a name="user-data-requirements"></a>

Die Beispiele in diesem Thema setzen Folgendes voraus:
+ Ihre Instance verfügt bereits über einen öffentlichen DNS-Namen, der über das Internet erreichbar ist.
+ Die Ihrer Instance zugeordnete Sicherheitsgruppe ist so konfiguriert, dass sie SSH-Datenverkehr (Port 22) zulässt, sodass Sie eine Verbindung zur Instance herstellen können, um die Ausgabeprotokolldateien anzuzeigen.
+ Ihre Instance wird mit einem Amazon-Linux-AMI gestartet. Die Befehle und Direktiven funktionieren unter Umständen nicht für andere Linux-Distributionen. Weitere Informationen zu anderen Distributionen, z. B. zur Unterstützung für cloud-init, finden Sie in der jeweiligen Dokumentation.

### Benutzerdaten und Shell-Skripts
<a name="user-data-shell-scripts"></a>

Shell-Skripts sind, sofern Sie sich damit auskennen, die einfachste und vollständigste Methode, mit der Sie einer Instance beim Start Anweisungen übermitteln. Wenn diese Skripts beim Start ausgeführt werden, verlängert sich dadurch die Dauer des Instance-Starts. Erlauben Sie einige Minuten für die vollständige Ausführung der Aufgaben, bevor Sie überprüfen, ob die Benutzerskripte vollständig ausgeführt wurden.

**Wichtig**  
Standardmäßig werden Benutzerdatenskripte und Cloud-init-Direktiven nur während des Startzyklus ausgeführt, wenn Sie eine Instance zum ersten Mal starten. Sie können Ihre Konfiguration aktualisieren, um sicherzustellen, dass Ihre Benutzerdatenskripte und Cloud-Init-Direktiven bei jedem Neustart der Instance ausgeführt werden. Weitere Informationen finden Sie unter [Wie kann ich Benutzerdaten verwenden, um bei jedem Neustart meiner Amazon EC2 EC2-Linux-Instance automatisch ein Skript auszuführen](https://repost.aws/knowledge-center/execute-user-data-ec2)? im AWS Knowledge Center.

Benutzerdaten-Shell-Skripts müssen mit den Zeichen `#!` und dem Pfad zu dem Interpreter beginnen, der das Skript lesen soll (üblicherweise **/bin/bash)**). Eine Einführung in Shell-Scripting finden Sie im [Bash-Referenzhandbuch](https://www.gnu.org/software/bash/manual/bash.html) auf der Website des *GNU-Betriebssystems*.

Als Benutzerdaten eingegebene Skripte werden als Stammbenutzer ausgeführt. Verwenden Sie daher nicht den **sudo**-Befehl im Skript. Denken Sie daran, dass alle von Ihnen erstellten Dateien dem Stammbenutzer gehören. Wenn Sie Zugriff auf die Dateien durch einen anderen Benutzer als den Stammbenutzer benötigen, sollten Sie die Berechtigungen im Skript entsprechend ändern. Außerdem können Sie keine Befehle verwenden, die Benutzerfeedback erfordern (z. B. **yum update** ohne das `-y`-Flag ), da das Skript nicht interaktiv ausgeführt wird.

Wenn Sie eine AWS API, einschließlich der AWS CLI, in einem Benutzerdatenskript verwenden, müssen Sie beim Starten der Instance ein Instanzprofil verwenden. Ein Instanzprofil stellt die entsprechenden AWS Anmeldeinformationen bereit, die das Benutzerdatenskript benötigt, um den API-Aufruf auszuführen. Weitere Informationen finden Sie unter [Verwenden von Instance-Profilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) im IAM-Benutzerhandbuch. Die Berechtigungen, die Sie der IAM-Rolle zuweisen, hängen davon ab, welche Dienste Sie mit der API aufrufen. Weitere Informationen finden Sie unter [IAM-Rollen für Amazon EC2](iam-roles-for-amazon-ec2.md).

Die Ausgabeprotokolldatei von Cloud-Init zeichnet die Ausgabe der Konsole auf, was die Behebung von Fehlern an den Skripts vereinfacht, falls sich die Instance nach dem Start nicht verhält wie erwartet. Um die Protokolldatei anzuzeigen, [stellen Sie eine Verbindung mit der Instance her](connect-to-linux-instance.md) und öffnen Sie `/var/log/cloud-init-output.log`.

Wird ein Benutzerdatenskript verarbeitet, dann wird es nach kopiert und von dort aus ausgeführ `/var/lib/cloud/instances/instance-id/`. Das Skript wird nach der Ausführung nicht gelöscht. Stellen Sie sicher, dass Sie die Benutzerdatenskripts aus `/var/lib/cloud/instances/instance-id/` löschen, bevor Sie ein AMI aus der Instance erstellen. Andernfalls ist das Skript in diesem Verzeichnis auf jeder Instance vorhanden, die vom AMI gestartet wird.

### Instance-Benutzerdaten aktualisieren
<a name="user-data-modify"></a>

Um die Instance-Benutzerdaten aktualisieren zu können, müssen Sie zuerst die Instance anhalten. Wenn die Instance ausgeführt wird, können Sie die Benutzerdaten anzeigen, sie können jedoch nicht ändern.

**Warnung**  
Wenn Sie eine Instance beenden, gehen die Daten auf den Instance-Speicher-Volumes verloren. Um diese Daten beizubehalten, sichern Sie sie auf einem persistenten Speicher.

**Ändern von Instance-Benutzerdaten**

1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Wählen Sie im Navigationsbereich **Instances** aus.

1. Wählen Sie die Instance und dann **Instance-Status**, **Instance anhalten** aus. Wenn diese Option deaktiviert ist, wurde die Instance entweder bereits angehalten oder das Root-Volume ist ein Instance-Speicher-Volume.

1. Wenn Sie zur Bestätigung aufgefordert werden, wählen Sie **Stop** aus. Das Anhalten der Instance kann einige Minuten dauern.

1. Wählen Sie mit der ausgewählten Instance **Aktionen**, **Instance-Einstellungen**, **Benutzerdaten bearbeiten** aus.

1. Ändern Sie die Benutzerdaten nach Bedarf und wählen Sie dann **Speichern**.

1. Starten Sie die Instance. Die neuen Benutzerdaten werden nach dem Start in Ihrer Instance angezeigt, Benutzerdatenskripts werden jedoch nicht ausgeführt.

### Benutzerdaten und Cloud-Init-Anweisungen
<a name="user-data-cloud-init"></a>

Das Cloud-Init-Paket konfiguriert bestimmte Aspekte einer neuen Amazon Linux-Instance bei deren Start. Insbesondere wird die Datei `.ssh/authorized_keys` für den ec2-user konfiguriert, sodass Sie sich mit dem eigenen privaten Schlüssel anmelden können. Weitere Informationen zu den Konfigurationsaufgaben, die das cloud-init-Paket für Amazon-Linux-Instances ausführt, finden Sie in der folgenden Dokumentation:
+ **Amazon Linux 2023** – [Maßgeschneiderte cloud-init](https://docs.aws.amazon.com/linux/al2023/ug/cloud-init.html)
+ **Amazon Linux 2** – [Cloud-init in Amazon Linux 2 verwenden](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html)

Die Cloud-Init-Anweisungen können wie ein Skript auch beim Start einer Instance an diese weitergeleitet werden, wenngleich sich die Syntax unterscheidet. Weitere Informationen zu Cloud-Init finden Sie unter. [https://cloudinit.readthedocs.org/en/latest/index.html](https://cloudinit.readthedocs.org/en/latest/index.html)

**Wichtig**  
Standardmäßig werden Benutzerdatenskripte und Cloud-init-Direktiven nur während des Startzyklus ausgeführt, wenn Sie eine Instance zum ersten Mal starten. Sie können Ihre Konfiguration aktualisieren, um sicherzustellen, dass Ihre Benutzerdatenskripte und Cloud-Init-Direktiven bei jedem Neustart der Instance ausgeführt werden. Weitere Informationen finden Sie unter [Wie kann ich Benutzerdaten verwenden, um bei jedem Neustart meiner Amazon EC2 EC2-Linux-Instance automatisch ein Skript auszuführen](https://repost.aws/knowledge-center/execute-user-data-ec2)? im AWS Knowledge Center.

Wenn diese Skripts beim Start ausgeführt werden sollen, verlängert sich dadurch die Dauer des Instance-Starts. Erlauben Sie einige Minuten für die vollständige Ausführung der Aufgaben, bevor Sie überprüfen, ob die Benutzerdatenanweisungen vollständig durchgeführt wurden.

**So leiten Sie cloud-init-Anweisungen an eine Amazon-Linux-Instance weiter**

1. Folgen Sie dem Verfahren unter [Starten einer Instance](ec2-launch-instance-wizard.md). Das Feld **User data** (Benutzerdaten) befindet sich im Abschnitt [Erweiterte Details](ec2-instance-launch-parameters.md#liw-advanced-details) des Launch Instance Wizard. Geben Sie den Text Ihrer cloud-init-Anweisung im Feld **User Data** (Benutzerdaten) ein und führen Sie dann das Verfahren zum Starten der Instance aus.

   Die folgenden Beispiele zeigen, wie Anweisungen einen Webserver in Amazon Linux erstellen und konfigurieren. Die Zeile `#cloud-config` ganz oben ist erforderlich, um die Befehle als cloud-init-Anweisungen zu identifizieren.

------
#### [ AL2023 ]

   ```
   #cloud-config
   package_update: true
   package_upgrade: all
   	
   packages:
   - httpd
   - mariadb105-server
   - php8.1
   - php8.1-mysqlnd
   
   runcmd:
   - systemctl start httpd
   - systemctl enable httpd
   - [ sh, -c, "usermod -a -G apache ec2-user" ]
   - [ sh, -c, "chown -R ec2-user:apache /var/www" ]
   - chmod 2775 /var/www
   - [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
   - [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
   - [ sh, -c, 'echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php' ]
   ```

------
#### [ AL2 ]

   ```
   #cloud-config
   package_update: true
   package_upgrade: all
   	
   packages:
   - httpd
   - mariadb-server
   	
   runcmd:
   - [ sh, -c, "amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2" ]
   - systemctl start httpd
   - systemctl enable httpd
   - [ sh, -c, "usermod -a -G apache ec2-user" ]
   - [ sh, -c, "chown -R ec2-user:apache /var/www" ]
   - chmod 2775 /var/www
   - [ find, /var/www, -type, d, -exec, chmod, 2775, {}, \; ]
   - [ find, /var/www, -type, f, -exec, chmod, 0664, {}, \; ]
   - [ sh, -c, 'echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php' ]
   ```

------

1. Geben Sie der Instance ausreichend Zeit zum Starten und zum Ausführen der Anweisungen in Ihren Benutzerdaten, dann überprüfen Sie, ob die Anweisungen die gewünschten Aufgaben ausgeführt haben.

   Geben Sie für dieses Beispiel in einem Webbrowser die URL der PHP-Testdatei ein, die die Anweisungen erstellt haben. Diese URL ist die öffentliche DNS-Adresse Ihrer Instance, gefolgt von einem Schrägstrich und dem Dateinamen.

   ```
   http://my.public.dns.amazonaws.com/phpinfo.php
   ```

   Die PHP-Informationsseite wird angezeigt. Wenn Sie die PHP-Informationsseite nicht anzeigen können, prüfen Sie, ob die verwendete Sicherheitsgruppe eine Regel enthält, um den HTTP-Datenverkehr (Port 80) zuzulassen. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln konfigurieren](changing-security-group.md#add-remove-security-group-rules).

1. (Optional) Wenn Ihre Anweisungen nicht die Aufgaben erfüllt haben, die Sie erwartet haben oder wenn Sie nur überprüfen möchten, ob Ihre Direktiven ohne Fehler abgeschlossen wurden, [stellen Sie eine Verbindung mit der Instance her](connect-to-linux-instance.md), untersuchen Sie die Ausgabeprotokolldatei (`/var/log/cloud-init-output.log`) und suchen Sie nach Fehlermeldungen in der Ausgabe. Weitere Informationen zur Fehlerbehebung erhalten Sie, indem Sie den Anweisungen die folgende Zeile hinzufügen:

   ```
   output : { all : '| tee -a /var/log/cloud-init-output.log' }
   ```

   Diese Anweisung übermittelt die Ausgabe von **runcmd** an `/var/log/cloud-init-output.log`.

### Benutzerdaten und die AWS CLI
<a name="user-data-api-cli"></a>

Sie können den verwenden, AWS CLI um die Benutzerdaten für Ihre Instance anzugeben, zu ändern und anzuzeigen. Informationen zum Anzeigen von Benutzerdaten Ihrer Instance mithilfe von Instance-Metadaten erhalten Sie unter [Auf Instance-Metadaten für eine EC2-Instance zugreifen](instancedata-data-retrieval.md).

Unter Windows können Sie den AWS Tools for Windows PowerShell anstelle von verwenden AWS CLI. Weitere Informationen finden Sie unter [Benutzerdaten und die Tools für Windows PowerShell](#user-data-powershell).

**Beispiel: Angeben von Benutzerdaten beim Start**  
Verwenden Sie den Befehl [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) mit dem Parameter `--user-data`, um Benutzerdaten beim Start Ihrer Instance anzugeben. Mit **run-instances** AWS CLI führt der die Base64-Kodierung der Benutzerdaten für Sie durch.

Im folgenden Beispiel wird gezeigt, wie Sie ein Skript als String auf der Befehlszeile angeben:

```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
    --key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
    --user-data echo user data
```

Im folgenden Beispiel wird gezeigt, wie Sie ein Skript mithilfe einer Textdatei angeben: Verwenden Sie beim Angeben der Datei das Präfix `file://`.

```
aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
    --key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
    --user-data file://my_script.txt
```

Das folgende Element ist eine Beispieltextdatei mit einem Shell-Skript.

```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

**Beispiel: Modifizieren der Benutzerdaten einer angehaltenen Instance**  
Sie können die Benutzerdaten einer gestoppten Instanz mit dem [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html)Befehl ändern. Mit **modify-instance-attribute** AWS CLI führt der keine Base64-Kodierung der Benutzerdaten für Sie durch.
+ Verwenden Sie auf einem **Linux**-Computer den Befehl „base64“, um die Benutzerdaten zu codieren.

  ```
  base64 my_script.txt >my_script_base64.txt
  ```
+ Verwenden Sie auf einem, **Windows**-Computer den Befehl „certutil“, um die Benutzerdaten zu codieren. Bevor Sie diese Datei mit dem verwenden können AWS CLI, müssen Sie die erste (BEGIN CERTIFICATE) und die letzte Zeile (END CERTIFICATE) entfernen.

  ```
  certutil -encode my_script.txt my_script_base64.txt
  notepad my_script_base64.txt
  ```

Verwenden Sie die Parameter `--attribute` und `--value`, um die codierte Textdatei zur Angabe der Benutzerdaten zu verwenden. Verwenden Sie beim Angeben der Datei das Präfix `file://`.

```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --value file://my_script_base64.txt
```

**Beispiel: Löschen der Benutzerdaten einer angehaltenen Instance**  
Verwenden Sie den [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html)Befehl wie folgt, um die vorhandenen Benutzerdaten zu löschen:

```
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --user-data Value=
```

**Beispiel: Anzeigen von Benutzerdaten**  
Verwenden Sie den [describe-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-attribute.html)Befehl, um die Benutzerdaten für eine Instanz abzurufen. Mit **describe-instance-attribute** AWS CLI führt der keine Base64-Decodierung der Benutzerdaten für Sie durch.

```
aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData
```

Im folgenden Beispiel wird die Ausgabe mit base64-Benutzerdaten verschlüsselt.

```
{
    "UserData": {
        "Value": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQpzZXJ2aWNlIGh0dHBkIHN0YXJ0CmNoa2NvbmZpZyBodHRwZCBvbg=="
    },
    "InstanceId": "i-1234567890abcdef0"
}
```
+ Verwenden Sie auf einem **Linux**-Computer die Option `--query`, um die codierten Benutzerdaten abzurufen, und den Befehl „base64“, um sie zu decodieren.

  ```
  aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" | base64 --decode
  ```
+ Verwenden Sie auf einem **Windows**-Computer die Option `--query`, um die codierten Benutzerdaten abzurufen, und den Befehl „certutil“, um sie zu decodieren. Die codierte Ausgabe wird in einer, die decodierte Ausgabe in einer anderen Datei gespeichert.

  ```
  aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute userData --output text --query "UserData.Value" >my_output.txt
  certutil -decode my_output.txt my_output_decoded.txt
  type my_output_decoded.txt
  ```

Es folgt eine Beispielausgabe.

```
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```

### Kombinieren von Shell-Skripts und cloud-init-Anweisungen
<a name="user-data-mime-multi"></a>

Standardmäßig können Sie jeweils nur einen Inhaltstyp in Benutzerdaten einbeziehen. Allerdings können Sie die Inhaltstypen `text/cloud-config` und `text/x-shellscript` in einer mehrteiligen MIME-Datei verwenden, um sowohl ein Shell-Skript als auch cloud-init-Anweisungen in Ihren Benutzerdaten einzubeziehen.

Nachfolgend wird das mehrteilige MIME-Format veranschaulicht.

```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
	
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
	
#cloud-config
cloud-init directives
	
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
	
#!/bin/bash
shell script commands
--//--
```

Die folgenden Benutzerdaten enthalten beispielsweise cloud-init-Anweisungen und ein Bash-Shell-Skript. Die cloud-init-Anweisungen erstellen eine Datei (`/test-cloudinit/cloud-init.txt`) und schreiben `Created by cloud-init` in diese Datei. Das Bash-Shell-Skript erstellt eine Datei (`/test-userscript/userscript.txt`) und schreibt `Created by bash shell script` in diese Datei.

```
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
	
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
	
#cloud-config
runcmd:
- [ mkdir, /test-cloudinit ]
write_files:
- path: /test-cloudinit/cloud-init.txt
content: Created by cloud-init
	
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
	
#!/bin/bash
mkdir test-userscript
touch /test-userscript/userscript.txt
echo "Created by bash shell script" >> /test-userscript/userscript.txt
--//--
```

## So verarbeitet Amazon EC2 Benutzerdaten für Linux-Instances
<a name="ec2-windows-user-data"></a>

Auf Windows-Instances führt der Start-Agent die Aufgaben im Zusammenhang mit Benutzerdaten aus. Weitere Informationen finden Sie hier:
+ [EC2Starten Sie v2](ec2launch-v2.md) 
+ [EC2Starten](ec2launch.md) 
+ [EC2Config](ec2config-service.md)

[Beispiele für die Zusammenstellung einer `UserData` Eigenschaft in einer CloudFormation Vorlage finden Sie unter [Base64-kodierte Eigenschaft und Base64-kodierte UserData Eigenschaft mit](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64) und. UserData AccessKey SecretKey](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-general.html#scenario-userdata-base64-with-keys)

Ein Beispiel für die Ausführung von Befehlen auf einer Instance innerhalb einer Auto-Scaling-Gruppe, die mit Lifecycle Hooks arbeitet, finden Sie im [Tutorial: Konfigurieren von Benutzerdaten zum Abrufen des Ziel-Lifecycle-Status über Instance-Metadaten](https://docs.aws.amazon.com/autoscaling/ec2/userguide/tutorial-lifecycle-hook-instance-metadata.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.

**Topics**
+ [

### Benutzerdatenskripts
](#user-data-scripts)
+ [

### Komprimierte Benutzerdaten
](#user-data-compressed)
+ [

### Ausführung von Benutzerdaten
](#user-data-execution)
+ [

### Benutzerdaten und die Tools für Windows PowerShell
](#user-data-powershell)

### Benutzerdatenskripts
<a name="user-data-scripts"></a>

Damit `EC2Config` oder `EC2Launch` Skripte ausführen können, müssen Sie das Skript in ein spezielles Tag einschließen, wenn Sie es zu den Benutzerdaten hinzufügen. Welches Tag Sie verwenden, hängt davon ab, ob die Befehle in einem Befehlszeilenfenster (Batch-Befehle) oder unter Windows ausgeführt werden. PowerShell

Wenn Sie sowohl ein Batch-Skript als auch ein PowerShell Windows-Skript angeben, wird das Batch-Skript zuerst und das PowerShell Windows-Skript als Nächstes ausgeführt, unabhängig von der Reihenfolge, in der sie in den Instanzbenutzerdaten erscheinen.

Wenn Sie eine AWS API, einschließlich der AWS CLI, in einem Benutzerdatenskript verwenden, müssen Sie beim Starten der Instanz ein Instanzprofil verwenden. Ein Instanzprofil stellt die entsprechenden AWS Anmeldeinformationen bereit, die das Benutzerdatenskript für den API-Aufruf benötigt. Weitere Informationen finden Sie unter [Instance-Profile](iam-roles-for-amazon-ec2.md#ec2-instance-profile). Die Berechtigungen, die Sie der IAM-Rolle zuweisen, hängen davon ab, welche Dienste Sie mit der API aufrufen. Weitere Informationen finden Sie unter [IAM-Rollen für Amazon EC2](iam-roles-for-amazon-ec2.md).

**Topics**
+ [

#### Syntax für Batch-Skripts
](#user-data-batch-scripts)
+ [

#### Syntax für PowerShell Windows-Skripts
](#user-data-powershell-scripts)
+ [

#### Syntax für YAML-Konfigurationsskripts
](#user-data-yaml-scripts)
+ [

#### Base64-Codierung
](#user-data-base64-encoding)

#### Syntax für Batch-Skripts
<a name="user-data-batch-scripts"></a>

Geben Sie ein Batch-Skript unter Verwendung des `script`-Tags (Markierung) an. Trennen Sie die Befehle durch Zeilenumbrüche, wie im folgenden Beispiel gezeigt.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
```

In der Standardeinstellung werden Benutzerdatenskripte einmal ausgeführt, wenn Sie die Instance starten. Um die Benutzerdaten-Skripts bei jedem Neustart oder Starten der Instance auszuführen, fügen Sie den Benutzerdaten `<persist>true</persist>` hinzu.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
<persist>true</persist>
```

**EC2Starten Sie den v2-Agenten**  
Um ein XML-Benutzerdatenskript als eigenständigen Prozess mit der **executeScript** Aufgabe EC2 Launch v2 in der `UserData` Phase auszuführen, fügen Sie `<detach>true</detach>` weitere Benutzerdaten hinzu.

**Anmerkung**  
Das detach-Tag wird auf früheren Start-Agenten nicht unterstützt.

```
<script>
    echo Current date and time >> %SystemRoot%\Temp\test.log
    echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
</script>
<detach>true</detach>
```

#### Syntax für PowerShell Windows-Skripts
<a name="user-data-powershell-scripts"></a>

Die AWS Windows AMIs enthalten die [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/), sodass Sie diese Cmdlets in Benutzerdaten angeben können. Wenn Sie Ihrer Instance eine IAM-Rolle zuordnen, müssen Sie keine Anmeldeinformationen für die Cmdlets angeben, da Anwendungen, die auf der Instance ausgeführt werden, die Anmeldeinformationen der Rolle verwenden, um auf AWS Ressourcen (z. B. Amazon S3 S3-Buckets) zuzugreifen.

Geben Sie mithilfe des Tags ein PowerShell Windows-Skript an. `<powershell>` Trennen Sie die Befehle mithilfe von Zeilenumbrüchen voneinander. Beim `<powershell>`-Tag wird die Groß- und Kleinschreibung beachtet.

Beispiel:

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
```

Standardmäßig werden Benutzerdaten-Skripts einmal ausgeführt, wenn Sie die Instance starten. Um die Benutzerdaten-Skripts bei jedem Neustart oder Starten der Instance auszuführen, fügen Sie den Benutzerdaten `<persist>true</persist>` hinzu.

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

Sie können ein oder mehrere PowerShell Argumente mit dem `<powershellArguments>` Tag angeben. Wenn keine Argumente übergeben werden, fügen EC2 EC2 Launch und Launch v2 standardmäßig das folgende Argument hinzu:`-ExecutionPolicy Unrestricted`.

**Beispiel:**

```
<powershell>
    $file = $env:SystemRoot + "\Temp" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<powershellArguments>-ExecutionPolicy Unrestricted -NoProfile -NonInteractive</powershellArguments>
```

**EC2Starten Sie den v2-Agenten**  
Um ein XML-Benutzerdatenskript als eigenständigen Prozess mit der **executeScript** Aufgabe EC2 Launch v2 in der `UserData` Phase auszuführen, fügen Sie `<detach>true</detach>` weitere Benutzerdaten hinzu.

**Anmerkung**  
Das detach-Tag wird auf früheren Start-Agenten nicht unterstützt.

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<detach>true</detach>
```

#### Syntax für YAML-Konfigurationsskripts
<a name="user-data-yaml-scripts"></a>

Wenn Sie EC2 Launch v2 zum Ausführen von Skripten verwenden, können Sie das YAML-Format verwenden. Konfigurationsaufgaben, Details und Beispiele für EC2 Launch v2 finden Sie unter[EC2Starten Sie die v2-Aufgabenkonfiguration](ec2launch-v2-settings.md#ec2launch-v2-task-configuration).

Geben Sie ein YAML-Skript mit der Aufgabe `executeScript` an.

**Beispiel für eine YAML-Syntax zum Ausführen eines Skripts PowerShell ** 

```
version: 1.0
tasks:
- task: executeScript
  inputs:
  - frequency: always
    type: powershell
    runAs: localSystem
    content: |-
      $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
      New-Item $file -ItemType file
```

**YAML-Beispielsyntax zum Ausführen eines Batch-Skripts**

```
version: 1.1
tasks:
- task: executeScript
  inputs:
  - frequency: always
    type: batch
    runAs: localSystem
    content: |-
      echo Current date and time >> %SystemRoot%\Temp\test.log
      echo %DATE% %TIME% >> %SystemRoot%\Temp\test.log
```

#### Base64-Codierung
<a name="user-data-base64-encoding"></a>

Wenn Sie die Amazon EC2-API oder ein Tool verwenden, mit dem keine Base64-Codierung der Benutzerdaten durchgeführt wird, müssen Sie die Benutzerdaten selbst codieren. Andernfalls wird ein Fehler ausgegeben, der darauf hinweist, dass keine auszuführenden `script`- oder `powershell`-Tags gefunden wurden. Im Folgenden finden Sie ein Beispiel, das mit Windows codiert. PowerShell

```
$UserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Script))
```

Das Folgende ist ein Beispiel für die Dekodierung mit. PowerShell

```
$Script = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($UserData))
```

[Weitere Informationen zur Base64-Kodierung finden Sie unter https://www.ietf. org/rfc/rfc](https://www.ietf.org/rfc/rfc4648.txt)4648.txt.

### Komprimierte Benutzerdaten
<a name="user-data-compressed"></a>

EC2Launch v2 unterstützt komprimierte Benutzerdaten als Methode zum Senden von Benutzerdaten, die das IMDS-Limit von 16 KB überschreiten. Um dieses Feature zu verwenden, komprimieren Sie Ihr Benutzerdatenskript in ein `.zip`-Archiv und übergeben es an Ihre EC2-Instance. Wenn EC2 Launch v2 komprimierte Benutzerdaten erkennt, wird das komprimierte Benutzerdatenskript automatisch entpackt und ausgeführt.

Wenn Sie die Amazon-EC2-API oder ein Tool verwenden, mit dem keine base64-Codierung der Benutzerdaten durchgeführt wird, müssen Sie genauso wie bei Standard-Benutzerdaten die komprimierten Benutzerdaten selbst codieren. Weitere Informationen zur Größenbeschränkung für Benutzerdaten und base64-Codierung finden Sie unter [Auf Instance-Metadaten für eine EC2-Instance zugreifen](instancedata-data-retrieval.md).

### Ausführung von Benutzerdaten
<a name="user-data-execution"></a>

Standardmäßig ist in allen AWS Windows-Versionen AMIs die Ausführung von Benutzerdaten für den ersten Start aktiviert. Sie können vorgeben, dass die Benutzerdaten-Skripts beim nächsten Neustart oder erneuten Starten der Instance ausgeführt werden sollen. Alternativ können Sie vorgeben, dass die Benutzerdaten-Skripts bei jedem Neustart oder erneuten Starten der Instance ausgeführt werden sollen.

**Anmerkung**  
Benutzerdaten können nach dem ersten Start nicht standardmäßig ausgeführt werden. Informationen darüber, wie Sie Benutzerdaten beim Neustart oder beim Starten der Instance ausführen können, finden Sie unter [Skripts bei nachfolgenden Neustarts oder Starts ausführen](#user-data-scripts-subsequent).

Benutzerdaten-Skripts werden vom lokalen Administratorkonto ausgeführt, wenn ein zufälliges Passwort generiert wird. Andernfalls werden Benutzerdaten-Skripts vom Systemkonto ausgeführt.

#### Skripte zum Starten von Instances
<a name="user-data-scripts-launch"></a>

Skripts in den Instance-Benutzerdaten werden beim ersten Start der Instance ausgeführt. Ist der `persist`-Tag (Markierung) vorhanden, wir die Ausführung der Benutzerdaten für nachfolgende Neustarts oder Starts aktiviert. Die Protokolldateien für EC2 Launch v2, EC2 Launch und EC2 Config enthalten die Ausgabe der Standardausgabe- und Standardfehlerstreams.

**EC2Starten Sie v2**  
Die Protokolldatei für EC2 Launch v2 ist`C:\ProgramData\Amazon\EC2Launch\log\agent.log`.

**Anmerkung**  
Der Ordner `C:\ProgramData` ist möglicherweise ausgeblendet. Zum Anzeigen des Ordners müssen Sie die ausgeblendeten Dateien und Ordner einblenden.

Bei der Ausführung von Benutzerdaten werden die folgenden Informationen protokolliert:
+ `Info: Converting user-data to yaml format` – Wenn die Benutzerdaten im XML-Format bereitgestellt wurden
+ `Info: Initialize user-data state` – Der Beginn der Benutzerdatenausführung
+ `Info: Frequency is: always` – Wenn die Benutzerdatenaufgabe bei jedem Start ausgeführt wird
+ `Info: Frequency is: once` – Wenn die Benutzerdatenaufgabe nur einmal ausgeführt wird
+ `Stage: postReadyUserData execution completed` – Das Ende der Ausführung von Benutzerdaten

**EC2Starten**  
Die Protokolldatei für EC2 Launch ist`C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.log`.

Der Ordner `C:\ProgramData` ist möglicherweise ausgeblendet. Zum Anzeigen des Ordners müssen Sie die ausgeblendeten Dateien und Ordner einblenden.

Bei der Ausführung von Benutzerdaten werden die folgenden Informationen protokolliert:
+ `Userdata execution begins` – Der Beginn der Benutzerdatenausführung
+ `<persist> tag was provided: true` – Wenn das persist-Tag (Markierung) gefunden wird
+ `Running userdata on every boot` – Wenn der persist-Tag (Markierung) gefunden wird
+ `<powershell> tag was provided.. running powershell content` – Wenn der powershell-Tag (Markierung) gefunden wird
+ `<script> tag was provided.. running script content` – Wenn der Skript-Tag (Markierung) gefunden wird
+ `Message: The output from user scripts` – Wenn Benutzerdatenskripte ausgeführt werden, wird deren Ausgabe protokolliert

**EC2Config**  
Die Protokolldatei für EC2 Config ist`C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2Config.log`. Bei der Ausführung von Benutzerdaten werden die folgenden Informationen protokolliert:
+ `Ec2HandleUserData: Message: Start running user scripts` – Der Beginn der Benutzerdatenausführung
+ `Ec2HandleUserData: Message: Re-enabled userdata execution` – Wenn der persist-Tag (Markierung) gefunden wird
+ `Ec2HandleUserData: Message: Could not find <persist> and </persist>` – Wenn der persist-Tag (Markierung) nicht gefunden wird
+ `Ec2HandleUserData: Message: The output from user scripts` – Wenn Benutzerdatenskripte ausgeführt werden, wird deren Ausgabe protokolliert

#### Skripts bei nachfolgenden Neustarts oder Starts ausführen
<a name="user-data-scripts-subsequent"></a>

Wenn Sie Instance-Benutzerdaten aktualisieren, wird der aktualisierte Benutzerdateninhalt automatisch in den Instance-Metadaten wiedergegeben, wenn Sie die Instance das nächste Mal starten oder neu starten. Je nach installiertem Launch-Agent kann jedoch eine zusätzliche Konfiguration erforderlich sein, um Benutzerdatenskripts so zu konfigurieren, dass sie bei nachfolgenden Starts oder Neustarts ausgeführt werden.

Wenn Sie die Option **Herunterfahren mit Sysprep** wählen, werden Benutzerdatenskripts beim Start oder Neustart der Instance ausgeführt, auch wenn Sie die Ausführung der Benutzerdaten für nachfolgende Starts oder Neustarts nicht aktiviert haben.

Für Anweisungen zur Aktivierung der Benutzerdatenausführung wählen Sie die Registerkarte aus, die Ihrem Start-Agenten entspricht.

------
#### [ EC2Launch v2 ]

Im Gegensatz zu EC2 EC2 Launch v1 wertet Launch v2 die Benutzerdatenaufgabe bei jedem Start aus. Es ist nicht erforderlich, die Benutzerdatenaufgabe manuell zu planen. Die Benutzerdaten werden auf der Grundlage der angegebenen Frequenz- oder Persistenzoptionen ausgeführt.

Für XML-Benutzerdatenskripts  
Um Benutzerdatenskripts bei jedem Start auszuführen, fügen Sie den Benutzerdaten das `<persist>true</persist>`-Flag hinzu. Wenn das Persist-Flag nicht enthalten ist, wird das Benutzerdatenskript nur beim ersten Start ausgeführt.

Für YAML-Benutzerdaten  
+ Wenn eine Aufgabe beim ersten Start für Benutzerdaten ausgeführt werden soll, setzen Sie die Aufgaben-`frequency` auf `once`.
+ Wenn eine Aufgabe bei jedem Start für Benutzerdaten ausgeführt werden soll, setzen Sie die Aufgaben-`frequency` auf `always`.

------
#### [ EC2Launch ]

1. Herstellen einer Verbindung mit Ihrer Windows-Instance.

1. Öffnen Sie ein PowerShell Befehlsfenster und führen Sie einen der folgenden Befehle aus:

**Einmal ausführen**  
Um Benutzerdaten beim nächsten Start einmal auszuführen, verwenden Sie das `-Schedule`-Flag.

   ```
   C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -Schedule
   ```

**Bei allen nachfolgenden Systemstarts ausführen**  
Um Benutzerdaten bei allen nachfolgenden Starts auszuführen, verwenden Sie das `-SchedulePerBoot`-Flag.

   ```
   C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -SchedulePerBoot
   ```

1. Trennen Sie die Verbindung zu Ihrer Windows-Instance. Um beim nächsten Starten der Instance aktualisierte Skripts auszuführen, halten Sie die Instance an und aktualisieren die Benutzerdaten.

------
#### [ EC2Config ]

1. Herstellen einer Verbindung mit Ihrer Windows-Instance.

1. Öffnen `C:\Program Files\Amazon\Ec2ConfigService\Ec2ConfigServiceSetting.exe`.

1. Wählen Sie **unter Benutzerdaten** die Option ** UserDataAusführung für den nächsten Dienststart aktivieren** aus.

1. Trennen Sie die Verbindung zu Ihrer Windows-Instance. Um beim nächsten Starten der Instance aktualisierte Skripts auszuführen, halten Sie die Instance an und aktualisieren die Benutzerdaten.

------

### Benutzerdaten und die Tools für Windows PowerShell
<a name="user-data-powershell"></a>

Sie können die Tools für Windows verwenden, PowerShell um die Benutzerdaten für Ihre Instanz anzugeben, zu ändern und anzuzeigen. Informationen zum Anzeigen von Benutzerdaten Ihrer Instance mithilfe von Instance-Metadaten erhalten Sie unter [Auf Instance-Metadaten für eine EC2-Instance zugreifen](instancedata-data-retrieval.md). Hinweise zu Benutzerdaten und dem AWS CLI finden Sie unter[Benutzerdaten und die AWS CLI](#user-data-api-cli).

**Beispiel: Angeben von Instance-Benutzerdaten beim Start**  
Erstellen Sie eine Textdatei mit Instance-Benutzerdaten. Um die Benutzerdaten-Skripts bei jedem Neustart oder Starten der Instance auszuführen, fügen Sie `<persist>true</persist>` hinzu, wie im folgenden Beispiel gezeigt.

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

Verwenden Sie den [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html)Befehl, um die Benutzerdaten für die Instanz anzugeben, wenn Sie Ihre Instance starten. Dieser Befehl führt keine Base64-Codierung der Benutzerdaten für Sie durch Verwenden Sie die folgenden Befehle, um die Benutzerdaten in einer Textdatei namens `script.txt` zu codieren.

```
PS C:\> $Script = Get-Content -Raw script.txt
PS C:\> $UserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Script))
```

Verwenden Sie den Parameter `-UserData`, um die Benutzerdaten an den Befehl **New-EC2Instance** zu übergeben.

```
PS C:\> New-EC2Instance -ImageId ami-abcd1234 -MinCount 1 -MaxCount 1 -InstanceType m3.medium \
    -KeyName my-key-pair -SubnetId subnet-12345678 -SecurityGroupIds sg-1a2b3c4d \
    -UserData $UserData
```

**Beispiel: Aktualisieren von Instance-Benutzerdaten einer angehaltenen Instance**  
Sie können die Benutzerdaten einer gestoppten Instance mithilfe des [Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html)Befehls ändern.

Erstellen Sie eine Textdatei mit dem neuen Skript. Verwenden Sie die folgenden Befehle, um die Benutzerdaten in der Textdatei namens `new-script.txt` zu codieren.

```
PS C:\> $NewScript = Get-Content -Raw new-script.txt
PS C:\> $NewUserData = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($NewScript))
```

Verwenden Sie die Parameter `-UserData` und `-Value`, um die Benutzerdaten anzugeben.

```
PS C:\> Edit-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData -Value $NewUserData
```

**Beispiel: Anzeige von Instance-Benutzerdaten**  
Verwenden Sie den [Get-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceAttribute.html)Befehl, um die Benutzerdaten für eine Instanz abzurufen.

```
PS C:\> (Get-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData).UserData
```

Es folgt eine Beispielausgabe. Beachten Sie, dass die Benutzerdaten codiert sind.

```
PHBvd2Vyc2hlbGw+DQpSZW5hbWUtQ29tcHV0ZXIgLU5ld05hbWUgdXNlci1kYXRhLXRlc3QNCjwvcG93ZXJzaGVsbD4=
```

Verwenden Sie die folgenden Befehle, um die codierten Benutzerdaten in einer Variablen zu speichern und anschließend zu decodieren.

```
PS C:\> $UserData_encoded = (Get-EC2InstanceAttribute -InstanceId i-1234567890abcdef0 -Attribute userData).UserData
PS C:\> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($UserData_encoded))
```

Es folgt eine Beispielausgabe.

```
<powershell>
    $file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
    New-Item $file -ItemType file
</powershell>
<persist>true</persist>
```

**Beispiel: Umbenennen der Instance entsprechend des Tag (Markierung)-Werts**  
Sie können den [Get-EC2Tag](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Tag.html)Befehl verwenden, um den Tag-Wert zu lesen, die Instance beim ersten Start so umzubenennen, dass sie dem Tag-Wert entspricht, und den Computer neu zu starten. Um diesen Befehl erfolgreich auszuführen, müssen Sie über eine Rolle mit `ec2:DescribeTags`-Berechtigungen verfügen, die der Instance zugeordnet sind, da Tag-Informationen per API-Aufruf abgerufen werden müssen. Weitere Informationen zu Einstellungsberechtigungen unter Verwendung von IAM-Rollen finden Sie unter [Anfügen einer IAM-Rolle an eine Instance](attach-iam-role.md).

------
#### [ IMDSv2 ]

```
<powershell>
    [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri 'http://169.254.169.254/latest/api/token' -UseBasicParsing
    $instanceId = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri 'http://169.254.169.254/latest/meta-data/instance-id' -UseBasicParsing
	$nameValue = (Get-EC2Tag -Filter @{Name="resource-id";Value=$instanceid},@{Name="key";Value="Name"}).Value
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------
#### [ IMDSv1 ]

```
<powershell>
	$instanceId = (Invoke-WebRequest http://169.254.169.254/latest/meta-data/instance-id -UseBasicParsing).content
	$nameValue = (Get-EC2Tag -Filter @{Name="resource-id";Value=$instanceid},@{Name="key";Value="Name"}).Value
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------

Sie können die Instance auch mit Tags aus Instance-Metadaten umbenennen, wenn Ihre Instance so konfiguriert ist, dass über die Instance-Metadaten auf Tags zugegriffen wird. Weitere Informationen finden Sie unter [Tags für Ihre EC2-Instances mithilfe von Instance-Metadaten anzeigen](work-with-tags-in-IMDS.md).

------
#### [ IMDSv2 ]

```
<powershell>
    [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri 'http://169.254.169.254/latest/api/token' -UseBasicParsing
	$nameValue = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri 'http://169.254.169.254/latest/meta-data/tags/instance/Name' -UseBasicParsing
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------
#### [ IMDSv1 ]

```
<powershell>
	$nameValue = Get-EC2InstanceMetadata -Path /tags/instance/Name
	$pattern = "^(?![0-9]{1,15}$)[a-zA-Z0-9-]{1,15}$"
	#Verify Name Value satisfies best practices for Windows hostnames
	If ($nameValue -match $pattern) 
	    {Try
	        {Rename-Computer -NewName $nameValue -Restart -ErrorAction Stop} 
	    Catch
	        {$ErrorMessage = $_.Exception.Message
	        Write-Output "Rename failed: $ErrorMessage"}}
	Else
	    {Throw "Provided name not a valid hostname. Please ensure Name value is between 1 and 15 characters in length and contains only alphanumeric or hyphen characters"}
</powershell>
```

------

# Identifizieren Sie jede Instance, die in einer einzelnen Anfrage gestartet wurde
<a name="AMI-launch-index-examples"></a>

In diesem Beispiel wird gezeigt, wie Sie Ihre Amazon-EC2-Instances sowohl mit Benutzerdaten als auch mit Instance-Metadaten konfigurieren können.

**Anmerkung**  
Die Beispiele in diesem Abschnitt verwenden die IPv4 Adresse des IMDS:`169.254.169.254`. Wenn Sie Instanz-Metadaten für EC2-Instances über die IPv6 Adresse abrufen, stellen Sie sicher, dass Sie stattdessen die IPv6 Adresse aktivieren und verwenden:. `[fd00:ec2::254]` Die IPv6 Adresse des IMDS ist mit Befehlen kompatibel. IMDSv2 Die IPv6 Adresse ist nur auf [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) in [Subnetzen zugänglich, die von IPv6 -unterstützt werden](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (Dual-Stack oder nur). IPv6 

Alice möchte vier Instances ihres bevorzugten Datenbank-AMI starten; die erste soll dabei als Master-Instance fungieren, die übrigen drei als Replikate. Beim Start der Instances möchte sie Benutzerdaten für die Replikationsstrategien der einzelnen Replikate hinzufügen. Sie weiß, dass diese Daten in allen vier Instances verwendet werden, d. h. sie muss die Benutzerdaten so strukturieren, dass jede Instance erkennt, welcher Teile für sie gedacht ist. Dies kann mithilfe des Instance-Metadatenwerts `ami-launch-index` erreicht werden; dieser ist für jede Instance eindeutig. Wenn sie mehrere Instances gleichzeitig startet, gibt das `ami-launch-index` die Reihenfolge an, in der die Instances gestartet wurden. Der Wert für die zuerst gestartete Instance ist `0`.

Hier sind die Benutzerdaten, die Alice erstellt hat.

```
replicate-every=1min | replicate-every=5min | replicate-every=10min
```

Die `replicate-every=1min`-Daten definieren die Konfiguration für das erste Replikat, `replicate-every=5min` definiert die Konfiguration für das zweite Replikat usw. Alice beschließt, diese Daten als ASCII-Zeichenfolge bereitzustellen; die Daten für die einzelnen Instances werden dabei durch ein Pipe-Symbol (`|`) voneinander getrennt.

Alice startet vier Instances mit dem Befehl [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) unter Angabe der Benutzerdaten.

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --count 4 \
    --instance-type t2.micro \
    --user-data "replicate-every=1min | replicate-every=5min | replicate-every=10min"
```

Nach dem Start sind in jeder Instance eine Kopie der Benutzerdaten und die folgenden Metadaten vorhanden:
+ AMI-ID: ami-0abcdef1234567890
+ Reservation ID: r-1234567890abcabc0
+ Public keys: none 
+ Security group name: default
+ Instance type: t2.micro

Jede Instance hat jedoch eindeutige Metadaten, wie in den folgenden Tabellen dargestellt.


| Metadaten | Value | 
| --- | --- | 
| instance-id | i-1234567890abcdef0 | 
| ami-launch-index | 0 | 
| public-hostname | ec2-203-0-113-25.compute-1.amazonaws.com | 
| public-ipv4 | 67.202.51.223 | 
| local-hostname | ip-10-251-50-12.ec2.internal | 
| local-ipv4 | 10.251.50.35 | 


| Metadaten | Value | 
| --- | --- | 
| instance-id | i-0598c7d356eba48d7 | 
| ami-launch-index | 1 | 
| public-hostname | ec2-67-202-51-224.compute-1.amazonaws.com | 
| public-ipv4 | 67.202.51.224 | 
| local-hostname | ip-10-251-50-36.ec2.internal | 
| local-ipv4 | 10.251.50.36 | 


| Metadaten | Value | 
| --- | --- | 
| instance-id | i-0ee992212549ce0e7 | 
| ami-launch-index | 2 | 
| public-hostname | ec2-67-202-51-225.compute-1.amazonaws.com | 
| public-ipv4 | 67.202.51.225 | 
| local-hostname | ip-10-251-50-37.ec2.internal | 
| local-ipv4 | 10.251.50.37 | 


| Metadaten | Value | 
| --- | --- | 
| instance-id | i-1234567890abcdef0 | 
| ami-launch-index | 3 | 
| public-hostname | ec2-67-202-51-226.compute-1.amazonaws.com | 
| public-ipv4 | 67.202.51.226 | 
| local-hostname | ip-10-251-50-38.ec2.internal | 
| local-ipv4 | 10.251.50.38 | 

Alice mit dem Wert unter `ami-launch-index` bestimmen, welcher Teil der Benutzerdaten für eine bestimmte Instance anzuwenden ist.

1. Sie stellt eine Verbindung mit einer der Instances her und ruft den `ami-launch-index` für diese Instance ab, um sicherzustellen, dass es sich um eines der Replikate handelt:

------
#### [ IMDSv2 ]

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

   Für die folgenden Schritte verwenden die IMDSv2 Anfragen das gespeicherte Token aus dem vorherigen IMDSv2 Befehl, vorausgesetzt, das Token ist nicht abgelaufen.

------
#### [ IMDSv1 ]

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

------

1. Sie speichert das `ami-launch-index` als Variable.

------
#### [ IMDSv2 ]

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

------
#### [ IMDSv1 ]

   ```
   [ec2-user ~]$ ami_launch_index=`curl http://169.254.169.254/latest/meta-data/ami-launch-index`
   ```

------

1. Sie speichert die Benutzerdaten als Variable.

------
#### [ IMDSv2 ]

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

------
#### [ IMDSv1 ]

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

------

1. Schließlich verwendet Alice den Befehl **cut**, um den Teil der Benutzerdaten zu extrahieren, der für diese Instance gilt.

------
#### [ IMDSv2 ]

   ```
   [ec2-user ~]$ echo $user_data | cut -d"|" -f"$ami_launch_index"
   replicate-every=5min
   ```

------
#### [ IMDSv1 ]

   ```
   [ec2-user ~]$ echo $user_data | cut -d"|" -f"$ami_launch_index"
   replicate-every=5min
   ```

------