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](#microvms-networking-port-routing) 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-port`header** — Per le richieste HTTP standard, includi questa intestazione con il numero di porta di destinazione. 1. **WebSocket subprotocol**: se il WebSocket client non è in grado di impostare intestazioni personalizzate, specifica la porta di destinazione come sottoprotocollo denominato`lambda-microvms.port.{{N}}`, dov'è {{N}} il numero di porta. Fornisci dei sottoprotocolli quando apri la connessione. WebSocket Per vedere un esempio, consulta [Protocolli](microvms-launching.md#microvms-launching-websocket). 1. **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](microvms-launching.md#microvms-launching-connecting) ### 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](microvms-launching.md#microvms-launching-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: true`intestazione 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 riferimento`run-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.