Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Von Lambda verwaltete Instances
Mit Lambda Managed Instances können Sie Lambda-Funktionen auf Ihren Amazon EC2 EC2-Instances der aktuellen Generation ausführen, einschließlich Graviton4, netzwerkoptimierten Instances und anderen speziellen Rechenoptionen, ohne Instance-Lebenszyklen, Betriebssystem- und Sprach-Runtime-Patching, Routing, Lastenausgleich oder Skalierungsrichtlinien verwalten zu müssen. Mit Lambda Managed Instances profitieren Sie von EC2-Preisvorteilen, einschließlich EC2-Sparplänen und Reserved Instances.
Eine Liste der unterstützten Instance-Typen finden Sie auf der [AWS Lambda Preisseite](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) und wählen Sie Ihre aus. AWS-Region
## Die wichtigsten Funktionen
Lambda Managed Instances bietet die folgenden Funktionen:
+ **Wählen Sie geeignete Instances** aus — Wählen Sie [geeignete Instances](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) auf der Grundlage von Leistungs- und Kostenanforderungen aus, einschließlich Zugriff auf aktuelle Versionen CPUs wie Graviton4, konfigurierbare Speicher-CPU-Verhältnisse und Netzwerke mit hoher Bandbreite.
+ **Automatische Bereitstellung** — stellt AWS automatisch geeignete Instanzen bereit und aktiviert Umgebungen zur Funktionsausführung.
+ **Dynamische Skalierung** — Instanzen werden dynamisch auf der Grundlage Ihrer Funktionsdatenverkehrsmuster skaliert.
+ **Vollständig verwaltetes Erlebnis** — AWS kümmert sich um Infrastrukturmanagement, Skalierung, Patching und Routing mit denselben umfassenden Integrationen zur Ereignisquelle, mit der Sie vertraut sind.
## Wann sollten Lambda Managed Instances verwendet werden
Ziehen Sie Lambda Managed Instances für die folgenden Anwendungsfälle in Betracht:
+ **Vorhersehbare Workloads mit hohem Volumen — Ideal für Steady-State-Workloads** ohne unerwartete Datenverkehrsspitzen. Lambda Managed Instances lassen sich standardmäßig so skalieren, dass sie eine Verdoppelung des Datenverkehrs innerhalb von fünf Minuten bewältigen können.
+ **Leistungskritische Anwendungen** — Zugriff auf aktuelle CPUs, unterschiedliche Speicher-CPU-Verhältnisse und hoher Netzwerkdurchsatz
+ **Regulatorische Anforderungen** — Granulare Governance-Anforderungen mit Kontrolle über VPC und Instance-Platzierung
+ **Vielfältige Anwendungen** — ereignisgesteuerte Anwendungen, media/data Verarbeitung, Webanwendungen und ältere Workloads, die auf serverlose Systeme migriert werden
## Funktionsweise
Lambda Managed Instances verwendet Kapazitätsanbieter als Grundlage für die Ausführung Ihrer Funktionen:
1. **Erstellen Sie einen Kapazitätsanbieter** — Definieren Sie, wo Ihre Funktionen ausgeführt werden, indem Sie die VPC-Konfiguration und optional die Instanzanforderungen und die Skalierungskonfiguration angeben
1. **Erstellen Sie Ihre Funktion** — Erstellen Sie Lambda-Funktionen wie gewohnt und hängen Sie sie an einen Kapazitätsanbieter an
1. **Veröffentlichen Sie eine Funktionsversion** — Funktionsversionen werden nach der Veröffentlichung auf Kapazitätsanbieter-Instanzen aktiv
Wenn Sie eine Funktionsversion mit einem Kapazitätsanbieter veröffentlichen, startet Lambda Managed Instances in Ihrem Konto. Aus Gründen der AZ-Resilienz werden standardmäßig drei Instances und drei Ausführungsumgebungen gestartet, bevor Ihre Funktionsversion als AKTIV markiert wird. Wenn Sie eine Funktion an einen vorhandenen Kapazitätsanbieter anhängen, der bereits andere Funktionen ausführt, kann es sein, dass Lambda keine neuen Instances hochfährt, wenn die verfügbaren Instances bereits Kapazität für die Ausführungsumgebungen der neuen Funktion haben.
## Parallelitätsmodell
Lambda Managed Instances unterstützen mehrere gleichzeitige Aufrufe, wobei eine Ausführungsumgebung mehrere Aufrufe gleichzeitig verarbeiten kann. Dies unterscheidet sich vom Berechnungstyp Lambda (Standard), der ein einzelnes Parallelitätsmodell bereitstellt, bei dem eine Ausführungsumgebung maximal einen Aufruf gleichzeitig ausführen kann. Multi-Concurrency ermöglicht eine bessere Nutzung Ihrer zugrunde liegenden EC2-Instances und ist besonders vorteilhaft für IO-intensive Anwendungen wie Webservices oder Batch-Jobs. Diese Änderung des Ausführungsmodells bedeutet, dass Thread-Sicherheit, Statusverwaltung und Kontextisolation je nach Laufzeit unterschiedlich gehandhabt werden müssen.
## Tenance und Isolierung
Der Lambda-Compute-Typ (Standard) ist mandantenfähig und nutzt die Firecracker MicroVM-Technologie, um die Ausführungsumgebungen zu isolieren, die auf gemeinsam genutzten Lambda-Flotten ausgeführt werden. Lambda Managed Instances werden in Ihrem Konto ausgeführt und bieten die neuesten EC2-Hardware- und Preisoptionen. Managed Instances verwenden Container, die auf EC2-Nitro-Instances laufen, um Isolation zu gewährleisten, und nicht Firecracker. Kapazitätsanbieter dienen als Sicherheitsgrenze für Lambda-Funktionen. Funktionen werden in Containern innerhalb von Instanzen ausgeführt.
### Verwaltete Instanzen verstehen
Die Funktionen von Lambda Managed Instances werden auf verwalteten EC2-Instances in Ihrem Konto ausgeführt. Diese Instances werden vollständig von Lambda verwaltet, was bedeutet, dass Sie im Vergleich zu Standard-EC2-Instances eingeschränkte Berechtigungen für sie haben. Sie können Lambda Managed Instances in Ihrem Konto wie folgt identifizieren:
+ Das Vorhandensein des `Operator` Felds in der EC2-Ausgabe `DescribeInstances`
+ Das `aws:lambda:capacity-provider` Tag auf der Instanz
Sie können EC2-Standardoperationen nicht direkt auf diesen Instances ausführen, z. B. sie manuell beenden. Um verwaltete Instances zu löschen, löschen Sie den zugehörigen Kapazitätsanbieter. Lambda beendet dann die Instances im Rahmen des Löschvorgangs für den Kapazitätsanbieter.
## Preisgestaltung
Lambda Managed Instances verwendet EC2-basierte Preise mit einer Verwaltungsgebühr von 15% zusätzlich zu den Kosten für EC2-Instances. Dieses Preismodell unterstützt EC2-Sparpläne, Reserved Instances und alle anderen Preisnachlässe, die für Ihre EC2-Nutzung gelten. [Weitere Informationen finden Sie auf der Preisseite: Preise/ https://aws.amazon.com/lambda/](https://aws.amazon.com/lambda/pricing/)
**Wichtig:** EC2-Preisnachlässe gelten nur für die zugrunde liegende EC2-Rechenleistung, nicht für die Verwaltungsgebühr.
## Wie sich Lambda Managed Instances vom Compute-Typ Lambda (Standard) unterscheiden
Lambda Managed Instances ändert die Art und Weise, wie Lambda Anfragen verarbeitet, im Vergleich zu Lambda (Standard).
**Die wichtigsten Unterschiede:**
| | Lambda (Standard) | Von Lambda verwaltete Instances |
| --- | --- | --- |
| Parallelitätsmodell | Einzelnes Parallelitätsmodell, bei dem eine Ausführungsumgebung maximal einen Aufruf gleichzeitig unterstützen kann | Gleichzeitige Aufrufe, bei denen eine Ausführungsumgebung mehrere Aufrufe gleichzeitig verarbeiten kann, wodurch der Durchsatz insbesondere bei IO-intensiven Anwendungen erhöht wird |
| Mietverhältnis und Isolierung | Mehrmandantenfähig, wobei die Firecracker MicroVM-Technologie zur Isolierung zwischen Ausführungsumgebungen verwendet wird, die auf gemeinsam genutzten Lambda-Flotten ausgeführt werden | Führen Sie es in Ihrem Konto aus und verwenden Sie EC2 Nitro, um die Isolierung zu gewährleisten. Kapazitätsanbieter dienen als Sicherheitsgrenze, wobei Funktionen in Containern innerhalb von Instances ausgeführt werden |
| Preismodell | Preisgestaltung pro Anfrage und Dauer | Instanzbasierte Preisgestaltung mit EC2-Preismodellen, einschließlich On-Demand- und Reserved Instances, und Sparoptionen wie Compute Savings Plans |
| Skalierungsverhalten | Skaliert, wenn es keine freie Ausführungsumgebung für die Verarbeitung eines eingehenden Aufrufs gibt (Kaltstart). Skaliert ohne Verkehr auf Null | Skaliert asynchron nur basierend auf der CPU-Ressourcenauslastung, ohne Kaltstarts. Skaliert auf ein Minimum an Ausführungsumgebungen, die ohne Datenverkehr konfiguriert sind |
| Am besten geeignet für | Funktionen mit hohem Datenverkehr, die einige Kaltstartzeiten verkraften können, oder Anwendungen ohne Dauerlast, die von einer Skalierung auf Null profitieren | Vorhersagbares Datenvolumen funktioniert, wenn Sie die Flexibilität, die Preispläne und die Hardwareoptionen von EC2 nutzen möchten |
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ [Sicherheit und Berechtigungen für Lambda Managed Instances](lambda-managed-instances-security.md) verstehen
# Erste Schritte mit Lambda Managed Instances
## Eine Lambda Managed Instance-Funktion erstellen (Konsole)
Sie können die Lambda-Konsole verwenden, um eine Managed Instance-Funktion zu erstellen, die auf EC2 Amazon-Instances ausgeführt wird, die von einem Kapazitätsanbieter verwaltet werden.
**Wichtig:** Bevor Sie eine Managed Instance-Funktion erstellen, müssen Sie zunächst einen Kapazitätsanbieter erstellen. Für diese Funktionen ist ein Kapazitätsanbieter erforderlich, der die EC2 Amazon-Infrastruktur definiert, auf der Ihre Funktionen ausgeführt werden.
**So erstellen Sie eine Lambda Managed Instance-Funktion (Konsole)**
1. Öffnen Sie die Lambda-Konsole.
1. Wählen Sie im linken Navigationsbereich **Capacity Providers** aus.
1. Wählen Sie **Kapazitätsanbieter erstellen** aus.
1. Geben Sie im Abschnitt **Einstellungen für den Kapazitätsanbieter** einen Namen für Ihren Kapazitätsanbieter ein.
1. Wählen Sie VPC und Berechtigungen für Ihren Kapazitätsanbieter aus. Sie können entweder ein vorhandenes verwenden oder ein neues erstellen. Informationen zum Erstellen der erforderlichen Operatorrolle finden Sie unter [Lambda-Operatorrolle für Lambda Managed Instances](lambda-managed-instances-operator-role.md).
1. Erweiterten Sie **Advanced settings (Erweiterte Einstellungen)**.
1. Definieren Sie Ihre **Instance-Anforderungen**, indem Sie die Prozessorarchitektur und die Instance-Typen auswählen.
1. Geben Sie unter **Auto Scaling** die maximale Anzahl von EC2 v CPUs für Ihren Kapazitätsanbieter an. Sie können auch den **Modus Manuelle Instanzskalierung** wählen, um Ihren eigenen Skalierungswert für eine präzise Steuerung festzulegen.
1. Wählen Sie **Create Capacity Provider** aus, um einen neuen zu erstellen.
1. Wählen Sie **Create function**.
1. Wählen Sie **Verfassen von Grund auf** aus.
1. Geben Sie im Bereich **Grundinformationen** einen **Funktionsnamen** ein.
1. Wählen Sie für **Runtime** eine der unterstützten Runtimes aus.
1. Wählen Sie die **Architektur** für Ihre Funktion (dieselbe, die Sie für den Kapazitätsanbieter ausgewählt haben). Standardmäßig **x86\$164**.
1. **Stellen Sie unter **Berechtigungen** sicher, dass Sie über die Berechtigungen für die gewählte Ausführungsrolle verfügen.** Andernfalls können Sie eine neue Rolle erstellen.
1. Wählen Sie unter **Zusätzliche Konfigurationen** den **Compute-Typ** als **Lambda Managed Instances** aus.
1. Der Kapazitätsanbieter-ARN des Kapazitätsanbieters, den Sie in den vorherigen Schritten erstellt haben, sollte vorab ausgewählt sein.
1. Wählen Sie **Speichergröße** und **Verhältnis Arbeitsspeicher (GiB) pro vCPU** aus.
1. Wählen Sie **Funktion erstellen**.
Ihre Lambda Managed Instance-Funktion wird erstellt und stellt Kapazität auf Ihrem angegebenen Kapazitätsanbieter bereit. Die Erstellung von Funktionen dauert in der Regel mehrere Minuten. Sobald der Vorgang abgeschlossen ist, können Sie Ihren Funktionscode bearbeiten und Ihren ersten Test ausführen.
## Eine Lambda Managed Instance-Funktion (AWS CLI) erstellen
### Voraussetzungen
Stellen Sie vor dem Beginn sicher, dass Sie über das Folgende verfügen:
+ **AWS CLI** — Installieren und konfigurieren Sie die AWS CLI. Weitere Informationen finden Sie unter [Installation oder Aktualisierung der neuesten Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ **IAM-Berechtigungen** — Ihr IAM-Benutzer oder Ihre IAM-Rolle muss über Berechtigungen verfügen, um Lambda-Funktionen und Kapazitätsanbieter zu erstellen und IAM-Rollen zu übergeben. Beachten Sie, dass Sie auch angeben müssen, `iam:CreateServiceLinkedRole` ob Sie zum ersten Mal einen Kapazitätsanbieter für das Konto erstellen oder ob die Service Linked Role (SLR) gelöscht wurde.
### Schritt 1: Erstellen Sie die erforderlichen IAM-Rollen
Lambda Managed Instances erfordern zwei IAM-Rollen: eine Ausführungsrolle für Ihre Funktion und eine Operator-Rolle für den Kapazitätsanbieter. Die Operator-Rolle ermöglicht es Lambda, EC2 Amazon-Instances in Ihrem Namen zu starten, zu beenden und zu überwachen. Die Funktionsausführungsrolle gewährt der Funktion Berechtigungen für den Zugriff auf andere AWS Dienste und Ressourcen.
**So erstellen Sie die Lambda-Ausführungsrolle**
1. Erstellen Sie ein Dokument mit Vertrauensrichtlinien, das es Lambda ermöglicht, die Rolle zu übernehmen:
```
cat > lambda-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Erstellen Sie die Ausführungsrolle:
```
aws iam create-role \
--role-name MyLambdaExecutionRole \
--assume-role-policy-document file://lambda-trust-policy.json
```
1. Hängen Sie die grundlegende Ausführungsrichtlinie an:
```
aws iam attach-role-policy \
--role-name MyLambdaExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
**Um die Rolle des Kapazitätsanbieters als Betreiber zu erstellen**
1. Erstellen Sie ein Dokument mit Vertrauensrichtlinien, das es Lambda ermöglicht, die Operatorrolle zu übernehmen:
```
cat > operator-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. Erstellen Sie die Operatorrolle:
```
aws iam create-role \
--role-name MyCapacityProviderOperatorRole \
--assume-role-policy-document file://operator-trust-policy.json
```
1. Fügen Sie die erforderliche EC2 Berechtigungsrichtlinie bei:
```
aws iam attach-role-policy \
--role-name MyCapacityProviderOperatorRole \
--policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator
```
### Schritt 2: VPC-Ressourcen einrichten
Lambda Managed Instances werden in Ihrer VPC ausgeführt und benötigen ein Subnetz und eine Sicherheitsgruppe.
**Um VPC-Ressourcen zu erstellen**
1. Erstellen Sie eine VPC:
```
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--query 'Vpc.VpcId' \
--output text)
```
1. Erstellen Sie ein Subnetz:
```
SUBNET_ID=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--query 'Subnet.SubnetId' \
--output text)
```
1. Erstellen Sie eine Sicherheitsgruppe:
```
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)
```
**Hinweis:** Ihre Lambda Managed Instance-Funktionen erfordern eine VPC-Konfiguration, um auf Ressourcen außerhalb der VPC zuzugreifen und Telemetriedaten an Logs und X-Ray zu CloudWatch übertragen. Einzelheiten zur Konfiguration finden Sie unter [Networking for Lambda Managed Instances](lambda-managed-instances-networking.md).
### Schritt 3: Erstellen eines Kapazitätsanbieters
Ein Kapazitätsanbieter verwaltet die EC2 Instances, auf denen Ihre Lambda-Funktionen ausgeführt werden.
**Um einen Kapazitätsanbieter zu erstellen**
```
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
```
Dieser Befehl erstellt einen Kapazitätsanbieter mit der folgenden Konfiguration:
+ **VPC-Konfiguration** — Gibt das Subnetz und die Sicherheitsgruppe für die Instances an EC2
+ **Berechtigungen** — Definiert die IAM-Rolle, die Lambda zur Verwaltung von Instanzen verwendet EC2
+ **Instanzanforderungen** — Spezifiziert die x86\$164-Architektur
+ **Skalierungskonfiguration** — Legt ein Maximum von 30 V CPUs für den Kapazitätsanbieter fest
### Schritt 4: Erstellen Sie eine Lambda-Funktion mit Inline-Code
**Um eine Funktion mit Inline-Code zu erstellen**
1. Erstellen Sie zunächst eine einfache Python-Funktion und verpacken Sie sie inline:
```
# 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. Erstellen Sie die Lambda-Funktion mithilfe der Inline-ZIP-Datei:
```
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}
```
Die Funktion wird erstellt mit:
+ **Laufzeit** — Python 3.13
+ **Handler** — Die `lambda_handler` Funktion in `lambda_function.py`
+ **Speicher** — 2048 MB
+ **Kurzlebiger Speicher — 512 MB**
+ **Kapazitätsanbieter** — Links zu dem von Ihnen erstellten Kapazitätsanbieter
### Schritt 5: Veröffentlichen Sie eine Funktionsversion
Um Ihre Funktion auf Lambda Managed Instances auszuführen, müssen Sie eine Version veröffentlichen.
**Um eine Funktionsversion zu veröffentlichen**
```
aws lambda publish-version \
--function-name my-managed-instance-function
```
Dieser Befehl veröffentlicht Version 1 Ihrer Funktion und stellt sie für den Kapazitätsanbieter bereit.
### Schritt 6: Rufen Sie Ihre Funktion auf
Nach der Veröffentlichung können Sie Ihre Funktion aufrufen.
**Um Ihre Funktion aufzurufen**
```
aws lambda invoke \
--function-name my-managed-instance-function:1 \
--payload '{"name": "World"}' \
response.json
# View the response
cat response.json
```
Die Funktion wird auf den von Ihrem Kapazitätsanbieter verwalteten EC2 Instanzen ausgeführt und gibt eine Antwort zurück.
### Bereinigen
Um Gebühren zu vermeiden, löschen Sie die Ressourcen, die Sie erstellt haben:
1. Löschen Sie die Funktion:
```
aws lambda delete-function --function-name my-managed-instance-function
```
1. Löschen Sie den Kapazitätsanbieter:
```
aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider
```
1. Löschen Sie die VPC-Ressourcen:
```
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. Löschen Sie die IAM-Rollen:
```
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
```
# Schlüsselkonzepte
Lambda Managed Instances führt mehrere Kernkonzepte ein, die sich von herkömmlichen Lambda-Funktionen unterscheiden. Das Verständnis dieser Konzepte ist für die effektive Bereitstellung und Verwaltung Ihrer Funktionen in der EC2 Infrastruktur unerlässlich.
**Kapazitätsanbieter** bilden die Grundlage für Lambda Managed Instances. Ein Kapazitätsanbieter definiert die Recheninfrastruktur, in der Ihre Funktionen ausgeführt werden, einschließlich VPC-Konfiguration, Instanzanforderungen und Skalierungsrichtlinien. Kapazitätsanbieter dienen auch als Sicherheitsgrenze für Ihre Funktionen, was bedeutet, dass allen Funktionen, die demselben Kapazitätsanbieter zugewiesen sind, gegenseitig vertraut werden muss.
**Das Skalierungsverhalten** unterscheidet sich erheblich von herkömmlichen Lambda-Funktionen. Anstatt bei eingehenden Aufrufen nach Bedarf zu skalieren, skalieren Managed Instances asynchron auf der Grundlage der CPU-Ressourcennutzung. Dieser Ansatz macht Kaltstarts überflüssig, erfordert jedoch eine Planung für das Verkehrswachstum. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, da Lambda die Kapazität entsprechend der Nachfrage erhöht.
**Sicherheit und Berechtigungen müssen sorgfältig geprüft werden**. Sie benötigen Operator-Rollenberechtigungen, damit Lambda die EC2 Ressourcen Ihrer Kapazitätsanbieter verwalten kann. Darüber hinaus benötigen Benutzer die `lambda:PassCapacityProvider` Erlaubnis, Kapazitätsanbietern Funktionen zuzuweisen. Diese dienen als Sicherheitsschleuse, um zu kontrollieren, welche Funktionen auf einer bestimmten Infrastruktur ausgeführt werden können.
**Die gleichzeitige Ausführung mehrerer** Instanzen ist ein wesentliches Merkmal von Managed Instances. Jede Ausführungsumgebung kann mehrere Aufrufe gleichzeitig verarbeiten, wodurch die Ressourcennutzung für IO-intensive Anwendungen maximiert wird. Dies unterscheidet sich von herkömmlichem Lambda, bei dem jede Umgebung jeweils eine Anfrage verarbeitet. Dieses Ausführungsmodell erfordert, je nach Laufzeit, Aufmerksamkeit auf Thread-Sicherheit, Statusverwaltung und Kontextisolation.
Die folgenden Abschnitte enthalten detaillierte Informationen zu den einzelnen Kernkonzepten.
# Kapazitätsanbieter
Ein Kapazitätsanbieter ist die Grundlage für den Betrieb von Lambda Managed Instances. Es dient als Sicherheitsgrenze für Ihre Funktionen und definiert die Rechenressourcen, die Lambda in Ihrem Namen bereitstellt und verwaltet.
Wenn Sie einen Kapazitätsanbieter erstellen, geben Sie Folgendes an:
+ **VPC-Konfiguration** — Die Subnetze und Sicherheitsgruppen, in denen Instances ausgeführt werden
+ **Berechtigungen** — IAM-Rollen für Lambda zur Verwaltung von EC2-Ressourcen
+ **Instanzanforderungen** [(optional) — Einstellungen für Architektur und Instanztyp](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)
+ **Skalierungskonfiguration** (optional) — So skaliert Lambda Ihre Instances
## Kapazitätsanbieter als Sicherheitsgrenze verstehen
Kapazitätsanbieter dienen als Sicherheitsgrenze für Lambda-Funktionen innerhalb Ihrer VPC und ersetzen die Firecracker-basierte Isolierung. Funktionen werden in Containern innerhalb von Instances ausgeführt, aber Container bieten im Gegensatz zu Firecracker Micro keine starke Sicherheitsisolierung zwischen Funktionen. VMs
**Wichtige Sicherheitskonzepte:**
+ **Kapazitätsanbieter:** Die Sicherheitsgrenze, die Vertrauensstufen für Lambda-Funktionen definiert
+ **Container-Isolierung:** Container sind KEIN Sicherheitsanbieter — verlassen Sie sich nicht auf sie, wenn es um die Sicherheit zwischen nicht vertrauenswürdigen Workloads geht
+ **Vertrauenstrennung:** Trennen Sie Workloads, denen nicht gegenseitig vertraut wird, indem Sie unterschiedliche Kapazitätsanbieter verwenden
## Erstellen eines Kapazitätsanbieters
Sie können einen Kapazitätsanbieter mithilfe der AWS CLI, der AWS Management Console oder erstellen AWS SDKs.
**Verwenden von 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
```
### Erforderliche Parameter
**CapacityProviderName**
+ Ein eindeutiger Name für Ihren Kapazitätsanbieter
+ Muss innerhalb Ihres AWS Kontos eindeutig sein
**VpcConfig**
+ **SubnetIds**(erforderlich): Mindestens ein Subnetz, maximal 16. Verwenden Sie aus Gründen der Ausfallsicherheit Subnetze in mehreren Availability Zones
+ **SecurityGroupIds**(optional): Sicherheitsgruppen für Ihre Instances. Standardmäßig wird die VPC-Standardsicherheitsgruppe verwendet, falls nicht angegeben
**PermissionsConfig**
+ **CapacityProviderOperatorRoleArn**(erforderlich): IAM-Rolle, die es Lambda ermöglicht, EC2-Ressourcen in Ihrem Kapazitätsanbieter zu verwalten
### Optionale Parameter
**InstanceRequirements**
Geben Sie die Architektur und die [Instance-Typen](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) für Ihren Kapazitätsanbieter an:
+ **Architekturen**: Wählen Sie `x86_64` oder`arm64`. Die Standardeinstellung ist `x86_64`
+ **AllowedInstanceTypes**: Geben Sie die zulässigen Instanztypen an. Beispiel: `m5.8xlarge`
+ **ExcludedInstanceTypes**: Geben Sie ausgeschlossene Instanztypen mithilfe von Platzhaltern an. Sie können nur einen von AllowedInstanceTypes oder angeben ExcludedInstanceTypes
Standardmäßig wählt Lambda optimale Instance-Typen für Ihren Workload aus. Wir empfehlen, Lambda Managed Instances die Instanztypen für Sie auswählen zu lassen, da eine Einschränkung der Anzahl möglicher Instanztypen zu einer geringeren Verfügbarkeit führen kann.
**CapacityProviderScalingConfig**
Konfigurieren Sie, wie Lambda Ihre Instances skaliert:
+ **ScalingMode**: Auf `Auto` für automatische Skalierung oder `Manual` manuelle Steuerung einstellen. Die Standardeinstellung ist `Auto`
+ **Max VCpu Count**: Maximale Anzahl von v CPUs für den Kapazitätsanbieter. Die Standardeinstellung ist 400.
+ **ScalingPolicies**: Definieren Sie Skalierungsrichtlinien für die Zielverfolgung für die CPU- und Speicherauslastung
**KmsKeyArn**
Geben Sie einen AWS KMS Schlüssel für die EBS-Verschlüsselung an. Standardmäßig wird der AWS verwaltete Schlüssel verwendet, falls nicht angegeben.
**Tags**
Fügen Sie Tags hinzu, um Ihre Kapazitätsanbieter zu organisieren und zu verwalten.
## Verwaltung von Kapazitätsanbietern
### Aktualisieren eines Kapazitätsanbieters
Sie können bestimmte Eigenschaften eines Kapazitätsanbieters mithilfe der `UpdateCapacityProvider` API aktualisieren.
```
aws lambda update-capacity-provider \
--capacity-provider-name my-capacity-provider \
--capacity-provider-scaling-config ScalingMode=Auto
```
### Löschen eines Kapazitätsanbieters
Mithilfe der `DeleteCapacityProvider` API können Sie einen Kapazitätsanbieter löschen, wenn er nicht mehr benötigt wird.
```
aws lambda delete-capacity-provider \
--capacity-provider-name my-capacity-provider
```
**Hinweis:** Sie können keinen Kapazitätsanbieter löschen, an den Funktionsversionen angehängt sind.
### Details zum Kapazitätsanbieter anzeigen
Rufen Sie mithilfe der `GetCapacityProvider` API Informationen über einen Kapazitätsanbieter ab.
```
aws lambda get-capacity-provider \
--capacity-provider-name my-capacity-provider
```
## Staaten des Kapazitätsanbieters
Ein Kapazitätsanbieter kann sich in einem der folgenden Staaten befinden:
+ **Ausstehend**: Der Kapazitätsanbieter wird gerade erstellt
+ **Aktiv**: Der Kapazitätsanbieter ist einsatzbereit
+ **Fehlgeschlagen**: Die Erstellung des Kapazitätsanbieters ist fehlgeschlagen
+ **Löschen**: Der Kapazitätsanbieter wird gelöscht
## Kontingente
+ **Maximale Kapazitätsanbieter pro Konto**: 1.000
+ **Maximale Funktionsversionen pro Kapazitätsanbieter**: 100 (kann nicht erhöht werden)
## Best Practices
1. **Nach Vertrauensstufe trennen**: Erstellen Sie verschiedene Kapazitätsanbieter für Workloads mit unterschiedlichen Sicherheitsanforderungen
1. **Verwenden Sie aussagekräftige Namen**: Benennen Sie Kapazitätsanbieter, um deren Verwendungszweck und Vertrauensstufe eindeutig anzugeben (z. B.,,`production-trusted`) `dev-sandbox`
1. **Verwenden Sie mehrere Availability Zones**: Geben Sie Subnetze über mehrere an, um eine hohe Verfügbarkeit AZs zu gewährleisten
1. **Lassen Sie Lambda Instance-Typen wählen**: Sofern Sie keine spezifischen Hardwareanforderungen haben, erlauben Sie Lambda, die für die Verfügbarkeit optimalen Instance-Typen auszuwählen
1. **Nutzung überwachen: Wird** verwendet AWS CloudTrail , um die Zuweisungen und Zugriffsmuster von Kapazitätsanbietern zu überwachen
## Nächste Schritte
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
+ [Sicherheit und Berechtigungen für Lambda Managed Instances](lambda-managed-instances-security.md) verstehen
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
# Skalierung von verwalteten Lambda-Instanzen
Lambda Managed Instances skaliert nicht, wenn Aufrufe eintreffen, und unterstützt keine Kaltstarts. Stattdessen wird es asynchron mithilfe von Signalen zum Ressourcenverbrauch skaliert. Managed Instances wird derzeit auf der Grundlage der CPU-Ressourcenauslastung und der Auslastung mehrerer Parallelitäten skaliert.
**Die wichtigsten Unterschiede:**
+ **Lambda (Standard):** Skaliert, wenn es keine freie Ausführungsumgebung für die Verarbeitung eines eingehenden Aufrufs gibt (Kaltstart)
+ **Lambda Managed Instances:** Skaliert asynchron auf der Grundlage der CPU-Ressourcenauslastung und der Mehrparallelität von Ausführungsumgebungen
Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, wenn Lambda Instances und Ausführungsumgebungen entsprechend der Nachfrage skaliert.
## Der Skalierungslebenszyklus
Lambda Managed Instances verwendet eine verteilte Architektur, um die Skalierung zu verwalten:
**Komponenten:**
+ **Verwaltete Instanzen** — Werden in Ihrem Konto in den von Ihnen bereitgestellten Subnetzen ausgeführt
+ **Router and Scaler** — Gemeinsam genutzte Lambda-Komponenten, die Aufrufe weiterleiten und die Skalierung verwalten
+ **Lambda Agent — Wird** auf jeder verwalteten Instanz ausgeführt, um den Lebenszyklus der Ausführungsumgebung zu verwalten und den Ressourcenverbrauch zu überwachen
**So funktioniert es:**
1. Wenn Sie eine Funktionsversion mit einem Kapazitätsanbieter veröffentlichen, startet Lambda Managed Instances in Ihrem Konto. Aus Gründen der AZ-Resilienz werden standardmäßig drei und drei Ausführungsumgebungen gestartet, bevor Ihre Funktionsversion als AKTIV markiert wird.
1. Jede verwaltete Instanz kann Ausführungsumgebungen für mehrere Funktionen ausführen, die demselben Kapazitätsanbieter zugeordnet sind.
1. Wenn der Datenverkehr in Ihre Anwendung fließt, verbrauchen Ausführungsumgebungen Ressourcen. Der Lambda-Agent benachrichtigt den Scaler, der entscheidet, ob neue Ausführungsumgebungen oder verwaltete Instances skaliert werden sollen.
1. Wenn der Router versucht, einen Aufruf an eine Ausführungsumgebung mit hohem Ressourcenverbrauch zu senden, benachrichtigt ihn der Lambda-Agent auf dieser Instanz, es auf einer anderen erneut zu versuchen.
1. Wenn der Traffic abnimmt, benachrichtigt der Lambda Agent den Scaler, der entscheidet, die Ausführungsumgebungen herunterzufahren und in verwalteten Instanzen zu skalieren.
## Anpassung des Skalierungsverhaltens
Sie können das Skalierungsverhalten von Managed Instances mithilfe von vier Steuerelementen anpassen:
### Steuerungen auf Funktionsebene
#### 1. Funktionsspeicher und v CPUs
Wählen Sie die Speichergröße und die vCPU-Zuweisung für Ihre Funktion. Die kleinste unterstützte Funktionsgröße ist 2 GB und 1 vCPU.
**Überlegungen**:
+ Wählen Sie eine Speicher- und vCPU-Einstellung, die mehrere gleichzeitige Ausführungen Ihrer Funktion unterstützt
+ Sie können keine Funktion mit weniger als 1 vCPU konfigurieren, da Funktionen, die auf verwalteten Instances ausgeführt werden, mehrere gleichzeitige Workloads unterstützen sollten
+ Sie können nicht weniger als 2 GB wählen, da dies dem Verhältnis von 2 zu 1 Arbeitsspeicher zu vCPU von c Instances entspricht, die das niedrigste Verhältnis aufweisen.
+ Für Python-Anwendungen müssen Sie möglicherweise ein höheres Verhältnis von Speicher zu V wählenCPUs, z. B. 4 zu 1 oder 8 zu 1, da Python Multiparallelität handhabt
+ Wenn Sie CPU-intensive Operationen ausführen oder wenig I/O ausführen, sollten Sie mehr als eine vCPU wählen
#### 2. Maximale Parallelität
Legen Sie die maximale Parallelität pro Ausführungsumgebung fest.
**Standardverhalten:** Lambda wählt sinnvolle Standardwerte, die den Ressourcenverbrauch und den Durchsatz in Einklang bringen und für eine Vielzahl von Anwendungen geeignet sind.
**Richtlinien für Anpassungen:**
+ **Erhöhen Sie die Parallelität:** Wenn Ihre Funktionsaufrufen nur sehr wenig CPU verbrauchen, können Sie die maximale Parallelität auf maximal 64 pro vCPU erhöhen
+ **Gleichzeitigkeit verringern: Wenn Ihre Anwendung viel Arbeitsspeicher und sehr wenig CPU beansprucht, können Sie die maximale Parallelität** reduzieren
**Wichtig:** Da Lambda Managed Instances für Anwendungen mit mehreren gleichzeitigen Vorgängen konzipiert sind, kann es in Ausführungsumgebungen mit sehr geringer Parallelität zu Drosselungen bei der Skalierung kommen.
### Kontrollen auf Ebene des Kapazitätsanbieters
#### 3. Nutzung der Zielressourcen
Wählen Sie Ihr eigenes Ziel für den CPU-Nutzungsverbrauch.
**Standardverhalten:** Lambda behält genügend Headroom bei, sodass sich Ihr Traffic ohne Drosselungen innerhalb von 5 Minuten verdoppeln kann.
**Optimierungsoptionen:**
+ Wenn Ihre Arbeitslast sehr konstant ist oder wenn Ihre Anwendung nicht empfindlich auf Drosselungen reagiert, können Sie das Ziel auf ein hohes Niveau setzen, um eine höhere Auslastung und niedrigere Kosten zu erreichen
+ Wenn Sie genügend Spielraum für hohe Datenmengen haben möchten, können Sie die Ressourcenziele auf ein niedriges Niveau setzen, was wiederum mehr Kapazität erfordert
#### 4. Auswahl des Instance-Typs
Legen Sie zulässige oder ausgeschlossene Instance-Typen fest.
**Standardverhalten:** Lambda wählt die besten Instance-Typen für Ihren Workload aus. Wir empfehlen, Lambda Managed Instances die Instanztypen für Sie auswählen zu lassen, da eine Einschränkung der Anzahl möglicher Instanztypen zu einer geringeren Verfügbarkeit führen kann.
**Benutzerdefinierte Konfiguration:**
+ **Spezifische Hardwareanforderungen:** Legen Sie für zulässige Instanztypen eine Liste kompatibler Instanzen fest. Wenn Sie beispielsweise eine Anwendung haben, die eine hohe Netzwerkbandbreite benötigt, können Sie mehrere n-Instance-Typen auswählen
+ **Kostenoptimierung:** Für Test- oder Entwicklungsumgebungen können Sie kleinere Instance-Typen wie m7a.large-Instance-Typen wählen
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ Lesen Sie die laufzeitspezifischen Anleitungen zum Umgang mit Mehrfachparallelität
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ Überwachen Sie Skalierungskennzahlen, um das Skalierungsverhalten zu optimieren
# Sicherheit und Berechtigungen
Lambda Managed Instances verwenden **Kapazitätsanbieter als Vertrauensgrenzen**. Funktionen werden in Containern innerhalb dieser Instanzen ausgeführt, aber Container bieten keine Sicherheitsisolierung zwischen Workloads. Alle Funktionen, die demselben Kapazitätsanbieter zugewiesen sind, müssen gegenseitig vertrauenswürdig sein.
## Wichtige Sicherheitskonzepte
+ **Kapazitätsanbieter**: Die Sicherheitsgrenze, die Vertrauensstufen für Lambda-Funktionen definiert
+ **Container-Isolierung**: Container stellen keine Sicherheitsgrenze dar. Verlassen Sie sich nicht auf sie, wenn es um die Sicherheit zwischen nicht vertrauenswürdigen Workloads geht
+ **Vertrauenstrennung**: Trennen Sie Workloads, denen nicht gegenseitig vertraut wird, indem Sie unterschiedliche Kapazitätsanbieter verwenden
## Erforderliche Berechtigungen
### PassCapacityProvider Aktion
Benutzer benötigen die `lambda:PassCapacityProvider` Erlaubnis, Kapazitätsanbietern Funktionen zuzuweisen. Diese Genehmigung dient als Sicherheitsschleuse und stellt sicher, dass nur autorisierte Benutzer Funktionen bestimmten Kapazitätsanbietern zuweisen können.
Kontoadministratoren kontrollieren über die `lambda:PassCapacityProvider` IAM-Aktion, welche Funktionen bestimmte Kapazitätsanbieter nutzen können. Diese Aktion ist erforderlich, wenn:
+ Funktionen erstellen, die Lambda Managed Instances verwenden
+ Aktualisierung von Funktionskonfigurationen zur Verwendung eines Kapazitätsanbieters
+ Bereitstellung von Funktionen über die Infrastruktur als Code
**Beispiel für eine IAM-Richtlinie**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:PassCapacityProvider",
"Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*"
}
]
}
```
### Serviceverknüpfte Rolle
AWS Lambda verwendet die `AWSServiceRoleForLambda` serviceverknüpfte Rolle, um die ec2-Ressourcen von Lambda Managed Instances bei Ihren Kapazitätsanbietern zu verwalten.
## Bewährte Methoden
1. **Nach Vertrauensstufe trennen**: Erstellen Sie verschiedene Kapazitätsanbieter für Workloads mit unterschiedlichen Sicherheitsanforderungen
1. **Verwenden Sie aussagekräftige Namen**: Benennen Sie Kapazitätsanbieter, um deren Verwendungszweck und Vertrauensstufe eindeutig anzugeben (z. B.,,`production-trusted`) `dev-sandbox`
1. **Least Privilege anwenden**: Erteilen Sie `PassCapacityProvider` Berechtigungen nur für die erforderlichen Kapazitätsanbieter
1. **Nutzung überwachen**: Wird verwendet AWS CloudTrail , um die Zuweisungen und Zugriffsmuster von Kapazitätsanbietern zu überwachen
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
# Lambda-Operatorrolle für Lambda Managed Instances
Wenn Sie Lambda Managed Instances verwenden, benötigt Lambda Berechtigungen zur Verwaltung der Rechenkapazität in Ihrem Konto. Die Operatorrolle stellt diese Berechtigungen über IAM-Richtlinien bereit, die es Lambda ermöglichen, EC2 Instanzen im Kapazitätsanbieter zu verwalten.
Lambda übernimmt bei der Ausführung dieser Verwaltungsvorgänge die Operatorrolle, ähnlich wie Lambda eine Ausführungsrolle übernimmt, wenn Ihre Funktion ausgeführt wird.
## Eine Operatorrolle erstellen
Sie können eine Operatorrolle in der IAM-Konsole oder mit der AWS CLI erstellen. Die Rolle muss Folgendes beinhalten:
+ **Berechtigungsrichtlinie** — Erteilt Berechtigungen zur Verwaltung von Kapazitätsanbietern und zugehörigen Ressourcen
+ **Vertrauensrichtlinie** — Ermöglicht dem Lambda-Dienst (`lambda.amazonaws.com`), die Rolle zu übernehmen
### Berechtigungsrichtlinie
Die Operatorrolle benötigt Berechtigungen zur Verwaltung von Kapazitätsanbietern und den zugrunde liegenden Rechenressourcen. Für die Rolle sind mindestens die Berechtigungen erforderlich, die in der [AWSLambdaEC2ResourceOperatorverwalteten](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator) Richtlinie enthalten sind. Derzeit gilt Folgendes:
```
{
"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"
}
}
}
]
}
```
### Vertrauensrichtlinie
Die Vertrauensrichtlinie ermöglicht es Lambda, die Betreiberrolle zu übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Serviceverknüpfte Rolle für verwaltete Lambda-Instances
Um den Lebenszyklus von Lambda Managed Instances verantwortungsbewusst zu verwalten, benötigt Lambda dauerhaften Zugriff, um verwaltete Instanzen in Ihrem Konto zu beenden. Lambda verwendet eine dienstgebundene Rolle (SLR) für AWS Identity and Access Management (IAM), um diese Operationen auszuführen.
**Automatische Erstellung**: Die serviceverknüpfte Rolle wird automatisch erstellt, wenn Sie zum ersten Mal einen Kapazitätsanbieter erstellen. Der Benutzer, der den ersten Kapazitätsanbieter erstellt, muss über die `iam:CreateServiceLinkedRole` Berechtigung für den `lambda.amazonaws.com` Prinzipal verfügen.
**Berechtigungen**: Die serviceverknüpfte Rolle gewährt Lambda die folgenden Berechtigungen für verwaltete Instanzen:
+ `ec2:TerminateInstances`— Um Instanzen am Ende ihres Lebenszyklus zu beenden
+ `ec2:DescribeInstances`— Um verwaltete Instanzen aufzuzählen
**Löschung**: Sie können diese serviceverknüpfte Rolle erst löschen, nachdem Sie alle Kapazitätsanbieter für Lambda Managed Instances in Ihrem Konto gelöscht haben.
Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Verwenden von serviceverknüpften Rollen für Lambda](using-service-linked-roles.md).
# Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances
Lambda Managed Instances bieten ein alternatives Bereitstellungsmodell, bei dem Ihr Funktionscode auf kundeneigenen EC2 Amazon-Instances ausgeführt wird, während Lambda die betrieblichen Aspekte verwaltet. Die Ausführungsumgebung für Managed Instances weist mehrere wichtige Unterschiede zu Lambda-Funktionen (Standard) auf, insbesondere darin, wie sie gleichzeitige Aufrufe verarbeitet und Container-Lebenszyklen verwaltet.
**Hinweis:** Informationen zur Lambda-Ausführungsumgebung (Standard) finden Sie unter Grundlegendes zum Lebenszyklus der Lambda-Ausführungsumgebung.
## Lebenszyklus der Ausführungsumgebung
Der Lebenszyklus einer Funktionsausführungsumgebung für Lambda Managed Instances unterscheidet sich in mehreren wesentlichen Punkten von Lambda (Standard):
### Init-Phase
Während der Init-Phase führt Lambda die folgenden Schritte aus:
+ Initialisieren und registrieren Sie alle Erweiterungen
+ Bootstrap für den Laufzeit-Einstiegspunkt. Runtime erzeugt die konfigurierte Anzahl von Runtime-Workern (die Implementierung hängt von der Laufzeit ab)
+ Führen Sie den Initialisierungscode der Funktion aus (Code außerhalb des Handlers)
+ Warten Sie, bis mindestens ein Runtime-Worker die Bereitschaft signalisiert, indem er aufruft `/runtime/invocation/next`
Die Init-Phase gilt als abgeschlossen, wenn die Erweiterungen initialisiert wurden und mindestens ein Runtime-Worker aufgerufen hat. `/runtime/invocation/next` Die Funktion ist dann bereit, Aufrufe zu verarbeiten.
**Anmerkung**
Für Funktionen von Lambda Managed Instances kann die Initialisierung bis zu 15 Minuten dauern. Das Timeout ist das Maximum von 130 Sekunden oder das konfigurierte Funktions-Timeout (bis zu 900 Sekunden).
### Invoke-Phase
Die Aufrufphase für Funktionen von Lambda Managed Instances weist mehrere einzigartige Merkmale auf:
**Kontinuierlicher Betrieb.** Im Gegensatz zu Lambda (Standard) bleibt die Ausführungsumgebung kontinuierlich aktiv und verarbeitet eingehende Aufrufe, ohne dass sie zwischen den Aufrufen einfrieren.
**Parallele Verarbeitung.** In derselben Ausführungsumgebung können mehrere Aufrufe gleichzeitig ausgeführt werden, wobei jeder Aufruf von einem anderen Runtime-Worker verarbeitet wird.
**Unabhängige Timeouts.** Das konfigurierte Timeout der Funktion gilt für jeden einzelnen Aufruf. Wenn bei einem Aufruf eine Zeitüberschreitung eintritt, markiert Lambda diesen bestimmten Aufruf als fehlgeschlagen, unterbricht jedoch keine anderen laufenden Aufrufe und beendet die Ausführungsumgebung nicht.
**Behandlung von Gegendruck.** Wenn alle Runtime-Worker mit der Verarbeitung von Aufrufen beschäftigt sind, werden neue Aufrufanforderungen zurückgewiesen, bis ein Worker verfügbar ist.
## Fehlerbehandlung und Wiederherstellung
Die Fehlerbehandlung in Umgebungen zur Funktionsausführung von Lambda Managed Instances unterscheidet sich von Lambda (Standard):
**Timeouts aufrufen.** Wenn bei einem einzelnen Aufruf das Timeout überschritten wird, gibt Lambda einen Timeout-Fehler für diesen Aufruf zurück. Lambda Managed Instances erzwingt das Timeout jedoch nicht — Ihr Code wird weiter ausgeführt. Als Funktionsentwickler sind Sie dafür verantwortlich, das Timeout zu erkennen und zu behandeln. Das Kontextobjekt gibt die verbleibende Zeit für den Aufruf an, wobei ein Nullwert oder ein negativer Wert auf ein Timeout hinweist. Andere gleichzeitige Aufrufe in der Ausführungsumgebung setzen die Verarbeitung normal fort.
**Fehler beim Runtime-Worker.** Wenn ein Runtime-Worker-Prozess abstürzt, arbeitet die Ausführungsumgebung mit den verbleibenden fehlerfreien Workern weiter.
**Die Erweiterung stürzt ab.** Wenn ein Erweiterungsprozess während der Initialisierung oder des Betriebs abstürzt, wird die gesamte Ausführungsumgebung als fehlerhaft markiert und beendet. Lambda erstellt eine neue Ausführungsumgebung, um sie zu ersetzen.
**Kein Reset/Reparieren.** Im Gegensatz zu Lambda (Standard) versuchen Managed Instances nicht, die Ausführungsumgebung nach Fehlern zurückzusetzen und neu zu initialisieren. Stattdessen werden fehlerhafte Container beendet und durch neue ersetzt.
# \$1LATEST.PUBLISHED Version in Lambda Managed Instances
Die Funktionen von Lambda Managed Instances unterstützen denselben nummerierten Versionierungsworkflow wie Lambda (Standard). Wenn Sie es vorziehen, keine nummerierten Versionen zu verwalten, führt Lambda Managed Instances einen neuen Versionstyp ein:`$LATEST.PUBLISHED`. Mit dieser Version können Sie nach Bedarf eine neueste veröffentlichte Version mit aktualisiertem Code oder aktualisierter Konfiguration erstellen oder erneut veröffentlichen, ohne nummerierte Versionen verwalten zu müssen.
**Hauptunterschied zu \$1LATEST:** Wenn Sie eine Lambda Managed Instances-Funktion mit einem unqualifizierten ARN aufrufen, ruft Lambda implizit die Version und nicht die unveröffentlichte `$LATEST.PUBLISHED` \$1LATEST-Version auf.
Der folgende AWS CLI-Befehl erstellt oder veröffentlicht die `$LATEST.PUBLISHED` Version erneut.
```
aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED
```
Die Ausgabe sollte folgendermaßen aussehen:
```
{
"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",
...
}
```
**Anmerkung**
Wenn Sie die Lambda-Konsole verwenden AWS CloudFormation , um eine Lambda Managed Instances-Funktion zu erstellen, erstellt Lambda die Version automatisch. `$LATEST.PUBLISHED`
# Laufzeiten von Lambda Managed Instances
Lambda verarbeitet Anfragen anders, wenn Lambda Managed Instances verwendet werden. Anstatt Anfragen nacheinander in jeder Ausführungsumgebung zu bearbeiten, verarbeiten Lambda Managed Instances mehrere Anfragen gleichzeitig in jeder Ausführungsumgebung. Diese Änderung des Ausführungsmodells bedeutet, dass Funktionen, die Lambda Managed Instances verwenden, Thread-Sicherheit, Statusverwaltung und Kontextisolation berücksichtigen müssen — Aspekte, die im Lambda-Modell (Standard) mit nur einer Parallelität nicht auftreten. Darüber hinaus variiert die Implementierung mehrerer Parallelitäten je nach Laufzeit.
## Unterstützte Sprachen
Lambda Managed Instances können mit den folgenden Programmiersprachen und Laufzeiten verwendet werden:
+ **Java:** Java 21 und höher.
+ **Python:** Python 3.13 und höher.
+ **Node.js:** Node.js 22 und höher.
+ **.NET:** .NET 8 und höher.
+ **Rust: Wird** mit der reinen Betriebssystem-Runtime `provided.al2023` und höher unterstützt.
## Sprachspezifische Überlegungen
Jede Programmiersprache implementiert Multiparallelität unterschiedlich. Sie müssen verstehen, wie Multiparallelität in der von Ihnen gewählten Programmiersprache implementiert wird, um die entsprechenden Best Practices für Parallelität anwenden zu können.
**Java**
Verwendet einen einzigen Prozess mit Betriebssystem-Threads für Parallelität. Mehrere Threads führen die Handler-Methode gleichzeitig aus, was eine threadsichere Behandlung von Status- und gemeinsam genutzten Ressourcen erfordert.
**Python**
Verwendet mehrere Python-Prozesse, bei denen jede gleichzeitige Anforderung in einem separaten Prozess ausgeführt wird. Dies schützt vor den meisten Parallelitätsproblemen, obwohl bei gemeinsam genutzten Ressourcen wie dem `/tmp` Verzeichnis Vorsicht geboten ist.
**Node.js**
Verwendet [Worker-Threads](https://nodejs.org/api/worker_threads.html) mit asynchroner Ausführung. Gleichzeitige Anfragen werden über Worker-Threads verteilt, und jeder Worker-Thread kann gleichzeitige Anfragen auch asynchron verarbeiten, was eine sichere Handhabung von Status- und gemeinsam genutzten Ressourcen erfordert.
**.NET**
Verwendet .NET-Aufgaben mit asynchroner Verarbeitung mehrerer gleichzeitiger Anfragen. Erfordert den sicheren Umgang mit staatlichen und gemeinsam genutzten Ressourcen.
**Rust**
Verwendet einen einzigen Prozess mit asynchronen Aufgaben, die von [Tokio](https://tokio.rs/) unterstützt werden. Der Handler muss \$1 sein. `Clone` `Send`
## Nächste Schritte
Ausführliche Informationen zu den einzelnen Laufzeitumgebungen finden Sie in den folgenden Themen:
+ [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ [Laufzeit von Node.js für verwaltete Lambda-Instanzen](lambda-managed-instances-nodejs-runtime.md)
+ [Python-Laufzeit für verwaltete Lambda-Instanzen](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für verwaltete Lambda-Instanzen](lambda-managed-instances-dotnet-runtime.md)
+ [Rust-Unterstützung für Lambda Managed Instances](lambda-managed-instances-rust.md)
# Java-Laufzeit für Lambda Managed Instances
Für Java-Laufzeiten verwenden Lambda Managed Instances Betriebssystem-Threads für Parallelität. Lambda lädt Ihr Handler-Objekt während der Initialisierung einmal pro Ausführungsumgebung und erstellt dann mehrere Threads. Diese Threads werden parallel ausgeführt und erfordern eine threadsichere Behandlung von Status- und gemeinsam genutzten Ressourcen. Jeder Thread verwendet dasselbe Handler-Objekt und alle statischen Felder.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Java-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Threads, die von der Java-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Runtime-Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status threadsicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung.
**Beispiel: Datenbank-Verbindungspools**
Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von Threads gemeinsam genutzt wird. Abhängig von der verwendeten Verbindungsbibliothek ist dies möglicherweise nicht threadsicher.
```
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();
}
}
```
Ein threadsicherer Ansatz besteht darin, einen Verbindungspool zu verwenden. Im folgenden Beispiel ruft der Funktionshandler eine Verbindung aus dem Pool ab. Die Verbindung wird nur im Kontext einer einzelnen Anfrage verwendet.
```
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();
}
}
```
**Beispiel: Sammlungen**
Standard-Java-Sammlungen sind nicht threadsicher:
```
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";
}
}
```
Verwenden Sie stattdessen Thread-sichere Sammlungen:
```
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";
}
}
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Thread oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.
Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `LambdaLogger` Objekt aus `context.getLogger()` verwenden, `requestId` ist es automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit Java](java-logging.md#java-logging-advanced).
## Kontext anfordern
Das `context` Objekt ist an den Anforderungsthread gebunden. `context.getAwsRequestId()`Die Verwendung ermöglicht einen threadsicheren Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.
Wird verwendet`context.getXrayTraceId()`, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen threadsicheren Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Wenn Sie in Ihrem Programm virtuelle Threads verwenden oder während der Initialisierung Threads erstellen, müssen Sie den erforderlichen Anforderungskontext an diese Threads übergeben.
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Threads gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ AWS SDK for Java 2.0: Version 2.34.0 oder höher
+ AWS X-Ray SDK for Java: Version 2.20.0 oder höher
+ AWS Distribution für OpenTelemetry — Instrumentation für Java: Version 2.20.0 oder höher
+ Powertools für AWS Lambda (Java): Version 2.8.0 oder höher
## Powertools für AWS Lambda (Java)
Powertools for AWS Lambda (Java) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java).
## Nächste Schritte
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Laufzeit von Node.js für verwaltete Lambda-Instanzen
Für Laufzeiten von Node.js verwendet Lambda Managed Instances Worker-Threads mit`async`/`await`-basierter Ausführung, um gleichzeitige Anfragen zu verarbeiten. Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Gleichzeitige Aufrufe werden in zwei Dimensionen verarbeitet: Worker-Threads sorgen für Parallelität in VCPUs, und asynchrone Ausführung sorgt für Parallelität innerhalb jedes Threads. Jede gleichzeitige Anforderung, die von demselben Worker-Thread bearbeitet wird, verwendet dasselbe Handler-Objekt und denselben globalen Status, sodass eine sichere Behandlung bei mehreren gleichzeitigen Anfragen erforderlich ist.
## Maximale Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Laufzeiten von Node.js sind standardmäßig 64 gleichzeitige Anfragen pro vCPU festgelegt, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
Für Node.js wird die Anzahl der gleichzeitigen Anfragen, die jede Ausführungsumgebung verarbeiten kann, durch die Anzahl der Worker-Threads und die Kapazität jedes Worker-Threads bestimmt, gleichzeitige Anfragen asynchron zu verarbeiten. Die Standardanzahl von Worker-Threads wird durch die Anzahl der CPUs verfügbaren V bestimmt. Sie können die Anzahl der Worker-Threads auch konfigurieren, indem Sie die `AWS_LAMBDA_NODEJS_WORKER_COUNT` Umgebungsvariable festlegen. Wir empfehlen die Verwendung von asynchronen Funktionshandlern, da dies die Verarbeitung mehrerer Anfragen pro Worker-Thread ermöglicht. Wenn Ihr Funktionshandler synchron ist, kann jeder Worker-Thread jeweils nur eine einzelne Anfrage verarbeiten.
## Funktionen für Mehrfachparallelität erstellen
Mit einem asynchronen Funktionshandler verarbeitet jeder Runtime-Worker mehrere Anfragen gleichzeitig. Globale Objekte werden von mehreren gleichzeitigen Anfragen gemeinsam genutzt. Vermeiden Sie bei veränderlichen Objekten die Verwendung von global state or use. `AsyncLocalStorage`
AWS SDK-Clients sind asynchron-sicher und erfordern keine besondere Behandlung.
**Beispiel: Globaler Status**
Der folgende Code verwendet ein globales Objekt, das innerhalb des Funktionshandlers mutiert ist. Das ist nicht asynchron-sicher.
```
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 };
};
```
Durch die Initialisierung des `state` Objekts innerhalb des Funktionshandlers wird ein gemeinsamer globaler Status vermieden.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Beispiel: Datenbankverbindungen**
Der folgende Code verwendet ein gemeinsames Client-Objekt, das von mehreren Aufrufen gemeinsam genutzt wird. Je nach verwendeter Verbindungsbibliothek ist dies möglicherweise nicht sicher für Parallelität.
```
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])
};
};
```
Ein Ansatz, der die Parallelität sicherstellt, besteht darin, einen Verbindungspool zu verwenden. Der Pool verwendet für jede gleichzeitige Datenbankabfrage eine separate Verbindung.
```
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])
};
};
```
## Node.js 22 Callback-basierte Handler
Wenn Sie Node.js 22 verwenden, können Sie keinen Callback-basierten Funktionshandler mit Lambda Managed Instances verwenden. Callback-basierte Handler werden nur für Lambda-Funktionen (Standard) unterstützt. Für Laufzeiten von Node.js 24 und höher sind Callback-basierte Funktionshandler sowohl für Lambda (Standard) als auch für Lambda Managed Instances veraltet.
Verwenden Sie stattdessen einen `async` Funktionshandler, wenn Sie Lambda Managed Instances verwenden. Weitere Informationen finden Sie unter [Definieren des Lambda-Funktionshandlers in Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge einer einzelnen Anfrage zugeordnet werden können. Wenn Sie den `console` Logger verwenden, `requestId` ist er automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit Node.js](nodejs-logging.md#node-js-logging-advanced).
Beliebte Protokollierungsbibliotheken von Drittanbietern, wie [Winston](https://github.com/winstonjs/winston), unterstützen in der Regel die Verwendung der Konsole für die Protokollausgabe.
## Kontext anfordern
`context.awsRequestId`Die Verwendung ermöglicht einen asynchronen Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.
Wird verwendet`context.xRayTraceId`, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`context.getRemainingTimeInMillis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Lambda-Funktionen (Standard) mit Erweiterungen können das SIGTERM-Signal auch abonnieren, indem `process.on()` Dies wird für Funktionen, die Lambda Managed Instances verwenden, nicht unterstützt, da es `process.on()` nicht mit Worker-Threads verwendet werden kann. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ AWS SDK für JavaScript v3: Version 3.933.0 oder höher
+ AWS X-Ray SDK für Node.js: Version 3.12.0 oder höher
+ AWS Distribution für OpenTelemetry — Instrumentierung für JavaScript: Version 0.8.0 oder höher
+ Powertools für AWS Lambda (TypeScript): Version 2.29.0 oder höher
## Elektrowerkzeuge für AWS Lambda () TypeScript
Powertools for AWS Lambda (TypeScript) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda () TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript).
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Python-Laufzeit für verwaltete Lambda-Instanzen
Die Lambda-Laufzeit verwendet mehrere Python-Prozesse, um gleichzeitige Anfragen zu verarbeiten. Jede gleichzeitige Anforderung wird in einem separaten Prozess mit eigenem Speicherplatz und eigener Initialisierung ausgeführt. Jeder Prozess verarbeitet synchron jeweils eine Anfrage. Prozesse teilen sich den Speicher nicht direkt, sodass globale Variablen, Caches auf Modulebene und Singleton-Objekte zwischen gleichzeitigen Anfragen isoliert werden.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Python-Laufzeiten ist die Standardeinstellung 16 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Prozesse, die von der Python-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
**Wichtig**
Die Verwendung prozessbasierter Parallelität bedeutet, dass jeder Runtime-Worker-Prozess seine eigene Initialisierung durchführt. Die gesamte Speicherbelegung entspricht dem Arbeitsspeicher pro Prozess multipliziert mit der Anzahl gleichzeitiger Prozesse. Wenn Sie große Bibliotheken oder Datensätze laden und über eine hohe Parallelität verfügen, haben Sie einen großen Speicherbedarf. Je nach Arbeitslast müssen Sie möglicherweise Ihr CPU-to-memory Verhältnis anpassen oder eine niedrigere Parallelitätseinstellung verwenden, um eine Überschreitung des verfügbaren Speichers zu vermeiden. Sie können die `MemoryUtilization` Metrik verwenden CloudWatch , um den Speicherverbrauch zu verfolgen.
## Erstellung von Funktionen für mehrere Parallelitäten
Aufgrund des prozessbasierten Multi-Concurrency-Modells greifen Lambda Managed Instances-Funktionen, die Python-Laufzeiten verwenden, bei mehreren Aufrufen nicht gleichzeitig auf speicherinterne Ressourcen zu. Sie müssen keine Codierungspraktiken anwenden, um die Sicherheit der Parallelität im Speicher zu gewährleisten.
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Prozess oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.
Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `logging` Modul aus der Python-Standardbibliothek in Lambda verwenden, `requestId` ist das automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter [Erweiterte Lambda-Protokollierungssteuerelemente mit Python verwenden](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Kontext anfordern
Wird verwendet`context.aws_request_id`, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Bei Python-Laufzeiten können Sie die `_X_AMZN_TRACE_ID` Umgebungsvariable verwenden, um mit Lambda Managed Instances auf die X-Ray-Trace-ID zuzugreifen. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`context.get_remaining_time_in_millis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Initialisierung der Funktion erfolgt einmal pro Prozess. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ Powertools für AWS Lambda (Python): Version 3.23.0 oder höher
## Powertools für AWS Lambda (Python)
Powertools for AWS Lambda (Python) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# .NET-Laufzeit für verwaltete Lambda-Instanzen
Für .NET-Laufzeiten verwenden Lambda Managed Instances einen einzigen .NET-Prozess pro Ausführungsumgebung. Mithilfe von.NET-Aufgaben werden mehrere Anfragen gleichzeitig verarbeitet.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für .NET-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Sicherheitspraktiken für Parallelität anwenden wie in jeder anderen Umgebung mit mehreren gleichzeitigen Vorgängen. Da das Handler-Objekt von allen Tasks gemeinsam genutzt wird, muss jeder veränderbare Status Thread-sicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung.
**Beispiel: Datenbank-Verbindungspools**
Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von mehreren gleichzeitigen Anfragen gemeinsam genutzt wird. Das `SqlConnection` Objekt ist nicht threadsicher.
```
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();
...
}
}
```
Um dieses Problem zu lösen, verwenden Sie für jede Anfrage eine separate Verbindung, die aus einem Verbindungspool stammt. ADO.NET-Anbieter unterstützen beispielsweise `Microsoft.Data.SqlClient` automatisch das Verbindungspooling, wenn das Verbindungsobjekt geöffnet wird.
```
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();
...
}
}
```
**Beispiel: Sammlungen**
Standard-.NET-Sammlungen sind nicht threadsicher:
```
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";
}
}
```
Verwenden Sie aus Sicherheitsgründen Sammlungen aus dem `System.Collections.Concurrent` Namespace:
```
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";
}
}
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn eine andere Anforderung die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `context.Logger` Objekt zum Generieren von Protokollen verwenden, `requestId` wird es automatisch in jeden Protokolleintrag aufgenommen. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit .NET](csharp-logging.md#csharp-logging-advanced).
## Kontext anfordern
Verwenden Sie die `context.AwsRequestId` Eigenschaft, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Verwenden Sie die `context.TraceId` Eigenschaft, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`ILambdaContext.RemainingTime`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Für Lambda Managed Instances sind die folgenden Mindestpaketversionen erforderlich:
+ Amazon.Lambda.Core: Version 2.7.1 oder höher
+ Amazon.Lambda. RuntimeSupport: Version 1.14.1 oder höher
+ OpenTelemetry. Instrumentierung. AWSLambda: Version 1.14.0 oder höher
+ AWSXRayRecorder.Core: Version 2.16.0 oder höher
+ AWSSDK.Core: Version 4.0.0.32 oder höher
## Powertools für AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) und [AWS Distro for OpenTelemetry - Instrumentation for](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) unterstützen DotNet derzeit keine Lambda Managed Instances.
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Rust-Unterstützung für Lambda Managed Instances
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert für Rust ist 8 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt die Anzahl der Tokio-Aufgaben, die von der Laufzeit ausgelöst werden, und ist für die gesamte Lebensdauer der Ausführungsumgebung statisch. Jeder Worker bearbeitet jeweils genau eine In-Flight-Anfrage, ohne Multiplexing pro Mitarbeiter. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status Thread-sicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
Um die gleichzeitige Bearbeitung von Anfragen zu aktivieren, fügen Sie Ihrer `Cargo.toml` Datei das `concurrency-tokio` Feature-Flag hinzu.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
Der `lambda_runtime::run_concurrent(…)` Einstiegspunkt muss innerhalb einer Tokio-Laufzeit aufgerufen werden, die in der Regel durch das `#[tokio::main]` Attribut Ihrer Hauptfunktion bereitgestellt wird. Ihr Handler-Closure muss \$1 implementieren [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html). [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html) Auf diese Weise kann das Framework Ihren Handler sicher für mehrere asynchrone Aufgaben gemeinsam nutzen. Wenn diese Grenzen nicht eingehalten werden, wird Ihr Code nicht kompiliert.
Wenn Sie einen gemeinsamen Status für mehrere Aufrufe benötigen (einen Datenbankpool, eine Konfigurationsstruktur), binden Sie ihn ein [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)und klonen Sie ihn in jeden Aufruf. `Arc`
Alle AWS SDKs für Rust-Clients sind konkurrenzsicher und erfordern keine besondere Behandlung.
### Beispiel: SDK-Client AWS
Im folgenden Beispiel wird ein S3-Client verwendet, um bei jedem Aufruf ein Objekt hochzuladen. Der Client wird direkt in die Closure geklont, ohne: `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
```
### Beispiel: Datenbank-Verbindungspools
Wenn Ihr Handler Zugriff auf einen gemeinsamen Status wie einen Client und eine Konfiguration benötigt, binden Sie ihn ein [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)und klonen Sie ihn `Arc` in jeden Aufruf:
```
#[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
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Aufrufen in derselben Ausführungsumgebung gemeinsam genutzt. Verwenden Sie eindeutige Dateinamen pro Aufruf (geben Sie z. B. die Anforderungs-ID an) oder implementieren Sie explizite Dateisperren, um Datenbeschädigungen zu vermeiden.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist in Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, unterstützen das strukturierte JSON-Protokollformat über die [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) von Lambda. Dieses Format beinhaltet das`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Weitere Informationen finden Sie unter[Implementierung der erweiterten Protokollierung mit der Tracing Crate](rust-logging.md#rust-logging-tracing).
## Kontext anfordern
Das `Context` Objekt wird direkt an jeden Handler-Aufruf übergeben. Wird verwendet`event.context.request_id`, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Wird verwendet`event.context.xray_trace_id`, um auf die X-Ray-Trace-ID zuzugreifen. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird automatisch weitergegeben, wenn das AWS SDK für Rust verwendet wird.
Wird verwendet`event.context.deadline`, um Timeouts zu erkennen — sie enthält die Frist für den Aufruf in Millisekunden.
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. `lambda_runtime`bietet ein Hilfsprogramm zur Vereinfachung der Konfiguration der Signalverarbeitung bei ordnungsgemäßem Herunterfahren,. [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) Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgende Mindestpaketversion:
+ `lambda_runtime`: Version 1.1.1 oder höher, mit aktivierter Funktion `concurrency-tokio`
+ Die unterstützte Mindestversion von Rust (MSRV) ist 1.84.0.
# Netzwerke für Lambda Managed Instances
Wenn Sie Funktionen von Lambda Managed Instances ausführen, müssen Sie die Netzwerkkonnektivität konfigurieren, damit Ihre Funktionen auf Ressourcen außerhalb der VPC zugreifen können. Dazu gehören AWS Dienste wie Amazon S3 und DynamoDB. Die Konnektivität wird auch für die Übertragung von Telemetriedaten an CloudWatch Logs und X-Ray benötigt.
## Verbindungsoptionen
Es gibt drei Hauptansätze für die Konfiguration der VPC-Konnektivität, die jeweils unterschiedliche Kompromisse in Bezug auf Kosten, Sicherheit und Komplexität beinhalten.
## Öffentliches Subnetz mit einem Internet-Gateway
Diese Option verwendet ein öffentliches Subnetz mit direktem Internetzugang über ein Internet-Gateway. Sie können zwischen IPv4 und IPv6 Konfigurationen wählen.
### IPv4 mit Internet-Gateway
**Um die IPv4 Konnektivität mit einem Internet-Gateway zu konfigurieren**
1. Erstellen oder verwenden Sie ein vorhandenes öffentliches Subnetz mit einem IPv4 CIDR-Block.
1. Hinzufügen eines Internet-Gateways zu Ihrer VPC.
1. Aktualisieren Sie die Routing-Tabelle, um den `0.0.0.0/0` Verkehr an das Internet-Gateway weiterzuleiten.
1. Stellen Sie sicher, dass den Ressourcen öffentliche IPv4 Adressen oder Elastic IP-Adressen zugewiesen sind.
1. Konfigurieren Sie Sicherheitsgruppen so, dass ausgehender Datenverkehr auf den erforderlichen Ports zugelassen wird.
Diese Konfiguration bietet bidirektionale Konnektivität und ermöglicht sowohl ausgehende Verbindungen von Ihren Funktionen als auch eingehende Verbindungen aus dem Internet.
### IPv6 mit Internet-Gateway
**Um die IPv6 Konnektivität mit einem Internet-Gateway zu konfigurieren**
1. Aktivieren Sie es IPv6 auf Ihrer VPC.
1. Erstellen oder verwenden Sie ein vorhandenes öffentliches Subnetz, dem ein IPv6 CIDR-Block zugewiesen wurde.
1. Schließen Sie ein Internet-Gateway an Ihre VPC an (dasselbe Internet-Gateway kann IPv4 sowohl als auch verarbeiten IPv6).
1. Aktualisieren Sie die Routentabelle, um den `::/0` Verkehr an das Internet-Gateway weiterzuleiten.
1. Vergewissern Sie sich, dass die AWS Dienste, die Sie für den Zugriff auf den Support IPv6 in Ihrer Region benötigen, vorhanden sind.
1. Konfigurieren Sie Sicherheitsgruppen so, dass ausgehender Datenverkehr an den erforderlichen Ports zugelassen wird.
Diese Konfiguration bietet bidirektionale Konnektivität mithilfe von IPv6 Adressierung.
### IPv6 mit Internet-Gateway nur für ausgehenden Datenverkehr
**So konfigurieren Sie die IPv6 Konnektivität mit einem Internet-Gateway nur für ausgehenden Datenverkehr**
1. Aktivieren Sie es IPv6 auf Ihrer VPC.
1. Erstellen oder verwenden Sie ein vorhandenes öffentliches Subnetz, dem ein IPv6 CIDR-Block zugewiesen wurde.
1. Schließen Sie ein Internet-Gateway nur für ausgehenden Datenverkehr an Ihre VPC an.
1. Aktualisieren Sie die Routing-Tabelle, um den Datenverkehr an das Internet-Gateway weiterzuleiten, das `::/0` nur für ausgehenden Verkehr bestimmt ist.
1. Vergewissern Sie sich, dass die AWS Dienste, die Sie für den Zugriff auf den Support IPv6 in Ihrer Region benötigen, vorhanden sind.
1. Konfigurieren Sie Sicherheitsgruppen so, dass ausgehender Datenverkehr an den erforderlichen Ports zugelassen wird.
Diese Konfiguration bietet nur ausgehende Konnektivität, wodurch eingehende Verbindungen aus dem Internet verhindert werden, während Ihre Funktionen ausgehende Verbindungen initiieren können.
## VPC-Endpunkte
VPC-Endpunkte ermöglichen es Ihnen, Ihre VPC privat mit unterstützten AWS Diensten zu verbinden, ohne dass ein Internet-Gateway, ein NAT-Gerät, eine VPN-Verbindung oder eine AWS Direct Connect-Verbindung erforderlich ist. Der Verkehr zwischen Ihrer VPC und dem AWS Service verlässt das Amazon-Netzwerk nicht.
**So konfigurieren Sie VPC-Endpoints**
1. Öffnen Sie die Amazon VPC-Konsole unter [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich **Endpunkte** aus.
1. Wählen Sie **Endpunkt erstellen** aus.
1. Wählen Sie bei **Service category** (Servicekategorie) die Option **AWS services** (-Services) aus.
1. Wählen Sie **unter Service-Name** den Service-Endpunkt aus, den Sie benötigen (z. B. `com.amazonaws.region.s3` für Amazon S3).
1. Wählen Sie im Feld **VPC** Ihre VPC aus.
1. Wählen Sie für **Subnetze** die Subnetze aus, in denen Sie Endpunkt-Netzwerkschnittstellen erstellen möchten. Wählen Sie für eine hohe Verfügbarkeit Subnetze in mehreren Availability Zones aus.
1. Wählen Sie für Sicherheitsgruppen die Sicherheitsgruppen aus, die den **Security groups** (Endpunkt-Netzwerkschnittstellen) zugeordnet werden sollen. Die Sicherheitsgruppen müssen eingehenden Datenverkehr von der Sicherheitsgruppe Ihrer Funktion an den erforderlichen Ports zulassen.
1. Wählen Sie **Endpunkt erstellen** aus.
Wiederholen Sie diese Schritte für jeden AWS Dienst, auf den Ihre Funktionen zugreifen müssen.
## Privates Subnetz mit NAT-Gateway
Diese Option verwendet ein NAT-Gateway, um den Internetzugang für Ressourcen in privaten Subnetzen bereitzustellen und gleichzeitig die Ressourcen privat zu halten.
**Um ein privates Subnetz mit einem NAT-Gateway zu konfigurieren**
1. Erstellen Sie ein öffentliches Subnetz (falls noch keines vorhanden ist) mit einem CIDR-Block.
1. Hinzufügen eines Internet-Gateways zu Ihrer VPC.
1. Erstellen Sie ein NAT-Gateway im öffentlichen Subnetz und weisen Sie eine Elastic IP-Adresse zu.
1. Aktualisieren Sie die Routing-Tabelle des öffentlichen Subnetzes, um eine Route hinzuzufügen: `0.0.0.0/0` → Internet-Gateway.
1. Erstellen oder verwenden Sie ein vorhandenes privates Subnetz mit einem CIDR-Block.
1. Aktualisieren Sie die Routentabelle des privaten Subnetzes, um eine Route hinzuzufügen: `0.0.0.0/0` → NAT-Gateway.
1. Konfigurieren Sie Sicherheitsgruppen so, dass ausgehender Verkehr an den erforderlichen Ports zugelassen wird.
Stellen Sie für hohe Verfügbarkeit ein NAT-Gateway in jeder Availability Zone bereit und konfigurieren Sie Routing-Tabellen pro Availability Zone, um das lokale NAT-Gateway zu verwenden. Dadurch werden AZ-übergreifende Datenübertragungsgebühren vermieden und die Ausfallsicherheit verbessert.
## Auswahl einer Konnektivitätsoption
Berücksichtigen Sie bei der Auswahl einer Konnektivitätsoption die folgenden Faktoren:
**Öffentliches Subnetz mit Internet-Gateway**
+ Einfachste Konfiguration mit niedrigsten Kosten
+ Geeignet für Entwicklungs- und Testumgebungen
+ Ressourcen können eingehende Verbindungen aus dem Internet empfangen (aus Sicherheitsgründen)
+ Unterstützt sowohl als IPv4 IPv6
**VPC-Endpunkte**
+ Höchste Sicherheit, der Verkehr bleibt im AWS Netzwerk
+ Geringere Latenz im Vergleich zum Internet-Routing
+ Empfohlen für Produktionsumgebungen mit strengen Sicherheitsanforderungen
+ Höhere Kosten pro Endpunkt, pro Availability Zone und pro verarbeitetem GB
+ Für hohe Verfügbarkeit ist in jeder Availability Zone ein Endpunkt erforderlich
**Privates Subnetz mit NAT-Gateway**
+ Ressourcen bleiben privat, wenn kein eingehender Internetzugang besteht
+ Standardmuster für Unternehmensarchitekturen
+ Unterstützt den gesamten IPv4 Internetverkehr
+ Moderate Kosten mit Stunden- und Datenverarbeitungsgebühren für das NAT-Gateway
+ Unterstützt IPv4 nur
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ [Sicherheit und Berechtigungen für Lambda Managed Instances](lambda-managed-instances-security.md) verstehen
# Überwachung von Lambda-verwalteten Instanzen
Sie können Lambda Managed Instances mithilfe von CloudWatch Metriken überwachen. Lambda veröffentlicht automatisch Kennzahlen, mit denen CloudWatch Sie die Ressourcennutzung überwachen, Kosten verfolgen und die Leistung optimieren können.
## Verfügbare Metriken
Lambda Managed Instances bietet Metriken auf zwei Ebenen: auf Ebene des Kapazitätsanbieters und auf Ebene der Ausführungsumgebung.
### Metriken auf Ebene des Kapazitätsanbieters
Kennzahlen auf Ebene des Kapazitätsanbieters bieten Einblick in die allgemeine Ressourcenauslastung Ihrer Instances. Diese Metriken verwenden die folgenden Dimensionen:
+ **CapacityProviderName**- Der Name Ihres Kapazitätsanbieters
+ **InstanceType**— Der EC2-Instance-Typ
**Kennzahlen zur Ressourcennutzung:**
+ **CPUUtilization**- Der Prozentsatz der CPU-Auslastung aller Instanzen im Kapazitätsanbieter
+ **MemoryUtilization**- Der Prozentsatz der Speicherauslastung für alle Instanzen im Kapazitätsanbieter
**Kapazitätskennzahlen:**
+ **v CPUAvailable** — Die Menge an vCPUs, die auf Instances für die Zuweisung verfügbar ist (in Anzahl)
+ **MemoryAvailable**— Die Menge an Arbeitsspeicher, die auf Instances für die Zuweisung verfügbar ist (in Byte)
+ **v CPUAllocated** — Die Menge an vCPUs, die Instanzen für Ausführungsumgebungen zugewiesen sind (in Anzahl)
+ **MemoryAllocated**— Die Menge an Speicher, die Instanzen für Ausführungsumgebungen zugewiesen wurde (in Byte)
### Metriken auf Ausführungsumgebungsebene
Metriken auf der Ebene der Ausführungsumgebung bieten Einblick in die Ressourcennutzung und Parallelität einzelner Funktionen. Diese Metriken verwenden die folgenden Dimensionen:
+ **CapacityProviderName**- Der Name Ihres Kapazitätsanbieters
+ **FunctionName**- Der Name Ihrer Lambda-Funktion
+ **Ressource** — Zeigen Sie Metriken für eine bestimmte Version einer Funktion nach Ressource an.
**Anmerkung**
Für Lambda Managed Instances (LMI) unterstützt die `Resource` Dimension nur Funktionsversionen. Das Format ist `:`.
**Verfügbare Metriken der Ausführungsumgebung:**
+ **ExecutionEnvironmentConcurrency**- Die maximale Parallelität über einen Probenzeitraum von 5 Minuten
+ **ExecutionEnvironmentConcurrencyLimit**— Das maximale Parallelitätslimit pro Ausführungsumgebung
+ **ExecutionEnvironmentCPUUtilization**— Der Prozentsatz der CPU-Auslastung für die Ausführungsumgebungen der Funktion
+ **ExecutionEnvironmentMemoryUtilization**- Der Prozentsatz der Speicherauslastung für die Ausführungsumgebungen der Funktion
## Metrische Häufigkeit und Retention
Die Metriken für Lambda Managed Instances werden in Intervallen von 5 Minuten veröffentlicht und 15 Monate lang aufbewahrt.
## Metriken anzeigen in CloudWatch
**So zeigen Sie Metriken für Lambda Managed Instances in der Konsole an CloudWatch **
1. Öffnen Sie die CloudWatch Konsole unter [console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie auf der Registerkarte **Alle Metriken** die Option **AWS/Lambda** aus.
1. Wählen Sie die metrische Dimension aus, die Sie anzeigen möchten:
+ Filtern Sie für Kennzahlen auf Ebene des Kapazitätsanbieters nach **CapacityProviderName**und **InstanceType**
+ Filtern Sie für Metriken auf Ausführungsumgebungsebene nach **CapacityProviderName**FunctionName****, und **Ressource**
1. Wählen Sie die Metriken aus, die Sie überwachen möchten.
## Verwenden von Metriken zur Leistungsoptimierung
Überwachen Sie die CPU- und Speicherauslastung, um festzustellen, ob Ihre Funktionen richtig dimensioniert sind. Eine hohe Auslastung kann darauf hindeuten, dass größere Instance-Typen oder eine größere Zuweisung von Funktionsspeicher erforderlich sind. Verfolgen Sie Parallelitätskennzahlen, um das Skalierungsverhalten zu verstehen und mögliche Drosselungen zu identifizieren.
Überwachen Sie die Kapazitätskennzahlen, um sicherzustellen, dass genügend Ressourcen für Ihre Workloads verfügbar sind. Anhand von **V CPUAvailable** und **MemoryAvailable**Metriken können Sie die verbleibende Kapazität Ihrer Instances ermitteln.
## Nächste Schritte
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ [Sicherheit und Berechtigungen für Lambda Managed Instances](lambda-managed-instances-security.md) verstehen
# Kontingente für Lambda Managed Instances
Auf dieser Seite werden die Dienstkontingente für AWS Lambda Managed Instances beschrieben. Diese Kontingente sind von AWS Lambda-Kontingenten (Standard) getrennt. Einige Kontingente können auf Anfrage erhöht werden.
## Lambda-API-Anforderungskontingente
Diese Kontingente steuern die Geschwindigkeit, mit der Sie API-Aufrufe tätigen können, um Kapazitätsanbieter für Lambda Managed Instances zu verwalten. Die API-Lese- und Schreibratenbegrenzungen gelten für alle Kapazitätsanbieteroperationen zusammen, einschließlich der Erstellung, Aktualisierung, Beschreibung und Löschung von Kapazitätsanbietern.
| Ressource | Kontingent |
| --- | --- |
| Die maximale kombinierte Rate (Anfragen pro Sekunde) für alle Lesevorgänge von Kapazitätsanbietern APIs | 15 Anforderungen pro Sekunde. Kann nicht erhöht werden. |
| Die maximale kombinierte Rate (Anfragen pro Sekunde) für alle Schreibvorgänge des Kapazitätsanbieters APIs | 1 Anfrage pro Sekunde. Kann nicht erhöht werden. |
## Ressourcenkontingente für Lambda Managed Instances
Diese Kontingente definieren die Grenzwerte für die Kernressourcen von Lambda Managed Instances in Ihrem AWS Konto. Sie regeln die Anzahl der Kapazitätsanbieter, die Sie erstellen können, und die Anzahl der Funktionsversionen, die jedem Kapazitätsanbieter zugeordnet werden können.
| Ressource | Kontingent |
| --- | --- |
| Kapazitätsanbieter | 1.000. Die maximale Anzahl von Kapazitätsanbietern, die in einem Konto erstellt wurden. |
| Funktionsversionen pro Kapazitätsanbieter | 100. Die maximale Anzahl von Funktionsversionen pro Kapazitätsanbieter. Kann nicht erhöht werden. |
## Kontingente für die Zuordnung von Ereignisquellen
Diese Kontingente steuern den Durchsatz und die Konfigurationslimits für die Verarbeitung von Ereignissen verschiedener AWS Dienste auf Lambda Managed Instances. Die Durchsatzgrenzen sorgen für eine vorhersehbare Leistung, während die Grenzwerte für die Anzahl der Zuordnungen zur Aufrechterhaltung der Servicestabilität beitragen. Zuordnungen von Ereignisquellen auf Lambda Managed Instances unterstützen Amazon SQS, DynamoDB Streams, Amazon Kinesis Data Streams, Amazon MSK und selbstverwaltetes Apache Kafka als Ereignisquellen.
| Ressource | Kontingent |
| --- | --- |
| Standarddurchsatz für die Zuordnung von SQS-Ereignisquellen auf Lambda Managed Instances | 5 MB pro Sekunde. Kann nicht erhöht werden. |
| Standarddurchsatz für die Zuordnung von Kafka-Ereignisquellen auf Lambda Managed Instances | 1 MB pro Sekunde. Kann nicht erhöht werden. |
| Standard-Kafka-Ereignisquellenzuordnungen auf Lambda Managed Instances | 100 Zuordnungen von Ereignisquellen. Kann nicht erhöht werden. |
| Durchsatz der Kinesis-Ereignisquellenzuordnung auf Lambda Managed Instances | 25 MB pro Sekunde. Kann erhöht werden. |
| Durchsatz für die Zuordnung von DynamoDB-Ereignisquellen auf Lambda Managed Instances | 10 MB pro Sekunde. Kann erhöht werden. |
| Rufen Sie den Anforderungsdurchsatz für asynchrone Aufrufe auf Lambda Managed Instances auf | 5 MB pro Sekunde. Kann erhöht werden. |
## Beantragen einer Kontingenterhöhung
Für Kontingente, die erhöht werden können, können Sie eine Erhöhung über die Service Quotas Quotas-Konsole beantragen.
**So fordern Sie eine Kontingenterhöhung an**
1. Öffnen Sie die Service Quotas Quotas-Konsole unter [console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
1. Wählen Sie im Navigationsbereich **AWS -Services**.
1. Wählen Sie **AWS Lambda**.
1. Wählen Sie das Kontingent aus, das Sie erhöhen möchten.
1. Wählen Sie **Kontingenterhöhung anfordern**.
1. Geben Sie den neuen Kontingentwert ein und begründen Sie die Erhöhung.
1. Wählen Sie **Anfrage** aus.
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
# Bewährte Methoden für Lambda Managed Instances
## Kapazitätsanbieter-Konfiguration
**Separate Kapazitätsanbieter nach Vertrauensstufe.** Erstellen Sie verschiedene Kapazitätsanbieter für Workloads mit unterschiedlichen Sicherheitsanforderungen. Alle Funktionen, die demselben Kapazitätsanbieter zugewiesen sind, müssen gegenseitig vertrauenswürdig sein, da Kapazitätsanbieter als Sicherheitsgrenze dienen.
**Verwenden Sie aussagekräftige Namen.** Benennen Sie Kapazitätsanbieter, um deren Verwendungszweck und Vertrauensstufe eindeutig anzugeben (z. B.`production-trusted`,`dev-sandbox`). Dies hilft den Teams, den Zweck und die Sicherheitslage der einzelnen Kapazitätsanbieter zu verstehen.
**Verwenden Sie mehrere Availability Zones.** Geben Sie bei der Erstellung von Kapazitätsanbietern Subnetze für mehrere Availability Zones an. Lambda startet aus Gründen der AZ-Resilienz standardmäßig drei Instances und gewährleistet so eine hohe Verfügbarkeit Ihrer Funktionen.
## Auswahl des Instance-Typs
**Lassen Sie Lambda die Instanztypen auswählen.** Standardmäßig wählt Lambda die besten Instance-Typen für Ihren Workload aus. Wir empfehlen, Lambda Managed Instances die Instanztypen für Sie auswählen zu lassen, da eine Einschränkung der Anzahl möglicher Instanztypen zu einer geringeren Verfügbarkeit führen kann.
**Geben Sie Instanztypen für bestimmte Anforderungen an.** Wenn Sie bestimmte Hardwareanforderungen haben, legen Sie für zulässige Instanztypen eine Liste kompatibler Instanzen fest. Beispiel:
+ Wählen Sie für Anwendungen, die eine hohe Netzwerkbandbreite erfordern, mehrere n-Instance-Typen aus
+ Wählen Sie für Test- oder Entwicklungsumgebungen mit Kostenbeschränkungen kleinere Instance-Typen wie m7a.large
## Konfiguration der Funktionen
**Wählen Sie die entsprechenden Speicher- und vCPU-Einstellungen.** Wählen Sie Speicher- und vCPU-Konfigurationen aus, die mehrere gleichzeitige Ausführungen Ihrer Funktion unterstützen. Die unterstützte Mindestfunktionsgröße beträgt 2 GB und 1 vCPU.
+ Wählen Sie für Python-Anwendungen ein höheres Verhältnis von Speicher zu V CPUs (z. B. 4 zu 1 oder 8 zu 1), da Python Multiparallelität so handhabt
+ Wählen Sie für CPU-intensive Operationen oder Funktionen mit wenig I/O mehr als eine vCPU
+ Für IO-intensive Anwendungen wie Webservices oder Batch-Jobs bietet die Mehrfachparallelität den größten Vorteil
**Konfigurieren Sie die maximale Parallelität entsprechend.** Lambda wählt vernünftige Standardwerte für maximale Parallelität, die den Ressourcenverbrauch und den Durchsatz in Einklang bringen. Passen Sie diese Einstellung an die Ressourcennutzung Ihrer Funktion an:
+ Erhöhen Sie die maximale Parallelität (bis zu 64 pro vCPU), wenn Ihre Funktionsaufrufe nur sehr wenig CPU verbrauchen
+ Verringern Sie die maximale Parallelität, wenn Ihre Anwendung viel Speicher und sehr wenig CPU beansprucht
Beachten Sie, dass in Ausführungsumgebungen mit sehr geringer Parallelität Drosselungen und Skalierungsschwierigkeiten auftreten können.
## Skalierungskonfiguration
**Stellen Sie die entsprechende Zielressourcennutzung ein.** Standardmäßig bietet Lambda genügend Spielraum, sodass sich Ihr Traffic ohne Drosselungen innerhalb von 5 Minuten verdoppeln kann. Passen Sie dies an Ihre Workload-Merkmale an:
+ Bei sehr gleichbleibenden Workloads oder Anwendungen, die nicht empfindlich auf Drosselungen reagieren, sollten Sie das Ziel auf einen hohen Wert setzen, um eine höhere Auslastung und niedrigere Kosten zu erreichen
+ Setzen Sie sich bei Workloads mit potenziellen Datenverkehrsspitzen niedrige Ressourcenziele, um zusätzlichen Spielraum zu haben
**Planen Sie das Verkehrswachstum ein.** Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, wenn Lambda Instances und Ausführungsumgebungen skaliert. Entwerfen Sie Ihre Anwendung so, dass sie mit potenzieller Drosselung in Phasen schneller Skalierung umgehen kann.
## Sicherheit
**Wenden Sie die geringsten Rechte für Berechtigungen an. PassCapacityProvider ** Erteilen `lambda:PassCapacityProvider` Sie Berechtigungen nur für die erforderlichen Kapazitätsanbieter. Verwenden Sie Berechtigungen auf Ressourcenebene, um einzuschränken, welche Kapazitätsanbieter Benutzer Funktionen zuweisen können.
**Überwachen Sie die Nutzung von Kapazitätsanbietern.** Wird verwendet AWS CloudTrail , um die Zuweisungen und Zugriffsmuster von Kapazitätsanbietern zu überwachen. Dies hilft bei der Identifizierung unberechtigter Zugriffsversuche und gewährleistet die Einhaltung von Sicherheitsrichtlinien.
**Trennen Sie nicht vertrauenswürdige Workloads.** Verlassen Sie sich bei der Sicherheitsisolierung zwischen nicht vertrauenswürdigen Workloads nicht auf Container. Verwenden Sie verschiedene Kapazitätsanbieter, um Workloads zu trennen, denen nicht gegenseitig vertraut wird.
## Kostenoptimierung
**Nutzen Sie die EC2-Preisoptionen.** Nutzen Sie EC2-Sparpläne und Reserved Instances, um die Kosten zu senken. Diese Preisoptionen gelten für die zugrunde liegende EC2-Rechenleistung (die Verwaltungsgebühr von 15% wird nicht rabattiert).
**Optimieren Sie für stationäre Workloads.** Lambda Managed Instances eignen sich am besten für Steady-State-Funktionen mit vorhersehbarem hohem Verkehrsaufkommen. Bei stark frequentierten Datenverkehrsmustern kann Lambda (Standard) kostengünstiger sein.
**Überwachen Sie die Ressourcennutzung.** Verfolgen Sie CloudWatch Metriken, um die CPU- und Speicherauslastung zu verstehen. Passen Sie die Funktionsspeicherzuweisung und die Auswahl des Instanztyps an die tatsächlichen Nutzungsmuster an, um die Kosten zu optimieren.
## Überwachung und Beobachtbarkeit
**Überwachen Sie die Kennzahlen der Kapazitätsanbieter.** Verfolgen Sie Kennzahlen auf Ebene der Kapazitätsanbieter CPUUtilization, einschließlich MemoryUtilization,CPUAvailable, v und, MemoryAvailable um sicherzustellen, dass genügend Ressourcen für Ihre Workloads verfügbar sind.
**Überwachen Sie die Kennzahlen der Ausführungsumgebung.** Verfolgen Sie Metriken auf der Ebene der Ausführungsumgebung, einschließlich ExecutionEnvironmentConcurrency und ExecutionEnvironmentConcurrencyLimit um das Skalierungsverhalten zu verstehen und mögliche Drosselungen zu identifizieren.
**Richten Sie Alarme ein. CloudWatch ** Erstellen Sie CloudWatch Alarme für wichtige Kennzahlen, um Probleme proaktiv zu identifizieren:
+ Hohe CPU- oder Speicherauslastung
+ Niedrige verfügbare Kapazität
+ Wir nähern uns den Grenzwerten für Parallelität
## Sprachspezifische Überlegungen
**Folgen Sie den sprachspezifischen Best Practices.** Jede Programmiersprache behandelt Multiparallelität unterschiedlich. Ausführliche Empfehlungen finden Sie in den sprachspezifischen Leitfäden:
+ **Java:** Verwenden Sie Thread-sichere Collections und für anforderungsspezifische `AtomicInteger` Status `ThreadLocal`
+ **Node.js: Wird** InvokeStore für alle anforderungsspezifischen Zustände verwendet und globale Variablen vermieden
+ **Python:** Verwenden Sie eindeutige Dateinamen in der `/tmp` Anfrage IDs und ziehen Sie die prozessbasierte Speicherisolierung in Betracht
+ **Rust:** Verwenden Sie `run_concurrent` statt`run`, wenn die `concurrency-tokio` Funktion aktiviert ist. Der Handler muss `Clone` \$1 sein`Send`.
**Testen Sie auf Thread-Sicherheits- und Parallelitätsprobleme.** Testen Sie Ihre Funktionen vor der Bereitstellung in der Produktion gründlich auf Thread-Sicherheitsprobleme, Race-Bedingungen und die korrekte Zustandsisolierung bei gleichzeitiger Last.
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ Konfigurieren Sie die [VPC-Konnektivität für Ihre Kapazitätsanbieter](lambda-managed-instances-networking.md)
+ [Überwachen Sie Lambda Managed Instances mit Metriken CloudWatch ](lambda-managed-instances-monitoring.md)
# Fehlerbehebung bei verwalteten Lambda-Instanzen
## Probleme bei der Drosselung und Skalierung
### Hohe Fehlerraten bei der Skalierung
**Problem: Es** treten Drosselungsfehler (HTTP 429) auf, wenn der Traffic schnell zunimmt.
**Ursache:** Lambda Managed Instances werden asynchron auf der Grundlage der CPU-Ressourcenauslastung und der Mehrparallelität skaliert. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, wenn Lambda Instances und Ausführungsumgebungen entsprechend der Nachfrage skaliert.
**Lösung:**
+ **Passen Sie die Zielressourcenauslastung an:** Wenn Ihr Workload vorhersehbare Verkehrsmuster aufweist, legen Sie eine niedrigere Zielressourcenauslastung fest, um zusätzlichen Spielraum für Datenverkehrsspitzen zu haben.
+ **Kapazität vor der Erwärmung:** Erhöhen Sie den Datenverkehr bei einem geplanten Anstieg des Datenverkehrs über einen längeren Zeitraum schrittweise, damit die Skalierung Schritt halten kann.
+ **Überwachen Sie die Skalierungsmetriken:** Verfolgen Sie die Messwerte für Drosselungsfehler, um den Grund für Drosselungen und Probleme mit der Kapazitätsskalierung zu verstehen.
+ **Überprüfen Sie die Funktionskonfiguration:** Stellen Sie sicher, dass Ihre Funktionsspeicher- und vCPU-Einstellungen mehrere gleichzeitige Ausführungen unterstützen. Erhöhen Sie bei Bedarf die Funktionsspeicher- oder vCPU-Zuweisung.
### Langsames Herunterskalieren
**Problem:** Es dauert lange, bis Instances herunterskaliert werden, nachdem der Traffic zurückgegangen ist.
**Ursache:** Lambda Managed Instances werden schrittweise herunterskaliert, um die Verfügbarkeit aufrechtzuerhalten und schnelle Kapazitätsänderungen zu vermeiden, die sich auf die Leistung auswirken könnten.
**Lösung:**
Dieses Verhalten wird erwartet. Lambda skaliert Instanzen konservativ herunter, um Stabilität zu gewährleisten. Überwachen Sie Ihre CloudWatch Metriken, um die Anzahl der laufenden Instanzen zu verfolgen.
## Probleme mit der Parallelität
### Bei Ausführungsumgebungen mit geringer Parallelität kommt es zu Drosselungen
**Problem:** Ihre Funktionen werden trotz verfügbarer Kapazität gedrosselt.
**Ursache:** Ausführungsumgebungen mit sehr niedriger maximaler Parallelität können Schwierigkeiten haben, effektiv zu skalieren. Lambda Managed Instances sind für Anwendungen mit mehreren gleichzeitigen Vorgängen konzipiert.
**Lösung:**
+ **Erhöhen Sie die maximale Parallelität:** Wenn Ihre Funktionsaufrufen nur sehr wenig CPU verbrauchen, erhöhen Sie die Einstellung für maximale Parallelität auf 64 pro vCPU.
+ **Funktionscode optimieren: Überprüfen Sie Ihren Funktionscode**, um den CPU-Verbrauch pro Aufruf zu reduzieren und so eine höhere Parallelität zu ermöglichen.
+ **Passen Sie den Funktionsspeicher und die vCPU an:** Stellen Sie sicher, dass Ihre Funktion über ausreichende Ressourcen verfügt, um mehrere gleichzeitige Aufrufe zu verarbeiten.
### Probleme mit der Thread-Sicherheit (Java-Laufzeit)
**Problem:** Ihre Java-Funktion erzeugt falsche Ergebnisse oder es treten unter Last Rennbedingungen auf.
**Ursache:** Mehrere Threads führen die Handler-Methode gleichzeitig aus, und der gemeinsame Status ist nicht threadsicher.
**Lösung:**
+ Verwenden Sie `AtomicInteger` or `AtomicLong` für Zähler anstelle von primitiven Typen
+ Ersetze durch `HashMap` `ConcurrentHashMap`
+ Zum `Collections.synchronizedList()` Einwickeln verwenden `ArrayList`
+ Wird `ThreadLocal` für einen anforderungsspezifischen Status verwendet
+ Greifen Sie IDs vom Lambda Context-Objekt aus auf die Ablaufverfolgung zu, nicht über Umgebungsvariablen
Eine ausführliche Anleitung finden Sie in der Dokumentation [Java Runtime for Lambda Managed Instances](lambda-managed-instances-java-runtime.md).
### Probleme mit der Statusisolierung (Laufzeit von Node.js)
**Problem:** Ihre Funktion Node.js gibt Daten aus verschiedenen Anfragen zurück oder es kommt zu Datenbeschädigungen.
**Ursache:** Globale Variablen werden von mehreren gleichzeitigen Aufrufen desselben Worker-Threads gemeinsam genutzt. Wenn asynchrone Operationen die Kontrolle übernehmen, können andere Aufrufe den gemeinsamen Status ändern.
**Lösung:**
+ Installation und Verwendung `@aws/lambda-invoke-store` für alle anforderungsspezifischen Zustände
+ Ersetzen Sie globale Variablen durch und `InvokeStore.set()` `InvokeStore.get()`
+ Verwenden Sie eindeutige Dateinamen in `/tmp` mit Anfrage IDs
+ Access Trace IDs mit Umgebungsvariablen `InvokeStore.getXRayTraceId()` anstelle von Umgebungsvariablen
Eine ausführliche Anleitung finden Sie in der Dokumentation [Node.js Runtime for Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md).
### Dateikonflikte (Python-Laufzeit)
**Problem:** Ihre Python-Funktion liest falsche Daten aus Dateien in`/tmp`.
**Ursache:** Das `/tmp` Verzeichnis wird von mehreren Prozessen gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen.
**Lösung:**
+ Verwenden Sie bei Anfrage IDs eindeutige Dateinamen: `/tmp/request_{context.request_id}.txt`
+ Verwenden Sie das Sperren von Dateien mit `fcntl.flock()` für gemeinsam genutzte Dateien
+ Bereinigen Sie temporäre Dateien mit „`os.remove()`Nach dem Gebrauch“
Eine ausführliche Anleitung finden Sie in der Dokumentation zur [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md).
## Leistungsprobleme
### Hohe Speicherauslastung
**Problem: Bei** Ihren Funktionen kommt es zu hoher Speicherauslastung oder zu out-of-memory Fehlern.
**Ursache:** Jede gleichzeitige Anforderung in Python wird in einem separaten Prozess mit eigenem Speicherplatz ausgeführt. Die gesamte Speichernutzung entspricht dem Speicher pro Prozess multipliziert mit gleichzeitigen Prozessen.
**Lösung:**
+ Überwachen Sie die Metrik in `MemoryUtilization` CloudWatch
+ Reduzieren Sie die `MaxConcurrency` Einstellung, wenn sich die Speichernutzung dem Speicherlimit der Funktion nähert
+ Erhöhen Sie die Speicherzuweisung für Funktionen, um eine höhere Parallelität zu unterstützen
+ Optimieren Sie die Speichernutzung, indem Sie Daten bei Bedarf statt während der Initialisierung laden
### Inkonsistente Leistung
**Problem:** Die Funktionsleistung variiert zwischen Aufrufen erheblich.
**Ursache:** Lambda kann je nach Verfügbarkeit unterschiedliche Instanztypen auswählen, oder Funktionen werden möglicherweise auf Instanzen mit unterschiedlicher Ressourcenverfügbarkeit ausgeführt.
**Lösung:**
+ **Zulässige Instanztypen angeben:** Wenn Sie bestimmte Leistungsanforderungen haben, konfigurieren Sie zulässige Instance-Typen in Ihrem Kapazitätsanbieter, um die Instance-Typen einzuschränken, die Lambda auswählen kann.
+ **Überwachen Sie Metriken auf Instanzebene:** Verfolgen Sie `CPUUtilization` und verfolgen Sie sie `MemoryUtilization` auf Ebene des Kapazitätsanbieters, um Ressourcenbeschränkungen zu identifizieren.
+ Überprüfen Sie `vCPUAvailable` die **Kapazitätskennzahlen:** Stellen Sie sicher`MemoryAvailable`, dass auf Ihren Instances ausreichend Ressourcen verfügbar sind.
## Probleme mit dem Kapazitätsanbieter
### Die Funktionsversion kann nicht AKTIV werden
**Problem:** Ihre Funktionsversion befindet sich nach der Veröffentlichung weiterhin im Status „Ausstehend“.
**Ursache:** Lambda startet Managed Instances und startet Ausführungsumgebungen. Dieser Vorgang benötigt Zeit, insbesondere bei der ersten Funktionsversion eines neuen Kapazitätsanbieters.
**Lösung:**
Warten Sie, bis Lambda den Initialisierungsprozess abgeschlossen hat. Lambda startet standardmäßig drei Instances aus Gründen der AZ-Resilienz und startet drei Ausführungsumgebungen, bevor Ihre Funktionsversion als AKTIV markiert wird. Dies dauert in der Regel mehrere Minuten.
### Der Kapazitätsanbieter kann nicht gelöscht werden
**Problem:** Beim Versuch, einen Kapazitätsanbieter zu löschen, wird eine Fehlermeldung angezeigt.
**Ursache:** Sie können keinen Kapazitätsanbieter löschen, an den Funktionsversionen angehängt sind.
**Lösung:**
1. Identifizieren Sie mit der `ListFunctionVersionsByCapacityProvider` API alle Funktionsversionen, die den Kapazitätsanbieter verwenden.
1. Löschen oder aktualisieren Sie diese Funktionsversionen, um die Zuordnung des Kapazitätsanbieters zu entfernen.
1. Versuchen Sie erneut, den Kapazitätsanbieter zu löschen.
### Generische Fehlermeldungen bei der Veröffentlichung von Funktionen
**Problem:** Beim Veröffentlichen von Funktionen treten generische Fehlermeldungen wie „Beim Publizieren ist ein interner Fehler aufgetreten“ auf.
**Lösung:**
+ **Überprüfen Sie die IAM-Berechtigungen:** Stellen Sie sicher, dass Sie über die entsprechenden `lambda:PassCapacityProvider` Berechtigungen für den Kapazitätsanbieter verfügen, den Sie verwenden möchten.
+ **Überprüfen Sie die Konfiguration des Kapazitätsanbieters:** Stellen Sie mithilfe der `GetCapacityProvider` API sicher, dass sich Ihr Kapazitätsanbieter im Status AKTIV befindet.
+ **Überprüfen Sie die VPC-Konfiguration:** Stellen Sie sicher, dass die in Ihrem Kapazitätsanbieter angegebenen Subnetze und Sicherheitsgruppen korrekt konfiguriert und zugänglich sind.
+ ** AWS CloudTrail Protokolle überprüfen:** In den CloudTrail Protokollen finden Sie detaillierte Fehlerinformationen zu dem fehlgeschlagenen Vorgang.
## Probleme bei der Überwachung und Beobachtbarkeit
### Fehlende Metriken CloudWatch
**Problem:** Sie sehen keine erwarteten Kennzahlen CloudWatch für Ihren Kapazitätsanbieter oder Ihre Funktionen.
**Ursache:** Metriken werden in Intervallen von 5 Minuten veröffentlicht. Bei neuen Kapazitätsanbietern oder Funktionen sind Metriken möglicherweise nicht sofort verfügbar.
**Lösung:**
Warten Sie nach der Veröffentlichung einer Funktionsversion mindestens 5-10 Minuten, bevor Sie erwarten, dass Metriken in angezeigt werden CloudWatch. Vergewissern Sie sich, dass Sie sich den richtigen Namespace (`AWS/Lambda`) und die richtigen Dimensionen (`CapacityProviderName``FunctionName`, oder`InstanceType`) ansehen.
### Protokolle können nicht gefunden CloudWatch werden
**Problem:** Ihre Funktion wird erfolgreich ausgeführt, aber Sie können keine CloudWatch Protokolle in Logs finden.
**Ursache:** Lambda Managed Instances werden in Ihrer VPC ausgeführt und benötigen Netzwerkkonnektivität, um Protokolle an Logs zu CloudWatch senden. Ohne die richtige VPC-Konnektivitätskonfiguration können Ihre Funktionen den Endpunkt des CloudWatch Logs-Dienstes nicht erreichen.
**Lösung:**
Konfigurieren Sie die VPC-Konnektivität, damit Ihre Funktionen CloudWatch Protokolle an Logs senden können. Sie haben drei Möglichkeiten:
**Option 1: VPC-Endpunkt für CloudWatch Logs (für die Produktion empfohlen)**
1. Öffnen Sie die Amazon VPC-Konsole unter [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich **Endpunkte** aus.
1. Wählen Sie **Endpunkt erstellen** aus.
1. Wählen Sie bei **Service category** (Servicekategorie) die Option **AWS services** (-Services) aus.
1. Wählen Sie als **Servicename** die Option (durch Ihre Region ersetzen) aus. `com.amazonaws.region.logs` `region` AWS
1. Wählen Sie für **VPC** die von Ihrem Kapazitätsanbieter verwendete VPC aus.
1. Wählen Sie für **Subnetze** die Subnetze aus, in denen Sie Endpunkt-Netzwerkschnittstellen erstellen möchten. Wählen Sie für eine hohe Verfügbarkeit Subnetze in mehreren Availability Zones aus.
1. Wählen Sie für **Sicherheitsgruppen** Sicherheitsgruppen aus, die eingehenden HTTPS-Verkehr (Port 443) aus der Sicherheitsgruppe Ihrer Funktion zulassen.
1. Aktivieren Sie **Private DNS** für den Endpunkt.
1. Wählen Sie **Endpunkt erstellen** aus.
**Option 2: Öffentliches Subnetz mit Internet-Gateway**
Wenn Ihr Kapazitätsanbieter öffentliche Subnetze verwendet, stellen Sie Folgendes sicher:
1. Ein Internet-Gateway ist an Ihre VPC angeschlossen
1. Die Routentabelle leitet den `0.0.0.0/0` Verkehr an das Internet-Gateway weiter
1. Sicherheitsgruppen lassen ausgehenden HTTPS-Verkehr auf Port 443 zu
**Option 3: Privates Subnetz mit NAT-Gateway**
Wenn Ihr Kapazitätsanbieter private Subnetze verwendet, stellen Sie Folgendes sicher:
1. Ein NAT-Gateway ist in einem öffentlichen Subnetz vorhanden
1. Die Routing-Tabelle des privaten Subnetzes leitet den `0.0.0.0/0` Verkehr an das NAT-Gateway weiter
1. Die öffentliche Subnetz-Routentabelle leitet den `0.0.0.0/0` Verkehr an ein Internet-Gateway weiter
1. Sicherheitsgruppen ermöglichen ausgehenden HTTPS-Verkehr auf Port 443
Eine ausführliche Anleitung zu VPC-Konnektivitätsoptionen finden Sie unter [VPC-Konnektivität für Lambda](lambda-managed-instances-networking.md) Managed Instances.
### Schwierigkeiten beim Korrelieren von Protokollen aus gleichzeitigen Anfragen
**Problem:** Die Protokolle verschiedener Anfragen sind ineinander verschachtelt, was es schwierig macht, einzelne Anfragen nachzuverfolgen.
**Ursache:** Das Verschachteln von Protokollen wird erwartet und ist in Systemen mit mehreren gleichzeitigen Vorgängen Standard.
**Lösung:**
+ **Strukturierte Protokollierung im JSON-Format verwenden: Geben** Sie die Anforderungs-ID in alle Protokollanweisungen ein
+ **Java:** Verwenden Sie Log4j mit, um die `ThreadContext` Anfrage-ID automatisch einzubeziehen
+ **Node.js:** `console.log()` Mit JSON-Formatierung verwenden und einschließen `InvokeStore.getRequestId()`
+ **Python:** Verwenden Sie das Standard-Logging-Modul mit JSON-Formatierung und fügen Sie hinzu `context.request_id`
Eine ausführliche Anleitung finden Sie auf den laufzeitspezifischen Dokumentationsseiten.
## Weitere Hilfe
Wenn Sie nach dem Ausprobieren dieser Lösungen weiterhin Probleme haben:
1. ** CloudWatch Kennzahlen überprüfen:** Überprüfen Sie die Kennzahlen zum Kapazitätsanbieter und zur Ausführungsumgebung, um Ressourcenbeschränkungen oder Skalierungsprobleme zu identifizieren.
1. ** AWS CloudTrail Protokolle überprüfen:** In den CloudTrail Protokollen finden Sie detaillierte Informationen zu API-Aufrufen und Fehlern.
1. ** AWS Support kontaktieren:** Wenn Sie das Problem nicht lösen können, wenden Sie sich mit Einzelheiten zur Konfiguration Ihres Kapazitätsanbieters, zur Funktionskonfiguration und zu den spezifischen Fehlermeldungen, auf die Sie stoßen, an den AWS Support.
## Nächste Schritte
+ Erfahren Sie mehr über [Kapazitätsanbieter für Lambda Managed Instances](lambda-managed-instances-capacity-providers.md)
+ [Skalierung für Lambda Managed Instances](lambda-managed-instances-scaling.md) verstehen
+ [Lesen Sie laufzeitspezifische Anleitungen für [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) und Python](lambda-managed-instances-python-runtime.md)
+ [Überwachen Sie Lambda Managed Instances mit Metriken CloudWatch ](lambda-managed-instances-monitoring.md)
+ Informieren Sie sich über [bewährte Methoden für Lambda Managed Instances](lambda-managed-instances-best-practices.md)