Variables d’environnement

Les variables d'environnement sont des paires clé-valeur accessibles au code de votre application au moment de l'exécution. Utilisez des variables d'environnement pour les configurations non sensibles que vous souhaitez modifier sans modifier le code, telles que les indicateurs de fonctionnalité, les niveaux de journalisation et les identifiants de ressources tels que le nom d'hôte d'une base de données. Pour les valeurs sensibles telles que les clés d'API et les informations d'identification de base de données, ne les stockez pas dans des variables d'environnement. Utilisez plutôt Secrets Manager ou AWS Systems Manager Parameter Store et récupérez les valeurs lors de l'exécution.

Les variables d'environnement sont définies lorsque vous créez la révision et sont immuables après la création. Pour modifier une variable d'environnement, créez une nouvelle révision. Dans la nouvelle version, spécifiez toutes les variables d'environnement et tous les serviceConfig paramètres que vous souhaitez conserver, et pas uniquement les valeurs qui changent. Les paramètres que vous omettez prennent leurs valeurs par défaut, et les variables d'environnement que vous omettez ne sont pas définies.

Lambda définit la variable d'environnement suivante spécifiquement pour les fonctions Web :

Les fonctions Web reçoivent également d'autres variables d'environnement d'exécution Lambda, telles que AWS_LAMBDA_FUNCTION_MEMORY_SIZEAWS_LAMBDA_METADATA_API, et. AWS_LAMBDA_METADATA_TOKEN Pour la liste générale, voirVariables d’environnement d’exécution définies. Si votre code ou une bibliothèque lit une variable de cette liste, vérifiez que Lambda la définit dans une fonction Web avant de vous y fier. Les fonctions Web ne reçoivent pas toutes les variables de cette liste.

Les noms de variables d'environnement suivants sont réservés aux fonctions Web Lambda et ne peuvent pas être définis. Si vous en spécifiez une, Lambda rejette la demande de création d'une fonction Web ou d'une révision :

Certains frameworks lisent plutôt leurs propres variables d'environnement pour l'adresse d'écoute. Par exemple, le mode Next.js autonome lit HOSTNAME et. PORT Pour de tels frameworks, utilisez un fichier index.js d'entrée qui définit ces variables AWS_LAMBDA_HTTP_ENDPOINT avant de démarrer le serveur.

Par défaut, le moteur d'exécution se charge index.js à la racine de votre package de déploiement en tant que fichier d'entrée de votre application. Le moteur d'exécution ne lit pas le point d'entrée depuispackage.json. Si votre fichier d'entrée a un nom ou un chemin différent (par exemple,dist/index.js), définissez la variable d'AWS_LAMBDA_NODEJS_ENTRYPOINTenvironnement sur son chemin, par rapport à la racine de votre package.

L'exemple suivant montre comment lire la variable d'AWS_LAMBDA_HTTP_ENDPOINTenvironnement dans une Node.js application :

// Lambda provides the address to bind in AWS_LAMBDA_HTTP_ENDPOINT ("host:port").
// The fallback applies only when running locally.
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host, () => {
  console.log(`Server listening on ${host}:${port}`);
});

Pour définir vos propres variables d'environnement, ajoutez une environmentVariables carte à l'serviceConfigobjet lorsque vous créez une révision, comme dans l'exemple suivant. Pour la commande complète, voirCréation d'une révision.

{
  "executionRoleArn": "arn:aws:iam::111122223333:role/my-web-function-role",
  "environmentVariables": {
    "DATABASE_URL": "my-database-endpoint",
    "LOG_LEVEL": "info",
    "FEATURE_FLAG_NEW_UI": "true"
  }
}

Si vous spécifiez une clé gérée par le client, Lambda chiffre les variables d'environnement au repos avec cette clé. Pour plus d'informations, consultez Chiffrement au repos pour les fonctions Web.