View a markdown version of this page

Rete - AWS Lambda

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Rete

È possibile configurare l'accesso alla rete per le AWS Lambda microVM associando le risorse di Network Connector alla microVM in fase di esecuzione. I connettori di rete vengono specificati quando si chiama run-microvm e non possono essere modificati mentre una microVM è in esecuzione.

Panoramica di

Ogni microVM può avere configurazioni di rete in ingresso (in entrata) e in uscita (in uscita) indipendenti:

  • I connettori di rete in ingresso consentono la connettività in entrata. I client si connettono a un endpoint HTTPS gestito dal servizio e Lambda inoltra il traffico alle porte configurate all'interno della MicroVM. I connettori di ingresso sono AWS gestiti: vi si fa riferimento tramite ARN quando si esegue una microVM.

  • I connettori di rete in uscita abilitano il traffico in uscita. Per impostazione predefinita, le microVM dispongono di un accesso pubblico a Internet. Puoi invece creare un connettore di uscita VPC gestito dal cliente per indirizzare il traffico in uscita attraverso il tuo VPC.

Un singolo connettore può essere riutilizzato su più microVM: questo è il modello di utilizzo previsto.

Connettività in entrata

Ogni microVM Lambda è raggiungibile tramite un URL di endpoint HTTPS univoco, assegnato durante la chiamata. run-microvm I client inviano richieste a questo endpoint tramite HTTPS. Lambda indirizza ogni richiesta verso una porta all'interno della tua microVM, dove l'applicazione la riceve.

Per impostazione predefinita, le richieste ricevute sull'endpoint vengono indirizzate alla porta 8080 all'interno della microVM. Per effettuare il routing verso una porta diversa, vedi. Routing delle porte

I seguenti protocolli sono supportati sull'endpoint in entrata:

  • HTTP/1.1

  • HTTP/2

  • WebSockets

  • gRPC

  • Server-Sent Eventi (SSE)

Nota

Il traffico tra il client e l'endpoint MicroVM è sempre crittografato con TLS. L'applicazione può soddisfare internamente le richieste tramite HTTP o HTTPS.

Routing delle porte

Lambda seleziona la porta di destinazione all'interno della tua microVM utilizzando il seguente ordine di priorità:

  1. X-aws-proxy-portheader — Per le richieste HTTP standard, includi questa intestazione con il numero di porta di destinazione.

  2. WebSocket subprotocol: se il WebSocket client non è in grado di impostare intestazioni personalizzate, specifica la porta di destinazione come sottoprotocollo denominatolambda-microvms.port.N, dov'è N il numero di porta. Fornisci dei sottoprotocolli quando apri la connessione. WebSocket Per vedere un esempio, consulta Protocolli.

  3. Predefinito (8080): se non viene specificato nessuno dei due, le richieste vengono indirizzate alla porta 8080.

Importante

La porta di destinazione deve rientrare in quella allowedPorts definita nel token di autenticazione. Le richieste verso porte non autorizzate ricevono una risposta 403 Forbidden.

Autenticazione

Tutte le richieste a un endpoint MicroVM richiedono un token di autenticazione valido nell'intestazione. X-aws-proxy-auth I token vengono generati utilizzando. create-microvm-auth-token Ogni token è una stringa JWE (JSON Web Encryption) crittografata destinata a:

  • Una microVM specifica (identificata da un ID).

  • Un insieme di porte consentite (porta singola, intervallo o tutte le porte).

  • Un orario di scadenza (configurato al momento della creazione del token).

L'esempio seguente crea un token e lo utilizza per inviare una richiesta autenticata:

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'

Per una procedura dettagliata sulla creazione di token e sulla connessione a una microVM, comprese le connessioni, vedere. WebSocket Connessione a una microVM

Risposte agli errori

I seguenti codici di stato HTTP vengono restituiti dall'endpoint MicroVM quando non è in grado di elaborare o recapitare una richiesta all'applicazione. Queste risposte provengono dall'endpoint, non dall'applicazione.

Codice Stato Causa e risoluzione
400 Richiesta non valida Richiesta non valida o intestazione di porta o sottoprotocollo non valido. WebSocket Verifica il formato.
403 Accesso negato Token mancante, scaduto o non valido; oppure la porta richiesta non è inclusa nel token. allowedPorts Genera un nuovo token o usa una porta consentita.
429 Troppe richieste Limite di velocità superato (a livello di account o per microVM). Riprova con backoff esponenziale.
500 Errore interno del server Si è verificato un errore interno. Riprova la richiesta .
502 Gateway non valido L'applicazione non risponde o il ripristino automatico non è riuscito entro il numero massimo di tentativi. Per informazioni, consulta Auto-resume.

Intestazioni della richiesta

Lo spazio dei nomi dell'X-aws-proxy-*intestazione è riservato da Lambda ai metadati della richiesta, come il token di autenticazione () e la porta di destinazione (X-aws-proxy-auth). X-aws-proxy-port Lambda rimuove le X-aws-proxy-* intestazioni prima di inoltrare la richiesta all'applicazione.

Request/response larghezza di banda

Ogni microVM Lambda ha una request/response larghezza di banda scalabile linearmente in base alle sue dimensioni. Questa larghezza di banda si applica a tutto il traffico attraverso l'endpoint MicroVM, sia per le richieste in entrata che per le risposte in uscita.

Dimensione microVM (linea di base) Larghezza di banda massima
0,5 GB, 0,25 vCPU 1 MB/s (8 Mbps)
1 GB, 0,5 vCPU 2 MB/s (16 Mbps)
2 GB, 1 vCPU 4 MB/s (32 Mbps)
4 GB, 2 vCPU 8 MB/s (64 Mbps)
8 GB, 4 vCPU 16 MB/s (128 Mbps)

Se riscontri una maggiore latenza delle richieste a causa della saturazione della rete, riduci la concomitanza della richiesta o le dimensioni del payload oppure seleziona una dimensione microVM più grande per aumentare la larghezza di banda disponibile.

HTTP/2 supporto

Lambda MicroVMS supporta l'endpoint HTTP/2 in ingresso. Lambda negozia il protocollo tramite ALPN (Application-Layer Protocol Negotiation) durante l'handshake TLS, preferendo e ricorrendo a. HTTP/2 HTTP/1.1 Un client lo utilizza automaticamente. HTTP/2-capable

Da utilizzare HTTP/2 tra l'endpoint e l'applicazione all'interno della microVM:

  • La tua applicazione supporta TLS: Lambda HTTP/2 negozia con la tua applicazione tramite ALPN, ricorrendo HTTP/1.1 a HTTP/2 se non è supportato.

  • L'applicazione utilizza HTTP in chiaro: includi l'X-aws-proxy-force-h2: trueintestazione nella richiesta da utilizzare HTTP/2 nella connessione all'applicazione.

Connettività in uscita

Per impostazione predefinita, le microVM Lambda dispongono di accesso pubblico a Internet sul percorso di uscita. Per connettere le microVM alle risorse dei tuoi VPC privati, come RDS ElastiCache, API interne e sistemi locali tramite Direct Connect o VPN, crea un connettore di rete Lambda con la tua configurazione VPC.

Quando si utilizza l'uscita del VPC, il traffico in uscita è soggetto alle regole dei gruppi di sicurezza e agli ACL di rete che regolano il traffico nel VPC.

Utilizzo dei connettori di rete in uscita

I connettori di rete in uscita instradano il traffico in uscita dalla microVM attraverso il VPC. Si crea un connettore una volta, quindi si fa riferimento ad esso tramite ARN all'avvio di MicroVMS tramite il comando. run-microvm

Prerequisiti

Prima di creare un connettore di rete, è necessario un ruolo IAM che consenta a Lambda di creare interfacce di rete elastiche (ENI) nel tuo VPC. Il ruolo richiede le seguenti autorizzazioni:

{ "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" } } } ] }

Creazione di un connettore di rete

Crea un connettore specificando le sottoreti VPC, i gruppi di sicurezza e il protocollo di rete (oppure): IPv4 DualStack

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

Stati dei connettori di rete

Un connettore deve essere in ACTIVE uno stato prima di potervi fare riferimentorun-microvm.

Stato Description
PENDING Il connettore è in fase di creazione (è in corso il provisioning degli ENI sottostanti).
ACTIVE Il connettore è pronto per l'uso.
INACTIVE Il connettore è temporaneamente inattivo.
FAILED Il provisioning o l'aggiornamento non sono riusciti. Controlla StateReason.
DELETING Il connettore è in fase di eliminazione; gli ENI sono in corso di pulizia.
DELETE_FAILED Eliminazione non riuscita.

Esecuzione di una microVM con un connettore di rete

Fai riferimento all'ARN del connettore durante l'esecuzione di una microVM:

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}'
Nota

Prima di aggiornare o eliminare un connettore, assicurati che tutte le microVM che lo utilizzano siano terminate. La modifica di un connettore che è attivamente in uso può causare problemi di connettività di rete per l'esecuzione di MicroVMS.