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à.
# Le migliori pratiche per Lambda Web Functions
## Proteggi ogni endpoint
Ogni endpoint è raggiungibile da Internet, quindi il modo in cui autentichi i chiamanti, predisponi una porta d'ingresso e stabilisci le autorizzazioni determina chi può raggiungere l'applicazione e a cosa può accedere. Utilizza le seguenti pratiche:
+ Ogni endpoint è raggiungibile da Internet, indipendentemente dal tipo di autenticazione. Con`ApplicationManaged`, Lambda non autentica le richieste, quindi qualsiasi client che conosce il dominio può chiamare la tua applicazione. Implementa l'autenticazione, l'autorizzazione, la convalida degli input, il controllo delle dimensioni delle richieste e la protezione dagli abusi nell'applicazione o in una porta principale.
+ Da utilizzare `IamAuth` quando i chiamanti possono firmare le richieste e le policy IAM forniscono il modello di autorizzazione richiesto. Ambita le policy relative alle risorse in base agli ARN e ai principali degli endpoint specifici.
+ Metti Amazon CloudFront o Amazon API Gateway davanti a un endpoint quando hai bisogno di un dominio personalizzato, AWS WAF ispezione, caching o controlli edge centralizzati. Limita l'origine in modo che i clienti non possano aggirare la porta principale. Con CloudFront, utilizza un `IamAuth` endpoint and origin access control (OAC), come descritto in. [CloudFront integrazione](web-functions-endpoint-access-control.md#web-functions-endpoint-access-control-cloudfront) Con le altre porte frontali, l'endpoint rimane direttamente raggiungibile, quindi verifica un segreto o un token condiviso nell'applicazione.
+ Utilizza un ruolo di esecuzione dedicato con autorizzazioni con privilegi minimi. Separa l'identità di distribuzione, l'uploader del codice, il responsabile del servizio Lambda, il ruolo di esecuzione e le autorizzazioni del chiamante dell'endpoint.
+ Non inserire segreti nei pacchetti o nei log di distribuzione. Carica i segreti in fase di esecuzione da un archivio segreto appropriato, memorizzali nella cache solo per il tempo necessario e oscura i campi di richiesta riservati.
## Conserva gli artefatti di distribuzione immutabili
+ Abilita il controllo delle versioni nel bucket di codice e registra l'ID della versione dell'oggetto per ogni distribuzione.
+ Non sovrascrivete o eliminate le versioni degli oggetti utilizzate dalle revisioni attive o di rollback. Mantieni l'accesso principale al servizio Lambda per tutto il tempo in cui una revisione fa riferimento all'oggetto.
+ Crea pacchetti di distribuzione in una pipeline ripetibile. Installa le dipendenze di produzione da un file di blocco, escludi i file di sviluppo e testa l'archivio esatto prima del caricamento.
+ Crea dipendenze native per Arm64. Un modulo nativo creato per x86\_64 non viene eseguito nell'ambiente di esecuzione di Web Function.
+ Utilizza bucket, prefissi, ruoli o account separati quando gli ambienti hanno requisiti di fiducia o conservazione diversi.
## Progettazione per richieste simultanee
+ Mantieni i dati specifici della richiesta nell'ambito della richiesta. Non archiviate credenziali, dati dei clienti, oggetti di risposta o stati modificabili in base alla richiesta in variabili globali.
+ I/OUsa la modalità asincrona. Il funzionamento sincrono della CPU o del file system blocca il ciclo degli Node.js eventi e ritarda ogni richiesta in corso nell'ambiente.
+ Da utilizzare `worker_threads` per CPU-intensive lavori che prevedono l'utilizzo di più vCPU, oppure una versione `maxConcurrencyPerEnvironment` inferiore per ridurre i conflitti.
+ Tieni conto dell'Node.jsheap separatamente dalla memoria dell'ambiente. L'ambiente dispone di 2 GB, mentre l'heap V8 predefinito è di 1.024 MB. Se aumenti l'heap con `--max-old-space-size` in`NODE_OPTIONS`, lascia memoria per i buffer, i moduli nativi, il runtime e le richieste concorrenti.
+ Riutilizza i client e i pool di connessioni inizializzati tra le richieste, ma convalida le connessioni obsolete e la crescita della cache associata. Mantieni lo stato richiesto al di fuori dell'ambiente di esecuzione.
+ Mantieni attive le connessioni in uscita in modo che le richieste ai database e ad altre dipendenze le riutilizzino invece di aprire ogni volta una nuova connessione. Node.jsabilita keep-alive per impostazione predefinita nel suo agente HTTP globale. Se crei il tuo agente o configuri un client SDK, mantieni abilitato keep-alive. Gestisci anche le connessioni che il lato remoto chiude mentre sono inattive.
+ Usa nomi univoci per i file temporanei e rimuovili quando non sono più necessari. Più richieste condividono il `/tmp` file system da 512 MB dell'ambiente e i file possono persistere tra le richieste fino alla rimozione dell'ambiente.
## Mantieni prevedibile l'avvio
+ Avvia prontamente il server HTTP e ascolta il valore esatto di. `AWS_LAMBDA_HTTP_ENDPOINT`
+ Mantieni il pacchetto piccolo e rimuovi le dipendenze di produzione non utilizzate.
+ Inizializza solo le risorse necessarie prima che il server possa accettare il traffico. Esegui le operazioni opzionali senza fretta, ma evita che le richieste simultanee duplichino costose inizializzazioni.
+ Fate in modo che `SIGTERM` la pulizia finisca entro 1 secondo, ma non affidatevi ai callback di spegnimento per rendere persistenti i dati richiesti.
## Stabilisci i limiti del comportamento misurato
+ Test di carico con le stesse dipendenze delle applicazioni e gli stessi servizi downstream utilizzati nella produzione. Aumentate la concorrenza fino a quando la latenza, il consumo di CPU, la memoria o la capacità downstream diventino il vincolo vincolante.
+ Utilizzatelo `maxConcurrencyPerEnvironment` per vincolare la contesa per processo, `maxEnvironments` per la scala orizzontale vincolata e `rateLimit` per proteggere le dipendenze a valle dai picchi di richieste.
+ Verifica i limiti regionali e relativi all'account applicati prima dei test delle prestazioni e dei lanci. La configurazione degli endpoint non può creare capacità oltre il limite dell'account.
+ Riprova le risposte HTTP 429 e le risposte HTTP 503 senza intestazione. `lambda-web-error-type` Usa backoff e jitter e riprova solo quando l'operazione è idempotente. Utilizzate chiavi di idempotenza o la deduplicazione a livello di applicazione per le scritture.
## Implementa con verifica e rollback espliciti
+ Utilizza i pesi di revisione manuali per gli endpoint di produzione. Mantieni la distribuzione automatica delle versioni più recenti per ambienti di sviluppo in cui è accettabile l'implementazione immediata.
+ Attendi la nuova revisione `Active` e il completamento dell'aggiornamento dell'endpoint prima di valutarlo. Per tutti `MultiRegion` gli `PerRegion` endpoint, verifica lo stato dell'aggiornamento in ogni regione.
+ Utilizza i registri delle applicazioni o le metriche personalizzate che includono l'identificatore di revisione durante le implementazioni di Canary. Service-vended le metriche non includono una dimensione di revisione.
+ Prima di spostare il traffico, definisci le metriche che una nuova revisione deve soddisfare e per quanto tempo le osservi (criteri di cottura) e le soglie che attivano un rollback. Conserva la versione dell'oggetto di codice, l'accesso tramite chiave e la configurazione della revisione precedente fino al termine della finestra di rollback. Lambda elimina automaticamente le revisioni più vecchie a cui nessun endpoint indirizza quando una funzione Web supera il limite di revisione, quindi mantieni la revisione di rollback su un endpoint (ad esempio, un endpoint di test) o preparati a ricrearla dalla stessa versione dell'oggetto. Per informazioni dettagliate, vedi [Limiti di revisione e pulizia automatica](web-functions-revisions.md#web-functions-revisions-limits).
## Crea una linea di base operativa
+ Emetti log strutturati delle applicazioni con ID di richiesta, ID di revisione, percorso, codice di stato, durata e identificatori necessari per diagnosticare gli errori a valle. Non registrate credenziali, token o corpi di richiesta sensibili.
+ Allarme in caso di 5xx risposte e accelerazioni e monitora le richieste eseguite, gli ambienti attivi e la capacità dell'account. Configura metriche di errore sparse per trattare i dati mancanti in modo appropriato.
+ Utilizza l'ID della richiesta di risposta e le intestazioni del flusso di registro per correlare gli errori dei client ai log. Abilita i log di sistema DEBUG solo quando sono necessari gli eventi aggiuntivi.
+ Registra le operazioni di gestione e gli eventi relativi ai dati di chiamata degli endpoint AWS CloudTrail quando i requisiti di audit li richiedono.
## Operate MultiRegion e gestite gli PerRegion endpoint come sistemi distribuiti
+ Rendi disponibili i dati delle applicazioni, i segreti, le chiavi e le dipendenze downstream in ogni regione in grado di ricevere traffico.
+ Verifica gli errori di distribuzione parziali e gli errori relativi alle dipendenze regionali. Non date per scontato che tutte le regioni eseguano la stessa revisione finché ogni aggiornamento regionale non riporta un esito positivo.
+ Dopo ogni aggiornamento dell'endpoint, controlla `updateStatus` ogni voce inserita. `regionalEndpoints` La replica può fallire in alcune regioni mentre ha esito positivo in altre. Di conseguenza, un aggiornamento può essere applicato parzialmente. Riprova o ripristina prima di considerare la distribuzione completa.
+ Per gli `PerRegion` endpoint, verifica il DNS esterno o il failover front-door indipendentemente dall'implementazione di Web Function.
+ Centralizza le visualizzazioni operative nella regione di origine, ma mantieni un percorso di ripristino per ritardi o interruzioni della telemetria.