Funktionen von Lambda Managed Instances bereitstellen und aktualisieren

Wenn Sie eine Lambda Managed Instances-Funktion aktualisieren, stellt Lambda Ausführungsumgebungen für die neue Funktionsversion auf Ihren verwalteten Instances bereit, bevor der Datenverkehr dorthin verlagert wird. Sie können die Geschwindigkeit und Sicherheit der Bereitstellung kontrollieren, indem Sie eine Bereitstellungsstrategie auswählen. In diesem Thema werden die Bereitstellungsstrategien beschrieben, die für Lambda Managed Instances-Funktionen verfügbar sind, und wie sie mithilfe von Infrastructure as Code (IaC) definiert werden.

Anmerkung

Bevor Sie eine Funktion bereitstellen, benötigen Sie einen Kapazitätsanbieter. Weitere Informationen finden Sie unter Kapazitätsanbieter für Lambda Managed Instances.

Bereitstellungsstrategien

Lambda Managed Instances unterstützt die folgenden Strategien für die Veröffentlichung einer neuen Funktionsversion. Wählen Sie die Strategie, die dem Umfang der Kontrolle entspricht, die Sie über den Rollout behalten möchten. Fortlaufende Updates sind die einfachste Option. Blue/green und Canary-Deployments geben dir mehr Kontrolle darüber, wie der Traffic auf die neue Version übertragen wird.

Fortlaufende Updates

Um ein fortlaufendes Update durchzuführen, veröffentlichen Sie Ihre Änderungen im $LATEST.PUBLISHED Version Ihrer Funktion. $LATEST.PUBLISHED ist ein für Lambda Managed Instances spezifischer Versionstyp, den Sie mit neuem Code oder neuer Konfiguration erneut veröffentlichen, anstatt nummerierte Versionen beizubehalten. Wenn Sie eine Lambda Managed Instances-Funktion mit ihrem unqualifizierten Amazon-Ressourcennamen (ARN) aufrufen, ruft Lambda die $LATEST.PUBLISHED Version. Weitere Informationen finden Sie unter LATEST.PUBLISHED $-Version in von Lambda verwalteten Instances.

Jedes Mal, wenn Sie erneut veröffentlichen $LATEST.PUBLISHED, Lambda ersetzt die Ausführungsumgebungen auf Ihren verwalteten Instances schrittweise durch die neue Version, ohne dass Sie den Traffic direkt über einen Funktionsalias verwalten müssen. Dies ist die einfachste Strategie.

Verwenden Sie fortlaufende Updates, wenn Sie eine automatische schrittweise Verlagerung des Datenverkehrs von der alten Version auf die neue Version wünschen und keine direkte Kontrolle über den Prozentsatz des Datenverkehrs benötigen, der an jede Version gesendet wird, um die Bereitstellung oder das Rollback zu verwalten.

Blue/green Bereitstellungen mit einem gewichteten Alias

In einem blue/green Bei einer Bereitstellung veröffentlichen Sie die neue Version zusammen mit der aktuellen Version und verwenden eine Alias mit einer Routing-Konfiguration, um einen Prozentsatz des Datenverkehrs an die neue Version zu senden. Sie rufen die Funktion über den Alias-qualifizierten ARN auf. Um die Bereitstellung weiterzuentwickeln, erhöhen Sie die Gewichtung der neuen Version. Um sie rückgängig zu machen, verlagern Sie die Gewichtung auf die vorherige Version zurück.

Das folgende Beispiel verwendet AWS CLI, um 10 Prozent des Datenverkehrs an Version zu senden 2 während der Version 1 bedient weiterhin die restlichen 90 Prozent.

aws lambda update-alias \
  --function-name my-managed-instance-function \
  --name production \
  --function-version 1 \
  --routing-config AdditionalVersionWeights={"2"=0.1}

In diesem Befehl gilt Folgendes:

• my-managed-instance-function ist der Name Ihrer Funktion.

• production ist der Name des Alias, den Sie aufrufen.

• --function-version 1 ist die Version, die weiterhin den verbleibenden Datenverkehr empfängt.

• AdditionalVersionWeights={"2"=0.1} sendet 10 Prozent des Datenverkehrs an Version 2.

Um ein Rollback durchzuführen, löschen Sie die Routing-Konfiguration, sodass der gesamte Datenverkehr zur stabilen Version zurückkehrt.

aws lambda update-alias \
  --function-name my-managed-instance-function \
  --name production \
  --function-version 1 \
  --routing-config '{}'

In diesem Befehl --routing-config '{}' löscht die Routing-Konfiguration, sodass der gesamte Datenverkehr zur Version in zurückkehrt --function-version, Version 1.

Canary-Einsätze mit AWS CodeDeploy

Um eine zu automatisieren blue/green Verkehrsverlagerung, benutze AWS CodeDeploy. CodeDeploy leitet den Datenverkehr gemäß einer Bereitstellungskonfiguration von der aktuellen Version auf die neue Version um. Beispielsweise werden 10 Prozent des Datenverkehrs an die neue Version gesendet, fünf Minuten gewartet und dann der Rest verschoben. Wenn ein CloudWatch ein mit dem Einsatz verbundener Alarm während der Schicht in einen Alarmzustand übergeht, CodeDeploy setzt den Einsatz automatisch zurück.

Für weitere Informationen über CodeDeploy Bereitstellungskonfigurationen für Lambda finden Sie unter Bereitstellungskonfigurationen auf einer Lambda-Rechenplattform in der AWS CodeDeploy Benutzerleitfaden.

Wählen Sie zwischen $LATEST.PUBLISHED und numerische Versionen mit Aliasen

Bei beiden Bereitstellungsmodellen werden Änderungen eingeführt allmählich. Ob du aktualisierst $LATEST.PUBLISHED Wenn Sie den Traffic mit einem gewichteten Alias verlagern, ersetzt Lambda Managed Instances die Ausführungsumgebungen der alten Version schrittweise durch die neue Version und nicht alle gleichzeitig. Dieser Ansatz sorgt für eine effiziente Nutzung der Instanzen während des Rollouts. Anstatt im Voraus einen kompletten zweiten Satz von Ausführungsumgebungen bereitzustellen, ersetzt Lambda diese schrittweise: Bei jedem Schritt gewinnt es Kapazität aus der alten Version zurück, bevor der nächste Batch der neuen Version veröffentlicht wird, sodass beim Rollout vermieden wird, dass die doppelte Basiskapazität erreicht wird.

Wie $LATEST.PUBLISHED Der Rollout schreitet voran

Wenn Sie ein Update veröffentlichen für $LATEST.PUBLISHED, Lambda beginnt mit der schrittweisen Einführung der neuen Version. Bei jedem Schritt erstellt Lambda neue Ausführungsumgebungen — bis zu 20 Prozent der Gesamtmenge der alten Version — und ersetzt schrittweise die Ausführungsumgebungen der alten Version.

Zwei Faktoren bestimmen, wie lange die Einführung dauert:

• Zeit der Initialisierung - Jeder Schritt wartet darauf, dass die neuen Ausführungsumgebungen initialisiert sind, bevor er fortgesetzt wird. Wenn die Initialisierung 10 Minuten dauert, wartet jeder Schritt mindestens 10 Minuten.

• Dauer des Aufrufs — Bevor Lambda eine alte Ausführungsumgebung entfernen kann, müssen die während des Fluges ausgeführten Aufrufe abgeschlossen sein (Drain). Wenn Ihre durchschnittliche Aufrufdauer 5 Minuten beträgt, dauert das Entleeren bei jedem Schritt im Durchschnitt etwa 5 Minuten.

Da Lambda Managed Instances für eine hohe Instanzauslastung sorgen, tragen sowohl die Initialisierung als auch die Entleerung zur Gesamtbereitstellungszeit bei. Funktionen mit langer Initialisierung oder lang andauernden Aufrufen benötigen länger, bis sie vollständig eingeführt werden.

Wie entwickeln sich numerische Versionen mit Aliasen

Gewichtete Alias-Aktualisierungen erfolgen auf die gleiche Weise schrittweise. Wenn Sie die Routing-Gewichtungen für einen Alias ändern — beispielsweise von 90 Prozent Version 1 und 10 Prozent Version 2 auf 100 Prozent — ersetzt Lambda Managed Instances langsam die Ausführungsumgebungen der Version 1 durch Version 2, ohne dass überschüssige Instance-Kapazität bereitgestellt wird.

Verwenden Sie numerische Versionen mit einem Alias, wenn Sie eine genauere Kontrolle über den schrittweisen Rollout und die versionsspezifische Beobachtbarkeit wünschen. Da es sich bei jeder Version um einen eigenen Qualifizierer handelt, können Sie die Kennzahlen für die Canary-Version und die Stable-Version vergleichen, bevor Sie für eine Änderung werben. Weitere Informationen finden Sie unter Metriken für Ihre Lambda-Funktionen anzeigen.

Konfiguration der Skalierung nach einer Bereitstellung

Jede Funktionsversion, die Sie bereitstellen, hat ihre eigene Skalierungskonfiguration, die die minimale und maximale Anzahl von Ausführungsumgebungen steuert, die Lambda für diese Version verwaltet. Stellen Sie die Skalierungskonfiguration ein, nachdem Sie eine Version veröffentlicht haben, sodass die neue Version den Datenverkehr mit der erwarteten Kapazität bedienen kann.

Im folgenden Beispiel wird die Skalierungskonfiguration für eine bestimmte Version festgelegt. Ersetzen 2 mit deiner Versionsnummer oder mit $LATEST.PUBLISHED.

aws lambda put-function-scaling-config \
  --function-name my-managed-instance-function \
  --qualifier 2 \
  --function-scaling-config MinExecutionEnvironments=3,MaxExecutionEnvironments=20

Verwaltung von Bereitstellungen mit Infrastruktur als Code

Sie können die Funktionen von Lambda Managed Instances und deren Kapazitätsanbieter mit Infrastruktur als Code definieren und bereitstellen, einschließlich AWS CloudFormation, der AWS Cloud-Entwicklungskit (AWS CDK) und Tools von Drittanbietern wie HashiCorp Terraform. Modellieren Sie Ihren Kapazitätsanbieter, Ihre Funktion, Ihre Versionen und Ihren Alias als Ressourcen, sodass Ihre Bereitstellungsstrategie reproduzierbar und überprüfbar ist.

Beachten Sie bei der Verwaltung von Lambda Managed Instance-Bereitstellungen mit IaC die folgenden Überlegungen:

• Veröffentlichen Sie eine Version, um eine Änderung zu aktivieren. Eine neue Funktionsversion wird auf den Instanzen des Kapazitätsanbieters erst aktiv, nachdem sie veröffentlicht wurde. Modellieren Sie jede Version, die Sie weiterhin verwenden möchten, z. B. beide Seiten einer blue/green shift — als eigene Ressource.

• Die Skalierung der Konfiguration erfolgt pro Version. Wenden Sie die minimalen und maximalen Einstellungen für die Ausführungsumgebung auf jede Version an oder $LATEST.PUBLISHED. Wenn Ihr IAC-Tool die Skalierungskonfiguration nicht direkt modelliert, stellen Sie sie mit dem put-function-scaling-config AWS CLI-Befehl nach der Bereitstellung.

• Bereitstellungspakete müssen von Amazon S3 stammen, wenn Sie das verwenden AWS Cloud Control-API. Die AWS Die Cloud Control API akzeptiert den Code einer Funktion nur als Amazon S3-Standort- oder Container-Image-URI, nicht als lokal hochgeladene ZIP-Datei. Wenn Ihr IAC-Tool diese API verwendet, laden Sie Ihr Bereitstellungspaket zuerst in einen S3-Bucket hoch und referenzieren Sie es mit Bucket und Schlüssel. Verwenden Sie einen versionierten Bucket, damit Aktualisierungen des Objekts erkannt werden.

Beispiel: CloudFormation Muster

Das Folgende CloudFormation Die Vorlage zeigt eine blue/green Einsatz. Es erstellt einen Kapazitätsanbieter, eine Lambda Managed Instances-Funktion, zwei veröffentlichte Versionen (jede mit ihrer eigenen Funktionsskalierungskonfiguration) und einen Alias mit dem Namen production das leitet 90 Prozent des Datenverkehrs an die stabile Version und 10 Prozent an die Canary-Version weiter. Um für den Canary zu werben, legen Sie den Alias fest FunctionVersion zur Canary-Version und entferne den RoutingConfig. Um den Vorgang rückgängig zu machen, entfernen Sie den RoutingConfig damit der gesamte Verkehr zur stabilen Version zurückkehrt. Ersetzen Sie das Subnetz, die Sicherheitsgruppe, die Rolle und die Amazon S3-Werte durch Ihre eigenen Werte.

AWSTemplateFormatVersion: '2010-09-09'
Description: Lambda Managed Instances blue/green deployment with a weighted alias

Resources:
  MyCapacityProvider:
    Type: AWS::Lambda::CapacityProvider
    Properties:
      CapacityProviderName: my-capacity-provider
      VpcConfig:
        SubnetIds:
          - subnet-0123456789abcdef0
        SecurityGroupIds:
          - sg-0123456789abcdef0
      PermissionsConfig:
        CapacityProviderOperatorRoleArn: arn:aws:iam::111122223333:role/my-capacity-provider-operator-role
      InstanceRequirements:
        Architectures:
          - arm64

  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: my-managed-instance-function
      Role: arn:aws:iam::111122223333:role/my-function-execution-role
      Runtime: python3.13
      Handler: index.lambda_handler
      Architectures:
        - arm64
      Code:
        S3Bucket: my-deployment-bucket
        S3Key: function.zip
      CapacityProviderConfig:
        LambdaManagedInstancesCapacityProviderConfig:
          CapacityProviderArn: !GetAtt MyCapacityProvider.Arn

  # Stable version - receives the majority of traffic
  StableVersion:
    Type: AWS::Lambda::Version
    Properties:
      FunctionName: !Ref MyFunction
      FunctionScalingConfig:
        MinExecutionEnvironments: 10
        MaxExecutionEnvironments: 50

  # Canary version - receives a small percentage of traffic
  CanaryVersion:
    Type: AWS::Lambda::Version
    Properties:
      FunctionName: !Ref MyFunction
      FunctionScalingConfig:
        MinExecutionEnvironments: 3
        MaxExecutionEnvironments: 20

  ProductionAlias:
    Type: AWS::Lambda::Alias
    Properties:
      FunctionName: !Ref MyFunction
      Name: production
      FunctionVersion: !GetAtt StableVersion.Version
      RoutingConfig:
        AdditionalVersionWeights:
          - FunctionVersion: !GetAtt CanaryVersion.Version
            FunctionWeight: 0.1

Beispiel: CDK

Das folgende CDK-Beispiel (TypeScript) definiert denselben Kapazitätsanbieter und dieselbe Funktion unter Verwendung der Level-1-Konstrukte (L1) aus aws-cdk-lib/aws-lambda Modul. operatorRole und executionRole sind IAM-Rollen an anderer Stelle in Ihrem Stack definiert.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';

const capacityProvider = new lambda.CfnCapacityProvider(this, 'MyCapacityProvider', {
  capacityProviderName: 'my-capacity-provider',
  vpcConfig: {
    subnetIds: ['subnet-0123456789abcdef0'],
    securityGroupIds: ['sg-0123456789abcdef0'],
  },
  permissionsConfig: {
    capacityProviderOperatorRoleArn: operatorRole.roleArn,
  },
  instanceRequirements: {
    architectures: ['arm64'],
  },
});

const fn = new lambda.CfnFunction(this, 'MyFunction', {
  functionName: 'my-managed-instance-function',
  role: executionRole.roleArn,
  runtime: 'python3.13',
  handler: 'index.lambda_handler',
  architectures: ['arm64'],
  code: { s3Bucket: 'my-deployment-bucket', s3Key: 'function.zip' },
  capacityProviderConfig: {
    lambdaManagedInstancesCapacityProviderConfig: {
      capacityProviderArn: capacityProvider.attrArn,
    },
  },
  functionScalingConfig: {
    minExecutionEnvironments: 3,
    maxExecutionEnvironments: 20,
  },
  publishToLatestPublished: true,
});
fn.addDependency(capacityProvider);

Beispiel: Canary-Bereitstellung mit AWS CodeDeploy

Das folgende CDK-Beispiel (TypeScript) verwendet AWS CodeDeploy um den Verkehr automatisch auf eine neue Funktionsversion umzuleiten. Das LambdaDeploymentGroup sendet fünf Minuten lang 10 Prozent des Datenverkehrs auf die neue Version und verschiebt dann den Rest. Wenn der CloudWatch während des Einsatzes in einen Alarmzustand übergeht, CodeDeploy kehrt zur vorherigen Version zurück.

fn ist der L1 CfnFunction aus dem vorherigen Beispiel. Weil CodeDeployist LambdaDeploymentGroup arbeitet mit dem Level-2-Alias (L2) und den Funktionskonstrukten, importiert die L1-Funktion per ARN und erstellt daraus die Version und den Alias.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as codedeploy from 'aws-cdk-lib/aws-codedeploy';
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';

// Import the L1 function so that L2 constructs can reference it.
const importedFn = lambda.Function.fromFunctionArn(this, 'ImportedFunction', fn.attrArn);

// Publish the version that CodeDeploy shifts traffic to.
const canaryVersion = new lambda.CfnVersion(this, 'CanaryVersion', {
  functionName: fn.ref,
});

// Create the alias that CodeDeploy shifts traffic on.
const alias = new lambda.Alias(this, 'ProductionAlias', {
  aliasName: 'production',
  version: lambda.Version.fromVersionAttributes(this, 'CanaryVersionRef', {
    lambda: importedFn,
    version: canaryVersion.attrVersion,
  }),
});

// Roll back automatically if this alarm fires during the deployment.
const errorAlarm = new cloudwatch.Alarm(this, 'ErrorAlarm', {
  metric: importedFn.metricErrors({ period: cdk.Duration.minutes(1) }),
  threshold: 5,
  evaluationPeriods: 1,
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
});

new codedeploy.LambdaDeploymentGroup(this, 'CanaryDeployment', {
  alias,
  deploymentConfig: codedeploy.LambdaDeploymentConfig.CANARY_10PERCENT_5MINUTES,
  alarms: [errorAlarm],
  autoRollback: {
    failedDeployment: true,
    deploymentInAlarm: true,
  },
});

Nächste Schritte

• Verstehen Skalierung für von Lambda verwaltete Instances

• Erfahren Sie mehr über Kapazitätsanbieter für Lambda Managed Instances

• Überprüfung bewährte Methoden für von Lambda verwaltete Instances