Un développeur dispose d'une application qui utilise une fonction AWS Lambda pour télécharger des fichiers vers Amazon S3 et a besoin d'autorisations pour effectuer ces téléchargements. Le développeur possède déjà un utilisateur IAM avec des informations d'identification IAM valides pour Amazon S3. Que doit faire un architecte de solutions pour accorder les autorisations requises ?

La bonne approche consiste à créer un rôle d'exécution IAM avec les autorisations S3 nécessaires et à l'attacher à la fonction Lambda. Lambda assume ce rôle lors de son exécution, ce qui lui confère les autorisations requises pour interagir avec S3 sans stocker de clés d'accès directement dans le code ou la configuration de la fonction. C'est la méthode recommandée par AWS pour accorder des autorisations aux services. Ajouter des autorisations à la politique de ressources de la fonction Lambda ne fonctionnerait pas car la politique de ressources contrôle qui peut invoquer la fonction, pas les autorisations que la fonction a pour appeler d'autres services AWS. Créer une requête signée est une méthode pour accorder un accès temporaire à des utilisateurs spécifiques pour des objets S3, mais ce n'est pas la bonne approche pour une fonction Lambda qui a besoin d'un accès persistant à S3. Créer un nouvel utilisateur IAM et utiliser ses informations d'identification dans la fonction Lambda est une mauvaise pratique de sécurité, car cela implique de stocker des informations d'identification à long terme, ce qui est risqué.