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.
# HTTP-APIs für Kundenaufrufe veröffentlichen
Sie können Stufen und benutzerdefinierte Domänennamen verwenden, um Ihre API zu veröffentlichen, die Clients aufrufen können.
Eine API-Stufe ist ein logischer Verweis auf einen Lebenszyklusstatus Ihrer API (z. B. `dev`, `prod`, `beta` oder `v2`). Jede Stufe ist ein benannter Verweis auf eine Bereitstellung der API und wird für Clientanwendungen zum Aufrufen zur Verfügung gestellt. Sie können verschiedene Integrationen und Einstellungen für jede Stufe einer API konfigurieren.
Sie können benutzerdefinierte Domänennamen verwenden, um eine einfachere, intuitivere URL für Clients bereitzustellen, die Ihre API aufrufen können, als die Standard-UR, `https://api-id.execute-api.region.amazonaws.com/stage`.
**Anmerkung**
Um die Sicherheit Ihrer API-Gateway-APIs zu erhöhen, ist die `execute-api.{region}.amazonaws.com`-Domain in der [Public Suffix List (PSL](https://publicsuffix.org/)) registriert. Aus Sicherheitsgründen empfehlen wir Ihnen, Cookies mit einem `__Host-`-Präfix zu verwenden, falls Sie jemals sensible Cookies im Standard-Domain-Namen für Ihre API-Gateway-APIs einrichten müssen. Diese Vorgehensweise hilft Ihnen dabei, Ihre Domain vor CSRF-Versuchen (Cross-Site Request Forgery Attempts, Anforderungsfälschung zwischen Websites) zu schützen. Weitere Informationen finden Sie auf der [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes)-Seite im Mozilla Developer Network.
**Topics**
+ [Stufen für HTTP APIs im API Gateway](http-api-stages.md)
+ [Sicherheitsrichtlinie für HTTP APIs in API Gateway](http-api-ciphers.md)
+ [Benutzerdefinierte Domainnamen für HTTP-APIs in API Gateway](http-api-custom-domain-names.md)
# Stufen für HTTP APIs im API Gateway
Eine API-Stufe ist ein logischer Verweis auf einen Lebenszyklusstatus Ihrer API (z. B. `dev`, `prod`, `beta` oder `v2`). API-Stufen werden durch ihre API-ID und den Stufennamen identifiziert und sind in der URL enthalten, die Sie zum Aufrufen der API verwenden. Jede Stufe ist ein benannter Verweis auf eine Bereitstellung der API und wird für Clientanwendungen zum Aufrufen zur Verfügung gestellt.
Sie können eine `$default`-Phase erstellen, die beispielsweise von der Basis der URL Ihrer API bereitgestellt wird, z. B. `https://{api_id}.execute-api.{region}.amazonaws.com/`. Sie verwenden diese URL, um eine API-Phase aufzurufen.
Eine Bereitstellung ist ein Snapshot Ihrer API-Konfiguration. Nachdem Sie eine API in einer Phase bereitgestellt haben, kann sie von Clients aufgerufen werden. Sie müssen eine API bereitstellen, damit Änderungen wirksam werden. Wenn Sie automatische Bereitstellungen aktivieren, werden Änderungen an einer API automatisch für Sie freigegeben.
# Verwenden Sie Stage-Variablen für HTTP APIs in API Gateway
Stufenvariablen sind Schlüssel-Werte-Paare, die Sie für eine Stufe einer HTTP-API definieren können. Sie weisen dasselbe Verhalten auf wie Umgebungsvariablen und können für die API-Einrichtung verwendet werden.
Stage-Variablen sind nicht dazu gedacht, für sensible Daten wie Anmeldeinformationen verwendet zu werden. Verwenden Sie einen AWS Lambda Autorisierer, um sensible Daten an Integrationen weiterzugeben. Sie können sensible Daten an Integrationen in der Ausgabe des Lambda-Genehmigers übergeben. Weitere Informationen hierzu finden Sie unter [Antwortformat des Lambda-Genehmigers](http-api-lambda-authorizer.md#http-api-lambda-authorizer.payload-format-response).
## Beispiel – Den HTTP-Integrationsendpunkt mithilfe einer Stufenvariablen anpassen
Sie können beispielsweise eine Stufenvariable definieren und dann ihren Wert als HTTP-Endpunkt für eine HTTP-Proxy-Integration festlegen. Später können Sie den Endpunkt mithilfe des zugeordneten Stufenvariablennamens referenzieren. Auf diese Weise können Sie in jeder Stufe dieselbe API-Einrichtung mit einem anderen Endpunkt verwenden. In ähnlicher Weise können Sie Stufenvariablen verwenden, um für jede Phase Ihrer API eine andere AWS Lambda Funktionsintegration anzugeben.
Wenn Sie eine Stufenvariable zum Anpassen des HTTP-Integrationsendpunkts verwenden möchten, müssen Sie zunächst den Namen und den Wert der Stufenvariablen (z. B. `url`) mit dem Wert `example.com` festlegen. Richten Sie als Nächstes eine HTTP-Proxy-Integration ein. Anstatt die URL des Endpunkts einzugeben, können Sie API Gateway anweisen, den Wert der Stufenvariablen zu verwenden, **http://\$1\$1stageVariables.url\$1**. Dieser Wert weist API Gateway an, Ihre Stufenvariable `${}` zur Laufzeit abhängig von der Stufe Ihrer API zu ersetzen.
Sie können auf ähnliche Weise auf Stufenvariablen verweisen, um einen Lambda-Funktionsnamen oder einen AWS Rollen-ARN anzugeben.
Wenn Sie einen Lambda-Funktionsnamen als Stufenvariablenwert angeben, müssen Sie die Berechtigungen für die Lambda-Funktion manuell konfigurieren. Der folgende [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html)-Befehl konfiguriert die Berechtigung für die Lambda-Funktion:
```
aws lambda add-permission --function-name arn:aws:lambda:XXXXXX:your-lambda-function-name --source-arn arn:aws:execute-api:us-east-1:YOUR_ACCOUNT_ID:api_id/*/HTTP_METHOD/resource --principal apigateway.amazonaws.com --statement-id apigateway-access --action lambda:InvokeFunction
```
# API Gateway-Stufenvariablenreferenz für HTTP APIs in API Gateway
In den folgenden Fällen können Sie API Gateway APIs Gateway-Stufenvariablen für HTTP verwenden.
## HTTP-Integration URIs
Sie können eine Stufenvariable als Teil einer HTTP-Integrations-URI verwenden, wie in den folgenden Beispielen gezeigt.
+ Eine vollständige URI ohne Protokoll – `http://${stageVariables.}`
+ Eine vollständige Domäne – `http://${stageVariables.}/resource/operation`
+ Eine Unterdomäne – `http://${stageVariables.}.example.com/resource/operation`
+ Ein Pfad – `http://example.com/${stageVariables.}/bar`
+ Eine Abfragezeichenfolge – `http://example.com/foo?q=${stageVariables.}`
## Lambda-Funktionen
Sie können eine Stufenvariable anstelle eines Integrationsnamens oder Alias für die Lambda-Funktion verwenden, wie in den folgenden Beispielen gezeigt.
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function:${stageVariables.}/invocations`
+ `arn:aws:apigateway::lambda:path/2015-03-31/functions/arn:aws:lambda:::function::${stageVariables.}/invocations`
**Anmerkung**
Um eine Stufenvariable für eine Lambda-Funktion zu verwenden, muss sich die Funktion im selben Konto wie die API befinden. Stufenvariablen unterstützen keine kontoübergreifenden Lambda-Funktionen.
## AWS Anmeldeinformationen für die Integration
Sie können eine Stage-Variable als Teil eines ARN mit AWS Benutzer- oder Rollenanmeldedaten verwenden, wie im folgenden Beispiel gezeigt.
+ `arn:aws:iam:::${stageVariables.}`
# Sicherheitsrichtlinie für HTTP APIs in API Gateway
API Gateway erzwingt eine Sicherheitsrichtlinie von `TLS_1_2` für alle HTTP-API-Endpunkte.
Eine *Sicherheitsrichtlinie* ist eine vordefinierte Kombination aus einer TLS-Mindestversion und Verschlüsselungsverfahren, die von Amazon API Gateway bereitgestellt wird. Das TLS-Protokoll behandelt Netzwerksicherheitsprobleme wie Manipulationen und Abhören zwischen einem Client und einem Server. Wenn Ihre Clients über die benutzerdefinierte Domäne einen TLS-Handshake mit Ihrer API ausführen, erzwingt die Sicherheitsrichtlinie die TLS-Version und die Verschlüsselungssuite-Optionen, die von Ihren Clients verwendet werden können. Diese Sicherheitsrichtlinie akzeptiert TLS 1.2- und TLS 1.3-Verkehr und weist TLS 1.0-Verkehr zurück.
## Unterstützte TLS-Protokolle und Chiffren für HTTP APIs
In der folgenden Tabelle werden die unterstützten TLS-Protokolle für HTTP beschrieben. APIs
| **TLS-Protokolle** | **TLS\$11\$12-Sicherheitsrichtlinie** |
| --- | --- |
| TLSv13. | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| TLSv12. | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
In der folgenden Tabelle werden die TLS-Verschlüsselungen beschrieben, die für die Sicherheitsrichtlinie TLS 1\$12 für HTTP verfügbar sind. APIs
| **TLS-Verschlüsselungsverfahren** | **TLS\$11\$12-Sicherheitsrichtlinie** |
| --- | --- |
| TLS-AES-128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| TLS-AES-256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| TLS- - - CHACHA20 POLY1305 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-RSA- AES128 -GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-ECDSA- AES128 - SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-RSA- - AES128 SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-ECDSA- -GCM AES256 - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-RSA- AES256 -GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-ECDSA- AES256 - SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| ECDHE-RSA- - AES256 SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| AES128-GCM- SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| AES128-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| AES256-GCM- SHA384 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
| AES256-SHA256 | ![\[alt text not found\]](http://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/images/success_icon.svg) Ja |
## OpenSSL- und RFC-Verschlüsselungsnamen
OpenSSL und IETF RFC 5246 verwenden unterschiedliche Namen für die gleichen Verschlüsselungsverfahren. Eine Liste der Namen der Verschlüsselungsverfahren finden Sie unter [OpenSSL- und RFC-Verschlüsselungsnamen](apigateway-security-policies-list.md#apigateway-secure-connections-openssl-rfc-cipher-names).
## Informationen über REST und APIs WebSocket APIs
Weitere Informationen zu REST APIs und WebSocket APIs finden Sie unter [Wählen Sie eine Sicherheitsrichtlinie für Ihre benutzerdefinierte Domain in API Gateway](apigateway-custom-domain-tls-version.md) und[Sicherheitsrichtlinie für WebSocket APIs in API Gateway](websocket-api-ciphers.md).
# Benutzerdefinierte Domainnamen für HTTP-APIs in API Gateway
*Benutzerdefinierte Domainnamen* sind einfachere und intuitivere URLs, die Sie Ihren API-Benutzern zur Verfügung stellen können.
Nach der Bereitstellung der API können Sie (und Ihre Kunden) die API mit der Standardstamm-URL im folgenden Format aufrufen:
```
https://api-id.execute-api.region.amazonaws.com/stage
```
hierzu wird *api-id* in API Gateway generiert, *region* ist die AWS-Region und *stage* wird als Stufe angegeben wenn Sie die API bereitstellen.
Der Hostname-Teil der URL (also `api-id.execute-api.region.amazonaws.com`) verweist auf einen API-Endpunkt. Der Standard-API-Endpunkt hat möglicherweise einen schwer zu merkenden, zufallsgenerierten Namen, der nicht besonders benutzerfreundlich ist.
Mit benutzerdefinierten Domainnamen können Sie den Hostnamen Ihrer API einrichten und einen Basispfad (z. B. `myservice`) auswählen, um die alternative URL Ihrer API zuzuordnen. Eine benutzerfreundlichere API-Basis-URL kann dann folgendermaßen aussehen:
```
https://api.example.com/myservice
```
## Überlegungen
Die folgenden Überlegungen können sich auf Ihre Verwendung eines benutzerdefinierten Domainnamens auswirken.
+ Eine regionale benutzerdefinierte Domain kann REST-APIs and HTTP-APIs zugeordnet werden. Sie können API-Gateway-Version-2-APIs verwenden, um regionale benutzerdefinierte Domainnamen für REST-APIs zu erstellen und zu verwalten.
+ Als Mindest-TLS-Version wird ausschließlich TLS 1.2 unterstützt.
+ Sie müssen den Ressourceneintrag Ihres DNS-Anbieters erstellen oder aktualisieren, bevor Sie ihn dem API-Endpunkt zuordnen können. Ohne ein solches Mapping können API-Anfragen für den benutzerdefinierten Domainnnamen API Gateway nicht erreichen.
+ Mit einem Wildcard-Zertifikat können Sie eine nahezu unendliche Anzahl von Domainnamen unterstützen, ohne das Standardkontingent zu überschreiten. Weitere Informationen finden Sie unter [Benutzerdefinierte Domainnamen mit Platzhalter](#http-wildcard-custom-domain-names).
## Voraussetzungen
Im Folgenden sind die Voraussetzungen für die Erstellung eines benutzerdefinierten Domainnamens aufgeführt.
### Registrieren eines Domainnamens
Wenn Sie benutzerdefinierte Domainnamen für Ihre APIs einrichten möchten, müssen Sie eine Internetdomäne registrieren. Sie können Ihre Internetdomain mithilfe von [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) oder mit einem Domain-Registrar Ihrer Wahl registrieren. Ihr benutzerdefinierter Domainname kann der Name einer Unter- oder Root-Domain (Zone Apex) einer registrierten Internetdomain sein.
Ihr Domainname muss der [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4)-Spezifikation entsprechen und darf ein Maximum von 63 Oktetten pro Label und insgesamt 255 Oktetten nicht überschreiten.
### Zertifikate für benutzerdefinierte Domainnamen
Vor der Einrichtung eines benutzerdefinierten Domainnamens für eine API müssen Sie ein SSL-/TLS-Zertifikat in ACM vorbereiten. Wenn ACM in der AWS-Region nicht verfügbar ist, in der Sie Ihren benutzerdefinierten Domainnamen erstellen, müssen Sie ein Zertifikat für API Gateway in dieser Region importieren.
Wenn Sie ein SSL-/TLS-Zertifikat importieren möchten, müssen Sie den PEM-formatierten Hauptteil des SSL-/TLS-Zertifikats, den persönlichen Schlüssel und die Zertifikatkette für den benutzerdefinierten Domainnamen bereitstellen.
Ein in ACM gespeichertes Zertifikat wird durch seinen ARN angegeben. Wenn Sie Zertifikate verwenden, die von ACM ausgestellt werden, brauchen sich keine Gedanken über vertrauliche Zertifikatdetails wie private Schlüssel zu machen. Wenn Sie also ein von AWS verwaltetes Zertifikat für einen Domainnamen verwenden möchten, müssen Sie lediglich auf dessen ARN verweisen.
Wenn Ihre Anwendung, manchmal auch als Zertifikats-Pinning bekannt, verwendet, um ein ACM-Zertifikat zu pinnen, kann die Anwendung möglicherweise keine Verbindung zu Ihrer Domain herstellen, nachdem AWS das Zertifikat erneuert hat. Weitere Informationen finden Sie unter [Probleme beim Zertifikats-Pinning](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) im *AWS Certificate Manager-Benutzerhandbuch*.
## Benutzerdefinierte Domainnamen mit Platzhalter
Mit benutzerdefinierten Platzhalter-Domainnamen können Sie eine nahezu unendliche Anzahl von Domainnamen unterstützen, ohne das [Standardkontingent](limits.md)zu überschreiten. Zum Beispiel könnten Sie jedem Ihrer Kunden einen eigenen Domainnamen geben, `customername.api.example.com`.
Um einen benutzerdefinierten Platzhalterdomainnamen zu erstellen, geben Sie einen Platzhalter (`*`) als erste Subdomain einer benutzerdefinierten Domain an, die alle möglichen Subdomains einer Root-Domain darstellt.
Der benutzerdefinierte Domainnamen mit Platzhalter `*.example.com` führt beispielsweise zu Unterdomains wie `a.example.com`, `b.example.com` und `c.example.com`, die alle zur gleichen Domain weiterleiten.
Benutzerdefinierte Domainnamen mit Platzhaltern unterstützen andere Konfigurationen als die benutzerdefinierten Standarddomainnamen von API Gateway. Beispielsweise können Sie in einem einzelnen AWS-Konto `*.example.com` und `a.example.com` so konfigurieren, dass sie sich anders verhalten.
Um einen benutzerdefinierten Domänennamen mit Platzhalter zu erstellen, müssen Sie ein von ACM ausgestelltes Zertifikat angeben, das mithilfe der DNS- oder der E-Mail-Validierungsmethode validiert wurde.
**Anmerkung**
Sie können keinen benutzerdefinierten Domainnamen mit Platzhalter erstellen, wenn ein anderes AWS-Konto einen benutzerdefinierten Domainnamen erstellt hat, der mit dem benutzerdefinierten Domainnamen mit Platzhalter in Konflikt steht. Wurde `a.example.com` beispielsweise von Konto A erstellt, dann kann Konto B als benutzerdefinierten Domainnamen mit Platzhalter nicht `*.example.com` erstellen.
Wenn Konto A und Konto B den gleichen Besitzer haben, können Sie sich an das [AWS Supportcenter](https://console.aws.amazon.com/support/home#/) wenden, um eine Ausnahme anzufordern.
## Die nächsten Schritte für benutzerdefinierte Domainnamen
Verwenden Sie die Dokumentation aus dem REST-API-Abschnitt des API-Gateway-Entwicklerhandbuchs für die Einrichtung eines benutzerdefinierten Domainnamens für eine HTTP-API.
Geben Sie zunächst ein Zertifikat für Ihren benutzerdefinierten Domainnamen an. Weitere Informationen finden Sie unter [Bereiten Sie Zertifikate vor in AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md). Dann erstellen Sie einen regionalen benutzerdefinierten Domainnamen. Weitere Informationen finden Sie unter [Einrichten eines regionalen benutzerdefinierten Domainnamens in API Gateway](apigateway-regional-api-custom-domain-create.md).
# API-Stufen zu einem benutzerdefinierten Domainnamen für HTTP-APIs zuweisen
Sie verwenden API-Mappings, um API-Stufen mit einem benutzerdefinierten Domain-Namen zu verbinden. Nachdem Sie einen Domain-Namen erstellt und DNS-Einträge konfiguriert haben, verwenden Sie API-Mappings, um Datenverkehr über Ihren benutzerdefinierten Domain-Namen an Ihre APIs zu senden.
Ein API-Mapping gibt eine API, eine Phase und optional einen Pfad an, die für das Mapping verwendet werden sollen. Sie können beispielsweise die `production`-Phase einer API in `https://api.example.com/orders` abbilden.
Sie können HTTP-API- und REST-API--Stufen demselben benutzerdefinierten Domain-Namen zuweisen.
Bevor Sie ein API-Mapping erstellen, benötigen Sie eine API, eine Phase und einen benutzerdefinierten Domain-Namen. Weitere Informationen zum Erstellen eines benutzerdefinierten Domain-Namens finden Sie unter [Einrichten eines regionalen benutzerdefinierten Domainnamens in API Gateway](apigateway-regional-api-custom-domain-create.md).
## Weiterleiten von API-Anforderungen
Sie können API-Mappings mit mehreren Ebenen konfigurieren, z. B. `orders/v1/items` und `orders/v2/items`.
Bei API-Mappings mit mehreren Ebenen leitet API Gateway Anfragen an das API-Mapping weiter, die den längsten Übereinstimmungspfad hat. API Gateway berücksichtigt nur die für API-Mappings konfigurierten Pfade und keine API-Routen, um die aufzurufende API auszuwählen. Wenn kein Pfad mit der Anforderung übereinstimmt, sendet API Gateway die Anforderung an die API, die Sie dem leeren Pfad `(none)` zugeordnet haben.
Bei benutzerdefinierten Domain-Namen, die API-Mappings mit mehreren Ebenen verwenden, leitet API Gateway Anfragen an das API-Mapping weiter, die den längsten Übereinstimmungspräfix hat.
Betrachten Sie beispielsweise einen benutzerdefinierten Domain-Namen `https://api.example.com` mit den folgenden API-Mappings:
1. `(none)` API 1 zugewiesen.
1. `orders` API 2 zugewiesen.
1. `orders/v1/items` API 3 zugewiesen.
1. `orders/v2/items` API 4 zugewiesen.
1. `orders/v2/items/categories` API 5 zugewiesen.
| Anfrage | Ausgewählte API | Erklärung |
| --- | --- | --- |
| `https://api.example.com/orders` | `API 2` | Die Anforderung stimmt genau mit diesem API-Mapping überein. |
| `https://api.example.com/orders/v1/items` | `API 3` | Die Anforderung stimmt genau mit diesem API-Mapping überein. |
| `https://api.example.com/orders/v2/items` | `API 4` | Die Anforderung stimmt genau mit diesem API-Mapping überein. |
| `https://api.example.com/orders/v1/items/123` | `API 3` | API Gateway wählt das Mapping aus, das den längsten Übereinstimmungspfad hat. Das `123` am Ende der Anforderung hat keinen Einfluss auf die Auswahl. |
| `https://api.example.com/orders/v2/items/categories/5` | `API 5` | API Gateway wählt das Mapping aus, das den längsten Übereinstimmungspfad hat. |
| `https://api.example.com/customers` | `API 1` | API Gateway verwendet die leere Zuweisung als Catch-All. |
| `https://api.example.com/ordersandmore` | `API 2` | API Gateway wählt das Mapping aus, das den längsten Übereinstimmungspräfix hat. Bei einem benutzerdefinierten Domain-Namen, der mit einstufigen Mappings konfiguriert ist, z. B. nur `https://api.example.com/orders` und `https://api.example.com/`, würde API Gateway `API 1` auswählen, da es keinen passenden Pfad mit `ordersandmore` gibt. |
## Einschränkungen
+ In einer API-Zuweisung müssen sich der benutzerdefinierte Domainname und die zugeordneten APIs im selben AWS-Konto befinden.
+ API-Zuweisungen dürfen nur Buchstaben, Zahlen und die folgenden Zeichen enthalten: `$-_.+!*'()/`.
+ Die maximale Länge für den Pfad in einer API-Zuweisung beträgt 300 Zeichen.
+ Es können 200 API-Zuweisungen mit mehreren Ebenen für jeden Domainnamen vorhanden sein. Dieses Limit beinhaltet keine API-Zuweisungen mit einer einzigen Ebene, wie z. B. `/prod`.
+ Sie können HTTP-APIs nur einem regionalen benutzerdefinierten Domainnamen mit der TLS 1.2-Sicherheitsrichtlinie zuordnen.
+ Sie können WebSocket-APIs nicht demselben benutzerdefinierten Domainnamen wie dem einer HTTP-API oder REST-API zuweisen.
+ Wenn Sie mehrstufige API-Zuweisungen erstellen, konvertiert API Gateway alle Header-Namen in Kleinbuchstaben.
## Ein API-Mapping erstellen
Um ein API-Mapping zu erstellen, müssen Sie zuerst einen benutzerdefinierten Domain-Namen, eine API und eine Phase erstellen. Informationen zum Erstellen eines benutzerdefinierten Domain-Namens finden Sie unter [Einrichten eines regionalen benutzerdefinierten Domainnamens in API Gateway](apigateway-regional-api-custom-domain-create.md).
AWS Serverless Application Model-Beispielvorlagen, die alle Ressourcen erstellen, finden Sie unter [Sitzungen mit SAM](https://github.com/aws-samples/sessions-with-aws-sam/tree/master/custom-domains) auf GitHub.
------
#### [ AWS-Managementkonsole ]
**So erstellen Sie ein API-Mapping**
1. Melden Sie sich bei der API-Gateway-Konsole unter [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway) an.
1. Wählen Sie **benutzerdefinierte Domain-Namen** aus.
1. Wählen Sie einen benutzerdefinierten Domain-Namen aus, den Sie bereits erstellt haben.
1. Wählen Sie **API-Mappings** aus.
1. Wählen Sie **API-Zuweisungen konfigurieren** aus.
1. Wählen Sie **Neue Zuweisung hinzufügen** aus.
1. Geben Sie eine **API**, eine **Phase** und optional einen **Pfad** ein.
1. Wählen Sie **Speichern** aus.
------
#### [ AWS CLI ]
Der folgende [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api.html)-Befehl erstellt eine API-Zuweisung. In diesem Beispiel sendet API Gateway Anforderungen an `api.example.com/v1/orders` an die angegebene API und Phase.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1/orders \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
Mit dem folgenden CloudFormation-Beispiel wird ein API-Mapping erstellt.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'orders/v2/items'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Deaktivieren des Standardendpunkts für REST-APIs
Standardmäßig können Clients Ihre API mithilfe des `execute-api`-Endpunkts aufrufen, den API Gateway für Ihre API generiert. Um sicherzustellen, dass Kunden nur über einen benutzerdefinierten Domänennamen auf Ihre API zugreifen können, deaktivieren Sie den standardmäßigen `execute-api`-Endpunkt. Wenn Sie den Standardendpunkt deaktivieren, wirkt sich dies auf alle Stufen einer API aus.
Der folgende Vorgang zeigt, wie ein Standardendpunkt für eine HTTP-API deaktiviert wird.
------
#### [ AWS-Managementkonsole ]
1. Melden Sie sich bei der API Gateway-Konsole unter [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway) an.
1. Wählen Sie eine HTTP-API.
1. Wählen Sie die ID Ihrer API aus, um die Seite mit den **API-Details** zu öffnen.
1. Klicken Sie unter **API-Details** auf **Bearbeiten**.
1. Klicken Sie unter **Standardendpunkt** auf **Deaktivieren**.
1. Wählen Sie **Speichern** aus.
Wenn Sie für Ihre Stufe automatische Bereitstellungen aktivieren, müssen Sie Ihre API nicht erneut bereitstellen, damit die Änderung wirksam wird. Andernfalls müssen Sie Ihre API erneut bereitstellen.
1. (Optional) Klicken Sie auf **Bereitstellen** und stellen Sie Ihre API erneut bereit oder erstellen Sie eine neue Stufe, in der die Änderung wirksam werden soll.
------
#### [ AWS CLI ]
Der [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html)-Befehl deaktiviert den Standardendpunkt einer HTTP-API:
```
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
```
Nachdem Sie den Standardendpunkt deaktiviert haben, müssen Sie Ihre API bereitstellen, damit die Änderung wirksam wird, es sei denn, automatische Bereitstellungen sind aktiviert.
Der Befehl [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-deployment.html) erstellt eine Bereitstellung:
```
aws apigatewayv2 create-deployment \
--api-id abcdef123 \
--stage-name dev
```
------
# IP-Adresstypen für benutzerdefinierte Domainnamen für HTTP-APIs
Beim Erstellen einer API geben Sie den Typ der IP-Adressen an, die Ihre Domain aufrufen können. Sie können IPv4 auswählen, um IPv4-Adressen für den Aufruf Ihrer Domain zuzulassen, oder Dualstack, um sowohl IPv4- als auch IPv6-Adressen für den Aufruf zuzulassen. Wir empfehlen, den IP-Adresstyp auf Dualstack zu setzen, um Engpässe im IP-Adressraum zu vermeiden und Ihre Sicherheitsposition zu verbessern. Weitere Informationen zu den Vorteilen eines Dualstack-IP-Adresstyps finden Sie unter [IPv6 in AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
## Überlegungen zu IP-Adresstypen
Die folgenden Überlegungen können Ihre Verwendung von IP-Adresstypen beeinflussen.
+ Der Standard-IP-Adresstyp für benutzerdefinierte Domainnamen in API Gateway ist IPv4.
+ Ihr benutzerdefinierter Domainname muss nicht denselben IP-Adresstyp für alle darauf zugewiesenen APIs haben. Wenn Sie Ihren Standard-API-Endpunkt deaktivieren, kann dies die Art und Weise beeinflussen, wie Aufrufer Ihre API aufrufen können.
## Ändern des IP-Adresstyps eines benutzerdefinierten Domainnamens
Sie können den IP-Adresstyp ändern, indem Sie die Endpunktkonfiguration der Domain aktualisieren. Dies kann über die AWS-Managementkonsole, die AWS CLI, CloudFormation oder ein AWS SDK erfolgen.
------
#### [ AWS-Managementkonsole ]
**So ändern Sie den IP-Adresstyp eines benutzerdefinierten Domainnamens**
1. Melden Sie sich bei der API Gateway-Konsole unter [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway) an.
1. Wählen Sie einen öffentlichen benutzerdefinierten Domainnamen aus.
1. Wählen Sie **Endpunktkonfiguration** aus.
1. Wählen Sie unter „IP-Adresstyp“ entweder **IPv4** oder **Dualstack** aus.
1. Wählen Sie **Speichern** aus.
------
#### [ AWS CLI ]
Der folgende [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html)-Befehl aktualisiert eine API, sodass sie den IP-Adresstyp „Dualstack“ aufweist:
```
aws apigatewayv2 update-domain-name \
--domain-name dualstack.example.com \
--domain-name-configurations CertificateArn=arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc,IpAddressType=dualstack
```
Die Ausgabe sieht wie folgt aus:
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "dualstack.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-abcd1234.execute-api.us-east-1.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-5678-abc",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z3LQWSYCGH4ADY",
"SecurityPolicy": "TLS_1_2",
"IpAddressType": "dualstack"
}
],
"Tags": {}
}
```
------