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à:
-
X-aws-proxy-portheader — Per le richieste HTTP standard, includi questa intestazione con il numero di porta di destinazione. -
WebSocket subprotocol: se il WebSocket client non è in grado di impostare intestazioni personalizzate, specifica la porta di destinazione come sottoprotocollo denominato
lambda-microvms.port., dov'èNNil numero di porta. Fornisci dei sottoprotocolli quando apri la connessione. WebSocket Per vedere un esempio, consulta Protocolli. -
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-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'
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-connectorsconnector-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.