View a markdown version of this page

Netzwerk - AWS Lambda

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.

Netzwerk

Sie konfigurieren den Netzwerkzugriff für Ihre AWS Lambda microVMs, indem Sie Ihrer microVM zur Laufzeit Network Connector-Ressourcen zuordnen. Netzwerkanschlüsse werden beim Aufrufen angegeben run-microvm und können nicht geändert werden, während eine MicroVM läuft.

-Übersicht

Jede MicroVM kann über unabhängige Netzwerkkonfigurationen für den Eingang (eingehend) und den Ausgang (ausgehend) verfügen:

  • Eingangsnetzwerkanschlüsse ermöglichen eingehende Konnektivität. Clients stellen eine Verbindung zu einem vom Service verwalteten HTTPS-Endpunkt her, und Lambda leitet den Datenverkehr an Ports weiter, die Sie in der MicroVM konfigurieren. Ingress-Connectors werden AWS verwaltet — Sie referenzieren sie per ARN, wenn Sie eine MicroVM ausführen.

  • Ausgehende Netzwerkanschlüsse ermöglichen ausgehenden Datenverkehr. Standardmäßig haben MicroVMs öffentlichen Internetzugang. Sie können stattdessen einen vom Kunden verwalteten VPC-Ausgangsconnector erstellen, um ausgehenden Datenverkehr über Ihre VPC weiterzuleiten.

Ein einziger Connector kann für viele MicroVMs wiederverwendet werden — dies ist das beabsichtigte Verwendungsmuster.

Eingehende Konnektivität

Jede Lambda MicroVM ist über eine eindeutige HTTPS-Endpunkt-URL erreichbar, die Ihnen bei einem Anruf zugewiesen wird. run-microvm Clients senden Anfragen über HTTPS an diesen Endpunkt. Lambda leitet jede Anfrage an einen Port in Ihrer MicroVM weiter, wo Ihre Anwendung sie empfängt.

Standardmäßig werden am Endpunkt empfangene Anfragen an Port 8080 innerhalb der MicroVM weitergeleitet. Informationen zur Weiterleitung an einen anderen Port finden Sie unter. Port-Routing

Die folgenden Protokolle werden auf dem Eingangsendpunkt unterstützt:

  • HTTP/1.1

  • HTTP/2

  • WebSockets

  • gRPC

  • Server-Sent Ereignisse (SSE)

Anmerkung

Der Datenverkehr zwischen Ihrem Client und dem MicroVM-Endpunkt wird immer mit TLS verschlüsselt. Ihre Anwendung kann Anfragen intern entweder über HTTP oder HTTPS bearbeiten.

Port-Routing

Lambda wählt den Zielport in Ihrer MicroVM in der folgenden Prioritätsreihenfolge aus:

  1. X-aws-proxy-portHeader — Fügen Sie bei Standard-HTTP-Anfragen diesen Header mit der Zielportnummer hinzu.

  2. WebSocket Unterprotokoll — Wenn Ihr WebSocket Client keine benutzerdefinierten Header einrichten kann, geben Sie den Zielport als Unterprotokoll mit dem Namen anlambda-microvms.port.N, wobei die Portnummer N steht. Sie geben Unterprotokolle an, wenn Sie die Verbindung öffnen. WebSocket Ein Beispiel finden Sie unter Protokolle.

  3. Standard (8080) — Wenn keines von beiden angegeben ist, wird die Route zu Port 8080 angefordert.

Wichtig

Der Zielport muss innerhalb des im allowedPorts Authentifizierungstoken definierten Ports liegen. Anfragen an nicht autorisierte Ports erhalten die Antwort 403 Forbidden.

Authentifizierung

Alle Anfragen an einen MicroVM-Endpunkt erfordern ein gültiges Authentifizierungstoken im X-aws-proxy-auth Header. Sie generieren Token mitcreate-microvm-auth-token. Jedes Token ist eine verschlüsselte JWE-Zeichenfolge (JSON Web Encryption) mit folgendem Gültigkeitsbereich:

  • Eine bestimmte MicroVM (identifiziert durch ID).

  • Eine Reihe zulässiger Ports (einzelner Port, Bereich oder alle Ports).

  • Eine Ablaufzeit (konfiguriert bei der Token-Erstellung).

Das folgende Beispiel erstellt ein Token und verwendet es, um eine authentifizierte Anfrage zu senden:

aws lambda-microvms create-microvm-auth-token \ --microvm-identifier microvm-id \ --expiration-in-minutes 30 \ --allowed-ports '[{"port":8080}]'
curl 'https://microvm-endpoint' \ -H 'X-aws-proxy-auth: TOKEN' \ -H 'X-aws-proxy-port: 8080'

Eine vollständige Anleitung zum Erstellen von Token und zum Herstellen einer Verbindung zu einer MicroVM, einschließlich WebSocket Verbindungen, finden Sie unter. Verbindung zu einer MicroVM herstellen

Fehlermeldungen

Die folgenden HTTP-Statuscodes werden vom MicroVM-Endpunkt zurückgegeben, wenn er eine Anfrage nicht verarbeiten oder an Ihre Anwendung senden kann. Diese Antworten kommen vom Endpunkt, nicht von Ihrer Anwendung.

Code Status Ursache und Lösung
400 Inkorrekte Anfrage Fehlerhafte Anfrage oder ein ungültiger Port-Header oder ein ungültiges WebSocket Unterprotokoll. Überprüfen Sie das Format.
403 Forbidden Fehlendes, abgelaufenes oder ungültiges Token oder der angeforderte Port ist nicht im Token enthaltenallowedPorts. Generieren Sie ein neues Token oder verwenden Sie einen zulässigen Port.
429 Zu viele Anfragen Das Ratenlimit wurde überschritten (auf Kontoebene oder pro microVM). Versuchen Sie es erneut mit exponentiellem Backoff.
500 Internal Server Error Es ist ein interner Fehler aufgetreten. Wiederholen Sie die Anforderung.
502 Bad Gateway Die Anwendung reagiert nicht oder die automatische Wiederaufnahme war innerhalb der maximalen Anzahl von Wiederholungsversuchen nicht erfolgreich. Siehe Auto-resume.

Anfordern von Headern

Der X-aws-proxy-* Header-Namespace wird von Lambda für Anforderungsmetadaten wie das Authentifizierungstoken (X-aws-proxy-auth) und den Zielport (X-aws-proxy-port) reserviert. Lambda entfernt X-aws-proxy-* Header, bevor die Anfrage an Ihre Anwendung weitergeleitet wird.

Request/response Bandbreite

Jede Lambda MicroVM hat eine request/response Bandbreite, die linear mit ihrer Größe skaliert. Diese Bandbreite gilt für den gesamten Datenverkehr über den MicroVM-Endpunkt, sowohl für eingehende Anfragen als auch für ausgehende Antworten.

Größe der MicroVM (Basiswert) Max. Bandbreite
0,5 GB, 0,25 vCPU 1 MB/s (8 Mbit/s)
1 GB, 0,5 vCPU 2 MB/s (16 Mbit/s)
2 GB, 1 vCPU 4 MB/s (32 Mbit/s)
4 GB, 2 vCPU 8 MB/s (64 Mbit/s)
8 GB, 4 vCPU 16 MB/s (128 Mbit/s)

Wenn Sie aufgrund der Netzwerksättigung eine erhöhte Latenz bei Anfragen feststellen, reduzieren Sie entweder die Parallelität Ihrer Anfragen oder die Größe der Nutzlast, oder wählen Sie eine größere MicroVM-Größe, um die verfügbare Bandbreite zu erhöhen.

HTTP/2 Unterstützung

Lambda MicroVMS unterstützt HTTP/2 am eingehenden Endpunkt. Lambda handelt das Protokoll während des TLS-Handshakes über ALPN (Application-Layer Protocol Negotiation) aus, wobei es bevorzugt HTTP/2 wird und darauf zurückgreift. HTTP/1.1 Ein HTTP/2-capable Client verwendet es automatisch.

So verwenden Sie es HTTP/2 zwischen dem Endpunkt und Ihrer Anwendung innerhalb der MicroVM:

  • Ihre Anwendung verwendet TLS — Lambda verhandelt HTTP/2 mit Ihrer Anwendung über ALPN und greift darauf zurück, HTTP/1.1 falls dies HTTP/2 nicht unterstützt wird.

  • Ihre Anwendung verwendet HTTP im Klartext-Format — Fügen Sie den X-aws-proxy-force-h2: true Header in Ihre Anfrage ein, der für die Verbindung zu Ihrer Anwendung verwendet HTTP/2 werden soll.

Ausgehende Konnektivität

Standardmäßig haben Lambda MicroVMs öffentlichen Internetzugang auf dem Ausgangspfad. Um MicroVMs mit Ressourcen in Ihren privaten VPCs — wie RDS ElastiCache, internen APIs und lokalen Systemen über Direct Connect oder VPN — zu verbinden, erstellen Sie einen Lambda Network Connector mit Ihrer VPC-Konfiguration.

Wenn Sie VPC-Egress verwenden, unterliegt ausgehender Datenverkehr Sicherheitsgruppenregeln und Netzwerk-ACLs, die den Verkehr in Ihrer VPC regeln.

Arbeiten mit ausgehenden Netzwerkverbindern

Ausgangsnetzwerkanschlüsse leiten ausgehenden Datenverkehr von Ihrer MicroVM über Ihre VPC weiter. Sie erstellen einmal einen Connector und verweisen dann per ARN darauf, wenn Sie MicroVMS über den run-microvm Befehl starten.

Voraussetzungen

Bevor Sie einen Netzwerkconnector erstellen, benötigen Sie eine IAM-Rolle, die es Lambda ermöglicht, Elastic Network Interfaces (ENIs) in Ihrer VPC zu erstellen. Die Rolle erfordert die folgenden Berechtigungen:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "CreateENI", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": [ "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ] }, { "Sid": "TagENI", "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:network-interface/*", "Condition": { "StringEquals": { "ec2:ManagedResourceOperator": "network-connectors.lambda.amazonaws.com" } } } ] }

Einen Netzwerkkonnektor erstellen

Erstellen Sie einen Connector, indem Sie Ihre VPC-Subnetze, Sicherheitsgruppen und Ihr Netzwerkprotokoll angeben (IPv4oderDualStack):

aws lambda-core create-network-connector \ --name my-connector \ --configuration '{ "VpcEgressConfiguration": { "SubnetIds": ["subnet-xxx"], "SecurityGroupIds": ["sg-xxx"], "NetworkProtocol": "IPv4", "AssociatedComputeResourceTypes": ["MicroVm"] } }' \ --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole

Status des Netzwerkkonnektors

Ein Connector muss sich im ACTIVE Status befinden, bevor Sie ihn referenzieren könnenrun-microvm.

Status Description
PENDING Der Connector wird erstellt (die zugrunde liegenden ENIs werden bereitgestellt).
ACTIVE Der Connector ist einsatzbereit.
INACTIVE Der Connector ist vorübergehend inaktiv.
FAILED Die Bereitstellung oder Aktualisierung ist fehlgeschlagen. Überprüfen Sie StateReason.
DELETING Der Connector wird gelöscht; ENIs werden bereinigt.
DELETE_FAILED Der Löschvorgang ist fehlgeschlagen.

Versionierung des Netzwerkkonnektors

Die Versionierung gilt für VPC-Ausgangsnetzwerkanschlüsse (Connectortyp). VPC_EGRESS Ein VPC-Ausgangsconnector ist versioniert: Bei jedem erfolgreichen update-network-connector Aufruf wird eine neue Version erstellt, und frühere Versionen bleiben verfügbar.

Wenn Sie eine MicroVM ausführen, verweisen Sie per ARN auf einen VPC-Ausgangsconnector. --egress-network-connectors Sie können eine der beiden Formen verwenden:

  • Unqualifizierter ARN — löst auf die neueste Version des Connectors auf. Eine MicroVM nimmt Konfigurationsänderungen automatisch auf. arn:aws:lambda:us-east-1:123456789012:network-connector:nc-id

  • Qualifizierter ARN — verbindet die MicroVM mit einer bestimmten Version. Verwenden Sie diese Option, um eine microVM zum Testen, zur Fehlerbehebung oder zum Rollback in einer bekannten Konfiguration zu speichern. arn:aws:lambda:us-east-1:123456789012:network-connector:nc-id:version-number

Eine MicroVM wird nur dann auf eine neue Version umgestellt, wenn Sie den ARN ändern, auf den sie verweist, sodass Sie neue Versionen nach Ihrem eigenen Zeitplan übernehmen können.

Beispiel für einen run-microvm Aufruf, der eine bestimmte Connector-Version anheftet:

aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \ --egress-network-connectors arn:aws:lambda:us-east-1:123456789012:network-connector:nc-id:version-number \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800,"autoResumeEnabled":false}'

Betrieb einer MicroVM mit einem Netzwerkanschluss

Verweisen Sie auf den Connector-ARN, wenn Sie eine MicroVM ausführen:

aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \ --egress-network-connectors connector-arn \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800,"autoResumeEnabled":false}'
Anmerkung

Bevor Sie einen Connector aktualisieren oder löschen, stellen Sie sicher, dass alle MicroVMs, die ihn verwenden, beendet wurden. Das Ändern eines Connectors, der aktiv verwendet wird, kann zu Netzwerkverbindungsproblemen beim Ausführen von MicroVMs führen.

Sie können private Konnektivität über das AWS Netzwerk zwischen Ihren VPC-Ressourcen und Lambda MicroVMs verwenden AWS PrivateLink , ohne das öffentliche Internet zu durchqueren. MicroVMS unterstützt je nach gewünschtem Verkehrsziel zwei VPC-Endpunkte:

  • MicroVM-Management-APIs (Images erstellen, ausführen, aussetzen, beenden) — verwendet den vorhandenen Lambda-VPC-Endpunkt (). com.amazonaws.region.lambda

  • Konnektivität zu MicroVMS (HTTPS-Verkehr zu Ihren laufenden Anwendungen) — verwendet einen separaten Endpunkt (). com.amazonaws.region.lambda-microvm

Lambda MicroVMS nutzt denselben VPC-Endpunktdienst wie Lambda (). com.amazonaws.region.lambda Vollständige Anweisungen finden Sie unter Erstellen eines Schnittstellenendpunkts für Lambda.

Um zu kontrollieren, wer Ihren Schnittstellenendpunkt verwenden kann und welche Lambda MicroVMS-API-Aktionen sie ausführen können, fügen Sie eine Endpunktrichtlinie hinzu. Die Richtlinie gibt den Prinzipal an, der Aktionen ausführen kann, die Aktionen, die er ausführen kann, und die Ressourcen, auf die er einwirken kann. Lambda MicroVMS-Aktionen verwenden das lambda: IAM-Aktionspräfix.

Weitere Informationen finden Sie unter Steuerung des Zugriffs auf Services mit VPC-Endpunkten im Amazon-VPC-Benutzerhandbuch.

Die folgende Beispielrichtlinie ermöglicht es dem Benutzer, MyUser MicroVM-Images aufzulisten und über den Endpunkt abzurufen:

{ "Statement": [ { "Principal": { "AWS": "arn:aws:iam::111122223333:user/MyUser" }, "Effect": "Allow", "Action": [ "lambda:ListMicrovmImages", "lambda:GetMicrovmImage" ], "Resource": "*" } ] }

Um den HTTPS-Verkehr zu Ihren laufenden MicroVMs privat zu halten, erstellen Sie einen Schnittstellenendpunkt für den Dienst. com.amazonaws.region.lambda-microvm Dieser Endpunkt verarbeitet Verbindungen zu MicroVM-Endpunkt-URLs (z. B.). abc123def456.lambda-microvm.us-east-1.on.aws

Weitere Informationen zu den Eigenschaften von Schnittstellenendpunkten finden Sie im Leitfaden zu Schnittstellenendpunkten in der Amazon VPC-Dokumentation.

So erstellen Sie einen Schnittstellen-Endpunkt für MicroVM-Konnektivität (Konsole)

  1. Öffnen Sie die Seite Endpunkte der Amazon-VPC-Konsole.

  2. Wählen Sie Endpunkt erstellen aus.

  3. Stellen Sie sicher, dass für Service-Kategorie die Option AWS -Services ausgewählt ist.

  4. Wählen Sie für Servicename com.amazonaws.region.lambda-microvm aus. Stellen Sie sicher, dass der Typ Schnittstelle ist.

  5. Auswählen von VPC und Subnetzen

  6. Um privates DNS für den Schnittstellenendpunkt zu aktivieren, aktivieren Sie das Kontrollkästchen DNS-Name aktivieren (empfohlen). Dadurch wird sichergestellt, dass Anfragen, die den Hostnamen des öffentlichen MicroVM-Endpunkts verwenden, automatisch zu Ihrem Schnittstellenendpunkt aufgelöst werden, ohne dass clientseitige Änderungen erforderlich sind.

  7. Wählen Sie unter Security group (Sicherheitsgruppe) eine oder mehrere Sicherheitsgruppen aus. Die Sicherheitsgruppe muss ausgehenden TCP-Verkehr über Port 443 zu den Endpunkt-Netzwerkschnittstellen zulassen.

  8. Wählen Sie Endpunkt erstellen aus.

Um die private DNS-Option zu verwenden, müssen Sie die enableDnsSupport Attribute enableDnsHostnames und für Ihre VPC festlegen. Weitere Informationen finden Sie unter Anzeigen und Aktualisieren der DNS-Unterstützung für Ihre VPC im Amazon-VPC-Benutzerhandbuch.

So erstellen Sie einen Schnittstellenendpunkt für MicroVM-Konnektivität (AWS CLI)

aws ec2 create-vpc-endpoint \ --vpc-id vpc-ec43eb89 \ --vpc-endpoint-type Interface \ --service-name com.amazonaws.us-east-1.lambda-microvm \ --subnet-id subnet-abababab \ --security-group-id sg-1a2b3c4d \ --private-dns-enabled

Gehen Sie wie folgt vor, um zu überprüfen, ob der Endpunkt verfügbar ist und ob privates DNS aktiv ist:

aws ec2 describe-vpc-endpoints \ --vpc-endpoint-ids vpce-1a2b3c4d5e6f7g8h9 \ --query 'VpcEndpoints[0].{State:State,PrivateDns:PrivateDnsEnabled,Dns:DnsEntries[*].DnsName}'

Wenn privates DNS aktiviert ist — Der Endpunkt verwaltet die DNS-Auflösung *.lambda-microvm.region.on.aws innerhalb Ihrer VPC. Ihre vorhandenen MicroVM-Endpunkt-Hostnamen werden (zum Beispielabc123def456.lambda-microvm.us-east-1.on.aws) in die privaten IP-Adressen der Endpunkt-Netzwerkschnittstellen aufgelöst. Es ist keine Änderung des Clients erforderlich.

Wenn privates DNS deaktiviert ist, generiert Amazon VPC einen endpunktspezifischen DNS-Namen für Ihren Endpunkt in der Form. vpce-id-hash.lambda-microvm.region.vpce.amazonaws.com Um den Datenverkehr über diesen Endpunkt weiterzuleiten und gleichzeitig die richtige MicroVM zu erreichen, müssen Sie den ursprünglichen MicroVM-Hostnamen an zwei Stellen beibehalten:

  • TLS Server Name Indication (SNI) — Der TLS-Handshake verwendet diesen Wert, um zu identifizieren, für welche MicroVM die Verbindung bestimmt ist.

  • HTTP-Host-Header — Der Proxy verwendet diesen Wert, um die Anfrage an die richtige MicroVM weiterzuleiten.

Wenn einer der Werte auf den VPC-Endpunkt-Hostnamen statt auf den MicroVM-Hostnamen gesetzt ist, kann die Verbindung nicht zur richtigen MicroVM weitergeleitet werden.

Beispiel: Connect über einen endpunktspezifischen DNS-Namen her

Im folgenden Beispiel wird curl mit dem --connect-to Flag verwendet, um die TCP-Verbindung zu Ihrem VPC-Endpunkt umzuleiten, wobei der MicroVM-Hostname in der URL, im SNI und im Host-Header beibehalten wird:

ENDPOINT_HOST=abc123def456.lambda-microvm.us-east-1.on.aws VPCE_HOST=vpce-0a1b2c3d4e5f67890-a1b2c3d4.lambda-microvm.us-east-1.vpce.amazonaws.com curl --connect-to "$ENDPOINT_HOST:443:$VPCE_HOST:443" \ -H "x-aws-proxy-auth: $MICROVM_AUTH_TOKEN" \ -H "x-aws-proxy-port: 8080" \ "https://$ENDPOINT_HOST/"

Das --connect-to Flag weist curl an, die TCP-Verbindung zur VPC-Endpunktadresse zu öffnen, während die URL, TLS SNI und der Host-Header auf Ihren MicroVM-Hostnamen eingestellt bleiben.

Weitere Informationen finden Sie unter Zugriff auf einen Service über einen Schnittstellenendpunkt im Benutzerhandbuch für Amazon VPC.

Sie können eine Endpunktrichtlinie anhängen, um zu steuern, welche MicroVMs über den lambda-microvm VPC-Endpunkt erreichbar sind. Mithilfe einer Endpunktrichtlinie für den lambda-microvm Service können Sie Verbindungen zu bestimmten Konten oder Organisationen festlegen. Standardmäßig erlaubt der Endpunkt Verbindungen zu MicroVMs in jedem AWS Konto. (Hinweis: Der Client, der die Verbindung herstellt, muss immer noch über ein gültiges MicroVM-Authentifizierungstoken verfügen, um Zugriff zu erhalten.)

Standardmäßig verfügt ein VPC-Endpunkt über eine Vollzugriffsrichtlinie, die den gesamten Datenverkehr zulässt. Wenn Sie die Standardrichtlinie durch eine benutzerdefinierte Richtlinie ersetzen, bewertet Lambda MicroVMS diese Richtlinie anhand der lambda:ConnectMicrovm Aktion bei jeder Verbindung, die über den Endpunkt hergestellt wird. Wenn die Richtlinie keine Verbindung zu MicroVMs zulässt, wird die Verbindung mit der Antwort HTTP 403 Forbidden abgelehnt. Eine Richtlinie, die keinen Zugriff gewährt, lambda:ConnectMicrovm verweigert alle Verbindungen über den Endpunkt.

Anmerkung

Die lambda:ConnectMicrovm Aktion autorisiert eine Verbindung zu einem MicroVM-Endpunkt über den Schnittstellenendpunkt. Es handelt sich nicht um einen Lambda-API-Vorgang und kann nicht in identitäts- oder ressourcenbasierten IAM-Richtlinien verwendet werden — er ist nur in einer VPC-Endpunktrichtlinie gültig.

Principal und Ressource

Verbindungen zu einem MicroVM-Endpunkt werden mit einem MicroVM-Authentifizierungstoken und nicht mit Signature Version 4 authentifiziert. AWS Aus diesem Grund ist der Verbindung kein IAM-Prinzipal zugeordnet. Stattdessen bewertet Lambda MicroVMS die Endpunktrichtlinie mit einem anonymen Prinzipal. Das bedeutet Folgendes:

  • Principal muss "*" sein. Eine Richtlinie, die einen bestimmten Prinzipal benennt, entspricht nichts und verweigert jede Verbindung.

  • Bedingungsschlüssel, die von der Identität des Anforderers abhängen (wie aws:PrincipalArnaws:PrincipalOrgID, undaws:userid), werden nicht ausgefüllt und stimmen nicht überein.

  • Resourcemuss es auch sein. "*" Lambda MicroVMS beschränkt die Bewertung von Endpunktrichtlinien nicht auf einzelne MicroVM-Ressourcen-ARNs. Um einzuschränken, welche MicroVMs der Endpunkt erreichen kann, verwenden Sie den Bedingungsschlüssel und nicht das aws:ResourceAccount Element. Resource

Unterstützte Bedingungsschlüssel

Bedingungsschlüssel Description
aws:ResourceAccount Das AWS Konto, dem die MicroVM gehört, mit der eine Verbindung hergestellt wird.
aws:ResourceOrgID Die AWS Organisations-ID des Kontos, dem die MicroVM gehört.
aws:SourceVpce Die ID des Schnittstellenendpunkts, über den die Verbindung geleitet wurde.
aws:SourceVpc Die ID der VPC, von der die Verbindung stammt.
aws:VpcSourceIp Die private IP-Adresse des Clients, der die Verbindung hergestellt hat.

Beispiel: Erlauben Sie nur Verbindungen zu MicroVMs in Ihrem eigenen Konto

Die folgende Endpunktrichtlinie erlaubt Verbindungen über den Endpunkt nur zu MicroVMs, die dem Konto 111122223333 gehören. Verbindungen zu MicroVMs, die einem anderen Konto gehören, werden verweigert.

{ "Statement": [ { "Principal": "*", "Effect": "Allow", "Action": "lambda:ConnectMicrovm", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" } } } ] }