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à.
# Istanze Lambda gestite
Lambda Managed Instances ti consente di eseguire funzioni Lambda sulle istanze Amazon EC2 di attuale generazione, tra cui Graviton4, istanze ottimizzate per la rete e altre opzioni di elaborazione specializzate, senza dover gestire i cicli di vita delle istanze, le patch di runtime del sistema operativo e del linguaggio, il routing, il bilanciamento del carico o le politiche di scalabilità. Con Lambda Managed Instances, puoi beneficiare dei vantaggi tariffari di EC2, tra cui EC2 Savings Plans e Reserved Instances.
Per un elenco dei tipi di istanze supportati, vai alla pagina [AWS Lambda dei prezzi](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) e seleziona la tua. Regione AWS
## Funzionalità chiave
Lambda Managed Instances offre le seguenti funzionalità:
+ **Scegli le istanze adatte**: seleziona le [istanze appropriate](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) in base ai requisiti di prestazioni e costi, incluso l'accesso alle ultime novità CPUs come Graviton4, rapporti memoria-CPU configurabili e reti a larghezza di banda elevata.
+ **Provisioning automatico: effettua automaticamente il provisioning** delle istanze adatte e attiva gli ambienti di esecuzione delle funzioni. AWS
+ **Scalabilità dinamica: le** istanze si ridimensionano dinamicamente in base ai modelli di traffico funzionale.
+ **Esperienza completamente gestita**: AWS gestisce la gestione dell'infrastruttura, il ridimensionamento, l'applicazione di patch e il routing, con le stesse ampie integrazioni event-source che conosci.
## Quando usare le istanze gestite Lambda
Prendi in considerazione le istanze gestite Lambda per i seguenti casi d'uso:
+ Carichi di **lavoro prevedibili in base ai volumi elevati: ideali per carichi di lavoro stazionari** senza picchi di traffico imprevisti. Le istanze gestite Lambda sono scalabili per gestire il raddoppio del traffico entro cinque minuti per impostazione predefinita.
+ **Applicazioni critiche per le prestazioni: accesso ai più recenti e diversi rapporti memoria-CPU** e un CPUs throughput di rete elevato
+ **Requisiti normativi**: esigenze di governance granulare con controllo sul VPC e sul posizionamento delle istanze
+ **Varietà di applicazioni**: migrazione di applicazioni basate sugli eventi, media/data elaborazione, applicazioni Web e carichi di lavoro legacy alla modalità serverless
## Come funziona
Lambda Managed Instances utilizza i provider di capacità come base per l'esecuzione delle tue funzioni:
1. **Crea un provider di capacità**: definisci dove vengono eseguite le tue funzioni specificando la configurazione del VPC e, facoltativamente, i requisiti dell'istanza e la configurazione di scalabilità
1. **Crea la tua funzione**: crea le funzioni Lambda come al solito e collegale a un provider di capacità
1. **Pubblica una versione della funzione**: le versioni delle funzioni diventano attive sulle istanze del provider di capacità una volta pubblicate
Quando pubblichi una versione della funzione con un provider di capacità, Lambda avvia Managed Instances nel tuo account. Per impostazione predefinita, avvia tre istanze per la resilienza AZ e avvia tre ambienti di esecuzione prima di contrassegnare la versione della funzione come ATTIVA. Se colleghi una funzione a un provider di capacità esistente che esegue già altre funzioni, Lambda potrebbe non generare nuove istanze se le istanze disponibili hanno già la capacità di adattarsi agli ambienti di esecuzione della nuova funzione.
## Modello di concorrenza
Le istanze gestite Lambda supportano le chiamate simultanee, in cui un ambiente di esecuzione può gestire più chiamate contemporaneamente. Ciò differisce dal tipo di calcolo Lambda (predefinito), che fornisce un unico modello di concorrenza in cui un ambiente di esecuzione può eseguire al massimo una chiamata alla volta. La multi-concorrenza consente un migliore utilizzo delle istanze EC2 sottostanti ed è particolarmente utile per le applicazioni che richiedono un elevato livello di I/O come i servizi Web o i lavori in batch. Questa modifica del modello di esecuzione significa che la sicurezza dei thread, la gestione dello stato e l'isolamento del contesto devono essere gestiti in modo diverso a seconda del runtime.
## Locazione e isolamento
Il tipo di elaborazione Lambda (predefinito) è multi-tenant e utilizza la tecnologia Firecracker MicroVM per fornire isolamento tra gli ambienti di esecuzione in esecuzione su flotte Lambda condivise. Le istanze gestite Lambda vengono eseguite nel tuo account e forniscono l'hardware EC2 e le opzioni di prezzo più recenti. Le istanze gestite utilizzano contenitori in esecuzione su istanze EC2 Nitro per fornire isolamento anziché Firecracker. I provider di capacità fungono da limite di sicurezza per le funzioni Lambda. Le funzioni vengono eseguite in contenitori all'interno delle istanze.
### Comprensione delle istanze gestite
Le funzioni Lambda Managed Instances vengono eseguite sulle istanze gestite EC2 del tuo account. Queste istanze sono gestite completamente da Lambda, il che significa che hai autorizzazioni limitate su di esse rispetto alle istanze EC2 standard. Puoi identificare le istanze gestite Lambda nel tuo account tramite:
+ La presenza del `Operator` campo nell'output EC2 `DescribeInstances`
+ Il `aws:lambda:capacity-provider` tag sull'istanza
Non è possibile eseguire operazioni EC2 standard direttamente su queste istanze, ad esempio interromperle manualmente. Per distruggere le istanze gestite, elimina il provider di capacità associato. Lambda interromperà quindi le istanze come parte del processo di eliminazione del provider di capacità.
## Prezzi
Lambda Managed Instances utilizza prezzi basati su EC2 con una commissione di gestione del 15% in aggiunta al costo delle istanze EC2. Questo modello di prezzo supporta EC2 Savings Plans, Reserved Instances e qualsiasi altro sconto sui prezzi applicato all'utilizzo di EC2. [Per ulteriori dettagli, consulta la pagina dei prezzi: prezzi/ https://aws.amazon.com/lambda/](https://aws.amazon.com/lambda/pricing/)
**Importante:** gli sconti sui prezzi di EC2 si applicano solo al calcolo EC2 sottostante, non alla commissione di gestione.
## In che modo le istanze gestite Lambda differiscono dal tipo di calcolo Lambda (predefinito)
Lambda Managed Instances modifica il modo in cui Lambda elabora le richieste rispetto a Lambda (impostazione predefinita).
**Principali differenze:**
| | Lambda (impostazione predefinita) | Istanze Lambda gestite |
| --- | --- | --- |
| Modello di concorrenza | Modello di concorrenza singolo in cui un ambiente di esecuzione può supportare al massimo una chiamata alla volta | Richiamazioni simultanee in cui un unico ambiente di esecuzione è in grado di gestire più chiamate contemporaneamente, aumentando la produttività soprattutto per le applicazioni che richiedono un elevato livello di I/O |
| Locazione e isolamento | Multi-tenant, che utilizza la tecnologia Firecracker MicroVM per fornire isolamento tra gli ambienti di esecuzione in esecuzione su flotte Lambda condivise | Esegui nel tuo account, utilizzando EC2 Nitro per fornire isolamento. I provider di capacità fungono da limite di sicurezza, con funzioni eseguite in contenitori all'interno delle istanze |
| Modello tariffario | Prezzi relativi alla durata della richiesta | Prezzi basati sulle istanze con modelli di prezzo EC2, tra cui istanze on demand e riservate, e opzioni di risparmio come Compute Savings Plans |
| Comportamento del dimensionamento | Scalabilità quando non esiste un ambiente di esecuzione libero per gestire una chiamata in entrata (avvio a freddo). Scalabilità fino a zero senza traffico | Scalabilità asincrona in base solo all'utilizzo delle risorse della CPU, senza avviamenti a freddo. Scalabilità fino ad ambienti di esecuzione minimi configurati senza traffico |
| Ideale per | Funzioni con traffico intenso in grado di gestire alcuni orari di avvio a freddo o applicazioni senza carico sostenuto che traggono vantaggio dalla scalabilità a zero | Funzioni di traffico prevedibile ad alto volume quando desideri la flessibilità, i piani tariffari e le opzioni hardware di EC2 |
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ Comprendi [la sicurezza e le autorizzazioni per le istanze gestite Lambda](lambda-managed-instances-security.md)
# Guida introduttiva alle istanze gestite Lambda
## Creazione di una funzione Lambda Managed Instance (console)
Puoi utilizzare la console Lambda per creare una funzione di istanza gestita che viene eseguita su EC2 istanze Amazon gestite da un provider di capacità.
**Importante:** prima di creare una funzione di istanza gestita, devi prima creare un provider di capacità. Queste funzioni richiedono che un provider di capacità definisca l' EC2 infrastruttura Amazon che eseguirà le tue funzioni.
**Per creare una funzione Lambda Managed Instance (console)**
1. Apri la console Lambda.
1. Scegli **Capacity providers** dal riquadro di navigazione a sinistra.
1. Scegli **Crea fornitore di capacità**.
1. Nella sezione **Impostazioni del fornitore di capacità**, inserisci un nome per il tuo fornitore di capacità.
1. Seleziona VPC e autorizzazioni per il tuo provider di capacità. Puoi usarne uno esistente o crearne uno nuovo. Per informazioni sulla creazione del ruolo operatore richiesto, consulta Ruolo operatore [Lambda per istanze gestite Lambda](lambda-managed-instances-operator-role.md).
1. Espandere **Advanced settings (Impostazioni avanzate)**.
1. Definisci i **requisiti dell'istanza** scegliendo l'architettura del processore e i tipi di istanza.
1. In **Auto scaling**, specifica il numero massimo di EC2 v CPUs per il tuo provider di capacità. Puoi anche scegliere la **modalità di ridimensionamento manuale dell'istanza** per impostare il tuo valore di ridimensionamento per un controllo preciso.
1. Scegli **Create Capacity Provider** per crearne uno nuovo.
1. Quindi, scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. Nel riquadro **Informazioni di base**, fornisci un **nome per la funzione**.
1. Per **Runtime**, scegli uno dei Runtime supportati.
1. Scegliete l'**architettura** per la vostra funzione (la stessa che avete selezionato per il provider di capacità). Per impostazione predefinita, **x86\$164**.
1. **In **Autorizzazioni**, assicurati di disporre dell'autorizzazione per il ruolo di esecuzione scelto.** Altrimenti, puoi creare un nuovo ruolo.
1. In **Configurazioni aggiuntive**, scegli il **tipo di elaborazione** come Istanze gestite **Lambda**.
1. L'ARN del fornitore di capacità creato nei passaggi precedenti deve essere preselezionato.
1. Scegli **la dimensione della memoria** e la **memoria dell'ambiente di esecuzione (GiB) per rapporto vCPU**.
1. Scegli **Crea funzione**.
La funzione Lambda Managed Instance viene creata e fornirà capacità al provider di capacità specificato. La creazione della funzione richiede in genere diversi minuti. Una volta completata, è possibile modificare il codice della funzione ed eseguire il primo test.
## Creazione di una funzione Lambda Managed Instance (CLI AWS )
### Prerequisiti
Prima di iniziare, assicurati di disporre di:
+ **AWS CLI**: installa e configura la CLI AWS . Per ulteriori informazioni, consulta [Installazione o aggiornamento della versione più recente della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ **Autorizzazioni IAM**: il tuo utente o ruolo IAM deve disporre delle autorizzazioni per creare funzioni Lambda, fornitori di capacità e passare ruoli IAM. Tieni presente che ti servirà anche `iam:CreateServiceLinkedRole` se è la prima volta che crei un provider di capacità nell'account o se il Service Linked Role (SLR) è stato eliminato.
### Fase 1: Creare i ruoli IAM richiesti
Le istanze gestite Lambda richiedono due ruoli IAM: un ruolo di esecuzione per la funzione e un ruolo di operatore per il provider di capacità. Il ruolo di operatore consente a Lambda di avviare, terminare e monitorare le EC2 istanze Amazon per tuo conto. Il ruolo di esecuzione della funzione concede alla funzione le autorizzazioni per accedere ad altri servizi e risorse. AWS
**Per creare il ruolo di esecuzione Lambda**
1. Crea un documento sulla politica di fiducia che consenta a Lambda di assumere il ruolo:
```
cat > lambda-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Crea il ruolo di esecuzione:
```
aws iam create-role \
--role-name MyLambdaExecutionRole \
--assume-role-policy-document file://lambda-trust-policy.json
```
1. Allega la politica di esecuzione di base:
```
aws iam attach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
**Per creare il ruolo di gestore di capacità**
1. Crea un documento sulla politica di fiducia che consenta a Lambda di assumere il ruolo di operatore:
```
cat > operator-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Crea il ruolo dell'operatore:
```
aws iam create-role \
--role-name MyCapacityProviderOperatorRole \
--assume-role-policy-document file://operator-trust-policy.json
```
1. Allega la politica di EC2 autorizzazioni richiesta:
```
aws iam attach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
```
### Fase 2: Configurazione delle risorse VPC
Le istanze gestite Lambda vengono eseguite nel tuo VPC e richiedono una sottorete e un gruppo di sicurezza.
**Per creare risorse VPC**
1. Crea un VPC:
```
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query 'Vpc.VpcId' \
--output text)
```
1. Crea una sottorete:
```
SUBNET_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--query 'Subnet.SubnetId' \
--output text)
```
1. Crea un gruppo di sicurezza:
```
SECURITY_GROUP_ID=$(aws ec2 create-security-group \
--group-name my-capacity-provider-sg \
--description "Security group for Lambda Managed Instances" \
--vpc-id $VPC_ID \
--query 'GroupId' \
--output text)
```
**Nota:** le funzioni Lambda Managed Instances richiedono la configurazione VPC per accedere alle risorse esterne al VPC e trasmettere i dati di telemetria a Logs e X-Ray. CloudWatch Per i dettagli sulla configurazione, consulta [Networking for Lambda Managed Instances](lambda-managed-instances-networking.md).
### Fase 3: creazione di un provider di capacità
Un provider di capacità gestisce le EC2 istanze che eseguono le funzioni Lambda.
**Come creare un provider di capacità**
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=[$SUBNET_ID],SecurityGroupIds=[$SECURITY_GROUP_ID] \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \
--instance-requirements Architectures=[x86_64] \
--capacity-provider-scaling-config MaxVCpuCount=30
```
Questo comando crea un provider di capacità con la seguente configurazione:
+ **Configurazione VPC**: specifica la sottorete e il gruppo di sicurezza per le istanze EC2
+ **Autorizzazioni**: definisce il ruolo IAM utilizzato da Lambda per gestire le istanze EC2
+ **Requisiti dell'istanza**: specifica l'architettura x86\$164
+ **Configurazione di scalabilità**: imposta un massimo di 30 v per il provider di capacità CPUs
### Fase 4: Creare una funzione Lambda con codice in linea
**Per creare una funzione con codice in linea**
1. Innanzitutto, crea una semplice funzione Python e impacchettala in linea:
```
# Create a temporary directory for the function code
mkdir -p /tmp/my-lambda-function
cd /tmp/my-lambda-function
# Create a simple Python handler
cat > lambda_function.py << 'EOF'
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': json.dumps({
'message': 'Hello from Lambda Managed Instances!',
'event': event
})
}
EOF
# Create a ZIP file
zip function.zip lambda_function.py
```
1. Crea la funzione Lambda utilizzando il file ZIP in linea:
```
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=$(aws configure get region)
aws lambda create-function \
--function-name my-managed-instance-function \
--package-type Zip \
--runtime python3.13 \
--handler lambda_function.lambda_handler \
--zip-file fileb:///tmp/my-lambda-function/function.zip \
--role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \
--architectures x86_64 \
--memory-size 2048 \
--ephemeral-storage Size=512 \
--capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:my-capacity-provider}
```
La funzione viene creata con:
+ **Runtime** — Python 3.13
+ **Handler** — La funzione in `lambda_handler` `lambda_function.py`
+ **Memoria**: 2048 MB
+ Archiviazione **effimera: 512** MB
+ **Provider di capacità**: collegamenti al provider di capacità creato
### Fase 5: Pubblicare una versione della funzione
Per eseguire la funzione su Lambda Managed Instances, devi pubblicare una versione.
**Per pubblicare una versione della funzione**
```
aws lambda publish-version \
--function-name my-managed-instance-function
```
Questo comando pubblica la versione 1 della funzione e la distribuisce al provider di capacità.
### Passaggio 6: richiama la funzione
Dopo la pubblicazione, puoi richiamare la tua funzione.
**Per richiamare la tua funzione**
```
aws lambda invoke \
--function-name my-managed-instance-function:1 \
--payload '{"name": "World"}' \
response.json
# View the response
cat response.json
```
La funzione viene eseguita sulle EC2 istanze gestite dal fornitore di capacità e restituisce una risposta.
### Eliminazione
Per evitare di incorrere in addebiti, elimina le risorse che hai creato:
1. Eliminare la funzione:
```
aws lambda delete-function --function-name my-managed-instance-function
```
1. Eliminare il fornitore di capacità:
```
aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider
```
1. Eliminare le risorse VPC:
```
aws ec2 delete-security-group --group-id $SECURITY_GROUP_ID
aws ec2 delete-subnet --subnet-id $SUBNET_ID
aws ec2 delete-vpc --vpc-id $VPC_ID
```
1. Elimina i ruoli IAM:
```
aws iam detach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam detach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
aws iam delete-role --role-name MyLambdaExecutionRole
aws iam delete-role --role-name MyCapacityProviderOperatorRole
```
# Concetti principali
Lambda Managed Instances introduce diversi concetti fondamentali che differiscono dalle tradizionali funzioni Lambda. La comprensione di questi concetti è essenziale per implementare e gestire efficacemente le funzioni sull'infrastruttura. EC2
**I fornitori di capacità** costituiscono la base delle istanze gestite Lambda. Un provider di capacità definisce l'infrastruttura di elaborazione su cui vengono eseguite le tue funzioni, inclusa la configurazione del VPC, i requisiti delle istanze e le politiche di scalabilità. I provider di capacità fungono anche da limite di sicurezza per le vostre funzioni, il che significa che tutte le funzioni assegnate allo stesso fornitore di capacità devono essere considerate reciprocamente affidabili.
Il **comportamento di scalabilità** differisce in modo significativo dalle tradizionali funzioni Lambda. Invece di scalare su richiesta all'arrivo delle chiamate, le istanze gestite si scalano in modo asincrono in base all'utilizzo delle risorse della CPU. Questo approccio elimina le partenze a freddo ma richiede una pianificazione della crescita del traffico. Se il traffico raddoppia più che nel giro di 5 minuti, potresti riscontrare rallentamenti man mano che Lambda aumenta la capacità per soddisfare la domanda.
**La sicurezza e** le autorizzazioni richiedono un'attenta considerazione. Sono necessarie le autorizzazioni del ruolo di operatore per consentire a Lambda di EC2 gestire le risorse nei tuoi provider di capacità. Inoltre, gli utenti hanno bisogno dell'`lambda:PassCapacityProvider`autorizzazione per assegnare funzioni ai fornitori di capacità, che fungono da barriera di sicurezza per controllare quali funzioni possono essere eseguite su un'infrastruttura specifica.
**L'esecuzione simultanea** è una caratteristica fondamentale delle istanze gestite. Ogni ambiente di esecuzione è in grado di gestire più chiamate contemporaneamente, massimizzando l'utilizzo delle risorse per le applicazioni che richiedono un elevato livello di I/O. Ciò differisce dalla Lambda tradizionale in cui ogni ambiente elabora una richiesta alla volta. Questo modello di esecuzione richiede attenzione alla sicurezza dei thread, alla gestione dello stato e all'isolamento del contesto a seconda del runtime.
Le seguenti sezioni forniscono informazioni dettagliate su ogni concetto fondamentale.
# fornitori di capacità
Un provider di capacità è la base per l'esecuzione di istanze gestite Lambda. Funge da limite di sicurezza per le tue funzioni e definisce le risorse di calcolo che Lambda fornirà e gestirà per tuo conto.
Quando crei un fornitore di capacità, specifichi:
+ **Configurazione VPC: le** sottoreti e i gruppi di sicurezza in cui verranno eseguite le istanze
+ **Autorizzazioni**: ruoli IAM per Lambda per la gestione delle risorse EC2
+ **Requisiti dell'istanza** [(facoltativi): preferenze relative all'architettura e al tipo di istanza](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)
+ **Configurazione di scalabilità** (opzionale): in che modo Lambda ridimensiona le tue istanze
## Comprendere i provider di capacità come limite di sicurezza
I provider di capacità fungono da limite di sicurezza per le funzioni Lambda all'interno del VPC, sostituendo l'isolamento basato su Firecracker. Le funzioni vengono eseguite in contenitori all'interno delle istanze, ma i contenitori non forniscono un forte isolamento di sicurezza tra le funzioni, a differenza di Firecracker micro. VMs
**Concetti chiave sulla sicurezza:**
+ **Capacity Provider:** il limite di sicurezza che definisce i livelli di fiducia per le funzioni Lambda
+ **Isolamento dei container:** i container NON sono un fornitore di sicurezza: non fate affidamento su di essi per la sicurezza tra carichi di lavoro non affidabili
+ **Trust Separation:** separa i carichi di lavoro che non sono reciprocamente affidabili utilizzando diversi provider di capacità
## Creazione di un provider di capacità
È possibile creare un provider di capacità utilizzando la AWS CLI, la console di AWS gestione o. AWS SDKs
**Utilizzo della AWS CLI:**
```
aws lambda create-capacity-provider \
--capacity-provider-name my-capacity-provider \
--vpc-config SubnetIds=subnet-12345,subnet-67890,subnet-11111,SecurityGroupIds=sg-12345 \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::123456789012:role/MyOperatorRole \
--instance-requirements Architectures=x86_64 \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Parametri obbligatori
**CapacityProviderName**
+ Un nome univoco per il tuo fornitore di capacità
+ Deve essere univoco all'interno del tuo AWS account
**VpcConfig**
+ **SubnetIds**(obbligatorio): Almeno una sottorete, massimo 16. Utilizza sottoreti in più zone di disponibilità per garantire la resilienza
+ **SecurityGroupIds**(opzionale): gruppi di sicurezza per le tue istanze. Il valore predefinito è il gruppo di sicurezza VPC predefinito se non specificato
**PermissionsConfig**
+ **CapacityProviderOperatorRoleArn**(richiesto): ruolo IAM che consente a Lambda di gestire le risorse EC2 nel tuo provider di capacità
### Parametri facoltativi
**InstanceRequirements**
Specificate l'architettura e i [tipi di istanza](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) per il vostro provider di capacità:
+ **Architetture**: scegli `x86_64` o. `arm64` L'impostazione predefinita è `x86_64`
+ **AllowedInstanceTypes**: Specificate i tipi di istanza consentiti. Ad esempio: `m5.8xlarge`
+ **ExcludedInstanceTypes**: Specificate i tipi di istanza esclusi utilizzando i caratteri jolly. È possibile specificare solo uno dei o AllowedInstanceTypes ExcludedInstanceTypes
Per impostazione predefinita, Lambda sceglie i tipi di istanza ottimali per il carico di lavoro. Ti consigliamo di lasciare che le istanze gestite da Lambda scelgano i tipi di istanza per te, poiché limitare il numero di tipi di istanze possibili può comportare una minore disponibilità.
**CapacityProviderScalingConfig**
Configura il modo in cui Lambda ridimensiona le tue istanze:
+ **ScalingMode**: impostato per il ridimensionamento automatico o `Auto` `Manual` per il controllo manuale. L'impostazione predefinita è `Auto`
+ **VCpuNumero massimo**: numero massimo di v CPUs per il provider di capacità. Il valore predefinito è 400.
+ **ScalingPolicies**: definisci le politiche di scalabilità del tracciamento degli obiettivi per l'utilizzo della CPU e della memoria
**KmsKeyArn**
Specificare una AWS KMS chiave per la crittografia EBS. Il valore predefinito è la chiave AWS gestita se non specificata.
**Tag**
Aggiungi tag per organizzare e gestire i tuoi provider di capacità.
## Gestione dei fornitori di capacità
### Aggiornare un provider di capacità
È possibile aggiornare determinate proprietà di un provider di capacità utilizzando l'`UpdateCapacityProvider`API.
```
aws lambda update-capacity-provider \
--capacity-provider-name my-capacity-provider \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Eliminare un provider di capacità
Puoi eliminare un fornitore di capacità quando non è più necessario utilizzando l'`DeleteCapacityProvider`API.
```
aws lambda delete-capacity-provider \
--capacity-provider-name my-capacity-provider
```
**Nota:** non è possibile eliminare un fornitore di capacità a cui sono associate versioni di funzioni.
### Visualizzazione dei dettagli del fornitore di capacità
Recupera informazioni su un fornitore di capacità utilizzando l'`GetCapacityProvider`API.
```
aws lambda get-capacity-provider \
--capacity-provider-name my-capacity-provider
```
## Stati del fornitore di capacità
Un provider di capacità può trovarsi in uno dei seguenti stati:
+ **In sospeso**: il provider di capacità è in fase di creazione
+ **Attivo**: il provider di capacità è pronto per l'uso
+ **Fallita**: la creazione del provider di capacità non è riuscita
+ **Eliminazione**: il provider di capacità viene eliminato
## Quote
+ **Fornitori di capacità massima per account**: 1.000
+ **Numero massimo di versioni funzionali per provider di capacità**: 100 (non possono essere aumentate)
## Best practice
1. **Separati per livello di affidabilità**: crea diversi provider di capacità per carichi di lavoro con requisiti di sicurezza diversi
1. **Usa nomi descrittivi: nomina i** fornitori di capacità per indicare chiaramente l'uso previsto e il livello di affidabilità (ad esempio,`production-trusted`) `dev-sandbox`
1. **Utilizza più zone di disponibilità**: specifica le sottoreti su più AZs zone per un'elevata disponibilità
1. **Consenti a Lambda di scegliere i tipi di istanza**: a meno che tu non abbia requisiti hardware specifici, consenti a Lambda di selezionare i tipi di istanza ottimali per la disponibilità
1. **Monitora l'utilizzo**: AWS CloudTrail da utilizzare per monitorare le assegnazioni dei provider di capacità e i modelli di accesso
## Fasi successive
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ Comprendi [la sicurezza e le autorizzazioni per le istanze gestite Lambda](lambda-managed-instances-security.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
# Scalabilità delle istanze gestite Lambda
Le istanze gestite Lambda non sono scalabili all'arrivo delle chiamate e non supportano gli avviamenti a freddo. Al contrario, è scalabile in modo asincrono utilizzando segnali di consumo delle risorse. Le istanze gestite attualmente sono scalabili in base all'utilizzo delle risorse della CPU e alla saturazione di più valute.
**Principali differenze:**
+ **Lambda (impostazione predefinita):** scala quando non esiste un ambiente di esecuzione libero per gestire una chiamata in entrata (avvio a freddo)
+ **Istanze gestite Lambda:** scalabilità asincrona in base all'utilizzo delle risorse della CPU e alla saturazione multiconcorrenza degli ambienti di esecuzione
Se il traffico raddoppia più che nel giro di 5 minuti, potresti riscontrare rallentamenti man mano che Lambda ridimensiona le istanze e gli ambienti di esecuzione per soddisfare la domanda.
## Il ciclo di vita della scalabilità
Lambda Managed Instances utilizza un'architettura distribuita per gestire la scalabilità:
**Componenti:**
+ **Istanze gestite**: esegui nel tuo account nelle sottoreti che fornisci
+ **Router e scaler**: componenti Lambda condivisi che indirizzano le chiamate e gestiscono la scalabilità
+ **Lambda Agent**: viene eseguito su ogni istanza gestita per gestire il ciclo di vita dell'ambiente di esecuzione e monitorare il consumo di risorse
**Come funziona:**
1. Quando pubblichi una versione della funzione con un provider di capacità, Lambda avvia Managed Instances nel tuo account. Per impostazione predefinita, ne avvia tre per la resilienza AZ e avvia tre ambienti di esecuzione prima di contrassegnare la versione della funzione come ATTIVA.
1. Ogni istanza gestita può eseguire ambienti di esecuzione per più funzioni mappate allo stesso provider di capacità.
1. Man mano che il traffico fluisce verso l'applicazione, gli ambienti di esecuzione consumano risorse. L'agente Lambda invia una notifica allo Scaler, che decide se scalare nuovi ambienti di esecuzione o istanze gestite.
1. Se Router tenta di inviare una chiamata a un ambiente di esecuzione con un elevato consumo di risorse, l'agente Lambda su quell'istanza gli notifica di riprovare su un'altra istanza.
1. Quando il traffico diminuisce, Lambda Agent invia una notifica a Scaler, che decide di ridimensionare gli ambienti di esecuzione e scalare nelle istanze gestite.
## Regolazione del comportamento di scalabilità
È possibile personalizzare il comportamento di scalabilità delle istanze gestite tramite quattro controlli:
### Controlli a livello di funzione
#### 1. Memoria delle funzioni e v CPUs
Scegli la dimensione della memoria e l'allocazione della vCPU per la tua funzione. La dimensione minima della funzione supportata è 2 GB e 1 vCPU.
**Considerazioni:**
+ Scegli un'impostazione di memoria e vCPU che supporti le esecuzioni simultanee della tua funzione
+ Non è possibile configurare una funzione con meno di 1 vCPU, poiché le funzioni in esecuzione su istanze gestite dovrebbero supportare carichi di lavoro multi-concorrenti.
+ Non puoi scegliere meno di 2 GB perché corrisponde al rapporto 2 a 1 tra memoria e vCPU delle istanze c, che hanno il rapporto più basso
+ Per le applicazioni Python, potrebbe essere necessario scegliere un rapporto più elevato tra memoria e vCPUs, ad esempio 4 a 1 o 8 a 1, a causa del modo in cui Python gestisce la multi-concorrenza
+ Se si eseguono operazioni che richiedono un uso intensivo della CPU o si eseguono operazioni di I/O limitate, è consigliabile scegliere più di una vCPU
#### 2. Simultaneità massima
Imposta la concorrenza massima per ambiente di esecuzione.
**Comportamento predefinito:** Lambda sceglie impostazioni predefinite ragionevoli che bilanciano il consumo di risorse e la velocità effettiva, adatte a un'ampia varietà di applicazioni.
**Linee guida per la regolazione:**
+ **Aumentare la concorrenza:** se le chiamate alle funzioni utilizzano pochissima CPU, è possibile aumentare la concorrenza massima fino a un massimo di 64 per vCPU
+ **Riduzione della concorrenza:** se l'applicazione consuma una grande quantità di memoria e pochissima CPU, è possibile ridurre la concorrenza massima
**Importante:** poiché le istanze gestite Lambda sono pensate per applicazioni multi-concorrenti, gli ambienti di esecuzione con una concorrenza molto bassa possono presentare problemi di scalabilità.
### Controlli a livello di provider di capacità
#### 3. Obiettivo di utilizzo delle risorse
Scegli il tuo obiettivo per il consumo di utilizzo della CPU.
**Comportamento predefinito:** Lambda mantiene un margine di manovra sufficiente per raddoppiare il traffico entro 5 minuti senza acceleratori.
**Opzioni di ottimizzazione:**
+ Se il carico di lavoro è molto costante o se l'applicazione non è sensibile alle limitazioni, è possibile impostare l'obiettivo su un livello elevato per ottenere un maggiore utilizzo e ridurre i costi
+ Se si desidera mantenere un margine di manovra sufficiente in caso di picchi di traffico, è possibile impostare obiettivi di risorse a un livello basso, il che richiederà una maggiore capacità
#### 4. Selezione del tipo di istanza
Imposta i tipi di istanza consentiti o esclusi.
**Comportamento predefinito:** Lambda sceglie i tipi di istanza migliori per il tuo carico di lavoro. Ti consigliamo di lasciare che le istanze gestite da Lambda scelgano i tipi di istanza per te, poiché limitare il numero di tipi di istanze possibili può comportare una minore disponibilità.
**Configurazione personalizzata:**
+ **Requisiti hardware specifici:** imposta i tipi di istanze consentiti su un elenco di istanze compatibili. Ad esempio, se disponi di un'applicazione che richiede un'elevata larghezza di banda di rete, puoi selezionare diversi tipi di istanze n
+ **Ottimizzazione dei costi:** per gli ambienti di test o sviluppo, puoi scegliere tipi di istanze più piccoli, come i tipi di istanze m7a.large
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Consulta le guide specifiche per il runtime per la gestione della concorrenza multipla
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ Monitora le metriche di scalabilità per ottimizzare il comportamento di scalabilità
# Sicurezza e autorizzazioni
Le istanze gestite Lambda utilizzano i **provider di capacità come** limiti di fiducia. Le funzioni vengono eseguite in contenitori all'interno di queste istanze, ma i contenitori non forniscono un isolamento di sicurezza tra i carichi di lavoro. Tutte le funzioni assegnate allo stesso provider di capacità devono essere considerate affidabili da entrambe le parti.
## Concetti chiave di sicurezza
+ **Capacity Provider**: il limite di sicurezza che definisce i livelli di fiducia per le funzioni Lambda
+ **Isolamento** dei container: i container non sono un limite di sicurezza: non fate affidamento su di essi per la sicurezza tra carichi di lavoro non affidabili
+ **Trust Separation**: separa i carichi di lavoro che non sono reciprocamente affidabili utilizzando diversi provider di capacità
## Autorizzazioni richieste
### PassCapacityProvider Azione
Gli utenti devono essere `lambda:PassCapacityProvider` autorizzati ad assegnare funzioni ai fornitori di capacità. Questa autorizzazione funge da barriera di sicurezza, garantendo che solo gli utenti autorizzati possano collocare funzioni in fornitori di capacità specifiche.
Gli amministratori degli account controllano quali funzioni possono utilizzare fornitori di capacità specifici tramite l'azione `lambda:PassCapacityProvider` IAM. Questa azione è necessaria quando:
+ Creazione di funzioni che utilizzano istanze gestite Lambda
+ Aggiornamento delle configurazioni delle funzioni per utilizzare un provider di capacità
+ Implementazione di funzioni tramite infrastruttura come codice
**Esempio di politica IAM**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:PassCapacityProvider",
"Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*"
}
]
}
```
### Ruolo collegato ai servizi
AWS Lambda utilizza il ruolo `AWSServiceRoleForLambda` collegato ai servizi per gestire le risorse ec2 di Lambda Managed Instances nei tuoi provider di capacità.
## Best practice
1. **Separati per livello di fiducia**: crea diversi provider di capacità per carichi di lavoro con requisiti di sicurezza diversi
1. **Usa nomi descrittivi: nomina i** fornitori di capacità per indicare chiaramente l'uso previsto e il livello di affidabilità (ad esempio,`production-trusted`) `dev-sandbox`
1. **Applica il privilegio minimo**: concedi `PassCapacityProvider` le autorizzazioni solo ai fornitori di capacità necessari
1. **Monitora l'utilizzo**: AWS CloudTrail da utilizzare per monitorare le assegnazioni e i modelli di accesso dei fornitori di capacità
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
# Ruolo dell'operatore Lambda per le istanze gestite Lambda
Quando utilizzi Lambda Managed Instances, Lambda necessita delle autorizzazioni per gestire la capacità di elaborazione nel tuo account. Il ruolo operatore fornisce queste autorizzazioni tramite policy IAM che consentono a Lambda di EC2 gestire le istanze nel provider di capacità.
Lambda assume il ruolo di operatore durante l'esecuzione di queste operazioni di gestione, in modo simile a come Lambda assume un ruolo di esecuzione durante l'esecuzione della funzione.
## Creazione di un ruolo di operatore
Puoi creare un ruolo operatore nella console IAM o con la AWS CLI. Il ruolo deve includere:
+ **Politica delle autorizzazioni**: concede le autorizzazioni per gestire i provider di capacità e le risorse associate
+ **Politica di fiducia**: consente al servizio Lambda (`lambda.amazonaws.com`) di assumere il ruolo
### Policy delle autorizzazioni
Il ruolo di operatore richiede le autorizzazioni per gestire i provider di capacità e le risorse di elaborazione sottostanti. Come minimo, il ruolo richiede le autorizzazioni previste nella policy [AWSLambdaEC2ResourceOperatorgestita](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator), attualmente:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateTags",
"ec2:AttachNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCapacityReservations",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
```
### Policy di attendibilità
La policy di fiducia consente a Lambda di assumere il ruolo di operatore:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Ruolo collegato ai servizi per le istanze gestite Lambda
Per gestire in modo responsabile il ciclo di vita delle istanze gestite Lambda, Lambda richiede un accesso persistente per terminare le istanze gestite nel tuo account. Lambda utilizza un ruolo collegato al servizio (SLR) AWS Identity and Access Management (IAM) per eseguire queste operazioni.
**Creazione automatica**: il ruolo collegato al servizio viene creato automaticamente la prima volta che si crea un provider di capacità. L'utente che crea il primo fornitore di capacità deve disporre dell'`iam:CreateServiceLinkedRole`autorizzazione per il `lambda.amazonaws.com` principale.
**Autorizzazioni**: il ruolo collegato al servizio concede a Lambda le seguenti autorizzazioni sulle istanze gestite:
+ `ec2:TerminateInstances`— Per terminare le istanze alla fine del loro ciclo di vita
+ `ec2:DescribeInstances`— Per enumerare le istanze gestite
**Eliminazione**: puoi eliminare questo ruolo collegato al servizio solo dopo aver eliminato tutti i provider di capacità di Lambda Managed Instances nel tuo account.
Per ulteriori informazioni sui ruoli collegati al servizio, consulta [Utilizzo di ruoli collegati ai servizi per Lambda](using-service-linked-roles.md).
# Comprendere l'ambiente di esecuzione di Lambda Managed Instances
Le istanze gestite Lambda forniscono un modello di distribuzione alternativo che esegue il codice funzionale su istanze Amazon di proprietà del cliente EC2 mentre Lambda gestisce gli aspetti operativi. L'ambiente di esecuzione per le istanze gestite presenta diverse differenze importanti rispetto alle funzioni Lambda (predefinite), in particolare nel modo in cui gestisce le chiamate simultanee e gestisce i cicli di vita dei container.
**Nota:** per informazioni sull'ambiente di esecuzione Lambda (predefinito), vedere Comprendere il ciclo di vita dell'ambiente di esecuzione Lambda.
## Ciclo di vita dell'ambiente di esecuzione
Il ciclo di vita di un ambiente di esecuzione delle funzioni Lambda Managed Instances differisce da Lambda (impostazione predefinita) in diversi modi chiave:
### Fase di init
Durante la fase di inizializzazione, Lambda esegue le seguenti operazioni:
+ Inizializza e registra tutte le estensioni
+ Avvia il punto di ingresso del runtime. Il runtime genera il numero configurato di runtime worker (l'implementazione dipende dal runtime)
+ Codice di inizializzazione della funzione Run (codice esterno al gestore)
+ Attendi che almeno un runtime worker segnali la disponibilità chiamando `/runtime/invocation/next`
La fase di inizializzazione è considerata completa quando le estensioni sono state inizializzate e almeno un runtime worker ha chiamato. `/runtime/invocation/next` La funzione è quindi pronta per elaborare le chiamate.
**Nota**
Per le funzioni Lambda Managed Instances, l'inizializzazione può richiedere fino a 15 minuti. Il timeout è il massimo di 130 secondi o il timeout della funzione configurata (fino a 900 secondi).
### Invoca fase
La fase Invoke per le funzioni Lambda Managed Instances presenta diverse caratteristiche uniche:
**Funzionamento continuo.** A differenza di Lambda (impostazione predefinita), l'ambiente di esecuzione rimane continuamente attivo ed elabora le chiamate non appena arrivano senza bloccarsi tra una chiamata e l'altra.
**Elaborazione parallela.** È possibile eseguire più chiamate contemporaneamente all'interno dello stesso ambiente di esecuzione, ciascuna gestita da un runtime worker diverso.
**Timeout indipendenti.** Il timeout configurato della funzione si applica a ogni singola chiamata. Quando scade una chiamata, Lambda contrassegna quella chiamata specifica come fallita ma non interrompe le altre chiamate in esecuzione né termina l'ambiente di esecuzione.
**Gestione della contropressione.** Se tutti i runtime worker sono impegnati nell'elaborazione delle chiamate, le nuove richieste di chiamata vengono rifiutate fino a quando un worker non diventa disponibile.
## Gestione e ripristino degli errori
La gestione degli errori negli ambienti di esecuzione delle funzioni Lambda Managed Instances è diversa da Lambda (impostazione predefinita):
**Richiama i timeout.** Quando scade una singola chiamata, Lambda restituisce un errore di timeout per quella chiamata. Tuttavia, Lambda Managed Instances non impone il timeout: il codice continuerà a funzionare. In qualità di sviluppatore di funzioni, sei responsabile del rilevamento e della gestione del timeout. L'oggetto context espone il tempo rimanente per l'invocazione, con un valore zero o negativo che indica un timeout. Le altre chiamate simultanee nell'ambiente di esecuzione continuano l'elaborazione normalmente.
**Errori dei Runtime Worker.** Se un processo di runtime worker si blocca, l'ambiente di esecuzione continua a funzionare con i restanti lavoratori sani.
**L'estensione si blocca.** Se un processo di estensione si blocca durante l'inizializzazione o l'operazione, l'intero ambiente di esecuzione viene contrassegnato come non integro e viene terminato. Lambda crea un nuovo ambiente di esecuzione per sostituirlo.
**Nessun ripristino o riparazione.** A differenza di Lambda (impostazione predefinita), le istanze gestite non tentano di reimpostare e reinizializzare l'ambiente di esecuzione dopo errori. Invece, i contenitori non integri vengono chiusi e sostituiti con altri nuovi.
# Versione \$1LATEST.PUBLISHED in Lambda Managed Instances
Le funzioni Lambda Managed Instances supportano lo stesso flusso di lavoro di controllo delle versioni numerate di Lambda (impostazione predefinita). Se preferisci non mantenere versioni numerate, Lambda Managed Instances introduce un nuovo tipo di versione:. `$LATEST.PUBLISHED` Questa versione consente di creare o ripubblicare l'ultima versione pubblicata secondo necessità con codice o configurazione aggiornati, senza gestire versioni numerate.
**Differenza fondamentale rispetto a \$1LATEST:** quando richiami una funzione Lambda Managed Instances utilizzando un ARN non qualificato, Lambda richiama implicitamente la versione anziché la versione \$1LATEST non pubblicata. `$LATEST.PUBLISHED`
Il seguente comando AWS CLI crea o ripubblica la versione. `$LATEST.PUBLISHED`
```
aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED
```
Verrà visualizzato l’output seguente:
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:$LATEST.PUBLISHED",
"Version": "$LATEST.PUBLISHED",
"Role": "arn:aws:iam::123456789012:role/lambda-role",
"Handler": "function.handler",
"Runtime": "nodejs24.x",
...
}
```
**Nota**
Se utilizzi AWS CloudFormation o la console Lambda per creare una funzione Lambda Managed Instances, Lambda crea automaticamente la versione. `$LATEST.PUBLISHED`
# Runtime di esecuzione delle istanze gestite Lambda
Lambda elabora le richieste in modo diverso quando utilizza istanze gestite Lambda. Invece di gestire le richieste in sequenza in ogni ambiente di esecuzione, le istanze gestite Lambda elaborano più richieste contemporaneamente all'interno di ciascun ambiente di esecuzione. Questa modifica nel modello di esecuzione significa che le funzioni che utilizzano le istanze gestite Lambda devono considerare la sicurezza dei thread, la gestione dello stato e l'isolamento del contesto, problemi che non sorgono nel modello a concorrenza singola Lambda (predefinito). Inoltre, l'implementazione multi-concorrenza varia da un runtime all'altro.
## Lingue supportate
Le istanze gestite Lambda possono essere utilizzate con i seguenti linguaggi di programmazione e runtime:
+ **Java: Java** 21 e versioni successive.
+ **Python: Python 3.13** e versioni successive.
+ **Node.js:** Node.js 22 e versioni successive.
+ **.NET:** .NET 8 e versioni successive.
+ **Rust:** supportato utilizzando il runtime solo per il sistema operativo `provided.al2023` e versioni successive.
## Considerazioni specifiche sulla lingua
Ogni linguaggio di programmazione implementa la multiconcorrenza in modo diverso. È necessario comprendere come viene implementata la concorrenza multipla nel linguaggio di programmazione prescelto per applicare le migliori pratiche di concorrenza appropriate.
**Java**
Utilizza un unico processo con thread del sistema operativo per la concorrenza. Più thread eseguono il metodo handler contemporaneamente, richiedendo una gestione thread-safe delle risorse statali e condivise.
**Python**
Utilizza più processi Python in cui ogni richiesta simultanea viene eseguita in un processo separato. Ciò protegge dalla maggior parte dei problemi di concorrenza, sebbene sia necessaria attenzione per le risorse condivise come la directory. `/tmp`
**Node.js**
Utilizza [thread di lavoro con esecuzione](https://nodejs.org/api/worker_threads.html) asincrona. Le richieste concorrenti sono distribuite tra i thread di lavoro e ogni thread di lavoro può anche gestire le richieste simultanee in modo asincrono, il che richiede una gestione sicura delle risorse statali e condivise.
**.NET**
Utilizza .NET Tasks con l'elaborazione asincrona di più richieste simultanee. Richiede una gestione sicura delle risorse statali e condivise.
**Rust**
[Utilizza un unico processo con attività asincrone basate su Tokio.](https://tokio.rs/) Il gestore deve essere \$1. `Clone` `Send`
## Fasi successive
Per informazioni dettagliate su ogni runtime, consultate i seguenti argomenti:
+ [Runtime Java per istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ [Runtime Node.js per istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Runtime Python per istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ [.NET runtime per istanze gestite Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Supporto Rust per istanze gestite Lambda](lambda-managed-instances-rust.md)
# Runtime Java per istanze gestite Lambda
Per i runtime Java, le istanze gestite Lambda utilizzano i thread del sistema operativo per la concorrenza. Lambda carica l'oggetto gestore una volta per ambiente di esecuzione durante l'inizializzazione e quindi crea più thread. Questi thread vengono eseguiti in parallelo e richiedono una gestione thread-safe delle risorse statali e condivise. Ogni thread condivide lo stesso oggetto gestore e tutti i campi statici.
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime Java, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Questo valore determina anche il numero di thread utilizzati dal runtime Java. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza dei thread quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multithread. Poiché l'oggetto handler è condiviso tra tutti i thread di runtime worker, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
AWS I client SDK sono thread-safe e non richiedono una gestione speciale.
**Esempio: pool di connessioni al database**
Il codice seguente utilizza un oggetto di connessione al database statico condiviso tra i thread. A seconda della libreria di connessioni utilizzata, questa potrebbe non essere thread-safe.
```
public class DBQueryHandler implements RequestHandler {
// Single connection shared across all threads - NOT SAFE
private static Connection connection;
public DBQueryHandler() {
this.connection = DriverManager.getConnection(jdbcUrl, username, password);
}
@Override
public String handleRequest(Object input, Context context) {
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();
// Multiple threads using same connection causes issues
return result.toString();
}
}
```
Un approccio thread-safe consiste nell'utilizzare un pool di connessioni. Nell'esempio seguente, il gestore di funzioni recupera una connessione dal pool. La connessione viene utilizzata solo nel contesto di una singola richiesta.
```
public class DBQueryHandler implements RequestHandler {
private static HikariDataSource dataSource;
public DBQueryHandler() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
dataSource = new HikariDataSource(config); // Create pool once per Lambda container
}
@Override
public String handleRequest(Object input, Context context) {
String query = "SELECT column_name FROM your_table LIMIT 10";
StringBuilder result = new StringBuilder("Data:\n");
// try-with-resources automatically calls close() on the connection,
// which returns it to the HikariCP pool (does NOT close the physical DB connection)
try (Connection connection = dataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
result.append(rs.getString("column_name")).append("\n");
}
} catch (Exception e) {
context.getLogger().log("Error: " + e.getMessage());
return "Error";
}
return result.toString();
}
}
```
**Esempio: collezioni**
Le raccolte Java standard non sono thread-safe:
```
public class Handler implements RequestHandler {
private static List items = new ArrayList<>();
private static Map cache = new HashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Not thread-safe
cache.put("key", input); // Not thread-safe
return "Success";
}
}
```
Utilizza invece raccolte thread-safe:
```
public class Handler implements RequestHandler {
private static final List items =
Collections.synchronizedList(new ArrayList<>());
private static final ConcurrentHashMap cache =
new ConcurrentHashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Thread-safe
cache.put("key", input); // Thread-safe
return "Success";
}
}
```
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per thread o per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti.
[Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'`LambdaLogger`oggetto, `requestId` viene incluso automaticamente in ogni voce di registro. `context.getLogger()` Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con Java](java-logging.md#java-logging-advanced).
## Contesto della richiesta
L'`context`oggetto è associato al thread di richiesta. Using `context.getAwsRequestId()` fornisce un accesso thread-safe all'ID della richiesta corrente.
Utilizzare `context.getXrayTraceId()` per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso thread-safe all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Se utilizzi thread virtuali nel tuo programma o crei thread durante l'inizializzazione, dovrai passare qualsiasi contesto di richiesta richiesto a questi thread.
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra i thread.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ AWS SDK for Java 2.0: versione 2.34.0 o successiva
+ AWS X-Ray SDK per Java: versione 2.20.0 o successiva
+ AWS Distro for OpenTelemetry - Instrumentation for Java: versione 2.20.0 o successiva
+ Powertools for AWS Lambda (Java): versione 2.8.0 o successiva
## Utensili elettrici per AWS Lambda (Java)
Powertools for AWS Lambda (Java) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedere [Powertools for AWS Lambda (](https://github.com/aws-powertools/powertools-lambda-java)Java).
## Fasi successive
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite da Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Runtime Node.js per istanze gestite Lambda
Per i runtime di Node.js, Lambda Managed Instances utilizza thread di lavoro `async` con esecuzione basata su`await`/per gestire le richieste simultanee. L'inizializzazione della funzione avviene una volta per thread di lavoro. Le chiamate simultanee vengono gestite in due dimensioni: i thread di lavoro forniscono il parallelismo su v e l'esecuzione asincrona fornisce la concorrenza all'interno di CPUs ciascun thread. Ogni richiesta concorrente gestita dallo stesso thread di lavoro condivide lo stesso oggetto del gestore e lo stesso stato globale, il che richiede una gestione sicura in caso di più richieste simultanee.
## Simultaneità massima
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime di Node.js, l'impostazione predefinita è 64 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
Per Node.js, il numero di richieste simultanee che ogni ambiente di esecuzione può elaborare è determinato dal numero di thread di lavoro e dalla capacità di ciascun thread di lavoro di elaborare le richieste concorrenti in modo asincrono. Il numero predefinito di thread di lavoro è determinato dal numero di v CPUs disponibili oppure è possibile configurare il numero di thread di lavoro impostando la variabile di ambiente. `AWS_LAMBDA_NODEJS_WORKER_COUNT` Si consiglia di utilizzare gestori di funzioni asincroni poiché ciò consente l'elaborazione di più richieste per thread di lavoro. Se il gestore di funzioni è sincrono, ogni thread di lavoro può elaborare solo una singola richiesta alla volta.
## Creazione di funzioni per la concorrenza multipla
Con un gestore di funzioni asincrone, ogni runtime worker elabora più richieste contemporaneamente. Gli oggetti globali verranno condivisi tra più richieste simultanee. Per gli oggetti mutabili, evita di usare global state or use. `AsyncLocalStorage`
AWS I client SDK sono asincroni e non richiedono una gestione speciale.
**Esempio: stato globale**
Il codice seguente utilizza un oggetto globale che viene modificato all'interno del gestore della funzione. Questo non è asincrono.
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
L'inizializzazione dell'`state`oggetto all'interno del gestore della funzione evita lo stato globale condiviso.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Esempio: connessioni al database**
Il codice seguente utilizza un oggetto client condiviso che viene condiviso tra più chiamate. A seconda della libreria di connessioni utilizzata, questo potrebbe non essere sicuro in termini di concorrenza.
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
Un approccio sicuro per la concorrenza consiste nell'utilizzare un pool di connessioni. Il pool utilizza una connessione separata per ogni interrogazione simultanea del database.
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Gestori basati su callback Node.js 22
Quando si utilizza Node.js 22, non è possibile utilizzare un gestore di funzioni basato su callback con Lambda Managed Instances. I gestori basati su callback sono supportati solo per le funzioni Lambda (predefinite). Per i runtime di Node.js 24 e versioni successive, i gestori di funzioni basati su callback sono obsoleti sia per le istanze gestite Lambda (impostazione predefinita) che per quelle gestite Lambda.
Utilizza invece un gestore di `async` funzioni quando usi Lambda Managed Instances. Per ulteriori informazioni, consulta [Definire il gestore di funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html) in Node.js.
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza il `console` logger, `requestId` viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con Node.js](nodejs-logging.md#node-js-logging-advanced).
Le librerie di registrazione di terze parti più diffuse, come [Winston](https://github.com/winstonjs/winston), includono in genere il supporto per l'utilizzo della console per l'output dei log.
## Contesto della richiesta
Using `context.awsRequestId` fornisce un accesso sicuro e asincrono all'ID della richiesta corrente.
Utilizzare `context.xRayTraceId` per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso sicuro in termini di concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `context.getRemainingTimeInMillis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per thread di lavoro. È possibile che vengano visualizzate voci di registro ripetute se la funzione emette log durante l'inizializzazione.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. Le funzioni Lambda (impostazione predefinita) con estensioni possono anche sottoscrivere il segnale SIGTERM utilizzando. `process.on()` Questa funzionalità non è supportata per le funzioni che utilizzano istanze gestite Lambda poiché `process.on()` non può essere utilizzata con i thread di lavoro. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ AWS SDK per JavaScript v3: versione 3.933.0 o successiva
+ AWS X-Ray SDK per Node.js: versione 3.12.0 o successiva
+ AWS Distro for OpenTelemetry - Strumentazione per: versione 0.8.0 o successiva JavaScript
+ Powertools for AWS Lambda TypeScript (): versione 2.29.0 o successiva
## Elettroutensili per AWS TypeScript Lambda ()
Powertools for AWS Lambda TypeScript () è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedete [Powertools for AWS Lambda TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) ().
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite da Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Runtime Python per istanze gestite Lambda
Il runtime Lambda utilizza più processi Python per gestire le richieste simultanee. Ogni richiesta simultanea viene eseguita in un processo separato con spazio di memoria e inizializzazione propri. Ogni processo gestisce una richiesta alla volta, in modo sincrono. I processi non condividono direttamente la memoria, quindi le variabili globali, le cache a livello di modulo e gli oggetti singleton sono isolati tra le richieste simultanee.
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime Python, l'impostazione predefinita è 16 richieste simultanee per vCPU, oppure puoi configurare il tuo valore. Questo valore determina anche il numero di processi utilizzati dal runtime di Python. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
**Importante**
L'utilizzo della concorrenza basata sui processi significa che ogni processo di runtime worker esegue la propria inizializzazione. L'utilizzo totale della memoria è uguale alla memoria per processo moltiplicata per il numero di processi simultanei. Se state caricando librerie o set di dati di grandi dimensioni e la concorrenza è elevata, avrete un notevole ingombro di memoria. In base al carico di lavoro, potrebbe essere necessario regolare il CPU-to-memory rapporto o utilizzare un'impostazione di concorrenza inferiore per evitare di superare la memoria disponibile. Puoi utilizzare la `MemoryUtilization` metrica in per tenere traccia del consumo CloudWatch di memoria.
## Creazione di funzioni per la multiconcorrenza
Grazie al modello multi-concorrenza basato sui processi, le funzioni Lambda Managed Instances che utilizzano i runtime Python non accedono contemporaneamente alle risorse in memoria da più richiami. Non è necessario applicare pratiche di codifica per la sicurezza della concorrenza in memoria.
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per processo o per richiesta per evitare conflitti. Ricorda di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti.
[Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando usi il `logging` modulo della libreria standard Python in Lambda, `requestId` viene incluso automaticamente in ogni voce di registro. Per ulteriori informazioni, consulta [Usare i controlli di registrazione avanzati Lambda con Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Contesto della richiesta
Utilizzare `context.aws_request_id` per accedere all'ID della richiesta corrente.
Con i runtime Python, puoi usare la variabile di `_X_AMZN_TRACE_ID` ambiente per accedere all'ID di traccia X-Ray con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `context.get_remaining_time_in_millis()` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per processo. È possibile che vengano visualizzate voci di registro ripetute se la funzione emette registri durante l'inizializzazione.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ Powertools for AWS Lambda (Python): versione 3.23.0 o successiva
## Powertools per AWS Lambda (Python)
Powertools for AWS Lambda (Python) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedere [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Esamina il [runtime di.NET per le istanze gestite Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# .NET runtime per istanze gestite Lambda
Per i runtime.NET, le istanze gestite Lambda utilizzano un singolo processo.NET per ambiente di esecuzione. Più richieste simultanee vengono elaborate utilizzando .NET Tasks.
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime.NET, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza della concorrenza quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multi-concorrente. Poiché l'oggetto handler è condiviso tra tutte le attività, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
AWS I client SDK sono thread-safe e non richiedono una gestione speciale.
**Esempio: pool di connessioni al database**
Il codice seguente utilizza un oggetto di connessione al database statico che viene condiviso tra richieste simultanee. L'`SqlConnection`oggetto non è thread-safe.
```
public class DBQueryHandler
{
// Single connection shared across threads - NOT SAFE
private SqlConnection connection;
public DBQueryHandler()
{
connection = new SqlConnection("your-connection-string-here");
connection.Open();
}
public string Handle(object input, ILambdaContext context)
{
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
Per risolvere questo problema, utilizzate una connessione separata per ogni richiesta, ricavata da un pool di connessioni. I provider ADO.NET supportano `Microsoft.Data.SqlClient` automaticamente il pool di connessioni quando l'oggetto di connessione viene aperto.
```
public class DBQueryHandler
{
public DBQueryHandler()
{
}
public string Handle(object input, ILambdaContext context)
{
using var connection = new SqlConnection("your-connection-string-here");
connection.Open();
using var cmd = connection.CreateCommand();
cmd.CommandText = "SELECT ..."; // your query
using var reader = cmd.ExecuteReader();
...
}
}
```
**Esempio: raccolte**
Le raccolte .NET standard non sono thread-safe:
```
public class Handler
{
private static List items = new List();
private static Dictionary cache = new Dictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
Usa le raccolte dallo spazio dei `System.Collections.Concurrent` nomi per la sicurezza della concorrenza:
```
public class Handler
{
private static ConcurrentBag items = new ConcurrentBag();
private static ConcurrentDictionary cache = new ConcurrentDictionary();
public string FunctionHandler(object input, ILambdaContext context)
{
items.Add(context.AwsRequestId);
cache["key"] = input;
return "Success";
}
}
```
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un'altra richiesta sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'`context.Logger`oggetto per generare registri, `requestId` viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedere[Utilizzo dei controlli di registrazione avanzati di Lambda con .NET](csharp-logging.md#csharp-logging-advanced).
## Contesto della richiesta
Utilizza la `context.AwsRequestId` proprietà per accedere all'ID della richiesta corrente.
Utilizzate la `context.TraceId` proprietà per accedere all'ID della traccia X-Ray. Ciò fornisce un accesso sicuro per la concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS
Utilizzato per rilevare i `ILambdaContext.RemainingTime` timeout. Per ulteriori informazioni, consulta [Gestione e ripristino degli errori](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra le richieste.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:
+ Amazon.Lambda.Core: versione 2.7.1 o successiva
+ Amazon.Lambda. RuntimeSupport: versione 1.14.1 o successiva
+ OpenTelemetry.Strumentazione. AWSLambda: versione 1.14.0 o successiva
+ AWSXRayRecorder.Core: versione 2.16.0 o successiva
+ AWSSDK.Core: versione 4.0.0.32 o successiva
## Utensili elettrici per AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET](https://docs.aws.amazon.com/powertools/dotnet/)) [AWS e Distro OpenTelemetry for - Instrumentation for DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) attualmente non supportano le istanze gestite Lambda.
## Fasi successive
+ Esamina il [runtime Java per le istanze gestite Lambda](lambda-managed-instances-java-runtime.md)
+ Esamina il [runtime di Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Esamina il runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md)
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
# Supporto Rust per istanze gestite Lambda
## Configurazione della concorrenza
Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione `PerExecutionEnvironmentMaxConcurrency` della funzione. Questa è un'impostazione opzionale e il valore predefinito per Rust è 8 richieste simultanee per vCPU, oppure puoi configurare il tuo valore. Questo valore determina il numero di attività Tokio generate dal runtime ed è statico per tutta la durata dell'ambiente di esecuzione. Ogni lavoratore gestisce esattamente una richiesta in corso alla volta, senza multiplazione per lavoratore. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.
## Creazione di funzioni per la multiconcorrenza
È necessario applicare le stesse pratiche di sicurezza dei thread quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multithread. Poiché l'oggetto handler è condiviso tra tutti i thread di lavoro, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.
Per abilitare la gestione simultanea delle richieste, aggiungi il flag di `concurrency-tokio` funzionalità al tuo `Cargo.toml` file.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
Il punto di `lambda_runtime::run_concurrent(…)` ingresso deve essere chiamato dall'interno di un runtime Tokio, in genere fornito dall'`#[tokio::main]`attributo sulla funzione principale. La chiusura del gestore deve implementare [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html)\$1. [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html) Ciò consente al framework di condividere il gestore tra più attività asincrone in modo sicuro. Se questi limiti non vengono soddisfatti, il codice non verrà compilato.
Quando hai bisogno di uno stato condiviso tra le chiamate (un pool di database, una struttura di configurazione), inseriscilo [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)e clonalo in ogni invocazione. `Arc`
Tutti i client AWS SDK for Rust sono sicuri per la concorrenza e non richiedono una gestione speciale.
### AWS Esempio: client SDK
L'esempio seguente utilizza un client S3 per caricare un oggetto a ogni chiamata. Il client viene clonato direttamente nella chiusura senza: `Arc`
```
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let s3_client = aws_sdk_s3::Client::new(&config);
run_concurrent(service_fn(move |event: LambdaEvent| {
let s3_client = s3_client.clone(); // cheap clone, no Arc needed
async move {
s3_client.put_object()
.bucket(&event.payload.bucket)
.key(&event.payload.key)
.body(event.payload.body.into_bytes().into())
.send()
.await?;
Ok(Response { message: "uploaded".into() })
}
}))
.await
```
### Esempio: pool di connessioni al database
Quando il gestore ha bisogno di accedere a uno stato condiviso, ad esempio un client e una configurazione, inseriscilo [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)e clonalo `Arc` in ogni chiamata:
```
#[derive(Debug)]
struct AppState {
dynamodb_client: DynamoDbClient,
table_name: String,
cache_ttl: Duration,
}
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let state = Arc::new(AppState {
dynamodb_client: DynamoDbClient::new(&config),
table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),
cache_ttl: Duration::from_secs(300),
});
run_concurrent(service_fn(move |event: LambdaEvent| {
let state = state.clone();
async move { handle(event, state).await }
}))
.await
```
## Directory /tmp condivisa
La `/tmp` directory è condivisa tra tutte le chiamate simultanee nello stesso ambiente di esecuzione. Utilizza nomi di file univoci per ogni chiamata (ad esempio includi l'ID della richiesta) o implementa il blocco esplicito dei file per evitare il danneggiamento dei dati.
## Registrazione dei log
L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti. [Le funzioni che utilizzano Lambda Managed Instances supportano il formato di log JSON strutturato tramite i controlli di registrazione avanzati di Lambda.](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Questo formato include`requestId`, che consente di correlare le voci di registro a una singola richiesta. Per ulteriori informazioni, vedere[Registrazione avanzata con la cassa Tracing](rust-logging.md#rust-logging-tracing).
## Contesto della richiesta
L'`Context`oggetto viene passato direttamente a ogni chiamata del gestore. Utilizzare `event.context.request_id` per accedere all'ID della richiesta corrente.
Utilizzare `event.context.xray_trace_id` per accedere all'ID di traccia X-Ray. Lambda non supporta la variabile di `_X_AMZN_TRACE_ID` ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l' AWS SDK per Rust.
Viene utilizzato `event.context.deadline` per rilevare i timeout: contiene la scadenza della chiamata in millisecondi.
## Inizializzazione e spegnimento
L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra le richieste.
Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. `lambda_runtime`offre un aiuto per semplificare la configurazione di una corretta gestione del segnale di spegnimento,. [https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html) Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta [Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda](lambda-runtime-environment.md).
## Versioni di dipendenza
Lambda Managed Instances richiede la seguente versione minima del pacchetto:
+ `lambda_runtime`: versione 1.1.1 o successiva, con la funzionalità abilitata `concurrency-tokio`
+ La versione minima di Rust (MSRV) supportata è 1.84.0.
# Rete per istanze gestite Lambda
Quando si eseguono le funzioni Lambda Managed Instances, è necessario configurare la connettività di rete per consentire alle funzioni di accedere alle risorse esterne al VPC. Ciò include AWS servizi come Amazon S3 e DynamoDB. La connettività è necessaria anche per trasmettere dati di telemetria a CloudWatch Logs e X-Ray.
## Opzioni di connettività
Esistono tre approcci principali per configurare la connettività VPC, ciascuno con diversi compromessi in termini di costi, sicurezza e complessità.
## Sottorete pubblica con un gateway Internet
Questa opzione utilizza una sottorete pubblica con accesso diretto a Internet tramite un gateway Internet. È possibile scegliere tra IPv4 e IPv6 configurazioni.
### IPv4 con gateway internet
**Per configurare la IPv4 connettività con un gateway Internet**
1. Crea o usa una sottorete pubblica esistente con un blocco IPv4 CIDR.
1. Collegare un Internet Gateway al VPC.
1. Aggiorna la tabella delle rotte per indirizzare il `0.0.0.0/0` traffico verso il gateway Internet.
1. Assicurati che alle risorse siano assegnati IPv4 indirizzi pubblici o indirizzi IP elastici.
1. Configura i gruppi di sicurezza per consentire il traffico in uscita sulle porte richieste.
Questa configurazione fornisce una connettività bidirezionale, che consente sia le connessioni in uscita dalle tue funzioni sia le connessioni in entrata da Internet.
### IPv6 con gateway internet
**Per configurare la IPv6 connettività con un gateway Internet**
1. Abilita IPv6 sul tuo VPC.
1. Crea o usa una sottorete pubblica esistente con un blocco IPv6 CIDR assegnato.
1. Collega un gateway Internet al tuo VPC (lo stesso gateway Internet può gestire entrambi IPv4 e IPv6).
1. Aggiorna la tabella delle rotte per indirizzare il `::/0` traffico verso il gateway Internet.
1. Verifica che i AWS servizi di cui hai bisogno per accedere all'assistenza IPv6 nella tua regione.
1. Configura i gruppi di sicurezza per consentire il traffico in uscita sulle porte richieste.
Questa configurazione fornisce una connettività bidirezionale tramite l'indirizzamento. IPv6
### IPv6 con gateway Internet solo in uscita
**Per configurare la IPv6 connettività con un gateway Internet solo in uscita**
1. Abilita IPv6 sul tuo VPC.
1. Crea o usa una sottorete pubblica esistente con un blocco IPv6 CIDR assegnato.
1. Collega un gateway Internet solo in uscita al tuo VPC.
1. Aggiorna la tabella delle rotte per indirizzare il `::/0` traffico verso il gateway Internet solo in uscita.
1. Verifica che i AWS servizi di cui hai bisogno per accedere all'assistenza IPv6 nella tua regione.
1. Configura i gruppi di sicurezza per consentire il traffico in uscita sulle porte richieste.
Questa configurazione fornisce connettività solo in uscita, impedendo le connessioni in entrata da Internet e consentendo alle funzioni di avviare connessioni in uscita.
## Endpoint VPC
Gli endpoint VPC ti consentono di connettere privatamente il tuo VPC ai AWS servizi supportati senza richiedere un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione Direct Connect. AWS Il traffico tra il tuo VPC e il AWS servizio non esce dalla rete Amazon.
**Per configurare gli endpoint VPC**
1. [Apri la console Amazon VPC all'indirizzo console.aws.amazon.com/vpc/.](https://console.aws.amazon.com/vpc/)
1. Nel pannello di navigazione, seleziona **Endpoints (Endpoint)**.
1. Seleziona **Crea endpoint**.
1. Per **Service category (Categoria servizio)**, scegli **AWS services**.
1. Per **Nome del servizio**, seleziona l'endpoint del servizio di cui hai bisogno (ad esempio, `com.amazonaws.region.s3` per Amazon S3).
1. In **VPC**, seleziona il tuo VPC.
1. Per **Sottoreti**, seleziona le sottoreti in cui desideri creare interfacce di rete per endpoint. Per un'elevata disponibilità, seleziona le sottoreti in più zone di disponibilità.
1. Per **Security groups** (Gruppi di sicurezza), seleziona i gruppi di sicurezza da associare alle interfacce di rete dell'endpoint. I gruppi di sicurezza devono consentire il traffico in entrata dal gruppo di sicurezza della funzione sulle porte richieste.
1. Seleziona **Crea endpoint**.
Ripeti questi passaggi per ogni AWS servizio a cui le tue funzioni devono accedere.
## Sottorete privata con gateway NAT
Questa opzione utilizza un gateway NAT per fornire l'accesso a Internet alle risorse nelle sottoreti private, mantenendo le risorse private.
**Per configurare una sottorete privata con gateway NAT**
1. Crea una sottorete pubblica (se non ne esiste già una) con un blocco CIDR.
1. Collegare un Internet Gateway al VPC.
1. Crea un gateway NAT nella sottorete pubblica e assegna un indirizzo IP elastico.
1. Aggiorna la tabella delle rotte della sottorete pubblica per aggiungere una route: `0.0.0.0/0` → internet gateway.
1. Crea o usa una sottorete privata esistente con un blocco CIDR.
1. Aggiorna la tabella di routing della sottorete privata per aggiungere una rotta: `0.0.0.0/0` → gateway NAT.
1. Configura i gruppi di sicurezza per consentire il traffico in uscita sulle porte richieste.
Per un'elevata disponibilità, implementa un gateway NAT in ogni zona di disponibilità e configura le tabelle di routing per zona di disponibilità per utilizzare il gateway NAT locale. In questo modo si evitano costi di trasferimento dati Cross-AZ e si migliora la resilienza.
## Scelta di un'opzione di connettività
Quando scegli un'opzione di connettività, considera i seguenti fattori:
**Sottorete pubblica con gateway Internet**
+ Configurazione più semplice con il costo più basso
+ Adatto per ambienti di sviluppo e test
+ Le risorse possono ricevere connessioni in entrata da Internet (considerazioni relative alla sicurezza)
+ Supporta sia IPv4 e IPv6
**Endpoint VPC**
+ Massima sicurezza, il traffico rimane all'interno della AWS rete
+ Latenza inferiore rispetto al routing Internet
+ Consigliato per ambienti di produzione con requisiti di sicurezza rigorosi
+ Costo più elevato per endpoint, per zona di disponibilità e per GB di elaborazione
+ Richiede un endpoint in ogni zona di disponibilità per un'elevata disponibilità
**Sottorete privata con gateway NAT**
+ Le risorse rimangono private senza accesso a Internet in entrata
+ Modello di architettura aziendale standard
+ Supporta tutto il traffico IPv4 Internet
+ Costo moderato con tariffe orarie per il gateway NAT e per l'elaborazione dei dati
+ Supporta solo IPv4
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ Comprendi [la sicurezza e le autorizzazioni per le istanze gestite Lambda](lambda-managed-instances-security.md)
# Monitoraggio delle istanze gestite da Lambda
Puoi monitorare le istanze gestite Lambda utilizzando le metriche. CloudWatch Lambda pubblica automaticamente le metriche per aiutarti CloudWatch a monitorare l'utilizzo delle risorse, tenere traccia dei costi e ottimizzare le prestazioni.
## Metriche disponibili
Lambda Managed Instances fornisce metriche a due livelli: a livello di provider di capacità e a livello di ambiente di esecuzione.
### Metriche a livello di provider di capacità
Le metriche a livello di Capacity Provider forniscono visibilità sull'utilizzo complessivo delle risorse in tutte le istanze. Queste metriche utilizzano le seguenti dimensioni:
+ **CapacityProviderName**- Il nome del fornitore di capacità
+ **InstanceType**- Il tipo di istanza EC2
**Metriche di utilizzo delle risorse:**
+ **CPUUtilization**- La percentuale di utilizzo della CPU tra le istanze del provider di capacità
+ **MemoryUtilization**- La percentuale di utilizzo della memoria tra le istanze del provider di capacità
**Metriche sulla capacità:**
+ **v CPUAvailable** - La quantità di vCPU disponibile nelle istanze da allocare (in numero)
+ **MemoryAvailable**- La quantità di memoria disponibile nelle istanze da allocare (in byte)
+ **v CPUAllocated** - La quantità di vCPU allocata sulle istanze per gli ambienti di esecuzione (in numero)
+ **MemoryAllocated**- La quantità di memoria allocata sulle istanze per gli ambienti di esecuzione (in byte)
### Metriche a livello di ambiente di esecuzione
Le metriche a livello di ambiente di esecuzione forniscono visibilità sull'utilizzo delle risorse e sulla concorrenza per le singole funzioni. Queste metriche utilizzano le seguenti dimensioni:
+ **CapacityProviderName**- Il nome del fornitore di capacità
+ **FunctionName**- Il nome della tua funzione Lambda
+ **Risorsa**: per risorsa, visualizza le metriche per una versione specifica di una funzione.
**Nota**
Per le istanze gestite Lambda (LMI), la `Resource` dimensione supporta solo le versioni delle funzioni. Il formato è `:`.
**Metriche dell'ambiente di esecuzione disponibili:**
+ **ExecutionEnvironmentConcurrency**- La massima concorrenza in un periodo di campionamento di 5 minuti
+ **ExecutionEnvironmentConcurrencyLimit**- Il limite massimo di concorrenza per ambiente di esecuzione
+ **ExecutionEnvironmentCPUUtilization**- La percentuale di utilizzo della CPU per gli ambienti di esecuzione della funzione
+ **ExecutionEnvironmentMemoryUtilization**- La percentuale di utilizzo della memoria per gli ambienti di esecuzione della funzione
## Frequenza e ritenzione metriche
Le metriche di Lambda Managed Instances vengono pubblicate a intervalli di 5 minuti e conservate per 15 mesi.
## Visualizzazione delle metriche in CloudWatch
**Per visualizzare i parametri delle istanze gestite da Lambda nella console CloudWatch **
1. [Apri la CloudWatch console all'indirizzo console.aws.amazon.com/cloudwatch/.](https://console.aws.amazon.com/cloudwatch/)
1. Nel riquadro di navigazione, seleziona **Parametri**.
1. Nella scheda **Tutte le metriche**, scegli **AWS/Lambda**.
1. Scegli la dimensione metrica che desideri visualizzare:
+ Per le metriche a livello di provider di capacità, filtra per e **CapacityProviderName**InstanceType****
+ **Per le metriche a livello di ambiente di esecuzione, filtra per e **CapacityProviderName**FunctionName****Resource**
1. Seleziona le metriche che desideri monitorare.
## Utilizzo delle metriche per ottimizzare le prestazioni
Monitora l'utilizzo della CPU e della memoria per capire se le tue funzioni sono dimensionate correttamente. Un utilizzo elevato può indicare la necessità di tipi di istanze più grandi o di una maggiore allocazione della memoria funzionale. Tieni traccia delle metriche di concorrenza per comprendere il comportamento di scalabilità e identificare potenziali limitazioni.
Monitora i parametri di capacità per verificare che siano disponibili risorse sufficienti per i tuoi carichi di lavoro. I parametri **v CPUAvailable** e le **MemoryAvailable**metriche ti aiutano a comprendere la capacità residua delle tue istanze.
## Fasi successive
+ Scopri come [scalare le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ Comprendi [la sicurezza e le autorizzazioni per le istanze gestite Lambda](lambda-managed-instances-security.md)
# Quote delle istanze gestite Lambda
Questa pagina descrive le quote di servizio per le istanze gestite AWS Lambda. Queste quote sono separate dalle quote AWS Lambda (predefinite). Alcune quote possono essere aumentate su richiesta.
## Quote di richieste API Lambda
Queste quote controllano la velocità con cui è possibile effettuare chiamate API per gestire i provider di capacità di Lambda Managed Instances. I limiti di velocità delle API di lettura e scrittura si applicano a tutte le operazioni dei provider di capacità combinate, tra cui la creazione, l'aggiornamento, la descrizione e l'eliminazione dei provider di capacità.
| Risorsa | Quota |
| --- | --- |
| La velocità combinata massima (richieste al secondo) per tutti i provider di capacità di lettura APIs | 15 richieste al secondo. Non può essere aumentato. |
| La velocità combinata massima (richieste al secondo) per tutti i provider di capacità di scrittura APIs | 1 richiesta al secondo. Non può essere aumentato. |
## Quote di risorse per Lambda Managed Instances
Queste quote definiscono i limiti per le risorse principali di Lambda Managed Instances all'interno del tuo account. AWS Esse regolano il numero di provider di capacità che è possibile creare e il numero di versioni di funzioni che possono essere associate a ciascun provider di capacità.
| Risorsa | Quota |
| --- | --- |
| fornitori di capacità | 1.000. Il numero massimo di fornitori di capacità creati in un account. |
| Versioni delle funzioni per provider di capacità | 100. Il numero massimo di versioni di funzioni per provider di capacità. Non può essere aumentato. |
## Quote di mappatura delle sorgenti degli eventi
Queste quote controllano il throughput e i limiti di configurazione per l'elaborazione degli eventi da vari AWS servizi sulle istanze gestite Lambda. I limiti di throughput garantiscono prestazioni prevedibili, mentre i limiti del numero di mappature aiutano a mantenere la stabilità del servizio. Le mappature delle sorgenti degli eventi su Lambda Managed Instances supportano Amazon SQS, DynamoDB Streams, Amazon Kinesis Data Streams, Amazon MSK e Apache Kafka autogestito come sorgenti di eventi.
| Risorsa | Quota |
| --- | --- |
| Throughput di mappatura delle sorgenti di eventi SQS standard su istanze gestite Lambda | 5 MB al secondo. Non può essere aumentato. |
| Velocità effettiva di mappatura delle sorgenti di eventi Kafka standard su istanze gestite Lambda | 1 MB al secondo. Non può essere aumentato. |
| Mappature standard delle sorgenti degli eventi Kafka su istanze gestite Lambda | 100 mappature delle sorgenti degli eventi. Non può essere aumentato. |
| Throughput di mappatura delle sorgenti di eventi Kinesis su istanze gestite Lambda | 25 MB al secondo. Può essere aumentato. |
| Throughput di mappatura delle sorgenti di eventi DynamoDB su istanze gestite Lambda | 10 MB al secondo. Può essere aumentato. |
| Richiama la velocità effettiva delle richieste per le chiamate asincrone sulle istanze gestite Lambda | 5 MB al secondo. Può essere aumentato. |
## Richiesta di aumento delle quote
Per le quote che possono essere aumentate, puoi richiedere un aumento tramite la console Service Quotas.
**Richiesta di un aumento delle quote**
1. [Apri la console Service Quotas all'indirizzo console.aws.amazon.com/servicequotas/.](https://console.aws.amazon.com/servicequotas/)
1. Nel pannello di navigazione, scegliere **servizi AWS **.
1. Selezionare **AWS Lambda**.
1. Seleziona la quota che desideri aumentare.
1. Scegliere **Request quota increase (Richiedi aumento di quota)**.
1. Inserisci il nuovo valore della quota e fornisci una giustificazione per l'aumento.
1. Scegli **Richiedi**.
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
# Le migliori pratiche per le istanze gestite Lambda
## configurazione del provider di capacità
**Separa i provider di capacità in base al livello di affidabilità.** Crea diversi provider di capacità per carichi di lavoro con requisiti di sicurezza diversi. Tutte le funzioni assegnate allo stesso fornitore di capacità devono essere considerate affidabili da entrambe le parti, in quanto i fornitori di capacità fungono da limite di sicurezza.
**Usa nomi descrittivi.** Denominate i fornitori di capacità per indicare chiaramente l'uso previsto e il livello di affidabilità (ad esempio`production-trusted`,`dev-sandbox`). Questo aiuta i team a comprendere lo scopo e il livello di sicurezza di ciascun fornitore di capacità.
**Utilizza più zone di disponibilità.** Specificate le sottoreti su più zone di disponibilità durante la creazione di provider di capacità. Lambda lancia tre istanze per impostazione predefinita per la resilienza AZ, garantendo un'elevata disponibilità delle funzioni.
## Selezione del tipo di istanza
**Consenti a Lambda di scegliere i tipi di istanza.** Per impostazione predefinita, Lambda sceglie i tipi di istanza migliori per il tuo carico di lavoro. Ti consigliamo di lasciare che le istanze gestite da Lambda scelgano i tipi di istanza per te, poiché limitare il numero di tipi di istanze possibili può comportare una minore disponibilità.
**Specificate i tipi di istanza per requisiti specifici.** Se hai requisiti hardware specifici, imposta i tipi di istanze consentiti su un elenco di istanze compatibili. Esempio:
+ Per le applicazioni che richiedono un'elevata larghezza di banda di rete, seleziona diversi tipi di istanze n
+ Per ambienti di test o sviluppo con vincoli di costo, scegli tipi di istanze più piccoli come m7a.large
## Configurazione delle funzioni
**Scegli le impostazioni di memoria e vCPU appropriate.** Seleziona configurazioni di memoria e vCPU che supportano le esecuzioni simultanee della tua funzione. La dimensione minima della funzione supportata è 2 GB e 1 vCPU.
+ Per le applicazioni Python, scegli un rapporto più elevato tra memoria e v CPUs (ad esempio 4 a 1 o 8 a 1) a causa del modo in cui Python gestisce la multi-concorrenza
+ Per operazioni che richiedono un uso intensivo della CPU o funzioni che eseguono poco I/O, scegli più di una vCPU
+ Per le applicazioni che richiedono un elevato livello di I/O, come i servizi Web o i lavori in batch, la multi-concorrenza offre i maggiori vantaggi
**Configura la massima concorrenza in modo appropriato.** Lambda sceglie impostazioni predefinite ragionevoli per la massima concorrenza che bilanciano il consumo di risorse e la velocità effettiva. Modifica questa impostazione in base all'utilizzo delle risorse della tua funzione:
+ Aumenta la concorrenza massima (fino a 64 per vCPU) se le chiamate alle funzioni utilizzano pochissima CPU
+ Riduci la concorrenza massima se l'applicazione consuma una grande quantità di memoria e pochissima CPU
Tieni presente che gli ambienti di esecuzione con una concorrenza molto bassa possono presentare rallentamenti e difficoltà di scalabilità.
## Scaling configuration (Configurazione dimensionamento)
**Imposta l'utilizzo appropriato delle risorse target.** Per impostazione predefinita, Lambda offre un margine di manovra sufficiente per raddoppiare il traffico entro 5 minuti senza acceleratori. Modifica questa impostazione in base alle caratteristiche del carico di lavoro:
+ Per carichi di lavoro molto stabili o applicazioni non sensibili alle limitazioni di velocità, stabilisci l'obiettivo su un livello elevato per ottenere un maggiore utilizzo e ridurre i costi
+ Per i carichi di lavoro con potenziali aumenti di traffico, stabilisci obiettivi di risorse a un livello basso per mantenere un margine di crescita aggiuntivo
**Pianifica la crescita del traffico.** Se il traffico raddoppia più che nel giro di 5 minuti, potresti riscontrare rallentamenti man mano che Lambda aumenta la scalabilità delle istanze e degli ambienti di esecuzione. Progetta la tua applicazione per gestire le potenziali limitazioni durante i periodi di rapida scalabilità.
## Sicurezza
**Applica il privilegio minimo per le autorizzazioni. PassCapacityProvider ** Concedi `lambda:PassCapacityProvider` le autorizzazioni solo ai fornitori di capacità necessari. Utilizza le autorizzazioni a livello di risorsa per limitare i fornitori di capacità che gli utenti possono assegnare alle funzioni.
**Monitora l'utilizzo dei provider di capacità.** Utilizzato AWS CloudTrail per monitorare le assegnazioni dei provider di capacità e i modelli di accesso. Questo aiuta a identificare i tentativi di accesso non autorizzati e garantisce la conformità alle politiche di sicurezza.
**Separa i carichi di lavoro non affidabili.** Non fare affidamento sui contenitori per l'isolamento di sicurezza tra carichi di lavoro non affidabili. Utilizza diversi provider di capacità per separare i carichi di lavoro che non sono reciprocamente affidabili.
## Ottimizzazione dei costi
**Sfrutta le opzioni di prezzo di EC2.** Sfrutta i vantaggi di EC2 Savings Plans e Reserved Instances per ridurre i costi. Queste opzioni di prezzo si applicano al calcolo EC2 sottostante (la commissione di gestione del 15% non è scontata).
**Ottimizza per carichi di lavoro stazionari.** Le istanze gestite Lambda sono più adatte per funzioni stazionarie con traffico prevedibile ad alto volume. Per modelli di traffico a raffica, Lambda (impostazione predefinita) può essere più conveniente.
**Monitora l'utilizzo delle risorse.** Tieni traccia delle CloudWatch metriche per comprendere l'utilizzo della CPU e della memoria. Modifica l'allocazione della memoria delle funzioni e la selezione del tipo di istanza in base ai modelli di utilizzo effettivi per ottimizzare i costi.
## Monitoraggio e osservabilità
**Monitora le metriche dei fornitori di capacità.** Tieni traccia delle metriche a livello di provider di capacità CPUUtilization MemoryUtilization, tra cuiCPUAvailable, v e verifica MemoryAvailable che siano disponibili risorse sufficienti per i tuoi carichi di lavoro.
**Monitora le metriche dell'ambiente di esecuzione.** Tieni traccia delle metriche a livello di ambiente di esecuzione, tra cui ExecutionEnvironmentConcurrency e ExecutionEnvironmentConcurrencyLimit per comprendere il comportamento di scalabilità e identificare potenziali limitazioni.
**Imposta allarmi. CloudWatch ** Crea CloudWatch allarmi per le metriche chiave per identificare in modo proattivo i problemi:
+ Utilizzo elevato della CPU o della memoria
+ Bassa capacità disponibile
+ Ci avviciniamo ai limiti di concorrenza
## Considerazioni specifiche sulla lingua
**Segui le best practice specifiche per ogni lingua.** Ogni linguaggio di programmazione gestisce la concorrenza multipla in modo diverso. Consulta le guide specifiche per ogni lingua per consigli dettagliati:
+ **Java:** utilizza raccolte thread-safe e per lo stato specifico della richiesta `AtomicInteger` `ThreadLocal`
+ **Node.js:** da utilizzare InvokeStore per tutti gli stati specifici della richiesta ed evitare le variabili globali
+ **Python:** usa nomi di file univoci nella richiesta IDs e considera `/tmp` l'isolamento della memoria basato sul processo
+ **Rust:** usa `run_concurrent` invece di`run`, con la `concurrency-tokio` funzionalità abilitata. Il gestore deve essere `Clone` \$1`Send`.
**Verifica la sicurezza dei thread e i problemi di concorrenza.** Prima di passare alla produzione, testate accuratamente le vostre funzioni per verificare eventuali problemi di sicurezza dei thread, le condizioni di gara e il corretto isolamento dello stato in presenza di carichi simultanei.
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ Configura la [connettività VPC per i tuoi provider](lambda-managed-instances-networking.md) di capacità
+ [Monitora le istanze gestite Lambda con metriche CloudWatch ](lambda-managed-instances-monitoring.md)
# Risoluzione dei problemi relativi alle istanze gestite da Lambda
## Problemi di limitazione e scalabilità
### Tassi di errore elevati durante lo scale-up
**Problema:** si verificano errori di limitazione (HTTP 429) quando il traffico aumenta rapidamente.
**Causa:** le istanze gestite Lambda scalano in modo asincrono in base all'utilizzo delle risorse della CPU e alla saturazione multi-concorrenza. Se il traffico raddoppia più che nel giro di 5 minuti, potresti riscontrare rallentamenti man mano che Lambda ridimensiona le istanze e gli ambienti di esecuzione per soddisfare la domanda.
**Soluzione:**:
+ **Modifica l'utilizzo delle risorse target:** se il carico di lavoro presenta modelli di traffico prevedibili, imposta un utilizzo delle risorse target inferiore per mantenere un margine di manovra aggiuntivo in caso di picchi di traffico.
+ **Capacità di preriscaldamento:** per gli aumenti di traffico pianificati, aumenta gradualmente il traffico su un periodo più lungo per consentire alla scalabilità di tenere il passo.
+ **Monitora le metriche di scalabilità: tieni traccia delle metriche** degli errori di accelerazione per comprendere il motivo delle limitazioni e dei problemi di scalabilità della capacità.
+ **Rivedi la configurazione delle funzioni:** assicurati che le impostazioni della memoria delle funzioni e della vCPU supportino le esecuzioni simultanee multiple. Se necessario, aumentare la memoria funzionale o l'allocazione della vCPU.
### Ridimensionamento lento
**Problema:** una volta diminuito il traffico, le istanze impiegano molto tempo a ridursi.
**Causa:** le istanze gestite Lambda si ridimensionano gradualmente per mantenere la disponibilità ed evitare rapidi cambiamenti di capacità che potrebbero influire sulle prestazioni.
**Soluzione:**:
Questo è il comportamento previsto. Lambda riduce le istanze in modo conservativo per garantire la stabilità. Monitora le tue CloudWatch metriche per tenere traccia del numero di istanze in esecuzione.
## Problemi di concorrenza
### Ambienti di esecuzione con bassa esperienza di concorrenza, limiti
**Problema: nonostante** la capacità disponibile, le funzioni subiscono delle limitazioni.
**Causa:** gli ambienti di esecuzione con una concorrenza massima molto bassa possono avere difficoltà a scalare in modo efficace. Le istanze gestite Lambda sono progettate per applicazioni multi-concorrenti.
**Soluzione:**:
+ **Aumenta la concorrenza massima:** se le chiamate alle funzioni utilizzano pochissima CPU, aumenta l'impostazione della concorrenza massima fino a 64 per vCPU.
+ **Ottimizza il codice della funzione:** rivedi il codice della funzione per ridurre il consumo di CPU per chiamata e consentire una maggiore concorrenza.
+ **Regola la memoria delle funzioni e la vCPU:** assicurati che la tua funzione disponga di risorse sufficienti per gestire più chiamate simultanee.
### Problemi di sicurezza dei thread (runtime Java)
**Problema:** la funzione Java produce risultati errati o presenta condizioni di gara sotto carico.
**Causa:** più thread eseguono il metodo handler contemporaneamente e lo stato condiviso non è thread-safe.
**Soluzione:**:
+ Usa `AtomicInteger` o per i contatori anziché `AtomicLong` i tipi primitivi
+ Sostituisci con `HashMap` `ConcurrentHashMap`
+ Utilizzare `Collections.synchronizedList()` per avvolgere `ArrayList`
+ Usa `ThreadLocal` per lo stato specifico della richiesta
+ Accedi alla traccia IDs dall'oggetto Lambda Context, non dalle variabili di ambiente
Per una guida dettagliata, consulta la documentazione [di Java runtime for Lambda Managed Instances](lambda-managed-instances-java-runtime.md).
### Problemi di isolamento dello stato (runtime Node.js)
**Problema:** la funzione Node.js restituisce dati da richieste diverse o presenta un danneggiamento dei dati.
**Causa:** le variabili globali sono condivise tra chiamate simultanee sullo stesso thread di lavoro. Quando le operazioni asincrone danno il controllo, altre invocazioni possono modificare lo stato condiviso.
**Soluzione:**:
+ Installa e usa `@aws/lambda-invoke-store` per tutti gli stati specifici della richiesta
+ Sostituisci le variabili globali con e `InvokeStore.set()` `InvokeStore.get()`
+ Usa nomi di file univoci nella `/tmp` richiesta IDs
+ Accedi alla traccia IDs utilizzando `InvokeStore.getXRayTraceId()` invece delle variabili di ambiente
Per una guida dettagliata, consulta la documentazione del [runtime Node.js per le istanze gestite Lambda](lambda-managed-instances-nodejs-runtime.md).
### Conflitti tra file (runtime Python)
**Problema:** la tua funzione Python legge dati errati dai file in. `/tmp`
**Causa:** più processi condividono la `/tmp` directory. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati.
**Soluzione:**:
+ Usa nomi di file univoci con richiesta IDs: `/tmp/request_{context.request_id}.txt`
+ Usa il blocco dei file con `fcntl.flock()` per i file condivisi
+ Pulisci i file temporanei con `os.remove()` dopo l'uso
Per una guida dettagliata, consulta la documentazione del [runtime Python per le istanze gestite Lambda](lambda-managed-instances-python-runtime.md).
## Problemi di prestazioni
### Elevato utilizzo della memoria
**Problema:** le funzioni presentano un elevato utilizzo della memoria o out-of-memory errori.
**Causa:** ogni richiesta simultanea in Python viene eseguita in un processo separato con il proprio spazio di memoria. L'utilizzo totale della memoria è uguale alla memoria per processo moltiplicata per i processi simultanei.
**Soluzione:**:
+ `MemoryUtilization`Monitora la metrica in CloudWatch
+ Riduci l'`MaxConcurrency`impostazione se l'utilizzo della memoria si avvicina al limite di memoria della funzione
+ Aumenta l'allocazione della memoria funzionale per supportare una maggiore concorrenza
+ Ottimizza l'utilizzo della memoria caricando i dati su richiesta anziché durante l'inizializzazione
### Prestazioni incoerenti
**Problema:** le prestazioni delle funzioni variano in modo significativo tra le chiamate.
**Causa:** Lambda può selezionare diversi tipi di istanze in base alla disponibilità oppure le funzioni possono essere eseguite su istanze con disponibilità di risorse variabile.
**Soluzione:**:
+ **Specificare i tipi di istanze consentiti:** se hai requisiti prestazionali specifici, configura i tipi di istanza consentiti nel tuo provider di capacità per limitare i tipi di istanze che Lambda può selezionare.
+ **Monitora le metriche a livello di istanza:** monitora `CPUUtilization` e `MemoryUtilization` a livello di provider di capacità per identificare i vincoli di risorse.
+ **Esamina le metriche sulla capacità:** verifica `vCPUAvailable` e `MemoryAvailable` assicurati che siano disponibili risorse sufficienti sulle tue istanze.
## Problemi con i fornitori di capacità
### La versione della funzione non riesce a diventare ATTIVA
**Problema:** la versione della funzione rimane in sospeso dopo la pubblicazione.
**Causa:** Lambda sta avviando istanze gestite e avviando ambienti di esecuzione. Questo processo richiede tempo, soprattutto per la prima versione della funzione su un nuovo provider di capacità.
**Soluzione:**:
Attendi che Lambda completi il processo di inizializzazione. Lambda avvia tre istanze per impostazione predefinita per la resilienza AZ e avvia tre ambienti di esecuzione prima di contrassegnare la versione della funzione come ATTIVA. Questo richiede in genere diversi minuti.
### Impossibile eliminare il provider di capacità
**Problema:** viene visualizzato un errore quando si tenta di eliminare un provider di capacità.
**Causa:** non è possibile eliminare un provider di capacità a cui sono associate versioni di funzioni.
**Soluzione:**:
1. Identifica tutte le versioni delle funzioni utilizzando il provider di capacità con l'`ListFunctionVersionsByCapacityProvider`API.
1. Elimina o aggiorna le versioni di tali funzioni per rimuovere l'associazione del fornitore di capacità.
1. Riprova a eliminare il provider di capacità.
### Messaggi di errore generici durante la pubblicazione delle funzioni
**Problema:** durante la pubblicazione delle funzioni vengono visualizzati messaggi di errore generici come «Si è verificato un errore interno durante la pubblicazione».
**Soluzione:**:
+ **Verifica le autorizzazioni IAM:** assicurati di disporre dell'`lambda:PassCapacityProvider`autorizzazione per il provider di capacità che stai cercando di utilizzare.
+ **Verifica la configurazione del provider di capacità:** conferma che il tuo fornitore di capacità sia nello stato ATTIVO utilizzando l'`GetCapacityProvider`API.
+ **Rivedi la configurazione del VPC:** assicurati che le sottoreti e i gruppi di sicurezza specificati nel tuo provider di capacità siano configurati e accessibili correttamente.
+ **Controlla AWS CloudTrail i log:** consulta i CloudTrail log per informazioni dettagliate sugli errori relativi all'operazione non riuscita.
## Problemi di monitoraggio e osservabilità
### Metriche mancanti CloudWatch
**Problema:** non vedi le metriche previste CloudWatch per il tuo capacity provider o per le tue funzioni.
**Causa:** le metriche vengono pubblicate a intervalli di 5 minuti. I nuovi fornitori di capacità o le nuove funzioni potrebbero non disporre di metriche immediatamente disponibili.
**Soluzione:**:
Attendi almeno 5-10 minuti dopo la pubblicazione della versione di una funzione prima di aspettarti che le metriche vengano visualizzate in. CloudWatch Verifica di utilizzare lo spazio dei nomi (`AWS/Lambda`) e le dimensioni (`CapacityProviderName`, o) corretti. `FunctionName` `InstanceType`
### Impossibile trovare i log CloudWatch
**Problema:** la funzione viene eseguita correttamente, ma non è possibile trovare i log in Logs. CloudWatch
**Causa:** le istanze gestite Lambda vengono eseguite nel tuo VPC e richiedono una connettività di rete per inviare i log ai log. CloudWatch Senza una corretta configurazione della connettività VPC, le funzioni non possono raggiungere l'endpoint del servizio CloudWatch Logs.
**Soluzione:**:
Configura la connettività VPC per consentire alle tue funzioni di inviare log a Logs. CloudWatch Sono disponibili tre opzioni:
**Opzione 1: endpoint VPC per CloudWatch registri (consigliato per la produzione)**
1. [Apri la console Amazon VPC all'indirizzo console.aws.amazon.com/vpc/.](https://console.aws.amazon.com/vpc/)
1. Nel pannello di navigazione, seleziona **Endpoints (Endpoint)**.
1. Seleziona **Crea endpoint**.
1. Per **Service category (Categoria servizio)**, scegli **AWS services**.
1. Per Nome del **servizio**, seleziona (sostituisci con la tua regione). `com.amazonaws.region.logs` `region` AWS
1. Per **VPC**, seleziona il VPC utilizzato dal tuo provider di capacità.
1. Per le **sottoreti**, seleziona le sottoreti in cui desideri creare interfacce di rete endpoint. Per un'elevata disponibilità, seleziona le sottoreti in più zone di disponibilità.
1. Per **i gruppi di sicurezza**, seleziona i gruppi di sicurezza che consentono il traffico HTTPS in entrata (porta 443) dal gruppo di sicurezza della funzione.
1. Abilita il **DNS privato** per l'endpoint.
1. Seleziona **Crea endpoint**.
**Opzione 2: sottorete pubblica con gateway Internet**
Se il tuo fornitore di capacità utilizza sottoreti pubbliche, assicurati che:
1. Un gateway Internet è collegato al tuo VPC
1. La tabella delle rotte indirizza `0.0.0.0/0` il traffico verso il gateway Internet
1. I gruppi di sicurezza consentono il traffico HTTPS in uscita sulla porta 443
**Opzione 3: sottorete privata con gateway NAT**
Se il tuo fornitore di capacità utilizza sottoreti private, assicurati di:
1. Un gateway NAT esiste in una sottorete pubblica
1. La tabella di routing della sottorete privata indirizza il `0.0.0.0/0` traffico verso il gateway NAT
1. La tabella di routing della sottorete pubblica indirizza il `0.0.0.0/0` traffico verso un gateway Internet
1. I gruppi di sicurezza consentono il traffico HTTPS in uscita sulla porta 443
Per una guida dettagliata sulle opzioni di connettività VPC, consulta [Connettività VPC per istanze gestite Lambda](lambda-managed-instances-networking.md).
### Difficoltà a correlare i log delle richieste simultanee
**Problema:** i log di richieste diverse sono interlacciati, il che rende difficile tracciare le singole richieste.
**Causa:** l'interlacciamento dei log è un comportamento previsto e standard nei sistemi multi-concorrenti.
**Soluzione:**:
+ **Usa la registrazione strutturata con formato JSON:** includi l'ID della richiesta in tutte le istruzioni di registro
+ **Java:** usa Log4j con `ThreadContext` per includere automaticamente l'ID della richiesta
+ **Node.js:** da utilizzare `console.log()` con la formattazione JSON e includere `InvokeStore.getRequestId()`
+ **Python:** usa il modulo di registrazione standard con formattazione JSON e includi `context.request_id`
Per una guida dettagliata, consulta le pagine di documentazione specifiche del runtime.
## Ottenere ulteriore assistenza
Se continui a riscontrare problemi dopo aver provato queste soluzioni:
1. **Esamina CloudWatch le metriche:** verifica le metriche del provider di capacità e dell'ambiente di esecuzione per identificare i vincoli di risorse o i problemi di scalabilità.
1. **Controlla AWS CloudTrail i log:** consulta i CloudTrail log per informazioni dettagliate su chiamate ed errori delle API.
1. **Contatta l' AWS assistenza:** se non riesci a risolvere il problema, contatta l' AWS assistenza per fornire dettagli sulla configurazione del tuo provider di capacità, sulla configurazione delle funzioni e sui messaggi di errore specifici che stai riscontrando.
## Fasi successive
+ Scopri i [provider di capacità per le istanze gestite Lambda](lambda-managed-instances-capacity-providers.md)
+ Comprendi la [scalabilità per le istanze gestite Lambda](lambda-managed-instances-scaling.md)
+ [Consulta le guide specifiche di runtime per [Java](lambda-managed-instances-java-runtime.md), [Node.js e Python](lambda-managed-instances-nodejs-runtime.md)](lambda-managed-instances-python-runtime.md)
+ [Monitora le istanze gestite Lambda con metriche CloudWatch ](lambda-managed-instances-monitoring.md)
+ Consulta [le best practice per le istanze gestite Lambda](lambda-managed-instances-best-practices.md)