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. Netzwerkkonnektoren werden beim Aufrufen angegeben run-microvm und können nicht geändert werden, während eine MicroVM läuft.
-Übersicht
Jede MicroVM kann unabhängige Netzwerkkonfigurationen für Eingangs- (eingehend) und ausgehende (ausgehende) Netzwerkkonfigurationen haben:
-
Netzwerkeingangsanschlüsse ermöglichen eingehende Konnektivität. Clients stellen eine Verbindung zu einem vom Dienst verwalteten HTTPS-Endpunkt her, und Lambda leitet den Datenverkehr an Ports weiter, die Sie innerhalb der MicroVM konfigurieren. Ingress-Connectors werden AWS verwaltet — Sie referenzieren sie per ARN, wenn Sie eine MicroVM ausführen.
-
Netzwerkkonnektoren für ausgehenden Datenverkehr ermöglichen ausgehenden Datenverkehr. Standardmäßig haben MicroVMs einen öffentlichen Internetzugang. Sie können einen vom Kunden verwalteten VPC-Ausgangsconnector erstellen, um den ausgehenden Datenverkehr stattdessen über Ihre VPC zu leiten.
Ein einzelner Connector kann auf vielen microVMs wiederverwendet werden — dies ist das beabsichtigte Nutzungsmuster.
Eingehende Konnektivität
Jede Lambda-MicroVM ist über eine eindeutige HTTPS-Endpunkt-URL erreichbar, die beim Aufruf 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 eingegangene 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 eingehenden Endpunkt unterstützt:
-
HTTP/1.1
-
HTTP/2
-
WebSockets
-
gRPC
-
Server-Sent Ereignisse (SSE)
Anmerkung
Der Datenverkehr zwischen Ihrem Client und dem MicroVM-Endpunkt ist 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:
-
X-aws-proxy-portHeader — Fügen Sie bei Standard-HTTP-Anfragen diesen Header der Zielportnummer hinzu. -
WebSocket Unterprotokoll — Wenn Ihr WebSocket Client keine benutzerdefinierten Header festlegen kann, geben Sie den Zielport als Unterprotokoll mit dem Namen an
lambda-microvms.port., wobei sich die PortnummerNNbefindet. Sie stellen Unterprotokolle bereit, wenn Sie die Verbindung öffnen. WebSocket Ein Beispiel finden Sie unter Protokolle. -
Standard (8080) — Wenn keines angegeben ist, werden Anfragen an Port 8080 weitergeleitet.
Wichtig
Der Zielport muss innerhalb des im allowedPorts Authentifizierungstoken definierten Ports liegen. Anfragen an nicht autorisierte Ports erhalten die Antwort 403 Forbidden.
Authentifizierung
Für alle Anfragen an einen MicroVM-Endpunkt ist ein gültiges Authentifizierungstoken im X-aws-proxy-auth Header erforderlich. 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 (bei der Token-Erstellung konfiguriert).
Das folgende Beispiel erstellt ein Token und verwendet es, um eine authentifizierte Anfrage zu senden:
aws lambda-microvms create-microvm-auth-token \ --microvm-identifiermicrovm-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 keine Anfrage an Ihre Anwendung verarbeiten oder übermitteln kann. Diese Antworten kommen vom Endpunkt, nicht von Ihrer Anwendung.
| Code | Status | Ursache und Lösung |
|---|---|---|
| 400 | Inkorrekte Anfrage | Falsch formatierte 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 gehört nicht zum TokenallowedPorts. Generieren Sie ein neues Token oder verwenden Sie einen zulässigen Port. |
| 429 | Zu viele Anfragen | Das Ratenlimit wurde überschritten (auf Kontoebene oder pro Mikro-VM). 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 ist von Lambda für Anforderungsmetadaten wie das Authentifizierungstoken (X-aws-proxy-auth) und den Zielport () reserviert. X-aws-proxy-port 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 wird. Diese Bandbreite gilt für den gesamten Datenverkehr über den MicroVM-Endpunkt, sowohl für eingehende Anfragen als auch für ausgehende Antworten.
| MicroVM-Größe (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 Anforderungslatenz feststellen, reduzieren Sie entweder die Parallelität Ihrer Anfragen oder die Nutzlastgröße oder wählen Sie eine größere microVM-Größe, um die verfügbare Bandbreite zu erhöhen.
HTTP/2 unterstützung
Lambda MicroVMS wird HTTP/2 auf dem eingehenden Endpunkt unterstützt. Lambda handelt das Protokoll während des TLS-Handshakes über ALPN (Application-Layer Protocol Negotiation) aus, bevorzugt und greift darauf zurück. HTTP/2 HTTP/1.1 Ein HTTP/2-capable Client verwendet es automatisch.
Zur Verwendung HTTP/2 zwischen dem Endpunkt und Ihrer Anwendung in der MicroVM:
-
Ihre Anwendung bedient TLS — Lambda verhandelt HTTP/2 mit Ihrer Anwendung über ALPN und greift auf solche zurück, die nicht unterstützt werden HTTP/1.1 . HTTP/2
-
Ihre Anwendung liefert Klartext-HTTP — Fügen Sie den
X-aws-proxy-force-h2: trueHeader in Ihre Anfrage ein, um ihn für die Verbindung zu Ihrer Anwendung HTTP/2 zu verwenden.
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 ausgehenden VPC-Datenverkehr verwenden, unterliegt der ausgehende Datenverkehr Sicherheitsgruppenregeln und Netzwerk-ACLs, die den Verkehr in Ihrer VPC regeln.
Arbeiten mit Netzwerkanschlüssen für ausgehenden Datenverkehr
Netzwerkkonnektoren für ausgehenden Datenverkehr leiten den ausgehenden Datenverkehr von Ihrer MicroVM durch Ihre VPC weiter. Sie erstellen einen Connector einmal und verweisen dann per ARN darauf, wenn Sie MicroVMs über den Befehl starten. run-microvm
Voraussetzungen
Bevor Sie einen Netzwerkconnector erstellen, benötigen Sie eine IAM-Rolle, die es Lambda ermöglicht, elastische Netzwerkschnittstellen (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 das Netzwerkprotokoll (IPv4oderDualStack) angeben:
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 im ACTIVE Status sein, 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 |
Das Löschen ist fehlgeschlagen. |
Ausführen einer MicroVM mit einem Netzwerkanschluss
Verweisen Sie beim Ausführen einer MicroVM auf den Connector-ARN:
aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \ --egress-network-connectorsconnector-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 Problemen mit der Netzwerkkonnektivität beim Ausführen von MicroVMs führen.
Verwendung von Lambda MicroVMs mit Schnittstellen-VPC-Endpunkten (AWS PrivateLink)
Sie können es AWS PrivateLink für private Konnektivität über das AWS Netzwerk zwischen Ihren VPC-Ressourcen und Lambda-MicroVMs verwenden, ohne das öffentliche Internet nutzen zu müssen. 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
VPC-Endpunkt für MicroVM-Verwaltungs-APIs
Lambda MicroVMS nutzt denselben VPC-Endpunktdienst wie Lambda (). com.amazonaws. Vollständige Anweisungen finden Sie unter Erstellen eines Schnittstellenendpunkts für Lambda. region.lambda
Endpunktrichtlinie für MicroVM-Management-APIs
Um zu steuern, wer Ihren Schnittstellenendpunkt verwenden kann und welche Lambda MicroVMS-API-Aktionen sie ausführen können, fügen Sie eine Endpunktrichtlinie hinzu. Die Richtlinie spezifiziert den Prinzipal, der Aktionen ausführen kann, die Aktionen, die er ausführen kann, und die Ressourcen, auf die er reagieren 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 Benutzern, MicroVM-Images über den Endpunkt MyUser aufzulisten und abzurufen:
{ "Statement": [ { "Principal": { "AWS": "arn:aws:iam::111122223333:user/MyUser" }, "Effect": "Allow", "Action": [ "lambda:ListMicrovmImages", "lambda:GetMicrovmImage" ], "Resource": "*" } ] }
VPC-Endpunkt für MicroVM-Konnektivität
Um den HTTPS-Verkehr zu Ihren laufenden MicroVMs privat zu halten, erstellen Sie einen Schnittstellenendpunkt für den Dienst. com.amazonaws. Dieser Endpunkt verarbeitet Verbindungen zu MicroVM-Endpunkt-URLs (z. B.). region.lambda-microvmabc123def456.lambda-microvm.us-east-1.on.aws
Weitere Informationen zu den Eigenschaften von Schnittstellenendpunkten finden Sie im Leitfaden für Schnittstellenendpunkte in der Amazon VPC-Dokumentation.
Erstellen des Endpunkts
So erstellen Sie einen Schnittstellenendpunkt für MicroVM-Konnektivität (Konsole)
-
Öffnen Sie die Seite Endpunkte
der Amazon-VPC-Konsole. -
Wählen Sie Endpunkt erstellen aus.
-
Stellen Sie sicher, dass für Service-Kategorie die Option AWS -Services ausgewählt ist.
-
Wählen Sie für Servicename
com.amazonaws.aus. Stellen Sie sicher, dass der Typ Schnittstelle ist.region.lambda-microvm -
Auswählen von VPC und Subnetzen
-
Um privates DNS für den Schnittstellenendpunkt zu aktivieren, aktivieren Sie das Kontrollkästchen DNS-Namen aktivieren (empfohlen). Dadurch wird sichergestellt, dass Anfragen, die den öffentlichen MicroVM-Endpunkt-Hostnamen verwenden, automatisch an Ihren Schnittstellenendpunkt weitergeleitet werden, ohne dass clientseitige Änderungen erforderlich sind.
-
Wählen Sie unter Security group (Sicherheitsgruppe) eine oder mehrere Sicherheitsgruppen aus. Die Sicherheitsgruppe muss ausgehenden TCP-Verkehr auf Port 443 zu den Netzwerkschnittstellen des Endpunkts zulassen.
-
Wählen Sie Endpunkt erstellen aus.
Um die private DNS-Option verwenden zu können, müssen Sie die enableDnsSupport Attribute enableDnsHostnames und Ihrer VPC festlegen. Weitere Informationen finden Sie unter Anzeigen und Aktualisieren der DNS-Unterstützung für Ihre VPC im Amazon-VPC-Benutzerhandbuch.
Um einen Schnittstellenendpunkt für MicroVM-Konnektivität (AWS CLI) zu erstellen
aws ec2 create-vpc-endpoint \ --vpc-idvpc-ec43eb89\ --vpc-endpoint-type Interface \ --service-name com.amazonaws.us-east-1.lambda-microvm \ --subnet-idsubnet-abababab\ --security-group-idsg-1a2b3c4d\ --private-dns-enabled
Gehen Sie wie folgt vor, um zu überprüfen, ob der Endpunkt verfügbar ist und ob das private DNS aktiv ist:
aws ec2 describe-vpc-endpoints \ --vpc-endpoint-idsvpce-1a2b3c4d5e6f7g8h9\ --query 'VpcEndpoints[0].{State:State,PrivateDns:PrivateDnsEnabled,Dns:DnsEntries[*].DnsName}'
Verhalten von privatem DNS
Wenn privates DNS aktiviert ist — Der Endpunkt verwaltet die DNS-Auflösung *.lambda-microvm. innerhalb Ihrer VPC. Ihre vorhandenen MicroVM-Endpunkt-Hostnamen (zum Beispielregion.on.awsabc123def456.lambda-microvm.us-east-1.on.aws) werden in die privaten IP-Adressen der Endpunkt-Netzwerkschnittstellen aufgelöst. Es ist keine Änderung des Clients erforderlich.
Wenn privates DNS deaktiviert ist — Amazon VPC generiert im Formular einen endpunktspezifischen DNS-Namen für Ihren Endpunkt. Um den Datenverkehr über diesen Endpunkt zu leiten und trotzdem die richtige MicroVM zu erreichen, müssen Sie den ursprünglichen MicroVM-Hostnamen an zwei Stellen beibehalten:vpce-id-hash.lambda-microvm.region.vpce.amazonaws.com
-
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 Hostnamen des VPC-Endpunkts statt auf den MicroVM-Hostnamen gesetzt ist, kann die Verbindung nicht an die richtige MicroVM weitergeleitet werden.
Beispiel: Stellen Sie eine Verbindung über einen endpunktspezifischen DNS-Namen her
Das folgende Beispiel verwendet curl --connect-to Flag, um die TCP-Verbindung zu Ihrem VPC-Endpunkt umzuleiten, während 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, der TLS-SNI und der Host-Header auf Ihren MicroVM-Hostnamen gesetzt bleiben.
Weitere Informationen finden Sie unter Zugriff auf einen Service über einen Schnittstellenendpunkt im Benutzerhandbuch für Amazon VPC.
Endpunktrichtlinie für MicroVM-Konnektivität
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 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 HTTP-Antwort 403 Forbidden abgelehnt. Eine Richtlinie, die das nicht 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.
Prinzipal 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 wertet Lambda MicroVMS die Endpunktrichtlinie mit einem anonymen Prinzipal aus. Das bedeutet Folgendes:
-
Principalmuss"*"sein. Eine Richtlinie, die einen bestimmten Prinzipal benennt, stimmt mit nichts überein 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 auch sein."*"Lambda MicroVMS beschränkt die Bewertung der Endpunktrichtlinien nicht auf einzelne MicroVM-Ressourcen-ARNs. Um einzuschränken, welche MicroVMs der Endpunkt erreichen kann, verwenden Sie den Bedingungsschlüssel und nicht dasaws:ResourceAccountElement.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" } } } ] }